Three.js: WebGL2रेंडरर

बहुत अच्छा। :) मैं वास्तव में थोड़ा चिंतित था कि वेबजीएल 2 और 1 की जटिलता को कैसे संभाला जाए।

यूबीओ का उपयोग करना पसंद करना बहुत अच्छा होगा। :) और मैं केवल BufferGeometry का समर्थन करने वाले विचार से प्यार करता हूं - जो चीजों को काफी सरल बनाना चाहिए।

यह ज्यादातर समान शेडर्स का समर्थन करने के लिए अच्छा होगा, हालांकि अगर हम आगे प्रतिपादन के साथ चिपके रहते हैं (जो ऐसा लगता है कि यूई 4 वीआर के लिए गति के लिए क्या कर रहा है।) मुझे लगता है कि हम इसे स्विंग कर सकते हैं? तुम क्या सोचते हो?

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

@mrdoob हिप हिप हुर्रे! और यह सुनकर बहुत अच्छा लगा कि BufferGeometry का विशेष रूप से उपयोग किया जाएगा। मैं

मैं यूबीओ को तरजीह देने के @bhouston के सुझाव को दूसरा मानता हूं।

क्या यह भी संभव होगा कि रेंडरर से लाइटिंग और शैडो हैंडलिंग को पूरी तरह से डिकूप किया जाए? डिफ़ॉल्ट वास्तव में आसान हैं, लेकिन जब आप प्रकाश और छाया तर्क पर पूर्ण नियंत्रण चाहते हैं, तो WebGLRenderer और सह। ऐसा महसूस करें कि उन्होंने लड़ाई लड़ी है।

और जब मैं विशलिस्ट-वाई प्रकार की वस्तुओं को सूचीबद्ध कर रहा हूं, तो क्या एल्गोरिदम को 'प्लग करने योग्य' बनाया जा सकता है? मेरे पास छँटाई की ज़रूरतें हैं जो तीन के दायरे से बाहर हैं, और मौजूदा WebGLRenderer में छँटाई कार्यों को ओवरराइड करना अनावश्यक रूप से कठिन लगता है। रेंडरर ऑब्जेक्ट बनाते समय शायद यह एक वैकल्पिक सेटिंग हो सकती है?

मुझे लगभग आश्चर्य होता है कि क्या किसी को केवल WebGLRenderer 1 को संशोधित करना चाहिए और BufferGeometry ऑब्जेक्ट्स के अलावा किसी भी चीज़ के लिए समर्थन हटा देना चाहिए। यह आगे बढ़ने का एक आसान तरीका हो सकता है। यदि ज्यामिति को बफ़रज्यामिति में परिवर्तित करने के लिए एक सरल कार्य है जो लोगों को कॉल करने के लिए मजबूर करता है ...

मुझे लगता है कि मैं ऐसा इसलिए कह रहा हूं क्योंकि मैं WebGLRenderer और WebGLRenderer2 के बीच फीचर समानता बनाए रखने की कोशिश करने के बारे में चिंतित हूं। समानांतर में दो को बनाए रखने के बजाय एकल कोड आधार विकसित करना आसान है।

मुझे लगभग आश्चर्य होता है कि क्या किसी को केवल WebGLRenderer 1 को संशोधित करना चाहिए और BufferGeometry ऑब्जेक्ट्स के अलावा किसी भी चीज़ के लिए समर्थन हटा देना चाहिए। यह आगे बढ़ने का एक आसान तरीका हो सकता है। यदि ज्यामिति को बफ़रज्यामिति में परिवर्तित करने के लिए एक सरल कार्य है जो लोगों को कॉल करने के लिए मजबूर करता है ...

ऐसा एक समारोह पहले से ही है। लेकिन इतना आसान भी नहीं है...

मुझे लगता है कि खरोंच से WebGLRenderer2 बनाना बेहतर है ताकि हम एपीआई और समर्थित सुविधाओं पर पुनर्विचार कर सकें।

Firefox 51 में अब WebGL 2 समर्थन है: https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

इसके लिए इंतजार नहीं कर सकता!

वेबजीएल 2.0 का समर्थन करने वाला क्रोम 56 जारी किया गया था!
https://developers.google.com/web/updates/2017/01/nic56

WebGLRenderer2 आगे बढ़ने का अच्छा समय है? एक्सडी

क्या हमें एक WebGLDeferredRenderer2 भी बनाना चाहिए?

अगले सप्ताह यह सब देखना शुरू करने की योजना है! ️

किसी भी मौके पर आपके पास इसे देखने के लिए पहले से ही कुछ समय था! बहुत आगे देख रहे हैं! (3डी बनावट)

@mrdoob
कोई सुधार?
अगर आपको कुछ चिंता है, तो कृपया हमारे साथ साझा करें!
हम चर्चा और मदद कर सकते हैं; डी

अभी समय नहीं हुआ है। जल्दी जल्दी! मैं

https://blog.chromium.org/2017/03/faster-3d-rendering-with-webgl-20.html

कोई सुधार? मुझे विशेष रूप से कुछ चिकित्सा छवियों को प्रस्तुत करने के लिए 3D बनावट में दिलचस्पी है। मैं इस पुल अनुरोध को सफल बनाने में मदद करने के लिए भी तैयार हूं।

वर्तमान तीन.js webgl2 सैंडबॉक्स काम नहीं करता :( https://threejs.org/examples/webgl2_sandbox.html
एक तीन.जेएस संस्करण निर्माण मुद्दा हो सकता है?

यदि ऑनलाइन <script type="module"> पहले ही लागू कर दिया गया होता...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYYPBAAJ

कम से कम Mozilla इस पर काम कर रही है https://bugzilla.mozilla.org/show_bug.cgi?id=1240072

@mrdoob , क्या इसका मतलब यह है कि WebGL 2.0 में अपडेट होने पर हम 3.js API से <script type="module"> का लाभ उठाने की उम्मीद कर सकते हैं? ;)

बीटीडब्ल्यू मुझे लगता है कि वेबजीएल 2.0 समर्थन को वेबजीएलआरेंडरर में जोड़ने के लिए औसत समय में यह सबसे आसान है। मुझे लगता है कि यह वृद्धिशील अपनाने की अनुमति देगा और हम यह देखने के लिए फीचर डिटेक्शन कर सकते हैं कि क्या हम WebGL 2 सुविधाओं का उपयोग कर सकते हैं। मुझे नहीं लगता कि यह करना सबसे कठिन काम है। मुझे पता है कि यह शुद्ध वेबजीएल 2 रेंडरर के विपरीत थोड़ी जटिलता की ओर जाता है, लेकिन यह निकट और मध्यम अवधि में सबसे आसान रास्ता है। और हम धीरे-धीरे विकसित होते हैं जहां हम अंततः वेबजीएल 1 को पीछे छोड़ देते हैं जब वेबजीएल 2 के 90% से अधिक अंगीकरण हो जाता है।

ख्रोनोस ने अभी webgl2 पर एक वेबिनार किया था:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide =id.gd15060520_0_38
मीडिया शीघ्र ही बाहर हो जाएगा, लेकिन प्रस्तुति मुख्य रूप से स्लाइड्स के वॉयस-ओवर और स्लाइड्स में संबंधित डेमो थी।

यह बिल्कुल स्पष्ट है कि इसके लिए एक नई शुरुआत की आवश्यकता है, न कि मौजूदा WebGLRenderer से "अपडेट" करने की।

ईएस 6 मॉड्यूल के संदर्भ में, मुझे लगता है कि स्रोत का वर्तमान दृष्टिकोण ईएस 6 मॉड्यूल है, फिर बंडल के लिए रोलअप का उपयोग करना अभी भी "दोहरी निर्माण" का समर्थन करने का तरीका है।

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

@bhouston आकर्षक ...

नवीनतम स्थिति?

मुझे इसके बारे में किसी तरह मिश्रित भावना मिली है। प्रारंभ में मैं उसी रास्ते के बारे में सोच रहा था जैसा कि @bhouston ने प्रस्तावित किया था, वर्तमान में webgl2 सुविधाओं को वर्तमान WebGLRenderer में जोड़ते हुए। लेकिन यह रेंडरर को उन विशेषताओं से निपटने के लिए अधिक जटिल और कठिन बना देगा जो शाखाओं और स्थिति जांच से भरे एक गन्दा कोड के साथ समाप्त होने वाले दो संस्करणों के बीच सबसे अलग हैं।
एक विकल्प WebGLRenderer को WebGL2Renderer के शुरुआती बिंदु के रूप में क्लोन करना और मूल रेंडरर के साथ खिलवाड़ किए बिना सुविधाओं को हटाना/जोड़ना जारी रखना हो सकता है।
यदि हम Playcanvas जैसे इंजनों पर एक नज़र डालें, जो संभवत: सबसे पुराने webgl2 समर्थन वाला इंजन है, तो हम देख सकते हैं कि यह UBO या VAO जैसी नई webgl2 सुविधाओं का लाभ भी नहीं उठाता है क्योंकि यह कुछ ऐसा है जो संशोधित करेगा इंजन के कई हिस्से।

मेरा दृढ़ विश्वास है कि यदि हम एक ही रेंडरर पर दोनों संस्करणों को मिलाने का प्रयास करते हैं तो हम कोड को बनाए रखने के लिए कठिन हो जाएंगे और जैसे ही webgl2 को पूरी तरह से समर्थन मिलेगा, हमें वैसे भी इसे दोबारा करने की आवश्यकता होगी जैसा कि मुझे लगता है कि हम होंगे उस संगतता को बनाए रखने के लिए एक डिज़ाइन का पालन करने के लिए मजबूर किया गया, बजाय इसे वेबग्ल 2 को ध्यान में रखते हुए स्क्रैच से डिज़ाइन करने के लिए।

तो मेरा वोट WebGL2Renderer से शुरू करना है, भले ही हम धीमी गति से आगे बढ़ें (हमारे पास अभी भी सुधार की गुंजाइश है जब तक कि webgl2 को वहां से लगभग 100% समर्थन नहीं मिल जाता)।

केवल रेंडरर के अलावा कुछ फ़ाइलों को संशोधित किया जाना चाहिए, उदाहरण के लिए बनावट, प्रोग्राम इत्यादि। क्या हमें renderer\webgl2 सबफ़ोल्डर बनाना चाहिए और उन फ़ाइलों को जोड़ना जारी रखना चाहिए जो विशेष रूप से उस रेंडरर के लिए बनाई जाएंगी?

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

इसके विकास पर कोई अपडेट?

अभी नहीं। मैं इस महीने वेबवीआर को प्राथमिकता दे रहा था।

जैसा कि ऊपर @fernandojsg द्वारा सुझाया गया है, मैंने WebGL2 और ES3 शेडर भाषा में एक त्वरित 'इन-प्लेस रूपांतरण' की कोशिश की। यहाँ स्क्वैश डिफ है: https://github.com/tstanev/three.js/compare/master...ttanev :traian/webgl2 असल में, यह लगभग उतना बुरा नहीं दिखता जितना मैंने शुरू में उम्मीद की थी। यह लगभग ऐसा लग रहा है कि कुछ रणनीतिक रूप से रखे गए ifdefs के माध्यम से दोनों का समर्थन करना बहुत बदसूरत नहीं होगा।
[संपादित करें: अद्यतन लिंक।]

@tstanev क्या आपके पास एक कामकाजी उदाहरण है?

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

@tstanev webgl2 परिवर्तनों के लिए प्रदर्शन की तुलना ऑनलाइन करने के बारे में क्या?) इसे देखना अच्छा होगा। (webgl2 पर तीन.जेएस बनाम तीन.जेएस)

नमस्ते
इस बेहतरीन विचार के लिए धन्यवाद।
मैं अपने प्रोग्राम में webgl2renderer का उपयोग करना चाहता हूं, लेकिन मैं इसे प्रीकंपाइल संस्करण (r86) में उपयोग नहीं कर सका, इसलिए मुझे स्रोत मिलता है और webgl2renderer को तीन.js आयात में अनसुना कर देता है और फिर इसे बनाता है।
अब मेरा कोड और आपका उदाहरण (webgl2-sandbox) बिना किसी त्रुटि के चलेगा लेकिन वे कुछ भी नहीं दिखाते हैं

संपादित करें: मैंने उन्हें फ़ायरफ़ॉक्स 54 और क्रोम 60 में परीक्षण किया था
मेरा उदाहरण bufferGeometry और ShaderMaterial का उपयोग करके और webglrenderer में सही ढंग से काम करेगा

कोई मुझे जवाब नहीं देता? अब webgl2renderer की समस्या क्या है?

@ MHA15 संभवतः इसे बिल्ड में शामिल नहीं किया गया है क्योंकि यह अभी तक उत्पादन के लिए तैयार नहीं है।

अरे दोस्तों, WebGL2Renderer का विकास कैसा चल रहा है?
मुझे पता है कि इसे खरोंच से फिर से बनाने का निर्णय लिया गया था। लेकिन यह कुछ समय हो गया है और इस विषय पर विकास धीमा है क्योंकि मुझे विश्वास है कि इसे फिर से बनाने के लिए यह एक बड़ी मात्रा में काम है।

इस बिंदु पर, क्या हम WebGLRenderer का क्लोन बनाने पर पुनर्विचार कर सकते हैं और इसे WebGL2 में बदल सकते हैं, जैसा कि @mattdesl ने https://github.com/mrdoob/three.js/issues/8125 में किया था ?? फिर हम यूबीओ जैसी कुछ नई सुविधाओं के आधार पर रेंडरर को संशोधित कर सकते हैं जैसा @fernandojsg ने कहा। आखिरकार, हम उन सभी webgl 1 लीगेसी कोड को हटा देंगे।

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

मेरी राय में, स्क्रैच से रेंडरर बनाने के लिए बड़ी मात्रा में काम की आवश्यकता होती है और आदर्श रूप से यह केवल कुछ योगदानकर्ताओं के साथ ही शुरू हो सकता है।

कि यह सच है। लेकिन फिर भी, मुझे लगता है कि हर जगह सशर्त जोड़कर WebGLRenderer को बनाए रखना कठिन बनाने से आसान है। मैंने अपने पिछले 5 वर्षों में से अधिकांश को पढ़ने और बनाए रखने के लिए WebGLRenderer को आसान बनाने की कोशिश में बिताया है।

साथ ही, मुझे लगता है कि @fernandojsg आने वाले हफ्तों में इसे शुरू करने की योजना बना रहा था।

वह तो कमाल है। @fernandojsg के बेहतरीन काम की प्रतीक्षा में !!

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

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

जबकि हम इस पर हैं... 5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc
webgl2_sandbox फिर से काम करता है (हालांकि es6 मॉड्यूल की आवश्यकता है)।

@mrdoob क्या आपके पास कोई मोटा अनुमान है कि यह मास्टर/रिलीज़ में कब उपलब्ध होगा? :) मुझे खुशी है कि यह हो रहा है! :)

@wdanilo वास्तव में नहीं... WebGL2 से आपको किन विशेषताओं की आवश्यकता है?

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

@mrdoob glsl में flat जैसे नए कीवर्ड भी बहुत मददगार होंगे।

मेरी परियोजना को 3D बनावट की आवश्यकता है।

दिलचस्प...
उन विशिष्ट मामलों के बारे में जागरूक होने के लिए बहुत उपयोगी है जिनके लिए लोगों को WebGL 2.0 की आवश्यकता होती है।
उन्हें आने दो!

3डी टेक्सचर्स भी हमारे लिए एक बड़ी विशेषता है। मुझे लगता है कि हम कुछ शेडर सुविधाओं का भी उपयोग करते हैं।

कभी-कभी मुझे MRT चाहिए

एकाधिक रेंडर लक्ष्यों के लिए +1 भी

एक एक्सटेंशन के माध्यम से WebGL1 में पहले से ही एकाधिक रेंडर लक्ष्य समर्थित हैं, और थ्रीजेएस में इसके लिए एक पीआर भी है: https://github.com/mrdoob/three.js/pull/9358 ( डेमो )।

मुझे लगता है कि मल्टीसैंपल रेंडर टारगेट मेरी पसंदीदा विशेषता है। अधिकांश ग्राहक पोस्ट-प्रोसेसिंग (ब्लूम, एलयूटी, आदि) का अनुरोध करते हैं, लेकिन एफएक्स के लागू होने के बाद उचित एंटी-अलियासिंग की कमी से वे निराश हैं। MSAA लक्ष्य प्रस्तुत करने के साथ हम अंत में एक अच्छी तरह से एंटी-अलियास _and_ पोस्ट-प्रोसेस्ड दृश्य प्राप्त कर सकते हैं।

मैं सहमत हूँ। प्रभाव कंपोज़र के साथ पोस्ट प्रोसेस्ड दृश्यों पर एंटी एलियासिंग के लिए वर्कअराउंड शेडर्स सच्चे एंटी एलियासिंग के लिए पर्याप्त नहीं हैं।

ड्रा फीडबैक के लिए +1। या यह पहले से ही webgl1 एक्सटेंशन के रूप में समर्थित है
तीन?

गुरु, 14 दिसंबर, 2017 को रात 9:45 बजे काइल नोटिफिकेशन @github.com ने लिखा:

मैं सहमत हूँ। पोस्ट प्रोसेस्ड दृश्यों पर एंटी एलियासिंग के लिए वर्कअराउंड शेडर
प्रभाव के साथ संगीतकार सच्चे एंटी एलियासिंग के लिए पर्याप्त नहीं है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

मेरे पास यहां कुछ उपयोग के मामले हैं:

1. मुझे एमआरटी की आवश्यकता है - वर्तमान में मैं एक ही शेडर को 4 या 5 बार प्रस्तुत कर रहा हूं, केवल अलग-अलग बफर प्राप्त करने के लिए एक विशेषता बदल रहा हूं।
2. एंटीएलियासिंग के साथ बनावट को प्रस्तुत करना हमारे लिए एक महत्वपूर्ण विशेषता है - हम विज़ुअलाइज़ेशन पूर्वावलोकन के साथ एक "नोड संपादक" बनाते हैं। प्रत्येक विज़ुअलाइज़ेशन केवल एक बनावट है जिसे हम कुछ भी आकर्षित करते हैं और यहां कोई उचित एंटीअलाइजिंग दर्द नहीं है।
3. "फ्लैट" कीवर्ड - अब मैं एक फ्लोट विशेषता के साथ ज्यामिति को अनुक्रमित कर रहा हूं, जो स्पष्ट रूप से उप-इष्टतम है - यूंट वन के साथ अनुक्रमण से भी बदतर। मैं इस विशेषता को वर्टेक्स से फ्रैगमेंट शेडर में पास कर रहा हूं और अब मैं यूंट का उपयोग नहीं कर सकता, क्योंकि हमारे पास "फ्लैट" kwrd के समर्थन की कमी है।
4. (छोटे) 3D बनावट उच्च अंत विज़ुअलाइज़ेशन के लिए बहुत अच्छे हैं जिन्हें हम निकट भविष्य में समर्थन देना चाहेंगे।

मेरे लिए एंटी-अलियासिंग और पोस्ट-प्रोसेसिंग का एक साथ उपयोग करना सबसे महत्वपूर्ण है।

@mrdoob मेरी शीर्ष 3 WebGL 2 विशेषताएं/उपयोग के मामले (महत्व के क्रम में):

1. बहु-नमूना रेंडर लक्ष्य: पोस्ट-प्रोसेसिंग में उचित (MS) AA के लिए।
2. पूर्णांक बनावट: छवि आधारित एल्गोरिदम जैसे हस्ताक्षरित दूरी फ़ील्ड, साथ ही डीईएम (डिजिटल एलिवेशन मॉडल) जैसे अधिक विदेशी बनावट आधारित डेटा का उपयोग करने के लिए।
3. ट्रांसफॉर्म फीडबैक: पार्टिकल सिस्टम करने के लिए।

@mrdoob वैसे, क्या आप जानते हैं कि #9358 PR का विलय क्यों नहीं किया गया? जैसा कि @mattalat ने लिखा है, यह तीनjs के लिए मल्टीटार्गेट रेंडरिंग लाता है। 2 साल पहले प्रतिबद्ध किया गया था, अन्य परिवर्तनों के साथ अद्यतित रहने के लिए कई बार तय किया गया था और अब तक यह वहां नहीं है :(

मैं इसके बारे में पूछ रहा हूं क्योंकि मुझे एसडीएफ आकार के विवरण का उपयोग करते हुए एक दृश्य मिला है। प्रत्येक आकार 6 अलग-अलग आउटपुट का उत्पादन करता है, इसलिए अब मैं इसे 0 से 5 तक के शेडर नंबरों के लिए 6 बार गणना करता हूं। यह मल्टीपल आउटपुट का उपयोग करने के लिए बहुत अच्छा होगा और यह केवल 5x प्रदर्शन को बढ़ावा देगा।

@wdanilo शायद यह सही समय नहीं था (उस समय रेंडरर में कई चलती चीजें)। साथ ही, ऐसा लगता है कि इसमें ऐसे निर्माण शामिल हैं जो आसानी से संघर्ष का कारण बनते हैं। कोई नया पीआर करने के लिए तैयार है?

/सीसी @edankwan

हमें 3D टेक्सचर और मल्टीसैंपल रेंडर लक्ष्य चाहिए।

मैं इसका उपयोग करना चाहता हूं इसलिए मैं गहराई से सेट कर सकता हूं। टाइप = तीन। फ्लोट टाइप .. जब तक कि वर्तमान में ऐसा करने का कोई और तरीका न हो।

क्या कोई उम्मीद है कि 1 के अलावा लाइनथिकनेस विंडोज और वेबजीएल 2.0 पर काम कर रही होगी? यदि हां, तो यह हमारे कुछ आउटपुट में सुधार करेगा।

और यहां मैं खुद को जवाब देता हूं। SO पर थिक-ऑफ-लाइन्स-यूजिंग-थ्री-लाइनबेसिक मटेरियल को पढ़ना मैं समझ गया कि मोटी लाइनों को भविष्य में वैसे भी एक ज्योमेट्री की आवश्यकता होगी।

@ Richard004 इसका WebGL 2 से कोई लेना-देना नहीं है। इस सुविधा अनुरोध के लिए हमारे पास पहले से ही एक PR है, देखें #11349

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

दूसरा, मुझे लगता है कि बहुत से डेवलपर्स इससे लाभ उठा सकते हैं: यानी, एक चर के साथ एक सरणी तत्व तक पहुंचना। वर्तमान में WebGL 1.0 (GLSL) में, इस तरह का प्रोग्राम विफल हो जाएगा:

int myData[200];
int x = 3; // 'x' might change later based on my lookup needs
int requestedData = myData[x];

हालांकि वेबजीएल 2.0 में, आप ऐसा कर सकते हैं। लूप के अंदर अक्सर इसकी आवश्यकता होती है, जहां आपको किसी सरणी से अलग-अलग मान प्राप्त करने की आवश्यकता होती है, लेकिन आप केवल एक पुनरावृत्त लूप नहीं कर सकते हैं (उदाहरण के लिए उपरोक्त उदाहरण में 0 से 199), क्योंकि तब आपको प्रत्येक की जांच करने की आवश्यकता होगी एकल तत्व और वह वास्तव में धीमा है।

पोस्टप्रोसेसिंग में एंटीएलियासिंग निश्चित रूप से फायदेमंद होगा।

इस सब के तहत सवाल है: क्या यह तीन के लिए एक नई वास्तुकला का समय है?

मैंने हाल ही में D3, संस्करण 4 का उपयोग करना शुरू किया है। यह एक पूर्ण रीडिज़ाइन था। ईएस6
मॉड्यूल। और कहीं अधिक महत्वपूर्ण, 30 मॉड्यूल, जिनमें से प्रत्येक का अपना था
रेपो। मैं वास्तव में D3 आर्किटेक्चर को देखने की सलाह देता हूं।

मैं यह नहीं कह रहा हूं कि हमें थ्री के लिए इसकी आवश्यकता है, लेकिन मुझे लगता है कि हम इस पर विचार कर सकते हैं
प्रमुख संस्करण टक्कर। आंशिक रूप से webgl2 के कारण। लेकिन आवश्यकता के कारण भी
उप-मॉड्यूल।

एक उदाहरण: एक D3 "चयन" रेपो/उप-मॉड्यूल है। यह आपका मूल है
jQuery डीओएम मॉड्यूल लेकिन डीओएम की सभी वर्बोजिटी के साथ छुपा हुआ है
कार्यात्मक, जंजीर डिजाइन। इसका उपयोग बाकी के उपयोग के बिना किया जा सकता है
डी3.

क्या आप एक तीन स्वतंत्र मॉड्यूल को पसंद नहीं करेंगे जिसने सभी वेबलॉग बनाए हैं
वाचालता गायब? शायद webgl ctx/shader . के लिए भी कई उप-मॉड्यूल
प्रबंधन, बफर प्रबंधन, और इसी तरह। वास्तव में, बफर ज्यामिति है a
इस तरह बहुत। भागों से छायादार निर्माण के लिए डिट्टो।

सिर्फ एक विचार।

@ fetox74 बहुत यकीन है कि आप पहले से ही AA कर सकते हैं https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

@elunty FXAAShader मूल एंटीअलाइजिंग की तुलना में पर्याप्त पर्याप्त परिणाम नहीं देता है, मैंने इसे जंगली में उपयोग किया है।

मुझे ज्यादातर वीएओ में दिलचस्पी है और मिपमैप्स को लिखना है जो मुझे आशा है कि उस कल्पना के तहत संभव है।

@pailhead संबंधित #8705: पलक:

EXT_shader_texture_lod के लिए मूल समर्थन की प्रतीक्षा कर रहे हैं।
यह अधिकांश Android उपकरणों और MS Edge और Internet Explorer पर MeshStandardMaterial और MeshPhysicalMaterial का उपयोग करते समय उत्पन्न होने वाली कलाकृतियों को हल कर सकता है

@mrdoob क्या आपकी या आपकी टीम की ओर से Threejs को Webgl 2.0 में अपडेट करने की कोई योजना है? इस धागे में सचमुच वर्षों लगते हैं और वास्तव में कुछ भी नहीं बदलता है जबकि अन्य सभी ढांचे पहले ही आगे बढ़ चुके हैं। मेरा जल्द ही एक कठिन निर्णय होगा, हमें शायद बाबुल या कुछ और पर प्रवास करना होगा और मैं वास्तव में तीन के साथ रहना चाहूंगा। मैं, यदि कोई होगा, तो इसके आधुनिकीकरण की कोई योजना बनाऊंगा।

@wdanilo अगर वेबजीएल 2.0 आपके प्रोजेक्ट के लिए प्राथमिकता है तो मैं आपको बेबीलोन में माइग्रेट करने की सलाह दूंगा। मुझे पता है कि कुछ तीन.जेएस योगदानकर्ता इस पर काम करने की योजना बना रहे हैं, लेकिन मैं व्यक्तिगत रूप से वेबवीआर और कलाकारों के कार्यप्रवाह (एसवीजी समर्थन, आदि) पर केंद्रित हूं।

@mrdoob मैं वास्तव में यहाँ आपके तेज़ उत्तर की सराहना करता हूँ। मैं वास्तव में तीन.जेएस को नहीं छोड़ना चाहूंगा। मुझे पसंद है कि हुड के तहत लिब का निर्माण कैसे किया जाता है और इसकी धारणाएं "सामान्य" ढांचे के रूप में होती हैं, न कि "गेम-केंद्रित" आदि। वैसे भी, जानकारी के लिए धन्यवाद और इसे स्पष्ट रखें।

(धन्यवाद फिर से @takahirox , मुझे इस धागे के बारे में पता था)। मैंने अभी-अभी पुल अनुरोध #13692 किया है। मैं समझता हूं कि इस पर ध्यान नहीं दिया जा रहा है लेकिन हमारे उद्देश्यों के लिए यह अच्छी तरह से काम कर रहा है।

संबंधित #13702

मैंने #9965 और #12250 . का अनुसरण करते हुए WebGL2 आधार शाखा बनाई

रेपो: https://github.com/takahirox/three.js/tree/WebGL2Base
उदाहरण: https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

आप इसके साथ WebGL2.0 + Three.js शुरू कर सकते हैं।

(क्षमा करें @yoshikiohshima कार्य के साथ विरोधाभासी)

@mrdoob क्या हमारे पास WebGL2Renderer के लिए तीन.js/dev-2.0 जैसी शाखा हो सकती है? या क्या हम इसे देव में विलय कर सकते हैं, फिर भी webgl1 और webgl2 के बीच बहुत सारे डुप्लिकेट कोड हो सकते हैं?

मैं इस मुद्दे पर पिछले विकास के लिए नया हूँ। @takahirox , क्या आप उस रणनीति को संक्षेप में बता सकते हैं जिसमें आप ले रहे हैं और https://github.com/takahirox/three.js/tree/WebGL2Base द्वारा समर्थित क्या हैं? (और फिर से मेरी अज्ञानता के लिए खेद है) लेकिन मुझे WebGL2 का समर्थन करने के लिए बहुत सारे डुप्लिकेट कोड की आवश्यकता नहीं दिखाई दी। मुद्दे क्या हैं?

@mrdoob क्या हमारे पास WebGL2Renderer के लिए तीन.js/dev-2.0 जैसी शाखा हो सकती है? या क्या हम इसे देव में विलय कर सकते हैं, फिर भी webgl1 और webgl2 के बीच बहुत सारे डुप्लिकेट कोड हो सकते हैं?

सुनिश्चित नहीं है कि इसे एक नई शाखा की आवश्यकता क्यों होगी। डुप्लिकेट कोड क्यों होगा?

कोई टकराव नहीं लगता। WebGL2.0 के लिए अभी दो मांगें हैं।

1. पूर्ण WebGL2.0 सुविधाओं का समर्थन करने और अच्छी तरह से अनुकूलित करने के लिए WebGL2Renderer बनाना
2. मौजूदा WebGLRenderer में webgl2 समर्थन जोड़ना। लेकिन हम इस पर WebGL2.0 सुविधाओं का पूरी तरह से समर्थन नहीं करते हैं और WebGL2.0 के लिए अनुकूलित नहीं करते हैं क्योंकि हम रेंडरर को खराब नहीं करना चाहते हैं। तो मूल रूप से यह केवल Three.js + WebGL2.0 + GLSL3.0 की प्रारंभिक पहुंच के लिए है

मेरा 1 के लिए है। उसका काम 2 के लिए है। हमारे पास डुप्लिकेट कोड नहीं है और 2 के लिए नई शाखा बनाने की आवश्यकता नहीं है।

@takahirox मुझे लगता है कि फिलहाल उसी शाखा में काम करना बेहतर होगा।

अगर तुम सुधर जाओ...

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGL2Renderer.js

और webgl2 उदाहरण सीधे कक्षाएं आयात करते हैं (बिल्ड की आवश्यकता नहीं है) ...

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L39 -L47

संघर्ष नहीं होना चाहिए।

आप अब तक मेरे WebGL2Base को भूल सकते हैं क्योंकि ऐसा लगता है कि हमने एक WebGLRenderer में WebGL2.0 समर्थन शुरू कर दिया है।

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

हाँ मैं यही सोचता हूँ। मुझे लगता है कि मौजूदा WebGLRenderer में मूल webgl 2.0 समर्थन जोड़ने का मतलब है कि जब हम WebGL2Renderer पर काम कर रहे हों तो कुछ हो जाए।

बेझिझक रेंडरर को फिर से लिखना शुरू करें और पीआर भेजें (आदर्श रूप से कदम दर कदम)।

क्षमा करें अगर स्पष्ट पूछ रहे हैं, लेकिन इस पूरे मुद्दे को पढ़ने के बाद, आखिरी पोस्ट आधा साल पहले होने के साथ, और मास्टर स्रोत कोड और उदाहरणों दोनों में webgl2 के कुछ संदर्भ ढूंढने के बाद, मैं अभी भी इसे काफी समझ नहीं पा रहा हूं .

आश्चर्य है कि webgl2 तीन.जेएस में अपनी वर्तमान स्थिति में प्रयोग करने योग्य है या नहीं? (भले ही साधारण बफ़रज्योमेट्री मेश प्रस्तुत कर रहे हों) क्या इफ़ेक्टकॉम्पोज़र वेबग्ल 2-संदर्भ-सक्षम रेंडरर के साथ काम करेगा? क्या रेंडर टारगेट को किसी भी तरह से एडजस्ट करना होगा?

बेशक, सबसे बड़ा सवाल यह है कि क्या कस्टम पास के साथ कंपोजर का उपयोग करते समय वर्तमान में उचित एंटीअलाइजिंग प्राप्त करना संभव है?

ऐसा लगता है कि अंत में हमने वेबजीएल 2.0 सुविधाओं को WebGLRenderer में जोड़ना समाप्त कर दिया।
हालांकि वेबजीपीयू को निश्चित रूप से WebGPURenderer की आवश्यकता होगी।