Sign in to follow this  
Werrock

Ray intersection with vertex buffer

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this