Adding a point query

[cadop]

Based on the ideas proposed in ed722e0 , there is some value to providing a primitive id of a point. The problems with doing this through the current APIs hit struct:

1. This is a massive API change effecting nearly all functions that use a raycast
2. The c interface returning this data requires all APIs to be updated, and is a breaking change for any existing code that doesn't expect an additional return
3. To address the first two, more changes to the codebase need to be done to handle this case.
4. Adding another value to the struct will increase its size, which for a single raycast is negligible, but it will impact every raycast from every function, and compound the issue for large ray batches (i.e. size of struct increases, all this data has to be stored, and now more data is transferred through API, which further slows down).

So while not insurmountable, I think there is a solution to what the aim was of ed722e0 , and provides a nice additional feature that should be relatively clean.

Using a new RTCPointQuery (see: https://spec.oneapi.io/oneart/latest/embree-spec.html#rtcpointquery ), we can add a function that allows users to pass a point ( or list of points ), including a radius, and get the primID associated with that point. I took a few minutes to look at the docs. So far from what I can tell, there are a few benefits and features of this method:

1. It doesn't break anything in the current API
2. Should be a straightforward addition to the codebase
3. It adds functionality that the addition of primid in the rayhit struct doesn't have
4. The use is intuitive, get a hitpoint form the API, ask the API for the primid of that hitpoint
5. It can be used outside of rayhits (i.e. some arbitrary point in a scene that the user wants to query on the mesh)
6. A radius can be specified, so points that are close but within some distance can still be used

Some more investigation to the examples are needed though. It's not immediately clear where the callback function should be implemented.

[mariuszhermansdorfer]

It's always interesting to be a new-comer to a project and just mess around with a subset of the existing codebase without understanding the full complexity and thought process that went into creating the API in the first place. Thanks for painting the bigger picture here!
I totally agree that this addition should be a non-breaking change and come with the least effort on our end.

To provide more context why I need this. I'm working on a mesh sculpting app for Rhino:

214147851-04087ad2-517c-484c-b9d4-15d1ea40e26c.mp4

There is a lot to it, but specific to DHART, on mouse move I cast a single ray from the cursor position to identify which mesh vertices fall within the cursor radius. This is the current logic:

1. Cast a ray
2. Get the hit point
3. Get the id of the hit face (primId)
4. Iterate over the face vertices to find the closest one to the hit point
5. Iterate over mesh connectivity to find all vertices within the cursor radius
6. Perform sculpting operation
7. Update the BVH

Switching to RTCPointQuery would allow me to compress points 3-5 into a single query. That's awesome and - as you mention - intuitive to use.

I'd still appreciate a way of updating only portions of the BVH. Currently, I recreate the whole thing on every mouse up. For smaller meshes the penalty is tolerable (5-10 ms) but it gets more noticeable with higher poly counts (240 ms for 1.000.000 triangles).

[cadop]

The app looks awesome!

I'm glad the point query will also work well for this case.

Yes the dynamic BVH is something i've wanted to implement for awhile. I just need to spend some time to figure out a nice way to do it.