क्या OpenGL समन्वय प्रणाली बाएं हाथ या दाहिने हाथ की है?

Question

मैं OpenGL समन्वय प्रणाली को समझने की कोशिश कर रहा हूं। हालाँकि, कुछ ट्यूटोरियल कहते हैं कि डिफॉल्ट कोऑर्डिनेट सिस्टम को छोड़ दिया गया है (देखें http://www.c-sharpcorner.com/UploadFile/jeradus/OpenGLBasics11172005014307AM/OpenGLBasics.aspx ) और अन्य कहते हैं कि यह दाहिने हाथ में है (देखें http: // www .falloutsoftware.com / tutorials / gl / gl0.htm )। क्या सही है? मैं समझता हूं कि हम एक दूसरे को दर्पण में बदल सकते हैं लेकिन मैं डिफ़ॉल्ट निर्देशांक जानना चाहूंगा।

Comments

संबंधित प्रोग्रामर

— कोस

क्या यह पूरी तरह से इस बात पर निर्भर नहीं करता है कि आप अपने परिवर्तनों को शेड्स में कैसे लिखते हैं और इसलिए पूरी तरह से आप पर निर्भर है?

— jcoder

बस मेरे दो सेंट evl.uic.edu/ralph/508S98/coordinates.html , इसमें कुछ स्व व्याख्यात्मक चित्र हैं।

— rrallvv

मुझे नहीं लगता कि आप अपने स्वीकृत उत्तर को अपडेट करने पर विचार करेंगे?

— जोनाथन मी

Answer 1

यहां कुछ भ्रम है।

OpenGL को ऑब्जेक्ट स्पेस और वर्ल्ड स्पेस में राइट हैंड किया गया है।

लेकिन विंडो स्पेस (उर्फ स्क्रीन स्पेस) में हम अचानक बायें हाथ में आ जाते हैं ।

यह कैसे हुआ ?

जिस तरह से हम दाएं हाथ से बाएं हाथ के लिए प्राप्त करते हैं वह एक नकारात्मक z स्केलिंग प्रविष्टि glOrthoया glFrustumप्रोजेक्शन मैट्रिसेस है। -1 से z स्केलिंग (जबकि वे थे के रूप में एक्स और वाई छोड़ने) समन्वय प्रणाली की गंभीरता को बदलने का प्रभाव है।

GlFrustum के लिए,

दूर और पास सकारात्मक माना जाता है, दूर के साथ > निकट । दूर = १००० और पास = १ कहो । फिर सी = - (1001) / (999) = -1.002।

अधिक विवरण और आरेख के लिए यहां देखें ।

एक से ओर्थोग्रफिक परिप्रेक्ष्य , glOrtho इस तरह एक मैट्रिक्स उत्पन्न करता है:

यहां, बाएं , दाएं , नीचे और ऊपर बाएं ऊर्ध्वाधर , दाएं ऊर्ध्वाधर , नीचे क्षैतिज , शीर्ष क्षैतिज कतरन विमानों (सम्मान) के लिए सिर्फ निर्देशांक हैं ।

पास और दूर विमानों, हालांकि, अलग ढंग से निर्दिष्ट कर रहे हैं । पास पैरामीटर के रूप में परिभाषित किया गया है

• नियर: समीप की दूरी समीप की कतरन समतल। यह दूरी नकारात्मक है यदि विमान दर्शक के पीछे होना है।

और आगे:

• zFar द दूर की गहराई वाले क्लिपिंग प्लेन दूरी । यह दूरी नकारात्मक है यदि विमान को दर्शक के पीछे होना है।

यहां हमारे पास एक विशिष्ट कैनोनिकल व्यू वॉल्यूम है

क्योंकि z गुणक (-2 / (दूर-पास)) है, शून्य से प्रभावी रूप से z को -1 से चिन्हित करता है । इसका अर्थ है कि "z" को देखने के परिवर्तन के दौरान बाएं हाथ से बंद कर दिया गया है , अधिकांश लोगों के लिए अनभिज्ञ है क्योंकि वे ओपनजीएल में "दाएं हाथ" समन्वय प्रणाली के रूप में काम करते हैं।

इसलिए, यदि आप फोन करते हैं

glOrthof(-1, 1, -1, 1, 10, -10) ; // near=10, FAR=-10,

तो NEAR PLANE आपसे 10 यूनिट आगे है । आप कहाँ हैं? क्यों, मूल में, आपके दाईं ओर x- अक्ष के साथ, आपके सिर के ऊपर y- अक्ष, और आपकी नाक नकारात्मक z- अक्ष को इंगित करती है (जो कि डिफ़ॉल्ट है "डिफ़ॉल्ट रूप से, कैमरा मूल पर स्थित है। , नकारात्मक z- अक्ष को इंगित करता है, और इसमें (0, 1, 0) का अप-वेक्टर होता है। " )। तो निकट विमान z = -10 पर है। सुदूर विमान आपके पीछे 10 इकाइयाँ है, z = + 10 पर ।

Comments

"ग्लूकोकैट में आगे की ओर वेक्टर को नकारा जाता है" - क्या आप पुष्टि कर सकते हैं कि यह मामला है? GluPerspective या GlFrustum या GlOrtho नहीं?

— कोस

हम अचानक क्लिप स्पेस से बाएं हाथ के हो गए हैं, न कि केवल विंडो स्पेस।

— लीजेंड 2k

पूरे उत्तर के लिए +1, -1 (प्रतीक्षा करें, बल्कि -2) "जिस तरह से हम दाएं-हाथ से बाएं हाथ से प्राप्त करते हैं, वह इसलिए है क्योंकि ग्लूकोल्ट () के मानक कार्यान्वयन में फॉरवर्ड वेक्टर को नकार दिया जाता है, जो फ़ंक्शन है हर कोई व्यू मैट्रिक्स बनाने के लिए उपयोग करता है। जब आप फॉरवर्ड वेक्टर को नकारते हैं, तो यह समन्वय प्रणाली की दृढ़ता को बदलने का प्रभाव होता है। " , जो महज बकवास है ...

— ईसाई राऊ

... संगणना में आगे के सदिश की उपेक्षा gluLookAtकरने का समन्वय स्थान की दृढ़ता को बदलने से कोई लेना-देना नहीं है, बस इस मैट्रिक्स की गणना कैसे की जाती है (और वास्तव में + z दाहिने हाथ की जगह में वास्तव में "पिछड़ा" है)। gluLookAtएक साधारण कठोर शरीर परिवर्तन (रोटेशन + अनुवाद) की गणना दाहिने हाथ की जगह में करने के अलावा और कुछ नहीं करता है। यह निर्धारित कार्य पाइपलाइन (और आमतौर पर शेड्स, भी) द्वारा उपयोग किए जाने वाले प्रोजेक्शन मैट्रिस हैं जो जेड-घटक की उनकी उपेक्षा में वास्तविक सौम्यता परिवर्तन करते हैं, जैसा कि आपने पहले ही अपने उत्तर में नोट किया था।

— ईसाई राऊ

@bobobobo आपका कहना है कि यदि आप केवल रोटेशन और अनुवाद कार्यों का उपयोग करके अपने दृश्य मैट्रिक्स की गणना करते हैं (जो मुझे लगता है कि आप बदले हुए काम का आरोप नहीं लगाएंगे), इसके बजाय gluLookAt, एक के आधार पर परिवर्तन नहीं होगा gluLookAt? निश्चित रूप से नहीं (क्योंकि आप शायद जानते हैं कि "हर कोई"gluLookAt मैट्रिक्स अभिकलन के लिए उपयोग नहीं करता है ), क्योंकि आपको पता होना चाहिए कि gluLookAtरोटेशन और अनुवाद कॉल का एक गुच्छा के अलावा और कुछ नहीं है (जैसा कि वे "उच्च स्तर" शब्द "के रूप में भी प्रच्छन्न हैं) आधार " ) जिसमें कोई प्रतिबिंब शामिल नहीं है।

— ईसाई राऊ

Answer 2

डिफ़ॉल्ट रूप से सामान्यीकृत डिवाइस समन्वय बाएं हाथ से होता है।

GlDepthRange डिफ़ॉल्ट रूप से [0, 1] (निकट, दूर) स्क्रीन में + z अक्ष बिंदु को दाईं ओर + x और दाईं ओर + y कर रही है, यह बाएं हाथ की प्रणाली है।

डेप्थ रेंज को [1, 0] में बदलने से सिस्टम राइट-हैंड हो जाएगा।

निकोल के पिछले जवाब का हवाला देते हुए : (स्ट्राइक थ्रू माय काम है, नीचे समझाया गया है)

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

एक बार जब आप फिक्स्ड-फंक्शन पाइपलाइन को फेंक देते हैं, तो आप सीधे "क्लिप-स्पेस" से निपटते हैं। OpenGL विशिष्टता एक 4D सजातीय समन्वय प्रणाली के रूप में क्लिप-स्पेस को परिभाषित करती है। जब आप सामान्यीकृत डिवाइस निर्देशांक के माध्यम से परिवर्तनों का पालन करते हैं, और विंडो स्थान के नीचे, आप यह पाते हैं।

विंडो स्पेस विंडो के पिक्सल के स्पेस में होता है। मूल निचले बाएँ कोने में है, जिसमें + Y ऊपर और X सही चल रहा है। यह एक बहुत ही सही-सही समन्वय प्रणाली की तरह लगता है। लेकिन Z का क्या?

डिफ़ॉल्ट गहराई श्रेणी (glDepthRange) पास Z मान को 0 और दूर Z मान को एक पर सेट करता है । तो + Z दर्शक से दूर जा रहा है ।

यह एक बाएं हाथ की समन्वय प्रणाली है। हाँ तुम कर सकते होGL_LESS से GL_GREATER तक और गहराई परीक्षण बदलें[0, 1] से [1, 0] तक glDepthRange बदलें। लेकिन ओपनजीएल की डिफ़ॉल्ट स्थिति बाएं हाथ के समन्वय प्रणाली में काम करना है। और क्लिप-स्पेस से विंडो स्पेस को प्राप्त करने के लिए आवश्यक परिवर्तनों में से कोई भी Z. तो क्लिप-स्पेस को नकारात्मक नहीं करता है, वर्टेक्स (या जियोमेट्री) shader का आउटपुट एक बाएं हाथ वाला स्थान (थोथा है। यह एक 4D समरूपता स्थान है, इसलिए। सादगी को पिन करना मुश्किल है)।

फिक्स्ड-फंक्शन पाइपलाइन में, मानक प्रोजेक्शन मैट्रिसेस (ग्लोरोथो, ग्लफ्रीस्टम और इस तरह से निर्मित) सभी एक दाएं हाथ के स्थान से बाएं हाथ के लिए बदल जाते हैं । वे Z का अर्थ फ्लिप करते हैं; बस वे उत्पन्न होने वाले मेट्रिसेस की जाँच करें। नेत्र स्थान में, + Z दर्शक की ओर बढ़ता है; प्रक्षेपण के बाद के स्थान में, यह दूर चला जाता है।

मुझे संदेह है कि Microsoft (और GLide) ने अपने प्रोजेक्शन मैट्रिसेस में नकार प्रदर्शन करने की जहमत नहीं उठाई।

मैंने अपने निष्कर्षों से विचलित होने के बाद एक भाग पर प्रहार किया।

या तो DepRRange या DepthFunc को बदलना और ClearDepth (0) का उपयोग करना काम करता है, लेकिन दोनों का उपयोग करते समय वे एक दूसरे को वापस बाएं हाथ के सिस्टम में रद्द कर देते हैं।

Comments

गहराई सीमा [1, -1] नहीं हो सकती। मुझे लगता है कि आपका मतलब था [1, 0]। इसके अलावा, यह पहले बताया गया है ।

— निकोल बोल्स

आपका उत्तर बहुत अच्छा है, बहुत बुरा है यह एक डायरेक्टएक्स प्रश्न के लिए है, आपको इसे यहां पर फिर से लिखना चाहिए!

— hultqvist

@SigTerm क्यों आपको लगता है कि एक गलत बयान को सही करना इसके लायक नहीं है? मैंने यह जानने में कई घंटे बिताए हैं कि वर्टेक्स कोऑर्डिनेट और मैट्रिक्स रोटेशन जनरेशन केवल यह पता लगाने के लिए है कि वास्तव में डिफॉल्ट कोऑर्डिनेट सिस्टम राइट-हैंडेड नहीं था।

— हॉल्टकविस्ट

सवाल यह था कि क्या यह बायाँ-या दाएं हाथ वाला सिस्टम था। इस उत्तर में उससे अधिक विवरण हैं, दो अन्य तरीकों से समझाते हुए इसे दाहिने हाथ में लेना, मैट्रिक्स परिवर्तन में -1 जोड़ना अभी तक इसे करने का एक और तरीका है। लेकिन इस बात से कोई भी फर्क नहीं पड़ता कि आप मानते हैं कि सिस्टम डिफ़ॉल्ट रूप से राइट-हैंडेड है, आप केवल तभी कुछ बदल सकते हैं यदि आप जानते हैं कि आप क्या बदल रहे हैं। फिर भी

— hultqvist

मुझे जवाब बहुत ज्ञानवर्धक लगा, और यह खोजों में आया, इसलिए यह मेरे लिए इसके लायक था।

— ओपनजीएल ईएस

Answer 3

केवल एन.डी.सी.

आपको केवल यह ध्यान देना चाहिए कि OpenGL केवल NDC को जानता है! और यह एक बाएं हाथ की समन्वय प्रणाली है।

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

हम आम तौर पर विश्व-अंतरिक्ष में दाएँ हाथ के समन्वय प्रणाली का उपयोग क्यों करते हैं?

मुझे लगता है कि यह पारंपरिक है। यह बस करता है। शायद यह सिर्फ DirectX से अलग करना चाहता है।

Comments

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

— टॉम

यद्यपि यह शब्द "सामान्यीकृत डिवाइस निर्देशांक" को शामिल करने के लिए इसे दोहराता है, तो यह अच्छा हो सकता है।

— टॉमी

OpenGL कुछ वर्षों के बाद DirectX से पहले की है, इसलिए OpenGL निश्चित रूप से DirectX से खुद को अलग करने की कोशिश नहीं कर रहा था। डायरेक्टएक्स के प्रमुख डेवलपर, एलेक्स सेंट जॉन ने कहा है कि बाएं हाथ के समन्वय प्रणाली के लिए जाने का माइक्रोसॉफ्ट का निर्णय "व्यक्तिगत पसंद से बाहर का हिस्सा" और "एक मनमाना विकल्प" था।

— क्रिस नोलेट

यह पूरी तरह सही नहीं है। OpenGL भी क्लिपिंग समन्वय प्रणाली को जानता है, क्योंकि क्लिपिंग उसी में होती है। क्लिप कोऑर्डिनेट सिस्टम में NDC कोऑर्डिनेट सिस्टम tho जैसी ही क्षमता है।

— प्लाज़्मासेल

Answer 4

कौची मात्सुडा की पुस्तक "वेबगैल प्रोग्रामिंग गाइड" लगभग दस पेज "वेबग्ल / ओपनग्ल: लेफ्ट या राइट हैंडेड" पर खर्च करती है?

पुस्तक के अनुसार:

• व्यवहार में, अधिकांश लोग दाएं हाथ की प्रणाली का उपयोग करते हैं

• OpenGl वास्तव में आंतरिक रूप से एक बाएं हाथ की प्रणाली है

• आंतरिक रूप से, अधिक गहराई से यह वास्तव में न तो है। बहुत नीचे OpenGl में z- मूल्य की परवाह नहीं है। जिस क्रम में आप चीजों को खींचते हैं वह निर्धारित करता है कि शीर्ष पर क्या खींचा गया है (पहले एक त्रिभुज खींचें, फिर एक क्वाड, क्वाड त्रिभुज को ओवरराइड करता है)।

मैं "इट्स न तो" से पूरी तरह सहमत नहीं है, लेकिन यह शायद वैसे भी एक दार्शनिक सवाल है।

Comments

The order in which you draw things determines what is drawn on top (draw a triangle first, then a quad, the quad overrides the triangle). यह सच है, गहराई से परीक्षण के अभाव में। गहराई परीक्षण की उपस्थिति में, एक अंश का z मान गहराई बफर में मान के साथ तुलना की जाती है, और गहराई परीक्षण में विफल होने पर खंड को छोड़ दिया जाता है, इसलिए क्वाड उनकी गहराई के आधार पर त्रिकोण को अधिलेखित कर सकता है या नहीं कर सकता है। गहराई समारोह का इस्तेमाल किया।

— क्रिस्वार्ज़

Answer 5

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

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

Answer 6

OpenGL के अंतर्निहित प्रक्षेपण और परिवर्तन कार्यों का उपयोग करके, स्क्रीन पर आंदोलनों का अवलोकन करते हुए दाएं हाथ के समन्वय प्रणाली के नियमों का पालन करें । उदाहरण के लिए, यदि आपके विचार के सामने की कोई वस्तु सकारात्मक z दिशा में अनुवादित है, तो वह वस्तु आपकी ओर बढ़ेगी।

गहराई बफर काफी विपरीत है, और यह वह जगह है जहां एनडीसी (सामान्यीकृत डिवाइस निर्देशांक) खेलने में आते हैं। यदि GlDepthFunc में GL_LESS को पास करने का अर्थ है कि जब वे पहले से ही गहराई बफर में हैं, तो पिक्सेल आपके पास आ जाएंगे, तो पिक्सल को बाएं हाथ के समन्वय प्रणाली में रहना माना जाता है।

एक और समन्वय प्रणाली है, और वह व्यूपोर्ट है! व्यूपोर्ट का समन्वय प्रणाली ऐसा है कि + x दाईं ओर इंगित करता है, और + y नीचे इंगित करता है। मुझे लगता है कि इस बिंदु से चिंता मूक है क्योंकि हम केवल इस बिंदु पर x, y के साथ काम कर रहे हैं।

अंत में, हुड के नीचे gluLookAt को लुक-ऑन वेक्टर को नकारना होगा। चूंकि गणित मानता है कि एक वेक्टर एक सकारात्मक दिशा की ओर इशारा कर रहा है, जिस वस्तु को वह देख रहा है, और एक कैमरा नीचे -z दिखता है, लुक-ऑन वेक्टर को नकारात्मक होना चाहिए ताकि वह कैमरे के साथ संरेखित हो।

कुछ चबाने के लिए। यह सही अर्थों में समन्वय प्रणाली की z दिशा को आगे वेक्टर बनाने के लिए बहुत मायने नहीं रखता है :)। मुझे लगता है कि Microsoft को इसका एहसास तब हुआ जब उन्होंने Direct3D को डिज़ाइन किया।