Three.js: GLTFLoader: सामान्य-स्पर्शरेखा परीक्षण मॉडल परिणाम गलत है

यह @ cx20 लिखने के लिए धन्यवाद।

बस अधिक संदर्भ के लिए, यहाँ कुछ संबंधित जानकारी और मुद्दे हैं:

• मैंने @donmccurdy के थ्रीजेएस ग्लटफ दर्शक, डोनमकुर्डी / थ्री-ग्ल्टफ-दर्शक # 10 पर इसी तरह की समस्या की सूचना दी। लेकिन मुझे अब लगता है कि यह थ्री जेएस के ग्लैटीएफ लोडर में एक बग है, दर्शक में नहीं। इसलिए, यह नया मुद्दा मेरे पुराने मुद्दे की तुलना में बेहतर है।

• उपरोक्त पुराने मुद्दे में, मॉडल आकाश का सामना करता था, लेकिन बाद में मैंने इसे क्षितिज का सामना करने के लिए घुमाया। इससे यह देखना आसान हो जाता है कि जब प्रतिबिंब सही नहीं होते हैं, क्योंकि क्षितिज क्रेज़ीली घूमता है, जैसा कि ऊपर दिखाया गया है।

• ख्रोनोसग्रुप / glTF # 952 में चर्चा करके मॉडल के सामान्य मानचित्र के अपने उपयोग की पुष्टि सही थी।

• # 11315 में थ्री जेएस के सामान्य मानचित्रों की हैंडलिंग पर सवाल उठाया गया था।

• बाबुलजेएसएस को हाल ही में इसी तरह की समस्या थी, यहां रिपोर्ट की गई और बाबुलजेएसएस के glTF 2.0 लोडर के एक

अच्छा राइटअप, धन्यवाद!

मॉडल इस पंक्ति को जोड़ने के साथ सही ढंग से प्रस्तुत करता है:

materialParams.normalScale = new THREE.Vector2(-1, 1);

लेकिन मुझे यकीन नहीं है कि मैं इस मुद्दे को अच्छी तरह समझता हूं। # 11315 को समझने से यहां मदद मिल सकती है।

@donmccurdy आपकी सलाह के लिए धन्यवाद।
मैं समझ गया कि normalScale को समायोजित करने से सुधार होगा।
हालांकि, अगर glTF मॉडल सही है, तो मुझे लगता है कि glTF लोडर के लिए इसे संभालना बेहतर है।

@ cx20 ने सहमति व्यक्त की, यह तय अब THREE.GLTF2Loader में विलय हो गया है।

मैंने पुष्टि की है कि इसे ठीक किया जा रहा है।

तीन.js + सामान्य-स्पर्शरेखा परीक्षण मॉडल परिणाम:

इसने पुन: प्राप्त किया है, कुछ समय के बीच r101 और r104:

Https://github.com/mrdoob/three.js/pull/15749 देखें - प्रतिगमन जानबूझकर है, और मॉडल में स्पर्शरेखाओं को शामिल करके इससे बचा जा सकता है।

आदर्श रूप से हमारे पास इसे पूरी तरह से हल करने के लिए मिक्कटस्पेस स्पर्शरेखा बनाने के लिए जेएस कार्यान्वयन होगा, लेकिन यह काफी जटिल है।

मुझे अब तक # 15749 की जानकारी नहीं थी। मैं इस पर पहरा लगा रहा हूं, मैंने सोचा था कि हमने glTF में स्पर्शरेखाओं को परिभाषित करने के लिए एक अच्छा काम किया है कि वे कम से कम रनटाइम पर अनुमानित हो सकें।

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

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

फिर से खोलना 😅

मुझे संदेह है कि इस बदलाव ने थ्रीजेएस में बहुसंख्यक glTF मॉडल के लिए सामान्य मैपिंग को तोड़ा है।

मुझे विश्वास नहीं है कि यह कुछ भी गंभीर है - हमने हमेशा डेरिवेटिव के साथ shader में tangents realtime उत्पन्न किया है, और हम अभी भी करते हैं। हमने पहले एक हैक ( normalScale.y *= -1 ) शामिल किया था जो इस विशिष्ट परीक्षण मॉडल को ठीक करने के लिए हुआ, लेकिन कुछ अन्य उदाहरणों को तोड़ने के लिए भी हुआ। मेरे पास इस बात की कोई व्याख्या नहीं है कि मदद कब की गई, या नहीं की गई, इसलिए हमने संग्रहीत स्पर्शकों का समर्थन करने के बाद हैक को हटा दिया - जिस स्थिति में यह निश्चित रूप से गलत होगा। अब जो मॉडल हैक पर निर्भर थे (और स्पर्शरेखा शामिल नहीं हैं) टूट गए हैं, और मॉडल जो हैक से टूट गए थे (और स्पर्शरेखा शामिल नहीं हैं) तय हो गए हैं।

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

ऊपर देखो। सामान्य तौर पर, मेरा मानना ​​है कि हम पर्याप्त रूप से स्पर्शरेखा के बिना मॉडल प्रस्तुत करते हैं। हालांकि, हम glTF कल्पना द्वारा आवश्यक रूप से मिक्कटस्पेस स्पर्शरेखा उत्पन्न नहीं करते हैं। मेरी जानकारी के अनुसार, इसका कोई JS कार्यान्वयन मौजूद नहीं है, और हमारा व्युत्पन्न-आधारित shader कार्यान्वयन केवल "ज्यादातर अच्छा पर्याप्त" सन्निकटन है। यह नमूना मॉडल एक जानबूझकर चरम मामला है जो उस सन्निकटन की सीमाओं को प्रदर्शित करता है।

हमें एक जेएस मिकट्सस्पेस स्पर्शरेखा पीढ़ी के कार्यान्वयन के लिए खुशी होगी; यह THREE.BufferGeometryUtils के लिए अच्छा होगा। लेकिन आधिकारिक (देशी) mikktspace कोड काफी लंबा है, और मैंने यह देखने के लिए अभी तक पर्याप्त रूप से खोदा नहीं है कि स्पर्शरेखा बनाने के लिए कितना आवश्यक है।

हमने पहले एक हैक ( normalScale.y *= -1 ) शामिल किया था जो इस विशिष्ट परीक्षण मॉडल को ठीक करने के लिए हुआ, लेकिन कुछ अन्य उदाहरणों को तोड़ने के लिए भी हुआ

क्या यह विशेष रूप से अन्य glTF मॉडल को तोड़ता है, या केवल सामान्य रूप में उदाहरण?

जंगली में दो अलग-अलग प्रकार के स्पर्शरेखा-स्थान सामान्य नक्शे हैं। पदार्थ पेंटर इन "डायरेक्टएक्स नॉर्मल्स" और "ओपनजीएल नॉर्मल" कहते हैं, जो इसके लिए सबसे बड़ा नाम नहीं है। अंतर विशेष रूप से y चैनल का उलटा है, जिसका अर्थ है कि बनावट में हरे चैनल मान उलटे हैं। y *= -1 को एक से दूसरे में कनवर्ट करने का सही तरीका है। तथाकथित "डायरेक्टएक्स नॉर्मल्स" एक बाएं हाथ के समन्वय प्रणाली का उपयोग करता है, और glTF सामान्य / स्पर्श / कड़वाहट के लिए दाएं हाथ के समन्वय प्रणाली को परिभाषित करता है।

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

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

(पिछले साल खरोनाग्रुप / glTF- नमूना-मॉडल # 174 में इस पर कुछ चर्चा भी हुई)

मैं विशेष रूप से सामान्य नक्शे पर glTF कल्पना से एक वाक्य को बाहर करना चाहता हूं:

सामान्य वैक्टर OpenGL सम्मेलनों का उपयोग करते हैं जहां + X सही है और + Y ऊपर है। + Z दर्शक की ओर इशारा करता है।

यह वाक्य वह है जो मॉडल को स्पर्शरेखा वाले वैक्टर के बिना भेजने की अनुमति देता है, जिससे अंतरिक्ष की बचत होती है।

आइए इसका परीक्षण करते हैं। यहाँ मैंने एक पेंट प्रोग्राम में एक चंचल ऊंचाई का नक्शा (टक्कर का नक्शा) बनाया है।

आइए इस ऊंचाई के क्षेत्र को एक बाहरी उछाल के रूप में परिभाषित करें, जहां सफेद पिक्सेल दर्शक के करीब हैं, और काले पिक्सेल आगे दूर हैं।

एक ऑनलाइन कनवर्टर का उपयोग करना (संदिग्ध गुणवत्ता का, लेकिन हम एक पल में परिणाम की जांच करेंगे), मैंने इसे ऊंचाई के नक्शे से एक सामान्य नक्शे में बदल दिया है। ध्यान रखें कि यहां कोई 3D मॉडल नहीं है, कोई UV निर्देशांक या मिककस्पेस गणना या कोई ज्यामिति नहीं है। बस एक ऊंचाई का नक्शा एक सामान्य नक्शे में बदल गया। मुझे glTF के निर्देशों के अनुसार ऑनलाइन कन्वर्टर को मैन्युअल रूप से कॉन्फ़िगर करना था, जैसे कि X सही है, Y ऊपर है, और Z दर्शक का सामना कर रहा है। यह परिणाम है:

चलो एक पेंट प्रोग्राम में वापस लाएं और रंग चैनलों को देखें कि ये वैक्टर कहां हैं। नीचे, प्रत्येक रंग चैनल को अपनी स्वयं की एक ग्रेस्केल छवि में अलग किया गया है। याद रखें कि इनकी व्याख्या इस तरह की जाएगी कि काले का अर्थ -1.0 , मध्य ग्रे का अर्थ 0.0 , और सफ़ेद का अर्थ +1.0 ।

तो मुझे लगता है कि ऑनलाइन कन्वर्टर ने वही किया जो glTF ने पूछा, कम से कम इसे सही तरीके से कॉन्फ़िगर करने के बाद। लाल (X) छवि में, हम दाईं ओर ढलान देख सकते हैं जिसमें सफेद पिक्सेल (+1.0) है, छवि के दाहिने किनारे पर X वेक्टर को इंगित करता है। लाल छवि के बाईं ओर, काले पिक्सेल (-1.0) छवि के बाईं ओर X वेक्टर को इंगित करते हैं। ग्रीन (वाई) छवि में, बंप के शीर्ष ढलान के साथ सफेद पिक्सेल छवि के शीर्ष पर वाई वेक्टर को इंगित करते हैं। Z मान कम से कम सहज हैं, लेकिन याद रखें कि टक्कर की नोक और पिछली प्लेट दोनों ही दर्शक को इंगित करते हैं, और सभी तरफ ढलान इंगित करते हैं, इसलिए सभी समान रूप से गहरे हैं।

क्या होगा अगर हम इसे ब्लेंडर ईवे में लोड करते हैं, जो (सिर्फ glTF की तरह) ओपनजीएल-शैली के सामान्य मानचित्रों को स्वीकार करता है? यदि यूवी मानचित्र को घुमाया जाता है, या उलटा होने पर भी स्केल किया जाता है तो क्या होता है?

पता चला, यह ठीक काम करता है। दरअसल, इस तरह से स्पर्शरेखा स्थान को परिभाषित करने का पूरा बिंदु सॉफ्टवेयर को वैक्टरों के साथ पागल होने में सक्षम नहीं करना है, यह बनावट कलाकारों को यह सुनिश्चित करने के लिए कुछ पवित्रता प्रदान करने की अनुमति देता है कि उनके सामान्य नक्शे ज्यामिति की परवाह किए बिना राइट-अप होंगे।

लेकिन, सभी सॉफ्टवेयर OpenGL कन्वेंशन का उपयोग नहीं करते हैं। कुछ एक अलग सम्मेलन (जिसे कभी-कभी डायरेक्टएक्स कन्वेंशन कहा जाता है) का उपयोग करते हैं, जहां वाई वैक्टर शीर्ष के बजाय छवि के नीचे स्थित होता है। यहाँ इस रूप में मेरी छवि का विघटित Y चैनल है। लाइटर पिक्सेल छवि के निचले भाग का सामना करने वाले होते हैं।

अगर मैं इन डायरेक्टएक्स-शैली के सामान्य मानचित्रों में से एक को ब्लेंडर ईवे में लोड करता हूं, तो क्या मैं अभी भी काम करने की उम्मीद कर सकता हूं?

नंबर ब्लेंडर + वाई अप की उम्मीद कर रहा था। गणित गलत है, और प्रतिबिंबित क्षितिज रेखा चारों ओर घूमती है।
यदि आप एक OpenGL- शैली के सामान्य नक्शे को उस इंजन में लोड करते हैं, जो कि + Y डाउन की अपेक्षा कर रहा था, तो वही होता है।

यह वही है जो NormalTangentTest मॉडल परीक्षण करने का प्रयास कर रहा है। प्रत्येक पंक्ति यूवी भिन्न निर्देशांक में घूमती है, यह सुनिश्चित करने की कोशिश करती है कि प्रतिबिंब इन अलग-अलग झुकावों में दाईं ओर बने रहें।

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

इस समय मैं इस विशेष नमूने के साथ मेल खाने के लिए मिकत्सेस्पेस से टैंगेंटव्ल फ़्लिप कर रहा हूँ, लेकिन यह वही था जो काम करने के लिए हुआ था।

क्या यह विशेष रूप से अन्य glTF मॉडल को तोड़ता है, या केवल सामान्य रूप में उदाहरण?

रिपोर्ट किए गए बग विशेष रूप से glTF मॉडल से संबंधित थे। उस ने कहा, मुझे संदेह है कि FBX या COLLADA के माध्यम से भौतिक निर्यात में पर्याप्त विश्वास है, यह कहने के लिए कि उन सामान्य मानचित्र सम्मेलनों को कभी भी अच्छी तरह से समझा और परीक्षण किया गया था।

अंतर विशेष रूप से y चैनल उलटा है, जिसका अर्थ है कि बनावट में हरे चैनल मान उल्टे हैं। Y * = -1 को गुणा करना एक को दूसरे में बदलने का सही तरीका है।

धन्यवाद, जब हमने इसे लागू किया था, तो यह हमारे "हैक" का अधिक बेहतर औचित्य है। 😇

यह दुर्भाग्यपूर्ण है कि कल्पना मिक्टस्पेस और अधिकांश कार्यान्वयनों के लिए कॉल करती है जो स्क्रीन-स्पेस डेरिवेटिव के साथ अनुमानित हैं।

यह कल्पना सही है कि टंकियों को उत्पन्न करने के लिए मिककस्पेस सबसे मजबूत तरीका है, मुझे लगता है, यह सार्वभौमिक रूप से रनटाइम पर स्वचालित रूप से ऐसा करने का सही विकल्प नहीं है। यदि सस्ता विकल्प किसी विशेष मॉडल के लिए सही दिखता है, तो कुछ और अधिक महंगा करने का कोई कारण नहीं है जो किसी भी बेहतर नहीं दिखता है। अनुमान के लिए कल्पना की भाषा को ढीला किया जा सकता है लेकिन मैं इस बारे में दृढ़ता से महसूस नहीं करता।

अभी भी विनिर्देशन में एक ठोस सूत्र होने की आवश्यकता है कि एक अकेला आदिम के लिए एक स्पर्शरेखा की गणना कैसे की जाए, एक आदिम और उसके यूवी निर्देशांक दिए गए हैं, और जो कि विचित्र के लिए उपयोग करने के लिए हस्ताक्षर करते हैं।

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

मूल मुद्दे के लिए, ऐसा लगता है कि हमें कहीं न कहीं normal.y *= -1 गुणक को पुनर्स्थापित करना चाहिए। ऐसा करने के लिए तीन संभावित स्थान हैं:

• (ए) GLTFLoader में, उन मेषों के लिए जिनके पास स्पर्शरेखा नहीं है
• (बी) GLTFLoader में, सभी मेश के लिए
• (c) सभी जालों के लिए, WebGLRenderer में

यदि तीनj वास्तव में DirectX सम्मेलन का उपयोग कर रहे हैं और उदाहरण के लिए ब्लेंडर नहीं है, तो मैं (c) के लिए मामला देख सकता था। एक त्वरित और सुरक्षित समाधान के हित में, हालांकि, मैं (ए) के साथ जाने के लिए इच्छुक हूं।

मुझे जो संदेह हो रहा है वह यह है कि जब थ्रीजेएस ऑटो-टेंपलेट की गणना करता है, तो यह उम्मीद करता है कि सामान्य मानचित्र को फ़्लिप्ड वाई (डायरेक्टएक्स) शैली के साथ लेखक किया गया है।

नहीं, तीन। Js यह नहीं मानते हैं कि ...

तीन .js मान लेता है + Y स्पर्शरेखा स्थान के लिए "अप" है, और बढ़ती-वी uv अंतरिक्ष के लिए "अप" है।

यही है, तीन .js मान लेता है uv (0, 0) बनावट के निचले-बाएँ कोने में है, जबकि glTF कल्पना ऊपरी-बाएँ को मानती है। यही कारण है कि GLTFLoader texture.flipY से false । (तीन.js डिफ़ॉल्ट रूप से texture.flipY से true ।)

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

ठीक से लेखक glTF मॉडल के लिए, यह धारणा सही नहीं है। हालाँकि, आपको किसी भी मॉडल के लिए normalScale.y = - 1 सेट करके क्षतिपूर्ति करने में सक्षम होना चाहिए जो _properly glTF spec_ का पालन करता है।

मुझे यह भी प्रतीत होता है कि हम flipY झंडे को सम्मान देकर इसे स्वचालित रूप से ठीक कर सकते हैं।

अगर normalScale.y सेटिंग काम नहीं कर रही है, तो कुछ और चल रहा है।

इस स्पष्टीकरण के लिए धन्यवाद। मुझे लगता है कि हमारे यहां एक रास्ता है।

मुझे यह भी प्रतीत होता है कि हम flipY झंडे का सम्मान करके इसे स्वचालित रूप से ठीक कर सकते हैं।

हां, उन मामलों के अपवाद के साथ जहां glTF अपने स्वयं के स्पर्शरेखा वैक्टर की आपूर्ति करता है, है ना? मैं flipY परीक्षण और y इसी निषेध की आवश्यकता के लिए केवल ऑटो-गणना स्पर्शरेखाओं की उम्मीद करूंगा।

यदि यह मामला नहीं है ... इसका मतलब यह होगा कि मेरे NormalTangentMirrorTest मॉडल में गलत स्पर्शरेखाएं हैं, जिसका अर्थ है कि ब्लेंडर glTF निर्यातक स्वयं गलत स्पर्शरेखाओं को glTF मॉडल में डाल रहा है।

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

लेकिन ऐसा लगता है कि सही कार्रवाई normalScale.y फ्लिप करने के लिए है जब ऑटो-जनरेट किए गए स्पर्शरेखा (आपूर्ति किए गए स्पर्शरेखा नहीं) का उपयोग flipY ध्वज के साथ किया जा रहा है। विचार?

अपनी पिछली पोस्ट में, मैंने समझाया कि कैसे विशिष्ट स्पर्शरेखाओं के लिए मैन्युअल रूप से क्षतिपूर्ति की जाती है जब विशेषता स्पर्शरेखा मौजूद नहीं होती है। स्पर्शरेखा मौजूद होने पर स्क्रीन-स्पेस डेरिवेटिव्स का उपयोग नहीं किए जाने पर क्षतिपूर्ति के लिए कुछ भी नहीं होना चाहिए।

मैंने यह भी सुझाव दिया कि हम flipY झंडे का सम्मान करके इसे स्वचालित रूप से ठीक करने में सक्षम हो सकते हैं। मैंने यह नहीं कहा कि हम इसे स्वचालित रूप से normalScale.y फ़्लिप करेंगे। मुझे नहीं लगता कि हमें उपयोगकर्ता की सेटिंग में बदलाव करना चाहिए।

किसी भी घटना में, इससे पहले कि हम उस रास्ते से नीचे जाएं, मुझे लगता है कि यह जरूरी है कि हम इस परिकल्पना को सत्यापित करें:

[Y] ou किसी भी मॉडल के लिए normalScale.y = - १ सेट करके क्षतिपूर्ति करने में सक्षम होना चाहिए जो कि glTF युक्ति का ठीक से पालन करता है।

हमारे पास हर उस मॉडल के लिए एक स्पष्टीकरण होना चाहिए जिसे सही तरीके से प्रस्तुत नहीं किया जा रहा है।

मुझे नहीं लगता कि हमें उपयोगकर्ता की सेटिंग में बदलाव करना चाहिए।

हां, क्षमायाचना, मेरा इरादा उस तरह के कार्यान्वयन विवरण को निर्धारित करने का नहीं था। मैं बस यह सुनिश्चित करने की कोशिश कर रहा हूं कि स्क्रीन-स्पेस स्पर्शरेखा पीढ़ी के उद्देश्य से flipY flag_ का अर्थ क्या है, इसकी गलतफहमी नहीं है।

हमारे पास हर उस मॉडल के लिए एक स्पष्टीकरण होना चाहिए जिसे सही तरीके से प्रस्तुत नहीं किया जा रहा है।

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

मुझे लगता है कि यह इस मुद्दे से निकटता से संबंधित है? https://github.com/KhronosGroup/glTF-Sample-Models/issues/174

@WestLangley यहाँ मैंने अब तक क्या पाया है। डिफ़ॉल्ट रूप से, khronos-NormalTangentTest (कोई स्पर्शरेखा शामिल नहीं है) गलत दिखता है:

यदि मैंने normalScale.y = -1 सेट किया है, तो यह अभी भी गलत है:

अगर मैं इसके बजाय normalScale.x = -1 सेट करता हूं, तो यह सही लगता है:

संभव अपवाद के साथ कि प्रतिपादन थोड़ा पिक्सेलित दिखता है, विशेष रूप से गोल्ड रिफ्लेक्टर पर। क्या यह स्क्रीन-स्पेस सन्निकटन या किसी अन्य बग के संकेतक के साथ अपेक्षित है?

अगर किसी के पास टैंगेंट्स के बिना कोई अन्य अच्छा परीक्षण मॉडल है, तो कृपया उन्हें मेरा रास्ता भेजें। मैं यह सुनिश्चित करना चाहता हूं कि मेरे पास एक प्रतिनिधि नमूना है, और यह निर्धारित करें कि क्या कोई ऐसा है जो glTF कल्पना में फिट नहीं है।

@ लीलाश उस परीक्षण का मेरे लिए कोई मतलब नहीं है, यह मेरे लिए कभी समझ में नहीं आया है, और यह शायद कभी नहीं होगा। तो ... मैं इसे समझाने की कोशिश में आपकी मदद नहीं करूंगा।

वह उदाहरण बहुत अधिक IMHO है। हमें एक सुसंगत परीक्षण मामले की आवश्यकता है जो समझने के लिए पर्याप्त दृश्य प्रदान करता है कि क्या हो रहा है।

BTW, हमारे पास VertexTangentHelper (# 3511) हुआ करता था, जिसे बफर ज्यामिति का समर्थन करने के लिए पुनर्जीवित किया जा सकता था।

@WestLangley काश मुझे पता होता कि मैं NormalTangentTest को और अधिक स्पष्ट कैसे बना सकता हूं। यह कुछ भी अलग नहीं करता है, यह बस प्रत्येक नमूने के अभिविन्यास (यूवी स्थान में) को घुमाता है। तीनों स्तंभ अलग-अलग सामग्रियों का परीक्षण करने के लिए हैं, स्वर्ण स्तंभ अपने आप में पर्याप्त हो सकता है। इसके अलावा मुझे नहीं लगता कि परीक्षण मॉडल बहुत सरल हो सकता है और अभी भी इन विभिन्न यूवी झुकाव का परीक्षण कर सकता है।

यूवी घुमावों के बावजूद, सामान्य मानचित्र की छवि काफी सुसंगत होती है कि वे किस तरह से वेक्टर्स को इंगित करते हैं, जब सामान्य मानचित्र को 2 डी छवि के रूप में देखा जाता है। छवि के 2 डी दृश्य में, सभी गोलार्धों के दाहिने पक्षों में उच्च लाल-चैनल मान होते हैं, और सभी गोलार्ध के शीर्ष किनारों में यूवी निर्देशांक की परवाह किए बिना उच्च हरे-चैनल मान होते हैं। यह glTF विनिर्देशन का अनुसरण करता है जो UV अंतरिक्ष में बनावट के दाईं ओर लाल (+ X) अंक और UV अंतरिक्ष में बनावट के शीर्ष किनारे पर हरे (+ Y) अंक बनाता है। इस कार्य को करने के लिए किसी को स्पर्शरेखा वाले वैक्टर की आवश्यकता नहीं होती है: एक साधारण स्क्रीन-स्पेस का आकलन आम तौर पर किस दिशा में + U अक्ष दी गई त्रिकोण के लिए स्पर्शरेखा और द्वि-स्पर्शरेखा वैक्टर को काम करने के लिए पर्याप्त है, जैसा कि बाबुलजेएस और सीज़ैलजेएस, और निश्चित रूप से थ्री जेएस भी करता है, लेकिन कुछ के साथ अभी तक अस्पष्टीकृत सामान्य अक्ष धुरी है।

GlTF के flipY झंडे के उपयोग के साथ भ्रम का एक ज्ञात बिंदु है, यूवी अंतरिक्ष में V निर्देशांक है, जो मुझे लगता है कि आप पहले से ही अच्छी तरह से जानते हैं। मुझे लंबे समय से यह संदेह था कि यह अस्पष्टीकृत सामान्य शल्क फ्लिप में एक भूमिका निभाता है।

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

यह 3 डी ज्यामिति से पहले सामान्य मानचित्र बनावट दोहराने वाले कलाकारों के लिए एक महत्वपूर्ण प्रभाव है, क्योंकि कलाकार को बनावट छवि बनाने से पहले यूवी या स्पर्शरेखा निर्देशांक तक पहुंच की आवश्यकता नहीं होती है।

@WestLangley मुझे यह परीक्षण केवल इसलिए पसंद

इसके अलावा, प्लॉट मोटा होता है: मूल परीक्षण एक दो तरफा सामग्री है। # 17804 के कारण, मैंने इसे एकल-पक्षीय के रूप में आज़माने का फैसला किया। यह डिफ़ॉल्ट रूप से अभी भी गलत है, लेकिन जब मैंने normalScale.y = -1 सेट किया तो मुझे सही उत्तर मिल गया:

बहुत कम से कम मुझे आशा है कि हम इस बात से सहमत हो सकते हैं कि बदलते डबल साइड को सामने वाले के रेंडर को प्रभावित नहीं करना चाहिए?

@emackey एक अन्य परीक्षण मॉडल जो सहायक हो सकता है मुझे लगता है कि वेल्डेड मानदंडों के साथ एक चमकदार घन होगा और इसे गोल के बजाय क्यूब के आकार का बनाने के लिए डिज़ाइन किया गया एक समान सामान्य नक्शा होगा। संभवतः दो संस्करण, एक बिना आपूर्ति किए स्पर्शरेखा के साथ। दुर्भाग्य से मुझे इसे करने के लिए संलेखन कौशल की कमी है। अगर मैं इसे हमारे लिए बनाऊं तो सभी बहुत धन्यवाद दे सकते हैं: प्रार्थना:

@emackey इस पर आपके सभी काम के लिए धन्यवाद। मैं इसकी बहुत सराहना करता हूं। मैं उन सभी विभिन्न मुद्दों को समझता हूं जो कलाकारों के साथ उत्पन्न हो सकते हैं - और ऐसे मुद्दे जिन्हें दूर किया जाना चाहिए।

शायद आप @elalish के साथ काम करने के लिए तैयार

@elalish हमने पहले इन मुद्दों को संबोधित किया है। एक समय मैं इस धारणा के तहत था कि सब कुछ काम कर रहा है। यदि एक साधारण परीक्षण मामला है, तो मैं bisect का उपयोग कर सकता हूं ताकि यह पता लगाया जा सके कि चीजें कहां टूट गईं।

वेल्डेड मानदंडों के साथ चमकदार घन और गोल के बजाय इसे घन के आकार का बनाने के लिए डिज़ाइन किया गया एक समान सामान्य नक्शा।

हो गया: normal_map_flat.zip मैंने ड्रेको टीम द्वारा लिखित स्पर्शरेखा उदाहरण लिया, और स्पर्शरेखा विशेषता के बिना एक अतिरिक्त संस्करण बनाया।

एक समय मैं इस धारणा के तहत था कि सब कुछ काम कर रहा है।

मुझे लगता है कि हम एक ऐसी स्थिति में पहुंच गए हैं जहां सब कुछ काम करता है _if_ मॉडल में स्पर्शरेखाएं शामिल हैं। यदि नहीं, तो चीजें आमतौर पर ठीक हैं, लेकिन विशेष रूप से यूवी सीम के आसपास कुछ किनारे मामले संभव हैं। उस स्थिति में हम उपयोगकर्ताओं को स्पर्शरेखा जोड़ने की सलाह देंगे। या, https://github.com/mrdoob/three.js/issues/11438#issuecomment -507027586 में उल्लिखित @emackey के रूप में, शायद हमें GLTFLoader में normalScale.y *= -1 फ्लिप बहाल करना चाहिए, केवल उन मामलों में जहां मेष वर्टेक्स स्पर्शरेखा को छोड़ता है।

@donmccurdy धन्यवाद। मैं आज इस मुद्दे के लिए समय से बाहर हूं, लेकिन मैं अभी भी फ्लैट क्यूब पक्षों के साथ संघर्ष कर रहा हूं। यदि आप एक चमकदार सतह ( metallicFactor: 1, roughnessFactor: 0.1 ) के लिए अपने मॉडल को संपादित करते हैं, तो आपको क्यूब तैरते हुए पक्षों में प्रतिबिंब दिखाई देंगे।

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

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

मैं सूक्ष्म फ़न-हाउस इफ़ेक्ट्स की उम्मीद करूँगा, लेकिन वर्तमान में मुझे जो नहीं मिल रहा है (कोई स्पर्श संस्करण):

स्पर्शरेखा संस्करण के साथ वास्तव में कोई बेहतर नहीं है, जो मुझे आश्चर्यचकित करता है कि क्या यह वास्तव में एक वैध glTF है:

@emackey क्या आप हमें यह बताने के लिए योग्य महसूस करते हैं कि क्या या तो ये दोनों मॉडल @donmccurdy प्रदान किए गए हैं जो वास्तव में वैध glTF हैं? यदि वे हैं, तो मुझे लगता है कि हमारे पास एक बड़ी समस्या है।

यह विशेष रूप से घन ऐसा चरम उदाहरण है कि मैं वास्तव में नहीं जानता कि क्या कहना है, या क्या शारीरिक रूप से यथार्थवादी प्रतिबिंब एक उचित उम्मीद है। सामान्य नक्शे धक्कों और डेंट जैसे विवरण जोड़ने के लिए होते हैं, न कि मेष की पूरी सतह को ख़राब करने के लिए। यह परीक्षण करने के लिए बहुत प्रभावी तरीका है कि स्पर्शरेखाओं को सही तरीके से पढ़ा या उत्पन्न किया गया। मुझे पता है कि normalScale.y *= -1 परिवर्तन कभी भी इसे ठीक करने के लिए पर्याप्त नहीं था; यह उन उदाहरणों में से एक था जिसने हमें पहले स्थान पर संग्रहीत स्पर्शरेखाओं का समर्थन करने के लिए प्रेरित किया।

बाबुल में भी प्रतिबिंब जंगली दिखते हैं:

यदि केवल पहचानी गई समस्या NormalTangentTest के साथ है, और कोई भी उपयोगकर्ता उन मॉडलों के साथ आगे नहीं आया है जो गलत तरीके से अभ्यास करते हैं, तो शायद हमें यहां बदलाव करने से रोकना चाहिए?

मैं अभी भी normalScale.y *= -1 गुणक बहाल करने के साथ ठीक हूं, लेकिन समस्या के उदाहरणों की कमी एक संकेत की तरह लगती है कि समस्या मामूली है, बजाय एक संकेत के कि हमें ऐसे चरम उदाहरण बनाने की आवश्यकता है।

यदि केवल पहचानी गई समस्या NormalTangentTest के साथ है, और कोई भी उपयोगकर्ता उन मॉडलों के साथ आगे नहीं आया है जो गलत तरीके से अभ्यास करते हैं, तो शायद हमें यहां बदलाव करने से रोकना चाहिए?

सुधार: https://github.com/mrdoob/three.js/issues/17804 से पता चलता है कि कुछ वास्तव में दो तरफा सामग्री के साथ फिर से हो सकता है। यह आगे की जांच के लायक लगता है, हालांकि सादगी और पवित्रता के लिए शायद हमें शापित क्यूब को अब के लिए अकेला छोड़ देना चाहिए। 😇