Three.js: 資料：onBeforeCompile（）に追加

WebGLProgram.jsがすでに多くの処理を行っている場合、カスタムの文字列操作を要求するのは少しハッキーに思えます。 関連するユースケースがあります。これは、既存の#includeをオーバーライドするのではなく、新しい#includeを追加することです。 実行時にTHREE.ShaderLibを変更することで、今日これを行うことができますが、同様に汚れているように感じます。

おそらく、両方のより良い解決策は、マテリアルにカスタムShaderLibを提供できるようにすることです。これにより、手動の文字列操作や永続的な破壊なしに、組み込みチャンクをオーバーライド/拡張​​できます。 それは他の用途のためのonBeforeCompileフックを排除するものではありませんが、あなたの例がやろうとしていることとより一致しているようです。

とはいえ、rawインクルードに基づくシェーダー構成は、バージョンごとに常に非常に脆弱になります。 すべてのスケルトンコード（ 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 };
    //...
  }
}

いずれの場合も、リリースごとにあまり変更しないように、組み込みのシェーダーの内部構成に依存する必要があります。 各インクルードはすでに偽装された関数であり、署名が正しく指定されていません。 インクルードレベルのオーバーライドではなく、関数レベルのオーバーライドを提供することで、両側ではるかにクリーンで保守しやすくなると思います。

今日は思った。

良い！ 2月10日にこのプルリクエストを行ったときもそう思いました。

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

唯一の違いは、コールバックを介してそれを行っていることだと思われますか？ WebGLRendererの未使用の引数を利用しました。

たとえば、threejsを法線マップで動作させるためにこれを使用するのが好きですが、これで解決するのは簡単だと思われるいくつかの問題をリンクしました。

私のブランチを見て、これを試してみるか、この非常に単純な例を確認してください（照明/影などを使用してカスタム変形をテストし、いくつかのユニフォームを追加するだけです）。

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

おそらく、両方のより良い解決策は、マテリアルにカスタムShaderLibを提供できるようにすることです。これにより、手動の文字列操作や永続的な破壊なしに、組み込みチャンクをオーバーライド/拡張​​できます。

https://github.com/mrdoob/three.js/pull/10791で何が起こっているかを正確に要約します。もっと良い説明を書けたらいいのにと思います:)

私はここで何が起こっているのかわからないことを認めなければなりません。 3つに貢献することをあきらめて、それを理解していなかった人を知っていると思いますが、今ではちょっとイライラしています。

私が最初の段落を読んだときに既視感を持っているので、主にイライラします：

... Object3DのonBeforeRender（）と同様の方法。

これとまったく同じことがonBeforeRender() https://github.com/mrdoob/three.js/pull/9738でも発生しました。この機能を導入するには、説得力のある1年がかかりました。

うわあ、2回、同じ開発者で？ 私は明らかにここで何か間違ったことをしていますが、何ですか？ 初めてビルドファイルがチェックインされたとき、どうしたらいいかわからなかったので、忘れてしまいました。 しかし、今回はこのプルリクエストに加えて、現在競合が発生していますが、簡単に解決でき、数か月間競合は発生しませんでした。

誤解しないでください、私はここの作品の虚栄心ではないと思います、私はただ人々によってアイデアを実行してフィードバックを得たいと思います。 @unconedあなたが問題に精通していて、おそらく別のことを試したことがあることは明らかです。 あなたのようなユーザーが他のPRを見逃した原因は何ですか？

マテリアルごとのshaderlibについてはかなり良いと感じましたが、シェーダー全体を文字列として表示/比較してキャッシュを把握する関数がレンダラーに1つ見つかりましたが、それについてはそれほど気分が良くありませんでした。 フィードバックがあったらいいのに...

例に欠陥がありましたか？ 頭は私の抽象的なスパイクボールよりも何が起こっているのかをはるかに明白にするかもしれませんが、例全体はより多くの地面を覆う影で機能します。 どういうわけか重いですが、多くの頂点でsin / cosが原因だと思います。

最初からやり直していると思います...シーンキットは絶対に恐ろしいですが、このAPIは本当に素晴らしいです：

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

ひどく文書化されていますが、もっと興味のある部分を見つけることはできませんが、基本的には、シェーダーのさまざまな段階でフックを抽象化しています。

今年の初めに、まったく同じではないにしても、似たようなことをするように見えるプルリクエストを行いました。

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

唯一の違いは、コールバックを介してそれを行っていることだと思われますか？ WebGLRendererの未使用の引数を利用しました。

まだそのPRの世話をすることができなくてすみません@pailhead。 私のアプローチの主な利点は、3つの新しい行しか必要としないことだと思います。

そうは言っても、私はあなたと@unconedの提案を研究するために少し時間を費やします。

これは間違いなくよりエレガントな感じで、たった3行です。 私はもう一方のパターンとは異なるパターンに従っていました。 もう少し冗長かもしれないと言うつもりでしたが、確かではありません。 もう1つの利点は、数か月前に行って良かったことだけだと思います:)

うわあ、2回、同じ開発者で？ 私は明らかにここで何か間違ったことをしていますが、何ですか？

申し訳ありません。 私が考えることができる唯一のことは、おそらく私が圧倒されたということです。 長い議論や複雑なPRでエネルギーを消費しすぎるかもしれないので、後でそれを残して、より単純なPRに移行することにしました。

@pailheadはあなただけではありません。 @bhoustonは、このようなのPR、でも@WestLangleyとMugen87 @の多くを持っていました。

繰り返しになりますが、私がPRが好きではないということではなく、PRには、その時点では提供できない注意が必要であるということです。 良い例はインスタンス化PRです。 私はなんとかそれを読む時間を見つけ、私自身の実験を行い、単純化を提案しました。 うまくいけば、私はすぐにそれを再訪することができるでしょう。

これらすべてを管理し、すべてのPRに彼らが値する注意を払うことは困難です。

例に欠陥がありましたか？ 頭は私の抽象的なスパイクボールよりも何が起こっているのかをはるかに明白にするかもしれませんが、例全体はより多くの地面を覆う影で機能します。 どういうわけか重いですが、多くの頂点でsin / cosが原因だと思います。

今あなたはそれについて言及します...ええ、ズームインすると新しいMacBookProで10fpsで動作します😮

影とランド、罪のコスなどだと思いますが、ヒットが多すぎるようです。

いずれにせよ、これを3行で実行したことに驚いています。私は、マテリアルパラメータがどのようにユニフォームに変換され、そのパターンに従うかに焦点を合わせすぎていました。 違いは、辞書のような代替のShaderLibを提供するため、 #include <>は異なるコードを取り込むことです。 これが発生する前にインクルードを削除し、glslに置き換えます。 シェーダーの周りにある種のラッパーを返す場合、おそらくこの構文はよりクリーンになる可能性があります（ replace()代わりにチャンク名+ glslを指定するだけです。しかし、他の構文のように見える可能性があります。 。

これがあれば本当にいいです。私はそれほど多くの3Dエンジンを使ったことがありませんが、ユニティとシーンキットにはこのようなものがあるようです。

@unconed

onBeforeCompile()利点の1つは、材料特性が変わらないことだと思います。 そのため、組み込みのマテリアルを拡張するような感じがします。

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)

_これはチャンク名とユニフォームオブジェクトの辞書にすぎません。 ここでの文字列操作は、「このチャンクを再利用して、その上で何かを実行したい」という方針に沿っています。

このPR：

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（）の利点の1つは、材料特性が変更されないことだと思います。

他のPRでも同じように動作するので、どのように行ってもかまわないと思います。

私が考えることができるおそらく無関係な利点の1つは、同じブロック内の同じレベルでマテリアルを操作するためのロジックを維持できることです。 どこかに色を変更するコードがあり、後でそのマテリアルにカスタムGLSLを追加する場合は、コードを追加して色のユニフォームを変更できます。 （テキストの壁をスキップ）

uv_pars_vertexが紛らわしい場合は、次の質問をすることをお勧めします。

「 float rand( vec2)ようなカスタムGLSL関数をどこに挿入しますか？」

次に、これは理にかなっているかもしれませんhttps://github.com/mrdoob/three.js/pull/11050

もう1つの議論は、GLSLを知っていると仮定し、THREEのシェーダーフレームワークを知っていると仮定すると、創造性を発揮し、どこに何を注入するかを考える必要があります。 uv_pars_vertexがマテリアルの拡張を行うのに便利な場所であることを理解するために、少し考えてほとんどのシェーダーを調べる必要がありました。

このようなものから抽象化に移行し、 lightingPhase 、 objectTransformation 、 perspectiveTransformationなどのフックを使用することをお勧めします。 または、すべてのシェーダープログラムに含まれている少なくともguaranteedToBeAboveMainButBelowCommonsAndExtensionCallsダミーチャンク。 % vertex %でそれを目指しているようですか？ しかし、私はその構文に慣れていません。

このPRは、現状では逆方向に進んでいるようです。 どこをタップする必要があるかを知ることに加えて、明示的に文字列を操作し、レンダラーがすでに行っている作業の一部を繰り返す必要があります。 また、最初の質問に加えて別の質問をする場合

挿入している関数内で、commonsチャンクで宣言されている関数を使用するにはどうすればよいですか？

シェーダー全体にユニフォームを追加するだけでなく、より多くの文字列操作を行っていることに気付くかもしれません。

uv_pars_vertexがマテリアルの拡張を行うのに便利な場所であることを理解するために、少し考えてほとんどのシェーダーを調べる必要がありました。

私たちがオーバーエンジニアリングしない限り、それを回避する方法はないと思います。 % vertex %のアイデアは、フックに名前を付けて、コードを挿入している状態を多かれ少なかれ教えてくれることですが、どの変数がどの時点で使用可能であるかを文書化するのは難しいでしょう。 。

組み込みのマテリアルハッキングを許可するための扉を開いていますが、適切な「サポート」を提供できるとは思いません。 ユーザーは、物事が壊れる可能性があることに注意する必要があります。

他のPRで取り組んでみました。 少なくとも関数、バリエーション、属性、ユニフォーム用にダミーフックを追加しました。 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とincludesはおそらくこのようには機能しません。 しかし、他のアプローチでは比較的簡単であることがわかります。 空の文字列を使用して、常に#include <some_phase>追加できます。 #ifdefを使用して、トリガーされるものを管理するのに役立つ可能性があります。 したがって、たとえば、「vertex_transformation」フェーズのロジックを提供する場合、シェーダーは提供するものをすべて定義します。 各チャンクがGLSLで何をするかを文書化すると、全体的に役立ちます。 抽象化をさらに進めることなく、チャンクが現在どのように構造化されているかについて、このマップがあれば素晴らしいと思います。

組み込みのマテリアルハッキングを許可するための扉を開いていますが、適切な「サポート」を提供できるとは思いません。 ユーザーは、物事が壊れる可能性があることに注意する必要があります。

私たちはすでにすべての素材で利用可能な定義のものを持っています。 https://github.com/mrdoob/three.js/issues/10764は、 THREE.ShaderLibを変更してから、 Materialインスタンスで.definesプロパティを定義することを提案しました。 確かに、私がエントリを書くまでプロパティは文書化されていませんでした（しかしあなたはそれを承認しました:)）、そしてまだ定義されていません。

しかし、これが現在機能し、すべてのマテリアルに継承されている方法はサポートされています。それに何かを入れると、そのマテリアルのシェーダーに影響します。 さらに、すでにシェーダーライブラリの一部であるものを定義すると、問題が発生する可能性があります。

賢いお尻になろうとしているのではなく、例を考え出そうとしている。 私は主に定義を使用ShaderMaterialが、それはすべての材料に影響を与えない、どれだけのでWebGLRenderer作品。 次のようなロジックはありません。

Phongようなマテリアルの抽象化のような、はるかに賢い表面の場合は、定義を考慮しないでください。 3つはシェーダーチャンクをオーバーライドするように設計されておらず、PhongテンプレートはGLSLが実行する必要があることの最終的な権限であり、これを使用から隠すのに役立つため、GLSL定義がこれに干渉しないようにすることは理にかなっています。

それが壊れるかどうかは完全にはわかりませんが、試してみる必要があります。

そうは言っても、それが多くの利益をもたらすのであれば、私は物事を壊すオプションが欲しいです。 かなりカプセル化された小さなGLSLスニペットを使用すると、3つのバージョンを簡単に変更して、法線マップを異なる方法でレンダリングできます。 法線を取り、それを別の法線に変換することは非常に簡単です。完全に異なる方法でコンピュータグラフィックスを始めない限り、これが壊れるのを見ることができません:)

インスタンス化は別の例でした：

ああ、ANGLE_INSTANCED_ARRAYSを使用したいのですが、3つはシャドウまたはPBRマテリアルではサポートされていないようです。これらの2行を追加して、機能させてください。」

この機能がついにthree.jsに登場するのを見てうれしいです:)。 はい、 yet another material modifier PRも作成しました（https://github.com/mrdoob/three.js/pull/7581）古すぎてコードはもう関係ありませんが、基本的には@mrdoobのようなフックを
この機能を使用したいほとんどの人は、デフォルトのマテリアルを完全に書き直すのではなく、「わずかに」変更したいと思うので、変更内容を簡単に理解できるので、事前定義されたフックのアイデアが好きです。

私はこのPRのシンプルさが好きですが、より構造化されたクリーンな方法で物事を行う場合は、コードに置き換えるフックの辞書と、ユニフォームやカスタムコードを追加する簡単な方法をすでに用意しておくことをお勧めします。文字列を置き換えるだけです。

@ fernandojsg ＃10791をチェックしてフィードバックを提供できる可能性があります。メインのすぐ外側に追加のフック（「pre_vertex」など）を配置し、管理が少し増えていることを除けば、これは非常によく似ています。

@fernandojsgあなたのPRを忘れていました😚。 あなたのPRは、私がこれが機能しているのを見始めた方法と非常によく似ていると思います。 潜在意識？

賢いお尻になろうとしているのではなく、例を考え出そうとしている。 私は主に定義を使用ShaderMaterialが、それはすべての材料に影響を与えない、どれだけのでWebGLRenderer作品。

ライブラリがそのようにハッキング可能であることを嬉しく思いますが、意図されていないものに不正使用機能を内部的に使用するべきではありません。 そうすれば、壊れやすいコードになってしまうのは簡単です。

＃7581をもう一度読んでいます... % 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;

};

次に、これを行うことができます：

`` `js
var material = new THREE.ExtendedMaterial（
新しいTHREE.MeshBasicMaterial（）、
{頂点： 'transformed.x + = sin（position.y）/ 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', ... )を使用するべきではありませんか？

あなたがそれを宣言する必要がないことを私は知りませんでした。 まだ変化と機能を残していますか？

まだ変化と機能を残していますか？

いい視点ね。

GLSLで属性を宣言する必要はもうありませんか？ ユニフォームのように機能すると思いました。GLSLで宣言しますが、JSで入力する必要はありません。

このリストは、コードがかなり散らばってしまう特定の事柄に関しては、かなり急速に大きくなる可能性があると思います。 法線マップを実行する1つの方法には、vertとfragの両方での変化と変換ロジックという2つの追加属性が含まれます。

シンプルでエレガントな最新の変更が気に入っています。 私は@pailheadに同意し、グローバルスコープにコードを配置する場所が必要です。 https://github.com/mrdoob/three.js/pull/7581で、 preMainVertex preMainFragmentをグローバルに注入して、さまざまな機能に使用できるようにしました。 おそらくglobalVertex/Fragmentなどの名前の方が良いでしょう。

GLOBAL_VERTEXとGLOBAL_FRAGMENTいいですね👌

正確に私が他のPRでそれらに名前を付けた方法😆👍

@pailheadしかし、コードをマージする秘訣はわかっています@ mrdoobが最終的に同様のことを行うことを

今、私もその名前が好きで、それで私たちは行く準備ができていると信じていますか、それとも何かが足りませんか？ 例をPRからこの新しいコードに変換してみます;）

コードが入る部分は問題ありません。タイムラインは少しずれています。 ＃7581はほぼ2年前に提案されました。 https://github.com/mrdoob/three.js/issues/10789で参照されていなかったため、おそらくレーダーから外れました。 私はそれをぶつけたり、フォークしたりしたでしょう。

モジュールをインポートして自分の3つを選んだとしても、非公式のコアモジュールを使用することにあまり満足していません。 「ねえ、fooを処理するnpmパッケージがあります」と言うのははるかに簡単です。 そのため、このようなPRは重要だと感じていますが、3つでは十分な柔軟性がありません。

利益！

どのような利益がありますか？ 😆

コードが入る部分は問題ありません。タイムラインは少しずれています。 ＃7581はほぼ2年前に提案されました。 https://github.com/mrdoob/three.js/issues/10789で参照されていなかったため、おそらくレーダーから外れました。 私はそれをぶつけたり、フォークしたりしたでしょう。

何？ 新しいPRを作成する前に、開いているすべてのPRをチェックしていませんか？ #trololol

NS ：）

リストにダイヤルして、できるだけ早く：D

このシェーダーは（たとえば）：

#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フックはありませんか？

私のPRでは、マテリアルの動作を少し変更したかっただけです。通常、fsが完全に実行された後、または@mrdoobが彼の例で示したものと同様の変換に対して、いくつかの色補正を行います。
ただし、各インクルードを完全に置き換えたい場合は、インクルードの代わりにフックを使用し、フックをバインドしなかった場合に備えて、インクルード自体を挿入するロジックを追加する必要があります。

法線に対してこれを実行したいと思います（導関数を使用せず、3ds maxまたはmaya、または法線マップが生成されている場所からの実際のTBN情報を使用します）。 MeshPhongMaterialをインスタンスで機能するように適合させるには、いくつかのチャンクを完全に置き換える必要もありましたが、これはそのようなエッジケースのように感じます。

これらは私が考えることができる2つです、私はもっとあるのだろうかと思います。

したがって、 % hook %は実際のフック専用です。 <begin_vertex>を置き換えたい場合でも、文字列でそれを探す必要があります。 begin_vertexフックはありませんか？

両方を交換できます。 現在のコードでは、すでに何でも置き換えることができます。 %HOOK%ものは便宜上のものです。

＃11562で述べたように、交換可能なシェーダーチャンクの概念はどうですか？

例：

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つのマテリアル上の複数のテクスチャ間の遷移のコードがいかに簡単であるかを示しています。

簡単に実装でき、不要なコードを作成する必要がありません。

@ sasha240100

https://github.com/mrdoob/three.js/pull/10791は、 partsがshaderChunksと呼ばれ、それを口論。
：roll_eyes：😆

チャンクはすでにマークされているので、 frag{}辞書も必要ありません。 それらはすべて_fragmentと_vertex持っています。

これは、文字列を検索して置き換える必要があるものを見つける必要があることを除いて、同じことを行います。

@pailheadはい、 frag: {}削除しましょう。 マテリアルシェーダーを連結する前に渡す必要があるため、引数として使用しました。 この場合、連結後に既存のパーツを交換することを簡単に回避できます。

実際には、引数とプロパティの両方を追加できます。 colorように

これは今どこにありますか？ 例が.replace()を実行しているのがわかりますが、フック/交換可能なチャンクが表示されませんか？ @mrdoob

まだこれに戻ることができていません。

% hook % PRをしたいですか？

上記のコメントから、拡張された資料が必要ですか？

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を追加して、インクルードを探しますか？ 私が書いた今、それは3人の責任でさえあるべきではないように思えますが、一方で、将来的にはTHREE.ExtendedMaterialを% hook %スタブするでしょうか？

あなたがTHREE.BAS拡張子を知っているかどうかはわかりません。 次のように、カスタマイズされたマテリアルから配列としてアクセスできる元のマテリアルのプレースホルダーを使用します。

  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はmain（）関数の先頭にあります。 vertexParametersとfragmentParametersはシェーダーの上部にあり、ユニフォームまたは属性を定義します。 vertexFunctionsとfragmentFunctionsは、main（）関数の前にあります。 法線、位置などについては、以下同様です。

位置でわかるように、変数transformedを変更して、最終的な位置を変更します。 たとえば、フラグメントシェーダーの法線（ objectNormal ）または色（ diffuseColor ）についても同様です。

これはPhongマテリアルがどのように見えるかであり、プレースホルダーのみを追加します： //github.com/zadvorsky/three.bas/blob/master/src/materials/PhongAnimationMaterial.js

こんにちはみんな、私はコンボをフォローしようとしていましたが、正直なところ、私はゲーム開発者ではなくフロントエンドから来たので、私は負けました。

MTLをロードしようとすると、次のようになります。

material.onBeforeCompile.toString（）は未定義です。

私のMTLファイルは元々.psdファイルを指していて、同じフォルダーを含む数少ないpngの1つに変更しました（通常）psdをロードすることはできないと思いますが、とにかく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 );

}

これはモデルの問題ですか？ スリーで？ mtlローダーで？ 解決策はありますか？

どんな助けでもいただければ幸いです。
ありがとう。

material.shader = shaderでmaterial.onBeforeCompile(shader=>...) material.shader = shaderようなことをする必要がありますか？

私はそれがやや不格好に感じると思います、ある時点で他の提案を再検討する価値があるかもしれません:)

@jjalonso

これはバグのようです：

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

これが原因ですが、 Materialにこの機能がない原因は何ですか？
https://github.com/mrdoob/three.js/blob/35a26f178c523514673d992da1aece23c1cfca6e/src/renderers/webgl/WebGLPrograms.js#L244

@mrdoob

これらの拡張シェーダーが正しくキャッシュされていない可能性はありますか？ 2つの異なるマテリアルを使用しようとしています。1つはdithering_fragment変更されており、もう1つは変更されてい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プレースホルダー/フックを削除した場合、他のプルリクエストを再検討しますか？ それらがあれば、多くのファイルに触れましたが、それらがなければ、コードは少なくなります。 3行ではありませんが、正しくハッシュされます:)

このフィドルで#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を作成し、その結果を処理することができます。 😅

ただし...実際に使用されている方法（シェーダーにパッチを適用するため）については、不可能ではないことに同意します。 しかし、簡単なAPI（ fn.toString() ）はハッキーであり、堅牢なAPIはより複雑です。

私はまだ問題を理解していません。 この観点はどうですか：

MeshPhongMaterialあり、 MeshStandardMaterialがないrNを取ります。

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'
}

MeshStandardMaterialからGLSLをシリアル化した場所はどこにもありません。

同じように、拡張された素材をシリアル化します。

//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として...そのコールバックをシリアル化します。

なぜ、なぜあなたはそれを考えるのですか:)これが私の混乱の核心だと思います、なぜこのフックに何か考えが与えられているのですか、それは材料の定義、説明、何の一部でもありません。 データではなく、エンジン、プラグイン、アプリなどと関係があります。

上記の例は私には問題ないように見えます。マテリアルを逆シリアル化するユーザーコードがHamburgerPhongMaterialの存在を知っている必要がありますか？ 私はそれで問題はありません。＃14099と同様のアプローチを取り、toJSONとfromJSONをオーバーライドする場合、必ずしもAPIの変更は必要ありません。

ここで@takahiroxの質問を別の方法で解釈したのではないでしょうか。

... .onBeforeCompile（）でハッキングされたマテリアルをシリアル化することは困難（または不可能）です。 完全に機能する（レンダリング、コピー、クローン、シリアル化など）変更された組み込みマテリアルが必要な場合、ユーザーはShaderMaterialを使用する必要があると思いますか？

私はそれを分割しようとします：

• ユーザーがプレーンなMeshStandardMaterialでtoJSON（）を呼び出した場合、そのonBeforeCompileによって変更されたGLSLは、GLSLへの変更が自動的にシリアル化されません。
• ユーザーがGLSLへの変更を示すいくつかの追加のプロパティを使用してMeshStandardMaterialをシリアル化し、それらの追加のプロパティをどう処理するかを知っているカスタムコードをロードする場合、それは確かに問題ありません。
• 他のさまざまなオプション（ShaderMaterial、NodeMaterial、glTFのKHR_techniques_webgl 、...）を使用して、任意のカスタムマテリアルをシリアル化できます。

私たちが話しているケースがそれらの1つではない場合、私はここで誤解していると思います。 これが約＃14099の場合、私は（まだ）それをマージすることに賛成です。

うーん、私は実際には最初の2つを区別していませんでした。 私はユニフォームを必要としない何かを考えようとしています、それは例えばgl_FragColor.xyz /= gl_FragColor.a;かもしれません。 しかし、私はあなたがこのようなものを（資料と一緒に？ ）シリアル化したいシナリオを想像することはできません。 マテリアルデータではなく、エフェクトレンダラーなどの範囲に含まれるようです。

materials = loadSerializedMaterials()

effect = new Effect()

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

2番目の例は私がずっと考えていたものです。 さまざまな入力とともに、それらをどう処理するかについてのヒントをシリアル化しますuserData.extension === 'hamburger' 。

私は下手に書いたと思います。 私が言いたかったのは

• .onBeforeCompile()ハッキングされた組み込みマテリアルは、組み込みマテリアルと同じAPIで正しくコピー、複製、シリアル化されません。 ハッキングされていない素材として扱われます。
• ユーザーが正しい結果を求めている場合は、ユーザー側で追加の作業が必要です。
• ユーザー側の追加作業なしでThree.jsコアAPIを使用してハッキングされた組み込みマテリアルが必要な場合は、 ShaderMaterialなどの他のオプションを検討する必要があります。

私の質問は、特定のケースではなく、 .onBeforeCompile()のポリシーに関するものです。 制限を明確にして、ドキュメントにメモを追加したいと思いました。

three.jsとレンダリングシステム全体を忘れた場合、私はその要点を理解していると思います。 汎用オブジェクトとして、 .clone()場合は、クローンを作成して一貫した期待を持たせる必要があります。 問題は、両方の解決策（これを複製するのではなく複製する）に有効な引数があるように見えることです。 リスナーのクローンを作成しませんが、描画に影響を与える何かが一貫していることもある程度期待します。

他の領域でも同じ問題が発生したため、上記の提案はこれを行うための有効な方法だと思います（たとえば、ターゲット間で深度バッファーを共有することもownThing || outsideThingで解決できます）。

機能しない関数をキャッシュする代わりに、基本的にuserDataキャッシュしますが、そのサブセットをキャッシュします。 userData.hamburger: 'rare'をキャッシュすることは意味がありませんが、 userData.effectOn: true". Theキャッシュします。 ownChunks | ownWhatever`はこの問題を解決します。

また、次の問題も解決します。

onBeforeCompileメソッドには非常に任意のコードが含まれている可能性があるため、そのコールバックを堅牢にシリアル化することは確かに不可能です。

長い間、人々はonBeforeCompileを使用してきましたが、そこにはどのような任意のコードが含まれているのかを知る必要があります。 渡されたshaderオブジェクトでのみ動作すると思います。そのオブジェクトを変更しますが、とにかくShaderMaterial意味のある変更のみが影響します。 自分でglものを設定すると、おそらくオーバーライドされます。それが私の頭に浮かぶ唯一のことです。

これは基本的にpre three parseステップであり、 Material （ defines:{}で使用できないため、必須のuniforms:{}インターフェイスとともにシェーダーを自分で解析する機会が得られます。一方、 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()

TL：もののDRは、上記の「コンパイル」（パース）が発生したときに、特定の時点気にしないユーザーです。 彼らは何が起こるかをもっと気にかけていると思います。そして、何が起こるかは、単一のユースケースではないにしても、ほんの一握りに分離することができますin: shaderString, out: shaderString 。 パイプラインの特定のポイントで実行する必要がある理由は、調査して理解する価値があると思います。 それはその助け以上に物事の邪魔をしているようです。

@mrdoob .onBeforeCompile()ハッキングされたマテリアルをシリアル化するのは難しい（または不可能）と思います。 完全に機能する（レンダリング、コピー、クローン、シリアル化など）変更された組み込みマテリアルが必要な場合、ユーザーはShaderMaterialを使用する必要があると思いますか？

onBeforeCompile()の使用がシリアル化されるとは思っていませんでした...

onBeforeCompileを使用して激しく噛まれました。 組み込みのシェーダーを定義された方法で変更できるシェーダーヘルパークラスがあります。 これを行うには、onBeforeCompileメソッドを使用します。 どうやら、最初のコメントで述べたように、WebGLProgramはonBeforeCompile.toString（）をハッシュとして使用します。 しかし、私の関数はジェネリックであるため（頂点シェーダーとフラグメントシェーダーの一部を変数に置き換えます）、onBeforeCompile.toString（）はシェーダーごとに異なって見えません。 これは、私の異なるシェーダーがすべて同じプログラムとしてキャッシュされることを意味しました。 eval呼び出しとuuid、そして今では私の関数はすべて異なって見えます。 これを理解するために永遠にかかりました。

@donaldrhttps ： //github.com/mrdoob/three.js/issues/13192を参照してください。 これらの制限を文書化するとよいと思います。

evalの使用方法を教えてください。 ずっと考えていたのですが、汚れすぎたようです。 基本的に、ボディの上部にconst fdscxnmdrek435rkjlを追加してから、評価することができますか？

これは、私の異なるシェーダーがすべて同じプログラムとしてキャッシュされることを意味しました。 eval呼び出しとuuid、そして今では私の関数はすべて異なって見えます。 これを理解するために永遠にかかりました。

それは非常にイライラするように聞こえます、ごめんなさい。 😞必要な変更がライブラリ自体で意味があるように思われる場合は、未解決の問題も歓迎します。

未解決の問題も歓迎します。

既存のものを再開することを検討しますか？ ＃13192は同じように見えますが、閉じられました：crying_cat_face：機能と見なされた場合、回避策がそこに投稿されていれば本当にいいでしょう。

うーん...

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

^これは機能しますか？ eval使用したことはありません。

＃17567を介したMaterial.customProgramCacheKey（）の導入により、開発者は、条件ステートメントを使用してonBeforeCompile()を介して変更されたマテリアルに対してシェーダープログラムが共有されない可能性があります。

新しいスレッド（＃13446など）のonBeforeCompile()コンテキストで、他の既存の問題または拡張機能について説明してください。