2010-02-06 10 views
101

मैं फ़्रेमबफर और रेंडरबफर की अवधारणा के बारे में उलझन में हूं। मुझे पता है कि उन्हें प्रस्तुत करने की आवश्यकता है, लेकिन मैं उपयोग से पहले उन्हें समझना चाहता हूं।ओपनजीएल में फ्रेमबफर और रेंडरबफर के बीच की अवधारणा और अंतर क्या है?

मुझे पता है कि अस्थायी ड्राइंग परिणाम को स्टोर करने के लिए कुछ बिटमैप बफर की आवश्यकता है। बैक बफर और जब अन्य चित्र प्रगति पर हैं तो अन्य बफर को स्क्रीन पर देखा जाना आवश्यक है। सामने बफर और उन्हें फ्लिप करें, और फिर ड्रा करें। मैं इस अवधारणा को जानता हूं, लेकिन उन वस्तुओं को इस अवधारणा से जोड़ना मुश्किल है।

उनमें से अवधारणा और अंतर क्या है?

+5

रेंडरबफर फ्रेमबफर के चैनल-जैसे घटक (रंग, स्टेनलेस, गहराई और आदि) है। देखें: http://developer.apple.com/iphone/library/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/OpenGLESontheiPhone/OpenGLESontheiPhone.html – Eonil

+0

लिंक आईफोन विशिष्ट है, लेकिन फ्रेमबफर अच्छी तरह से समझाए गए हैं। – j00hi

उत्तर

51

This page में कुछ विवरण हैं जो मुझे लगता है कि अंतर काफी अच्छी तरह से समझाता है। सबसे पहले:

ओपन पाइपलाइन के अंतिम प्रतिपादन गंतव्य [यह] फ्रेमबफर कहा जाता है।

जबकि:

Renderbuffer वस्तु
इसके अलावा, renderbuffer वस्तु नव गुप्त प्रतिपादन के लिए शुरू की है। यह एक बनावट ऑब्जेक्ट को प्रतिपादित करने के बजाय सीधे एक रेंडरबफर ऑब्जेक्ट में एक दृश्य प्रस्तुत करने की अनुमति देता है। रेंडरबफर बस एक डाटा स्टोरेज ऑब्जेक्ट है जिसमें एक रेंडर करने योग्य आंतरिक प्रारूप की एक छवि होती है। इसका उपयोग ओपनजीएल लॉजिकल बफर को स्टोर करने के लिए किया जाता है, जिनमें स्टैंसिल या गहराई बफर जैसे संबंधित बनावट प्रारूप नहीं होते हैं।

+0

बिल्कुल सही। धन्यवाद! – Eonil

144

फ्रेमबफर वस्तु वास्तव में एक बफर, लेकिन एक एग्रीगेटर उद्देश्य यह है कि एक या अधिक अटैचमेंट है, जो अपनी बारी से, वास्तविक बफ़र्स होते हैं नहीं है। आप फ्रेमबफर सी संरचना के रूप में समझ सकते हैं जहां प्रत्येक सदस्य एक बफर के लिए सूचक होता है। किसी भी अनुलग्नक के बिना, फ़्रेमबफर ऑब्जेक्ट में बहुत कम पदचिह्न है।

अब प्रत्येक बफर एक फ्रेमबफर से जुड़ी एक Renderbuffer या एक बनावट हो सकता है।

रेंडरबफर एक वास्तविक बफर (बाइट्स, या पूर्णांक, या पिक्सल की एक सरणी) है। रेंडरबफर देशी प्रारूप में पिक्सेल मान स्टोर करता है, इसलिए इसे ऑफस्क्रीन प्रतिपादन के लिए अनुकूलित किया गया है। दूसरे शब्दों में, पर रेंडरबफर एक बनावट के चित्रण से कहीं अधिक तेज हो सकता है। दोष यह है कि पिक्सल देशी, कार्यान्वयन-निर्भर प्रारूप का उपयोग करता है, ताकि से रेंडरबफर एक बनावट से पढ़ने से कहीं अधिक कठिन हो। फिर भी, एक बार रेंडरबफर चित्रित किया गया है, कोई भी अपनी सामग्री को सीधे स्क्रीन पर कॉपी कर सकता है (या अन्य रेंडरबफर, मुझे लगता है), पिक्सेल स्थानांतरण संचालन का उपयोग करके बहुत जल्दी। इसका मतलब है कि रेंडरबफर का उपयोग आपके द्वारा वर्णित डबल बफर पैटर्न को कुशलतापूर्वक कार्यान्वित करने के लिए किया जा सकता है।

रेंडरबफर अपेक्षाकृत नई अवधारणा है।उनके सामने, फ़्रेमबफरबनावट पर प्रस्तुत करने के लिए उपयोग किया गया था, जो धीमा हो सकता है क्योंकि एक बनावट मानक प्रारूप का उपयोग करती है। एक बनावट को प्रस्तुत करना अभी भी संभव है, और यह काफी उपयोगी है जब किसी को दृश्य बनाने के लिए प्रत्येक पिक्सेल पर एकाधिक पास करने की आवश्यकता होती है, या किसी अन्य दृश्य की सतह पर एक दृश्य खींचने की आवश्यकता होती है!

ओपनजीएल विकी में this page है जो अधिक जानकारी और लिंक दिखाता है।

+9

धन्यवाद! इसे समझाते हुए जैसे कि structs और पॉइंटर्स मुझे बहुत अधिक समझ में आता है। – DouglasHeriot

+2

यह अभी भी मेरे लिए थोड़ा उलझन में है। यदि रेंडरबफर केवल एक त्वरित प्रतिलिपि बफर को प्रतिलिपि देता है, तो उसके लिए लगभग कोई उपयोग नहीं है! अगर मुझे पोस्ट-प्रसंस्करण चरण (एसएसएओ की तरह) करना है तो इसे डिफ़ॉल्ट फ्रेमबफर पर प्रस्तुत करना अधिक आसान नहीं है, जो पहले इसे रेंडरबफर में प्रस्तुत करने और फिर स्क्रीन पर प्रतिलिपि बनाने की तुलना में बनावट के लिए प्रस्तुत किया जाता है? – GameDeveloper

+3

रेंडर बफर कस्टम पोस्ट-प्रोसेसिंग के लिए डिज़ाइन नहीं किए गए हैं। इन्हें ड्रॉ प्रक्रिया के लिए गहराई और स्टैंसिल जानकारी स्टोर करने के लिए उपयोग किया जा सकता है। यह संभव है क्योंकि केवल जीपीएल कार्यान्वयन को खुद को रेंडरबफर डेटा पढ़ने की आवश्यकता होती है, और बनावट की तुलना में तेज़ी से होती है, क्योंकि मूल स्वरूप का उपयोग करता है। यदि आपको पोस्ट प्रोसेसिंग की आवश्यकता है, तो बनावट का उपयोग करें। – fernacolo

संबंधित मुद्दे