[WebGPU migration] intense shadow acne, and different lighting, after swapping from WebGLRenderer to WebGPURenderer

Questions
1

I applied a basic patch to replace WebGLRenderer with WebGPURenderer, the simple patch seen here.

This causes one of my test cases to have really bad shadow acne, plus the lighting looks different. In either case, I’m using physically correct lights (gonna be nice cleanup when legacy mode is removed).

Here’s the reference example using WebGLRenderer:

https://raw.githack.com/lume/lume/b5242eb39d1f3613c1071f6db40d954ca559faf6/examples/camera-rig.html

Video:

Here’s what it looks like after switching to WebGPURenderer:

You can see the shadow acne is very pronounced, plus the clouds are notably brighter white. (Also the background is broken, which is covered in the background thread)

Any ideas? Could there be an edge case to handle in WebGPURenderer? Or do these things need different values in the material (f.e. MeshPhysicalMaterial or MeshPhysicalNodeMaterial) in order to move forward?

2

Not really sure if this might help with your issue but if you check this topic there is a standalone GLTF Viewer, attached at the bottom of the post and currently using r168, which will allow you to manipulate any parts of the code so you can see the outcome.

In this viewer I went about replacing all applicable materials to node materials - if you do a search for node_materials in the code then you could see where they are used.

GLTF models appear to load and look properly, to me at least.

EDIT: Just updated that viewer to handle VRM files differently and also for materials to cast and receive shadows.

3

Thanks @GitHubDragonFly. The example above is only using a couple spheres and lights. Fairly basic. Actually this demo should be easy to recreate with plain Three.

4

The renderer is still WIP so there are open issues like this one.

With WebGPURenderer we have switched to depth textures for representing shadow maps (so the renderer does not use MeshDepthMaterial anymore). However, this new approach leads to more visible shadow acne which must be handled manually via defining a shadow (normal) bias. Increasing the precision of the depth textures was not helpful so far so there must be another reason why shadow acne occurs more often with depth textures.

1 Like
5

I imagine that the texture could somehow be made the same resolution as what WebGLRenderer would have been doing with MeshDepthMaterial. Is that the issue? Or is there more to it?

6

I experienced issues a long time ago that might be related…

Some of the shaders in threejs use(d) different methods to transform vertices, and thus get slightly different results.
i.e.:

   gl_Position = modelMatrix * viewMatrix * projectionMatrix;

vs:

   gl_Position = modelViewMatrix * projectionMatrix;

looks right on paper, but the modelViewMatrix construction happens in JS with 64 bit math, and the shader construction happens with whatever precision the shader is running at… just throwing it out there as a possibility.

7

@manthrax Is this about the shadow acne? Or did you mean to reply to my other issue about the transforms?

8

I meant about shadow acne.

i.e. the symptoms described sound similar to something I’ve seen before where different functions were used to transform vertices, yielding slightly different results, so shadowmap depths don’t exactly match what the regular shaders output.

1 Like
9

Ah, gotcha. In this case, it seems that the shadow acne pieces are huge compared to any possible imprecision in the sphere surface, but who knows that’s just what I see visually. For example, in the above screenshot, the acne bands (which are like bands of individual shadow triangles) seem to be oriented relative to the direction of the light, and I don’t see any physical waves on the surface of the sphere, only the acne bands. But who knows, maybe I can’t tell just with my eye.