@jo_chemla@BrianKaris Hey ! thanks !!
- after all culling and LOD selection it renders about 30M tris, but it can handle scene with up to 500B tris, maybe even more
- yep i plan on adding webGPU support to use compute shaders to make things faster :)
- plz see my reply here: https://t.co/9FkQ6QnvpN
@edankwan hey ! sorry for the late reply. I tried using uint, but was not sure how to encode both the depth & triangleIndex without breaking the gl.MIN test. imagine you have a depth of 0.01 and a triangleIndex of 999999, how to encode it to only use depth for the gl.MIN test ?
Hi everyone !
as promised, some insights on how the virtual geometry works in webgl 2:
First of all, many thanks to @BrianKaris for sharing info about his work on Nanite:
https://t.co/lP7Ky8goSD
and the slides:
https://t.co/GGVpVLEUHU
ok let's go:
@edankwan hey ! sorry for the late reply. I tried using uint, but was not sure how to encode both the depth & triangleIndex without breaking the gl.MIN test. imagine you have a depth of 0.01 and a triangleIndex of 999999, how to encode it to only use depth for the gl.MIN test ?
There’s obviously lot more going on in the pipeline, but this is just an example of the type of hacks used to make it work in Webgl.
Hope this is helpful !
And on top of this we can use MultipleRenderTargets to store more info, with 1 MRT for each info (triangle index, cluster index, page index, instance index). Since we store the depth in the integer part, that's what will be used to decide which fragment wins the gl.MIN test.
Using a Float32 frame buffer, storing the depth as integer, and triangle info in the decimal part.
But doing so reduces the precision of the depth value we can store, so to compensate we can split the depth into 4 ranges, and store in either red, blue, green or alpha channel.
But if we use a single gl_Point per triangle, compute the triangle screen-space bounding box in the vertex shader, use that bounding box to set the gl_PointSize, and use a custom software rasterizer in fragment shader, we can already get a x2 boost compared to hardware rasterizer
One of the main optimisations is the usage of a (pseudo) software rasterizer for micro triangles.
I say 'pseudo', because since Webgl 2 doesn’t support compute shaders we cannot build a full software rasterizer as they use in Nanite.
@pervasivesense Hey ! Yes that’s only the automatic LOD system. I also started working on streaming+compression but want to improve the rendering before focusing more on that.
@N8Programs@N8Programs hey ! from my testing with Transform feedbacks it seemed to be lot slower than the GPGPU approach. I guess it depends on the use case, but it was 3 to 5 times slower
@Pjbomb2 Hey ! Really nice work :) random guess, but did you try either clamping your new samples or making sure a new sample cannot be x times more brighter than the previously accumulated color? This helps with fireflies and a-trou filtering, so maybe it can help here
There is also an easter egg that changes the look of the whole site. The following video should help you find it.
You will see it directly if you have the metamask enable. 🦊
As promised, more insights on the webgl raytracer.
It is based on this article/paper by Tero Karras:
https://t.co/YAC60rhjql
It uses Morton code to build a BVH binary radix tree on the GPU in realtime.
#webgl#bvh#raytracing
@chrizzlibit Yes indeed it’s okay to have several objects/triangles using the same Morton code,at least at first. But these duplicates need to be handled when building the binary radix tree. Also as you guessed it doesn’t scale to large scenes (yet) but got plans for this(TLAS+per object bvh)