Ray intersection with vertex buffer

Started by
4 comments, last by jpetrie 16 years, 3 months ago
Is there a simple way of turning a vertex buffer(XYZ|DIFFUSE|NORMAL) into a dx9 mesh so it could used as a parameter to D3DXIntersect? To conclude, I want to do a ray intersection test with an object currently described as a vertex buffer.
Advertisement
You can create an empty mesh using D3DXCreateMesh()/D3DXCreateMeshFVF() and then copy your vertex buffer to it's vertex buffer, but you'll also need to fill it's index buffer and attribute table, which is kind of annoying.

You could also use D3DXIntersectTri() and then you won't have to bother with the above.

This is just what I found by browsing the SDK, so maybe someone will have a better suggestion.
I concur with Gage64's advice. Unless this is static data I'd really avoid creating another resource just to pass it to a function. It's generally a bad thing for performance to be creating/releasing resources during the main rendering loop...

As another thing to consider, if this is for some sort of physics calculation rather than graphics - why are you using rendering information for physics?? Yes, initially it might seem logical but they really are two seperate systems and thus suit different views on a common data set...

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

*tuts* We can only hope he's rendering the bounding volumes as a debug aid.
Quote:Original post by jollyjeffers
I concur with Gage64's advice. Unless this is static data I'd really avoid creating another resource just to pass it to a function. It's generally a bad thing for performance to be creating/releasing resources during the main rendering loop...

As another thing to consider, if this is for some sort of physics calculation rather than graphics - why are you using rendering information for physics?? Yes, initially it might seem logical but they really are two seperate systems and thus suit different views on a common data set...

hth
Jack


The vertex buffers are static so the mesh could aslo be static. The reason is because I try to see if a laser intersects with an object and want to return the distance from the laser source to the object.
Don't use the vertex data for this. It will likely be slow to access, and very slow to compute (it implies iterative triangle/ray intersections... which is very inefficient).

You should keep physical bounding volume information for each object you may need to perform intersection tests on; this information should be distinct from the render geometry. Simple spheres will suffice for the initial test, if you need more accuracy you can perform repeated tests on more specific (tighter fitting) bounding volumes.

This approach is semantically more correct, and vastly more efficient anyway. Consider a model with four thousand triangles. A single simple sphere/ray test will tell you if the laser has compeletely missed the object. If it has, you stop and move on to the next object. If it hasn't, you either take the appropriate action or, if you need more accuracy, perform a better test.

But were you to do this on a per-triangle basis, you'd have to perform four thousand slightly complex triangle/ray tests before you came to the same conclusion, unless you got rather lucky and stumbled across the correct triangle early on.

Another advantage to using bounding volumes is that you can very easily augment the volume hierarchy as needed or as you develop better tests. The crude, simple sphere tests will be sufficient to get things basically working, and you can refine from there.

This topic is closed to new replies.

Advertisement