Three.js: यूवी ऑफसेट / रिपीट बनावट के बजाय सामग्री का हिस्सा होना चाहिए

संबंधित पोस्ट: https://github.com/mrdoob/three.js/issues/3549

आपको प्रति सामग्री बनावट को क्लोन करना होगा (एक टन मेमोरी बर्बाद करना)

टन मेमोरी किस अर्थ में बर्बाद होती है?

"साझा" बनावट पर साझा यूवी ऑफ़सेट/दोहराव की आवश्यकता की संभावना कम है

उससे तुम्हारा क्या मतलब है?

यदि हम वर्तमान दृष्टिकोण को बनाए रखते हैं, तो एक चीज जिसे बदलने की जरूरत है, वह यह है कि जब एक बनावट का क्लोन बनाया जाता है, तो साझा की गई छवि को केवल एक बार GPU को पास किया जाना चाहिए।

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

दूसरे कथन के संबंध में:

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

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

श्रीदूब ने कहा कि प्रति सामग्री होने के कारण इसे निम्नलिखित रूप में होना चाहिए,

सामग्री.नक्शा
सामग्री.मैपऑफ़सेट
मटेरियल.मैपरिपीट
सामग्री.env
सामग्री.envOffset
सामग्री.envदोहराना
... आदि।

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

@QuaziKb पूरे सम्मान के साथ, यदि आप पुस्तकालय में एक मौलिक परिवर्तन का प्रस्ताव करने जा रहे हैं, जैसे कि आपने यहाँ प्रस्तावित किया है, तो आपको उस परिवर्तन के लिए एक स्पष्ट और सम्मोहक तर्क देना होगा। आपके विशेष आवेदन के संदर्भ के फ्रेम से बहस करने से इसमें कटौती नहीं होगी।

कहा जा रहा है, मैं भी ऑफसेट/रिपीट को Texture से सामग्री में स्थानांतरित होते देखना चाहता हूं।

मेरा मानना ​​​​है कि यह मान लेना उचित है कि निम्नलिखित मानचित्रों में समान ऑफसेट/दोहराव मान हैं:

specularMap
normalMap
bumpMap
alphaMap
aoMap (future)
glossMap (future)
displacementMap (future)

एकमात्र अपवाद है

इस तरह इसे अभी लागू किया गया है; भले ही प्रत्येक मानचित्र का अपना ऑफसेट/दोहराव मान हो, लेकिन उन्हें सम्मानित नहीं किया जाता है।

इसलिए, हम जोड़ सकते हैं MeshPhongMaterial , MeshLambertMaterial , MeshBasicMaterial , और SpriteMaterial , हम जोड़ देंगे

mapOffset // or mapTranslate
mapRepeat // or mapScale

हम offset और repeat को Texture से हटा देंगे।

इस तरह, स्प्राइट शीट को लागू करना सीधा-सीधा है। प्रत्येक स्प्राइट में एक सामग्री होती है, और उन सामग्रियों में एक ही बनावट होती है। बनावट में एक छवि है। बनावट को अब क्लोन करने की आवश्यकता नहीं है। GPU पक्ष पर, सामग्री एकल शेडर प्रोग्राम साझा करेगी।

आईएमएचओ, यह एक अधिक प्राकृतिक एपीआई है।

मैं यह याद करने की कोशिश कर रहा हूं कि एपीआई को जिस तरह से लागू किया गया था, उसे क्यों लागू किया गया था। मुझे उम्मीद है कि एक अच्छा कारण था।

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

मेरा मानना ​​​​है कि यह मान लेना उचित है कि निम्नलिखित मानचित्रों में समान ऑफसेट/दोहराव मान हैं:
नक्शा
...
अल्फा मैप

एफडब्ल्यूआईडब्ल्यू, यह व्यवहार (वर्तमान कार्यान्वयन) इस समय मेरे लिए महत्वपूर्ण निराशा पैदा कर रहा है। मैं जाल सामग्री के अल्फा मैप ऑफसेट को स्वतंत्र रूप से फैलाने वाले मानचित्र (जो स्थिर रहता है) से अलग करके जाल के प्रकटीकरण को एनिमेट करने का प्रयास कर रहा हूं। कुछ निराशा के बाद मुझे https://github.com/mrdoob/three.js/pull/4987 और इस बग के माध्यम से पता चला कि यह संभव नहीं है।

@jcarpenter आप किस "बग" का जिक्र कर रहे हैं? सुधार के लिए आपका क्या सुझाव है?

सुधार: "बग" से मेरा मतलब इस मुद्दे से था। बगजिला संस्कृति में अत्यधिक समय के कारण मिलावट। :p मैं समझता हूं कि यह कोई बग नहीं है, बल्कि इच्छित व्यवहार है।

सिनेमा ४डी जैसे पारंपरिक ३डी सामग्री निर्माण ऐप्स के साथ अपने अनुभव के आधार पर एक सुधार के लिए डब्लूआरटी, मुझे लगता है कि उपयोगकर्ता दोनों में सक्षम है:

• एक सामग्री के भीतर प्रत्येक बनावट के लिए ऑफसेट/स्केल/दोहराना परिभाषित करें, अन्य बनावट से स्वतंत्र, _and_
• मूल सामग्री के ऑफसेट/स्केल/दोहराने को परिभाषित करें

वैकल्पिक रूप से उपयोग के मामले में मैं काम कर रहा हूं ("मेष के प्रकटीकरण को एनिमेट करने का प्रयास"), रैपएस और रैपटी के लिए एक विकल्प होना शानदार होगा जो बिल्कुल लपेटता नहीं है। Cinema4D से संलग्न GIF के अनुसार, जिसमें UVW मैपिंग के लिए पूरी तरह से टाइलिंग को अक्षम करने का विकल्प है। मौजूदा रैप्स और रैपटी विधियों के साथ काफी व्यापक परीक्षण के आधार पर, ऐसा कुछ भी संभव नहीं है। मतलब तीन.जेएस में वस्तुओं के प्रकटीकरण को चेतन करने के लिए मेरे विकल्प ट्विनिंग स्थिति और पूरे जाल की अस्पष्टता तक सीमित लगते हैं ... जब तक कि मुझे कुछ याद नहीं आ रहा है।

माना। योजना यह सब (शेडर में एक मैट्रिक्स 3 का उपयोग करके) को सरल बनाना है और प्रति बनावट ऑफसेट/दोहराना (या अनुवाद/स्केल) होना है।

कोई भी जो इसमें मदद करना चाहता है उसकी बहुत सराहना की जाएगी!

@jcarpenter

दुख की बात है कि अभी ऐसा करने का एकमात्र तरीका कई मेश w/विभिन्न सामग्रियों, या एक कस्टम शेडर सामग्री के साथ है। ये दोनों उस उपयोगकर्ता के लिए एक तरह से शामिल हैं जो अभी तीन.जेएस वर्कफ़्लो में कूद रहा है।

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

योजना यह सब सरल बनाने के लिए है (शेडर में एकल मैट्रिक्स 3 का उपयोग करके) और प्रति बनावट ऑफसेट/दोहराना (या अनुवाद/स्केल) होना।

@mrdoob

1. क्या आपका मतलब _प्रति सामग्री.मैप_ है तो बनावट परिवर्तन सामग्री में है? दुर्भाग्य से, बहुत सारे भौतिक मानचित्र हैं। हम यह मान सकते हैं कि लाइटमैप को छोड़कर सभी बनावट परिवर्तन समान हैं।
2. क्या आप भी रोटेशन का समर्थन करना चाहते हैं? यदि ऐसा है, तो आपको रोटेशन सेंटर भी जोड़ना होगा - जब तक कि आप रोटेशन सेंटर को बनावट के केंद्र में हार्डवायर नहीं करना चाहते।

यह एक बहुत ही सराहनीय बदलाव होगा। बनावट को केवल अद्वितीय दोहराने वाले मूल्यों पर रखने के लिए क्लोन करना बहुत ही बोझिल लगता है। क्या अन्य पुस्तकालय ऐसा करते हैं?

1. क्या आपका मतलब _प्रति सामग्री.मैप_ है तो बनावट परिवर्तन सामग्री में है? दुर्भाग्य से, बहुत सारे भौतिक मानचित्र हैं। हम यह मान सकते हैं कि लाइटमैप को छोड़कर सभी बनावट परिवर्तन समान हैं।

मुझे लगता है कि हमारे पास प्रति नक्शा mat3 होना चाहिए और Texture गुणों से बना होना चाहिए।

1. क्या आप भी रोटेशन का समर्थन करना चाहते हैं? यदि ऐसा है, तो आपको रोटेशन सेंटर भी जोड़ना होगा - जब तक कि आप रोटेशन सेंटर को बनावट के केंद्र में हार्डवायर नहीं करना चाहते।

रोटेशन हाँ। केंद्र या नहीं ... मुझे यकीन नहीं है, लेकिन जहां तक ​​​​मैं समझता हूं, यह सब शेडर (प्रति नक्शा) के लिए एक mat3 में एन्कोड किया जा सकता है।

यहां एक प्रोटोटाइप दिखाया गया है कि कैसे एक Matrix3 एक शेडर को पास किया जा सकता है और offsetX , offsetY , repeatX , repeatY द्वारा परिभाषित एक परिवर्तन का प्रतिनिधित्व करता है। rotation , rotationCenterX , और rotationCenterY ।

यदि विकल्प के रूप में center की अनुमति नहीं है, तो इसे ( 0.5, 0.5 ) हार्डवायर किया जाना चाहिए।

टिप्पणियों का स्वागत है।

संपादित करें: डेमो अपडेट किया गया

यह महान है! :+1: :+1:

मुझे लगता है कि मैं translation और scale ( offset और repeat बजाय) के साथ जाऊंगा।

वास्तव में, नए भौतिक गुण क्या होने चाहिए? बहुत सारे भौतिक मानचित्र हैं।

बनावट गुणों से क्या हटाया जाना चाहिए?

मुझे लगता है कि बनावट पर wrapS/T रहना चाहिए।

मुझे लगता है कि texture.offset और texture.repeat को हटा दिया जाना चाहिए।

मुझे लगता है कि नई संपत्तियां होनी चाहिए... texture.translation , texture.rotation , texture.scale , texture.center और texture.matrix । हमें शायद texture.updateMatrix() विधि की भी आवश्यकता होगी जिसे रेंडर समय पर बुलाया जाएगा। यह, निश्चित रूप से, यह सुनिश्चित करने की चुनौती है कि हम इसे केवल एक बार ही करते हैं, भले ही बनावट का पुन: उपयोग किया गया हो।

इस पोस्ट के शीर्षक और https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293 में दिए गए तर्कों का जिक्र करते हुए, मैंने सोचा कि बिंदु इन गुणों को सामग्री में स्थानांतरित करना था।

/पिंग @bhouston टिप्पणियों के लिए।

मेरे विचार हैं कि बनावट ऑफसेट/दोहराना जितना संभव हो यूवी में बेक किया जाना चाहिए। यह आसान है। अधिकांश भाग के लिए UE4/Unity 5 इसे इस प्रकार करते हैं।

अपवाद यह है कि यूनिटी 5 में प्रति सामग्री एक वैश्विक ऑफसेट/रिपीट निर्दिष्ट करने की क्षमता है जो सभी बनावटों में साझा की जाती है - लेकिन यह प्रभावित नहीं करता है जिसे लाइट मैप या परिवेश समावेशन मानचित्र जैसे बेक्ड मानचित्र माना जाता है (वे समायोजित करने का कोई मतलब नहीं है।)

मैं यहां बहुत अधिक लचीलेपन की वकालत नहीं करने का कारण यह है कि पेशेवर रूप से बनाए गए मॉडल में उचित यूवी होते हैं जो इसे आम तौर पर आवश्यक नहीं बनाते हैं - सामग्री निर्माण उपकरण में इसे बेक करने के तरीके होते हैं। दूसरा मुद्दा यह है कि वेबजीएल में फ्रैगमेंट वर्दी के लिए हास्यास्पद रूप से कम निचली सीमा है - 16 वीईसी 4। यदि आपको प्रति मानचित्र दोहराना/ऑफ़सेट करना है, और हमें जल्द ही बहुत सारे मानचित्र मिलेंगे, तो हम बहुत कम मूल्य के लिए फ्रैगमेंट वर्दी बर्बाद कर रहे हैं।

मैंने हाल ही में Clara.io में प्रति बनावट में एक दोहराव/ऑफ़सेट और फिर चमक/लाभ नियंत्रण जोड़ा है और मैं इन परिवर्तनों को पूर्ववत कर दूंगा क्योंकि यह कम अंत उपकरणों पर फ्रैगमेंट वर्दी को बहने की ओर अग्रसर कर रहा है - जैसे कि प्रत्येक ऐप्पल आईओएस डिवाइस। हालाँकि NVIDIA 980s के साथ डेस्कटॉप पर रिपीट/ऑफ़सेट और ब्राइटनेस/गेन बहुत अच्छा काम करता है, लेकिन हमें हाई एंड मशीनों के लिए नहीं, बल्कि सभी के लिए डिज़ाइन करना है। ;)

हमें फ्रैगमेंट यूनिफॉर्म का सम्मान करना होगा और जरूरत पड़ने पर ही उनका इस्तेमाल करना होगा। मेरा मानना ​​है कि यह उन मामलों में से एक नहीं है।

अपवाद यह है कि यूनिटी 5 में प्रति सामग्री एक वैश्विक ऑफसेट/रिपीट निर्दिष्ट करने की क्षमता है

यह मूल रूप से तीन.जेएस अब क्या कर रहा है - हालांकि इसे डिफ्यूज मैप से ऑफसेट/रिपीट मिलता है, और अन्य सभी सामग्री बनावट उस मानचित्र से सेटिंग का उपयोग करती हैं।

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

दुर्भाग्य से, हमें इस पर बहुत अधिक सहमति नहीं मिल रही है।

एकता ५ जो कर रही है वह करना एक अच्छा विचार है। मैं इसे बनावट के बजाय सामग्री पर भी रखूंगा। आपको मेरा समर्थन है।

प्रति नक्शा वास्तव में आदर्श नहीं है, लेकिन इसे किसी भी तरह झंडे/चाबियों के साथ निर्दिष्ट करके हल किया जा सकता है जब सामग्री की आवश्यकता होती है, तो इसकी आवश्यकता होती है।

आम तौर पर यूवी को शेडर में संशोधित करने का एकमात्र कारण यह है कि आप उन्हें एनिमेटेड चाहते हैं। यदि आप केवल यूवी को स्थिर रूप से बदलना चाहते हैं, तो हमें इस कार्यक्षमता को जोड़ने के लिए शेडर को संशोधित नहीं करना चाहिए।

शेडर का एकमात्र प्रस्तावित परिवर्तन प्रतिस्थापित करना है

vUv = uv * offsetRepeat.zw + offsetRepeat.xy;

साथ

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

ठीक। इसके बारे में कैसे ... हम texture.dynamic ( false डिफ़ॉल्ट रूप से) जोड़ते हैं जो उत्पादन करता है:

vUV = uv;

यदि उपयोगकर्ता texture.dynamic को true तो हम texture.matrix से texture.translation , texture.rotation , texture.scale और texture.center गणना करते हैं

vUv = ( uvTransform * vec3( uv, 1 ) ).xy;

बेशक, अगर texture.dynamic बदलता है तो हमें प्रोग्राम को फिर से कंपाइल करना होगा।

इस तरह हम दोनों दुनिया के सर्वश्रेष्ठ प्राप्त करते हैं?

@mrdoob

1. आपके विचार में, scale बनावट की संपत्ति है या texture.scale सामग्री की संपत्ति है? मुझे आशा है कि यह बाद की बात है, क्योंकि यह धागा इसी के बारे में है।
2. हमें .matrix संपत्ति की आवश्यकता नहीं है। नया Matrix3 एक वर्दी है जो सामग्री वर्दी offsetRepeat को बदल देता है। यह रेंडरर में अन्य मापदंडों से गणना की जाती है और किसी अन्य वर्दी की तरह ही GPU को पास कर दी जाती है।

1. आपके विचार में, scale बनावट की संपत्ति है या texture.scale सामग्री की संपत्ति है? मुझे आशा है कि यह बाद की बात है, क्योंकि यह धागा इसी के बारे में है।

मैं इस धागे से असहमत हूं। मुझे नहीं लगता कि हमें mapMatrix , envMapMatrix , ... और न ही mapTranslation , mapRotation , mapScale से सामग्री को प्रदूषित करना चाहिए। मुझे लगता है कि यह क्लीनर है अगर THREE.Texture में translation , rotation , scale और, शायद center ।

1. हमें .matrix संपत्ति की आवश्यकता नहीं है। नया Matrix3 एक वर्दी है जो सामग्री वर्दी offsetRepeat को बदल देता है। यह रेंडरर में अन्य मापदंडों से गणना की जाती है और किसी अन्य वर्दी की तरह ही GPU को पास कर दी जाती है।

हमें कुछ ऐसा चाहिए। मान लें कि एक ही बनावट को अलग-अलग मानचित्रों में पुन: उपयोग किया जाता है। हम प्रत्येक उदाहरण के लिए Matrix3 गणना नहीं करना चाहते हैं।

मैं इस धागे से असहमत हूं। मुझे नहीं लगता कि हमें mapMatrix, envMapMatrix, ... और न ही mapTranslation, mapRotation, mapScale से सामग्री को प्रदूषित करना चाहिए। मुझे लगता है कि अगर तीन। बनावट में अनुवाद, रोटेशन, स्केल और शायद केंद्र है तो यह क्लीनर है।

क्या बनावट को अभी भी अलग-अलग दोहराने वाले गुणों के लिए क्लोन करने की आवश्यकता होगी? छोटे दृश्यों में यह शायद कोई बड़ी बात नहीं है, लेकिन बड़े दृश्यों में जहां पहले से ही 40+ बनावट हैं, यह एक स्मृति दुःस्वप्न है।

@titansoftime image को THREE.Texture से अलग किया जाना चाहिए। आदर्श रूप से एक एकल THREE.Image का उपयोग अलग-अलग THREE.Texture द्वारा अलग-अलग translation , rotation , ... कॉन्फ़िगरेशन के साथ किया जा सकता है।

@titansofttime छवि को तीन से अलग किया जाना चाहिए। बनावट। आदर्श रूप से एक सिंगल थ्री। इमेज का इस्तेमाल अलग-अलग थ्री द्वारा किया जा सकता है। हर एक को अलग-अलग अनुवाद, रोटेशन, ... कॉन्फ़िगरेशन के साथ टेक्सचर करें।

यह समझ आता है। क्या बनावट। क्लोन () पहले से ही इस तरह से काम करता है, या क्या इसे मैन्युअल रूप से सेट करना होगा?

texture.clone() इस तरह से काम करता है, लेकिन WebGLRenderer यह जानने में असमर्थ है कि छवि वही है इसलिए बनावट अपलोड अनावश्यक है ...

मैं इस धागे से असहमत हूं। मुझे नहीं लगता कि हमें mapMatrix, envMapMatrix, ... और न ही mapTranslation, mapRotation, mapScale से सामग्री को प्रदूषित करना चाहिए। मुझे लगता है कि अगर तीन। बनावट में अनुवाद, रोटेशन, स्केल और शायद केंद्र है तो यह क्लीनर है।

यह मूल रूप से अब हम क्या करते हैं। प्रत्येक बनावट की अपनी offset संपत्ति होती है, और अलग-अलग ऑफ़सेट का सम्मान नहीं किया जाता है - रेंडरर सामग्री के प्रत्येक मानचित्र के लिए समान ऑफ़सेट का उपयोग करता है।

एफडब्ल्यूआईडब्ल्यू, मुझे लगता है कि हमें वह करना चाहिए जो मैंने https://github.com/mrdoob/three.js/issues/5876#issuecomment -69483293 में कहा था।

मैं नहीं देखता कि एपीआई वह करने की अनुमति क्यों नहीं दे सकता जो @jcarpenter करना चाहता है ( alphaMap की ऑफसेट को एनिमेट करें, जबकि map वही रहता है)। कोई कैनवास में ऐसा कर सकता है, लेकिन मुझे लगता है कि इसके बजाय GPU के लिए यह एक कार्य है।

अलग नक्शे के ऑफसेट के साथ खेल offsetting ... से बातें एक कर सकता है की एक टन है alphaMap , केवल स्केलिंग normalMap , आदि

प्रति सामग्री केवल एक uvTransform बहुत सीमित लगता है।

अरे रुको। मुझे लगता है कि मैं समझता हूं कि आप लोग प्रति सामग्री क्यों पसंद करते हैं। इस तरह एक एकल vUv की गणना वर्टेक्स शेडर में की जाती है, बजाय uv प्रति पिक्सेल को फ़्रेग्मेंट शेडर में गणना करने के। सही?

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

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

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

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

अरे रुको। मुझे लगता है कि मैं समझता हूं कि आप लोग प्रति सामग्री क्यों पसंद करते हैं। इस तरह एक एकल vUv की गणना वर्टेक्स शेडर में की जाती है, बजाय uv प्रति पिक्सेल को फ़्रेग्मेंट शेडर में गणना करने के। सही?

नहीं। यूवी की गणना हमेशा की तरह वर्टेक्स शेडर में की जाती है।

एक स्प्राइट शीट और 20 स्प्राइट्स की कल्पना करें। वर्तमान में, हमें 20 क्लोन सामग्री और 20 क्लोन बनावट की आवश्यकता है - जैसे http://threejs.org/examples/misc_ubiquity_test2.html में। (बीटीडब्ल्यू, ध्यान दें कि हमारे पास पहले से ही SpriteMaterial.rotation ।)

सामग्री को ऑफसेट करने के लिए, हमें 20 क्लोन सामग्री और एक बनावट की आवश्यकता होगी।

वास्तव में, ऑफसेट को स्प्राइट में ले जाने के लिए, हमें 1 सामग्री और 1 बनावट की आवश्यकता होगी।

एक स्प्राइट शीट और 20 स्प्राइट्स की कल्पना करें। वर्तमान में, हमें 20 क्लोन सामग्री और 20 क्लोन बनावट की आवश्यकता है

ओह, मैं इस उपयोग के मामले पर विचार नहीं कर रहा था। धन्यवाद!

मैं इस बारे में सोचूंगा...

मैं बनावट में यूवी परिवर्तन की वकालत नहीं करता।

दो कारणों से: (१) यह भ्रमित करने वाला है, (२) प्रचार करने के लिए और भी घटनाएँ हैं, और (२) यह बेकार है।

भ्रम: इसका कारण यह है कि हमारे पास मुख्य मानचित्रों के लिए केवल एक यूवी चर है, लेकिन अगर बनावट में से एक पर यूवी परिवर्तन है, तो यह भ्रमित है कि यह यूवी परिवर्तन उन सभी मानचित्रों पर लागू किया जा सकता है जो पहले यूवी का उपयोग करते हैं चैनल, अन्य बनावट में परिवर्तन है या नहीं। यदि हमने प्रत्येक मानचित्र को सामग्री में अपना स्वयं का यूवी परिवर्तन करने की अनुमति दी है, तो मैं बनावट से जुड़े यूवी परिवर्तन के साथ अधिक ठीक होगा - लेकिन इसके टुकड़े समान उपयोग के कारण ऐसा करना कठिन है।

अधिक घटना प्रचार: दूसरी समस्या जो मैंने Clara.io में देखी, वह है घटना का प्रसार जब बनावट मापदंडों को चेतन करने की कोशिश की जा रही है। प्रत्येक सामग्री का उपयोग करने वाली प्रत्येक सामग्री का ट्रैक रखने के लिए प्रत्येक बनावट की आवश्यकता होती है, और फिर उन सामग्रियों को बताएं कि वे गंदे हैं और उन्हें पुनर्गणना करने की आवश्यकता है। ऐसा करना असंभव नहीं है, बस और काम है।

बेकार: दूसरा मुद्दा यह है कि यदि आपके पास 3D मॉडल या स्पाइट के कई उदाहरण हैं और उन सभी में एक ही एनिमेटेड बनावट है। उस स्थिति में आपको स्मृति में बनावट की अलग-अलग प्रतियां रखनी होंगी ताकि उन्हें अलग-अलग एनिमेटेड किया जा सके - भले ही बनावट डेटा समान हो। सामग्री पर यूवी ट्रांसफॉर्म डेटा डालने की तुलना में यह उस अर्थ में थोड़ा बेकार है।

इस प्रकार यदि हमारे पास प्रति सामग्री केवल यूवी ट्रांसफ़ॉर्म की अनुमति है, तो मैं इसे सामग्री पर ही रखूंगा। मैं यूनिटी ५ मॉडल का अनुसरण करूंगा जहां उनके पास यूवी ऑफसेट है, सामग्री में रोटेशन। गेम डेवलपर्स पहले से ही इस दृष्टिकोण से परिचित हैं।

मुझे लगता है कि सामग्री पर यूवी ट्रांसफॉर्म द्वारा स्प्राइट्स को अच्छी तरह से नियंत्रित किया जाता है - यह उपरोक्त 3 डी मॉडल मामले के समान ही है।

Having only one uvTransform per material seems very very limiting.

यहां पूरी तरह सहमत हैं। इस कार्यक्षमता का न होना अत्यंत सीमित है। ऐसे शानदार प्रभाव हैं जो यहां प्रदान किए जा सकते हैं जो सिर्फ इसलिए नहीं हैं क्योंकि हर ऑफसेट एक साथ बंद है।

लेकिन यह कार्यक्षमता क्लोनों को प्रभावित किए बिना कैसे उपलब्ध कराई जा सकती है?

मुझे लगता है कि बनावट के बजाय सामग्री पर मूल्यों का होना आम उपयोग के मामले के लिए समझ में आता है जहां आप सभी बनावट का मिलान किया जाएगा।

यहां पूरी तरह सहमत हैं। इस कार्यक्षमता का न होना अत्यंत सीमित है। ऐसे शानदार प्रभाव हैं जो यहां प्रदान किए जा सकते हैं जो सिर्फ इसलिए नहीं हैं क्योंकि हर ऑफसेट एक साथ बंद है।

लेकिन यह कार्यक्षमता क्लोनों को प्रभावित किए बिना कैसे उपलब्ध कराई जा सकती है?

THREE.ShaderMaterial या THREE.RawShaderMaterial आपको यह क्षमता देगा, और यह देखते हुए कि यह वर्तमान में नियमित सामग्री के साथ काम नहीं करता है, यह वह मार्ग है जिसका आपको वैसे भी उपयोग करना होगा।

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

इसके लिए +1, दोस्तों।

यह बहुत उपयोगी होगा जब आपके पास एक विशाल स्प्राइट शीट (उर्फ एटलस) हो और आप कई THREE.Sprite उदाहरणों पर इसकी बनावट का पुन: उपयोग करना चाहते हैं।

इस पर कोई भी समाचार? यह समस्या अभी भी एपीआई में एक बहुत ही आकर्षक दोष है। अधिकांश मानचित्र प्रकारों में ऑफ़सेट/रिपीट होते हैं जो अप्रयुक्त होते हैं, और घटना प्रसार एक एनिमेटेड स्प्राइट की तरह एक विमान के रास्ते पर धीमा/स्मृति भारी होने की आवश्यकता से अधिक बनाता है।

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

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

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

इसका समाधान @sunag का NodeMaterial btw है।

इसके लिए अपना +1 भी जोड़ रहे हैं! स्प्राइट शीट के साथ काम करना ज्यादा अच्छा होगा।

: +1: मुझे यह आश्चर्यजनक लगा। मुझे खेल में प्रत्येक स्प्राइट के लिए अपने बनावट को डुप्लिकेट करना शुरू करना पड़ा, क्योंकि मेरे सभी दोहराए गए स्प्राइट एक-दूसरे को एनिमेट कर रहे थे। ऐसा लगता है कि मैं GPU को अनावश्यक स्प्राइट डेटा लोड कर रहा हूं?

क्या किसी के पास इस मुद्दे का कोई समाधान है? क्या टेक्सचर इंटरफेस को दरकिनार करते हुए सीधे शेडर पर वर्दी सेट करके यूवी ऑफसेट में हेरफेर करना संभव हो सकता है?

इसका समाधान @sunag का NodeMaterial btw है।

@bhouston , क्या आप कृपया एक लिंक प्रदान कर सकते हैं? @sunag के खाते में उस नाम का कोई सार्वजनिक भंडार नहीं है।

@ rhys-vdw यह यहाँ केवल देव शाखा में स्थित है:

https://github.com/mrdoob/three.js/tree/dev/examples/js/nodes

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

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

@bhouston मैं नोड के साथ एक उदाहरण बना सकता हूं, यह अच्छा लग रहा है।

उदाहरण के लिए THREE.SpriteMaterial आप spritesheet बनाने के लिए ऑफ़सेट/स्केल का उपयोग कर सकते हैं:

var offsetX = frameX / mapWidth;
var scaleX = mapWidth / frameWidth;

sprite.material.map.offset.x = offsetX;
sprite.material.map.repeat.x = scaleX;

https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/plugins/SpritePlugin.js#L53

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

... इसलिए यह आपको बनावट एक्सेस को मनमाने ढंग से संशोधित करने की सुविधा देगा।

टीबीएच मुझे नहीं पता कि इसका क्या मतलब है। प्रति सामग्री के आधार पर "ऑफ़सेट" और "रिपीट" के लिए अलग-अलग सेट शेडर वर्दी को चेतन करने के लिए।

THREE.SpriteMaterial के बारे में आप उदाहरण के लिए इसके साथ स्प्राइटशीट बनाने के लिए ऑफ़सेट/स्केल का उपयोग कर सकते हैं ...

@ सुनग , शायद मुद्दा स्पष्ट नहीं है। आपके द्वारा साझा किया गया कोड बनावट को बदल देता है, जिसे उस सामग्री के सभी उदाहरणों द्वारा साझा किया जाता है। इसका मतलब यह है कि बनावट को साझा करने वाली दो सामग्रियों का होना असंभव है, लेकिन अद्वितीय ऑफसेट के साथ - उदाहरण के लिए, दो दुश्मन स्प्राइट अलग-अलग एनीमेशन फ्रेम दिखाते हैं।

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

@QuaziKb क्या कोई पीआर है जिसे मैं अपने प्रोजेक्ट के लिए लक्षित कर सकता हूं?

हालांकि यह पूरी बात कोई समस्या नहीं होगी, जैसा कि @WestLangley ने कहा, निम्नलिखित सत्य थे:

यदि हम वर्तमान दृष्टिकोण को बनाए रखते हैं, तो एक चीज जिसे बदलने की जरूरत है, वह यह है कि जब एक बनावट का क्लोन बनाया जाता है, तो साझा की गई छवि को केवल एक बार GPU को पास किया जाना चाहिए।

क्या वो सही है?

@ सुनग , शायद मुद्दा स्पष्ट नहीं है। आपके द्वारा साझा किया गया कोड बनावट को बदल देता है, जिसे उस सामग्री के सभी उदाहरणों द्वारा साझा किया जाता है। इसका मतलब यह है कि बनावट को साझा करने वाली दो सामग्रियों का होना असंभव है, लेकिन अद्वितीय ऑफसेट के साथ - उदाहरण के लिए, दो दुश्मन स्प्राइट अलग-अलग एनीमेशन फ्रेम दिखाते हैं।

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

https://github.com/mrdoob/three.js/issues/7522

लेकिन फिलहाल किसी ने इस तरह यूआईडी को तुरंत चालू करने की कोशिश की :?

THREE.Texture.prototype.createInstance = function() {

    var inst = this.clone();

    inst.uuid = this.uuid;
    inst.version = this.version;

    return inst;

}

यदि आप needsUpdate उपयोग करते हैं तो सभी उदाहरणों को version भी अपडेट करें।

उदाहरण:

var uniqueTextureOffset = map.createInstance();
var material = new THREE.SpriteMaterial( { map: uniqueTextureOffset } );

वही uuid बनाए रखें और version GPU पर texture साझा करेंगे।

https://github.com/mrdoob/three.js/blob/master/src/renderers/WebGLRenderer.js#L2832
https://github.com/mrdoob/three.js/blob/master/src/renderers/webgl/WebGLProperties.js#L11

हालांकि मेरे लिए यह एक अस्थायी समाधान है। मैं भविष्य के लिए NodeMaterial में विश्वास करता हूं।

क्या हम कृपया यूवी ट्रांसफॉर्म को सामग्री में स्थानांतरित कर सकते हैं?

दोनों दुनिया के सर्वश्रेष्ठ के बारे में कैसे। सामग्री पर एक नया uvOffset और सामग्री पर uvRepeat साथ एक ध्वज overrideOffsetRepeat जोड़ें। इस तरह यदि ध्वज झूठा है, तो यह पीछे की ओर संगत है, और यह डिफ़ॉल्ट है। और अगर यह सच है, तो यह सामग्री ऑफसेट/दोहराने का उपयोग करता है। मैं इसका समर्थन करूंगा क्योंकि ऐसा लगता है कि इसकी आवश्यकता तीव्र और व्यापक है। @वेस्टलैंगली? @मरदूब?

(हालांकि मैं वास्तव में आगे बढ़ने वाली हर चीज के लिए NodeMaterial का उपयोग करने का समर्थन करता हूं, लेकिन इसे स्विच करने में दर्द होता है।)

मुझे अभी भी लगता है कि इसका समाधान THREE.Image । https://github.com/mrdoob/three.js/issues/5876#issuecomment -81189892

THREE.Image

@mrdoob , क्या इसका मतलब यह होगा कि प्रत्येक असाइन किए गए Texture को Material के साथ क्लोन किया जाएगा?

@mrdoob ने लिखा:

मुझे अभी भी लगता है कि इसका समाधान तीन बनाना है। छवि

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

मुझे लगता है कि इस समाधान के लिए स्प्राइट्स के एक सेट के लिए दो बार नई वस्तुओं की आवश्यकता होगी - प्रत्येक स्प्राइट के लिए एक बनावट और एक सामग्री? अन्य दृष्टिकोण के लिए प्रत्येक स्प्राइट के लिए सिर्फ एक नई सामग्री की आवश्यकता होगी?

मुझे पता है कि एकता प्रति सामग्री दोहराने/ऑफसेट का समर्थन करती है, लेकिन 3DS मैक्स, माया, सॉफ्टिमेज जैसे उच्च अंत वीएफएक्स उपकरण नहीं करते हैं - उनके पास बस एक बिटमैप नोड और एक बनावट नोड होता है (जिसमें बिटमैप नोड के साथ-साथ यूवी मैपिंग भी शामिल है) nod ), जो

UE4 भी @mrdoob के प्रस्ताव के समान है, उनके पास एक "

उन्नत उपकरण बनावट से छवि/बिटमैप को विभाजित करते हैं और वे इस रूप में एक अलग यूवी मैपिंग नोड भी विभाजित करते हैं:

 -> Bitmap
 -> UVMapping

हम अभी मुख्य StandardMaterial में अधिक UVMapping विकल्पों की अनुमति नहीं देते हैं। लेकिन UE4, माया, सॉफ्टिमेज, 3DS मैक्स में उपयोग किए जाने वाले विभिन्न प्रकार के UVMappings, किस चैनल का उपयोग करना है, इसे लागू करने के लिए एक परिवर्तन, स्रोत के रूप में विश्व निर्देशांक का उपयोग करने के लिए, या यदि किसी को गोलाकार, घन, समतलीय प्रक्षेपण करना चाहिए उन अनुमानों के लिए आवश्यक मापदंडों के आधार पर।

UE4 में एक स्प्राइट बनावट है जो सामग्री के भीतर दोहराने/ऑफ़सेट करने की अनुमति देती है:

https://docs.unrealengine.com/latest/INT/Engine/Paper2D/Sprites/index.html

माया, सॉफ्टिमेज, 3डीएस मैक्स और यूई4 में बिटमैप/इमेज को टेक्सचर (और यूवी जेनरेशन से) से @mrdoob सुझाव दे रहा है, लेकिन वे सभी इसे प्राप्त करने के लिए शेडर ग्राफ़ का भी उपयोग करते हैं। यूनिटी 3 डी, जिसमें शेडर ग्राफ नहीं है, वह उपकरण है जो सामग्री में ऑफसेट/रिपीट को शामिल करता है, शायद इसलिए कि यह इसे एक शेडर ग्राफ नोड में ठीक से अलग नहीं कर सकता है।

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

बिल्कुल

शायद उल्लेख करने के लिए जगह से थोड़ा सा है लेकिन मैं पीटीईएक्स को जल्द से जल्द शामिल करने की सिफारिश करना चाहता हूं।
http://ptex.us/PtexFile.html
यदि ठेठ अनुमानों आदि को NodeTexture (?) में बदलने/बदलने का कोई तरीका है या विकल्प जो एक नया अधिक शक्तिशाली और व्यापक आधार स्तर बनावट मानचित्रण प्रणाली है? ... ठीक है, तो शायद यह समय से पहले विचार करने वाली बात है।
[आगे उसी बिंदु पर:]
पीटेक्स के साथ अवधारणा इसकी वास्तव में एक 2 डी छवि नहीं है बल्कि एक यूवी संबंध है ताकि आप 2 डी से 3 डी का अनुवाद करने की अवधारणा/चुनौती के बिना एक जटिल सतह के चारों ओर पेंट/स्टैम्प/प्रोजेक्ट कर सकें, जो गणितीय रूप से तुलना में सबसे अच्छा हैक है ( हमेशा तकनीकी रूप से विनाश से जूझ रहा है)।
मैं सिर्फ यह इंगित करता हूं कि पीटीएक्स को अधिक समझ में आना चाहिए था और 20+ साल पहले प्राथमिकता होनी चाहिए थी और इसे विस्तार या द्वितीय श्रेणी के कलाकार नहीं माना जाना चाहिए, लेकिन वास्तव में मेरे लिए यह दूसरी तरफ है। यह घोषणात्मक रूप से यह कहने का पुराना मूल तरीका होना चाहिए कि कैसे एक 2d छवि को ptex के एक सच्चे हमेशा काम करने वाले बेस लेवल सिस्टम में प्रोजेक्ट/स्टैम्प किया जाता है। वैसे भी सिर्फ इस विचार को लागू करने के लिए इसे एकीकृत किया जाना चाहिए यदि अधिक केंद्रीय रोल लेने के लिए सबसे अच्छा नहीं है।
ऊँचे-ऊँचे सुझाव देने के अवसर के लिए धन्यवाद। मैं बहुत खुश था कि पीटेक्स को एक कल्पना के लिए बनाया गया था। मैंने खुद इसके बारे में १०+ साल पहले सोचा था, लेकिन एक बच्चे के रूप में नए चश्मे आदि को परिभाषित करने की कोई शक्ति नहीं थी। पिछली बार मुझे यह देखना चाहिए था कि शायद मैं पर्यवेक्षक के रोल के बजाय एक अंतर बनाने की कोशिश कर सकता था जो मैं अभी भी बनाए रखता हूं। तो यहां एक लंबे समय से चली आ रही गलत को पूर्ववत करने का प्रयास है।

हो सकता है कि कोई व्यक्ति एक नया सूत्र शुरू कर सकता है यदि फ्लक्स में संभावित रूप से मौजूदा तरीकों की गहरी समझ रखने वाला कोई भी व्यक्ति इस बारे में अधिक लागू प्रस्ताव दे सकता है कि यह थ्रीजे में कैसे काम करेगा।
सुने जाने के अवसर के लिए फिर से धन्यवाद।

@MasterJames ऑफ-टॉपिक... कृपया एक नया सूत्र बनाएं?

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

@QuaziKb हां। यही NodeMaterial निपटता है।

क्या ऐसा नहीं है कि Texture प्रत्येक .clone() लिए एक ही OpenGL बनावट उदाहरण का उपयोग करता है, या क्या मुझे कुछ याद आ रहा है। क्या यह वास्तव में प्रत्येक क्लोन के लिए इसे पुनः अपलोड कर रहा है? अगर ऐसा है, तो यह एक _बहुत_गंभीर मुद्दा है।

@evrimoztamur , मेरा मानना ​​​​है कि यह हर बार बनावट की नकल करता है। आप देख सकते हैं कि WebGL इंस्पेक्टर का उपयोग करके क्या हो रहा है।

मैंने हर उस दृष्टिकोण की कोशिश की जिसके बारे में मैं सोच सकता था, जिसमें @sunag का समाधान भी शामिल है , लेकिन कुछ भी काम नहीं किया। मेरे प्रयोग के परिणाम नहीं देने के आधार पर, और ऊपर की चर्चा के आधार पर, मैंने यह देखा कि अन्य पुस्तकालय स्प्राइट एनीमेशन को कैसे संभालते हैं। मैं Babylon.js के पाया स्प्राइट और SpriteManager एपीआई कि मेरे विशेष जरूरतों को पूरा करता एक समाधान हो सकता है। यह स्प्राइट शीट, ऑफसेट और रिपीट, और एनिमेशन को संभालता है। हो सकता है कि यह थ्री.जेएस प्रदान करने के लक्ष्य की तुलना में उच्च स्तर का अमूर्तन है, लेकिन एक संदर्भ के रूप में देखने लायक हो सकता है।

@ rhys-vdw: एक वर्तमान परियोजना के लिए मैं MeshBasicMaterial के एक कमीने संस्करण के साथ समाप्त हुआ:
https://gist.github.com/karimbeyrouti/790d2e1a8c0137b16bae

जब आप मानचित्र सेट करते हैं, तो यह स्वचालित रूप से ऑफ़सेट/रिपीट यूनिफ़ॉर्म असाइन करता है (जो टक दूर सामग्री में होते हैं)। आप उन्हें आसानी से अलग से सेट कर सकते हैं - इससे आपको अभी के लिए बनावट को क्लोन करने की आवश्यकता नहीं होगी। (r73 के साथ काम करना)

मैंने अभी एक पीआर सबमिट किया है जो इस मुद्दे को संबोधित करेगा, पीआर #8278

@WestLangley ने लिखा:

मेरा मानना ​​​​है कि यह मान लेना उचित है कि निम्नलिखित मानचित्रों में समान ऑफसेट/दोहराव मान हैं:

नक्शा
स्पेक्युलर मैप
सामान्य नक्शा
नक्शा टक्कर
अल्फा मैप
एओमैप (भविष्य)
ग्लोस मैप (भविष्य)
विस्थापनमानचित्र (भविष्य)

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

संपादित करें: ठीक है, कम से कम यही मैंने सोचा था कि मैंने किया था। चाल को शायद नजरअंदाज कर दिया गया था। और मैं शेडर या कुछ में शोर जोड़कर समान परिणाम प्राप्त कर सकता हूं। WestLangley का Matrix3 डेमो अच्छा है।

मुझे लगता है कि यह स्प्राइट में विभिन्न यूवी के साथ उदाहरणों की समस्या को हल करता है। समान बनावट को बनाए रखते हुए vertex और pixel shader संशोधित करना संभव है।

https://threejs.org/examples/#webgl_sprites_nodes

यह एक साझा PlaneBufferGeometry साथ SpriteNodeMaterial और Mesh PlaneBufferGeometry । इंटरफ़ेस Sprite लिए उपयुक्त नहीं है लेकिन काम करता है। इंटरफ़ेस को अधिक अनुकूल बनाने के लिए शायद यह SpriteMesh तक विकसित हो सकता है

यह धागा मेरे लिए टीएल; डीआर है। लेकिन मैंने अभी इस कोड को r68 (पुरानी परियोजना, हाँ) में खोजा है:

        // uv repeat and offset setting priorities
        //  1. color map
        //  2. specular map
        //  3. normal map
        //  4. bump map
        //  5. alpha map

        var uvScaleMap;

        if ( material.map ) {

            uvScaleMap = material.map;

        } else if ( material.specularMap ) {

            uvScaleMap = material.specularMap;

        } else if ( material.normalMap ) {

            uvScaleMap = material.normalMap;

        } else if ( material.bumpMap ) {

            uvScaleMap = material.bumpMap;

        } else if ( material.alphaMap ) {

            uvScaleMap = material.alphaMap;

        }

        if ( uvScaleMap !== undefined ) {

            var offset = uvScaleMap.offset;
            var repeat = uvScaleMap.repeat;

            uniforms.offsetRepeat.value.set( offset.x, offset.y, repeat.x, repeat.y );

        }

इसलिए...

यदि आप पुस्तकालय में एक मौलिक परिवर्तन का प्रस्ताव करने जा रहे हैं, जैसे कि आपने यहाँ प्रस्तावित किया है, तो आपको उस परिवर्तन के लिए एक स्पष्ट और सम्मोहक तर्क देना होगा।

मैं फैलाने वाले और सामान्य मानचित्रों पर अलग-अलग दोहराने की कोशिश कर रहा था और अपने बालों को खींच रहा था क्योंकि यह काम नहीं कर रहा था। चूंकि एपीआई इस सेटिंग को बनावट में रखता है, मैंने सोचा कि मैं ऐसा कर सकता हूं। तो हाँ, सम्मोहक तर्क के लिए मेरे बालों को बचाने के बारे में क्या? यह टिकट अभी भी खुला है, 3js में अभी भी बनावट पर यह सेटिंग है, और यह केवल एक बनावट के लिए सम्मानित है = यह वास्तव में, पहले से ही प्रति-सामग्री सेटिंग है।

यदि आप इसे उस स्थान पर नहीं ले जा रहे हैं जहां यह संबंधित है, तो कम से कम यह कहें कि दस्तावेज़ों में इसका कोई प्रभाव नहीं पड़ता है?

@सुनाग पीआर के लिए:
https://github.com/mrdoob/three.js/pull/11531

एक मुद्दा जिसमें मैं भाग गया:
https://jsfiddle.net/f0j2v3s8/

ऐसा लगता है कि SpriteNodeMaterial पारदर्शिता खो गई है, इस उदाहरण को काम करने के लिए सम्मिश्रण का कोई संयोजन नहीं है जिसका उपयोग मैं कर सकता हूं।

कोई विचार?

@karimbeyrouti ने लिखा:

जब आप मानचित्र सेट करते हैं, तो यह स्वचालित रूप से ऑफ़सेट/रिपीट यूनिफ़ॉर्म असाइन करता है (जो टक दूर सामग्री में होते हैं)। आप उन्हें आसानी से अलग से सेट कर सकते हैं - इससे आपको अभी के लिए बनावट को क्लोन करने की आवश्यकता नहीं होगी। (r73 के साथ काम करना)

मेरा मानना ​​है कि यह अप्रचलित है क्योंकि uniforms.offsetRepeat को uniforms.uvTransform (r88) में बदल दिया गया है।

'एकाधिक ऑब्जेक्ट 3 डी उदाहरणों के साथ एक बनावट एटलस का पुन: उपयोग' मामले के संबंध में, मैं एक साधारण चलने का सुझाव देता हूं:

1. UVs डेटा (ऑफ़सेट, रिपीट) को एक एटलस जोंस ऑब्जेक्ट में स्टोर करें;
2. Object3D की onBeforeRender\onAfterRender फ़ंक्शन जोड़ी को हुक करें;
3. पहले रेंडर कॉलबैक में, एटलस जोंस ऑब्जेक्ट से यूवी डेटा लोड करें और मटेरियल.मैप पर सेट करें;
4. कॉलबैक रेंडर करने के बाद, इसे वापस रीसेट करें;

इसका परिणाम होगा:

1. एकाधिक वस्तुओं द्वारा साझा केवल एक बनावट और एक सामग्री, किसी क्लोन की आवश्यकता नहीं है और info.memory.textures काउंटर में वृद्धि नहीं होगी;
2. लेकिन फिर भी अन्य सभी मानचित्रों (सामान्य, एओ, विस्थापन...) को उसी यूवी अनुवाद का पालन करना चाहिए;