Three.js: नॉर्मल्स जाल के कुछ हिस्सों पर फ़्लिप करते हैं जिनमें डबल पक्षीय सामग्री होती है

@pushmatrix क्या आप पुष्टि कर सकते हैं कि यह मॉडल अपने स्वयं के स्पर्शरेखा की आपूर्ति करता है या नहीं करता है? मैं उत्सुक हूँ अगर यह # 11438 से संबंधित हो सकता है।

मेरा मानना ​​है कि यह अपने स्वयं के स्पर्शरेखाओं को निर्दिष्ट नहीं करता है

एक अलग परीक्षण के मामले का उपयोग करते हुए, git bisect, # 17586 को PR के रूप में इंगित करता है जिसने समस्या को शुरू किया है यदि मेष दो तरफा है और नकारात्मक पैमाने X है। यह r.109 में था, r.108 नहीं।

इस पीआर से मॉडल पर परीक्षण नहीं किया गया था क्योंकि वह मॉडल उपलब्ध नहीं है।

यहाँ परीक्षण glb है
wheels.glb.zip

3 साल पहले से: https://github.com/mrdoob/three.js/issues/10331#issue -194807426

मूल रूप से ऐसा लगता है कि ... gl_FrontFace Adreno GPU पर डबल पक्षीय सामग्री के साथ ठीक से काम नहीं कर रहा है।

क्या यह _still_ एक ऐसा मुद्दा है जिसे हमें समायोजित करने की आवश्यकता है?

//

यह मॉडल मेरी मशीन पर सही ढंग से रेंडर करने के लिए प्रकट होता है यदि हम normalmap_pars_fragment में एड्रेनो वर्कअराउंड को हटा दें:

#ifdef DOUBLE_SIDED

    // Workaround for Adreno GPUs gl_FrontFacing bug. See #15850 and #10331

    bool frontFacing = dot( cross( S, T ), N ) > 0.0;

    mapN.xy *= ( float( frontFacing ) * 2.0 - 1.0 );

#else

    mapN.xy *= ( float( gl_FrontFacing ) * 2.0 - 1.0 );

#endif

हम्म, मुझे वह टिप्पणी पढ़ना भी याद है; मुझे लगता है कि मैं इस बग को देखते हुए आया था, जो स्पष्ट रूप से r108 में तय किया गया था (कम से कम इसे हमारे लिए निर्धारित किया गया है): https://github.com/GoogleWebCompords/model-viewer/issues/740

शायद यह संबंधित है? FWIW, मुझे पुराने एड्रेनो जीपीयू के बारे में कुछ प्रतिक्रिया मिली है, तो जाहिर है कि वे अभी भी काफी सामान्य हैं।

बस पुष्टि करने के लिए, यह अभी भी dev :

बस पुष्टि करने के लिए, यह अभी भी देव में होता है:

सही। लेकिन अगर आप एड्रेनो बग वर्कअराउंड को नहीं हटाते हैं।

लेकिन अगर आप एड्रेनो बग वर्कअराउंड को नहीं हटाते हैं।

अब के लिए वर्कअराउंड हटाने के बारे में कैसे और फिर एक अलग समाधान के लिए खोज करें? वर्तमान कार्यान्वयन गलत विज़ुअल्स की ओर जाता है, इससे कोई फर्क नहीं पड़ता कि आप किस प्लेटफ़ॉर्म का उपयोग कर रहे हैं।

@ मुगें87 इस विशेष मामले में, मेरा मानना ​​है कि ज्यामिति एक दूसरे के दर्पण हैं, लेकिन वे समान सामान्य मानचित्र साझा करते हैं।

मैं आपसे सहमत हुँ। मैंने एड्रेनो-संगत वर्कअराउंड ढूंढने की कोशिश में कई घंटे लगाए हैं जो हर उपयोग के मामले में सही है।

व्हील मॉडल मॉडल का निरीक्षण, प्रत्येक पहिया का अपना यूवी शेल होता है। यह एक साझा नहीं करता है।
और शीर्ष क्रम विपरीत है।

हालांकि चेहरे का उन्मुखीकरण समान है, कम से कम ब्लेंडर में।

तो मुझे यकीन नहीं है कि यह r108 में बग है, या अगर r108 अब चीजों को ठीक से कर रहा है। _ (ツ) _ / ¯

@pushmatrix आप एकता या ब्लेंडर के साथ तुलना कर सकते हैं?

@mrdoob

ब्लेंडर 2.8

एकता

Sketchfab

@pushmatrix

एकता को देखना मुश्किल है क्योंकि प्रकाश उसी दिशा में है जो कैमरा है, लेकिन ऐसा लगता है कि एकता भी गलत है? 🤔

@mrdoob

हाँ, यह प्रकाश पर थोड़ा सा निर्भर करता है यह एक भ्रम होने के नाते समाप्त होता है और यह देख रहा है कि यह कुछ स्थानों पर पॉप अप हुआ है। लेकिन जब आप चारों ओर घूमते हैं, तो यह गायब हो जाता है।

यहां यह अन्य प्रकाश में है, जहां यह सही प्रतीत होता है

@ मर्डोबू फ्रंट-चेहरों के पास

इस उदाहरण में, मेरा _conjecture_ बाईं ओर का मॉडल है, जिसमें दक्षिणावर्त UVs हैं और दाईं ओर के मॉडल में _clockwise_ UVs हैं। जब doubleSide true मॉडल सही तरीके से गलत तरीके से प्रस्तुत कर रहा है।

AFAIK, एड्रेनो-वर्कअराउंड को हटाने से गैर-एड्रेनो GPU के लिए समस्या ठीक हो जाती है।

@pushmatrix आपकी एकता का उदाहरण दो दिशाओं से दिशात्मक रोशनी है। इससे यह समझ पाना मुश्किल हो जाता है कि क्या हो रहा है। एक एकल प्रकाश बेहतर हो सकता है।

@WestLangley मैं उसी पर्यावरण मानचित्र का उपयोग कर रहा हूं जो मॉडल-दर्शक उपयोग कर रहा है, लेकिन संभावना है कि यह एक ही रोटेशन नहीं है। मैं एक एकल प्रकाश के साथ कोशिश करूंगा।

@WestLangley एकल दिशात्मक प्रकाश चारों ओर घूमता है। मुझे लगता है कि मैं एक ऑप्टिकल भ्रम देख रहा हूं

एकता की तरह लगता है कि खांचे को पॉप में और बाहर कैसे प्रकाश हिट पर निर्भर करता है, लेकिन कम से कम यह दोनों के लिए संगत है।

थ्रीज भी संगत है, लेकिन एक निश्चित रूप से हमेशा पॉप आउट दिखता है:

मुझे ऐसा लगता है कि एकता में कुछ गड़बड़ है ...
जैसे इसे कुछ चाहिए। material.normalMapScale.x = -1 ।

@WestLangley

@ मर्डोबू फ्रंट-चेहरों के पास

इस उदाहरण में, मेरा _conjecture_ बाईं ओर का मॉडल है, जिसमें दक्षिणावर्त UVs हैं और दाईं ओर के मॉडल में _clockwise_ UVs हैं। जब doubleSide true मॉडल सही तरीके से गलत तरीके से प्रस्तुत कर रहा है।

AFAIK, एड्रेनो-वर्कअराउंड को हटाने से गैर-एड्रेनो GPU के लिए समस्या ठीक हो जाती है।

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

मुझे आज संबंधित shader कोड पर एक नज़र थी और ऐसा लगता है कि वे "Per-Pixel Tangent Space Normal Mapping" का उपयोग नहीं कर रहे हैं।

इस पोस्ट के अनुसार, स्केचफैब संपत्ति में स्पर्शरेखा परिभाषाओं की अपेक्षा करता है या ये डेटा हैं
यूवी निर्देशांक के आधार पर उत्पन्न। यह वही है जो मैंने GLSL कोड में देखा है।

यदि मैं BufferGeometryUtils.computeTangents() माध्यम से मॉडल में स्पर्शरेखा जोड़ता हूं और Material.vertexTangents से true सेट करता हूं, तो परिणाम ठीक लगता है:

BTW: क्या इस पोस्ट ^ ^ में स्केचफैब से कोड स्निपेट्स साझा करना ठीक है? आखिरकार, यह ओपन-सोर्स नहीं है।

संगति के लिए, यहां स्केचफैब 1 दिशात्मक प्रकाश के साथ आगे और पीछे चल रहा है:

हाँ एक बात का ध्यान रखें कि जब आप कोई मॉडल अपलोड करते हैं तो स्केचफैब उनके अंत में प्रोसेसिंग करता है, इसलिए बहुत संभव है कि वे चीजें / चीजें बदल रहे हों। आप जो देख रहे हैं, वह एक glTF नहीं है, बल्कि एक glTF फ़ाइल उनके अपने प्रारूप में परिवर्तित हो गई है।

@pushmatrix क्या आप _please_ प्रदर्शित कर सकते हैं कि # 17958 आपके मॉडल के लिए काम करता है?

तीन.js खंडित छाया में स्पर्शरेखा की गणना करता है। मुझे विश्वास है कि यह सही ढंग से काम करता है अगर कुछ छोटी गाड़ी एड्रेनो जीपीयू को समायोजित करने के लिए एक हैक हटा दिया जाता है। # 17958 देखें।

//

स्केचफैब सीपीयू पर स्पर्शरेखा की गणना करता है जब स्पर्शरेखा की आवश्यकता होती है और मॉडल द्वारा प्रदान नहीं की जाती है। ( @donmccurdy यह वही है जो glTF कल्पना की आवश्यकता है।)

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

इसे ठीक करता है!

ठीक है, तो ऐसा लगता है कि यहां समाधान एड्रेनो वर्कअराउंड (# 17958) को वापस करना है और लोगों को BufferGeometryUtils.computeTangents() का उपयोग करने की सलाह देते हैं जब मॉडल में स्पर्शरेखा नहीं होती है और वे Adreno GPUs (# 15850) का समर्थन करना चाहते हैं ।

बढ़िया है?

एक अन्य उपाय यह है कि BufferGeometryUtils.computeTangents() इंजन में स्वचालित रूप से कॉल किया जाए जब प्रदान नहीं किया जाता है और सभी कोड हटा दें जो कि टुकड़े टुकड़े में टैंटर की गणना करता है ... $

BufferGeometryUtils.computeTangents() वर्तमान में एक इंडेक्स की आवश्यकता है इसलिए इसे कोर में उपयोग नहीं किया जा सकता है। हालाँकि, मुझे लगता है कि यह बेहतर होगा यदि three.js कुछ बिंदु पर MIKKTSpace के अनुसार स्पर्शरेखा उत्पन्न कर सके और फिर perturbNormal2Arb() निकाल दें।

@WestLangley ने लिखा:

इसका मतलब होगा सभी बिल्ट-इन जियोमेट्री में सही स्पर्शरेखा जोड़ना।

मेरा मन बदल रहा है ... स्पर्शरेखाओं की आवश्यकता नहीं है। इसके बजाय, मैं सभी बिल्ट-इन ज्यामिति के लिए BufferGeometry.computeTangents() और "ओवरराइड" पद्धति को पुनर्स्थापित करूंगा, जिसके लिए हम विश्लेषणात्मक रूप से सटीक स्पर्शरेखा सेट कर सकते हैं।

//

एक और उपाय है कि इंजन में बफ़रगेटोमेट्री युटिल्स.कॉमप्यूटेंट्स () को स्वचालित रूप से कॉल किया जाए जब प्रदान नहीं किया जाता है और टुकड़े टुकड़े करने वाले सभी कोड को हटा दें ...

यह मुझे सही लगता है।

BufferGeometryUtils.computeTangents () को वर्तमान में एक इंडेक्स की आवश्यकता होती है इसलिए इसे कोर में उपयोग नहीं किया जा सकता है।

मुझे लगता है कि यह आसानी से तय हो गया है। और इसके लिए https://github.com/mrdoob/three.js/issues/17804#issuecomment -557135610 का समर्थन करना होगा।

यह बेहतर होगा यदि तीन.js किसी बिंदु पर MIKKTSpace के अनुसार स्पर्शरेखा उत्पन्न कर सकते हैं और फिर perturbNormal2Arb () को हटा दें ...

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

यह अच्छा होगा यदि BufferGeometryUtils.computeTangents मिककस्पेस दृष्टिकोण को लागू कर सकते हैं - यह सबसे अच्छा एल्गोरिथ्म है, अगर आपको उन्हें पहले से तैयार करना होगा। लेकिन शायद glkF- पाइपलाइन या gltfpack जैसे उपकरणों में मिककस्पेस को रखना आसान होगा, जो मौजूदा देशी कार्यान्वयन का उपयोग कर सकते हैं, और गणना अग्रिम में, ऑफ़लाइन कर सकते हैं।

@donmccurdy

लेकिन, कहते हैं ... <model-viewer> उपयोग के मामले में, मुझे नहीं लगता कि यह जानने का कोई विश्वसनीय तरीका है कि क्या उपयोगकर्ता के पास एड्रेनो जीपीयू है लेकिन हम सही देखना चाहेंगे (https: // github)। com / GoogleWebComponents / मॉडल-दर्शक / मुद्दों / 740)।

क्या <model-viewer> (और अन्य प्रोजेक्ट्स जो x-gpu समर्थन चाहते हैं) को BufferGeometryUtils.computeTangents जब स्पर्शरेखा प्रदान नहीं की जाती है, या तीन होनी चाहिए?

@pushmatrix

हाहा, मुझे अभी पता चला है कि ये पहिए realized कहां से हैं

https://bumbleride.com/products/era?variant=20719969599599

@ मर्डोबू 🕵

ठीक है, तो अब के लिए वर्कअराउंड को वापस करने देता है।