Forum Jump

Select Group :
Select Forum :
Sorted By :
Sort Order :
From The :
 
Thread Tools  Search this thread 
migdalskiy
Total Points:
145
Status Points:
95
Green Belt
November 21, 2008 5:43 PM PST
MOPP serialization

Is MOPP just bounding volume hierarchy, or does it contain the polygons, too? ~10 bytes per triangle seems on the high side for highly-optimized BVH without triangle info. I assume it's KD tree with roughly quantized bounds, each leaf potentially including a reference to one or several triangles. Am I right? Does it include references to convex shapes or triangles only?

If I have a lot of static convex objects, is it better to put them all into one MOPP or create tons of hkpConvexVerticesShapes, and combine them into one container shape, or create tons of hkpConvexVerticesShapes and create hkpRigidBody for each of them? Which is better for runtime - meaning raycasts, spherecasts and collision detection with dynamic objects (tons of ragdolls).

When I serialize hkpMoppBvTreeShape (without using infrastructure), do I absolutely have to serialize its child shape which contains unpacked vertices and triangles? hkpMoppBvTreeShape has a shape container, which points to ExtendedShape, which contains triangle and convex subparts. Do these levels of indirection have any non-negligible runtime cost implications? I.e. is it better to include tons of convex static shapes into hkpExtendedMeshShape, or is it better for the broadphase to create tons of hkpRigidBodies, each with hkpConvexVerticesShape. I assume it should be the same, but perhaps not?

 

havokchris
Total Points:
3,174
Status Points:
2,674
Brown Belt
November 23, 2008 5:41 AM PST
Rate
 
|Best Answer
#1

Hi migdalskiy,

I'm fuzzy on the details, but suffice it to say, the MOPP is more complicated than a kd-tree.

MOPPs don't store the shape information at the leaves, just shape keys for the original shape collection by default. This means that you can include convex shapes (e.g. in an hkpExtendedMeshShape or hkpListShape) in addition to triangle meshes.

For lots of static bodies, I'd recommened that you put them into a single container ( hkpExtendedMeshShape or hkpListShape as above) and wrap a MOPP around them. Basically, the queries that you mentioned will all have to spend time in either the broadphase (if they're all separate bodies) or in the midphase (if they're all wrapped in a MOPP), and MOPP queries are faster than broadphase ones. For 10's or 100's of objects, it might not matter much, but for 1000's of objects, raycasts will get quite expensive, as will adding and removing bodies from the world. But if they're in a MOPP, that only counts as 1 body as far as the broadphase is concerned.

For serialization, it's not necessary to also serialize the shape collection that it was build around BUT you need to make sure that you reproduce the original shape collection after you load the MOPP. Essentially, you can think of a MOPP as something that takes an AABB and gives back shape keys for child shapes within that AABB. So if the shape keys at runtime are different from when the MOPP was built (say, if you add the hkpExtendedMeshShape subparts in a different order), you'll get crashes or weird collisions.

Any cost from the indirection in the shape hierarchy would be negligible next to the algorithmic cost from having lots of bodies in the broadphase (as described above).

Hope that helps clear things up a bit.

-Chris
migdalskiy
Total Points:
145
Status Points:
95
Green Belt
November 24, 2008 9:48 AM PST
Rate
 
#2 Reply to #1
Quoting - havokchris

Hi migdalskiy,

I'm fuzzy on the details, but suffice it to say, the MOPP is more complicated than a kd-tree.

MOPPs don't store the shape information at the leaves, just shape keys for the original shape collection by default. This means that you can include convex shapes (e.g. in an hkpExtendedMeshShape or hkpListShape) in addition to triangle meshes.

For lots of static bodies, I'd recommened that you put them into a single container ( hkpExtendedMeshShape or hkpListShape as above) and wrap a MOPP around them. Basically, the queries that you mentioned will all have to spend time in either the broadphase (if they're all separate bodies) or in the midphase (if they're all wrapped in a MOPP), and MOPP queries are faster than broadphase ones. For 10's or 100's of objects, it might not matter much, but for 1000's of objects, raycasts will get quite expensive, as will adding and removing bodies from the world. But if they're in a MOPP, that only counts as 1 body as far as the broadphase is concerned.

For serialization, it's not necessary to also serialize the shape collection that it was build around BUT you need to make sure that you reproduce the original shape collection after you load the MOPP. Essentially, you can think of a MOPP as something that takes an AABB and gives back shape keys for child shapes within that AABB. So if the shape keys at runtime are different from when the MOPP was built (say, if you add the hkpExtendedMeshShape subparts in a different order), you'll get crashes or weird collisions.

Any cost from the indirection in the shape hierarchy would be negligible next to the algorithmic cost from having lots of bodies in the broadphase (as described above).

Hope that helps clear things up a bit.

-Chris


Thank you for the comprehensive answer!


Intel Software Network Forums Statistics

6668 users have contributed to 28284 threads and 87462 posts to date.
In the past 24 hours, we have 5 new thread(s) 32 new posts(s), and 43 new user(s).

In the past 3 days, the most popular thread for everyone has been Fortran and Matlab The most posts were made to Larger Test Data The post with the most views is Quoting - nabeels Hello e

Please welcome our newest member karolbe