# How to save cooked geometry data in PhysX?

## Recommended Posts

In PhysX 3.3.4, convexmesh\trianglemesh\heightfield should be cooked before use, and they could be cooked offline or at runtime.

According to Geometry, we can cook a geometry in two manners:

• offline manner by streaming
PxDefaultMemoryOutputStream writeBuffer;
cooking.cookTriangleMesh(someDescription, writeBuffer);
PxTriangleMesh* aTriangleMesh = physics.createTriangleMesh(readBuffer);
• or runtime manner by cook api
PxTriangleMesh* aTriangleMesh = theCooking->createTriangleMesh(meshDesc, thePhysics->getPhysicsInsertionCallback());

I should use the offline manner to achieve the best performance. I read the source code of PhysX and found them identical, except for an extra stream in offline manner containing data generated at cook time. So to speed up performance, should I save the stream to disk and recovery the cooked data at runtime to make cook actually "offline"?

However, Serialization says that

Quote

Note: cooking also generates a binary output stream. The primary purpose of cooking, however, is to translate from a user format to a format suitable for the SDK runtime, and so it is not considered a serialization mechanism. Loading a cooked mesh from a stream involves allocation and endian conversion. As a consequence, it is much less efficient than PhysX' binary serialization mechanism. See Shapes for more details about cooking.

So the stream generated in the offline cook manner should not be stored at disk. If that is the case, what does the redundancy stream for?
If I use the PhysX binary serialization mechanism, how to make the cook procedure offline and achieve the best performance?

Edited by stanleyerror

##### Share on other sites

There seems to be a disjoint in the question you are asking and the information used for illustration. Maybe the following will help clarify what you are trying to achieve.

1. If you are cooking high poly mesh, I would refrain from doing so as a tri-mesh is not optimal for PhysX so I would try using convex meshes where appropriate. With that said I don't recall if PhysX limits the number of vertices in a tri-mesh, but it does for convex meshes. Runtime cooking of a few convex meshes is not that slow, but I would image the cost would add up if you are cooking a lot of meshes. The trade-off here would be whether or not you have a hard load-time requirement.

2. When you cook any representation, be resulting binary stream can be serialized to disk and reloaded. This is where I got confused as the 2 snippets posted just shows 2 ways of creating a triangle mesh representation, not the offline/runtime method as you would think.  The first snippet posted would be the same offline/runtime. The only difference being with offline method, some external tool is used to cook the data using the same method as you would at runtime. However, instead of just turning around and consuming the buffer after cooking, the tool would save the stream to disk. Whenever the app is run, the cooked data is read from disk into a stream and used to create the tri-mesh representation.

See the documentation regarding PxPhysics::createTriangleMesh

Hope that helps clarify the issue.

##### Share on other sites

I got a bit confused between the stream of cooked data and the binary serialization mechanism before.

Save/load the stream of cooked data is a local cache mechanism (snippet 1). We can cache the stream (e.g. to a filestream on disk) the first time cooking the geometry, and recover the geometry from the cache file whenever we use, avoiding the cooking procedure. However, due to its platform-dependences, the cached file is better generated and used by one user, its not a good way to distribute or share these cache files with others.

Snippet 2 does runtime cooking, it is suitable for simple geometries, where runtime performance is not that critical.

The binary serialization mechanism is a global resource exchanging mechanism. It is designed to produce, distribute and share physx resources with others. The only two differences between binary serialization and RepX format are human readability and file size.

##### Share on other sites

Yes..that is correct. As long as the platform doesn't change...ex going from PC to ARM etc..your serialize data should work on the same platform it was cooked on. So I don't understand the comment in regards to the cached file is better generated and used by one user.

## Create an account

Register a new account

• 9
• 11
• 21
• 10
• 14
• ### Similar Content

• Hi fellow game devs,
First, I would like to apologize for the wall of text.
As you may notice I have been digging in vehicle simulation for some times now through my clutch question posts. And thanks to the generous help of you guys, especially @CombatWombat I have finished my clutch model (Really CombatWombat you deserve much more than a post upvote, I would buy you a drink if I could ha ha).
Now the final piece in my vehicle physic model is the differential. For now I have an open-differential model working quite well by just outputting torque 50-50 to left and right wheel. Now I would like to implement a Limited Slip Differential. I have very limited knowledge about LSD, and what I know about LSD is through readings on racer.nl documentation, watching Youtube videos, and playing around with games like Assetto Corsa and Project Cars. So this is what I understand so far:
- The LSD acts like an open-diff when there is no torque from engine applied to the input shaft of the diff. However, in clutch-type LSD there is still an amount of binding between the left and right wheel due to preload spring.
- When there is torque to the input shaft (on power and off power in 2 ways LSD), in ramp LSD, the ramp will push the clutch patch together, creating binding force. The amount of binding force depends on the amount of clutch patch and ramp angle, so the diff will not completely locked up and there is still difference in wheel speed between left and right wheel, but when the locking force is enough the diff will lock.
- There also something I'm not sure is the amount of torque ratio based on road resistance torque (rolling resistance I guess)., but since I cannot extract rolling resistance from the tire model I'm using (Unity wheelCollider), I think I would not use this approach. Instead I'm going to use the speed difference in left and right wheel, similar to torsen diff. Below is my rough model with the clutch type LSD:
speedDiff = leftWheelSpeed - rightWheelSpeed; //torque to differential input shaft. //first treat the diff as an open diff with equal torque to both wheels inputTorque = gearBoxTorque * 0.5f; //then modify torque to each wheel based on wheel speed difference //the difference in torque depends on speed difference, throttleInput (on/off power) //amount of locking force wanted at different amount of speed difference, //and preload force //torque to left wheel leftWheelTorque = inputTorque - (speedDiff * preLoadForce + lockingForce * throttleInput); //torque to right wheel rightWheelTorque = inputTorque + (speedDiff * preLoadForce + lockingForce * throttleInput); I'm putting throttle input in because from what I've read the amount of locking also depends on the amount of throttle input (harder throttle -> higher  torque input -> stronger locking). The model is nowhere near good, so please jump in and correct me.
Also I have a few questions:
- In torsen/geared LSD, is it correct that the diff actually never lock but only split torque based on bias ratio, which also based on speed difference between wheels? And does the bias only happen when the speed difference reaches the ratio (say 2:1 or 3:1) and below that it will act like an open diff, which basically like an open diff with an if statement to switch state?
- Is it correct that the amount of locking force in clutch LSD depends on amount of input torque? If so, what is the threshold of the input torque to "activate" the diff (start splitting torque)? How can I get the amount of torque bias ratio (in wheelTorque = inputTorque * biasRatio) based on the speed difference or rolling resistance at wheel?
- Is the speed at the input shaft of the diff always equals to the average speed of 2 wheels ie (left + right) / 2?