Migrating From PhysX SDK 3.2 to 3.3

• This guide highlights all significant parts of the API that have changed in the last dot release. An application with a working integration of the older version of PhysX should be able to easily migrate to the newer version by following these pointers.

Math Classes

The static createIdentity() and createZero() methods are now deprecated, and will be removed in a future release. The preferred method is to use the constructors PxMat33(PxIdentity), PxMat44(PxIdentity), PxQuat(PxIdentity), PxTransform(PxIdentity) for identity transforms, and PxMat33(PxZero) and PxMat44(PxZero) for zero matrices.

Scene Query API

• The Scene Query API underwent significant changes. The highlights are:

  • Former raycastAny, raycastMultiple, raycastSingle API calls are now folded into a single PxScene::raycast call

    • Same for overlaps and sweeps

    • Same for PxBatchQuery and PxVolumeCache

    • For PxScene queries a deprecated backwards compatibility mapping was added to aid the transition

      • This mapping will be removed in the next dot release

  • There are now dedicated callback and buffer classes for receiving query results, replacing PxRaycastHit array and count parameters.

    • Same for sweeps and overlaps
    • See PxRaycastBuffer, PxSweepBuffer, PxOverlapBuffer, PxRaycastCallback, PxSweepCallback, PxOverlapCallback

  • The way results are returned is now more robust and it is possible to transparently handle unbounded number of results without dynamic allocations.

  • Header PxSceneQueryFiltering.h was renamed to PxQueryFiltering.h, PxSceneQueryReport.h to PxQueryReport.h

  • PxHitFlag::eIMPACT changed to PxHitFlag::ePOSITION

  • PxRaycastHit.impact renamed to PxRaycastHit.position (same for PxSweepHit.impact)

  • PxQueryFlag::eNO_BLOCK and PxQueryFlag::eANY_HIT flags were added

  • The following classes were renamed

    • PxSceneQueryHit -> PxQueryHit
    • PxSceneQueryFlags -> PxHitFlags
    • PxSceneQueryHitType -> PxQueryHitType
    • PxSceneQueryFilterData -> PxQueryFilterData
    • PxSceneQueryFilterCallback -> PxQueryFilterCallback
    • PxSceneQueryFilterFlags -> PxQueryFlags
    • PxSceneQueryCache -> PxQueryCache
    • PxCCTNonWalkableMode -> PxControllerNonWalkableMode
    • PxControllerFlags -> PxControllerCollisionFlags
    • PxCCTHit -> PxControllerHit
    • PxConstraintDominance -> PxDominanceGroupPair
    • PxActorTypeSelectionFlags -> PxActorTypeFlags
    • PxFindOverlapTriangleMeshUtil -> PxMeshOverlapUtil
    • Old versions are #defined to new versions to simplify transition. These #defines are deprecated and will be phased out.

  • queryClient parameter was removed from raycast/sweep/overlap parameter list and added to PxQueryFilterData

    • The fix is to simply pass the same value via PxQueryFilterData::clientId

  • PxBatchQueryDesc now requires 3 parameters at construction time, PxU32 maxRaycastsPerExecute, PxU32 maxSweepsPerExecute, PxU32 maxOverlapsPerExecute

    • Each of these numbers is an upper bound on the number of PxBatchQuery::raycast(), sweep() and overlap() calls before a call to execute()
    • Previously there was no way to check for results buffer overflow in batch query code since sizes of these buffers were not specified.
    • The fix is to specify the batch query result (different from hit) buffer sizes at construction.

  • PxBatchQueryDesc no longer directly holds pointers to memory for queries, in 3.3 these are moved to PxBatchQueryMemory.

    • It is now possible to set a new batch query memory descriptor before each execute
    • userRaycastHitBuffer has been renamed to userRaycastTouchBuffer
    • raycastHitBufferSize has been renamed to raycastTouchBufferSize
    • same for overlaps and sweeps (userSweepHitBuffer, sweepHitBufferSize, userOverlapHitBuffer, overlapHitBufferSize)
    • A code snippet below illustrates the migration for these code changes

  • PxQueryFilterData constructors are now explicit. This means that previously it was possible to write

    • scene->raycast(..., PxQueryFlag::eDYNAMIC | PxQueryFlag::eSTATIC, ...), causing PxQueryFilterData to be implicitly constructed by the compiler
    • now it is required to explicitly write: scene->raycast(...,PxQueryFilterData(PxQueryFlag::eDYNAMIC | PxQueryFlag::eSTATIC), ...)
    • This change was made to improve type safety and reduce confusion while reading the code employing implicit constructors

  • PxRaycastBufferN, PxOverlapBufferN and PxSweepBufferN were added for convenience

    • A buffer object with space for 10 touching hits and one blocking hit can now be conveniently declared as PxRaycastBufferN<10> hits;

  • PxRaycastHit and PxSweepHit now inherit from PxLocationHit (formerly from PxSceneQueryImpactHit)

  • bool PxLocationHit::hadInitialOverlap() function was added to determine if a swept shape was overlapping at sweep distance=0 or if a raycast hit a shape at distance=0.

  • Functionality of PxSceneQueryFlag::eINITIAL_OVERLAP and PxSceneQueryFlag::eINITIAL_OVERLAP_KEEP was replaced with PxHitFlag::eASSUME_NO_INITIAL_OVERLAP and PxLocationHit::hadInitialOverlap().

  • Overlap scene queries with preFilter or postFilter returning multiple eBLOCK hits would previously return multiple results as touching hits.

    • eBLOCK should not be returned from user filters for overlap(). Doing so will result in undefined behavior, and a warning will be issued.
    • If the PxQueryFlag::eNO_BLOCK flag is set, the eBLOCK will instead be automatically converted to an eTOUCH and the warning suppressed.

  • Sweeps in 3.3 execute using a new faster code path, in some cases with reduced precision. If you encounter precision issues not previously experienced in earlier versions of PhysX, use ePRECISE_SWEEP flag to enable the backwards compatible more accurate sweep code.

• Snippets demonstrating API migration:

Former raycastSingle call:

PxRaycastHit hit;
bool hadHit = scene->raycastSingle(..., hit, ...);
if (hadHit) doStuff(hit);

Is now:

PxRaycastBuffer buf;
Bool hadHit = scene->raycast(..., buf, ...);
if (hadHit) doStuff(buf.block);

Former raycastAny call:

PxSceneQueryHit hit;
bool hadHit = scene->raycastAny(hit);
if (hadHit) doStuff(hit);

Is now:

PxRaycastBuffer buf; // declare a hit buffer with room for a single blocking hit
PxFilterData fdAny; fdAny.flags |= PxQueryFlag::eANY_HIT;
bool hadHit = scene->raycast(buf, PxHitFlags(), fdAny);
if (hadHit) doStuff(buf.block);

Former Multiple call:

PxRaycastHit buffer[N];
bool hasBlock;
PxI32 result = Scene->raycastMultiple(buffer, N, hasBlock);
if (result == -1)
    handleOverflow();
else
{
    if (hasBlock)
    {
        doBlocking(buffer[result-1]);
        doTouches(buffer, result-1);
    }
    else
    {
        doTouches(buffer, result);
    }
}

Is now:

PxRaycastBufferN<N> buf;
scene->raycast(buf);
if (buf.hasBlock)
    doBlocking(buf.block);
doTouches(buf.touches, buf.nbTouches);

or:

for (PxU32 i = 0; i < buf.getNbAnyHits(); i++) // "any" in this context refers to blocking or
                                               // touching hits
    doAnyHit(buf.getAnyHit(i));

Former batch query memory setup code in 3.2:

const PxU32 maxRaycastHits = 16, maxRaycastQueries = 8;
PxRaycastQueryResult* resultBuffer = new PxRaycastQueryResult[maxRaycastQueries];
PxRaycastHitBuffer* hitBuffer = new PxRaycastHit[maxRaycastHits];
PxBatchQueryDesc desc; // required no arguments, there was no safety check for maximum number
                       // of queries per batch (not hits per query)
desc.userRaycastResultBuffer = resultBuffer;
desc.userRaycastHitBuffer = hitBuffer;
desc.raycastHitBufferSize = maxRaycastHits;
PxBatchQuery* bq = PxCreateBatchQuery(desc);
for (PxU32 iQuery = 0; iQuery < maxRaycastQueries; iQuery++)
    bq->raycastSingle(...); // up to 8 raycast queries are allowed per PxBatchQuery::execute()
                            // call but there was no overflow check in 3.2
bq->execute();

for (PxU32 iResult = 0; iResult < nQueries; iResult++)
{
    for (PxU32 iHit = 0; iHit < resultBuffer[i].nbHits; iHit++)
    {
        bool isBlocking = (iHit == resultBuffer[i].nbHits &&
            (resultBuffer[iResult].hits[iHit].flags & PxSceneQueryFlag::eBLOCKING_HIT));
        processHit(resultBuffer[iResult].hits[iHit], isBlocking);
    }
}

Batch query setup code in 3.3:

const PxU32 maxRaycastHits = 16, maxRaycastQueries = 8;
PxBatchQueryDesc desc(maxQueries, 0, 0); // note the new required maximum of queries per batch
                                         // (this is different from maximum hits)
PxBatchQuery* bq = scene->createBatchQuery(desc);

PxRaycastQueryResult* resultBuffer = new PxRaycastQueryResult[maxRaycastQueries];
PxRaycastHitBuffer hitBuffer = new PxRaycastHit[maxRaycastHits];
PxBatchQueryMemory mem(maxQueries, 0, 0); // maximum number of queries for each type
                                          // (raycasts, overlaps, sweeps)
mem.userRaycastResultBuffer = resultBuffer;
mem.userRaycastTouchBuffer = hitBuffer;
mem.raycastTouchBufferSize  = maxHits;

PxBatchQuery* bq = PxCreateBatchQuery(desc);
bq->setUserMemory(mem);

for (PxU32 iQuery = 0; iQuery < maxRaycastQueries; iQuery++)
    bq->raycastSingle(...); // up to 8 raycast queries are allowed per PxBatchQuery::execute()
                            // with query count overflow check as of 3.3
bq->execute();

for (PxU32 iResult = 0; iResult < nQueries; iResult++)
{
    // note that the blocking hit is now reported in resultBuffer[i].block and touching hits in
    // resultBuffer[i].touches
    for (PxU32 iHit = 0; iHit < resultBuffer[i].nbTouches; iHit++)
        processTouchingHit(resultBuffer[iResult].touches[iHit]);

    processBlockingHit(resultBuffer[iResult].block);
}

SPU batch queries

In 3.2 the number of SPUs to be used per batch query was controlled by a global setting via setSceneParamInt call:

PxPS3Config::setSceneParamInt(getScene(), PxPS3ConfigParam::eSPU_RAYCAST, 3);

In 3.3 PxBatchQuery no longer automatically executes on multiple SPUs but requires a separate PPU thread, this design allows higher flexibility, such as executing batches on multiple SPU and PPU threads simultaneously, better control of parallel execution and allows the user to fine tune thread load balancing. Here's one possible way to run batch queries on multiple SPUs in 3.3:

struct BQThread : shdfnd::Thread
{
    Ps::Sync mBatchReady;
    Ps::Sync mBatchCompleted;
    PxBatchQuery* mBatch;

    PX_FORCE_INLINE BQThread() { mBatch = NULL; }
    PX_FORCE_INLINE void submitBatch(PxBatchQuery* batch) { mBatch = batch; }

    virtual void execute()
    {
        // execute submitted batches until quit is signalled
        for(;;)
        {
            mBatchReady.wait();
            mBatchReady.reset();

            if (quitIsSignalled())
                break;

            mBatch->execute();

            mBatch = NULL;
            mBatchCompleted.set();
        } // for (;;)

        quit(); // shutdown thread
    }
};

// main thread code:
// pre-create and launch batch execute threads
for (PxU32 iThread = 0; iThread < nThreads; iThread++)
{
    BQThread* t = PX_NEW(BQThread);
    t->start();
    mThreads.pushBack(t);
}

// submit batches
for (PxU32 iThread = 0; iThread < nThreads; iThread++)
{
    // create batches
    PxBatchQuery* threadBatch = createBatch(...);
    threadBatch->setRunOnSpu(true);

    mThreads[iThread]->submitBatch(threadBatch);
    mThreads[iThread]->mBatchReady.set();
}

// execute another batch on PPU in the meantime.
PxBatchQuery* threadBatch = createBatch(...);
threadBatch->setRunOnSpu(false);
threadBatch->execute();

// do other PPU work...

// wait for SPU batches to complete:
for (PxU32 i=0; i<mThreads.size(); ++i)
{
    mThreads[i]->mBatchCompleted.wait();
    mThreads[i]->mBatchCompleted.reset();
    releaseBatch(mThreads[i]->mBatch);
}

// terminate batch threads
for (PxU32 i=0; i<mThreads.size(); ++i)
{
    mThreads[i]->signalQuit();
    mThreads[i]->mBatchReady.set();
    mThreads[i]->waitForQuit();
    PX_DELETE(mThreads[i]);
}

Whether the batch is executed on SPU or PPU is determined by either bool PxBatchQueryDesc::runOnSpu or PxBatchQuery::setRunOnSpu(bool), by default batch query is executed on SPU:

PxBatchQueryDesc desc;
...
desc.runOnSpu = true;
...

Core PhysX

• The following methods require that the corresponding objects have been added to a scene. Calling these methods for objects which are not in a scene will result in undefined behavior. In the CHECKED build configuration an error message will get sent.

  • addForce/addTorque/clearForce/clearTorque() on a PxRigidBody
  • isSleeping/wakeUp/putToSleep() on a PxRigidDynamic, PxArticulation or PxCloth
  • PxScene::resetFiltering() and the deprecated counterparts on PxShape and PxParticleBase

• The sleep behavior of dynamic rigid bodies has changed significantly. Among the changes are:

  • The wakeUp() method of PxRigidDynamic and PxArticulation has lost the wake counter parameter. Use the newly introduced method setWakeCounter() instead to set a specific value.
  • Putting a dynamic rigid actor to sleep will clear any pending force updates.
  • Switching a dynamic actor to kinematic will put the actor to sleep immediately.
  • Switching a kinematic actor back to dynamic will not affect the sleep state (previously the actor was woken up).
  • Calling wakeUp/putToSleep() on a kinematically controlled dynamic actor is not valid any longer. The sleep state of a kinematic actor is solely defined based on whether a target pose has been set (see API documentation of isSleeping() for details).
  • A call to PxRigidBody::setCMassLocalPose() does not wake up the actor anymore. Add a call to PxRigidBody::wakeUp() to get the old behavior back. Note: this also affects related methods in PhysXExtensions like PxRigidBodyExt::updateMassAndInertia() etc.
  • Adding or removing a PxConstraint to/from the scene does not wake the connected actors up automatically anymore (note: this applies to PxJoint in PhysX Extensions as well).
  • If a non-zero velocity or force is set through PxRigidBody::setLinearVelocity(), ::setAngularVelocity(), ::addForce() or ::addTorque(), the actor will get woken up automatically even if the autowake parameter is false.
  • PxRigidBody::clearForce() and ::clearTorque() do not have the autowake parameter, to optionally wake the actor up, anymore. These methods will not change the sleep state any longer. Call ::wakeUp() subsequently to get the old default behavior.

• Shapes may now be shared between actors. This change has several ramifications:

  • PxShape::getActor() now returns a pointer rather than a reference. If the shape is shareable, the pointer is NULL.
  • The following methods of PxShape have been removed: getGlobalPose(), raycast(), sweep(), overlap(), getWorldBounds(). Replacements can be found in PxShapeExt.
  • PxShape now has the same reference counting semantics as meshes and materials, so that release() releases the user reference, and when the last reference is released, the shape is destroyed.
  • Shapes created through PxRigidActor::createShape() are still destroyed automatically when the actor is released. However, after serializing and deserializing such a shape, the regular reference counting semantics apply.
  • return results from scene queries which previously specified a shape now specify an actor also.

• Shape local transforms cannot be specified on shape creation anymore. Instead set the local transform after creation with PxShape::setLocalPose().

• The PxObserver/PxObservable system has been replaced by the PxDeletionListener API. The supported object types have been extended from PxActor to all core objects inheriting from PxBase. Furthermore, two kinds of deletion events are now distinguished: user release and memory release. The following snippet shows pseudocode for the transition from the previous to the new API:

old API:

class MyObserver : public PxObserver
{
public:
    virtual void onRelease(const PxObservable& observable);
}

MyObserver myObs;
PxRigidDynamic* d = create...;
d->registerObserver(myObs);

new API:

class MyDelListener : public PxDeletionListener
{
public:
    virtual void onRelease(const PxBase* observable, void* userData,
        PxDeletionEventFlag::Enum deletionEvent);
}

MyDelListener myDelListener;
PxPhysics* physics = create...;
PxRigidDynamic* d = create...;
physics->registerDeletionListener(myDelListener, PxDeletionEventFlag::eUSER_RELEASE, true);
PxBase* b = d;
physics->registerDeletionListenerObjects(myDelListener, &b, 1);

• The contactStream in PxContactPair is now stored in a variable-size compressed contact stream. This is used to save memory. As such, you can no longer simply cast it to a PxContactPoint* and access the data. Instead, you must either use PxContactPair::extractContacts or us a PxContactStreamIterator to interpret the data. Please see the callbacks section of the user guide for further information.

• The friction API and behavior for dynamic rigid bodies has changed slightly:

  • Friction mode flags eENABLE_ONE_DIRECTIONAL_FRICTION and eENABLE_TWO_DIRECTIONAL_FRICTION have been replaced by PxFrictionType::Enum PxSceneDesc::frictionType.
  • PxSceneDesc::contactCorrelationDistance has been deprecated, and it no longer has an influence on how many friction anchors are created in a single frame, only on when they are removed in later frames. This may cause a very minor change in friction behavior.

• PxShape::resetFiltering() and PxParticleBase::resetFiltering() have been deprecated. Please use one of the new overloaded methods PxScene::resetFiltering() instead.

• PxClientBehaviorBit and PxActorClientBehaviorBit have been renamed to PxClientBehaviorFlag and PxActorClientBehaviorFlag respectively.

• PxActorTypeSelectionFlag and PxActorTypeSelectionFlags have been renamed to PxActorTypeFlag and PxActorTypeFlags respectively.

• PxConstraintDominance has been renamed to PxDominanceGroupPair

• The parameter 'spring' on articulation joints has been renamed 'stiffness'.

• The parameter 'tangentialSpring' on articulation joints has been renamed 'tangentialStiffness'.

• PxConstraintFlag::Type has been renamed to PxConstraintFlag::Enum

• Discrete contact reports are no longer produced for pairs without PxPairFlag::eDETECT_DISCRETE_CONTACT raised in the filter shader. Previously, discrete contact generation would always have been performed regardless of the presence of the PxPairFlag::eDETECT_DISCRETE_CONTACT flag. This change potentially improves performance when using specific shapes for CCD-only collision, which would have previously generated discrete contacts and then ignored them in the solver.

• Trigger reports are no longer produced for pairs without PxPairFlag::eDETECT_DISCRETE_CONTACT raised in the filter shader. PxPairFlag::eTRIGGER_DEFAULT has been modified to include the PxPairFlag::eDETECT_DISCRETE_CONTACT flag.

PhysX Extensions

• Joint limits have been more carefully separated into PxJointLinearLimit, PxJointAngularLimitPair, PxJointLinearLimitPair.
• PxJoint::getType() is deprecated. Joints now inherit from PxBase, and getConcreteType() replaces getType(). Alternatively, to dynamically cast to a particular joint type, use e.g. joint->is<PxD6Joint>() which will return a pointer to a D6 joint if the type matches, otherwise NULL.
• The parameter 'spring' in joint limits and drives has been renamed 'stiffness'.
• Dominance settings no longer apply to joints. To achieve this effect, use setInvMassScale. For example if actor0 in the joint is to affect actor1 but not conversely, use setInvMassScale0(0.0f), setInverseInertiaScale0(0.0f).

PhysX Character Controller

• When creating a PxControllerManager, a reference to a PxScene has to be provided. As a consequence, creating a controller from a PxControllerManager now only requires the controller descriptor as an argument.
• On PxControllerManager::release(), all associated PxObstacleContext instances will get deleted automatically. Make sure to not access PxObstacleContext instances after the corresponding manager has been released.

PhysX Vehicles

• A new struct has been introduced to hold the enumerated list that began with PxVehicleDrive4W::eFRONT_LEFT_WHEEL. The changes are

  • PxVehicleDrive4W::eFRONT_LEFT_WHEEL -> PxVehicleDrive4WWheelOrder::eFRONT_LEFT
  • PxVehicleDrive4W::eFRONT_RIGHT_WHEEL -> PxVehicleDrive4WWheelOrder::eFRONT_RIGHT
  • PxVehicleDrive4W::eREAR_LEFT_WHEEL -> PxVehicleDrive4WWheelOrder::eREAR_LEFT
  • PxVehicleDrive4W::eREAR_RIGHT_WHEEL -> PxVehicleDrive4WWheelOrder::eREAR_RIGHT

• A new struct has been introduced to hold the enumerated list that began with PxVehicleDrive4WControl::eANALOG_INPUT_ACCEL. The changes are

  • PxVehicleDrive4W::eANALOG_INPUT_ACCEL -> PxVehicleDrive4WControl::eANALOG_INPUT_ACCEL
  • PxVehicleDrive4W::eANALOG_INPUT_BRAKE -> PxVehicleDrive4WControl::eANALOG_INPUT_BRAKE
  • PxVehicleDrive4W::eANALOG_INPUT_HANDBRAKE -> PxVehicleDrive4WControl::eANALOG_INPUT_HANDBRAKE
  • PxVehicleDrive4W::eANALOG_INPUT_STEER_LEFT -> PxVehicleDrive4WControl::eANALOG_INPUT_STEER_LEFT
  • PxVehicleDrive4W::eANALOG_INPUT_STEER_RIGHT -> PxVehicleDrive4WControl::eANALOG_INPUT_STEER_RIGHT
  • PxVehicleDrive4W::eMAX_NUM_DRIVE4W_ANALOG_INPUTS -> PxVehicleDrive4WControl::eMAX_NB_DRIVE4W_ANALOG_INPUTS

• A new struct has been introduced to hold the enumerated list that began with PxVehicleDrive4W::eFRONT_LEFT_WHEEL. The changes are

  • PxVehicleDriveTank::eTANK_WHEEL_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::eFRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::eFRONT_RIGHT,
  • PxVehicleDriveTank::eTANK_WHEEL_1ST_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e1ST_FROM_FRONT_LEFT,
  • PxVehicleDriveTank::eTANK_WHEEL_1ST_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e1ST_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_2ND_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e2ND_FROM_FRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_2ND_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e2ND_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_3RD_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e3RD_FROM_FRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_3RD_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder:: e3RD_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_4TH_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e4TH_FROM_FRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_4TH_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e4TH_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_5TH_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e5TH_FROM_FRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_5TH_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e5TH_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_6TH_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e6TH_FROM_FRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_6TH_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e6TH_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_7TH_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e7TH_FROM_FRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_7TH_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e7TH_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_8TH_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e8TH_FROM_FRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_8TH_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e8TH_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_9TH_FROM_FRONT_LEFT -> PxVehicleDriveTankWheelOrder::e9TH_FROM_FRONT_LEFT
  • PxVehicleDriveTank::eTANK_WHEEL_9TH_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e9TH_FROM_FRONT_RIGHT
  • PxVehicleDriveTank::eTANK_WHEEL_9TH_FROM_FRONT_RIGHT -> PxVehicleDriveTankWheelOrder::e9TH_FROM_FRONT_RIGHT

• A new struct has been introduced to hold the enumerated list that began with PxVehicleDriveTank::eANALOG_INPUT_ACCEL. The changes are

  • PxVehicleDriveTank::eANALOG_INPUT_ACCEL -> PxVehicleDriveTankControl::eANALOG_INPUT_ACCEL
  • PxVehicleDriveTank::eANALOG_INPUT_BRAKE_LEFT -> PxVehicleDriveTankControl::eANALOG_INPUT_BRAKE_LEFT
  • PxVehicleDriveTank::eANALOG_INPUT_BRAKE_RIGHT -> PxVehicleDriveTankControl::eANALOG_INPUT_BRAKE_RIGHT
  • PxVehicleDriveTank::eANALOG_INPUT_THRUST_LEFT -> PxVehicleDriveTankControl::eANALOG_INPUT_THRUST_LEFT
  • PxVehicleDriveTank::eANALOG_INPUT_THRUST_RIGHT -> PxVehicleDriveTankControl::eANALOG_INPUT_THRUST_RIGHT
  • PxVehicleDriveTank::eMAX_NUM_DRIVETANK_ANALOG_INPUTS -> PxVehicleDriveTankControl::eMAX_NB_DRIVETANK_ANALOG_INPUTS

• A new struct has been introduced to hold the enumerated list that began with PxVehicleDriveTank::eDRIVE_MODEL_STANDARD. The changes are

  • PxVehicleDriveTank::eDRIVE_MODEL_STANDARD -> PxVehicleDriveTankControlModel::eSTANDARD
  • PxVehicleDriveTank::eDRIVE_MODEL_SPECIAL -> PxVehicleDriveTankControlModel::eSPECIAL

• A new struct has been introduced to hold the enumerated list that began with eVEHICLE_TYPE_DRIVE4W. The changes are

  • eVEHICLE_TYPE_DRIVE4W -> PxVehicleTypes::eDRIVE4W
  • eVEHICLE_TYPE_DRIVETANK -> PxVehicleTypes::eDRIVETANK
  • eVEHICLE_TYPE_NODRIVE -> PxVehicleTypes::eNODRIVE
  • eMAX_NUM_VEHICLE_TYPES -> PxVehicleTypes::eMAX_NB_VEHICLE_TYPES

• A new struct has been introduced to hold the enumerated list that began with PxVehicleGraph::eCHANNEL_JOUNCE. The changes are

  • PxVehicleGraph::eCHANNEL_JOUNCE -> PxVehicleWheelGraphChannel::eJOUNCE
  • PxVehicleGraph::eCHANNEL_SUSPFORCE -> PxVehicleWheelGraphChannel::eSUSPFORCE
  • PxVehicleGraph::eCHANNEL_TIRELOAD -> PxVehicleWheelGraphChannel::eTIRELOAD
  • PxVehicleGraph::eCHANNEL_NORMALIZED_TIRELOAD -> PxVehicleWheelGraphChannel::eNORMALIZED_TIRELOAD
  • PxVehicleGraph::eCHANNEL_WHEEL_OMEGA -> PxVehicleWheelGraphChannel::eWHEEL_OMEGA
  • PxVehicleGraph::eCHANNEL_TIRE_FRICTION -> PxVehicleWheelGraphChannel::eTIRE_FRICTION
  • PxVehicleGraph::eCHANNEL_TIRE_LONG_SLIP -> PxVehicleWheelGraphChannel::eTIRE_LONG_SLIP
  • PxVehicleGraph::eCHANNEL_NORM_TIRE_LONG_FORCE -> PxVehicleWheelGraphChannel::eNORM_TIRE_LONG_FORCE
  • PxVehicleGraph::eCHANNEL_TIRE_LAT_SLIP -> PxVehicleWheelGraphChannel::eTIRE_LAT_SLIP
  • PxVehicleGraph::eCHANNEL_NORM_TIRE_LAT_FORCE -> PxVehicleWheelGraphChannel::eNORM_TIRE_LAT_FORCE
  • PxVehicleGraph::eCHANNEL_NORM_TIRE_ALIGNING_MOMENT -> PxVehicleWheelGraphChannel::eNORM_TIRE_ALIGNING_MOMENT
  • PxVehicleGraph::eMAX_NUM_WHEEL_CHANNELS -> PxVehicleWheelGraphChannel::eMAX_NB_WHEEL_CHANNELS

• A new struct has been introduced to hold the enumerated list that began with PxVehicleGraph::eCHANNEL_ENGINE_REVS. The changes are

  • PxVehicleGraph::eCHANNEL_ENGINE_REVS -> PxVehicleDriveGraphChannel::eENGINE_REVS
  • PxVehicleGraph::eCHANNEL_ENGINE_DRIVE_TORQUE -> PxVehicleDriveGraphChannel::eENGINE_DRIVE_TORQUE
  • PxVehicleGraph::eCHANNEL_CLUTCH_SLIP -> PxVehicleDriveGraphChannel::eCLUTCH_SLIP
  • PxVehicleGraph::eCHANNEL_ACCEL_CONTROL -> PxVehicleDriveGraphChannel::eACCEL_CONTROL
  • PxVehicleGraph::eCHANNEL_BRAKE_CONTROL -> PxVehicleDriveGraphChannel::eBRAKE_CONTROL
  • PxVehicleGraph::eCHANNEL_HANDBRAKE_CONTROL -> PxVehicleDriveGraphChannel::eHANDBRAKE_CONTROL
  • PxVehicleGraph::eCHANNEL_STEER_LEFT_CONTROL -> PxVehicleDriveGraphChannel::eSTEER_LEFT_CONTROL
  • PxVehicleGraph::eCHANNEL_STEER_RIGHT_CONTROL -> PxVehicleDriveGraphChannel::eSTEER_RIGHT_CONTROL
  • PxVehicleGraph::eCHANNEL_GEAR_RATIO -> PxVehicleDriveGraphChannel::eGEAR_RATIO
  • PxVehicleGraph::eMAX_NUM_ENGINE_CHANNELS -> PxVehicleDriveGraphChannel::eMAX_NB_DRIVE_CHANNELS

• A new struct has been introduced to hold the enumerated list that began with PxVehicleGraph::eGRAPH_TYPE_WHEEL. The changes are

  • PxVehicleGraph::eGRAPH_TYPE_WHEEL -> PxVehicleGraphType::eWHEEL
  • PxVehicleGraph::eGRAPH_TYPE_ENGINE -> PxVehicleGraphType::eDRIVE

• Non-persistent data is no longer stored in the vehicle. Instead of storing this data in each vehicle it is stored in an array and passed to PxVehicleUpdates as an extra function argument. A simple example of how to construct, use, and read this data is given below. This example code updates an array of vehicles and tests if they are in the air. If the vehicles are not in the air then the actor under each wheel is recorded and stored in an array:

  void updateVehicles(const PxF32 timestep, const PxVec3& gravity,
      const PxVehicleDrivableSurfaceToTireFrictionPairs& fricPairs,
      PxVehicleWheels** vehicles, PxU32 numVehicles, std::vector<PxActor*>& hitActors)
  {
      //Count the total number of wheels.
      unsigned int numWheels = 0;
      for(unsigned int i = 0; i < numVehicles; i++)
      {
          numWheels += vehicles[i]->mWheelsSimData.getNbWheels();
      }
  
      //Allocate buffers to store results for each vehicle and each wheel.
      PxVehicleWheelQueryResult* vehicleWheelQueryResults =
          new PxVehicleWheelQueryResult[numVehicles];
      PxWheelQueryResult* wheelQueryResults = new PxWheelQueryResult[numWheels];
      PxU32 wheelCount = 0;
      for(PxU32 i = 0; i < numVehicles; i++)
      {
          vehicleWheelQueryResults[i].nbWheelQueryResults =
              vehicles[i]->mWheelsSimData.getNbWheels();
          vehicleWheelQueryResults[i].wheelQueryResults = &wheelQueryResults[wheelCount];
          wheelCount +=  vehicles[i]->mWheelsSimData.getNbWheels();
      }
  
      //Update the array of vehicles.
      PxVehicleUpdates(timestep, gravity, fricPairs, numVehicles, vehicles,
          vehicleWheelQueryResults);
  
      //Test if each vehicle is in the air.
      for(PxU32 i = 0; i < numVehicles; i++)
      {
          if(!PxVehicleIsInAir(vehicleWheelQueryResults[i]))
          {
              for(PxU32 j = 0; j < vehicleWheelQueryResults[i].nbWheelQueryResults; j++)
              {
                  if(vehicleWheelQueryResults[i].wheelQueryResults[j].tireContactActor)
                  {
                      hitActors.push_back
                          (vehicleWheelQueryResults[i].wheelQueryResults[j].tireContactActor);
                  }
              }
          }
      }
  
      delete[] vehicleWheelQueryResults;
      delete[] wheelQueryResults;
  }
  

• The following accessors to non-persistent data associated with each wheel have been replaced as follows

  • PxVehicleWheelsDynData::getSuspLineStart -> PxWheelQueryResult::suspLineStart
  • PxVehicleWheelsDynData::getSuspLineDir -> PxWheelQueryResult::suspLineDir
  • PxVehicleWheels::getSuspRaycast -> PxWheelQueryResult::suspLineStart, PxWheelQueryResult::suspLineDir, PxWheelQueryResult::suspLineLength
  • PxVehicleWheelsDynData::getTireDrivableSurfaceShape -> PxWheelQueryResult::tireContactShape
  • PxVehicleWheelsDynData::getTireDrivableSurfaceMaterial -> PxWheelQueryResult::tireSurfaceMaterial
  • PxVehicleWheelsDynData::getTireDrivableSurfaceType -> PxWheelQueryResult::tireSurfaceType
  • PxVehicleWheelsDynData::getTireDrivableSurfaceContactPoint -> PxWheelQueryResult::tireContactPoint
  • PxVehicleWheelsDynData::getTireDrivableSurfaceContactNormal -> PxWheelQueryResult::tireContactNormal
  • PxVehicleWheelsDynData::getTireFriction -> PxWheelQueryResult::tireFriction
  • PxVehicleWheelsDynData::getSuspJounce -> PxWheelQueryResult::suspJounce
  • PxVehicleWheelsDynData::getSuspensionForce -> PxWheelQueryResult::suspSpringForce
  • PxVehicleWheelsDynData::getTireLongitudinalDir -> PxWheelQueryResult::tireLongitudinalDir
  • PxVehicleWheelsDynData::getTireLateralDir -> PxWheelQueryResult::tireLateralDir
  • PxVehicleWheelsDynData::getTireLongSlip -> PxWheelQueryResult::longitudinalSlip
  • PxVehicleWheelsDynData::getTireLatSlip ->PxWheelQueryResult::lateralSlip
  • PxVehicleWheelsDynData::getSteer -> PxWheelQueryResult::steerAngle
  • PxVehicleWheels::isInAir -> PxWheelQueryResult::isInAir

• PxVehicleWheels::setWheelShapeMapping and PxVehicleWheels::getWheelShapeMapping have been moved to PxVehicleWheelsSimData::setWheelShapeMapping and PxVehicleWheelsSimData::getWheelShapeMapping

• PxVehicleWheels::setSceneQueryFilterData and PxVehicleWheels::getSceneQueryFilterData have been moved to PxVehicleWheelsSimData::setSceneQueryFilterData and PxVehicleWheelsSimData::getSceneQueryFilterData

• PxVehicle4WEnable3WTadpoleMode and PxVehicle4WEnable3WDeltaMode now take an extra function argument: a non-const reference to a PxVehicleWheelsDynData

• PxVehicleWheels::isInAir() has been replaced with PxVehicleIsInAir(const PxVehicleWheelQueryResult& vehWheelQueryResults)

• PxVehicleDrive4WSmoothAnalogRawInputsAndSetAnalogInputs now takes an extra function argument "const bool isVehicleInAir". This can be calculated using the function PxVehicleIsInAir

• To improve api consistency PxVehicleTelemetryData::getNumWheelGraphs is now PxVehicleTelemetryData::getNbWheelGraphs

• To improve api consistency PX_MAX_NUM_WHEELS is now PX_MAX_NB_WHEELS

• To improve api consistency PxVehicleGraph::eMAX_NUM_TITLE_CHARS is now PxVehicleGraph::eMAX_NB_TITLE_CHARS

• PxVehicleTireData::mCamberStiffness has been replaced with PxVehicleTireData::mCamberStiffnessPerUnitGravity. PxVehicleTireData::mCamberStiffnessPerUnitGravity should be set so that it is equivalent to the old value of PxVehicleTireData::mCamberStiffness divided by the magnitude of gravitational acceleration (PxScene::getGravity().magnitude()). The advantage of using PxVehicleTireData::mCamberStiffnessPerUnitGravity is that it independent of length scale.

• PxVehicleComputeTireForceDefault has been removed from the public vehicle api. Custom tire shaders that call PxVehicleComputeTireForceDefault are best implemented by taking a copy of PxVehicleComputeTireForceDefault and calling the copy instead.

CCD

• The mechanism to activate CCD per shape has changed in 3.3. The PxShapeFlag::eUSE_SWEPT_BOUNDS that was used in 3.2 to active swept bounds per shape has been removed. In its place is a new flag PxRigidBodyFlag::eENABLE_CCD that is set per rigid actor. Setting this flag for an actor in 3.3 has approximately the same effect as setting PxShapeFlag::eUSE_SWEPT_BOUNDS on all the actor's shapes in 3.2.

• PxPairFlag::eSWEPT_INTEGRATION_LINEAR has been replaced with PxPairFlag::eCCD_LINEAR in PhysX 3.3.

• PxSceneFlag::eENABLE_SWEPT_INTEGRATION flag in 3.2 has been replaced with PxSceneFlag::eENABLE_CCD in PhysX 3.3.

• A simple example of how to enable CCD on a specific shape is given below. This demonstrates creating a body consisting of a large box and a smaller sphere, where the box is only used in discrete collision detection and the sphere is only used in CCD. The simulation filter shader shown here requires that the filter data of both shapes be flagged with eCCD_RESPONSE to generate a CCD response (PxPairFlag::eCCD_LINEAR). Likewise, the filter shader shown here is configured so that the filter data of both shapes need to be flagged with eDISCRETE_RESPONSE in order to generate a collision response (PxPairFlag::eRESOLVE_CONTACTS). A final remark is that the following shader requires that shapes of static actors have filter data with flags eDISCRETE_RESPONSE | eCCD_RESPONSE in order to ensure ccd and collision response from pairs that involve a static actor and a CCD-enabled dynamic actor:

  struct CCDFilterTest
  {
      enum FilterFlags
      {
          eDISCRETE_RESPONSE    = 1 << 0
          eCCD_RESPONSE        = 1 << 1
      };
      static PxFilterFlags filterShader(
          PxFilterObjectAttributes attributes0,
          PxFilterData filterData0,
          PxFilterObjectAttributes attributes1,
          PxFilterData filterData1,
          PxPairFlags& pairFlags,
          const void* constantBlock,
          PxU32 constantBlockSize)
      {
          pairFlags = PxPairFlags(0);
  
          PxU32 combo = filterData0.word0 & filterData1.word0;
          if(combo & eDISCRETE_RESPONSE)
          {
              pairFlags |= PxPairFlag::eRESOLVE_CONTACTS;
          }
          if(combo & eCCD_RESPONSE)
          {
              pairFlags |= PxPairFlag::eCCD_LINEAR;
          }
          return PxFilterFlags();
      }
  };
  
  ....
  
  PxRigidDynamic* dyn = getPhysics().createRigidDynamic(PxTransform(PxVec3(-4, -3.5, 0)));
  PxBoxGeometry box;
  box.halfExtents = PxVec3(1.f, 1.f, 1.f);
  PxSphereGeometry sphere;
  sphere.radius = 0.75f;
  PxShape* boxShape = dyn->createShape(box, getDefaultMaterial());
  PxShape* sphereShape = dyn->createShape(sphere, getDefaultMaterial());
  
  PxFilterData data = boxShape->getSimulationFilterData();
  data.word0 |= CCDFilterTest::eDISCRETE_RESPONSE;
  boxShape->setSimulationFilterData(data);
  
  data = sphereShape->getSimulationFilterData();
  data.word0 |= CCDFilterTest::eCCD_RESPONSE;
  sphereShape->setSimulationFilterData(data);
  
  dyn->setRigidBodyFlag(PxRigidBodyFlag::eENABLE_CCD, true);
  getActiveScene().addActor(*dyn);
  

PhysX Visual Debugger

• A new flag has been introduced to configure the visualizing of constraints:

  PxVisualDebuggerFlag::eTRANSMIT_CONSTRAINTS;

• A new function has been introduced to configure PxVisualDebugger flags:

  PxVisualDebugger::setVisualDebuggerFlags( PxVisualDebuggerFlags flags);

• A new funtion has been introduced to send error stream to PVD:

  PxVisualDebugger::sendErrorMessage((PxErrorCode::Enum code, const char* message, const char* file, PxU32 line);

• The following functions were renamed:

  PxVisualDebugger::getPvdConnectionFactory() -> PxVisualDebugger::getPvdConnection(); PxVisualDebugger::getPvdConnection() -> PxVisualDebugger::getPvdDataStream();

• The PVD connect function changed to the same method as previously 3.2 version:

  PxVisualDebuggerExt::connect -> PxVisualDebuggerExt::createConnection;

• The constraint, contacts and scene queries visualizing can all be configed with PxVisualDebuggerFlag in 3.3. Here is an example for how to enable pvd visualizing the contacts :

  mPhysics->getVisualDebugger()->setVisualDebuggerFlags(PxVisualDebuggerFlag::eTRANSMIT_CONTACTS | PxVisualDebuggerFlag::eTRANSMIT_CONSTRAINTS);

PhysX Cloth

There have been substantial changes to the PhysX 3.3 cloth solver that improve performance and behavior. This has resulted in a reorganization of how constraints are stored and processed in the cloth fabric. Prior to PhysX 3.3 the cloth solver used fibers to organize edge constraints into independent groups. In PhysX 3.3 it is no longer necessary to decompose constraints into fibers, instead edge constraints now exist individually and are solved in larger, independent sets. Interface changes are detailed below:

• Previously there were multiple solver types to choose from for each group of constraints such as eFAST, eSTIFF, eBENDING, etc (previously PxClothPhaseSolverConfig::SolverType). There is now one type of solver for all edge constraints, this is a flexible distance constraint with controls to adjust stiffness within certain ranges of compression and stretch (see PxClothStretchConfig). Behaviors such as bending are now achieved by the way distance constraints are arranged geometrically, rather than through a specialized bending solver.

• To reduce stretching a new constraint type has been added called "tether" constraints. These constraints do not act along edges of the mesh, but act as long range attachments between particles that enforce a maximum distance between two points. See PxClothFabric::getTetherAnchors().

• Cloth cooking which was previously part of the PxCooking library has been moved to the extension library, see PxClothFabricCooker:

  // PhysX 3.2.x
  cooking->cookClothFabric(meshDesc, gravity, outputStream);
  
  // PhysX 3.3
  PxClothFabricCooker cooker(meshDesc, gravity, useGeodesicTethers);
  cooker.save(outputStream, false);
  

• The PxClothCollisionData parameter has been removed from PxPhysx::createCloth(). The collision shapes can now be added after cloth creation using PxCloth::addCollisionSphere and PxCloth::addCollisionCapsule.

• PxCloth::wakeUp() does not have a parameter anymore. Use the newly introduced method setWakeCounter() instead to set a specific value.

• PxCloth::setDampingCoefficient now takes a PxVec3 instead of a PxReal to specify the damping per axis.

• PxCloth::setPhaseSolverConfig() has been renamed to PxCloth::setStretchConfig()

• PxCloth::lockClothReadData() has been renamed to PxCloth::lockParticleData()

• PxClothFabricTypes.h has been removed, this header has been merged with PxClothFabric.h

RepX Serialization

Substantial changes were made to the PhysX 3.3 serialization interface. Handling of collections and references between collections have been unified for RepX and binary serialization.

• The RepX and RepXUpgrader libraries have been removed. RepX functionality is now provided through PhysXExtensions.

• RepXCollection has been replaced with PxCollection, which is the common collection class for both RepX and binary serialization in 3.3. Collections are now instantiated on deserialization with PxSerialization::createCollectionFromXml(). Empty collections can be created with PxCreateCollection(). Serialization into RepX format is achieved through PxSerialization::serializeCollectionToXml().

• TRepXId has been replaced with PxSerialObjectId.

• RepXIdToRepXObjectMap and RepXObject have been replaced with new functionality in PxCollection, which now maps between serializable objects and PxSerialObjectId values.

• RepXExtension was removed. Serialization and deserialization of serializable types is achieved through the PxRepXSerializer interface.

• RepXUtility and PxToolkit functionality has been replaced with various functions in PxSerialization, PxCollection and PxScene.

  • A PxCollection with all PxPhysics-level objects such as shapes, meshes or materials (formally referred to as buffers) can be created using PxCollectionExt::createCollection(PxPhysics&).
  • Similarly PxCollectionExt::createCollection(PxScene&) can be used to create a collection of PxScene-level objects.
  • Dependencies between objects and collections can be handled with PxSerialization::complete().
  • The objects of a collection can be added to a scene with PxScene::addCollection().
  • Operations on files are generally handled with abstract interfaces: PxOutputStream and PxInputData. Default implementations are available as PxDefaultFileOutputStream and PxDefaultFileInputData.

• RepXUpgrader::upgradeCollection was removed. RepX data can be converted to newer PhysX versions by deserializing and re-serializing a collection: PxSerialization::createCollectionFromXml(), PxSerialization::serializeCollectionToXml().

• Serialization functionality requires a PxSerializationRegistry instance which can be created with PxSerialization::createSerializationRegistry().

• XML serialization can be configured to store the cooked triangle and convex mesh data along with the plain data for faster loading.

• PhysXVehicles supports RepX serialization. PxSerializationRegistry needs to be provided to PxInitVehicleSDK() for vehicle serialization, PxCloseVehicleSDK() for cleanup.

• Custom class RepX serialization is supported in 3.3, more information please read Serialization.

Binary Serialization

The binary serialization interface has been refactored and unified with the RepX serialization interface.

• Most serialization functionality requires an instance of the new class PxSerializationRegistry. It is application managed and can be created with PxSerialization::createSerializationRegistry() and released with PxSerializationRegistry::release().

• The base class for serializable types has been renamed from PxSerializable to PxBase. Most of the serialization functionality moved to a separate PxSerializer class. A PxSerializer instance per serializable type is registered in the PxSerializationRegistry. All PhysX and PhysXExtension serializables are registered by default.

• PxCollection has been reworked.

  • PxCollection::serialize() and PxCollection::deserialize() were replaced with PxSerialization::createCollectionFromBinary() PxSerialization::serializeCollectionToBinary() in PhysXExtensions.
  • PxSerializable::collectForExport() has been replaced with PxCollection::add(). PxSerialzation::complete() helps to add required objects for resolving dependencies. PxSerializable::isSerializable() should be used check whether a collection can be successfully serialized.

• PxUserReferences was removed: PxCollection instances can now be used directly to resolve dependencies between collections on deserialization. PxSerialization::complete() supports creating collections with external dependencies to other collections.

• PxSerialObjectRef has been replaced with PxSerialObjectId.

• PxCollectForExportSDK() and PxCollectForExportScene() functions were replaced with PxCollectionExt::createCollection(PxPhysics& physics) and PxCollectionExt::createCollection(PxScene& scene).

• PxDumpMetaData() was replaced with PxSerialization::dumpBinaryMetaData().

• The PxBinaryConverter moved from PhysXCooking to PhysXExtensions. PxCooking::createBinaryConverter() was replaced with PxSerialization::createBinaryConverter().

• PhysXVehicles supports binary serialization. PxSerializationRegistry needs to be provided to PxInitVehicleSDK() for vehicle serialization, PxCloseVehicleSDK() for cleanup.

• Custom class binary serialization is supported in 3.3, more information please read Serialization.

PhysX TaskManager

• The pxtask namespace has been removed and all its types are now included in the physx namespace with a Px prefix, for example pxtask::LightCpuTask has become physx::PxLightCpuTask