pmndrs / component-material Goto Github PK

Should be easy to use the glslify babel macro

Sometimes you might want to replace a specific string inside of a chunk, rather than the whole chunk.

Currently I'm doing this:

<ComponentMaterial.Vert.defaultnormal_vertex
    replaceChunk
    children={ShaderChunk.defaultnormal_vertex.replace(
      "vec3 transformedNormal = objectNormal;",
      "vec3 transformedNormal = displacedNormal;"
    )}
  />

Would be a bit easier if I could do this:

<ComponentMaterial.Vert.defaultnormal_vertex
    replaceString="vec3 transformedNormal = objectNormal;",
    children="vec3 transformedNormal = displacedNormal;"
  />

I need a few different materials in my project, but they share a lot of functionality. I'm not sure what the best approach to do this would be. One idea would be to reuse common tags. For example you could define them inside a fragment and then reuse that fragment inside of many materials.

function CommonTags () {
  return (
    <>
      <ComponentMaterial.Vert.defaultnormal_vertex
        replaceChunk
        children={ShaderChunk.defaultnormal_vertex.replace(
          "vec3 transformedNormal = objectNormal;",
          `vec3 transformedNormal = displacedNormal;`
        )} />
      <ComponentMaterial.Vert.displacementmap_vertex
        replaceChunk
        children="transformed = displacedPosition;"  />
    </>
  )
}

When writing a plain <shaderMaterial />, the material will hot reload when the shader code changes which enables rapid iteration during development.

By contrast, a <Material /> from component-material only hot reloads when uniforms change, while code changes require a full page reload. This makes it hard for me to adopt component-material in my workflow.

Default vert would be used like

<M>
   <M.vert /> // empty
</M>

and result in a default non-transforming vertex shader

void main() {
  gl_Position = projectionMatrix * modelViewMatrix * vec4(position,1.);
}

Have a look here:

https://codesandbox.io/s/react-component-threejs-127-32ch1

The issue is that this:

  return class extends baseMaterial {
    constructor(parameters = {}) {
      const entries = Object.entries(uniforms)
      super(parameters)

Is converted to:

    function _class(parameters) {
      var _this;

      if (parameters === void 0) {
        parameters = {};
      }

      var entries = Object.entries(uniforms);
      _this = _baseMaterial.call(this, parameters) || this;

Which is probably done by tsdx. I unfortunately don't know much about tsdx so I hope someone else has more knowledge about that and knows a quick fix for this.

We started the project including babel-glsl-macro in the library to let users just add glslify-type imports that would just work.

We later removed it because we didn't want to make babel a dependency - since your build process would HAVE to include babel core and babel macros.

On the other hand, babel-macros ships by default in:

• create-react-app
• gatsby
• next

The options are:

• leave it to the user to add a glsl pipeline to their build process
• add it in the library and require users to add babel & macros if they want to use the features

Questions:

Can we make it fail gracefully if the users don't have macros setup?

if (user.hasMacros) {
   shader = glsl(shader)
}

ShaderMaterial and RawShaderMaterial don't use chunks, so you can just use strings and a simpler tree like this

<ComponentMaterial from={RawShaderMaterial}>
   {/* common would be added to both vert and frag */}
   <common>
     <tools.rotate />
     <noise.simplex3rd />
   </common>
   <vert>
      ...all vertex code...
    </vert>
    <frag>
       ...all frag code...
    </frag>
</ComponentMaterial>