I realize supporting other build systems isn't something that physx would want to officially do, but I do think some more rigid conventions would make it easier for those that have to do it ourselves for one reason or another.

Integrating PhysX into a our build system required a lot more verbosity than I think really should be necessary. The convention that I typically see in projects that have "include" and "src" directories is that "include" is the sole search path required for dependencies to use said library.

To make PhysX itself build I had to add about 60 search paths just for physx to find other parts of itself. The vast majority of those search paths were under other search paths.

For example I had to not only add physx/include, but also physx/include/common, physx/include/geometry, and so forth. Which means its possible to include the same file with different paths (<PxPvd.h> and <pvd/PxPvd.h>).

There are also internal libraries that require headers that are in other libraries "src" directories, which seems like mixing two conventions. See the PX_COOKING issue below for what I think is an example of the fallout of this.

Another minor issue is there are some platform specific files stashed under "unix" directories and some under "linux", which means I can't just expand a platform name variable to build those files, I need to do some project-specific branching.

And one last thing, without PX_COOKING defined I was getting #error Do not include anymore!. With a message like that it sounds like something that should either just be removed from the repository, or the error just removed. If I had to hazard a guess, its because some other non-cooking library was including physxcooking/src/MeshCleaner.h and to ensure that didn't happen anymore someone made including that file outside cooking fail?

I am performing a raycast on a scene. Regardless of whether my scene is a single-sided model or a two-sided model, the speed of raycast is the same? It is reasonable to say that the higher the number of faces, the greater the complexity and the more time it takes.
In addition, do I need to set one-sided or two-sided when raycast? I looked at the documentation and found that the scene query has no options for " both sides " but the geometry query has.

Thanks. : )

Hi

All public headers are copied over to the install directory except the include/cudamanager directory which means you get compile errors when using PhysX 4 CMAKE 'install' directory.

Happy Christmas :)

Hello everybody, as a roboticist and being used to the urdf format, I really miss the basic shape of a cylinder. Especially for wheels an approximation with e.g. capsules does not make sense as it overly expands the volume and a mesh seems like overkill for this application.

Any intentions of adding cylinders to the set of supported primitive shapes?

Hi everyone,

I'm currently trying to figure out how to get jacobian matrices from a PxArticulationReducedCoordinate. What I try to get is the [6xNdof] matrix J_i for link i, mapping joint velocities to Cartesian velocities of link i. I followed the Documentation and so far I'm doing something like:

    articulation->commonInit();
    PxArticulationCache* cache = articulation->createCache();
    articulation->copyInternalStateToCache(*cache, PxArticulationCache::eALL);
    PxU32 link_idx = mylink->getLinkIndex();
    articulation->computeKinematicJacobian(link_idx, *cache);

With this background I have couple of questions:

• Do I access my matrix with cache->jacobian[link_idx].j[row][col] or cache->jacobian->.j[row][col] ? I'm especially confused here as cache->jacobian is a pointer to an PxKinematicJacobian object which contains the member xReal j[6][6]; //[column][row]. How can both dimensions of the jacobian be hardcoded to 6? One must be the number of Dof right?
• What does the public member cache->jacobian->nbColumns do? It is always zero and I can't find any assignments to it in the physx Code..
• How are the dof of floating bases handled in the jacobians?

I would really appreciate some help here as both documentation from here and the comments in the header PxArticulationReducedCoordinate.h do not really cover how to access/interpret the jacobians..

Hello,

I want to implement a system of vehicle destruction during the simulation. This system would change things like the maximum torque/speed of the engine, the ackermaan geometry, suspensions...

I wonder what is the more suitable way to implement this kind of thing with the PhysX vehicle SDK?

Is it possible to do something like :
void Car::UpdatePhysXData(const PxVehicleWheelsSimData& newSimData, const PxVehicleDriveSimData4W& newDriveSimData) { drive->setup(&PxGetPhysics(), mDynActor, newSimData, newDriveSimData, mNbWheels - 4); }
My other concern about this solution is performance wise, can it have a significant impact on it?
Or should I emulate things like a damaged steer/engine by editing the PxVehicleDrive4WRawInputData I use to update my vehicle? This would be easier to do but would be more limiting.

Thanks by advance,

Siliace

I'm generating PhysX scenes from code via the RepX format, and am looking something along the lines of MuJoCo's XML Reference Documentation but for RepX.

<PhysXCollection version="4.0.0">
	<UpVector>0 0 0</UpVector>
	<Scale>
		<Length>0</Length>
		<Speed>0</Speed>
	</Scale>
	<PxMaterial>
		<Id>2166841953424</Id>
		<DynamicFriction>0.5</DynamicFriction>
		<StaticFriction>0.5</StaticFriction>
		<Restitution>0.0</Restitution>
		<FrictionCombineMode>eAVERAGE</FrictionCombineMode>
		<RestitutionCombineMode>eAVERAGE</RestitutionCombineMode>
	</PxMaterial>
</PhysXCollection>

I've searched the contained documentation - which has been terrific in explaining the overall format and goals of the serialisation format - but haven't yet come across available tags or attributes. I gather that (almost) all of them map directly to the PhysX objects themselves, which has helped. But some things are still a mystery - such as what can be referenced aside from Shapes and Materials, can <Id> be anything other than an integer, what do the top-level tags, like <Scale> mean and what do they do, and what else is there?

The SnippetConvert snippet has an option to generate a few examples, those have helped too; but other than that I'm left with browsing GitHub for examples and how they are used to try and reverse-engineer their purpose.

Any ideas?

Fails to compiles on Ubuntu 18.04 with clang-8

PhysX/physx/../pxshared/include/foundation/unix/PxUnixIntrinsics.h:178:50: error: empty expression statement has no effect; remove unnecessary ';' to silence this
      warning [-Werror,-Wextra-semi-stmt]
        PX_ASSERT(((size_t(dest) + offset) & 0x7f) == 0);

In File "SqIncrementalAABBPrunerCore.cpp"
In line 396, 397

PxBounds3 bounds;
V4StoreU(node->mBVMin, &bounds.minimum.x);
V4StoreU(node->mBVMax, &bounds.maximum.x);

bounds.minimum and maximum only have three float values, but why you can copy four float values to it?

I don't know, Maybe it should use Vec3p
Or I used the wrong Macro to compile this library.

For now, I have to modify the code to avoid crash.

Vec3p minimum, maximum;
V4StoreU(node->mBVMin, &minimum.x);
V4StoreU(node->mBVMax, &maximum.x);

PxBounds3 bounds;
bounds.minimum = minimum;
bounds.maximum = maximum;

1. Change vsync = false; in RendererDesc.cpp to true.
2. Add Ps::Thread::sleep(1); on line 97 in SampleMain.cpp
   This brings down 2 busy-waiting cores, some 28% cpu usage on my pc, down to 2%.
   No more noisy fans when trying out the demos.

the GLSL is not compatible on Windows 10x 64 with latest intel IGP driver (25.20.100.6471 DCH / Win 10 64)

I had to put #version 440 in every shaders, yet I still do have lot of errors like :

Compiler error
Vendor: Intel
Renderer: Intel(R) HD Graphics 530
Version: 4.5.0 - Build 25.20.100.6471
Error: ERROR: 0:? : 'variable' : is not available in current GLSL version gl_TexCoord
ERROR: 0:? : 'variable' : is not available in current GLSL version gl_MultiTexCoord0
ERROR: 0:? : 'variable' : is not available in current GLSL version gl_Vertex

Is GLSL not compatible across vendors ?

Hello,

I just opened a random source code file and I see a lack of consistency in terms of indents.
There are some mixes of tab and space characters.

Are there code conventions which contributors have to follow?

Thanks!

Hi

THis isn't really an issue, but it's something that really bothers me and would make it harder to use. You have decided to use python as part of the project generation, where I think CMake should easily be able to handle it all by itself. I am wondering, why include Python in the mix? And are you planning on removing it as a dependency?
The reason python bothers my is because I regularly build on platforms without python, and I regularly work with a git managed project, where I prefer full control over CMake, and because of python, I don't have that.

So, are you planning on removing Python as part of your build system? And is there a way to avoid it when I integrate it with my CMakeLists.txt?(E.g. what variables need to be set to where?)

Thanks!

How does setVisualizationCullingBox work in PhysX? I tried setting a box to cull my debug lines, but it seems to have no effect.

As per mentioned in the title, the following flag eINFLATE_CONVEX is missing inside Includes/cooking/PxConvexMeshDesc.h but removal is not mentioned inside release notes. Has the flag been moved?

To my understanding, we can't use PhysX-4.0 together with FleX because PhysX is now distributed under the 3-Clause BSD license which forbids the usage of the name NVIDIA without written consent.
This is the exact opposite of the NVIDIA GAMEWORKS license as it requires detailed attribution to NVIDIA in section 6.

Is there any recommendation on how to deal with that? I am quite certain you don't want to allow the usage of NVIDIA's name individually?
Or ... can you tell if there are any plans for FleX becoming available under BSD license?

Hi,

I've been investigating some performance issues we have in large scenes (well over 10k rigid bodies). It seems that enabling speculative CCD on objects causes the objects to update contact distances via ScScene.preRigidBodyNarrowPhase even if they are sleeping. The contact distance update itself is rather expensive when many of the objects in the scene have speculative CCD enabled, but what's worse is that updating the contact distance causes BpSAP.updateWork to touch those objects as well.

Is there a reason why the contact distance is updated even for sleeping objects? To me it seems that it's only needed to inflate the contact distance when the object is moving. If the update is necessary, are there any other ideas for improving speculative CCD performance in large scenes?

I dont get contact reports between collisions of kinematic bodies in PxSimulationEventCallback (is that expected?). The only thing that works is to return e_CALLBACK from a custom shader and get collision pairs in PxSimulationFilterCallback::OnPairs - but thats very early on and inaccurate. I also get a warning warning : Filtering: Resolving contacts between two kinematic objects is invalid. Contacts will not get resolved. when doing so.

The documentation doesn't state anything about this. Is this a known limitation?

Hello,
I would like to use PhysX4.0 for simulating robots and to evaluate e.g. different kinematics. Therefore a pipeline for importing URDF-described robots as PxArticulationReducedCoordinate for simulation in generalized coordinates would be extremely valuable.
Are there any plans for adding URDF support?

Hi,

I think I've found a bug that probably has started occurring at some point after "PhysX 3.4.1, APEX 1.4.1 Release @2284554". I can reproduce the bug with latest PhysX 3.4, but I haven't tried to reproduce it on PhysX 4.0.

Here's a quick repro for it:

physx::PxSceneDesc sceneDesc( PxGetPhysics().getTolerancesScale() );
sceneDesc.cpuDispatcher = physx::PxDefaultCpuDispatcherCreate( 1 );
sceneDesc.filterShader = physx::PxDefaultSimulationFilterShader;
auto scene = PxGetPhysics().createScene( sceneDesc );

physx::PxTransform transform( physx::PxVec3( 0.0f, 0.0f, 0.0f ), physx::PxQuat( 0.0f, physx::PxVec3( 0.0f, 0.0f, 1.0f ) ) );
auto actor = PxGetPhysics().createRigidDynamic( transform );
actor->setRigidBodyFlag( physx::PxRigidBodyFlag::eENABLE_SPECULATIVE_CCD, true );

auto material = PxGetPhysics().createMaterial( 0.0f, 0.0f, 0.0f );
physx::PxBoxGeometry geometry( 0.5f, 0.5f, 0.5f );
physx::PxShape* shape = scene->getPhysics().createShape( geometry, *material );
shape->setFlag( physx::PxShapeFlag::eSIMULATION_SHAPE, false );
actor->attachShape( *shape );

scene->addActor( *actor );
scene->simulate( 1 / 60.0f );
scene->fetchResults( true );

PhysX emits an "Illegal BroadPhaseUpdateData" error and it also triggers an assert PX_ASSERT(mGroups[handle] != Bp::FilterGroup::eINVALID); in SimpleAABBManager::updateAABBsAndBP.

After I compiled PhysX SDK with xcode, the libPhysX_static_64.a is 221Mb.
When set the Generate Debuy Symbols is False, the generate static lib is 186Mb, but still too large for our git project.
So, how can I to reduce the size of libPhysX_static_64.a ??

I'm just wondering if there is an offline version(pdf file?) of user guide/API reference?

Thank you!

After generating the project I compiled Physx with make all (in compiler) and it seems that only snippets are compiled.
I tried to run cmake on the CMakeLists.txt in PhysX/physx/samples/compiler/cmake
And I encounter this error:

CMake Error at CMakeLists.txt:39 (MESSAGE):
  Could not find


-- Configuring incomplete, errors occurred!

I found this so I am not sure if samples are supposed to run under Linux.

Visual studio debugger console output:

"Exception thrown: read access violation.
cm was nullptr."

Autos output:

•   cm	0x0000000000000000 <NULL>	physx::PxsContactManager *
  

•   this	0x0000022da9505fa0 {mRemovedContactManagers={mData=0x0000000000000000 {???} mSize=0 mCapacity=0 } mNarrowPhasePairs=...}	physx::PxsNphaseImplementationContext *
  

•   physx::PxvNphaseImplementationContextUsableAsFallback	{...}	physx::PxvNphaseImplementationContextUsableAsFallback
  

•   mRemovedContactManagers	{mData=0x0000000000000000 {???} mSize=0 mCapacity=0 }	physx::shdfnd::Array<unsigned int,physx::shdfnd::NamedAllocator>
  

•   mNarrowPhasePairs	{mOutputContactManagers={mData=0x0000022db38209a0 {contactPatches=0x0000022e2d271120 "" contactPoints=...} ...} ...}	physx::PxsContactManagers
  

•   mNewNarrowPhasePairs	{mOutputContactManagers={mData=0x0000022e2ca80000 {contactPatches=0x0000000000000000 <NULL> contactPoints=...} ...} ...}	physx::PxsContactManagers
  

•   mModifyCallback	0x0000000000000000 <NULL>	physx::PxContactModifyCallback *
  

•   mIslandSim	0x0000022dc6042b40 {mIslandHandles={mFreeHandles={mData=0x0000022ee403ac80 {1162} mSize=1257 mCapacity=...} ...} ...}	physx::IG::IslandSim *
  

Call Stack:

PhysX_64.dll!physx::PxsNphaseImplementationContext::unregisterContactManager(physx::PxsContactManager * cm) Line 691 C++
PhysX_64.dll!physx::Sc::Scene::finishBroadPhaseStage2(const unsigned int ccdPass) Line 6074 C++
PhysX_64.dll!physx::Sc::Scene::updateCCDSinglePassStage3(physx::PxBaseTask * continuation) Line 3125 C++
PhysX_64.dll!physx::Cm::Task::run() Line 67 C++
CarbonEditor.exe!physx::Ext::CpuWorkerThread::execute() Line 97 C++
PhysXFoundation_64.dll!physx::shdfnd::`anonymous namespace'::PxThreadStart(void * arg) Line 101 C++
kernel32.dll!BaseThreadInitThunk�() Unknown
ntdll.dll!RtlUserThreadStart�() Unknown

Hi,

I have a crash with the following call stack:

PxFoundationDEBUG_x64.dll!physx::shdfnd::NamedAllocator::allocate(unsigned __int64 size, const char * filename, int line) Line 99 C++
PhysX3DEBUG_x64.dll!physx::shdfnd::Arrayphysx::Bp::AABBOverlap,physx::shdfnd::NamedAllocator::allocate(unsigned int size) Line 553 C++
PhysX3DEBUG_x64.dll!physx::shdfnd::Arrayphysx::Bp::AABBOverlap,physx::shdfnd::NamedAllocator::growAndPushBack(const physx::Bp::AABBOverlap & a) Line 679 C++
PhysX3DEBUG_x64.dll!physx::shdfnd::Arrayphysx::Bp::AABBOverlap,physx::shdfnd::NamedAllocator::pushBack(const physx::Bp::AABBOverlap & a) Line 304 C++
PhysX3DEBUG_x64.dll!physx::Bp::deleteOverlap(physx::shdfnd::Arrayphysx::Bp::AABBOverlap,physx::shdfnd::NamedAllocator * overlaps, const physx::shdfnd::Arrayphysx::Bp::VolumeData,physx::shdfnd::NamedAllocator & volumeData, unsigned int id0, unsigned int id1) Line 2252 C++
PhysX3DEBUG_x64.dll!physx::Bp::PersistentPairs::updatePairs(unsigned int timestamp, const physx::PxBounds3 * bounds, const float * contactDistances, const physx::Bp::FilterGroup::Enum * groups, const bool * lut, physx::shdfnd::Arrayphysx::Bp::VolumeData,physx::shdfnd::NamedAllocator & volumeData, physx::shdfnd::Arrayphysx::Bp::AABBOverlap,physx::shdfnd::NamedAllocator * createdOverlaps, physx::shdfnd::Arrayphysx::Bp::AABBOverlap,physx::shdfnd::NamedAllocator * destroyedOverlaps) Line 2372 C++
PhysX3DEBUG_x64.dll!physx::Bp::SimpleAABBManager::updatePairs(physx::Bp::PersistentPairs & p, physx::Bp::BpCacheData * data) Line 2436 C++
PhysX3DEBUG_x64.dll!physx::Bp::PersistentActorAggregatePair::update(physx::Bp::SimpleAABBManager & manager, physx::Bp::BpCacheData * data) Line 1028 C++
PhysX3DEBUG_x64.dll!physx::Bp::ProcessAggPairsParallelTask::runInternal() Line 2663 C++
PhysX3DEBUG_x64.dll!physx::Cm::Task::run() Line 67 C++

It looks like "volumeType" is 3 in deleteOverlap(), but the "overlaps" array it accesses has only two elements. I have a solid 100% repro for this crash in my (huge) test level, but unfortunately I don't have a simple way to repro that I could share. The crash goes away if I disable aggregates on my ragdolls.

The version I'm using is 3.4.1.25354359, but in the earlier "PhysX 3.4.1, APEX 1.4.1 Release @2284554" version I did not get this crash.

If this is not enough information to get the issue fixed, could you point me to some code I could take a look at to further investigate this?

I'm implementing a simple physics simulator and I wanted to know if it's possible to convert PxRigidDynamic to PxRigidStatic.
Thank you!

Hi all,

I'm attempting to read a RepX file and write the result back out to another RepX file, but noticed the IDs don't match between input and output, and that the <Name> tag isn't preserved.

How can I track which PxRigidDynamic coming out of the solver relates to which going in?

To reproduce

1. Build SnippetLoadSaveCollection.cpp, a modified version of SnippetLoadCollection.cpp
2. Load CollectionA_in.xml
3. Get CollectionA_out.xml in return.

Notice the input IDs start at 1, the output seems random, e.g. 1384972677664.

I found that if I serialise the same collection going into the solver after having run a few simulate() steps, rather than create one anew, then the IDs match. But I'm curious as to where these new IDs come from, and whether there was any way to preserve them? Preferably, I'd also keep the <Name> tag in the serialised output.

When excuting the shell script generate_projects.sh, I go this undefined error.

Using preset xml: /home/nvidia/PhysX/physx/buildtools/presets/public/linux-aarch64.xml
Target platform: linuxAarch64 using compiler: gcc
PM_CMakeModules_PATH: /home/nvidia/PhysX/physx/../externals/cmakemodules
PM_PATHS: /home/nvidia/PhysX/physx/../externals/opengl-linux
Cmake: cmake
sh: 1: cmake: not found
sh: 1: cmake: not found
sh: 1: cmake: not found
sh: 1: cmake: not found

After debugging, I figuerd out the error was becuase I did not have cmake installed in my system. Also, notice that for compiling CMake 3.12 or higher is required!

It could indicate the link of the source code of the PhysX SDK 4.0 demo "https://www.youtube.com/watch?v=K1rotbzekf0" ?

Hi,

When adding PxRigidDynamic object with PxRigidBodyFlag::eKINEMATIC motion type and PxShape with geometry type PxGeometryType::eTRIANGLEMESH crashes simulation.

This configuration was working fine in PhysX 3.4.

The Call Stack:
0000000000000000() Unknown

PhysX_64.dll!physx::PxcDiscreteNarrowPhasePCM(physx::PxcNpThreadContext & context, const physx::PxcNpWorkUnit & input, physx::Gu::Cache & cache, physx::PxsContactManagerOutput & output) Line 444 C++
PhysX_64.dll!PxsCMDiscreteUpdateTask::processCms<&physx::PxcDiscreteNarrowPhasePCM>(physx::PxcNpThreadContext * threadContext) Line 441 C++
PhysX_64.dll!PxsCMDiscreteUpdateTask::runInternal() Line 514 C++
PhysX_64.dll!physx::Cm::Task::run() Line 67 C++
CarbonEditor.exe!physx::Ext::CpuWorkerThread::execute() Line 97 C++
PhysXFoundation_64.dll!physx::shdfnd::`anonymous namespace'::PxThreadStart(void * arg) Line 101 C++
kernel32.dll!BaseThreadInitThunk�() Unknown
ntdll.dll!RtlUserThreadStart�() Unknown

NVIDIA, are you seriously?
link

There's quite a few binary files in this repository... prebuilt executables, libraries, textures, etc. I'd imagine the history for those files will get quite large as this repo moves forward. Why not use git-lfs to store those files?

Getting an error of not specifying PHYSX_ROOT_DIR when running generate_projects.bat

After I create and set to the ../physx directory of my project folder, I get further cmake errors with respect to NV_USE_GAMEWORKS_OUTPUT_DIRS?

Anybody know some magic I'm missing....?

Where can I find old PhysX DCC Plugins for 3dsmax to download.

I need version 2.01 or other older versions.

Hi,

I was trying to build the physx solution when I got following problems:

1. Building solutions with either debug or checked will generate include errors for d3dx9.h and d3d11tex.h like this:
   2>c:\physx-4.0\physx\samples\sampleframework\renderer\src\d3d9\d3d9renderer.h(42): fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or directory (compiling source file C:\PhysX-4.0\physx\samples\sampleframework\renderer\src\d3d9\D3D9RendererVertexBuffer.cpp) 2>c:\physx-4.0\physx\samples\sampleframework\renderer\src\d3d11\d3d11rendererutils.h(38): fatal error C1083: Cannot open include file: 'd3dx11tex.h': No such file or directory (compiling source file C:\PhysX-4.0\physx\samples\sampleframework\renderer\src\d3d11\D3D11RendererMaterial.cpp)

2. The above errors do not prevent the libs from generating though. I can find PhysXCommon_64.lib, PhysX_64.lib, PhysXFoundation_64.lib and PhysXCooking_64.lib and their dlls under the path physx\bin\win.x86_64.vc141.mt\checked (or \debug) as I building with x64 VS 2017. So here is what I did:

• In VC++ Directories -> Include Directories, I included physx\include and pxshared\include
• In VC++ Directories -> Library Directories, I included local\thirdparty\physx, which is a local directory I used to put the 4 lib files above
• In Linker->General->Additional Library Directories, I included local\thirdparty\physx again
• In Linker->Input, I included names of the 4 libs above, in order, separated with ';'
• I then copied the 5 dlls (plus PhysXGpu_64.dll) to the same folder as my application's .exe
• In my TheApp.hpp (my startup class) I included the lines
  #pragma comment(lib, "PhysX_64.lib") #pragma comment(lib, "PhysXCommon_64.lib") #pragma comment(lib, "PhysXCooking_64.lib") #pragma comment(lib, "PhysXFoundation_64.lib")

But then when I tried to create
PxDefaultErrorCallback m_DefaultErrorCallback;
as a member of TheApp, the linking error happens
1>TheApp.obj : error LNK2019: unresolved external symbol "public: __cdecl physx::PxDefaultErrorCallback::PxDefaultErrorCallback(void)" (??0PxDefaultErrorCallback@physx@@QEAA@XZ) referenced in function "public: __cdecl TheApp::TheApp(void)" (??0TheApp@@QEAA@XZ) 1>TheApp.obj : error LNK2019: unresolved external symbol "public: virtual __cdecl physx::PxDefaultErrorCallback::~PxDefaultErrorCallback(void)" (??1PxDefaultErrorCallback@physx@@UEAA@XZ) referenced in function "int public: __cdecl TheApp::TheApp(void)'::1'::dtor$0" (?dtor$0@?0???0TheApp@@QEAA@XZ@4HA)

I am not sure what is going wrong with my linking. Can someone share some insights? Thx.

John

I thought I'd test the capability of the new TGS solver to handle large mass ratios. To this end, I created a simple test case involving a vertical stack of 5 boxes, where adjacent boxes have a 100:1 mass ratio (the masses are 0.1Kg and 10Kg). The boxes are dimensioned 0.4m x 0.4m x 0.4m and set to use a contact offset of 1mm and a rest offset of 0.5mm. The friction offset is also set to 1mm on the scene descriptor.

I use a constant time-step of 0.01s and each box is set to use 40 positional iterations and 10 velocity iterations. This is using the same 8:2 ratio which I believe is the default but scaled up 5 fold.

This stack is stable using the PGS solver (and will eventually sleep):

If I switch to using the TGS solver then the stack is immediately unstable and collapses.

The stack is stable using the TGS solver if I set the rest offsets to 0. Also, if I increase the number of velocity iterations to 40 or so then the stack is stable.

Source code for the snippet.

Hi,
I'm working with reduced coordinate articulations for the purpose of simulating robots in generalized coordinates. As far as I understand from the code and the docs, when creating an articulation joint PxArticulationJoint I can only configure one of the discrete values defined in PxArticulationAxis like eTWIST, eSWING1, eSWING2, eX, eY, eZan eCOUNT as axis of motion. Are there any plans to support arbitrary unit vectors as axis of motion for revolute and prismatic joints at some point?
This seems necessary to comply with structures as defined by generic URDFs..

now that it has become "open" does it support acceleration also on amd boards as it was in the past with mods?

PX_PHYSX_STATIC_LIB controls the dllimport/dllexport of most of the libraries except for foundation.

This means that to include headers from static lib builds I need to do...

#define PX_PHYSX_STATIC_LIB
#define PX_FOUNDATION_DLL 0
#include <PxPhysics.h>
#include <PxFoundation.h>

...which seems a bit clunky. Ideally a simple config.h could be generated that gets included in both the physx build and the application build to ensure consistent environment. Or at the very least reduce it to a single define (e.g. PX_PHYSX_STATIC_LIB).

Instead use the *A or *W functions directly that match the types you are trying to pass to avoid compilation issues under different environments. Proposed diff below...

--- a/physx/source/physx/src/device/windows/PhysXIndicatorWindows.cpp
+++ b/physx/source/physx/src/device/windows/PhysXIndicatorWindows.cpp
@@ -74,7 +74,7 @@ physx::PhysXIndicator::PhysXIndicator(bool isGpu)
        else
                NvPhysXToDrv_Build_SectionName(GetCurrentProcessId(), configName);

-       mFileHandle = CreateFileMapping(INVALID_HANDLE_VALUE, NULL,
+       mFileHandle = CreateFileMappingA(INVALID_HANDLE_VALUE, NULL,
                PAGE_READWRITE, 0, sizeof(NvPhysXToDrv_Data_V1), configName);

        if (!mFileHandle || mFileHandle == INVALID_HANDLE_VALUE)

Hi folks, the PhysX documentation says "We strongly recommend that you use the checked build as the primary configuration for day-to-day development and QA.". My project uses the runtime library /MDd (because it's in debug configuration) but the checked configuration of PhysX uses /MD. This causes a linker error (LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in xxx.obj). A possible solution is to use the debug configuration of PhysX, which also uses the /MDd runtime library, but i don't think thats the correct solution to this issue.

My project uses the following PhysX libs:

• PhysX_64.lib
• PhysXCommon_64.lib
• PhysXCooking_64.lib
• PhysXFoundation_64.lib
• PhysXExtensions_static_64.lib
• PhysXPvdSDK_static_64.lib
• FastXml_static_64.lib

Are there any ideas how to solve this issue?

Thanks,
Michael

Hey,
My question is:
How can I create collisions for a tube or other complex objects with the PhysX Utility in 3dsmax?

Screenshot of the PhysX Utility in 3dsmax:
http://prntscr.com/mewcbt

What is the recommended way to enable/disable self collisions for PxArticulationReducedCoordinate?
A filterShader doesn't seem to help. Do we need to create PxAggregate for the links?

Is there any documentation for the new PxArticulationReducedCoordinate?

I would like to override the 'filterArticulationLinks' method, to avoid all self-collisions for some articulations (not just filter self-collisions between links that are directly parent-child).

static bool filterArticulationLinks(const ActorSim& rbActor0, const ActorSim& rbActor1)
{
	// If the bodies are articulation links of the same articulation and one link is the parent of the other link, then disable collision
	PxU32 size = rbActor0.getActorInteractionCount();
	Interaction** interactions = rbActor0.getActorInteractions();
	while(size--)
	{
		const Interaction* interaction = *interactions++;
		if(interaction->getType() == InteractionType::eARTICULATION)
		{
			if (rbActor0.getActorCore().getActorFlags() == physx::PxActorFlag::eDISABLE_SELF_COLLISION)
				return true;
			if (rbActor1.getActorCore().getActorFlags() == physx::PxActorFlag::eDISABLE_SELF_COLLISION)
				return true;
			if ((&interaction->getActorSim0() == &rbActor1) || (&interaction->getActorSim1() == &rbActor1))
				return true;
		}
	}
	return false;
}

Posted the question here, since Adam asked for it here, instead of forum (still, I think forum has some value too): https://devtalk.nvidia.com/default/topic/1046135/physx-and-physics-modeling/please-consider-posting-questions-to-physx-github-issues-directly-/

Hi there,

our legal counsel has advised us to put a CLA in place before accepting pull requests. We are working on sorting this out but due to the impending holidays it won't happen until next year.

Of course if you find and fix issues there is no harm in queuing up the fixes already so they are not forgotten about.

Another thing to be aware of is that our internal day to day development happens in perforce and we will continue pushing periodic 'releases' over to github that have passed our internal testing process. So even when we start to take pull requests they will not manifest on github immediately, but will get merged to perforce first and then appear here later as part of the next versioned update.

--Adam

Hi

The CharacterKinematic is built by default as a static library, but it looks like it can be configured as a dynamic library. When building everything is fine, however when including in a project, in windows, it causes linker errors. It is caused by this code in PxCharacter.h;

// define API function declaration
#if defined PX_PHYSX_STATIC_LIB || defined PX_PHYSX_CHARACTER_STATIC_LIB
	#define PX_PHYSX_CHARACTER_API
#else
	#if PX_WINDOWS
		#if defined PX_PHYSX_CHARACTER_EXPORTS
			#define PX_PHYSX_CHARACTER_API __declspec(dllexport)
		#else
			#define PX_PHYSX_CHARACTER_API __declspec(dllimport)
		#endif
	#elif PX_UNIX_FAMILY
		#define PX_PHYSX_CHARACTER_API PX_UNIX_EXPORT
    #else
		#define PX_PHYSX_CHARACTER_API
    #endif
#endif

The issue is a static library is 'exported' with no special declarations but if using the the library on windows with no knowledge, it uses __declspec(dllimport), which results in a linker error. This can be easily solved by the end user ensuring PX_PHYSX_CHARACTER_STATIC_LIB is defined. However its not very obvious. May I suggest either adding some documentation around this, or even better get CMAKE to create a BuildSettings.h type file which contains the pre-processor defines that are decide at CMAKE configure time. ie PX_PHYSX_CHARACTER_STATIC_LIB

Thanks :)

PS. Apart from this and the other issue i found, the new build system works great

CMake 3.13.2

Preset parameter required, available presets:
(0) mac64 <--- macOS Xcode PhysX general settings
(1) ios64 <--- iOS Xcode PhysX general settings
(2) linux-aarch64 <--- Linux-aarch64 gcc PhysX SDK general settings
(3) linux <--- Linux clang PhysX SDK general settings
Enter preset number: 3
Running generate_projects.bat linux
Using preset xml: buildtools/presets/public/linux.xml
Target platform: linux using compiler: clang
PM_CMakeModules_PATH: /files/thirdparty/PhysX/physx/../externals/cmakemodules
PM_PATHS: /files/thirdparty/PhysX/physx/../externals/opengl-linux
Cmake: cmake
Not searching for unused variables given on the command line.
PHYSX ROOT /files/thirdparty/PhysX/physx
PhysX Build Platform: linux
Using CXX Compiler: /usr/bin/clang++
CMake Error at /files/thirdparty/PhysX/externals/cmakemodules/GetCompilerAndPlatform.cmake:244 (IF):
  if given arguments:

    "STREQUAL" "x86_64-unknown-linux-gnu" "OR" "STREQUAL" "x86_64-linux-gnu"

  Unknown arguments specified
Call Stack (most recent call first):
  /files/thirdparty/PhysX/externals/cmakemodules/NvidiaBuildOptions.cmake:99 (GetPlatformBinName)
  /files/thirdparty/PhysX/physx/source/compiler/cmake/CMakeLists.txt:73 (INCLUDE)


-- Configuring incomplete, errors occurred!
See also "/files/thirdparty/PhysX/physx/compiler/linux-debug/CMakeFiles/CMakeOutput.log".```

etc

Getting a static assert firing only on 32-bit GCC Linux builds.

#if !PX_APPLE_FAMILY && !PX_EMSCRIPTEN && !(PX_CLANG && PX_X86)
PX_COMPILE_TIME_ASSERT(PX_OFFSET_OF(PxPackValidation, a) == 8);
#endif

Looks like its testing alignment behavior, but only on certain builds. But if it's indeed safe to disable this check on Apple, Emscripten and Clang+x86 builds, then surely its not needed elsewhere either? Either that or its being erroneously suppressed on those configurations?

Because while I could fix this issue by setting "-malign-double", I would have to set that for my entire project which I really don't want to just to suppress this error.

Hi everyone,
I'm currently working on simulation and control of floating base robots. I'm using PxArticulationReducedCoordinate to represent my robot and would like to use the dynamic model of the robot (more precisely gravity (g), coriolis/centrifugal-forces (c), and the massmatrix (M) ) e.g. for control purposes.
For all of these quantities, how and where are the 6 degrees of freedom of the floating base handled?

For example when I do the following to get the gravity terms, as far as I see I only get the terms acting in the joints of the system but nothing acting on the floating base..

    PxArticulationCache* cache = articulation->createCache();
    articulation->copyInternalStateToCache(*cache, PxArticulationCache::eALL);
    articulation->computeGeneralizedGravityForce(*cache);
    // .. and then read cache->jointForce[0 ... articulation->getDofs()-1]

Am I missing something? Are floating bases considered in the dynamics terms M c g?

On Windows, I use PhysX_64 PhysXCommon_64 PhysXCooking_64 PhysXExtensions_static_64 PhysXFoundation_64 PhysXPvdSDK_static_64 PhysXTask_static_64
But Linux lacks the last one. All other are built, no error shown in the end.
The build process prints
[ 34%] Built target PhysXTask
but no such lib is available for linking. Maybe that's the reason for these:
physxcooking/src/Cooking.cpp:97: undefined reference to physx::shdfnd::FPUGuard::FPUGuard()'`

pvd/src/PxPvdDataStream.cpp:784: undefined reference to physx::shdfnd::Time::getCurrentCounterValue()'
I know ordering during linking can be a problem on Linux too. I tried switching them around a bit with no luck.