export class JourneySphereMaterial extends LayerMaterial {
	constructor() {
		super({
			color: 'white',
			lighting: 'physical',
			transparent: true,
			transmission: 1,
			// @ts-ignore
			thickness: 0,
			alpha: 0.8,
		});
//This doesn't work, nor does using opacity.
		this.alpha= 0.2;
	}
}

Adds a button to the debugger to copy the vanilla js code and some util fns to support the serializing.

Let me know what you think!

Examples from the configurator (formatting varies depending on where you paste):

JSX:

    <LayerMaterial color={16711422} name={"Monkey w/ freckles"}>
      <Depth near={-0.06800000000000028} far={5} origin={[0,0,3]} colorA={"#fe96dc"} colorB={"#68eefb"} />
	<Depth near={1} far={3} origin={[0,0,-1.3670000000000089]} colorA={"#feb600"} colorB={"#000000"} mode={"screen"} />
	<Fresnel color={"#fefefe"} power={1.9099999999999757} mode={"softlight"} />
	<Noise colorA={"#84fee9"} colorB={"#969696"} colorC={"#000000"} colorD={"#000000"} scale={50} offset={[0,0,0]} name={"noise"} mode={"lighten"} />
    </LayerMaterial>
    

Vanilla JS:

 new LayerMaterial({
  color: new THREE.Color('#fefefe'),
  name: 'Monkey w/ freckles',

  layers: [
    new Depth({
      near: -0.06800000000000028,
      far: 5,
      origin: [0, 0, 3],
      colorA: new THREE.Color('#fe96dc'),
      colorB: new THREE.Color('#68eefb')
    }),
    new Depth({
      near: 1,
      far: 3,
      origin: [0, 0, -1.3670000000000089],
      colorA: new THREE.Color('#feb600'),
      colorB: new THREE.Color('#000000'),
      mode: 'screen'
    }),
    new Fresnel({
      color: new THREE.Color('#fefefe'),
      power: 1.9099999999999757,
      mode: 'softlight'
    }),
    new Noise({
      colorA: new THREE.Color('#84fee9'),
      colorB: new THREE.Color('#969696'),
      colorC: new THREE.Color('#000000'),
      colorD: new THREE.Color('#000000'),
      scale: 50,
      offset: [0, 0, 0],
      name: 'noise',
      mode: 'lighten'
    })
  ]
});

Skinned meshes stop working when using Lamina. I think it might be because the shader is not implementing skinned meshes maybe?

Example without lamina:

When i add Lamina:

first off wanted to say lamina is awesome, have really enjoyed playing around with it so far!

I was interested in making some custom layers that modified vertex positions eg:

1. fullscreen layer (gl_Position = vec4(position * 2.0, 1.0) ...)
2. height-map displacement layer (gl_Position.z += texture2d(map, uv).r)

Is this kinda thing out of scope for Lamina?

took a stab at implementing these but ran into issues because the ${body.vert} is included before gl_position is set and currently gl_position is determined entirely by unmodifiable input values. (modelViewMatrix, position, & projectionMatrix).

Can you spot the "mistakes?"

<mesh>
    <sphereGeometry args={[1, 64, 64]} />
    <LayerMaterial>
        <Base color="#603295" />
        <Depth colorA="white" colorB="#0F1C4D" alpha={0.5} mode="normal" near={0} far={2} origin={[1, 1, 1]} />
        <Depth colorA="red"  alpha={0.5} mode="add" near={3} far={2} origin={[-1, 1, 1]} />
        <Fresnel mode="add" color="orange" intensity={0.5} power={2} bias={0.05} />
        <Noise scale={2} mapping="world" type="curl"  colorA="white" colorB="0x000000" mode="softlight" />
        <Noise mapping="local" /*type="curl" */ scale={100} colorA="#aaa" colorB="black" type="simplex" mode="softlight" />
        <Noise mapping="local" type="simplex" scale={100} colorA="white" colorB="black" mode="subtract" alpha={0.2} />
    </LayerMaterial>
    </mesh>
    <mesh>
    <circleGeometry args={[2, 16]} />
    <LayerMaterial transparent depthWrite={false} side={THREE.FrontSide} blending={THREE.AdditiveBlending}>
        <Depth colorA="orange" colorB="black" alpha={1} mode="normal" near={-2} far={1.4} origin={[0, 0, 0]} />
        <Noise mapping="local" type="simplex" scale={200} colorA="#fff" colorB="black" mode="multiply" />
    </LayerMaterial>
</mesh>

With the complex interweaving it can get incredibly difficult to debug or even correctly configure things on even relatively simple 2 mesh layouts. This totally isn't "bad"

but people will make bad..

Now obviously if people go in an and configure things "correctly" they will have complex files as well, however I think some of the things can have baselines, where the changing or overriding is clear by performing it at all. Consider <noise>

BTW are we missing Noise props? This page mede it clear to understand, but our inputs are unique

---- This is real.. We used this in a multiple demos ----

<Noise scale={2} mapping="world" type="curl"  colorA="white" colorB="0x000000" mode="softlight" />
<Noise mapping="local" /*type="curl" */ scale={100} colorA="#aaa" colorB="black" type="simplex" mode="softlight" />
<Noise mapping="local" type="simplex" scale={100} colorA="white" colorB="black" mode="subtract" alpha={0.2} />

With Baseline configurations

<Noise  type="curl" mapping="world"   colorA="#ff0000" colorB="0x000000" mode="softlight" />
<Noise colorA="#aaa"  scale={2} mode="softlight" />
<Noise  alpha={0.2} mode="subtract" />

I feel like it's a LOT clearer what I'm fiddling with, and when I change the type Im doing it knowingly..

Maybe even catch it:

<LayerMaterial>
  <Noise type="curl" />
  <Noise type="curl" />
  <Noise type="curl" />
  <Noise type="curl" />
</LayerMaterial>
/***WARNING** More than 3 Noise Layers can cause significant frame loss: https://levadocs.io/curl */

The base can only be called once and at the origin

<LayerMaterial>
    <Base color="#603295" >
</LayerMaterial>

becomes:

<LayerMaterial color="#603295" >
...
</LayerMaterial>

Similar to how R3f handles camera. Now base only has 3 arguments and only 1 will regularly be set, but if they had a specific requirement or need and really wanted they still could still do:

<LayerMaterial>
    <Base color={compareAllyColors{userColorVar, safeColorVar)} alpha={() => isDarkMode ? 1 : .5}  blend={/**No idea why base blends?**/} >
</LayerMaterial>

R3F Canvas & Camera:

<Canvas camera={{ positon: [0,5,0] }}>
    <Lights >
        <mesh></mesh>
</Canvas>

<Canvas>
    <perspectiveCamera ref="camRef" position={ [0,5,0 }>
        <Lights >
        <mesh></mesh>
</Canvas>

lamina will re-create the shader on every render because "children" is not a stable reference. children should rather inform lamina on mount, and when certain props have changed that it must refresh. this of course would duplicate refresh multiple times once you're dealing with multiple layers — this draft would try to work against that.

On NextJS

info  - automatically enabled Fast Refresh for 1 custom loader
wait  - compiling /_error (client and server)...
error - ./node_modules/lamina/index.js:12:0
Module not found: Can't resolve 'react-dom/client

package.json

"dependencies": {
 ...
    "lamina": "^1.1.9",
    "react": "17.0.2",
    "react-dom": "17.0.2",
...
  },

Thanks for any input!

Am I the only one that thinks that the implementation of https://github.com/pmndrs/lamina/blob/main/README.md?plain=1#L205-L216 is confusing when looking at the comment?

For me it sounds like, that a CustomLayer should't change the position via the vertex-shader, but in the example it totally does exactly that:

  // Optionally Define a vertex shader!
  // Same rules as fragment shaders, except no blend modes.
  // Return a non-transformed vec3 position.
  static vertexShader = `   
    // Varyings must be prefixed by "v_"
    varying vec3 v_Position;
    void main() {
      v_Position = position;
      return position * 2.;
    }

So Return a non-transformed vec3 position. sounds to me that return position * 2.; shouldn't be done (I mean of course you can do that, but as a best practise it shouldn't right?).

When I copied the example I was surprised that my mesh had increased in size.

Consider this blend effect

        <LayerMaterial transparent depthWrite={false} side={THREE.FrontSide} blending={THREE.AdditiveBlending}>

With strings:

        <LayerMaterial transparent depthWrite={false} side="front" blending="additive">

Side has 3 options, front, back, both. Blending does have a lot more, so you could still allow it to be passed, but otherwise make it easier...

If we bake in the base as mentioned in #8 there's no need to call transparent. You still could I guess, just to be 100% sure or if you planned on adjusting the other values later.

But if you place a color in base:

 <LayerMaterial>
    <Base color="#603295" />
</LaterMaterial>

or by #8 :

<LayerMaterial color="#603295">

There's no alpha set so it is 100% opaque

where this becomes confusing is actually on the inverse:

 <LayerMaterial>
    <Base color="#603295" alpha=".5" />
</LaterMaterial>

You would think that layer is 50% see through (opaque) but it's not...

Transparent maps to the material, while base and alpha map to the material color map..

I have NO IDEA what this would do..

//simplified from @Fasani Blob experiment
<mesh>
  <sphereGeometry args={[0.8, 128, 128]} />
  <LayerMaterial>
    <Base color="#603295" />
          {...}
  </LayerMaterial>
</mesh>
<mesh ref={glow} scale={0.6} visible={showGlow}>
    <circleGeometry args={[2, 16]} />
    <LayerMaterial depthWrite={false} side={THREE.FrontSide} blending={THREE.AdditiveBlending}>
        {...}
    </LayerMaterial>
</mesh>

In that instance the user accidentally left of the transparent value on glow. Now, because the blending mode isnt the default we know we're supposed to be transparent..

TLDR: based on input props we can assume the intended transparency value

Transparency on meshStandardMaterial in Three.js doscs

Hello,

I want to create a PBR material that blends two normals maps. The first one should use uv index 0 and the second one should use uv index 1.

Is that possible with lamina?

Best

clone material is not same as origin material

const material = new LayerMaterial({
      color: new THREE.Color(0xff0000),
      lighting: 'physical',
    });

const cube = new THREE.Mesh(geometry, material.clone());

Wrong Result, Should be red (0xff0000)

And no matter I clone multiple materials, the clone materials always have the same uuid ...

It's great that Lamina layers can also provide vertex shaders that modify the vertex positions, but unless I've severely misunderstood something (and please tell me if I did), the way that vertex shaders are currently set up makes it kinda iffy to have multiple vertex-shading layers stacked in sequence.

As far as I understand, from the perspective of a layer's vertex shader, the following happens:

• A position variable is provided, containing the original vertex position from the geometry buffer.
• The vertex shader is expected to implement a void main that returns a new, modified position.
• If you have multiple Lamina layers that do this, each new layer will start with position being set to the original vertex position, essentially overwriting what the layers before already did to mutate it.

This makes it very hard to implement stacks of animation shaders (where one, for example, would animate the vertices based on velocity applied over time, and another apply a rotation) without completely bypassing this setup and writing all changes into a shared global variable, only to then have the final layer write into the actual position.

I don't know if this has implications (beyond potentially breaking existing code), so consider this an RFC: I propose that the system is changed to expect layer vertex shaders to mutate an existing position variable, eg.:

// wobble position vertexShader
void main() {
  position.x += sin(u_time);
}

// wobble scale vertexShader
void main() {
  position *= 2.0 + cos(u_time);
}

// etc.

Blend modes and ratios do not make sense here, so plain old mutation like this should be fine, but I'd be happy to hear what kind of stuff this will break.

I'm running into this error while using the current version of @react-three/fiber (first affected version is 8.0.21). For example, updating the dependencies in the complex-material leads to the following:

yarn.lock:

 "@react-three/fiber@^8.0.3":
-  version "8.0.9"
-  resolved "https://registry.yarnpkg.com/@react-three/fiber/-/fiber-8.0.9.tgz#e231626dc923a7fefd1d47588ce2c5af09726213"
-  integrity sha512-9hh3w0JjPwtoqRexCnAVSPK3kdjtTqpaeTDZOW2RHmfU0gSYaKijY+PtaiHjoym/2oTfa21mCmaROXXS2jDvvQ==
+  version "8.0.22"
+  resolved "https://registry.yarnpkg.com/@react-three/fiber/-/fiber-8.0.22.tgz#68c69ba7c0c4f5354562c5acfd5f0c9c64b9a64d"
+  integrity sha512-HkQR+SKm0Bi4qq9sxCV2rv2aXxEhWPcj52bLOCiW3WpF8sGJtmdc/pP4ih5gXwN7I5NMTa2eDeoSYkIPOwt1/g==

Error:

Uncaught TypeError: type is not a function
    at attach (index-f1b43982.esm.js:194:1)
    at switchInstance (index-f1b43982.esm.js:1024:1)
    at commitUpdate (index-f1b43982.esm.js:1119:1)
    at commitWork (react-reconciler.development.js:15871:1)
    at commitMutationEffectsOnFiber (react-reconciler.development.js:16204:1)
    at commitMutationEffects_complete (react-reconciler.development.js:16057:1)
    at commitMutationEffects_begin (react-reconciler.development.js:16046:1)
    at commitMutationEffects (react-reconciler.development.js:16016:1)
    at commitRootImpl (react-reconciler.development.js:18932:1)
    at commitRoot (react-reconciler.development.js:18811:1)

Line:

} else child.__r3f.previousAttach = type(parent, child);

Adding flatShading prop to the LayerMaterial doesn't affect the shading.

Left: <meshMatcapMaterial matcap={matcap} flatShading />

Right: <LayerMaterial flatShading> <Matcap map={matcap} /> </LayerMaterial>

https://codesandbox.io/s/lamina-matcap-ho7v4z?file=/src/App.js