Three.js: चयनात्मक प्रकाश व्यवस्था

मैं जो कह रहा हूं वह मूल रूप से channel फ़ील्ड में THREE.Light और lightChannel फ़ील्ड में THREE.Mesh या ऐसा कुछ है। यदि उत्तरार्द्ध शून्य है तो यह सभी प्रकाश स्रोतों से प्रभावित होता है। यदि उत्तरार्द्ध शून्य नहीं है, तो यह केवल समान मान वाले प्रकाश चैनलों को प्रभावित करता है।

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

लगता है जैसे आप छाया का उपयोग करना चाहते हैं?

खैर, मैं छाया के साथ ऐसा कुछ हासिल कर सकता था (और मैंने पहले ही कोशिश की है), लेकिन यह अलग-अलग दुष्प्रभाव देता है और मुझे लगता है कि यह एक हैक है, क्योंकि मुझे कुछ वस्तुओं को प्रकाश देने और फिर उन पर छाया डालने की आवश्यकता नहीं है . मुझे उन्हें पहले स्थान पर नहीं जलाना चाहिए।

मुझे जो चाहिए वह यह है कि एक विशिष्ट प्रकाश स्रोत मेष के एक सेट को प्रभावित नहीं करता है, लेकिन दूसरे सेट को प्रभावित करता है।

आमतौर पर मैं इस तरह की तकनीक का उपयोग करके ऐसा करता हूं: उदाहरण चर्चा सूत्र :

glEnable(GL_LIGHT0);
//...
glEnable(GL_LIGHTn);

// Draw the walls to room 1
DrawWalls(room[0]);

// Draw the contents of room 1
DrawContents(room[0]);

glDisable(GL_LIGHT0);
//...
glDisable(GL_LIGHTn);

// Draw the walls to room 2
DrawWalls(room[1]);

// Draw the contents of room 2
DrawContents(room[1]);

तो यह सिर्फ छाया से अलग विशेषता की तरह दिखता है। या क्या मैं कुछ न कुछ भूल रहा हूं?

हाँ... मुझे लगता है कि यह वास्तव में आसान हो सकता है। सुनिश्चित नहीं है कि इसके लिए एपीआई कैसा दिखना चाहिए।

शायद सबसे आसान समाधान यहां सबसे प्रभावी हो सकता है:

1. channel (या group ) को THREE.Light
2. affectedByLightChannel (या affectedByLightGroup ) को THREE.Mesh (या शायद ज्यामिति में एक चेहरे के लिए भी)

तुम क्या सोचते हो?

हो सकता है कि 'प्रभावित बायलाइट चैनल' बहुत लंबा हो और 'लाइट चैनल' जैसा कुछ काम करेगा, लेकिन मुझे लगता है कि यह सुविधाजनक होगा: प्रकाश स्रोत और रिसीवर पर सिर्फ चैनल नंबर।

उसके जैसा:

    light = new THREE.PointLight(0xFFF7D6, 1.0, 15)
    light.channel = 123
    testScene.add(light)

    testScene = new THREE.Scene
    geometry = new THREE.BoxGeometry(2,2,2)
    material = new THREE.MeshLambertMaterial 
        color: 0xffffff

    cube = new THREE.Mesh(geometry, material)
    cube.lightChannel = 123
    testScene.add(cube)

यदि lightChannel 0 के बराबर है, तो यह सभी चैनलों द्वारा प्रभावित होता है। यदि channel 0 के बराबर है, तो यह सभी मेश को प्रभावित करता है।

तो यह वर्तमान व्यवहार के साथ पूरी तरह पिछड़ा संगत होगा।

यह समझना थोड़ा कठिन हो सकता है... शायद यह कुछ इस तरह से बेहतर है:

cube.lightInfluences = [ light1, light2 ];

मुझे बिल्कुल ठीक लगता है।

हो सकता है कि कुछ मामलों में इसका उपयोग करना थोड़ा अधिक कठिन हो, लेकिन स्पष्ट रूप से इसे समझना आसान है।

मेष और रोशनी के लिए एक साधारण पूर्णांक मुखौटा संपत्ति के बारे में क्या?

light = new THREE.PointLight(0xFFF7D6, 1.0, 15)
light.mask = 0xffffffff; // default mask
testScene.add(light);

cube = new THREE.Mesh(geometry, material)
cube.mask = 0xffffffff; // default
testScene.add(cube);

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

0xffffffff का मुखौटा डिफ़ॉल्ट मौजूदा कोड को प्रभावित नहीं करेगा।

क्या @satori99 ने कहा।

हालांकि, मुझे लगता है कि mask इसके बजाय Light और Mesh*Material संपत्ति होनी चाहिए। (केवल वही सामग्री रोशनी से प्रभावित होती है।)

साथ ही, संपत्ति को वैकल्पिक रूप से lightMask , lightChannel , या channel ।

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

आप मास्क के साथ क्या कर सकते हैं जो आप सरणी दृष्टिकोण के साथ नहीं कर सकते हैं?

मैं ऊपर दो कमरों के साथ कार्य से एक उदाहरण दे सकता हूं।

सरणी दृष्टिकोण पर चैनल दृष्टिकोण का उपयोग करने का मुख्य बिंदु यह है कि यदि आप सरणी का उपयोग करते हैं तो 'हल्का 1 से कमरे 2 तक ले जाएं' जैसे सरल संचालन अधिक जटिल हो जाते हैं।

बस सेटिंग के बजाय

light1.channel = 2

(पहले इसे 1 पर सेट किया गया था)

आपको कमरे 1 में सभी वस्तुओं को ढूंढना होगा जिसमें पहले प्रकाश प्रभाव सरणी में प्रकाश 1 था, फिर प्रकाश को उनके सरणी से हटा दें, फिर इसे कमरे 2 में सभी वस्तुओं में जोड़ें।

सरल ऑपरेशन के साथ एक ही कहानी जैसे 'ऑब्जेक्ट 1 को कमरे 1 से कमरे 2 में ले जाएं'। इसके प्रभाव चैनल को 1 से 2 तक सेट करने के बजाय, आपको उस कमरे में सभी रोशनी ढूंढनी होगी, फिर उन्हें इसके प्रभाव सरणी से हटा दें, फिर कमरे दो में सभी रोशनी ढूंढें और उन्हें जोड़ें।

ऐसा नहीं है कि यह नहीं किया जा सकता है, इसलिए मैंने कहा कि प्रकाश प्रभाव दृष्टिकोण मेरे लिए बिल्कुल ठीक है। लेकिन चैनल सामग्री पहली चीज होगी जिसे मैं अपने लिए केवल सामान्य संचालन को 1 असाइनमेंट के रूप में सरल बनाने के लिए लागू करूंगा।

मुझे लगता है कि इसे मास्क के रूप में लागू किया जाना चाहिए। (चाहे इसे सीपीयू या जीपीयू पर लागू किया गया है, बाद में चर्चा के लिए एक मुद्दा है।)

हम उदाहरणों के माध्यम से दिखा सकते हैं कि इसे कैसे सेट किया जाए, और उपयोगकर्ता पैटर्न का पालन कर सकते हैं।

यदि आपको लगता है कि यह अभी भी बहुत जटिल है, तो हम इसके लिए THREE.Channels API बना सकते हैं।

light.channels = new THREE.Channels();
...
light.channels.clear();
light.channels.add( channel );
light.channels.remove( channel );
light.channels.all();

Mesh*Material लिए समान तरीके।

मुझे वह एपीआई पसंद है :)
मैं इसे वस्तुओं और रोशनी के लिए काम करते हुए देख सकता हूं, लेकिन आप इसे सामग्री के लिए कैसे काम करते हुए देखते हैं?

केवल सामग्री रोशनी का जवाब देती है। यह सामग्री की एक संपत्ति होगी, मुझे लगता है।

मैं इस पर @westlangley से सहमत हूं। रोशनी सामग्री पर निर्भर हैं।

सरल ऑपरेशन के साथ एक ही कहानी जैसे 'ऑब्जेक्ट 1 को कमरे 1 से कमरे 2 में ले जाएं'।

खैर, यह एक समस्या है। Channels वस्तु-आधारित नहीं होगा।

खैर, यह एक समस्या है। चैनल वस्तु-आधारित नहीं होंगे।

लेकिन क्यों? क्या यह एक तकनीकी सीमा है?

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

लेकिन क्यों? क्या यह एक तकनीकी सीमा है?

नहीं, ऐसा इसलिए है क्योंकि वस्तुएं रोशनी पर प्रतिक्रिया नहीं करती हैं। सामग्री ही करते हैं।

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

आप दृश्य में सभी वस्तुओं के लिए एक ही सामग्री का उपयोग कर सकते हैं - केवल clone उन वस्तुओं के लिए सामग्री जिनकी सामग्री के लिए अलग-अलग समान मूल्यों की आवश्यकता होती है। सभी द्वारा साझा किए जाने वाले अभी भी केवल एक शेडर कार्यक्रम होना चाहिए।

मुझे लगता है कि इसे मास्क के रूप में लागू किया जाना चाहिए। (चाहे इसे सीपीयू या जीपीयू पर लागू किया गया है, बाद में चर्चा के लिए एक मुद्दा है।)

क्या इसे सीधे GPU में कुछ हद तक आसानी से नियंत्रित किया जा सकता है?

क्या इसे सीधे GPU में कुछ हद तक आसानी से नियंत्रित किया जा सकता है?

हां, आपको रोशनी और सामग्री के लिए अतिरिक्त channels वर्दी में पास करना होगा।

एक परत प्रबंधन प्रणाली के बारे में कैसे? मैं मेश को परतों में समूहित करूंगा और वहां से मास्क लगाऊंगा (रोशनी, छाया, दृश्यता आदि को प्रभावित कर सकता है), एकता एक अच्छा उदाहरण होगा?

छाया भी एक संबंधित विषय है। मुझे लगता है कि चयनात्मक छाया कास्टिंग जैसा कुछ भी होना चाहिए। जैसे 'receiveShadowFrom = ...' (और स्रोतों की सूची) के बजाय सिर्फ 'ReceiveShadow = true'।

क्योंकि जब आप रोशनी सेट करते हैं जो केवल एक विशिष्ट कमरे (मेरे उदाहरण में) को प्रभावित करती है, तो आप तुरंत उन रोशनी को केवल इस कमरे की वस्तुओं पर छाया डालना चाहते हैं।

छाया विशेषताएँ वास्तव में सामग्री पर होनी चाहिए न कि वस्तुओं पर उन्हीं कारणों से जो इस धागे में ऊपर हैं।

छाया विशेषताएँ वास्तव में सामग्री पर होनी चाहिए न कि वस्तुओं पर उन्हीं कारणों से जो इस धागे में ऊपर हैं।

हाँ, यह समझ में आता है!

क्या इस सुविधा को शामिल करने की कोई योजना है (जैसे पहले मसौदे के लिए एक नियोजित लक्ष्य रिलीज)?

वर्कअराउंड के रूप में, क्या आप प्रत्येक कमरे (और उसकी रोशनी) के लिए एक अलग दृश्य बनाकर अपनी अधिकांश आवश्यकताओं को प्राप्त कर सकते हैं?

renderer.autoClear = false;
...
renderer.render( scene1, camera );
renderer.render( scene2, camera );

हम्म, मैं इस दृष्टिकोण की कोशिश करूँगा!

भविष्य के संस्करणों आईएमओ के लिए चुनिंदा प्रकाश/छाया जरूरी है।

इसके लिए बड़ा +9999, मुझे यह चुनने में सक्षम होना अच्छा लगेगा कि क्या कोई सामग्री प्रकाश स्रोत ए या प्रकाश स्रोत बी से छाया डालती है। किसी को भी दो दृश्यों के अलावा कोई समाधान मिला है? यह मेरे लिए चीजों को काफी दर्दनाक बनाने वाला है...

पवित्र बकवास यह अभी भी कैसे लागू नहीं किया गया है? रोहन से +9999 के बाद)

हाहा मेरा अनुमान है कि @tsone को लागू करना कठिन है, क्या आप उस प्रतिबद्धता पर कुछ जानकारी प्रदान कर सकते हैं? फ़ोन क्लाइंट पर अभी ब्राउज़ करना

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

यहाँ एक सरल JSFiddle है जो देव शाखा के Layers कार्यान्वयन का परीक्षण करता है:
https://jsfiddle.net/Angrypickle/t8f7q3vo/4/
दुर्भाग्य से, इस समय, ऐसा नहीं लगता कि यह ठीक से काम कर रहा है। या मुझ से कुछ गलत हो रहा है?

हां। परतें अभी तक रोशनी के साथ काम नहीं करती हैं। हालांकि वे कैमरा/ऑब्जेक्ट के साथ काम करते हैं! मैं

रोजर कि सर! यहाँ एक अद्यतन JSFiddle है जो परतों के साथ चयनात्मक प्रकाश व्यवस्था प्राप्त करने के लिए अतिव्यापी कैमरों का उपयोग करता है:
https://jsfiddle.net/Angrypickle/t4a1eusL/
ऐसा लगता है कि यह डेस्कटॉप और मोबाइल पर ठीक से काम करता है। किसी को भी इस दृष्टिकोण के साथ कुछ भी बहुत बुरा लगता है? कम से कम जब तक रोशनी परतों की कार्यक्षमता में बंधी नहीं होती है?

किसी को भी इस दृष्टिकोण के साथ कुछ भी बहुत बुरा लगता है?

बेशक यह बुरा है। दृश्य को नेविगेट करने वाला एकल कैमरा होने के बजाय, लोगों को अब camera1.add( camera2 ); मेरा मतलब है कि जब मैं इसे देखता हूं तो यह डब्ल्यूटीएफ है। कैसा? मेरे कैमरे में कैमरा? क्या होगा यदि मेरे पास दर्जनों कमरे हैं जिन्हें व्यक्तिगत रूप से प्रकाशित करने की आवश्यकता है? मुझे कितने कैमरे चाहिए? और परतें ... वहाँ कोई परतों कल, सही थे, और अब मैं उनके बारे में जानने के लिए।

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

@makc परतें वास्तव में सुपर सरल (और शक्तिशाली) हैं!
@ Zob1 का दृष्टिकोण निश्चित रूप से सही दृष्टिकोण नहीं है। उम्मीद है कि इसमें अधिक समय नहीं लगेगा जब तक कि परतें भी रोशनी के साथ काम नहीं करतीं।

दोस्तों सिर्फ यह सुनिश्चित करने के लिए कि मैं सही तरीके से अनुसरण कर रहा हूं; मान लें कि मेरे पास एक दृश्य और "मुख्य" प्रकाश स्रोत है। क्या इस तकनीक से यह संभव है कि कुछ सामग्री इस मुख्य प्रकाश स्रोत को अनदेखा कर दें, जबकि एक अलग प्रकाश स्रोत से छाया भी डाल रहे हों?

खैर, इसके लिए हमें सामग्री में लेयर सपोर्ट भी जोड़ना होगा।

इस समय हम क्या कर सकते हैं कैमरे से वस्तुओं को दिखाना/छिपाना:

मान लें कि आप एक गेम कर रहे हैं और, संपादक में, आप कोलाइडर प्रदर्शित करने के लिए गोले का उपयोग करते हैं। उन क्षेत्रों को परत 1 पर सेट किया जा सकता है, कैमरे के संपादक में परतें 0 और 1 सक्षम हो सकती हैं, लेकिन गेम कैमरा को परत 0 पर सेट किया जा सकता था। इस तरह, आपके संपादक में आप सभी डमी देखते हैं, लेकिन खेल में वे ' फिर से चला गया।

मुझे लगता है कि जब भी मैं संपादक को कार्यक्षमता जोड़ूंगा तो यह और अधिक समझ में आएगा। हमें शायद कुछ उदाहरण भी करने चाहिए।

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

मेरा मूल विचार था कि प्रत्येक वर्ण के ऊपर अदृश्य वृत्त ज्यामितीय स्थान "हेलोस" के रूप में हों और एक ऐसा प्रकाश बनाएं जो सीधे नीचे की ओर इशारा कर रहा हो, पूरे दृश्य को कवर कर रहा हो। ये प्रभामंडल केवल इस प्रकाश स्रोत से परछाईं देगा जबकि दृश्य में बाकी सब कुछ "मुख्य" प्रकाश स्रोत से छाया डालेगा।

मुझे लगता है कि इस विचार के काम करने के लिए, हमें परतों की आवश्यकता है?

ये प्रभामंडल केवल इस प्रकाश स्रोत से परछाईं देगा जबकि दृश्य में बाकी सब कुछ "मुख्य" प्रकाश स्रोत से छाया डालेगा।

हमारे पास shadowOnly विकल्प हुआ करता था, लेकिन इसे हटा दिया गया था।

एफडब्ल्यूआईडब्ल्यू, छाया बनाने के लिए यह दृष्टिकोण है ...

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

मैं उस उदाहरण को अभी फोन पर देखूंगा, लेकिन आशाजनक लग रहा है।

संपादित करें हम्म लेकिन अगर उस क्षेत्र ने दृश्य में अपनी स्थिति बदल दी और जमीन की जाली की ऊंचाई अलग-अलग थी, तो क्या इसकी छाया जमीन की सतह के मानदंडों से सही ढंग से मेल खाती है?

नहीं...

हाँ ऐसा सोचा। परतों की जरूरत है! हेहे

हाय @ रोहन-देशपांडे,

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

आप मेरे खेल की जांच कर सकते हैं जो यहां उनका उपयोग करता है:
https://github.com/erichlof/3dLightCycles

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

भविष्य में परतों के लिए यहां +1 करें :)

@erichlof गेम

ठीक है, मुझे लगता है कि मैं परतों की प्रतीक्षा करूँगा। तब तक मेरे हैकी समाधान को सहना होगा।

हे लोगों
क्या यह बात लागू की गई है?
http://stackoverflow.com/questions/33689781/casting-shadows-based-on-a-specific-light?noredirect=1#comment55153706_33689781

नहीं, इसे अभी तक लागू नहीं किया गया है। आपको परतों के लिए प्रतीक्षा करनी होगी या आईटीटी में सूचीबद्ध समाधानों में से एक का प्रयास करना होगा (उदाहरण के लिए अलग दृश्य)।

+999999 फिर से

यह निश्चित रूप से बहुत मददगार होगा। और अब हमारे पास परतें काम कर रही हैं, जो ऐसा लगता है कि यह वही है जो इसे पकड़ रहा है। तो, यहाँ दोस्ताना टक्कर है। ;-)

@manthrax इसे जांचें!

+999999 फिर से

मुझे इसके लिए अच्छा लगेगा। मेरे पास ऐसी स्थिति है जहां प्रत्येक अवतार केवल निकटतम प्रकाश से प्रकाशित होता है, और मेरे पास दृश्य में हजारों रोशनी हो सकती हैं, प्रत्येक अवतार के लिए एक प्रकाश निर्दिष्ट करना अच्छा होगा।

नमस्ते!
मुझे इस सुविधा की आवश्यकता होगी, और मैंने इसे लागू करने के बारे में सोचा, क्योंकि मुझे लगता है कि मैंने वह स्थान पाया है जहां यह किया जा सकता है ( initMaterial में WebGLRenderer ) और इसका उपयोग करके बहुत सीधा होना चाहिए मौजूदा परतें।

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

क्या यह प्रासंगिक होगा?

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

अपडेट करें:

https://github.com/tiesselune/three.js/tree/selective-lighting

मैं कहीं पहुंच रहा हूं। सुनिश्चित नहीं है कि यह प्रदर्शन को कैसे प्रभावित कर सकता है या मेरे कोड को पूर्ण के लिए कैसे अनुकूलित कर सकता है, लेकिन यह मेरे द्वारा किए गए कुछ परीक्षणों पर काम कर रहा है। प्रति परत प्रकाश! वाह!

मुझे अभी भी कुछ और परीक्षण करना है, और पुल अनुरोध सबमिट करने से पहले एक प्रासंगिक उदाहरण बनाना है।

अपडेट करें:

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

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

यहां दो समाधान दिए गए हैं जिनका मैं उपयोग कर सकता हूं:

1. मैं केवल एक चेतावनी प्रदर्शित कर सकता था जब अलग-अलग परतों पर अलग-अलग प्रकाश सेटिंग्स के साथ दो ऑब्जेक्ट एक ही सामग्री साझा करते हैं, इसलिए उपयोगकर्ता स्वयं एक नई क्लोन सामग्री बना और प्रबंधित कर सकता है।

2. मैं वस्तु के स्तर के बजाय भौतिक स्तर पर परतें जोड़ सकता हूं (और रोशनी के लिए समानांतर परत प्रणाली बना सकता हूं) ताकि विभिन्न प्रकाश सेटिंग्स प्राप्त करने के लिए विभिन्न सामग्रियों का उपयोग करना अनिवार्य हो। इसका मतलब यह होगा कि दृश्यता (वस्तुओं और कैमरों पर) के लिए वर्तमान परत प्रणाली होगी और प्रकाश व्यवस्था (सामग्री और रोशनी पर) के लिए एक अलग होगी।

तुम लोग क्या सोचते हो?

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

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

वैसे, filterAmbiantLights होना चाहिए filterAmbientLights ।

आप गलत वर्तनी के बारे में सही हैं। मैंने वास्तव में सब कुछ "परिवेश" के साथ लिखा था इससे पहले कि यह गलत था और मैं एक घटना भूल गया। मैं

मुझे लगता है कि मैं तब सामग्री पर परत की जानकारी ले जाने वाला हूं। यह जिस तरह से काम करता है उससे अधिक प्रासंगिक और सुसंगत लगता है।

प्रदर्शन ड्रॉप initMaterial (और फिर acquireProgram और getShaderParameter जो किसी कारण से काफी धीमा है) से आया (और अभी भी आता है) हर फ्रेम को कई बार बुलाया जा रहा है क्योंकि lightHash हर बार अलग होगा, material.needsUpdate से true ।

बीटीडब्ल्यू मैं क्रोम के प्रोफाइलिंग टूल्स का उपयोग कर रहा हूं। (समयरेखा और प्रोफाइलर)।

यह मेरे द्वारा ठीक है, लेकिन मुझे स्पष्ट नहीं है कि acquireProgram को हर समय क्यों चलाना चाहिए। यदि प्रोग्राम पैरामीटर में प्रत्येक प्रकार के प्रकाश की संख्या जोड़ दी जाती है, तो क्या हर बार शेडर को पुन: संकलित करना अनावश्यक नहीं होना चाहिए?

मुझे यह भी नहीं मिला;

यहां कॉल स्टैक (हर फ्रेम पर) और भयानक मेमोरी लीक है, यदि आप इनसे परिचित हैं, तो इससे मुझे यह समझने में मदद मिल सकती है कि क्या गलत है। ऐसा लगता है कि यह हर फ्रेम में नया WebGLProgram ...

शायद यह replaceLightNums हो सकता है जो WebGLProgram के निर्माण के दौरान वर्टेक्स/फ़्रैगमेंट शेडर कोड को अपडेट करता है, जिससे यह पुन: संकलित हो जाता है, या यह एक अलग शेडर है ...?

संपादित करें: वैसे भी, भौतिक स्तर पर परतों का उपयोग करने से समस्या का समाधान अपेक्षित होता है। मेरे पास कहीं न कहीं एक स्मृति रिसाव है जिसकी मुझे जांच करनी चाहिए लेकिन अन्यथा यह काफी अच्छा लगता है।

यह समझना शायद एक अच्छा विचार है कि ऐसा क्यों हो रहा है यह सुनिश्चित करने के लिए कि आप कोड को पूरी तरह से समझते हैं और कुछ नई बग पेश नहीं कर रहे हैं। क्या आप यह देखने के लिए कदम उठा सकते हैं कि शेडर कोड हर फ्रेम को क्यों बदलता है?

मैं WebGLPrograms अच्छी तरह से नहीं जानता कि क्या हो रहा है, लेकिन ऐसा लगता है कि यह आपके लिए उन शेडर्स को कैशिंग करना चाहिए।

यह काफी सरल है, वास्तव में:

• गीला जानने के लिए या कॉल करने के लिए नहीं acquireProgram , initMaterial को कैश से शेडर "कोड" मिलता है (यह वास्तव में हैश का अधिक है, getProgramCode में निर्मित) और तुलना करता है यह वर्तमान सामग्री के कार्यक्रम के "कोड" के लिए है।
• चूंकि यह फ़ंक्शन प्रत्येक प्रकार के प्रकाश की संख्या सहित मापदंडों से "कोड" बनाता है, जिसे फ़िल्टर किया जाता है और हालांकि वस्तुओं के बीच भिन्न होता है, एक ही सामग्री के लिए कोड अलग हो सकता है (ऐसा कहने के लिए, एक ही प्रोग्राम) किसी ऑब्जेक्ट से अन्य।
• चूंकि इस प्रक्रिया को प्रत्येक ऑब्जेक्ट के लिए पुनरावृत्त किया जाता है, इसलिए "कोड" प्रति फ्रेम कई बार बदलता है, जिससे यह एक ही फ्रेम में कई बार पुन: संकलित हो जाता है: जो पूर्ण ड्रॉप का कारण बनता है।
• उस ने कहा, चूंकि कई वस्तुओं में एक ही सामग्री होती है, और इसलिए, एक ही कार्यक्रम, अंतिम वस्तु कार्यक्रम के लिए इसके मापदंडों को लागू करके पुनरावृत्त होती है, जिसके कारण दोनों वस्तुओं को एक ही प्रकाश सेटअप के साथ जलाया जाता है, लेकिन जरूरी नहीं कि एक ही शैडोमैप्स (वह वस्तुओं के लिए एक अलग क्रम में गणना की जा सकती है, लेकिन वही "अंतिम वस्तु जीतती है" समस्या से ग्रस्त है), जिससे मेरी दृश्य विषमताएं होती हैं।

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

कुछ सुधार हो सकते हैं यदि प्रकाश संख्याएँ परिवर्तनशील हों, ताकि प्रत्येक सामग्री केवल एक ही कार्यक्रम के उदाहरण हों, लेकिन चूंकि उन संख्याओं को शेडर कोड में डाला गया है (में replaceLightNums ) यह वर्तमान में जिस तरह से चीजों के साथ असंगत लगता है हैं (और उनका अनुकूलन)।

आशा है कि स्पष्टीकरण काफी समझ में आया था

मुझे आश्चर्य है कि क्या हम लेयर मास्क को शेडर (प्रति वस्तु एक वर्दी और प्रति प्रकाश एक और वर्दी) पास कर सकते हैं। तब हम यहाँ कुछ इस तरह जोड़ सकते हैं।

कुछ इस तरह...

for ( int i = 0; i < NUM_POINT_LIGHTS; i ++ ) {

    pointLight = pointLights[ i ];
    pointLight.distance *= float( object.mask & pointlight.mask > 0.0 );

    ...

}

मेह, मुझे नहीं लगता कि हम glsl में बिटवाइज़ ऑपरेशन कर सकते हैं ...

हां, ऐसा लगता है कि जीएलएसएल 1.30 में बिटवाइज संचालन शुरू होता है और मानक वेबजीएल 1.00 का उपयोग करता है। मैं

हाय @mrdoob और @tiesselune ,

क्रोम 56 और फ़ायरफ़ॉक्स 51 अभी-अभी उतरे हैं, जिसका अर्थ है कि वेबजीएल 2.0 डिफ़ॉल्ट रूप से सक्षम है (वेबजीएल 2 ओपनजीएल ईएस 3.0 युक्ति का अनुसरण करता है)। इसका मतलब है कि बिट संचालन (और 3 डी बनावट जैसी अन्य अच्छी चीजें) अब उपलब्ध हैं। मुझे नहीं पता कि थ्री धीरे-धीरे वेबजीएल 2.0 में शिफ्ट होने की तैयारी कर रहा है या नहीं, लेकिन मैंने थ्री84.जेएस की अपनी कॉपी में कुछ अनिवार्य बदलाव किए हैं और वेबजीएल 2.0 को सक्षम किया है, और इसे सुनिश्चित करने के लिए एक शेडर में थोड़ा ऑपरेशन किया है। काम किया, और यह किया!
https://developers.google.com/web/updates/2017/01/nic56
https://developer.mozilla.org/en-US/Firefox/Releases/51

बस आपको बताना चाहता था। मास्किंग विचार के लिए +1 :-)

हाय @erichlof ! WebGL2 के लिए यह बहुत अच्छी खबर है; इसका मतलब है कि WebGL2 रेंडरर शायद अधिक कुशल तरीके से मास्किंग समस्याओं से निपटने में सक्षम होगा।

वैसे भी, अब तक WebGL2 का समर्थन करने वाले ब्राउज़रों के

फिर से नमस्कार!

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

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

यहाँ एक स्क्रीनशॉट है:

उदाहरण को यहां लाइव देखना संभव होना चाहिए:

https://rawgit.com/tiesselune/three.js/selective-lighting/examples/webgl_lights_selective_lights.html

हालांकि मुझे एक त्रुटि मिल रही है:

Uncaught TypeError: Cannot read property 'set' of undefined
    at init (webgl_lights_selective_lights.html:117)
    at webgl_lights_selective_lights.html:67

@looeee : आपको स्थानीय होस्ट पर npm run build-uglify चलाना होगा। मैंने स्वेच्छा से मर्जिबिलिटी उद्देश्यों के लिए अपने कमिट में बिल्ड शामिल नहीं किया है ...

या मुझे करना चाहिए?

संपादित करें: यहां परीक्षण उद्देश्यों के लिए एक अलग शाखा पर एक कार्यशील लिंक है: https://rawgit.com/tiesselune/three.js/selective-lights-test/examples/webgl_lights_selective_lights.html

अरे, मेरी ओर से +999999। इसे लागू किया जाना चाहिए (कम से कम THREE.Layers )

$$('.comment-body').reduce((acc, el) => {
  let mat = el.textContent.match(/\+(\d+)/)
  let num = +(mat && mat[1] || 0)
  return acc + num
}, 0)
>> 1219997

मैं

@mrdoob उन्होंने इस सूत्र में +Ns की गणना की

बीटीडब्ल्यू, +14570 चयनात्मक रोशनी के लिए

यह ठीक ट्यूनिंग के लिए अविश्वसनीय रूप से बहुत अच्छा होगा कि प्रकाश उच्च अमूर्तता में कैसे काम करता है।

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

https://codepen.io/trusktr/pen/RjzKJx

एकल-बिंदु-प्रकाश की तरह दिखने वाले कुछ प्रभाव दो या दो से अधिक रोशनी के संयोजन से प्राप्त किए जा सकते हैं जो केवल कुछ तत्वों को चुनिंदा रूप से प्रभावित कर रहे हैं।

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

@WestLangley

वर्कअराउंड के रूप में, क्या आप प्रत्येक कमरे (और उसकी रोशनी) के लिए एक अलग दृश्य बनाकर अपनी अधिकांश आवश्यकताओं को प्राप्त कर सकते हैं?

क्या आपके पास इस तरह के कुछ उदाहरण के लिए एक लिंक है? क्या इसके परिणाम पर अन्य अप्रत्याशित प्रतिपादन प्रभाव हो सकते हैं?

परिणाम पर अन्य अप्रत्याशित प्रतिपादन प्रभाव?

पारदर्शी वस्तुओं का प्रतिपादन क्रम, उदाहरण के लिए - दृश्य 1 में पारदर्शी वस्तुओं को दृश्य 2 में अपारदर्शी वस्तुओं से पहले प्रस्तुत किया जाएगा।

क्या आपके पास इस तरह के कुछ उदाहरण के लिए एक लिंक है?

यहाँ, मैंने आपके लिए एक बनाया है: https://jsfiddle.net/f2Lommf5/524/

पारदर्शी वस्तुओं का प्रतिपादन क्रम, उदाहरण के लिए - दृश्य 1 में पारदर्शी वस्तुओं को दृश्य 2 में अपारदर्शी वस्तुओं से पहले प्रस्तुत किया जाएगा।

वही तो में सोच रहा था; यह समाधान को बहुत सीमित मामलों के लिए केवल एक समाधान बनाता है। वास्तविक समाधान की प्रतीक्षा में!

ठीक है, आप तर्क दे सकते हैं कि समस्या केवल तभी होगी जब आप दृश्य 1 गर्त से दृश्य 2 की अपारदर्शी वस्तुओं को पारदर्शी वस्तुओं को देख सकें। लेकिन अगर ऐसा है, तो रोशनी भी गुजरनी चाहिए, और दृश्यों को शुरू करने के लिए अलग करने का कोई कारण नहीं होगा। लेकिन मैं मानता हूं कि इस तरह का तर्क वास्तव में आश्वस्त करने वाला नहीं है।

@makc यहाँ उस समस्या का एक उदाहरण है जिसे मैं हल करने का प्रयास कर रहा हूँ:

https://discourse.threejs.org/t/how-to-make-shadows-darker-on-transparent-objects/1389

मुझे लगता है कि चयनात्मक प्रकाश व्यवस्था वास्तव में इसमें मदद करेगी।

@trusktr मुझे लगता है कि आप mrdoob की छाया सामग्री को बदलकर इसे हल कर सकते हैं। यह सिर्फ काले-सफेद छाया बनावट दिखाता है, और आप इसे आवश्यकतानुसार पारदर्शी होने के लिए संशोधित कर सकते हैं

चुनिंदा प्रकाश व्यवस्था के लिए PlayCanvas में मास्क का उपयोग करना वास्तव में आसान लगता है: https://forum.playcanvas.com/t/set-certain-object-to-not-receive-light/785।

क्या हम इसमें विलय कर सकते हैं? मुझे लगता है कि लैम्बर्ट शेडर के कारण छाया की समस्या कोड में बदलाव से कोई लेना-देना नहीं था। @tieselune

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

संपादित करें: अभी पता चला है कि कोड का यह हिस्सा बहुत बदल गया है। मुझे लगता है कि थोड़ा समय चाहिए क्योंकि जिन राज्यों का मैं पहले उपयोग कर रहा था वे WebGLRenderer से WebGLLights में स्थानांतरित हो गए थे।

@tiesselune मुझे इसे एक प्रोजेक्ट में लाने की ज़रूरत थी इसलिए मैंने आगे बढ़कर आपके कोड को v93 पर पोर्ट कर दिया: https://github.com/ErikBehar/three.js/tree/selectiveLights

अगर तुम लोग चाहो तो मैं पीआर कर सकता हूँ ? @mrdoob

@ErikBehar वैसे तो ऐसा लगता है कि मैं क्या लक्ष्य बना रहा था लेकिन मेरे पास इसे पूरी तरह से करने का समय नहीं था। मुझे लगता है कि मैं WebGLRenderer से फ़िल्टरिंग/हैश फ़ंक्शंस को स्थानांतरित कर देता और उन्हें WebGLLights स्टेट ऑब्जेक्ट में जोड़ देता। मुझे लगता है कि वे अब वहां हैं, परत प्रणाली राज्य का हिस्सा है और रेंडरर का हिस्सा नहीं है।

@ErikBehar एक पीआर बहुत अच्छा होगा!

@tiesselune जैसा कि आप सुझाव देते हैं, मैं इसे आगे बढ़ने में लोल =] पर पीआर को धक्का देने के लिए स्वतंत्र महसूस करूंगा और मैं जल्द ही पीआर पोस्ट

इस पर क्या स्थिति है? मैंने r94dev कोड को @ErikBehar से @tiesselune अगर आप मुझे कुछ विचार दे सकते हैं जहां आप चुनिंदा प्रकाश व्यवस्था को जाने का इरादा रखते हैं, तो मुझे इसे स्थानांतरित करने, परीक्षण करने और पीआर डालने में खुशी होगी।

संपादित करें:
थोड़ी देर बाद: मैं देखता हूं कि इसे काम करने के लिए कुछ काम की जरूरत है, अब, नए लाइटहैश के साथ।

@VaelynPhi मुझे लगता है कि, चाहे वे @ErikBehar के कोड को स्वीकार करने के इच्छुक हों या नहीं, पीआर जमा करना अच्छा विचार है, बस पुराने को बदलने के लिए यदि अन्य लोग इसे चाहते हैं, जैसे आप स्वयं किया

इस पर गेंद गिराने के लिए क्षमा करें = / ... @VaelynPhi क्या आप अपना कांटा / शाखा पोस्ट कर सकते हैं?

चिंता न करें; मैं व्यस्त होने को समझता हूं। काश, आप जिस शाखा में काम कर रहे थे, मुझे वह शाखा भी नहीं मिली, @ErikBehar; मैं कोड के माध्यम से पढ़ने और इसे तोड़ने के लिए बस गया ताकि मैं राज्य को उचित स्थान पर ले जा सकूं और उम्मीद है कि किसी भी बग को ठीक कर सकूं। मुझे अभी तक v94 पर भी काम कर रहे बंदरगाह राज्य में नहीं जाना है। शायद मैं इसे साफ कर सकता हूं और पीआर में डाल सकता हूं ताकि इसे अपडेट किया जा सके जैसा @makc सुझाव देता है। मुझे थोड़ा दे दो; मैं अति व्यस्त हूँ। :) कम से कम शायद यह उन परिवर्तनों को उजागर करने में मदद करेगा जिन्हें हाल के संस्करण में चुनिंदा प्रकाश को खींचने के लिए किए जाने की आवश्यकता है।

इसके आधार पर एक पीआर जोड़ा गया:
https://github.com/ErikBehar/three.js/commit/ac0499b70b82bc7bb780100a8372fcdf318d1424#diff -5e43a0b5002eb2c419def3baf67d4e67
द्वारा @ErikBehar
क्या कोई कुछ समीक्षा और उदाहरण के साथ हाथ दे सकता है?

https://github.com/mrdoob/three.js/pull/15223

अरे दोस्तों, इस पर क्या स्थिति है? @tiesselune @ErikBehar क्या मैं आपकी कुछ मदद कर सकता हूं? अच्छा होगा कि 4 साल बाद आखिरकार इसे लागू कर दिया जाए

@flyrell मुझे लगता है कि हम शायद इस मुद्दे को बंद कर सकते हैं क्योंकि ऐसा लगता है कि यह # 15223 में किया जा सकता है?