NodeMaterials Not Working with WebGL (fixed with r159)

Questions
1

Thanks to assistance from sunag, I was able to switch to using shadows with WebGPU. I have since updated the example to work with NodeMaterials. Here is a CodePen example.

But when I saved and ran the program on my webpage, I was notified that there was no WebGPU support. I assume that is due to a problem with the server.

So I reverted the program above to work with WebGL. However, the NodeMaterials no longer work. Here is a CodePen example where only one part (the wing) is a NodeMaterial (line 329). The part has disappeared along with the tail which is the same color. Oddly, the shadow of the parts still shows.

Does anyone know how to fix this problem?

FINAL NOTE (Dec 1, 2023)
This problem was fixed with r159. Thanks sunag!

2

It looks like the example works with MeshPhongNodeMaterial instead of MeshLambertNodeMaterial materials, although it would be something to check. For NodeMaterial to work correctly in WebGLRenderer it is necessary to use NodeFrame.

import { nodeFrame } from 'three/addons/renderers/webgl-legacy/nodes/WebGLNodes.js';

function animate() {

	nodeFrame.update();

	...

}
1 Like
3

Thanks!

I deleted the WebGPU test, which I had left in by accident.

As you suggested, I substituted MeshPhongNodeMaterial and it seemed to fix the problem.

These results did not change if I made either or both of the following sets of changes::

  • the nodeFrame changes you suggested above…
  • as per WebGPU, adding “renderer.setAnimationLoop(rendAll)” along with deleting the “requestAnimationFrame(rendAll)”

The result is shown in the CodePen above.

So I assume that the minimum answer is to switch all materials to MeshPhongNodeMaterial and the optimum answer is to also make both sets of changes above?

(For fun, I then tried using MeshLambertNodeMaterial and making both sets of changes above. But nothing I did would make it work. So it appears that MeshLambertNodeMaterial is out?

4

It turns out that there is still a problem with the node materials.

I discovered this when I realized I had I made an error in fixing my CodePen example.

In the aircraft loading subroutine, for the first part of the aircraft, I had the option of selecting three different materials:

  1. new THREE.MeshLambertMaterial({color: 0xff00ff}));
  2. new MeshLambertNodeMaterial({colorNode: color(0xff00ff)}));
  3. new MeshPhongNodeMaterial({colorNode: color(0xff00ff)}));

I had meant to select option #3 (node Phong) to make it consistent with the other parts of the aircraft. However, I accidentally left it at option #1 (regular Lambert). Because of my error, everything seemed to be working fine…

However, when I selected option #3 (node Phong), the entire shadow disappeared. I then selected option #2 (node Lambert), and the shadow was there, but the entire aircraft had disappeared.

This suggests that the options selected for the first part of a mesh affect all the other parts that are added to the mesh. So somehow initially defining the mesh using a regular material sets variables to draw the airplane and shadow that are not set or changed by the additional meshes defined with node Materials. Initially defining the mesh using a node Phong material sets a variable to draw the aircraft that is not overridden by subsequent meshes that use node Lambert materials.

I hope that helps you track down the bug.

In the meantime, perhaps part of the fix should be defining meshes with an initial “dummy” regular material?

PS
The lines in question are 312-314.
If I am interpreting the results correctly, there is not a problem with receiving shadows, only casting them.