PxTransform synchronization with own Transform class

I am trying to integrate PhysX 3.4 into my own “game” engine. Naturally, I have my own implementation of Transform. Now I am wondering, what the recommended way is to synchronize the simulated transformation from PhysX with my own transform. Is there a way to pass a reference of my data in any way? I have seen someone do a loop copying all the PxTransform data, but this surely can’t be the right way?

I am very new to PhysX. In fact, I have just recently managed to compile it with my code. I apologize if I’m missing something very obvious. I mostly read the “Users Guide” that was provided, but the information was very scarce. If anyone has a more in depth articles I could read, that would be great.

Thanks in advance and let me know if more info is required.

There isn’t a way to fill in custom data structures with transform data. You will need to either query the transform from the PhysX actor and either use that transform, or convert and copy that transform to your own format.

However, you should not usually need to copy all the data between engines. PhysX can provide a list of active actors, or a list of active transforms (this feature is deprecated as it offers no benefit over active actor list). You should only needs to update the transforms for the subset of actors that are active in your engine.

Internally, PhysX stores actor poses in body space (centered around the computed center of mass of the body), while the public interface operates in model/actor space. There is a space conversion that happens when you set/get the actor’s global pose. These spaces are often the same (e.g. if you are simulating basic shapes like spheres or boxes) but can be quite different when simulating convex meshes or compound shape actors.

Ok thank you. I actually got it to work! Although I have to admit that I am very confused. If this is the only way to do it, then it means that all the big game engines out there are actually copying values back and forth, which blows my mind.

I haven’t gotten that far into the integration to allow for custom shapes, so I might have to ask again at a later point about the space conversion you talked about.

Two additional questions:

  1. As I had to request access to the repository, I assume that I am not allowed to upload the necessary include header files as well as the lib files from PhysX to my public repository right?
  2. I was only able to get VS studio DEBUG mode to work. RELEASE is just not complying. I get the following error:
Error (active)	E0035	#error directive: Exactly one of NDEBUG and _DEBUG needs to be defined!

Thanks for the help!

That error sounds like you are mixing debug and release builds. You need to link debug PhysX with your debug build and one of either checked, profile or release build of PhysX with you release build.

All engines will likely be copying the transforms, but this is unlikely to be a big performance bottleneck when you consider the amount of work required to simulate rigid bodies and compare that to the cost of storing a vector and quaternion per active actor. Different types of rigid bodies may need to be rendered differently, e.g. characters will be rendered after converting the rigid body transforms into per-bone skinning matrices, regular rigid bodies might be drawn with one or more draw calls (depending on the number of geometries). In order to render a lot of rigid bodies, bodies would need to be batched to render multiple rigid bodies in a single draw call otherwise draw call overhead would become a bottleneck, especially if multiple rendering passes were required (e.g. AO, shadows etc.).

Most big engines will have wrapped their use of PhysX with their own physics abstraction. This makes sense from a risk perspective because you then limit how much of your code directly operates on 3rd party types and it makes it easier to swap over to another physics engine in the future if PhysX if required. This would be a lot more difficult if their rendering, animation systems and game-side logic were all operating on PhysX types directly. Wrapping like this adds some overhead so the engine might not be as scalable as a low-level renderer sat on-top of PhysX but a commercial game engine offers so much more than just fast rendering and simulation.

I double checked. I was using the correct release libs. I solved the problem by just adding the “NDEBUG” to the “Preprocessor Definitions” in release mode.

Regarding the value copying, I was just surprised to learn this. How come there is no way to pass a float array of the transformation matrix by reference so the values automatically get filled? But I’m sure the devs had their reasons.

Also do you have any info about the redistribution? So I would need to upload the dlls, libs and header files for the project to compile. Is this allowed?
(Here the repo if relevant https://github.com/Haeri/PhotonBox)

Thanks for helping out so far. I really appreciate it :D

I’m not involved in licensing so I’ll ask someone to come back to you on that. I don’t want to give you incorrect advice.

How come there is no way to pass a float array of the transformation matrix by reference so the values automatically get filled?

While we could offer an API like this, it probably wouldn’t provide any performance advantages over what we have right now.

If PhysX was expected to fill in your matrix, it would need to first compute the model space transform from the mass space transform (we only store the body pose centered around the mass frame of the body in PhysX), then convert from a quaternion+vector pair that we work with internally to a matrix, then store this in your buffer. Furthermore, we would also need to know your matrix format, e.g. row/column major, whether you expect a right or left-handed matrix etc. This is not any less work than you would need to do using our public API.

For simplicity’s sake, the decision was made to just provide the transform and allow the application to then convert it to a suitable format for whatever renderer they are using.

I got some feedback from the legal team. The PhysX EULA requires that you only redistribute PhysX code with developers who have also agreed to NVIDIA Gameworks EULA. This prohibits you from distributing our source with your work unless you can guarantee that access is restricted in this way, which is likely impractical for you to guarantee.

There are no restrictions on releasing our binaries (DLLs) with your product but the difficulty is releasing any source components required to build your engine. The recommendation I was given was for you to include the skeleton folder structure for PhysX that your engine expects and provide instructions to your users to sync a specific PhysX git revision and place the code in your folder structure in order to build your application. This will guarantee you don’t run any risks of infringing the PhysX EULA.

Ok thank you for clarifying. The recommendation with the skeleton sounds very reasonable. Just one more thing I want to clear up: Do the “.lib” files count as binaries or source components? I had to manually recompile them due to CRT versioning issues and asking users to opt into the EULA as well as compiling libs would be just too much to ask just to get my engine to run.

Thanks again for the help!