•   Click here to view the Best Answer Next Thread Prev Thread

• Posts   Search Threads

• migdalskiy November 21, 2008 6: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 November 23, 2008 6:41 AM PST Rate   #1 Re: MOPP serialization 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 November 24, 2008 10:48 AM PST Rate   #2 Reply To #1 Re: MOPP serialization 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!

• = Best Answer

  Next Thread Prev Thread

Intel Software Network Forums Statistics

16,365 users have contributed to 46,338 threads and 163,917 posts to date.

For more complete information about compiler optimizations, see our Optimization Notice.