StaticTriangleGroup.rayCast question(s)

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
BrianL
Posts: 54
Joined: Wed Jun 25, 2008 4:41 pm
Location: Panama City Beach, FL

StaticTriangleGroup.rayCast question(s)

Post by BrianL »

My observations indicate that the normal returned from StaticTriangleGroup.rayCast is the normal for the face, which I assume is computed as the cross-product of two of the edges of the face. Is there any way that you know of that I could get the interpolated normal between the three vertices that define the face? Essentially I need a smoothly interpolated (Barycentric) normal for the face. I'd prefer to leverage the physics system if I can. However, if that's not possible I can do it myself, but I need some kind of identification for the face (three indices, three positions, etc...) so that I can look it up in my own list of faces and compute the interpolated normal.

Thanks.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: StaticTriangleGroup.rayCast question(s)

Post by Norbo »

There's no way this can be currently done just using the raycast call already present, though it will be easy enough to add in v0.6.0.
BrianL
Posts: 54
Joined: Wed Jun 25, 2008 4:41 pm
Location: Panama City Beach, FL

Re: StaticTriangleGroup.rayCast question(s)

Post by BrianL »

Norbo wrote:There's no way this can be currently done just using the raycast call already present, though it will be easy enough to add in v0.6.0.
Cool. Yeah, a simple additional bool parameter to the rayCast function to indicate face or interpolated normal would be helpful for sure...or a whole separate function, or whatever is easiest. Thanks for the quick reply.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: StaticTriangleGroup.rayCast question(s)

Post by Norbo »

There is one significant issue with finding an interpolated normal, as described in another thread (http://www.bepu-games.com/forums/viewto ... ?f=4&t=333). I do not store vertex normals, nor do I store connectivity information outside of an index buffer. Grabbing the position, index (within the group's own list, not any passed in mesh necessarily), and barycentric coordinates are all easy computationally (and are implemented), but to find adjacent triangles/edges for computing an interpolated normal requires a good bit of list navigation.

Without a rework of the group's information storage (which wouldn't be directly useful in terms of the physics engine itself, and would have a bit more overhead in times regular function), finding interpolated normals isn't going to be incredibly quick. You said earlier that if you had the position/index you could find the normals; do you have a setup where it would be a fast operation compared to an index buffer search?

Edit:
One thing I'm currently looking at is the option to create a normal list and/or adjacency list at initialization, so that the information is there only if it will probably be used later.

Re-edit: In practice, I still haven't gotten a solution fast enough to be acceptable even for initialization on nonexcessive meshes of ~20,000 triangles. I'm learning towards the solution of storing an external listing of normals corresponding to the indices within the engine, and then grabbing their vertex normals from the list using the indices returned by the raycast. Slightly indirect, but if it is possible to get a 1 to 1 correspondence between the normal list and internal vertex list, it would be the best solution for interpolated normals.
BrianL
Posts: 54
Joined: Wed Jun 25, 2008 4:41 pm
Location: Panama City Beach, FL

Re: StaticTriangleGroup.rayCast question(s)

Post by BrianL »

That makes sense, since you initialize that StaticTriangleGroup with just positions and indices. However, I do have all of those things (positions, normals, tangents, bitangents, UVs, etc - minus the connectivity data since I don't need it). I've got my own version up and working now with just what I need. For now, I'm manually ray-testing against my "world" so as to stay inside of it. The physics engine is handling all other "dynamics". It's actually working out quite well so far. However, I'm not really taxing the physics system yet. But it's unlikely that it will ever end up being super heavily taxed due to the nature of the desired game play.

To answer your question, if the StaticTriangleGroup doesn't internally re-arrange the data that is used for initialization, then yes, returning the three indices defining the triangle that was hit would be sufficient for me since I have to maintain a list of positions, normals, etc anyway for rendering.

I've noticed that ray-testing meshes with 1000+ triangles is definitely going to require some form of spatial subdivision to help accelerate the process. I will be doing somewhat frequent ray-testing with meshes ranging from a few hundred to 5000+ triangles. I'm currently brute forcing it for the sake of getting something up and running, but will likely be writing some spatial subdivision code by the end of the week.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: StaticTriangleGroup.rayCast question(s)

Post by Norbo »

The group won't rearrange things willy nilly, but it can get a bit confusing if there are multiple meshes (or just a vertex buffer with no associated index buffer being passed in). Passing in multiple meshes will just keep adding the vertices and indices to the end of the lists, while the no index buffer option creates a new vertex buffer and index buffer, making things much more difficult.
Post Reply