@Mugen87 folow ( #20421 (comment) ) ( f738e6a )
/jsm/renderers/nodes agnostic renderer node system
/jsm/renderers/webgpu/WebGPUNodeBuilder WebGPU node builder

I don't think it is necessary to make a new example for nodes anymore. Do you mind modifying the existing webgpu_sandbox_nodes example?

@Mugen87 You have any idea for that error message I am getting:
If I add a single vec3 in nodeUniforms it works done. 24 bytes seems the correct size for two vec3.

You have any idea for that error message I am getting:

This message did not pop up in my tests so far but I assume that vec3s must start on a 16-byte boundary. Can you please change the byteLength of Vector3Uniform to 16 for now?

/cc @Kangz @takahirox

@mrdoob This PR looks really great! In context of design, I would highlight one important aspect since it will accompany node material from the very beginning.

With the current implementation, nodes have the responsibility to control their build/generation. This process is mainly done with a node builder with is injected as a parameter. One could consider a different architecture such that nodes do not have any build/generate methods but just describe themselves. You then have a centralized entity that traverses through the node composition and performs the build.

I personally favor the current approach since it's similar to having toJSON() and fromJSON() on object level instead of a single complex component that handles the entire serialization/deserialization. It's easier to encapsulate code and hide component-specific logic (in this case node specific).

@Mugen87 You have any idea for that error message I am getting:
If I add a single vec3 in nodeUniforms it works done. 24 bytes seems the correct size for two vec3.

Mmmmh it should work with the std140 layout, but WebGPU seems to think it is 28 bytes probably because of a bad array stride? Could you share permalink of the GLSL->SPIRV compilation in http://shader-playground.timjones.io/ ?

I don't know how to share a permalink. Here is some sample code:

#version 450
layout(set = 0, binding = 2) uniform MaterialUniforms {
    float opacity;
    vec3 color1;
    vec3 color2;
} materialUniforms;

layout(set = 0, binding = 3) uniform sampler mySampler;
layout(set = 0, binding = 4) uniform texture2D myTexture;

layout(location = 0) in vec2 vUv;
layout(location = 0) out vec4 outColor;

void main() {
    outColor = texture( sampler2D( myTexture, mySampler ), vUv );
    outColor.a *= materialUniforms.opacity;
}

It seems that even if a single float only takes 4 bytes, it's necessary to put 12 bytes as padding when starting with color1. And after defining color1, you need 4 additional bytes before defining color2.

I guess we need the logic from the UBO PR that determines the total buffer size according to the STD140 layout.

https://github.com/mrdoob/three.js/pull/15562/files#diff-cba50499b84f8d3f3690b625a907ba74R209

Ah yes, I misread. It is expect that the buffer would use 28 bytes in std140 layout because things are mostly padded to 16 bytes all the time. Like you said, the logic in the UBO PR should help.

Okay, added: 1cf4431

@sunag After rebasing the mentioned warnings should be gone.

@sunag After rebasing the mentioned warnings should be gone.

@Mugen87 It work now. Thanks guys for quick fix.

I think in changing the properties to material.colorNode and material.opacityNode because the implementation will be easier including in WebGL context.

I add Nodes support for PointsMaterial ( 99cced5) in some minutes, very simple... This can be used for any material of threejs too.

Nice! I think we should manage now all existing uniforms over the node material system so the following code block can be eliminated:

Instead of this code, we just have this:

const bindings = this.pipelines.getBindings( object );

When you look at the shader code in WebGPURenderPipelines, you can see that the UBOs CameraUniforms and ModelUniforms are required in all programs so far. It's essentially a replacement for the pre-defined code in WebGLProgram.

When managing all bindings over the node material system, I suggest to finally review and then merge this PR since it is a proper first step.

When managing all bindings over the node material system, I suggest to finally review and then merge this PR since it is a proper first step.

I am already thinking about cleaning and Ready for review this PR after implement TextureNode.

Instead of this code, we just have this:
const bindings = this.pipelines.getBindings( object );

if ( material.isMeshBasicMaterial ) { 
  
 	bindings = this._getMeshBasicBindings(); 
  
 } else if ( material.isPointsMaterial ) { 
  
 	bindings = this._getPointsBasicBindings(); 
  
...

It is not clear to me where you want to move these functions, it is for WebGPURenderPipelines ?

It is not clear to me where you want to move these functions, it is for WebGPURenderPipelines ?

I thought we could remove them and add the common bindings (CameraUniforms and ModelUniforms) with the node material system.

I thought we could remove them and add the common bindings (CameraUniforms and ModelUniforms) with the node material system.

This would change a lot, a very simple implementation would mix the logic of the procedural with natives... I don't think it's appropriate for the moment.

No problem. We can experiment later with this. But the goal should be that all bindings are defined by the node material system at some point (and not be hard-wired in the renderer). In general, the renderer should not perform any checks for materials anymore (e.g. test for isMeshBasicMaterial). Only then it can be implemented material agnostic. We should focus on that after merging this PR.

If so, I see no reason not to leave the properties hybrid right now because code block like this don't make much sense... thinking ahead.

layout(set = 0, binding = 2) uniform OpacityUniforms {
	float opacity;
} opacityUniforms;

layout(set = 0, binding = 3) uniform sampler mySampler;
layout(set = 0, binding = 4) uniform texture2D myTexture;

Yeah, the current shader code was more or less developed for testing. If we can consolidate this in order to avoid unnecessary bindings, we should do so.

We just have to be aware that UBOs might be shared across multiple shader programs. So e.g. CameraUniforms should be a unique UBO which is reused.

We just have to be aware that UBOs might be shared across multiple shader programs. So e.g. CameraUniforms should be a unique UBO which is reused.

Yes, this feature already exists in the current node material system we should only bring it to the new node system: ( https://github.com/mrdoob/three.js/blob/dev/examples/jsm/nodes/accessors/CameraNode.js#L100 )

@sunag Do you think you can finish the PR in the next time by adding support for TextureNode? Otherwise I would give it a try since I've made myself a little bit more familiar with the node material system.

It would be good to have a basic version of the node material in place so we can move on with developing the renderer at other places.