WebGPURenderer & PhysicalLightingModel: Added clearcoat

[sunag]

Description

The same example of WebGL, I just made some adjustments in scale, mainly because the WebGL example version is based in legacy lighting.

https://raw.githack.com/mrdoob/three.js/dev/examples/webgpu_clearcoat.html

[WestLangley]

I think it is a good idea to get in the habit of limiting the controls zoom/pan/dolly to reasonable limits appropriate for the example.

[mrdoob]

What is temp()? 🤔

[LeviPesin]

It allows to create a new temporary variable.

[mrdoob]

would clone() work too?

[LeviPesin]

No. I meant "variable" as not a JS variable, but a variable in the final GLSL/WGSL code.

[mrdoob]

What is a temporary variable?

[LeviPesin]

temp just tells to explicitly create a new variable, so that we can do assigning to it.

[sunag]

The Node System tries to optimize the code automatically putting all code in a single line if possible. If a node is used more than two time they automatically create a temporary variable. Like:

vec3<f32> nodeVar2 = ...

When .temp() is used force the system to create a variable, it is useful to store a variable that the user can modify itself using addAssign(), subAssign(), or assign() for example. This syntax in WGSL is like:

// TSL: const node = vec3().temp()
vec3<f32> nodeVar2 = vec3<f32>( 0.0 );

// TSL: node.addAssign( 1.0 )
nodeVar2 = nodeVar2 + vec3<f32>( 1.0 );

// without temp
let node = vec3();
node = node.add( 1.0 );
// WGSL: ... ?= ( vec3<f32>( 0.0 ) +  vec3<f32>( 1.0 ) )

// using temp
const node = vec3().temp();
node.addAssign( 1.0 );

// WGSL:
// vec3<f32> nodeVar2 = vec3<f32>( 0.0 );
// nodeVar2 = nodeVar2 + vec3<f32>( 1.0 );

Without temp is used in most of the time because have a better syntax using chain but in some cases when an incremental variable is used like outgoingLight is used in differences functions seems better approach to avoid use async of variable.

[mrdoob]

Got it. Thanks!

[mrdoob]

I just made some adjustments in scale, mainly because the WebGL example version is based in legacy lighting.

Oh, could you also update the WebGL example so it doesn't use legacy lighting?

[LeviPesin]

Isn't this a bit of a hack?

[sunag]

I'm trying to convince myself that yes, but I think that currently is the better approach. I created a class to contextualize LighingModel but it creates more classes that can replaced by .includes(), basically if the user does not declare/assign clearcoat in .constructVariants() we can use builder.includes( clearcoat ) to detect that clearcoat is not used in this material.

[LeviPesin]

Not sure if I understand this comment... but can't we do shader( ( {}, stack, builder ) => lightingModel.init.call( context, stack, builder ) ), similar as how it was done in other places?

[sunag]

The syntax shader( ( {}, stack, builder ) => {} ) is correct, but the call syntax should be just .call( { ...inputs } ) like FunctionCallNode for the users and not .call( {}, stack, builder ). It because call() should return a ShaderCallNode and not run the function immediately. When it's called in construct() process, we can send stack and builder parameters, but if the user calls the shader() outside construct() like material.colorNode = shader(..).call() we would not be able to pass the builder/stack because it is in the wrong builder stage.