Coder Corner

PhysX 3.4 has a new mesh structure based on Opcode 2, which is used for the “midphase” queries (i.e. any collision query against a triangle mesh).

It is not enabled by default because it currently has some limitations compared to the previous midphase structure:

• it does not support deformable meshes (i.e. it does not support PxTriangleMesh::getVerticesForModification() and PxTriangleMesh::refitBVH())
• it is not implemented on all platforms. It is currently only available on platforms for which PX_INTEL_FAMILY is defined (that includes PCs but also consoles like the Xbox One and PS4).

To enable it, look up the comments for PxCookingParams::midphaseDesc and the PxMidphaseDesc class. Or check the PhysX manual. Or the PEEL code. Basically it will come down to simply adding this line to the cooking params before passing them to PxCreateCooking:

PxCookingParams Params;
Params.midphaseDesc.setToDefault(PxMeshMidPhase::eBVH34);

Overall, the new structure should be faster than the previous one. It is also much faster to build, so if for some reason you must cook triangle meshes at runtime, this new structure should help. Memory usage should be roughly the same as before.

You can see the results in PEEL 1.1. The new midphase structure is selected by default in PEEL, but you can go back to the old one using the “cooking” tab in the PhysX 3.4 plugin’s UI. Note that Opcode 2 used as a standalone library still provides significantly faster results (you can see that in PEEL as well), because PhysX has a larger per-query overhead for management, filtering, etc.

The midphase structure is also used in rigid body simulation, for dynamic objects colliding against triangle meshes (to fetch candidate triangles). So switching to the new structure might also give you performance gains there, even if you are not using scene queries.

In PhysX, debug visualization is enabled or disabled by this call:

PxScene::setVisualizationParameter(PxVisualizationParameter::eSCALE, Value);

With Value = 0.0 to disable it, and usually Value = 1.0 to enable it (but any non-zero value will enable it, and then be used as a scale factor for normals, etc).

Simply setting the PxVisualizationParameter::eSCALE to 1.0 does not render anything on its own. Users have to enable additional flags to tell the system which debug gizmos they want to see. For example here is the list I use in PEEL (but there’s more in the SDK):

• PxVisualizationParameter::eSCALE,
• PxVisualizationParameter::eBODY_AXES,
• PxVisualizationParameter::eBODY_MASS_AXES,
• PxVisualizationParameter::eBODY_LIN_VELOCITY,
• PxVisualizationParameter::eBODY_ANG_VELOCITY,
• PxVisualizationParameter::eCONTACT_POINT,
• PxVisualizationParameter::eCONTACT_NORMAL,
• PxVisualizationParameter::eACTOR_AXES,
• PxVisualizationParameter::eCOLLISION_AABBS,
• PxVisualizationParameter::eCOLLISION_SHAPES,
• PxVisualizationParameter::eCOLLISION_AXES,
• PxVisualizationParameter::eCOLLISION_COMPOUNDS,
• PxVisualizationParameter::eCOLLISION_FNORMALS,
• PxVisualizationParameter::eCOLLISION_EDGES,
• PxVisualizationParameter::eCOLLISION_STATIC,
• PxVisualizationParameter::eCOLLISION_DYNAMIC,
• PxVisualizationParameter::eJOINT_LOCAL_FRAMES,
• PxVisualizationParameter::eJOINT_LIMITS,
• PxVisualizationParameter::eMBP_REGIONS,

Now there is a trap here.

The trap is that if you just set PxVisualizationParameter::eSCALE to 1.0 alone, nothing gets rendered but it still has a performance impact. And it can be invisible to users, until they use a profiler.

For example in PEEL, it means that this particular UI config has a clear negative impact on performance:

And here’s the effect on performance in “ConvexGalore2″:

As you can see this is quite significant. The drop on the blue curve corresponds to the moment I unchecked “Enable debug visualization” in the UI. As soon as I did, performance went back to normal.

So, be aware of this, and make sure you don’t ship your game with PxVisualizationParameter::eSCALE still set to 1.0.