No, your eyes are not deceiving you. After three years of development, NVIDIA has released new major version of PhysX physics engine – PhysX SDK 3.0.
Currently, free binary version of PhysX SDK 3.0 is available for PC only (32-bit and 64-bit, Mac and Linux versions are promised to be delivered later). SDK 3.0 can be downloaded from Developer Support Center. Follow the path: [Online Support] -> [Downloads] -> [PhysX SDK 3.0]
If you are experiencing trouble with registration of PhysX Developer account, please refer to our registration guide.
Update [04.10.2011] PhysX SDK 3.1 released
Update [01.06.2011] PhysX SDK 3.0.1 available
Update [13.05.2011] Physx SDK 3.0 for Mac OSX available
Update [17.05.2011] Physx SDK 3.0 for Linux available (Ubuntu based, 64-bit)
Now, while your download is undergoing, let’s take a look on PhysX SDK 3.0 features:
PhysX SDK 2.x was originally developed as a PC only physics engine, which was subsequently ported to support gaming consoles being developed by Sony (PS3) and Microsoft (Xbox 360). The PS3 port was developed independently and has been maintained in a separate code base since its development, as have later ports to Linux and Mac OSX. The unwieldy growth during the SDK lifetime and separate code bases have added to the considerable complexity of maintaining and updating succeeding versions of the PhysX SDK at a time when faster and more compact engines are required to effectively support phones and tablets.
PhysX SDK 3.0 represents a significant rewrite of the PhysX engine.
This rewrite involved extensive changes to the API that effectively results in a new PhysX engine rather than a chart of changes based on its predecessor version. The various platforms versions are generated from a unified code base, further differentiating it from version 2.x. In addition to a new modular design, considerable legacy clutter has been removed. Collectively these changes have resulted in a physics SDK designed to facilitate easier ongoing maintenance, enable simpler ports to emerging gaming platforms, and the addition of new features and capabilities.
Focus on consoles and emerging gaming platforms.
PhysX SDK 3.0 was designed to be competitive on current-gen consoles and anticipates devices with even less system resources. These architectural changes include but are not limited to better overall memory management, improvements to cache efficiency, cross-platform SIMD implementations, intelligent SPU usage on PS3, multi-threading across multiple cores, and AltiVec/VMX optimizations on Xbox 360.
PhysX SDK 3.0 features new Task Manager feature that supports two Dispatchers (for PC both CPU and GPU Dispatchers are available) that are responsible for managing task dependencies and distributing tasks across as many worker threads as the developer defines. This feature allows the developer to balance the proper mix of resources to achieve the desired performance level.
PhysX SDK 3.0 also incorporates a SolverBatch that supports multiple threads for Rigid Bodies and Deformables that are using different solver islands. Additionally, narrow phase computation can use this feature to run multiple threads.
The particles and particle fluids pipeline currently provides tasks to run the following in parallel (PC/Xbox 360):
- Multiple particle system instances (for collision and SPH phases)
- Multiple work units for collision per particle system instance
- Multiple work units for SPH per particle fluid instance
For PS3 there is additional parallelization available for shape generation, which isn’t implemented yet for PC/Xbox 360. However, it doesn’t provide the parallelization across multiple particle system instances.
PC plus GPU provides more but overall differently structured parallelization.
A reworked vehicle model now includes components such as engine, clutch, gears, autobox, differential, wheels, tyres, suspensions and chassis, in comparison to simplified suspension/wheel/tire NXWheelShape class in PhysX SDK 2.x. One of the interesting aspects of the new model is the ability to create tire types, drivable surface types, and specify the friction used in the vehicle simulator to combine different tire and drivable surface types.
Like PhysX SDK 2.x, the vehicle model exists outside of the PhysX Core and so it does not have to be compiled into a game, to reduce executable size, if not needed. Source code is provided to facilitate developer customization.
New Serialization API.
Serialization (the process by which SDK objects are saved from memory to disk) in SDK 3.0 is much more powerful and much more efficient than in previous SDK versions. It supports all SDK objects, and desterilizes them “in place” – without any data copy or extra memory allocation, allowing them to be loaded as fast as possible. Serialization and cooking are not mutually exclusive though. The cooking library is still available – and mandatory – in the PhysX SDK 3.0. In fact, one cannot serialize a convex or triangle mesh without cooking it first.
Aggregates & Broadphase Clustering.
In PhysX SDK 2.x each NxShape was represented by a separate AABB in the broadphase. This caused a significant performance issue in large scenes, particularly when adding and removing shapes from the scene.
In PhysX SDK 3.0, developers can combine a collection of actors into an aggregate that can be managed as single entity in a broadphase data structure, purely as an optimization feature. For example, assigning the various body parts of a ragdoll to a single aggregate will result in decreased number of overlap tests (while joint limits are already preventing most body parts from penetrating each-other). Thus, in PhysX SDK 3.0, aggregates can be collectively represented by a single AABB in the broadphase, which improves overall efficiency.
This allows the client application to read and write to actors and the scene while the simulation is running on another thread.
An articulation is a single actor representing an acyclic system of jointed actors. Only an anatomical joint (similar to the spherical joint with swing and twist limits) is currently available for articulations. Articulations use solver techniques similar to Featherstone; although, they are more robust than sets of jointed actors and have drive models, which are easier to combine with procedurally generated motion. They’re also much more expensive in terms of CPU processing time.
Deformables and Force Fields.
Cloth and soft bodies were re-organized under one experimental Deformables actor.
Force fields are no longer needed. They were provided in PhysX SDK 2.x primarily because the architecture prevented efficient implementation of user-defined callbacks for force fields. In the PhysX SDK 3.0 implementation, because of the extra freedom allowed by double buffering and other architecture changes, users can efficiently apply forces directly to the rigid bodies and there is no longer a need for the force field mechanism. This approach provides greater flexibility and freedom for developers.
Distance based collision detection.
In PhysX SDK 3.0, collision routines can generate contacts when the shapes are a small distance apart but not quite yet touching. The benefit is that bodies can now come to rest without concern for a tiny overlap between them.
PhysX Visual Debugger Support (PVD).
It is now possible to create different non-uniformly scaled instances of your meshes and convexes without duplicating the memory.
Allows developers to create a staging area outside of the simulation from where they can add things into the simulation at high speed.
SDK 3.0 does not require installation of PhysX System Software on client or developer machine – it is fully driverless, like SDK 2.8.4.
Character Controller has not changed much from that of 2.8.4. It is planned however, to improve it in a future releases.
GPU hardware acceleration in SDK 3.0 is only available for particles/fluids.
Our big thanks to NVIDIA PhysX engineers, who have helped in the preparation of this article