Bugs of the BVH structure about three.js-pathtracing-renderer

[erichlof]

Hi @JiaxiangZheng
It is not a bug in the intersection algo - it is a limitation of WebGL 1.0 (GLSL 2.0). You can read a more detailed explanation here - the paragraph underneath the text "* .OBJ Model Loading Demo"

As soon as Three.js implements support for WebGL 2.0, these problems will go away. WebGL 2.0 (GLSL 3.0) allows dynamic indexing of arrays inside shaders, for example currentBVH_Node = BVH_nodes[x] where 'x' is the right number of the branch to go down when traversing the BVH tree. Currently with WebGL 1.0, I can't set 'x' without getting a compilation error. 'x' cannot be a variable, it must be a hard-coded constant like '1'. So I just randomly pick which branch to go down, left or right, instead of accessing them correctly by dynamic index. Even though the BVH traverse algo is randomly and incorrectly choosing which branch to go down, you can see a cloud of all the triangles - they are all there in fact, it's just moving at 60fps switching back and forth branches, therefore you get a blurry model.

But at least I can see that it's loading and walking down the branches ok :)

[Mourtz]

You can always go with a stackless BVH though. This way you won't have to wait for three.js to add support for WebGL 2 and you will cut down the render times.

[erichlof]

Hi @Mourtz
Thanks for the suggestion. Yes this is a direction I would like to explore - there are 2 common approaches, the BVH and the K-D tree: mainly stemming from this paper. It looks like some folks have already implemented it on CUDA hardware: GitHub link. I would need to port those CUDA kernels over to GLSL though.

The stackless one I really want to try is the LBVH because it dynamically creates the acceleration structure in parallel on the GPU every frame, which means you can have moving and dynamic models in the scene, rather than a pre-built, pre-loaded static scene (like a living room). However I must also wait for WebGL 2.0 with this approach because Morton codes and bit manipulations are used to quickly create and sort the tree each frame: GitHub link. WebGL 1.0 does not currently allow bit manipulations in GLSL shaders - it throws a compilation error. But WebGL 2.0 does allow this indeed.

[Mourtz]

Wow haven't seen this approach before, adding this to my OpenCL path tracer shouldn't be so hard. I also found the paper. Should be quite hard to implement this to a GLSL raytracer though, would be awesome if you make it happen someday. Keep up the good work man! :)

[Mourtz]

@erichlof just found out they have already added support for WebGL 2 in the dev branch. link

[erichlof]

@Mourtz
Thanks for the link to that paper! I was trying to locate that source for my earlier reply - I knew I had seen it somewhere, but couldn't remember the name. :)

Oh yes and about the dev branch of three.js for WebGL 2 support, that file hasn't been updated since December of last year. It looks like it gets a WebGL2 rendering context but I don't think it will just run out-of-the-box. Someone has to manually go into the entire library and update all the shader code to read 'in' and 'out' instead of 'attribute' as per this helpful document: Moving to WebGL2
1 person is actively doing it, here.

By the way your SDF ray-marching path tracer is beautiful! I like the nice UI you have for all the settings, and the visual quality is excellent. Have you seen MagicaVoxel yet? It has some of the helpful UI settings like you have. Although it just renders cubes, like Minecraft. Keep up the good work also! ;)

[Mourtz]

For the past 6 months, I have been working on an OpenCL raytracer for my BSc thesis and during this period I understood a lot of stuff in this project are wrong. Hopefully, I will fix them sometime soon. Thanks for your kind words anyways. :)

[erichlof]

Hi @JiaxiangZheng and @Mourtz ,

I just wanted to let you know I have implemented a working BVH builder for .obj models. The new Iterative version is much more robust. You can check it out here: BVH WebGL 2.0 demo

I'm going to go ahead and close out this issue because the old builder (the one that prompted this issue) which was buggy, has been replaced.