| characterkinematic |
|
|
- |
| collision |
|
|
- |
| common |
|
|
- |
| cooking |
|
|
- |
| cudamanager |
|
|
- |
| extensions |
|
|
- |
| foundation |
|
|
- |
| geometry |
|
|
- |
| geomutils |
|
|
- |
| gpu |
|
|
- |
| omnipvd |
|
|
- |
| pvd |
|
|
- |
| PxActor.h |
\brief Group index which allows to specify 1- or 2-way interaction
|
9116 |
- |
| PxAggregate.h |
\brief Class to aggregate actors into a single broad-phase entry.
A PxAggregate object is a collection of PxActors, which will exist as a single entry in the
broad-phase structures. This has 3 main benefits:
1) it reduces "broad phase pollution" by allowing a collection of spatially coherent broad-phase
entries to be replaced by a single aggregated entry (e.g. a ragdoll or a single actor with a
large number of attached shapes).
2) it reduces broad-phase memory usage
3) filtering can be optimized a lot if self-collisions within an aggregate are not needed. For
example if you don't need collisions between ragdoll bones, it's faster to simply disable
filtering once and for all, for the aggregate containing the ragdoll, rather than filtering
out each bone-bone collision in the filter shader.
\see PxActor, PxPhysics.createAggregate
|
9226 |
- |
| PxAnisotropy.h |
\brief Computes anisotropy information for a particle system to improve rendering quality
|
6694 |
- |
| PxArrayConverter.h |
\brief Utility class to convert gpu arrays to a different memory layout
|
1469 |
- |
| PxArticulationFlag.h |
\brief These flags determine what data is read or written to the internal articulation data via cache.
\see PxArticulationCache PxArticulationReducedCoordinate::copyInternalStateToCache PxArticulationReducedCoordinate::applyCache
|
2557 |
- |
| PxArticulationJointReducedCoordinate.h |
\brief A joint between two links in an articulation.
\see PxArticulationReducedCoordinate, PxArticulationLink
|
21047 |
- |
| PxArticulationLink.h |
\brief A component of an articulation that represents a rigid body.
Articulation links have a restricted subset of the functionality of a PxRigidDynamic:
- They may not be kinematic, and do not support contact-force thresholds.
- Their velocity or global pose cannot be set directly, but must be set via the articulation-root and joint positions/velocities.
- Sleep state and solver iteration counts are properties of the entire articulation rather than the individual links.
\see PxArticulationReducedCoordinate, PxArticulationReducedCoordinate::createLink, PxArticulationJointReducedCoordinate, PxRigidBody
|
6664 |
- |
| PxArticulationMimicJoint.h |
\brief A mimic joint enforces a linear relationship between the positions of two joints of the same articulation instance.
\see PxArticulationReducedCoodinate::createMimicJoint()
|
4490 |
- |
| PxArticulationReducedCoordinate.h |
\brief Data structure to represent spatial forces.
|
66950 |
- |
| PxArticulationTendon.h |
\brief Defines the low/high limits of the length of a tendon.
|
22850 |
- |
| PxArticulationTendonData.h |
\brief PxGpuSpatialTendonData
This data structure is to be used by the direct GPU API for spatial tendon data updates.
\see PxArticulationSpatialTendon PxDirectGPUAPI::getArticulationData PxDirectGPUAPI::setArticulationData
|
2215 |
- |
| PxBaseMaterial.h |
\brief Base material class.
\see PxPhysics.createMaterial PxPhysics.createDeformableSurfaceMaterial PxPhysics.createDeformableVolumeMaterial PxPhysics.createPBDMaterial
|
1195 |
- |
| PxBroadPhase.h |
\brief Broad phase algorithm used in the simulation
eSAP is a good generic choice with great performance when many objects are sleeping. Performance
can degrade significantly though, when all objects are moving, or when large numbers of objects
are added to or removed from the broad phase. This algorithm does not need world bounds to be
defined in order to work.
eMBP is an alternative broad phase algorithm that does not suffer from the same performance
issues as eSAP when all objects are moving or when inserting large numbers of objects. However
its generic performance when many objects are sleeping might be inferior to eSAP, and it requires
users to define world bounds in order to work.
eABP is a revisited implementation of MBP, which automatically manages broad-phase regions.
It offers the convenience of eSAP (no need to define world bounds or regions) and the performance
of eMBP when a lot of objects are moving. While eSAP can remain faster when most objects are
sleeping and eMBP can remain faster when it uses a large number of properly-defined regions,
eABP often gives the best performance on average and the best memory usage.
ePABP is a parallel implementation of ABP. It can often be the fastest (CPU) broadphase, but it
can use more memory than ABP.
eGPU is a GPU implementation of the incremental sweep and prune approach. Additionally, it uses a ABP-style
initial pair generation approach to avoid large spikes when inserting shapes. It not only has the advantage
of traditional SAP approch which is good for when many objects are sleeping, but due to being fully parallel,
it also is great when lots of shapes are moving or for runtime pair insertion and removal. It can become a
performance bottleneck if there are a very large number of shapes roughly projecting to the same values
on a given axis. If the scene has a very large number of shapes in an actor, e.g. a humanoid, it is recommended
to use an aggregate to represent multi-shape or multi-body actors to minimize stress placed on the broad phase.
|
29176 |
- |
| PxClient.h |
\brief An ID to identify different clients for multiclient support.
\see PxScene::createClient()
|
723 |
- |
| PxConstraint.h |
\brief constraint flags
\note eBROKEN is a read only flag
|
8328 |
- |
| PxConstraintDesc.h |
\brief Constraint row flags
These flags configure the post-processing of constraint rows and the behavior of the solver while solving constraints
|
19955 |
- |
| PxContact.h |
\brief Header for a contact patch where all points share same material and normal
|
20151 |
- |
| PxContactModifyCallback.h |
\brief An array of contact points, as passed to contact modification.
The word 'set' in the name does not imply that duplicates are filtered in any
way. This initial set of contacts does potentially get reduced to a smaller
set before being passed to the solver.
You can use the accessors to read and write contact properties. The number of
contacts is immutable, other than being able to disable contacts using ignore().
\see PxContactModifyCallback, PxModifiableContact
|
17433 |
- |
| PxDeformableAttachment.h |
\brief Identifies the attachment target type for an actor involved in an attachment.
The target type provides actor related information about what kind of attachment should be created.
\see PxDeformableAttachmentData
|
7360 |
- |
| PxDeformableBody.h |
\brief Represents a deformable body, a base class for deformable actors
\see PxDeformableSurface, PxDeformableVolume, PxActor
|
11589 |
- |
| PxDeformableBodyFlag.h |
\brief Flags to enable or disable special modes of a PxDeformableBody instance
|
1090 |
- |
| PxDeformableElementFilter.h |
\addtogroup physics
@{
|
5550 |
- |
| PxDeformableMaterial.h |
\brief Material class to represent a set of deformable material properties.
\see PxPhysics.createDeformableVolumeMaterial
|
2736 |
- |
| PxDeformableSkinning.h |
\brief Structure for triangle mesh skinning embedding information.
|
6207 |
- |
| PxDeformableSurface.h |
\brief The maximum number of triangles supported in a surface deformable mesh
The current limit is 1'048'575.
|
9863 |
- |
| PxDeformableSurfaceFlag.h |
\brief Identifies input and output buffers for PxDeformableSurface.
|
1297 |
- |
| PxDeformableSurfaceMaterial.h |
\brief Material class to represent surface deformable material properties.
\see PxPhysics.createDeformableSurfaceMaterial
|
2468 |
- |
| PxDeformableVolume.h |
\brief The maximum number of tetrahedrons supported in a deformable volume tetrahedron mesh
The current limit is 1'048'575.
|
16970 |
- |
| PxDeformableVolumeFlag.h |
\brief Flags to enable or disable special modes of a PxDeformableVolume instance
|
1759 |
- |
| PxDeformableVolumeMaterial.h |
\brief Material class to represent a set of deformable volume material properties.
\see PxPhysics.createDeformableVolumeMaterial
|
2053 |
- |
| PxDeletionListener.h |
\brief Flags specifying deletion event types.
\see PxDeletionListener::onRelease PxPhysics.registerDeletionListener()
|
2769 |
- |
| PxDirectGPUAPI.h |
\brief This flag specifies the type of data to get when calling PxDirectGPUAPI::getRigidDynamicData().
|
36075 |
- |
| PxFiltering.h |
\brief Collection of flags describing the actions to take for a collision pair.
\see PxPairFlags PxSimulationFilterShader.filter() PxSimulationFilterCallback
|
27855 |
- |
| PxImmediateMode.h |
\brief Structure to store linear and angular components of spatial vector
|
39401 |
- |
| PxIsosurfaceExtraction.h |
\brief Identifies filter type to be applied on the isosurface grid.
|
11782 |
- |
| PxMaterial.h |
\brief Flags which control the behavior of a material.
\see PxMaterial
|
11668 |
- |
| PxNodeIndex.h |
\brief PxNodeIndex
Node index is the unique index for each actor referenced by the island gen. It contains details like
if the actor is an articulation or rigid body. If it is an articulation, the node index also contains
the link index of the rigid body within the articulation. Also, it contains information to detect whether
the rigid body is static body or not
|
2804 |
- |
| PxParticleBuffer.h |
\brief The shared base class for all particle buffers, can be instantiated directly to simulate granular and fluid particles.
See #PxPhysics::createParticleBuffer.
A particle buffer is a container that specifies per-particle attributes of a set of particles that will be used during the simulation
of a particle system. It exposes direct access to the underlying GPU buffers and is independent of the scene and particle system. Particle
buffers can be added/removed from a particle system at any time between simulation steps, and transferred from one particle system to another.
|
8423 |
- |
| PxParticleGpu.h |
\brief Common material properties for particles. See #PxPBDMaterial.
Accessed by either integration or particle-rigid collisions
|
6916 |
- |
| PxParticleMaterial.h |
\deprecated This typedef only serves for deprecation and will be removed in a future version.
|
639 |
- |
| PxParticleNeighborhoodProvider.h |
\brief Computes neighborhood information for a point cloud
|
2918 |
- |
| PxParticleSystem.h |
\deprecated This typedef only serves for deprecation and will be removed in a future version.
|
645 |
- |
| PxParticleSystemFlag.h |
\brief Identifies dirty particle buffers that need to be updated in the particle system.
This flag can be used mark the device user buffers that are dirty and need to be written to the particle system.
|
2568 |
- |
| PxPBDMaterial.h |
\brief Material class to represent a set of PBD particle material properties.
\see #PxPhysics.createPBDMaterial
|
7702 |
- |
| PxPBDParticleSystem.h |
\brief Container to hold a pair of corresponding device and host pointers. These pointers should point to GPU / CPU mirrors of the same data, but
this is not enforced.
|
19019 |
- |
| PxPhysics.h |
\brief Abstract singleton factory class used for instancing objects in the Physics SDK.
In addition you can use PxPhysics to set global parameters which will effect all scenes and create
objects that can be shared across multiple scenes.
You can get an instance of this class by calling PxCreatePhysics().
\see PxCreatePhysics() PxScene
|
38257 |
- |
| PxPhysicsAPI.h |
This is the main include header for the Physics SDK, for users who
want to use a single #include file.
Alternatively, one can instead directly #include a subset of the below files.
|
6230 |
- |
| PxPhysicsSerialization.h |
\brief Registers physics classes for serialization.
This function is used to implement PxSerialization.createSerializationRegistry() and is not intended to be needed otherwise.
\see PxSerializationRegistry
|
1748 |
- |
| PxPhysXConfig.h |
Configuration include file for PhysX SDK |
432 |
- |
| PxPruningStructure.h |
\brief A precomputed pruning structure to accelerate scene queries against newly added actors.
The pruning structure can be provided to #PxScene:: addActors() in which case it will get merged
directly into the scene query optimization AABB tree, thus leading to improved performance when
doing queries against the newly added actors. This applies to both static and dynamic actors.
\note PxPruningStructure objects can be added to a collection and get serialized.
\note Adding a PxPruningStructure object to a collection will also add the actors that were used to build the pruning structure.
\note PxPruningStructure must be released before its rigid actors.
\note PxRigidBody objects can be in one PxPruningStructure only.
\note Changing the bounds of PxRigidBody objects assigned to a pruning structure that has not been added to a scene yet will
invalidate the pruning structure. Same happens if shape scene query flags change or shape gets removed from an actor.
\see PxScene::addActors PxCollection
|
3666 |
- |
| PxQueryFiltering.h |
\brief Filtering flags for scene queries.
\see PxQueryFilterData.flags
|
8325 |
- |
| PxQueryReport.h |
\brief Combines a shape pointer and the actor the shape belongs to into one memory location.
Serves as a base class for PxQueryHit.
\see PxQueryHit
|
10869 |
- |
| PxRigidActor.h |
\brief PxRigidActor represents a base class shared between dynamic and static rigid bodies in the physics SDK.
PxRigidActor objects specify the geometry of the object by defining a set of attached shapes (see #PxShape).
\see PxActor
|
8474 |
- |
| PxRigidBody.h |
\brief Parameter to addForce() and addTorque() calls, determines the exact operation that is carried out.
\see PxRigidBody.addForce() PxRigidBody.addTorque()
|
32262 |
- |
| PxRigidDynamic.h |
\brief Collection of flags providing a mechanism to lock motion along/around a specific axis.
\see PxRigidDynamic.setRigidDynamicLockFlag(), PxRigidBody.getRigidDynamicLockFlags()
|
17724 |
- |
| PxRigidStatic.h |
\brief PxRigidStatic represents a static rigid body simulation object in the physics SDK.
PxRigidStatic objects are static rigid physics entities. They shall be used to define solid objects which are fixed in the world.
<h3>Creation</h3>
Instances of this class are created by calling #PxPhysics::createRigidStatic() and deleted with #release().
<h3>Visualizations</h3>
\li #PxVisualizationParameter::eACTOR_AXES
\see PxRigidActor PxPhysics.createRigidStatic() release()
|
1481 |
- |
| PxScene.h |
\brief Expresses the dominance relationship of a contact.
For the time being only three settings are permitted:
(1, 1), (0, 1), and (1, 0).
\see getDominanceGroup() PxDominanceGroup PxScene::setDominanceGroupPair()
|
62383 |
- |
| PxSceneDesc.h |
\brief Enum for selecting the friction algorithm used for simulation.
\deprecated Since only the patch friction model is supported now, the friction type option is obsolete.
#PxFrictionType::ePATCH is the default friction logic (Couloumb type friction model). Friction gets computed per contact patch.
Up to two contact points lying in the contact patch area are selected as friction anchors to which friction impulses are applied. If there
are more than two contact points, to select anchors from, the anchors are selected using a heuristic that tries to maximize the distance
between the anchors within the contact patch area. For each contact patch, two perpendicular axes of the contact patch plane are selected.
A 1D-constraint along each of the two axes is used to implement friction at a friction anchor point. Note that the two axes are processed
separately when the PGS solver type is selected. This can lead to asymmetries when transitioning from dynamic to static friction and vice
versa in certain edge cases. The TGS solver type, on the other hand, works with the combined impulse along the two axes and as such avoids
this potential problem, but this is slightly more computationally expensive. Another difference between TGS and PGS is that TGS applies
friction throughout all position and all velocity iterations, while PGS by default applies friction throughout the last 3 position iterations
and all velocity iterations (unless #PxSceneFlag::eENABLE_FRICTION_EVERY_ITERATION is used).
#PxFrictionType::eFRICTION_COUNT is the total number of friction models supported by the SDK.
|
42420 |
- |
| PxSceneLock.h |
\brief RAII wrapper for the PxScene read lock.
Use this class as follows to lock the scene for reading by the current thread
for the duration of the enclosing scope:
PxSceneReadLock lock(sceneRef);
\see PxScene::lockRead(), PxScene::unlockRead(), PxSceneFlag::eREQUIRE_RW_LOCK
|
2101 |
- |
| PxSceneQueryDesc.h |
\brief Pruning structure used to accelerate scene queries.
eNONE uses a simple data structure that consumes less memory than the alternatives,
but generally has slower query performance.
eDYNAMIC_AABB_TREE usually provides the fastest queries. However there is a
constant per-frame management cost associated with this structure. How much work should
be done per frame can be tuned via the #PxSceneQueryDesc::dynamicTreeRebuildRateHint
parameter.
eSTATIC_AABB_TREE is typically used for static objects. It is the same as the
dynamic AABB tree, without the per-frame overhead. This can be a good choice for static
objects, if no static objects are added, moved or removed after the scene has been
created. If there is no such guarantee (e.g. when streaming parts of the world in and out),
then the dynamic version is a better choice even for static objects.
|
11451 |
- |
| PxSceneQuerySystem.h |
\brief Built-in enum for default PxScene pruners
This is passed as a pruner index to various functions in the following APIs.
\see PxSceneQuerySystemBase::forceRebuildDynamicTree PxSceneQuerySystem::preallocate
\see PxSceneQuerySystem::visualize PxSceneQuerySystem::sync PxSceneQuerySystem::prepareSceneQueryBuildStep
|
28999 |
- |
| PxSDFBuilder.h |
\brief Utility class to compute an SDF on the GPU
\note The sign of the SDF (inside vs. outside) is derived from the triangle winding of the input mesh.
Triangles must be wound consistently such that their normals, (v1 - v0).cross(v2 - v0) for a triangle
(v0, v1, v2), point away from the enclosed volume, i.e. counter-clockwise vertex order when seen from
outside. The builder does not analyze or repair the winding; inverted winding produces an inverted SDF.
Cooking through #PxCreateTriangleMesh() or #PxCookTriangleMesh() with a #PxSDFDesc normalizes the winding
of watertight, single-component meshes automatically; clients calling the builder directly must provide
correctly wound triangles.
|
5904 |
- |
| PxShape.h |
\brief Flags which affect the behavior of PxShapes.
\see PxShape PxShape.setFlag()
|
19615 |
- |
| PxSimulationEventCallback.h |
\brief Extra data item types for contact pairs.
\see PxContactPairExtraDataItem.type
|
31006 |
- |
| PxSimulationStatistics.h |
\brief Structure used to retrieve actual sizes/counts for the configuration parameters provided in PxGpuDynamicsMemoryConfig.
\note All the values in this structure are reported as the maximum over the lifetime of a PxScene.
\see PxScene::getSimulationStatistics(), PxSimulationStatistics, PxSceneDesc::PxGpuDynamicsMemoryConfig
|
13289 |
- |
| PxSmoothing.h |
\brief Ccomputes smoothed positions for a particle system to improve rendering quality
|
5090 |
- |
| PxSparseGridParams.h |
\brief Parameters to define the sparse grid settings like grid spacing, maximal number of subgrids etc.
|
2419 |
- |
| PxVisualizationParameter.h |
NOTE: Parameters should NOT be conditionally compiled out. Even if a particular feature is not available.
Otherwise the parameter values get shifted about and the numeric values change per platform. This causes problems
when trying to serialize parameters.
New parameters should also be added to the end of the list for this reason. Also make sure to update
eNUM_VALUES, which should be one higher than the maximum value in the enum.
|
5993 |
- |
| solver |
|
|
- |
| task |
|
|
- |