NodeMaterial: WebGPU

[sunag]

@Mugen87 @mrdoob Very, very draft to facilitate the understanding... this is a step implement to WebGL too, is my new approach, merger node slots directly in ShaderLib...

I fork the example webgpu_sandbox.html and added just some lines code:

import FloatNode from './jsm/renderers/nodes/inputs/FloatNode.js';
import Vector3Node from './jsm/renderers/nodes/inputs/Vector3Node.js';
import OperatorNode from './jsm/renderers/nodes/math/OperatorNode.js';

materialBox.colorNode = new OperatorNode( '+', new FloatNode( .5 ).setConst( true ), new Vector3Node( new THREE.Vector3( 0, 0, 1 ) ) );
materialBox.opacityNode = new FloatNode( .5 );
//materialBox.transparent = true;

[sunag]

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

[Mugen87]

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?

[sunag]

@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.

[Mugen87]

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

[Mugen87]

@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).

[Kangz]

@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/ ?

[Mugen87]

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.

[Mugen87]

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

[Kangz]

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.

[Mugen87]

Okay, added: 1cf4431

@sunag After rebasing the mentioned warnings should be gone.

[sunag]

@sunag After rebasing the mentioned warnings should be gone.

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

[sunag]

I already start the dev of TextureNode. I commit in the next days...

[sunag]

I made a texture animated to test, this commit is a WIP.
https://raw.githack.com/sunag/three.js/nodematerial-webgpu/examples/webgpu_sandbox.html

[sunag]

@Mugen87 I move WebGPUNode* to ./webgpu/nodes folder in order to facilitate.

[sunag]

I suggest merge this PR while I doing the others, in case it's ok for you too. I update all WebGPU examples.

[sunag]

I think that the next step is move CameraUniforms and ModelUniforms to nodes, right?

[sunag]

Examples
https://raw.githack.com/sunag/three.js/nodematerial-webgpu/examples/index.html?q=webgpu#webgpu_sandbox

[Mugen87]

I think that the next step is move CameraUniforms and ModelUniforms to nodes, right?

That sounds good. The renderer should not manage/setup UBOs but the material system. I've initially added this code in WebGPUBindings so we have something to start.

[Mugen87]

I suggest merge this PR while I doing the others, in case it's ok for you too.

I would say yes. The general structure of the node material system looks good to me. Merging this PR means we have something on dev to experiment with. Further tweaks and changes can be discussed in separate PRs.

[Mugen87]

@mrdoob Are you okay with merging this? 😊

[mrdoob]

Thanks!