PhysX also provides different broad-phase implementations, selected with PxSceneDesc::broadPhaseType. PCM should be the default algorithm since PhysX 3.4, but you can also try to enable it in previous versions like 3.3. PxSceneFlag::eENABLE_PCM enables an incremental “persistent contact manifold” algorithm, which is often faster than the previous implementation. Please refer to the Geometry chapter for details. Generally speaking the new PxMeshMidPhase::eBVH34 introduced in PhysX 3.4 has better performance for scene queries against large triangle meshes. It is a good idea to try the different options and see which one works best for you. PxCookingParams::midphaseDesc can be used to select the desired mid-phase structure. Please refer to the Simulation chapter for details. The PxScene::simulate() function accepts optional scratch buffers that can be used to reduce temporary allocations and improve simulation performance. Using PxConvexMeshGeometryFlag::eTIGHT_BOUNDS enables smaller/tighter bounds, which are more expensive to compute but can result in improved simulation performance when a lot of convex objects are interacting with each other. Consider using tight bounds for convex meshes īy default PhysX computes approximate (loose) bounds around convex objects. Please refer to the Debug Visualization chapter for details. Use a culling box to limit the amount of data the SDK gathers and sends to the renderer. Debug visualization is very slow ĭebug visualization can be very slow, because both the code gathering the debug data and the code rendering it is usually not optimal. Make sure it is disabled in your final/release builds. Disable debug visualization in final/release builds ĭebug visualization is great for debugging but it can have a significant performance impact. If you encounter a performance issue while using other builds, please switch to Release builds and check if the problem is still there. The PhysX SDK has different build configurations: Debug, Checked, Release, Profile. Use release builds for final performance tests However, there still exist various performance pitfalls that the user should be aware of. The PhysX SDK has been optimized a lot in the past dot releases. Note that these bounds only apply to application updates of actor coordinates, not updates by the simulation engine. We recommend the use of PxSceneDesc::sanityBounds, to generate reports when objects are inserted at positions beyond what your application expects, or when application code moves them to such unexpected positions. Limiting coordinates īugs in applications, or issues in content creation, can sometimes result in object placement at unexpected coordinates. This option is available with all build configurations. Note that this is only available in Debug, Checked and Profile builds.Īn alternative to OmniPVD is the built-in debug visualization system. Please refer to the Omniverse Visual Debugger chapter for details. Use the Omniverse Visual Debugger (OmniPVD) to see what PhysX is seeing and make sure the physics data is what you expect it to be. If the SDK silently fails or even crashes in a Release build, please switch to Debug or Checked builds to ensure this is not caused by an uncaught error. Note that some checks can be expensive and thus they are not performed in Release or Profile builds. Please refer to the Error Reporting chapter for details. To make sure that the scene is properly set up without warnings or errors, use either the Debug or Checked builds, and monitor the error callback. Use checked builds and the error stream They can be used to make sure the scenes are properly set up. The PhysX SDK contains a few debugging helpers. This chapter covers a number of best practices for the PhysX SDK to assist in diagnosing and fixing frequently encountered issues.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |