Consider adding a method to modify an existing BVH in embree

[mariuszhermansdorfer]

Use case description:

I'm working with a large mesh (500.000 quads) against which I constantly cast single rays from mouse cursor's position. This mesh is then modified while the mouse moves. At any given time only a few dozen vertices are affected. Only vertex position changes, face indices remain unchanged.

Wish

I'd like to be able to keep the existing BVH and only update a subset of vertices.

@cadop, do you have any ideas on how to approach this?

[cadop]

I can take a look at this over the next few weeks (really busy now, and it's a bit of work).

There is a method to add a mesh to the bvh, and if you know ahead of time which parts of your mesh will be modified, you can use the meshid to add and ignore certain meshes.

But I think there is another method in embree we can use for dynamic, but it will take some effort to port it. I remember it will also make rays a bit slower because of how it handles a changing bvh , so I need to add more flags or a new method etc

[mariuszhermansdorfer]

Appreciate it!

I searched a bit and here are my initial findings:

1. There is an official tutorial including source code showing how to work with dynamic scenes
2. The key here is to update the vertex buffer using the rtcUpdateGeometryBuffer method https://github.com/embree/embree/blob/489b746c0d5010e0da10345e9dc96768bec9a037/tutorials/dynamic_scene/dynamic_scene_device.cpp#L268
3. Additionally, it might be a good idea to set the build quality to RTC_BUILD_QUALITY_REFIT https://github.com/embree/embree/blob/489b746c0d5010e0da10345e9dc96768bec9a037/tutorials/dynamic_scene/dynamic_scene_device.cpp#L121-L122
4. Currently the c# interface disposes of buffers after use and for the above methods to work they would have to be stored somewhere.

Somewhat related to this feature request, I had to identify the primitive Id of the hit mesh (essentially its face index) and added these changes to the dev branch: https://github.com/cadop/dhart/pull/51/commits/ed722e0786f5e18b5cc8c5a3c7911fd981eac1ea

Let me know if they should go somewhere else.

[cadop]

You are really moving along!

Yes the dynamic scene is what I was mentioning, but there is a bit more to it for dhart. Since you are getting into the weeds and moving faster than I can comment on, some considerations to keep in mind for what will need to happen...

• We need to consider speed. updating bvh can have some implications here. This means we will need to have a flag to use it or not
• Once we have a flag, there are multiple places the API needs to keep track of what it is using
• We need error handling for when users don't provide valid inputs/changes
• The python API has to get updated for any change that happens to the C interface (part of my delay on pulling dev was that I need to do this)
• There is a 'double precision' flag for the raytracer. the issue about it being called embreebvh has continued, but the backend can switch between nanort for double precision and embree. The functions are templated to support this, so the more we change about the bvh, the harder this becomes
• We need unit tests for everything, including in C api, especiallly for things like keeping hold of references and cleaning them

None of this is saying we can't do it, just some things I hope you can keep in mind when modifying so it is easier/faster for me to go through the PR

Thanks for working on all these features!