Added the ability to build an octree, and an example of using the built octree to speed up ray detection

[bigbigbig2]

[bigbigbig2]

I added an example comparison. The effect is very obvious for large data. Due to data permission reasons, the code I submitted did not use large data, but used the original small data, so the effect is not as obvious as in my video.

20250721_103749.-.Compressed.with.FlexClip.mp4

[asundqui]

This is tremendous work @bigbigbig2 , thank you for volunteering this code! Please give us some time to review and discuss this... there's great merit here. I wonder a little bit about how this will interact with the "dynamic" nature of Spark... I have some other thoughts about how to do raycast that involve the GPU but are async, maybe this is the right way to get good performance in a "sync" fashion. Just wanted to leave this note so you know this PR hasn't gone unnoticed!

[soundform]

It would be good to make a compact representation of this octree available in the vertex shader, as this will pave the way to many advanced rendering features (https://research.nvidia.com/labs/toronto-ai/3DGRT). For example, simple GI (https://iquilezles.org/articles/simplegi) can be used to properly illuminate splats with an extra light source.

[bigbigbig2]

This is tremendous work @bigbigbig2 , thank you for volunteering this code! Please give us some time to review and discuss this... there's great merit here. I wonder a little bit about how this will interact with the "dynamic" nature of Spark... I have some other thoughts about how to do raycast that involve the GPU but are async, maybe this is the right way to get good performance in a "sync" fashion. Just wanted to leave this note so you know this PR hasn't gone unnoticed!这项工作非常出色，感谢您自愿贡献这段代码！请给我们一些时间来审查和讨论这个……这里有很多价值。我稍微有点好奇这个将如何与 Spark 的“动态”特性交互……我有一些关于如何进行 raycast 的想法，这些想法涉及 GPU 但异步，也许这是以一种“同步”方式获得良好性能的正确方法。只是想留下这个备注，让您知道这个 PR 没有被忽视！

I am very happy to receive your reply. Because this function is a function I have applied in actual production, I am also constantly maintaining and optimizing it. My subsequent updates will be synchronized in the fork warehouse. If there is a need later, I can merge it.

[soundform]

There's also an actively developed https://github.com/gkjohnson/three-mesh-bvh.

[bigbigbig2]

There's also an actively developed https://github.com/gkjohnson/three-mesh-bvh.还有一个活跃开发中的 https://github.com/gkjohnson/three-mesh-bvh。

I also tried this at the beginning, but it does not support instanceBufferGeomtry. I also saw that the author has explained the support in this regard, so I turned to the existing algorithm for constructing acceleration space structure for Gaussian.

[TheExDeus]

GPU based rays can be done with splat depth render (for precise position) or just index rendering (to get splat center) no?
Here is an example with index rendering: https://playcode.io/2572088
Technically it should actually be quite fast, as we render to a 1x1 frame buffer with appropriate clipping, so vertex shader will discard everything not inside that 1x1 pixel. Clipping before would be even better though.
There seems to be issues with sometimes returning 0 even if there is a splat under the mouse, but I feel it might be because of some async issues.
And it renders to int32 buffer, thus max splats is 2,147,483,647 which of course is plenty. But it could be uint32 too and just reserve 0.

[soundform]

FYI, I've been able to get three-mesh-bvh working for splats rendering:

gkjohnson/three-mesh-bvh#760

It does a raymarching loop with a splat.radius/5 step, and for each step it computes shadows. So raycasting with that BVH is quite fast, and it already supports GPU mode.

As for instanced geometry, I'm not sure if that's a real problem. Creating a separate points cloud mesh is cheap, relative to BVH construction costs.