PhysX 3.4, APEX 1.4 patch release @25354359v3.4.2-bsd

6 files changed, 6 insertions, 6 deletions

diff --git a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/ExtendingSerialization.txt b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/ExtendingSerialization.txt
index bd8f5791..58735ad9 100644
--- a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/ExtendingSerialization.txt
+++ b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/ExtendingSerialization.txt
@@ -30,7 +30,7 @@ Serialization and deserialization of a custom class can be achieved with the fol
 
 1. Define a *PxConcreteType* and type info for the custom class. Make sure its type value is unique.
 
-2. The custom class needs to inherit from *PxBase* and implement it's interface.
+2. The custom class needs to inherit from *PxBase* and implement its interface.
 
 3. Instance PxSerializerDefaultAdapter<T> and implement specialized methods where necessary.
 
diff --git a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Geometry.txt b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Geometry.txt
index dd5b5fce..ac370c3f 100644
--- a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Geometry.txt
+++ b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Geometry.txt
@@ -701,7 +701,7 @@ Then tessellate the field from the samples as required.
 Heightfield Modification
 +++++++++++++++++++++++++++++++
 
-Heightfield samples can be modified at runtime in rectangular blocks. In the following code snippet we create a HF and modify it's samples::
+Heightfield samples can be modified at runtime in rectangular blocks. In the following code snippet we create a HF and modify its samples::
 
     // create a 5x5 HF with height 100 and materials 2,3
     PxHeightFieldSample samples1[25];
diff --git a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/MigrationTo33.txt b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/MigrationTo33.txt
index 523e6be8..a34b44ee 100644
--- a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/MigrationTo33.txt
+++ b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/MigrationTo33.txt
@@ -742,4 +742,4 @@ The binary serialization interface has been refactored and unified with the RepX
 PhysX TaskManager
 ========================================================
 
-* The pxtask namespace has been removed and all it's types are now included in the physx namespace with a Px prefix, for example pxtask::LightCpuTask has become physx::PxLightCpuTask
+* 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
diff --git a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Particles.txt b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Particles.txt
index 653a76b3..a161b17c 100644
--- a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Particles.txt
+++ b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Particles.txt
@@ -61,7 +61,7 @@ The following section shows how a particle system is created and added::
 Particle Management
 ====================================================
 
-Particle systems reserve memory for a fixed number of particles - *PxParticleBase::getMaxParticles*.  Each of these particles can be addressed with a fixed index throughout it's lifetime.  The given range of indices is [0, *PxParticleBase::getMaxParticles*].  In order to support a dynamic amount of particles, particles are marked as being valid or invalid.  This is achieved by two means:  The valid particle range indicates the range within which particles may be valid.  Outside that range all particles are defined as being invalid.  Within that range valid particles are marked with the flag *PxParticleFlag::eVALID*.  Alternatively PhysX provides a bitmap with each bit set corresponding to a valid particle within the valid particle range. The bitmap consists of an array of 32-bit unsigned integers with enough elements to cover the valid particle range.
+Particle systems reserve memory for a fixed number of particles - *PxParticleBase::getMaxParticles*.  Each of these particles can be addressed with a fixed index throughout its lifetime.  The given range of indices is [0, *PxParticleBase::getMaxParticles*].  In order to support a dynamic amount of particles, particles are marked as being valid or invalid.  This is achieved by two means:  The valid particle range indicates the range within which particles may be valid.  Outside that range all particles are defined as being invalid.  Within that range valid particles are marked with the flag *PxParticleFlag::eVALID*.  Alternatively PhysX provides a bitmap with each bit set corresponding to a valid particle within the valid particle range. The bitmap consists of an array of 32-bit unsigned integers with enough elements to cover the valid particle range.
 
 .. figure:: ../images/ParticleValidScheme.png
    :scale: 100
diff --git a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/SpatialQueries.txt b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/SpatialQueries.txt
index 08376275..ae3da640 100644
--- a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/SpatialQueries.txt
+++ b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/SpatialQueries.txt
@@ -44,7 +44,7 @@ For example, in SnippetSpatialIndex::
                                              1e6, PxHitFlag::eDEFAULT,
                                              1, &hitData);
 
-        // if the raycast hit and it's closer than what we had before, shrink the maximum length
+        // if the raycast hits and is closer than what we had before, shrink the maximum length
         // of the raycast
 
         if(hit && hitData.distance < closest)
diff --git a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Vehicles.txt b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Vehicles.txt
index 1df3405e..3e9361b4 100644
--- a/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Vehicles.txt
+++ b/PhysX_3.4/Documentation/PhysXGuide/_sources/Manual/Vehicles.txt
@@ -1069,7 +1069,7 @@ PhysX tanks currently support two drive models: eSTANDARD and eSPECIAL.  The dri
 PxVehicleNoDrive
 ++++++++++++++++++++++++++++++++++++++++++++++++++
 
-The class PxVehicleNoDrive has been introduced to provide a close approximation to backwards compatibility with the interface to the 2.8.x NxWheelShape class.  It is essentially a rigid body with N suspension/wheel/tire units attached.  It's behavior is identical to that of a PxVehicleDrive4W which is permanently in neutral gear so that the engine has no influence on the wheels and the wheels are coupled only through the motion of the rigid body.  This comes, of course, without the storage overhead of Ackermann steering correction data, engine torque curve data etc.  The idea is that users can develop their own drive model on top of already existing vehicle code to manage the suspension raycasts, tire and suspension force computation, and PhysX SDK integration.
+The class PxVehicleNoDrive has been introduced to provide a close approximation to backwards compatibility with the interface to the 2.8.x NxWheelShape class.  It is essentially a rigid body with N suspension/wheel/tire units attached.  Its behavior is identical to that of a PxVehicleDrive4W which is permanently in neutral gear so that the engine has no influence on the wheels and the wheels are coupled only through the motion of the rigid body.  This comes, of course, without the storage overhead of Ackermann steering correction data, engine torque curve data etc.  The idea is that users can develop their own drive model on top of already existing vehicle code to manage the suspension raycasts, tire and suspension force computation, and PhysX SDK integration.
 
 The key functions are the application of per wheel drive and brake torques and per wheel steer angles::