Three.js: सामग्री: जोड़ा गया onBeforeCompile ()

जब WebGLProgram.js पहले से ही बहुत सारी प्रोसेसिंग करता है, तो कस्टम स्ट्रिंग मैनिपुलेशन की आवश्यकता के लिए यह थोड़ा हैकी लगता है। एक संबंधित उपयोग मामला है, जो मौजूदा को ओवरराइड करने के बजाय नए #includes जोड़ना है। आप इसे आज रनटाइम पर THREE.ShaderLib को संशोधित करके कर सकते हैं, लेकिन यह उतना ही गंदा लगता है।

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

उस ने कहा, कच्चे पर आधारित शेडर रचना हमेशा एक संस्करण से दूसरे संस्करण में बहुत नाजुक होने वाली है। यदि आपको सभी कंकाल कोड (जैसे meshphong_vert.glsl ) को शामिल करने में कोई आपत्ति नहीं है, तो आप पहले से ही कुछ इस तरह से अंतर्निहित सामग्री का विस्तार कर सकते हैं:

export class MyPhongMaterial extends ShaderMaterial {
  constructor({ color, radius, map, normalMap, emissiveMap }) {
    super();
    this.vertexShader = "...."
    this.fragmentShader = "....";
    this.uniforms = UniformsUtils.clone(ShaderLib.phong.uniforms);

    this.isMeshPhongMaterial = true;
    this.lights = true;

    this.uniforms.time = { value: 1 };
    //...
  }
}

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

आज मैंने सोचा..

अच्छा! मैंने भी १० फरवरी को ऐसा ही सोचा था जब मैंने यह पुल अनुरोध किया था:

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

ऐसा लगता है कि फर्क सिर्फ इतना है कि आप इसे कॉलबैक के माध्यम से कर रहे हैं? मैंने WebGLRenderer में अप्रयुक्त तर्क में टैप किया।

मुझे इसका उपयोग करना पसंद है उदाहरण के लिए सामान्य मानचित्रों के साथ काम करने के लिए तीनjs प्राप्त करना, लेकिन मैंने कुछ मुद्दों को जोड़ा है जो ऐसा लगता है कि वे इसके साथ हल करने के लिए तुच्छ होंगे।

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

http://dusanbosnjak.com/test/webGL/three-material-shader-override/webgl_materials_shader_override.html

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

वास्तव में इसमें क्या होता है: https://github.com/mrdoob/three.js/pull/10791 काश मैं बेहतर विवरण लिख पाता :)

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

ज्यादातर निराशा इसलिए होती है क्योंकि जब मैं पहला पैराग्राफ पढ़ता हूं तो मुझे डीजा वु होता है:

... Object3D के onBeforeRender() के समान तरीका।

ठीक यही बात onBeforeRender() https://github.com/mrdoob/three.js/pull/9738 के साथ भी हुई , जब इस सुविधा को प्राप्त करने में एक वर्ष का समय लगा।

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

मुझे गलत मत समझो, मुझे नहीं लगता कि यह यहां के कामों में व्यर्थ है, मुझे लगता है कि मैं सिर्फ लोगों के विचारों को चलाना चाहता हूं और प्रतिक्रिया प्राप्त करना चाहता हूं। @unconed यह स्पष्ट है कि आप समस्या से परिचित हैं और आपने शायद अलग-अलग चीजों की कोशिश की है। क्या कारण हो सकता है कि आप जैसे उपयोगकर्ता ने अन्य पीआर को याद किया हो?

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

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

मुझे लगता है कि अगर आप शुरू कर रहे हैं... भले ही दृश्य किट बिल्कुल भयानक है, यह एपीआई वास्तव में अच्छा है:

https://developer.apple.com/documentation/scenekit/scnshadable

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

इस साल की शुरुआत में मैंने एक पुल अनुरोध किया था जो ऐसा ही कुछ ऐसा ही लगता है यदि ठीक वही चीज़ नहीं है:

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

ऐसा लगता है कि फर्क सिर्फ इतना है कि आप इसे कॉलबैक के माध्यम से कर रहे हैं? मैंने WebGLRenderer में अप्रयुक्त तर्क में टैप किया।

उस पीआर की अभी तक देखभाल नहीं कर पाने के लिए क्षमा करें @pailhead। मुझे लगता है कि मेरे दृष्टिकोण का मुख्य लाभ यह है कि इसके लिए केवल 3 नई लाइनों की आवश्यकता है।

ऐसा कहने के बाद, मैं अब कुछ समय आपके और @unconed सुझावों का अध्ययन करने में

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

जीज़, दो बार, एक ही देव के साथ? मैं स्पष्ट रूप से यहाँ कुछ गलत कर रहा हूँ, लेकिन क्या?

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

यह केवल आप ही नहीं @pailhead हैं। @bhouston के पास इस तरह के बहुत सारे PR हैं , यहाँ तक कि

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

यह सब प्रबंधित करना और प्रत्येक पीआर को वह ध्यान देना कठिन है जिसके वे हकदार हैं।

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

अब आप इसका जिक्र करें... हाँ, ज़ूम इन करने पर नए MacBook Pro पर 10fps पर चलता है

मुझे लगता है कि यह छाया और रैंड, पाप कॉस और सामान है, लेकिन हाँ ऐसा लगता है कि यह बहुत अधिक हिट लेता है।

किसी भी तरह से, मुझे आश्चर्य है कि आपने इसे तीन पंक्तियों में खींच लिया, मैं इस बात पर बहुत अधिक ध्यान केंद्रित कर रहा था कि कैसे सामग्री परम वर्दी में बदल जाती है और उस पैटर्न का पालन करती है। अंतर यह है कि मैं शब्दकोश की तरह एक वैकल्पिक ShaderLib प्रदान करता हूं, इसलिए #include <> अलग कोड लाता है। ऐसा होने से पहले आप शामिल को हटा दें, और इसे glsl से बदल दें। मुझे लगता है कि यदि आप शेडर के चारों ओर किसी प्रकार का रैपर लौटाते हैं, तो शायद यह वाक्यविन्यास क्लीनर हो सकता है (केवल replace() बजाय खंड नाम + glsl प्रदान करें। लेकिन यह दूसरे की तरह अधिक दिख सकता है .

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

@ असंबद्ध

मुझे लगता है कि onBeforeCompile() से एक लाभ यह है कि भौतिक गुण अपरिवर्तित रहते हैं। तो यह अंतर्निर्मित सामग्रियों को विस्तारित करने जैसा लगता है।

export class MyMeshPhongMaterial extends MeshPhongMaterial {
  constructor( parameters ) {
    super( parameters );
    this.onBeforeCompile = function ( shader ) {
      shader.vertexShader = shader.vertexShader.replace(
        '#include <begin_vertex>',
        'vec3 transformed = vec3( position.x + sin( position.y ) / 2.0, position.y, position.z );'
      );
    };
  }
}

var material = new MyMeshPhongMaterial();
material.color.setRGB( 1, 0, 0 ); // this still works

ShaderLib साथ खिलवाड़ वास्तव में मुश्किल है। हालांकि हमेशा के लिए अपरिवर्तित हुक जोड़ना संभव होना चाहिए:

    #include <begin_vertex>
    % vertex %
    #include <morphtarget_vertex>
    #include <skinning_vertex>
    % transformed_vertex %
    #include <project_vertex>
    % projected_vertex %

प्रतिस्थापित कोड यह बन जाएगा:

this.onBeforeCompile = function ( shader ) {
  shader.vertexShader = shader.vertexShader.replace(
    '% vertex %',
    'transformed.x += sin( position.y ) / 2.0;'
  );
);

फिर हम ऐसे किसी भी हुक को हटा देंगे जिसका उपयोग संकलन से पहले नहीं किया गया है, निश्चित रूप से।

प्रति उदाहरण ShaderChunks की तुलना में यह कैसा दिखता है

//given some material
var material = new THREE.MeshNormalMaterial();

//and some shader snippet
var myShader = [
    'float theta = sin( time + position.y ) / 2.0;',
    'float c = cos( theta );',
    'float s = sin( theta );',
    'mat3 m = mat3( c, 0, s, 0, 1, 0, -s, 0, c );',
    'vec3 transformed = vec3( position ) * m;', //and making assumptions about THREE's shader framework
    'vNormal = vNormal * m;'
].join( '\n' );

https://github.com/mrdoob/three.js/pull/10791 Material.defines दृष्टिकोण के समान:

material.shaderIncludes = {

        begin_vertex: myShader,

    //uv_pars_vertex: [
    //  THREE.ShaderChunk['uv_pars_vertex'], //this doesn't have to be
    //  "uniform float time;",
    //].join('\n')
};

material.shaderUniforms = { time: { value: 0, type: 'f' || 'float' } }; //because this could just inject it in the right place (but needs type)

_यह केवल खंड नामों का एक शब्दकोश है, और वर्दी वस्तु है। यहां स्ट्रिंग मैनिपुलेशन "मैं इस खंड का पुन: उपयोग करना चाहता हूं, और इसके ऊपर कुछ करना चाहता हूं" की तर्ज पर अधिक है।

यह जनसंपर्क:

material.onBeforeCompile = function ( shader ) {

    shader.uniforms.time = { value: 0 };

    shader.vertexShader = 'uniform float time;\n' + shader.vertexShader; //this feels hacky

    shader.vertexShader = shader.vertexShader.replace( //this is more verbose
        '#include <begin_vertex>',
        myShader
    );

};

मुझे लगता है कि onBeforeCompile() से एक लाभ यह है कि भौतिक गुण अपरिवर्तित रहते हैं।

यह अन्य पीआर में समान काम करता है, इसलिए मुझे लगता है कि इससे कोई फर्क नहीं पड़ता कि यह कैसे किया जाता है।

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

यदि uv_pars_vertex भ्रमित करने वाला है, तो मुझे लगता है कि पूछने के लिए एक अच्छा प्रश्न है:

"मैं अपने कस्टम जीएलएसएल फ़ंक्शन को कहां इंजेक्ट करूं, जैसे float rand( vec2) ?"

तब यह समझ में आ सकता है https://github.com/mrdoob/three.js/pull/11050

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

इस तरह से अमूर्तता की ओर जाना बेहतर होगा, lightingPhase , objectTransformation , perspectiveTransformation आदि हुक रखें। या कम से कम एक guaranteedToBeAboveMainButBelowCommonsAndExtensionCalls डमी चंक जो हर शेडर प्रोग्राम में शामिल है। ऐसा लगता है कि आप इसके लिए % vertex % साथ जा रहे हैं? लेकिन मैं उस वाक्य रचना से अपरिचित हूँ।

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

मैं जिस फ़ंक्शन को इंजेक्ट कर रहा हूं, उसके अंदर कॉमन्स चंक में घोषित फ़ंक्शन का उपयोग कैसे करूं?

हो सकता है कि आप वर्दी को पूरे शेडर में तैयार करने की तुलना में खुद को अधिक स्ट्रिंग मैनिपुलेशन कर सकें।

मुझे थोड़ा सोचना पड़ा और अधिकांश शेडर्स को देखने के लिए यह पता लगाने के लिए कि uv_pars_vertex मेरी सामग्री विस्तार करने के लिए एक सुविधाजनक जगह है।

मुझे नहीं लगता कि इसके आसपास कोई रास्ता है जब तक कि हम ओवर-इंजीनियर न हों। % vertex % साथ विचार यह है कि हुक का नामकरण करके थोड़ी मदद करने की कोशिश करें और कमोबेश आपको बताएं कि आप किस स्थिति में कोड इंजेक्ट कर रहे हैं, लेकिन यह दस्तावेज करना कठिन होगा कि किस बिंदु पर कौन से चर उपलब्ध हैं .

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

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

जैसे ही हम साथ जाते हैं, इसे शायद दोबारा करने की आवश्यकता होगी लेकिन इन पंक्तियों के साथ कुछ:

#ifdef PHASE_FOO

#include <shader_foo> 
//someGlobalStruct.mvPosition = modelViewMatrix * myLogic( transformed );
//if there is glsl provided for phase "foo" document that it should operate on "transformed" 
//and that it should return "mvPosition" 
#end including <shader_foo>

#else 

  //default
  #ifdef USE_SKINNING

    vec4 mvPosition = modelViewMatrix * skinned;

  #else

    vec4 mvPosition = modelViewMatrix * vec4( transformed, 1.0 );

  #endif

#ifdef PHASE_BAR

#include <something_like_this>
//mvPosition = myPostDefaultTransformationLogic( mvPosition );

#endif

gl_Position = projectionMatrix * mvPosition;

#endif

बेशक ifdefs और शामिल हैं शायद इस तरह काम नहीं करेंगे। लेकिन मैं इसे दूसरे दृष्टिकोण के साथ अपेक्षाकृत सीधे आगे देख सकता हूं। हम खाली स्ट्रिंग्स के साथ #include <some_phase> हमेशा जोड़ सकते हैं। #ifdef s का उपयोग करके ट्रिगर होने वाली चीज़ों को प्रबंधित करने में कुछ मदद कर सकता है। तो उदाहरण के लिए, यदि आप "vertex_transformation" चरण के लिए तर्क प्रदान करते हैं, तो शेडर जो कुछ भी प्रदान करता है उसे परिभाषित करेगा। जीएलएसएल के साथ प्रत्येक खंड क्या करता है, इसका दस्तावेजीकरण समग्र रूप से सहायक होगा। अमूर्तता में आगे जाने के बिना, मुझे लगता है कि इस नक्शे को अब कैसे संरचित किया जाता है, यह बहुत अच्छा होगा।

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

हमारे पास पहले से ही प्रत्येक सामग्री पर परिभाषित सामग्री उपलब्ध है। https://github.com/mrdoob/three.js/issues/10764 संशोधित करने के लिए सुझाव दिया THREE.ShaderLib और फिर एक को परिभाषित .defines एक का एक उदाहरण पर संपत्ति Material । दी, संपत्ति तब तक अनिर्दिष्ट थी जब तक मैंने प्रविष्टि नहीं लिखी (लेकिन आपने इसे मंजूरी दे दी :)), और अभी भी

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

स्मार्ट-गधा बनने की कोशिश नहीं कर रहा है बल्कि एक उदाहरण के साथ आने की कोशिश कर रहा है। मैं ज्यादातर ShaderMaterial साथ परिभाषित करता हूं लेकिन यह सभी सामग्रियों को प्रभावित करता है, सिर्फ इसलिए कि WebGLRenderer काम करता है। कोई तर्क नहीं है जो कहता है:

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

मुझे पूरा यकीन नहीं है कि इसे तोड़ा जा सकता है, हालांकि मुझे कोशिश करनी होगी।

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

इंस्टेंसिंग एक और उदाहरण था:

ओह, मैं ANGLE_INSTANCED_ARRAYS का उपयोग करना चाहता हूं, तीन इसकी छाया या पीबीआर सामग्री के साथ इसका समर्थन नहीं करते हैं, मुझे बस इन दो पंक्तियों को जोड़ने दें, और इसे मेरे लिए काम करने दें"

मुझे यह देखकर खुशी हो रही है कि यह सुविधाएँ अंततः तीन.js पर आ रही हैं :)। हां मैंने एक yet another material modifier PR भी बनाया (https://github.com/mrdoob/three.js/pull/7581) यह इतना पुराना था कि कोड अब प्रासंगिक नहीं है, लेकिन मूल रूप से @mrdoob जैसे हुक
मुझे पूर्वनिर्धारित हुक का विचार पसंद है क्योंकि यह समझना आसान है कि आप क्या संशोधित कर रहे हैं क्योंकि मेरा मानना ​​​​है कि अधिकांश लोग जो इस सुविधा का उपयोग करना चाहते हैं, वे इसे पूरी तरह से फिर से लिखने के बजाय डिफ़ॉल्ट सामग्री को "थोड़ा" संशोधित करना चाहते हैं।

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

@fernandojsg किसी भी मौके पर आप # 10791 देख सकते हैं, फीडबैक दे सकते हैं, यह आपके द्वारा किए गए कार्यों के समान ही सुपर लगता है, सिवाय इसके कि मैंने अतिरिक्त हुक को मुख्य के बाहर रखा है (आपके "pre_vertex" जैसा कुछ) और थोड़ा और प्रबंधन है।

@fernandojsg मैं आपके पीआर के बारे में भूल गया था। मुझे लगता है कि आपका पीआर काफी हद तक दिखता है कि मैं इसे कैसे काम करना शुरू कर रहा था। अवचेतन?

स्मार्ट-गधा बनने की कोशिश नहीं कर रहा है बल्कि एक उदाहरण के साथ आने की कोशिश कर रहा है। मैं ज्यादातर ShaderMaterial साथ परिभाषित करता हूं लेकिन यह सभी सामग्रियों को प्रभावित करता है, सिर्फ इसलिए कि WebGLRenderer काम करता है।

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

#7581 फिर से पढ़ना... https://github.com/mrdoob/three.js/commit/e55898c27a843f69a47e602761c60d9bbe91ee35 के शीर्ष पर हम % HOOKS % जोड़ सकते हैं और फिर इस तरह एक वर्ग बना सकते हैं:

THREE.ExtendedMaterial = function ( material, hooks ) {

    material.onBeforeCompile = function ( shader ) {
        var vertexShader = shader.vertexShader;
        var fragmentShader = parameters.fragmentShader;
        for ( var name in hooks ) {
           vertexShader = vertexShader.replace( '%' + name + '%', hooks[ name ] );
           fragmentShader = fragmentShader.replace( '%' + name + '%', hooks[ name ] );
        }
        shader.vertexShader = vertexShader;
        shader.fragmentShader = fragmentShader;
    };

    return material;

};

तब हम यह कर सकते हैं:

```जेएस
वर सामग्री = नया तीन। विस्तारित सामग्री (
नया तीन। मेश बेसिक मटेरियल (),
{ शीर्ष: 'रूपांतरित। x + = पाप (स्थिति। वाई) / 2.0;' }
);

तो सवाल यह है कि हमारे पास क्या हुक होना चाहिए?

VERTEX
TRANSFORMED_VERTEX
PROJECTED_VERTEX

NORMAL
TRANSFORMED_NORMAL

FRAGMENT_UNIFORMS
INPUT_FRAGMENT
OUTPUT_FRAGMENT

@mrdoob एक उदाहरण के रूप में, आप इस सार में देख सकते हैं कि इंस्टेंसिंग का समर्थन करने के लिए कोड को MeshBasicMaterial वर्टेक्स शेडर में इंजेक्ट करने की आवश्यकता है।

और यहाँ बाकी सामग्री के लिए :)

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

VERTEX_UNIFORMS बहुत अधिक विचारणीय लगता है, आपको एक फ़ंक्शन, एक विशेषता या भिन्न कहां जोड़ना चाहिए? PRE_VERTEX या कुछ और?

NORMAL_MAP निश्चित रूप से आवश्यक है

vert:

PRE_VERTEX
VERTEX
TRANSFORMED_VERTEX
PROJECTED_VERTEX

NORMAL
TRANSFORMED_NORMAL

UV

fragment:

PRE_FRAGMENT
INPUT_FRAGMENT
LIGHT
NORMAL

OUTPUT_FRAGMENT

VERTEX_UNIFORMS बहुत अधिक विचारणीय लगता है, आपको एक फ़ंक्शन, एक विशेषता या भिन्न कहां जोड़ना चाहिए? PRE_VERTEX या कुछ और?

हम्म, राय? ऐसा कैसे?

attribute vec4 aMyAttribute; एक समान नहीं है :)

float myRand( vec4 foo ) { /*logic*/ return vec4(bar,baz)} वर्दी नहीं है

varying vec3 vMyVarying; भी वर्दी नहीं है

या तो बहुवचन नहीं, या वर्दी बिल्कुल नहीं

"इंजेक्शन" विशेषताओं के लिए उपयोग का मामला क्या है?
क्या आपको इसके बजाय geometry.addAttribute( 'aMyAttribute', ... ) का उपयोग नहीं करना चाहिए?

मुझे नहीं पता था कि आपको इसे घोषित करने की आवश्यकता नहीं है। अभी भी भिन्नता और कार्य छोड़ता है?

अभी भी भिन्नता और कार्य छोड़ता है?

अच्छी बात।

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

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

मुझे नवीनतम परिवर्तन पसंद हैं, यह अभी भी सरल और सुरुचिपूर्ण है। मैं @pailhead से सहमत https://github.com/mrdoob/three.js/pull/7581 में मेरे पास preMainVertex preMainFragment को विश्व स्तर पर इंजेक्ट किया जाना था ताकि आप उन्हें अलग-अलग और कार्यों के लिए उपयोग कर सकें। संभवत: globalVertex/Fragment या इससे मिलता-जुलता नाम बेहतर हो सकता है।

GLOBAL_VERTEX और GLOBAL_FRAGMENT अच्छा लगता है

ठीक उसी तरह मैंने उन्हें दूसरे पीआर 😆 में नाम दिया

@pailhead लेकिन अब आप अपने कोड को मर्ज करने का रहस्य जानते हैं: बस एक पीआर खोलें, इसे कुछ समय के लिए वहीं छोड़ दें, फिर @mrdoob के लिए कुछ ऐसा ही करने के बारे में सोचने के लिए प्रतीक्षा करें, उसके पीआर की प्रतीक्षा करें और फिर सटीक संदर्भ में वहां टिप्पणी करें ठीक उसी तरह जैसे आपने अपने पीआर पर किया था ताकि वह सोच सके कि यह उसका विचार था, वह इसे जोड़ देगा, मर्ज कर देगा ... लाभ!

अब गंभीरता से मुझे वह नाम भी पसंद हैं और इसके साथ ही मेरा मानना ​​है कि हम जाने के लिए तैयार हैं, या क्या मुझे कुछ याद आ रहा है? मैं उदाहरण को अपने पीआर से इस नए कोड में बदलने की कोशिश करूंगा;)

कोड में आने के बारे में हिस्सा ठीक है, समयरेखा थोड़े बंद है। #7581 लगभग दो साल पहले सुझाया गया था। https://github.com/mrdoob/three.js/issues/10789 में संदर्भित नहीं किया गया था, इसलिए शायद रडार से बाहर हो गया। मैंने इसे टक्कर मार दी होगी या इसे फोर्क किया होगा।

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

फायदा!

क्या लाभ? मैं

कोड में आने के बारे में हिस्सा ठीक है, समयरेखा थोड़े बंद है। #7581 लगभग दो साल पहले सुझाया गया था। https://github.com/mrdoob/three.js/issues/10789 में संदर्भित नहीं किया गया था, इसलिए शायद रडार से बाहर हो गया। मैंने इसे टक्कर मार दी होगी या इसे फोर्क किया होगा।

क्या? आपने नया पीआर बनाने से पहले सभी खुले पीआर की जांच नहीं की? #ट्रोलोलोल

सच :)

ठीक है सूची में डायल करें और इसे जल्द से जल्द प्राप्त करें: डी

क्या यह शेडर (उदाहरण के लिए) होगा:

#include <shadowmap_pars_vertex>

void main() {

    #include <begin_vertex>
    #include <project_vertex>
    #include <worldpos_vertex>
    #include <shadowmap_vertex>

}

ऐसे दिखते हैं:

#include <shadowmap_pars_vertex>

void main() {

    % begin_vertex %
    % project_vertex %
    % worldpos_vertex %
    % shadowmap_vertex %

}

उम्म मुझे यकीन नहीं है कि उन सभी को प्रतिस्थापित करें या कुछ मौजूदा व्यवहार को छोड़कर कोड को इंजेक्ट करें:

#include <shadowmap_pars_vertex>

%GLOBAL_VERTEX% 
void main() {
       %PRE_VERTEX% 
    #include <begin_vertex>
...
}

मेरा प्रारंभिक दृष्टिकोण अतिरिक्त कोड को इंजेक्ट करना था, जिसमें बाकी को अछूता छोड़ दिया गया था।

तो % hook % सिर्फ वास्तविक हुक के लिए है, अगर कोई <begin_vertex> को बदलना चाहता है तो उन्हें अभी भी इसे एक स्ट्रिंग में देखना होगा, यानी। एक begin_vertex हुक नहीं होगा?

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

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

वे दो हैं जिनके बारे में मैं सोच सकता हूं, मुझे आश्चर्य है कि क्या और भी हैं।

तो % hook % सिर्फ वास्तविक हुक के लिए है, अगर कोई <begin_vertex> को बदलना चाहता है तो उन्हें अभी भी इसे एक स्ट्रिंग में देखना होगा, यानी। एक begin_vertex हुक नहीं होगा?

आप दोनों को बदल सकते हैं। वर्तमान कोड पहले से ही आपको जो कुछ भी बदलने देता है। %HOOK% वाले सुविधा के लिए हैं।

जैसा कि मैंने #११५६२ में उल्लेख किया है, बदली जा सकने वाले शेडर विखंडू की अवधारणा के बारे में कैसे?

उदाहरण:

const material = new THREE.MeshPhongMaterial({
  color: 0xffffff,
  map: texture,

  parts: {
    frag: {
      map_pars_fragment: `
        uniform sampler2D map;
        uniform sampler2D map2;
     `,

      map_fragment: `
        vec4 texelColor = texture2D( map, vUv );
        vec4 texelColor2 = texture2D( map2, vUv );

    texelColor = mapTexelToLinear( 
          mix( texelColor, texelColor2, progress)
        );

    diffuseColor *= texelColor;
      `
    }
  }
});

material.uniforms.progress = {value: 1};
material.uniforms.map2 = {value: texture2};

1 सामग्री पर कई बनावटों के बीच संक्रमण का कोड कितना सरल हो सकता है।

इसे आसानी से लागू किया जा सकता है और अनावश्यक कोड बनाने से बचा जा सकता है।

@ साशा240100

https://github.com/mrdoob/three.js/pull/10791 बिल्कुल वैसा ही दिखता है जैसा आप सुझाव दे रहे हैं, सिवाय parts को shaderChunks कहा जाता है और यह इसे एक के रूप में नहीं लेता है तर्क।
:roll_eyes:

आपको frag{} शब्दकोश की भी आवश्यकता नहीं है, क्योंकि भाग पहले से ही चिह्नित हैं। उन सभी के पास _fragment और _vertex ।

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

@pailhead हां, आइए frag: {} ड्रॉप करें। मैंने इसे तर्क के रूप में इस्तेमाल किया क्योंकि सामग्री शेडर को जोड़ने से पहले इसे पारित किया जाना चाहिए। इस मामले में हम संयोजन के बाद मौजूदा भागों को बदलने से बच सकते हैं।

हम वास्तव में दोनों को जोड़ सकते हैं: तर्क के रूप में और संपत्ति के रूप में। जैसे color करता है

यह अभी कहाँ है? मुझे लगता है कि उदाहरण .replace() और मुझे कोई हुक/बदली जाने योग्य भाग नहीं दिख रहा है? @mrdoob

इस पर अभी तक वापसी नहीं हो पाई है।

क्या आप % hook % चीज़ के लिए पीआर करना चाहेंगे?

क्या आप उपरोक्त टिप्पणी से विस्तारित सामग्री चाहते हैं?

THREE.ExtendedMaterial = function ( material, hooks ) {

    material.onBeforeCompile = function ( shader ) {
        var vertexShader = shader.vertexShader;
        var fragmentShader = parameters.fragmentShader;
        for ( var name in hooks ) {
           vertexShader = vertexShader.replace( '%' + name + '%', hooks[ name ] );
           fragmentShader = fragmentShader.replace( '%' + name + '%', hooks[ name ] );
        }
        shader.vertexShader = vertexShader;
        shader.fragmentShader = fragmentShader;
    };

    return material;

};

हुक के लिए जगह चुनना और उन्हें दस्तावेज करना वास्तव में इतना छोटा नहीं हो सकता है? मैं शायद hooks को chunks और अभी के लिए global_vert और global_frag के अतिरिक्त, शामिल की तलाश करूं? अब कौन सा है कि मैं यह लिखा है, ऐसा लगता है कि लगता है यहां तक कि तीन की जिम्मेदारी नहीं होना चाहिए, लेकिन दूसरी ओर यह ठूंठ हैं THREE.ExtendedMaterial के लिए % hook % भविष्य में?

मुझे नहीं पता कि आप थ्री.बीएएस एक्सटेंशन के बारे में जानते हैं या नहीं। यह मूल सामग्री में प्लेसहोल्डर का उपयोग करता है जिसे अनुकूलित सामग्री से सरणियों के रूप में एक्सेस किया जा सकता है, जैसे:

  var material = new BAS.PhongAnimationMaterial({
    flatShading: true,
    vertexColors: THREE.VertexColors,
    side: THREE.DoubleSide,
    uniforms: {
      uTime: {type: 'f', value: 0}
    },
    vertexFunctions: [
      // cubic_bezier defines the cubicBezier function used in the vertexPosition chunk
      BAS.ShaderChunk['cubic_bezier'],
      BAS.ShaderChunk['quaternion_rotation']
    ],
    vertexParameters: [
      'uniform float uTime;',
      'attribute vec2 aDelayDuration;',
      'attribute vec3 aStartPosition;',
      'attribute vec3 aEndPosition;',
      'attribute vec3 aControl0;',
      'attribute vec3 aControl1;',
      'attribute vec4 aAxisAngle;'
    ],
    vertexInit: [
      'float tProgress = mod((uTime + aDelayDuration.x), aDelayDuration.y) / aDelayDuration.y;',
      'vec4 tQuat = quatFromAxisAngle(aAxisAngle.xyz, aAxisAngle.w * tProgress);'
    ],
    vertexPosition: [
      'transformed = rotateVector(tQuat, transformed);',
      'transformed += cubicBezier(aStartPosition, aControl0, aControl1, aEndPosition, tProgress);'
    ]
  });

मुझे यह तथ्य पसंद है कि यह सरल सम्मेलनों पर आधारित है: vertexInit और fragmentInit उदाहरण के लिए मुख्य() फ़ंक्शन के शीर्ष पर होंगे। वर्दी या विशेषताओं को परिभाषित करने के लिए vertexParameters और fragmentParameters शेडर के शीर्ष पर हैं। vertexFunctions और fragmentFunctions मुख्य() फ़ंक्शन से पहले हैं। और इसी तरह सामान्य, स्थिति आदि के लिए...

जैसा कि आप स्थिति में देख सकते हैं, आप अंतिम स्थिति बदलने के लिए चर transformed बदलते हैं। उदाहरण के लिए, सामान्य ( objectNormal ) या रंगों ( diffuseColor ) के लिए समान बात।

फोंग सामग्री इस तरह दिखती है, केवल प्लेसहोल्डर्स जोड़ती है: https://github.com/zadvorsky/three.bas/blob/master/src/materials/PhongAnimationMaterial.js

हाय दोस्तों, मैं कॉनवो का अनुसरण करने की कोशिश कर रहा था, लेकिन ईमानदारी से मैं हार गया क्योंकि मैं फ्रंट एंड से आया हूं न कि गेम देव से।

मैं एक एमटीएल लोड करने की कोशिश कर रहा हूं और मुझे मिल रहा है:

material.onBeforeCompile.toString() अपरिभाषित है।

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

# Blender MTL File: 'goblin.blend'
# Material Count: 1

newmtl Material
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.640000 0.640000 0.640000
Ks 0.001617 0.005682 0.002517
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 2
map_Kd Normal.png

कंसोल आउटपुट है:

THREE.WebGLRenderer 87
bundle.js:54570 OBJLoader: 29.447998046875ms
bundle.js:28429 Uncaught TypeError: Cannot read property 'toString' of undefined
    at WebGLPrograms.getProgramCode (bundle.js:28429)
    at initMaterial (bundle.js:32350)
    at setProgram (bundle.js:32542)
    at WebGLRenderer.renderBufferDirect (bundle.js:31605)
    at renderObject (bundle.js:32335)
    at renderObjects (bundle.js:32308)
    at WebGLRenderer.render (bundle.js:32072)
    at bundle.js:9658
    at bundle.js:53976
    at XMLHttpRequest.<anonymous> (bundle.js:40153)

और मैं जिस कोड का उपयोग कर रहा हूं वह मुख्य रूप से है:

OBJLoader(THREE);

const modelLoader = new THREE.OBJLoader();
const textureLoader = new MTLLoader();
textureLoader.setTexturePath( 'models/' );
    textureLoader.load('models/goblin.mtl', function( materials ) {

            materials.preload();

            modelLoader.setMaterials( materials );
            modelLoader.load('models/goblin.obj', function ( obj ) {
                 scene.add( obj );
                renderer.render( scene, camera );


            });

        }); 


    renderer.render( scene, camera );

}

क्या यह मॉडल में कोई समस्या है? तीन में? एमटीएल लोडर में? इसका समाधान है?

किसी भी सहायता की सराहना की जाएगी।
धन्यवाद।

क्या हमें material.shader = shader में material.onBeforeCompile(shader=>...) जैसा कुछ करना है?

मुझे लगता है कि यह कुछ हद तक भद्दा लगता है, किसी बिंदु पर दूसरे सुझाव पर दोबारा गौर करने लायक हो सकता है :)

@jjalonso

ऐसा लगता है कि यह एक बग है:

https://stackoverflow.com/questions/46787166/react-and-three-js-mtlloader-material-onbeforecompile-is-undefined

यह इसके कारण हो रहा है, लेकिन क्या कारण है कि Material में यह func नहीं है?
https://github.com/mrdoob/three.js/blob/35a26f178c523514673d992da1aece23c1cfca6e/src/renderers/webgl/WebGLPrograms.js#L244

@mrdoob

क्या यह संभव है कि इन विस्तारित शेड्स को सही ढंग से कैश नहीं किया जा रहा है? मैं दो अलग-अलग सामग्रियों का उपयोग करने की कोशिश कर रहा हूं, एक में dithering_fragment बदल गया है, दूसरा नहीं। जब मैं दोनों को दृश्य में जोड़ता हूं, तो ऐसा प्रतीत होता है कि dithering_fragment खंड के बिना केवल एक का उपयोग किया जा रहा है।

मैं इस पहेली के साथ इसे फिर से बनाने में असमर्थ रहा हूँ
https://codepen.io/anon/pen/KQPBjd

लेकिन मेरे उदाहरण में इस कोड के साथ

const dithering_fragment = 
`
gl_FragColor.xyz *= foobar
`

// in onBeforeCompile
console.log(shader.fragmentShader)



md5-0f1a3ac67268b230968df20abdbd03d1



/**
#if defined( DITHERING )
  gl_FragColor.rgb = dithering( gl_FragColor.rgb );
#endif

gl_FragColor.xyz *= foobar

}
*/

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

यह इसके कारण है:

https://github.com/mrdoob/three.js/blob/35a26f178c523514673d992da1aece23c1cfca6e/src/renderers/webgl/WebGLPrograms.js#L244

मेरे पास दोनों सामग्रियों को प्रदान किए गए कुछ तर्क के साथ एक ही कार्य है, तर्क के लिए चर कॉलबैक के दायरे से बाहर हैं, इस प्रकार मेरी दोनों सामग्रियों को एक ही हैश मिलता है?

array.push( material.onBeforeCompile( obtainShaderSomehow ) )

https://github.com/mrdoob/three.js/pull/10791 ने इसे इस तरह हल किया:

https://github.com/pailhead/three.js/blob/879d52349bd5ef72c64fc962d8ca26bacaf489bf/src/renderers/webgl/WebGLPrograms.js#L242

यदि मैं global_vertex और global_fragment प्लेसहोल्डर्स/हुक को हटा दूं तो क्या आप अन्य पुल अनुरोध पर पुनर्विचार करेंगे? उनके साथ यह बहुत सारी फाइलों को छूता है, उनके बिना, यह कम कोड है। तीन लाइनें नहीं, लेकिन यह सही ढंग से हैश :)

इस फिडेल में #41 कमेंट करें https://codepen.io/anon/pen/KQPBjd
और दृश्य में अन्य जाल की सामग्री बदल जाएगी।

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

क्या इसे हाल की रिलीज़ में शामिल किया गया है, या यह सब अभी भी विकास में है?

@cdhanna http://threejs.org/examples/#webgl_materials_modified

@mrdoob मुझे लगता है कि .onBeforeCompile() साथ हैक की गई सामग्री को क्रमबद्ध करना मुश्किल (या असंभव) है। क्या आपको लगता है कि उपयोगकर्ताओं को ShaderMaterial उपयोग करना चाहिए यदि वे पूर्ण कार्यात्मक (रेंडर, कॉपी, क्लोन, सीरियलाइज़, और इसी तरह) संशोधित अंतर्निर्मित सामग्री चाहते हैं?

_कृपया निम्नलिखित को सबसे अच्छे, रचनात्मक, गैर-टकराव वाले तरीके से पढ़ें_ :)

@takahirox यह दावा क्यों करता रहता है?

मुझे लगता है कि हैक की गई सामग्री को क्रमबद्ध करना मुश्किल (या असंभव) है

जब आप onBeforeCompile साथ सामग्री को "हैक" करते हैं तो आप केवल वर्दी जोड़ते हैं जो किसी अन्य सामग्री के समान होती है। इसमें कोई फर्क नही है। यदि आप material.color क्रमबद्ध कर सकते हैं तो आप material.userData.myColor क्रमबद्ध क्यों नहीं कर सकते?

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

लेखों द्वारा उत्पन्न एक बहुत छोटे नमूने से, इस प्रयोग से ऐसा नहीं लगता कि लोग ShaderMaterial दृष्टिकोण का उपयोग करना चाहते हैं।

यह अभी दिमाग में आया? क्या कोई ऐसा परीक्षण मौजूद है जो साबित करता है कि यह कठिन या असंभव है? पसंद:

runSerializationTest( someMaterialWithOnBeforeCompile ).expect( something )

चूंकि onBeforeCompile विधि में बहुत ही मनमाना कोड हो सकता है, उस कॉलबैक को दृढ़ता से क्रमबद्ध करना निश्चित रूप से असंभव है। उदाहरण के लिए, विधि एक तुल्यकालिक XMLHttpRequest बना सकती है और परिणाम के साथ कुछ कर सकती है। मैं

हालांकि ... जिस तरह से इसका व्यावहारिक रूप से उपयोग किया जाता है (शेडर्स को पैच करने के लिए) मैं मानता हूं कि यह असंभव नहीं है। लेकिन आसान एपीआई (जैसे fn.toString() ) हैकी हैं, और मजबूत एपीआई अधिक जटिल हैं।

मुझे अभी भी समस्या समझ में नहीं आ रही है। इस दृष्टिकोण के बारे में कैसे:

rN लें MeshPhongMaterial था और उसके पास MeshStandardMaterial ।

आप MeshPhongMaterial यानी क्रमबद्ध कर सकते हैं। इस तरह एक JSON लिखें:

{
  color: 'red',
  specular: 'very',
  glossy: 'not much'
}

rN+1 लें

आप अभी भी दोनों को उसी तरह क्रमबद्ध कर सकते हैं:

//phong
{
  color: 'red',
  specular: 'very',
  glossy: 'not much'
}

//standard
{
  color:'red',
  shininess: 'shiny',
  metalness: 'not much'
}

आपने GLSL को MeshStandardMaterial से कहीं भी क्रमांकित नहीं किया है।

उसी तरह, किसी भी विस्तारित सामग्री को क्रमबद्ध करना।

//extended PhongMaterial
{
   color: 'red',
   specular: 'very',
   glossy: 'not much',
   hamburger: 'medium rare'
}

अक्रमांकन:

if ( data.userData.hamburger && HamburgerPhongMaterial )
   mat = new HamburgerPhongMaterial( data ) 
else{ 
   console.warn(`I'm terribly sorry, but you don't have the HamburgerPhongMaterial extension, using default fallback`)
   mat = new PhongMaterial( data ) 
}

मुझे यहां क्या समझ नहीं आ रहा है?

onBeforeCompile के रूप में ... उस कॉलबैक को क्रमबद्ध करें।

क्यों, आप इसे क्यों मानेंगे :) मुझे लगता है कि यह मेरे भ्रम की जड़ है, इस हुक को कोई विचार क्यों दिया गया है, यह भौतिक परिभाषा, विवरण, कुछ भी का हिस्सा नहीं है। इसका इंजन, प्लगइन्स, ऐप्स आदि से कुछ लेना-देना है, डेटा से नहीं।

आपके द्वारा ऊपर दिया गया उदाहरण मुझे ठीक लगता है, इसके लिए केवल यह आवश्यक है कि सामग्री को अक्रमांकन करने वाला उपयोगकर्ता कोड हैम्बर्गरफोंगमटेरियल के अस्तित्व के बारे में जानता हो? मुझे इससे कोई समस्या नहीं है, यदि आप #14099 के समान दृष्टिकोण अपनाते हैं और JSON और fromJSON को ओवरराइड करते हैं, तो यह आवश्यक रूप से API परिवर्तनों की भी आवश्यकता नहीं है।

हो सकता है कि हमने यहां @takahirox के प्रश्न की अलग-अलग व्याख्या की हो?

....onBeforeCompile() के साथ हैक की गई सामग्री को क्रमबद्ध करना कठिन (या असंभव) है। क्या आपको लगता है कि उपयोगकर्ताओं को ShaderMaterial का उपयोग करना चाहिए यदि वे पूर्ण कार्यात्मक (रेंडर, कॉपी, क्लोन, सीरियलाइज़, और इसी तरह) संशोधित अंतर्निर्मित सामग्री चाहते हैं?

मैं इसे अलग करने की कोशिश करूंगा:

• यदि उपयोगकर्ता एक सादे MeshStandardMaterial पर toJSON() को कॉल करता है, जहां GLSL जिसे इसके onBeforeCompile द्वारा संशोधित किया गया है, GLSL में परिवर्तन स्वचालित रूप से क्रमबद्ध नहीं होंगे।
• यदि उपयोगकर्ता कुछ अतिरिक्त गुणों के साथ MeshStandardMaterial को क्रमबद्ध करता है जो GLSL में परिवर्तन का संकेत देता है, और इसे कस्टम कोड के साथ लोड करता है जो जानता है कि उन अतिरिक्त गुणों के साथ क्या करना है, तो निश्चित रूप से यह ठीक है।
• कई अन्य विकल्प (ShaderMaterial, NodeMaterial, glTF's KHR_techniques_webgl , ...) मनमाने ढंग से कस्टम सामग्री को क्रमबद्ध करने के लिए उपलब्ध हैं।

अगर हम जिस मामले की बात कर रहे हैं, वह उनमें से एक नहीं है, तो मुझे लगता है कि मैं यहां गलत समझ रहा हूं। यदि यह लगभग #१४०९९ है, तो मैं (अभी भी) इसे विलय करने के पक्ष में हूं।

हम्म, मैं वास्तव में पहले दो के बीच अंतर नहीं कर रहा था। मैं कुछ ऐसा सोचने की कोशिश कर रहा हूं जिसके लिए वर्दी की आवश्यकता नहीं होगी, उदाहरण के लिए यह gl_FragColor.xyz /= gl_FragColor.a; हो सकता है। लेकिन मैं ऐसे परिदृश्य की कल्पना नहीं कर सकता जहाँ आप कुछ इस तरह ( सामग्री के साथ? ) ऐसा लगता है कि यह कुछ प्रभाव रेंडरर या कुछ के दायरे में आ जाएगा, भौतिक डेटा नहीं।

materials = loadSerializedMaterials()

effect = new Effect()

effect.load( 'alphaDivide').then(()=>materials.forEach(mat.onBeforeCompile = effect.getOnBeforeCompile('alphaDivide')))

दूसरा उदाहरण वह है जो मेरे मन में हमेशा से था। विभिन्न इनपुट के साथ, एक संकेत को क्रमबद्ध करें कि उनके साथ क्या करना है userData.extension === 'hamburger' ।

मुझे लगता है कि मैंने खराब लिखा है। मैं जो उल्लेख करना चाहता था वह है

• .onBeforeCompile() साथ हैक की गई अंतर्निहित सामग्री की प्रतिलिपि नहीं बनाई जाती है, क्लोन नहीं किया जाता है, उसी एपीआई में सही ढंग से क्रमबद्ध किया जाता है जिसमें अंतर्निहित सामग्री होती है'। इसे गैर-हैक की गई सामग्री के रूप में नियंत्रित किया जाता है।
• यदि उपयोगकर्ता सही परिणाम चाहते हैं, तो उन्हें उपयोगकर्ता पक्ष में कुछ अतिरिक्त कार्य करने की आवश्यकता है।
• यदि उपयोगकर्ता बिना किसी अतिरिक्त कार्य के तीन.जेएस कोर एपीआई के साथ हैक की गई अंतर्निहित सामग्री चाहते हैं, तो उन्हें अन्य विकल्पों के बारे में सोचना चाहिए, जैसे ShaderMaterial ।

मेरा प्रश्न विशिष्ट मामले के बजाय केवल .onBeforeCompile() की नीति के लिए है। मैं सीमा को स्पष्ट करना चाहता था और दस्तावेज़ में एक नोट जोड़ना चाहता था।

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

मुझे अभी भी लगता है कि ऊपर से मेरा प्रस्ताव ऐसा करने का एक वैध तरीका है, क्योंकि मुझे अन्य क्षेत्रों में भी यही समस्या का सामना करना पड़ा है (जैसे लक्ष्य के बीच गहराई बफर साझा करना भी ownThing || outsideThing साथ हल किया जा सकता है।

फ़ंक्शन को कैशिंग करने के बजाय, जो काम नहीं करता है, आप मूल रूप से userData कैश करेंगे लेकिन इसका एक सबसेट। userData.hamburger: 'rare' को कैश करने का कोई मतलब नहीं है लेकिन यह userData.effectOn: true". The खुद का इनपुट करता है | खुद का हिस्सा | खुद जो कुछ भी' इस समस्या का समाधान करेगा।

यह समस्या का समाधान भी करता है:

जैसा कि onBeforeCompile विधि में बहुत मनमाना कोड हो सकता है, उस कॉलबैक को दृढ़ता से क्रमबद्ध करना निश्चित रूप से असंभव है।

काफी समय हो गया है, लोगों ने onBeforeCompile उपयोग किया है, हमें अब तक पता होना चाहिए कि वहां किस तरह का मनमाना कोड मिल सकता है। मुझे लगता है कि यह केवल shader ऑब्जेक्ट पर संचालित होता है जिसे पास किया जाता है। आप उस ऑब्जेक्ट को म्यूट करते हैं, लेकिन केवल म्यूटेशन जो ShaderMaterial साथ समझ में आता है, वैसे भी एक प्रभाव होगा। कुछ gl सामान को स्वयं सेट करना शायद ओवरराइड हो जाएगा, और यह केवल एक चीज है जो मेरे दिमाग में आती है।

यह अनिवार्य रूप से एक pre three parse कदम है, जहां आपको अनिवार्य uniforms:{} इंटरफ़ेस के साथ खुद को शेडर को पार्स करने का मौका मिलता है, क्योंकि आपके पास यह Material ( defines:{} Material पर उपलब्ध नहीं है। defines:{} दूसरी ओर आप करते हैं, और दोनों ShaderMaterial में भाई-बहन हैं)।

आप इसे कैसे करते हैं, यानी जो भी मनमाना कोड है, कोई फर्क नहीं पड़ता। यह कुछ भी वापस नहीं करता है, लेकिन यह shader:{} और फिर रेंडरर इसका उपयोग करता है।

दृष्टिकोण जो मैं सुझाता हूं:

1. विभिन्न वर्गों में ownThing जोड़ें। THREE.WebGLRenderTarget में .ownStencilDepthBuffer । यहाँ, जैसा कि मैंने ऊपर सुझाव दिया है, यह ownGLSL:{} ownInput | ownUniforms कुछ संस्करण होगा। आप shader:{} ऑब्जेक्ट को बदलने के लिए मनमाने कोड की आवश्यकता को हटाते हैं:

इस तरह से दिया गया इनपुट जो WebGLRenderer (सुपर प्राइवेट) के अंदर से उत्पन्न होता है:

const shader = {
  uniforms: buildFromMaterial(mat),
  vs: getVSTemplate(key),
  fs: getFSTemplate(key)
}

यह परमाणु:

shader = onBeforeCompile( shader )

shader.vs //invalid GLSL
shader.uniforms //you got some extra ones that onBeforeCompile may have mutated, maybe removed some others

shader = ___parse(shader) //private step

shader.vs //valid glsl, (not a template)

compile(shader)

इस का उपयोग करें:

function parseShader(shader){
   return {
     uniforms: shader.uniforms,
     vs: parseChunks(shader.vs)
     fs: parseChunks(shader.fs)
   }
}
//FIX FOR HASHING BUG
function parseChunk( material, chunkName ){
  return material.ownChunks[chunkName] || THREE.ShaderChunks[chunkName]
}

//do whatever you want with the templates, maybe remove an `#include <>`
shader = onBeforeParse(shader)

shader.vs //template || valid glsl

shader = parseShader(shader) //sample OWN || PRIVATE 

shader.vs //valid GLSL 

//if you want to apply a regex on the entire valid glsl, or compile node material or something else
shader = onBeforeCompile( shader )

compile(shader)

1. WebGLRenderer ShaderMaterial अलावा किसी और चीज़ के बारे में न जानें।

आप जहां भी होंगे

const mat = new THREE.MeshBasicMaterial()
const sm = new THREE.ShaderMaterial()

पास होना

const mat = nodeMaterial.compile() //returns ShaderMaterial, with a friendly interface (same as StandardMaterial for example)

const mat = chunkMaterial.compile()

उपरोक्त सामग्री का टीएल: डॉ उपयोगकर्ता उस समय विशेष बिंदु की परवाह नहीं करता है जब "संकलन" (पार्स) होता है । मुझे लगता है कि वे इस बात की अधिक परवाह करते हैं कि क्या होता है, और जो होता है उसे एक मुट्ठी भर के लिए अलग किया जा सकता है यदि एक भी उपयोग का मामला नहीं है in: shaderString, out: shaderString । मुझे लगता है कि पाइपलाइन में उस विशेष बिंदु पर ऐसा करने का कारण जांच और समझने लायक है। ऐसा लगता है कि यह मदद करने से ज्यादा चीजों के रास्ते में आ रहा है।

@mrdoob मुझे लगता है कि .onBeforeCompile() साथ हैक की गई सामग्री को क्रमबद्ध करना मुश्किल (या असंभव) है। क्या आपको लगता है कि उपयोगकर्ताओं को ShaderMaterial उपयोग करना चाहिए यदि वे पूर्ण कार्यात्मक (रेंडर, कॉपी, क्लोन, सीरियलाइज़, और इसी तरह) संशोधित अंतर्निर्मित सामग्री चाहते हैं?

मुझे उम्मीद नहीं थी (माना जाता है) कि onBeforeCompile() का उपयोग क्रमबद्ध किया जाएगा ...

मैंने अभी-अभी onBeforeCompile का उपयोग करके कड़ी मेहनत की है। मेरे पास एक शेडर सहायक वर्ग है जो मुझे परिभाषित तरीके से अंतर्निर्मित शेडर्स में संशोधन करने की अनुमति देता है। मैं ऐसा करने के लिए onBeforeCompile विधि का उपयोग करता हूं। जाहिर है, जैसा कि पहली टिप्पणी में कहा गया है, WebGLProgram onBeforeCompile.toString() को हैश के रूप में उपयोग करता है। लेकिन चूंकि मेरा कार्य सामान्य है (यह चर के साथ वर्टेक्स और खंड शेडर्स के हिस्सों को प्रतिस्थापित करता है) onBeforeCompile.toString() अलग-अलग शेडर्स के लिए अलग नहीं दिखता है। इसका मतलब यह था कि मेरे सभी अलग-अलग शेड एक ही प्रोग्राम के रूप में कैश किए गए थे। एक eval कॉल और एक uuid और अब मेरे कार्य सभी अलग दिखते हैं। यह पता लगाने में हमेशा के लिए लग गया।

@donaldr https://github.com/mrdoob/three.js/issues/13192 देखें

क्या आप साझा कर सकते हैं कि आप eval का उपयोग कैसे कर रहे हैं? मैं इसके बारे में सोच रहा था लेकिन यह बहुत गंदा लग रहा था। आप मूल रूप से शरीर के शीर्ष पर const fdscxnmdrek435rkjl जोड़ सकते हैं और फिर eval कर सकते हैं?

इसका मतलब यह था कि मेरे सभी अलग-अलग शेड एक ही प्रोग्राम के रूप में कैश किए गए थे। एक eval कॉल और एक uuid और अब मेरे कार्य सभी अलग दिखते हैं। यह पता लगाने में हमेशा के लिए लग गया।

यह बहुत निराशाजनक लगता है, क्षमा करें। 😞 यदि आपको आवश्यक संशोधन करने की आवश्यकता है, तो ऐसा लगता है कि वे पुस्तकालय में ही समझ में आएंगे, कृपया खुले मुद्दों का भी स्वागत करें।

कृपया खुले मुद्दों का भी स्वागत करें।

क्या आप मौजूदा को फिर से खोलने पर विचार करेंगे? #13192 ऐसा ही प्रतीत होता है लेकिन इसे बंद कर दिया गया था :crying_cat_face: यह वास्तव में अच्छा होगा यदि एक कार्य को वहां पोस्ट किया गया था यदि इसे एक विशेषता समझा जाता था।

हम्म...

const _obc = shader => {...}
const obc = `
function (shader){
  const _${ hash() }
  ${ _obc.toString() }
  _obc(shader)
}
`
material.onBeforeCompile = eval(obc)

^क्या यह काम करेगा? मैंने कभी भी eval उपयोग नहीं किया।

सामग्री. customProgramCacheKey onBeforeCompile() माध्यम से संशोधित सामग्री के लिए शेडर प्रोग्राम को सशर्त बयानों के साथ साझा नहीं किया जाता है।

कृपया नए थ्रेड्स (जैसे #13446) में onBeforeCompile() संदर्भ में अन्य मौजूदा मुद्दों या संवर्द्धन पर चर्चा करें।