ओपनजीएल के 'बाइंड' कार्यों के पीछे अवधारणा

Question

मैं this tutorial से ओपनजीएल सीख रहा हूं। मेरा प्रश्न सामान्य रूप से विनिर्देश के बारे में है, एक विशिष्ट कार्य या विषय के बारे में नहीं। जब निम्नलिखित की तरह कोड देखकर:

glGenBuffers(1, &positionBufferObject); 
glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject); 
glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW); 
glBindBuffer(GL_ARRAY_BUFFER, 0); 

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

glBindBuffer आप बना सकते हैं या एक नामित बफर वस्तु का उपयोग करने देता है:

आदमी पेज कि कहते हैं। GL_ARRAY_BUFFER, GL_ELEMENT_ARRAY_BUFFER, GL_PIXEL_PACK_BUFFER या GL_PIXEL_UNPACK_BUFFER या GL_PIXEL_UNPACK_BUFFER और GF_PIXEL_UNPACK_BUFFER और बफर सेट नए बफर ऑब्जेक्ट के नाम पर सेट के साथ glbindBuffer को कॉल करने के लिए बफर ऑब्जेक्ट का नाम लक्ष्य पर बाध्य करता है। जब एक बफर ऑब्जेक्ट लक्ष्य से जुड़ा होता है, तो उस लक्ष्य के लिए पिछला बाध्यकारी स्वचालित रूप से टूटा हुआ होता है।

'लक्ष्य' के लिए कुछ 'बाध्यकारी' की अवधारणा/उपयोगिता वास्तव में क्या है?

Answer 1

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

इसलिए जब आप कोई फ़ंक्शन कॉल करते हैं, तो यह निश्चित रूप से तर्कों पर निर्भर करता है, लेकिन संदर्भ/वस्तु पर - ओपनगल की आंतरिक स्थिति पर भी।

यह बाइंड के साथ बहुत स्पष्ट है, जो कहता है "इसे वर्तमान एक्स के रूप में सेट करें"। फिर बाद में कार्य "वर्तमान एक्स" को संशोधित करते हैं (जहां एक्स बफर हो सकता है, उदाहरण के लिए)। [अद्यतन:] और जैसा कि आप कहते हैं, सेट की जा रही चीज़ (ऑब्जेक्ट में विशेषता, या "डेटा सदस्य") बाध्य करने वाला पहला तर्क है। इसलिए GL_ARRAY_BUFFER एक विशेष चीज़ को नामित करता है जिसे आप सेट कर रहे हैं।

और प्रश्न के दूसरे भाग का उत्तर देने के लिए - इसे 0 पर सेट करना केवल मूल्य को साफ़ करता है ताकि आप गलती से अनियोजित परिवर्तन न करें।

Answer 2

लक्ष्य के लिए एक बफर बाध्य करना वैश्विक चर सेट करने जैसा कुछ है। इसके बाद के फ़ंक्शन कॉल उस वैश्विक डेटा पर काम करते हैं। ओपनजीएल के मामले में सभी "वैश्विक चर" एक साथ जीएल संदर्भ बनाते हैं। वस्तुतः सभी जीएल फ़ंक्शंस उस संदर्भ से पढ़ते हैं या इसे किसी भी तरीके से संशोधित करते हैं।

glGenBuffers() कॉल malloc() की तरह है, जो एक बफर आवंटित करता है; हमने glBindBuffer() के साथ इसे इंगित करने के लिए एक वैश्विक सेट किया है; हम उस ग्लोबल (glBufferData()) पर चलने वाले फ़ंक्शन को कॉल करते हैं और फिर हम वैश्विक को NULL पर सेट करते हैं, इसलिए यह glBindBuffer() का उपयोग करके अनजाने में उस बफर पर काम नहीं करेगा।

Answer 3

अनुभाग structs की तरह Introduction: What is OpenGL?

परिसर समुच्चय सीधे ओपन में कभी नहीं संपर्क में हैं से

। ऐसी कोई संरचना एपीआई के पीछे छिपी हुई है। इससे ओपनजीएल एपीआई को जटिल रूपांतरण परत के बिना गैर-सी भाषाओं में बेनकाब करना आसान हो जाता है।

सी ++ में, यदि आप एक वस्तु है कि एक पूर्णांक, एक नाव, और एक स्ट्रिंग निहित चाहता था, आप इसे और यह पहुँच इस प्रकार बना होगा:

struct Object 
{ 
    int count; 
    float opacity; 
    char *name; 
}; 

//Create the storage for the object. 
Object newObject; 

//Put data into the object. 
newObject.count = 5; 
newObject.opacity = 0.4f; 
newObject.name = "Some String"; 

ओपन में, क्या तुम करोगी इनमें से

//Create the storage for the object 
GLuint objectName; 
glGenObject(1, &objectName); 

//Put data into the object. 
glBindObject(GL_MODIFY, objectName); 
glObjectParameteri(GL_MODIFY, GL_OBJECT_COUNT, 5); 
glObjectParameterf(GL_MODIFY, GL_OBJECT_OPACITY, 0.4f); 
glObjectParameters(GL_MODIFY, GL_OBJECT_NAME, "Some String"); 

कोई भी वास्तविक हैं ओपन: एक API कि अधिक इस तरह दिखता का उपयोग जीएल आदेश, ज़ाहिर है। यह केवल एक उदाहरण है कि इस तरह के ऑब्जेक्ट के लिए इंटरफ़ेस कैसा दिखता है।

ओपन सब ओपन वस्तुओं के लिए भंडारण का मालिक है। इस वजह से, उपयोगकर्ता केवल संदर्भ द्वारा किसी ऑब्जेक्ट तक पहुंच सकता है। लगभग सभी OpenGL ऑब्जेक्ट्स को एक हस्ताक्षरित पूर्णांक (GLuint) द्वारा संदर्भित किया जाता है। ऑब्जेक्ट्स फॉर्म glgen * के फ़ंक्शन द्वारा बनाए जाते हैं, जहां * ऑब्जेक्ट का प्रकार है। पहला पैरामीटर बनाने के लिए ऑब्जेक्ट्स की संख्या है, और दूसरा एक ग्लूंट * सरणी है जो नव निर्मित ऑब्जेक्ट नाम प्राप्त करता है।

सबसे वस्तुओं को संशोधित करने के वे पहले संदर्भ के लिए बाध्य किया जाना चाहिए। संदर्भ में विभिन्न वस्तुओं के लिए कई वस्तुओं को बाध्य किया जा सकता है; यह एक ही वस्तु को विभिन्न तरीकों से उपयोग करने की अनुमति देता है। इन विभिन्न स्थानों को लक्ष्य कहा जाता है; सभी वस्तुओं में वैध लक्ष्यों की एक सूची है, और कुछ में केवल एक ही है। उपर्युक्त उदाहरण में, काल्पनिक लक्ष्य "GL_MODIFY" वह स्थान है जहां ऑब्जेक्टनाम बाध्य है।

इस प्रकार ओपनजीएल ऑब्जेक्ट्स काम करते हैं, और बफर ऑब्जेक्ट्स "अधिकांश ओपनजीएल ऑब्जेक्ट्स" हैं।

और अगर है कि काफी अच्छा नहीं है, ट्यूटोरियल Chapter 1: Following the Data में फिर से शामिल किया गया है:

void InitializeVertexBuffer() 
{ 
    glGenBuffers(1, &positionBufferObject); 

    glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject); 
    glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW); 
    glBindBuffer(GL_ARRAY_BUFFER, 0); 
} 

पहली पंक्ति बफर वस्तु बनाता है, वैश्विक चर positionBufferObject में वस्तु को संभाल भंडारण। हालांकि ऑब्जेक्ट अब मौजूद है, फिर भी इसकी कोई स्मृति नहीं है। ऐसा इसलिए है क्योंकि हमने इस ऑब्जेक्ट के साथ किसी को आवंटित नहीं किया है।

glBindBuffer समारोह GL_ARRAY_BUFFER बाध्यकारी लक्ष्य के लिए नव निर्मित बफर वस्तु बांधता है। जैसा कि परिचय में बताया गया है, ओपनजीएल में वस्तुओं को आमतौर पर कुछ भी करने के लिए संदर्भ के लिए बाध्य होना पड़ता है, और बफर ऑब्जेक्ट्स कोई अपवाद नहीं है।

glBufferData समारोह दो आपरेशन प्रदर्शन करती है। यह वर्तमान में GL_ARRAY_BUFFER से बफर बफर के लिए स्मृति आवंटित करता है, जिसे हमने अभी बनाया और बाध्य किया है। हमारे पास पहले से ही कुछ कशेरुक डेटा है; समस्या यह है कि यह ओपनजीएल की स्मृति की बजाय हमारी स्मृति में है। आकार (vertexPositions) vertexPositions सरणी के बाइट आकार को निर्धारित करने के लिए C++ कंपाइलर का उपयोग करता है। इसके बाद हम इस बफर ऑब्जेक्ट को आवंटित करने के लिए स्मृति के आकार के रूप में glbufferData को इस आकार को पास करते हैं। इस प्रकार, हम अपने चरम डेटा को स्टोर करने के लिए पर्याप्त GPU स्मृति आवंटित करते हैं।

अन्य आपरेशन कि glBufferData करता बफर वस्तु में हमारी स्मृति सरणी से डेटा की प्रतिलिपि है। तीसरा पैरामीटर इसे नियंत्रित करता है। यदि यह मान शून्य नहीं है, इस मामले में, glBufferData पॉइंटर द्वारा संदर्भित डेटा को बफर ऑब्जेक्ट में कॉपी करेगा। इस फ़ंक्शन कॉल के बाद, बफर ऑब्जेक्ट स्टोर करता है जो वास्तव में vertexPositions स्टोर करता है।

चौथे पैरामीटर कुछ हम भविष्य ट्यूटोरियल में देखेंगे है।

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

Answer 4

ओपनजीएल तकनीक अविश्वसनीय रूप से अपारदर्शी और भ्रमित हो सकती है। मुझे पता है! मैं ओपनजीएल के आधार पर 3 डी इंजन लिख रहा हूं (ऑफ और ऑन)। समस्या के मेरे मामले में, मैं अंतर्निहित 3 डी एपीआई (ओपनजीएल) को छिपाने के लिए इंजन लिखता हूं, इसलिए एक बार जब मैं कुछ काम करता हूं तो मैं कभी भी ओपनजीएल कोड को कभी नहीं देखता।

लेकिन यहां एक तकनीक है जो मेरे दिमाग को "ओपनजीएल मार्ग" को समझने में मदद करती है। मुझे लगता है कि इसके बारे में सोचने का यह तरीका सच है (लेकिन पूरी कहानी नहीं)।

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

तो ओपनजीएल एपीआई क्या करता है "सक्रिय बनावट" की धारणा बनाने के लिए। फिर जब हम एक बनावट में एक चित्र को कॉपी करने के लिए एक ओपन एपीआई फ़ंक्शन को कॉल करें, हम इसे इस तरह से कार्य करना होगा:

1: generate a texture and assign its identifier to an unsigned integer variable. 
2: bind the texture to the GL_TEXTURE bind point (or some such bind point). 
3: specify the size and format of the texture bound to GL_TEXTURE target. 
4: copy some image we want on the texture to the GL_TEXTURE target. 

और यदि हम एक और बनावट पर एक छवि आकर्षित करने के लिए चाहते हैं, हम कि एक ही प्रक्रिया दोहरानी होगी।

जब हम डिस्प्ले पर कुछ प्रस्तुत करने के लिए आखिरकार तैयार होते हैं, तो हमें अपने एक और अधिक बनावट बनाने के लिए हमारे कोड की आवश्यकता होती है और हमारे टुकड़े शेडर द्वारा सुलभ होने के लिए छवियों की प्रतिलिपि बनाई जाती है।

जैसा कि यह पता चला है, टुकड़ा शेडर कई "बनावट इकाइयों" (एक बनावट प्रति बनावट बनावट) तक पहुंचकर एक समय में एक से अधिक बनावट तक पहुंच सकता है। इसलिए, हमारे कोड को उन बनावटों को बांधना चाहिए जिन्हें हम बनावट इकाइयों के लिए उपलब्ध करना चाहते हैं, हमारे टुकड़े के टुकड़े उन्हें उम्मीद करते हैं।

तो हम कुछ इस तरह करना चाहिए: अब

glActiveTexture (GL_TEXTURE0); 
glBindTexture (GL_TEXTURE_2D, mytexture0); 

glActiveTexture (GL_TEXTURE1); 
glBindTexture (GL_TEXTURE_2D, mytexture1); 

glActiveTexture (GL_TEXTURE2); 
glBindTexture (GL_TEXTURE_2D, mytexture2); 

glActiveTexture (GL_TEXTURE3); 
glBindTexture (GL_TEXTURE_2D, mytexture3); 

---

, मुझे कहना पड़ेगा कि मैं कई कारणों से ओपन प्यार करता हूँ, लेकिन इस दृष्टिकोण मुझे पागल ड्राइव। ऐसा इसलिए है क्योंकि मैंने पिछले कुछ वर्षों से लिखे गए सभी सॉफ्टवेयर इस तरह दिखेगा:

error = glSetTexture (GL_TEXTURE0, GL_TEXTURE_2D, mytexture0); 
error = glSetTexture (GL_TEXTURE1, GL_TEXTURE_2D, mytexture1); 
error = glSetTexture (GL_TEXTURE2, GL_TEXTURE_2D, mytexture2); 
error = glSetTexture (GL_TEXTURE3, GL_TEXTURE_2D, mytexture3); 

बामो। इस राज्य को बार-बार स्थापित करने की आवश्यकता नहीं है। बस बनावट को जोड़ने के लिए बनावट को जोड़ने के लिए बनावट बनाते हैं, साथ ही बनावट-प्रकार को बनाते हैं, साथ ही बनावट की आईडी, और बनावट की आईडी जिसे मैं बनावट इकाई से जोड़ना चाहता हूं।

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

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

---

कम से कम मैं अपने सिर में "ओपनजीएल रास्ता" कैसे रखता हूं। वाकई, अगर कोई वास्तव में, वास्तव में, वास्तव में सभी कारणों को समझता है ओपनजीएल (और होना चाहिए) जिस तरह से संरचित है, मैं उन्हें अपना जवाब पोस्ट करना पसंद करूंगा। मेरा मानना ​​है कि यह एक महत्वपूर्ण सवाल और विषय है, और तर्क शायद ही कभी वर्णित है, जैसा कि कभी भी वर्णित है, इस तरह से बहुत कम है कि मेरा दंड मस्तिष्क समझ सकता है।

Answer 5

ओपनजीएल जिसे "राज्य मशीन" के रूप में जाना जाता है, उस अंत में ओपनजीएल में कई "बाध्यकारी लक्ष्य" होते हैं जिनमें से प्रत्येक में केवल एक चीज बंधी जा सकती है। कुछ और बाध्यकारी वर्तमान बांध को बदल देता है, और इस प्रकार इसकी स्थिति बदलता है। इस प्रकार बाध्यकारी बफर द्वारा आप मशीन की स्थिति को परिभाषित कर रहे हैं।

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