SDF generation demo not work on windows

[MaksimMirR]

Screenshots

Platform:

Any windows machine is the same result

[gkjohnson]

Yes I think @DennisSmolek mentioned the same thing. I don't have access to a windows machine at the moment so any help or investigation into this would be great.

[DennisSmolek]

I've actually been trying to get the example working on my local machine or a sandbox, unfortunately I'm running into the import.meta issue with the worker and can't see a quick fix or how to get it to work in code sandbox...

If someone has the fix for that I'll get back on this grey box sdf thing..

[gkjohnson]

I've actually been trying to get the example working on my local machine or a sandbox, unfortunately I'm running into the import.meta issue

How are you running the examples? It should be better documented / cleaned up but you'll want to run npm start then visit localhost:9080/example/dev-bundle/sdfGeneration.html.

I'd like the get rid of the static-server component and just use parcel in the future, tho.

[CodyJasonBennett]

I put this together for #491 which works on my Windows machines after disabling GPU generation (populating a Data3DTexture on the CPU instead of rendering into a WebGL3DRenderTarget).

• https://codesandbox.io/s/qyv9g0

[DennisSmolek]

@CodyJasonBennett haha I was going to post my fork of that too! https://codesandbox.io/s/three-mesh-bvh-sdf-generation-fbo-forked-fb7r86?file=/src/index.js:8488-8497

If you flip the "surface" value positive you'll see that it goes dark immediately at the cube boundary, which is where the march approximation starts in the GPU version:

I fiddled with things initially the other day and the render pass is still working correctly, but was having a hard time doing a comparison of GPU vs CPU as it has a pretty different setup/flow and not just because it's on the GPU...

On the GPU it calls ThreeJS methods to add some lights.. Which the CPU version skips.

// compute some basic lighting effects
vec3 lightDirection = normalize( vec3( 1.0 ) );
float lightIntensity =
    saturate( dot( normal, lightDirection ) ) +
    saturate( dot( normal, - lightDirection ) ) * 0.05 +0.1;

So my newb brain cant workout if it's say a bad sample or the light is weird etc.

It makes sense, the GPU would be faster/more powerful so add stuff, but on top of the Worker blocking a unbundled build I wasn't able to track down yet.

I'm going to refactor a version of that sandbox and try to make the marching passes as basic and 1:1 so I can better follow where it might be breaking..

[DennisSmolek]

GPU pass

CPU pass and tweaking the surface value in realtime

[DennisSmolek]

I stumbled onto this UnityLabs package and it seems we're all following the same guides.. https://github.com/Unity-Technologies/com.unity.demoteam.mesh-to-sdf/blob/main/Runtime/MeshToSDF.compute#L128 Which they cited as being based on a AMD OpenGPU lib. They actually included it: https://github.com/Unity-Technologies/com.unity.demoteam.mesh-to-sdf/blob/main/_External/TressFXSDF.hlsl#L123

Someone might swoop and and see the bug, but I'm confident I'll be able to work it out eventually!

[CodyJasonBennett]

Here's a minimal recreation toggling between THREE.WebGL3DRenderTarget and THREE.Data3DTexture via the gpuGeneration boolean. https://jsfiddle.net/cbenn/h3cL7tjw/ The page should display green at all times, but is black when gpuGeneration is disabled on Windows/D3D12.

This is clearly an issue between my device and three.js so I'll do a little investigation and forward this over there.

[DennisSmolek]

This is clearly an issue between my device and three.js so I'll do a little investigation and forward this over there. Small addendum I wanted to add is it's not just your device but seems like all windows machines.

Admittedly our sample size is small, but the OP also a Windows user. as is the 2 others I talked with

@N8Python would be interesting to ask too, as they seems to be using the same boilerplate/logic for GPU Generate things and may have a work around..

[gkjohnson]

@N8python would be interesting to ask too, as they seems to be using the same boilerplate/logic for GPU Generate things and may have a work around..

As far as I understand N8 was not rendering directly into a 3d render target.

This sounds like a platform issue, though. Does this happen on all browsers on windows? Or just Chrome?

[CodyJasonBennett]

I can reproduce this on all browsers on Windows. Is there a way to have ANGLE choose Vulcan or some other backend?

[gkjohnson]

I can reproduce this on all browsers on Windows. Is there a way to have ANGLE choose Vulcan or some other backend?

I'm not sure. Maybe it's worth opening a three.js issue with the minimal repro and the consider reporting to Chrome Bugzilla and maybe they can provide some more insight into where this is failing.

[DennisSmolek]

@CodyJasonBennett you have the specifics, but we isolated the issue to problems with the renderTarget / 3D Texture.

Seems it may be a higher up bug.

There are work arounds but they are hacks.

Problem on Chrome/Mac still exists (Onioning)

[CodyJasonBennett]

A work-around would be to render each layer into a 2D render target and iteratively pipe it into a 3D data texture on the CPU. You can see the diff here: https://gist.github.com/CodyJasonBennett/b6172655dd8bcf5a4d11c556394c7210. This is used in practice with https://codesandbox.io/s/simondev-youtube-clouds-rn9kfx.

I'm a bit burnt out right now, but I'll see if I can find time to report this downstream.

[gkjohnson]

In toggling the chrome://flags#use-angle setting for https://github.com/gkjohnson/three-gpu-pathtracer/issues/325#issuecomment-1407232890 I've noticed that the rendering with the OpenGL backend rather than the D3D11 backend fixes this issue. So this seems to definitely be a platform issue specifically with D3D11 ANGLE.

I'm going to try to take some steps to understand where this breaks, though, between the SDF example and working 2d array three.js example.

[makc]

same issue here. Idk if relevant, but did you see this comment at SO:

[gkjohnson]

This has been submitted to and acknowledged as a bug by Chrome:

https://bugs.chromium.org/p/chromium/issues/detail?id=1411048