Hello everyone,

I am trying to investigate simulation using SPH solver for particles just like in PhysX or FleX (Well for FleX I'm not 100% sure it is SPH), involving mechanical systems.

Actually Particles were removed from PhysX (or are going to be removed or whatever) because FleX is more performant. But FleX is not really practical to create mechanisms. (No Joint features). Are you going to create these features in FleX ?

I am trying to get realistic Water in PhysX. Has someone already found the ideal parameters to apply on the ParticleFluid system ? (Material, Viscosity, Stiffness, ParticleMass)

Thanks !

We build PhysX binaries in MSVS 2015 but one of our projects is in MSVS 2008.
Does it make sense to fix these issues ?

./../../GeomUtils/src/mesh/GuBV4.cpp: In member function ‘void physx::Gu::SourceMesh::remapTopology(const physx::PxU32*)’:
./../../GeomUtils/src/mesh/GuBV4.cpp:84: error: array subscript is below array bounds [-Warray-bounds]

found on:
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]

I can't find out any instruction about the force field interface or sample code. [mApexSDK->createModule("ForceField")] this fuction return a NULL pointer. and there will print a warning "ApexSDKImpl::createModule(ForceField) Not allowed". is there any body could give me some advice?

Hello,

I'm getting crash when building visualization buffer. It happens when some object moves (there is a few frames of working debug visualizer, when nothing moves). I'm doing gathering of debugBuffer after fetch with lockRead/unlockRead just to be sure, there is no race.

I'm using newset PhysX 3.4 code.

Callstack:

`visualizeTree'::`5'::Local::_Draw(const physx::Sq::AABBTreeRuntimeNode * root, const physx::Sq::AABBTreeRuntimeNode * node, physx::Cm::RenderOutput & out_) Line 775	C++
physx::Sq::ExtendedBucketPruner::visualize(physx::Cm::RenderOutput & out, unsigned int color) Line 790	C++
physx::Sq::AABBPruner::visualize(physx::Cm::RenderOutput & out, unsigned int color) Line 544	C++
physx::NpScene::visualize() Line 1540	C++
physx::NpScene::simulateOrCollide(float elapsedTime, physx::PxBaseTask * completionTask, void * scratchBlock, unsigned int scratchBlockSize, bool controlSimulation, const char * invalidCallMsg, physx::Sc::SimulationStage::Enum simStage) Line 1967	C++
physx::NpScene::simulate(float elapsedTime, physx::PxBaseTask * completionTask, void * scratchBlock, unsigned int scratchBlockSize, bool controlSimulation) Line 2049	C++

SqExtendedBucketPruner.cpp [775]

void visualizeTree(Cm::RenderOutput& out, PxU32 color, AABBTree* tree)
{
	if (tree)
	{
		struct Local
		{
			static void _Draw(const AABBTreeRuntimeNode* root, const AABBTreeRuntimeNode* node, Cm::RenderOutput& out_)
			{
				out_ << Cm::DebugBox(node->mBV, true);   // <<< CRASH, root and node is nullptr
				if (node->isLeaf())
					return;
				_Draw(root, node->getPos(root), out_);
				_Draw(root, node->getNeg(root), out_);
			}
		};
		out << PxTransform(PxIdentity);
		out << color;
		Local::_Draw(tree->getNodes(), tree->getNodes(), out);
	}
}

mMainTree seems to be empty : http://i.imgur.com/yZ1DYFS.png

It's strange that my posts in DevTalk Forums became hidden, so I create an issue here.

Following lines are from the original post :

"In the default coordinate settings, when posing the vehicle wheels, the signs of camber angle agree with left wheels. (So we must reverse the signs when setting up right wheels, Am I right ?)

However, in this coordinate settings, for left wheels, positive camber angles will generate lateral forces along negative x-axis, negative camber angles will generate lateral forces along positive x-axis, The implementation of PxVehicleComputeTireForceDefault follows equation (17) and equation (19) of CarSim Manual Appendix H, which doing the reverse."

https://devtalk.nvidia.com/default/topic/1011024/physx-and-physics-modeling/possible-bug-the-direction-of-camber-thrust-in-pxvehicle-physx-3-4-/

In his/her replies, gyeoman confirmed the bug, but he/she also suggested that the sign of camber angles do not affect the direction of camber thrust. I do not think it's correct. See the following wiki page, it has a good explanation.

https://en.wikipedia.org/wiki/Camber_thrust

And the following line comes from Gillespie's "Fundamentals of Vehicle Dynamics":

"...For discussion it is sufficient to recognize that the force is always oriented in the direction the tire is inclined..."

As gyeoman pointed out, the tire model comes from Equation 19, but Equation 19 comes from Equation 17. By Equation 17, it's easy to see the effect of the sign of camber angles.

Sorry for the lack of analysis, it really pains me to type a long explanation (I am not good at English), I give up. :(

Currently there is very inconsistent use of uppercase letters in some of the directory paths. E.g PxShared directory uses all lower case(lib,bin,include), PhysX_3.4 directory uses (Bin, Lib, Include). Rather annoying when working on non windows machines.

In PxMeshOverlapUtil::findOverlap I was hitting the assert PX_ASSERT(!overflow);

I tracked this down to GuBV4_BoxOverlap.cpp:158:

OBBParamsAll* ParamsAll = static_cast<OBBParamsAll*>(params);
ParamsAll->mHits[ParamsAll->mNbHits] = primIndex;
ParamsAll->mNbHits++;
if(ParamsAll->mNbHits==ParamsAll->mMaxNbHits)
	return 1;

In this case, "return 1" means an overflow occured. As you can see, it detects an overflow too early, as it can't know if there's going to be another one added.

I'd recommend changing this to something like:

OBBParamsAll* ParamsAll = static_cast<OBBParamsAll*>(params);
if(ParamsAll->mNbHits<ParamsAll->mMaxNbHits)
{
	ParamsAll->mHits[ParamsAll->mNbHits] = primIndex;
	ParamsAll->mNbHits++;
}
else
{
	return 1;
}

This way, it only reports an overflow when it tries to add a new hit and it doesn't fit into the array.

There's another instance of this mistake in GuBV4_BoxOverlap.cpp:378. Not sure about other files.

I try to init GPU Rigid Bodies :

	PxGpuDispatcher * GPUDispatcher;
	PxCudaContextManager* gCudaContextManager;

	PxCudaContextManagerDesc cudaContextManagerDesc;
	ZeroMemory(&cudaContextManagerDesc, sizeof ( PxCudaContextManagerDesc ));
	cudaContextManagerDesc.graphicsDevice = MY_DX11_device;
	cudaContextManagerDesc.interopMode = PxCudaInteropMode::D3D11_INTEROP;
	cudaContextManagerDesc.ctx = NULL;
	cudaContextManagerDesc.appGUID = "APName";

	gCudaContextManager = PxCreateCudaContextManager( *gFoundation, cudaContextManagerDesc );

	if ( gCudaContextManager )	
	GPUDispatcher = gCudaContextManager->getGpuDispatcher();

	if ( GPUDispatcher )		
	{
		desc.gpuDispatcher = GPUDispatcher;
		desc.flags |= PxSceneFlag::eENABLE_GPU_DYNAMICS;
		desc.flags |= PxSceneFlag::eENABLE_PCM;
		desc.flags |= PxSceneFlag::eENABLE_STABILIZATION;
		desc.broadPhaseType = PxBroadPhaseType::eGPU;
		desc.gpuMaxNumPartitions = 8;
		desc.gpuDynamicsConfig.constraintBufferCapacity = (32 * 1024 * 1024);
		desc.gpuDynamicsConfig.contactBufferCapacity = (24 * 1024 * 1024);
		desc.gpuDynamicsConfig.tempBufferCapacity = (16 * 1024 * 1024);
		desc.gpuDynamicsConfig.contactStreamSize = (6 * 1024 * 1024);
		desc.gpuDynamicsConfig.patchStreamSize = (5 * 1024 * 1024);
		desc.gpuDynamicsConfig.forceStreamCapacity = (1 * 1024 * 1024);
		desc.gpuDynamicsConfig.heapCapacity = (64 * 1024 * 1024);
		desc.gpuDynamicsConfig.foundLostPairsCapacity = (256 * 1024);
	}

	gScene = gPhysics->createScene(desc);

Initialization was successful, but RigidBodies - Boxes behavior are wrong : Something wrong with Boxes gravity and frictions if colliding with Heightfield or with each other. Boxes just skating on Heightfield surface as there no frictions at all.

If i use CPU PhysX i have no problem with RigidBodies and Heightfield behavior.

What is wrong with initialisation or whatever?

mPort is initialised before mHost ... https://github.com/NVIDIAGameWorks/PhysX-3.4/blob/master/PxShared/src/foundation/src/windows/PsWindowsSocket.cpp#L98-L99. These need swapping around as mHost is declared before mPort ( https://github.com/NVIDIAGameWorks/PhysX-3.4/blob/master/PxShared/src/foundation/src/windows/PsWindowsSocket.cpp#L87-L88 ) and warnings are treated as errors with the current setup on visual studio.

.

In PhysX-3.4\PhysX_3.4\Source\LowLevelCloth\src\SwSolverKernel.cpp, line 209

curPos0 = curPos0 & (splat<0>(radius) > sMinusFloatMaxXYZ);
curPos1 = curPos1 & (splat<1>(radius) > sMinusFloatMaxXYZ);
curPos2 = curPos2 & (splat<2>(radius) > sMinusFloatMaxXYZ);
curPos3 = curPos3 & ((radius) > sMinusFloatMaxXYZ);

why not ?

curPos0 = curPos0 & (splat<0>(radius) > sMinusFloatMaxXYZ);
curPos1 = curPos1 & (splat<1>(radius) > sMinusFloatMaxXYZ);
curPos2 = curPos2 & (splat<2>(radius) > sMinusFloatMaxXYZ);
curPos3 = curPos3 & (**splat<3>**(radius) > sMinusFloatMaxXYZ);

In the source code:
https://github.com/NVIDIAGameWorks/PhysX-3.4/blob/master/PhysX_3.4/Source/LowLevelDynamics/src/DyBodyCoreIntegrator.h#L71
I can see the damping formula,

However based on information I've found in the Bullet engine, it looks like that formula will produce different results depending on the timestep, see here:
https://github.com/bulletphysics/bullet3/blob/master/src/BulletDynamics/Dynamics/btRigidBody.cpp#L163
With the discussion here:
https://code.google.com/archive/p/bullet/issues/74

Perhaps PhysX's formula should be updated as well?

There is a reference pulled out of a vector type class at the top of the function:

PxTaskTableRow & tt = mTaskTable[ taskID ];

Next the task is sumbitted using:

mCpuDispatcher->submitTask( *tt.mTask );

In the case of using APEX cloth new tasks can be added to the task manager causing the vector to be resized. At the end of the PxTaskManager::dispatchTask() routine it uses the reference to set the type which stomps memory that was released by the vector class.

tt.mType = PxTaskType::TT_COMPLETED;

Simple fix is to change the line to:
mTaskTable[taskID].mType = PxTaskType::TT_COMPLETED;

I use gcc gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291] and i have the following issues due to missing braces. They just have to be added.

./../../LowLevelAABB/src/BpBroadPhaseMBP.cpp:1898: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]

./../../LowLevelAABB/src/BpBroadPhaseSapAux.cpp:746: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]

./../../LowLevelAABB/src/BpSimpleAABBManager.cpp:1206: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]

./../../LowLevelDynamics/src/DyConstraintPartition.cpp:443: error: suggest a space before ‘;’ or explicit braces around empty body in ‘for’ statement [-Wempty-body]

./../../LowLevelDynamics/src/DySolverControl.h:47: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]
./../../LowLevelDynamics/src/DySolverControl.h:60: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]
./../../LowLevelDynamics/src/DySolverControl.h:61: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]

./../../LowLevelDynamics/src/DyDynamics.cpp:2447: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]
./../../LowLevelDynamics/src/DyDynamics.cpp:2869: error: suggest a space before ‘;’ or explicit braces around empty body in ‘for’ statement [-Wempty-body]

./../../PhysXExtensions/src/serialization/SnSerialization.cpp:325: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]

./../../PhysXExtensions/src/serialization/Xml/SnRepXUpgrader.cpp:62: error: suggest a space before ‘;’ or explicit braces around empty body in ‘for’ statement [-Wempty-body]

./../../Common/src/CmBoxPruning.cpp:176: error: suggest a space before ‘;’ or explicit braces around empty body in ‘while’ statement [-Wempty-body]

Hi,
I try to use the physx sdk in my project.
I built it with VS2015 community without issues.

When I try to link the PhysxExtensions.lib to the physics dll of my project, I get some link errors (basically the same as this post: https://devtalk.nvidia.com/default/topic/527000/physx-and-physics-modeling/physx-sdk-3-2-2-windows-libraries-are-badly-compiled/post/3747125/#3747125 ).

I checked my dll. It's build with the /MD switch.
I selected all the project in the Physx solution and set their flag to /MD.

No matter what I do, I cannot get it to link.

It seems that some specific files are using the MT CRT, but I cannot find why (their property states /MD).

Thanks
JNQ

in PxPhysXConfig.h, try set these macro from 1 to 0 then compile

#define PX_USE_PARTICLE_SYSTEM_API 0
#define PX_USE_CLOTH_API 0

compile output:

1>------ Build started: Project: SimulationController, Configuration: debug x64 ------
1>  ScElementSim.cpp
1>..\..\SimulationController\src\ScElementSim.cpp(122): error C2039: 'eCLOTH': is not a member of 'physx::Sc::ElementType'
1>  e:\physx-3.4\physx_3.4\source\simulationcontroller\src\ScElementSim.h(49): note: see declaration of 'physx::Sc::ElementType'
1>..\..\SimulationController\src\ScElementSim.cpp(122): error C2065: 'eCLOTH': undeclared identifier
1>..\..\SimulationController\src\ScElementSim.cpp(122): error C2086: 'char PxCompileTimeAssert_Dummy[1]': redefinition
1>  E:\PhysX-3.4\PxShared\include\foundation/PxPreprocessor.h(485): note: see declaration of 'PxCompileTimeAssert_Dummy'
1>..\..\SimulationController\src\ScElementSim.cpp(123): error C2039: 'ePARTICLE_PACKET': is not a member of 'physx::Sc::ElementType'
1>  e:\physx-3.4\physx_3.4\source\simulationcontroller\src\ScElementSim.h(49): note: see declaration of 'physx::Sc::ElementType'
1>..\..\SimulationController\src\ScElementSim.cpp(123): error C2065: 'ePARTICLE_PACKET': undeclared identifier
1>..\..\SimulationController\src\ScElementSim.cpp(123): error C2086: 'char PxCompileTimeAssert_Dummy[1]': redefinition
1>  E:\PhysX-3.4\PxShared\include\foundation/PxPreprocessor.h(485): note: see declaration of 'PxCompileTimeAssert_Dummy'

This happens only when PCM contact generation is enabled. After re-enabling legacy contact generation by clearing the PxSceneFlag::eENABLE_PCM flag, everything works fine.

Hi

I'm trying building in target for android under windows, using tegra-toolkit. how build it?

ndk-build returned "Could not find application project directory"

Hi,

We are having an assert in function SphereAABBTest_SIMD::operator() during an overlap query.
When passed an empty box ( mCenter{x=0.000000000 y=0.000000000 z=0.000000000 }, mExtents {x=-8.50705867e+037 y=-8.50705867e+037 z=-8.50705867e+037 } ), the function produces an INF value and triggers the assert.

Based on comments in BucketPrunerCore::removeObject :

"Queries against empty boxes will never return a hit"

So it seems to be valid to test an empty box.
When ignoring the assert the function return the correct result ( false ).

Since this seems a valid case and it returns a correct result, I'd say this assert should not trigger.

Here is our callstack :

PhysX64_d.dll!physx::shdfnd::aos::FIsGrtrOrEq(const __m128 a, const __m128 b) Line 671	C++
PhysX64_d.dll!SphereAABBTest_SIMD::operator()(const physx::Sq::BucketBox & box) Line 1741	C++
PhysX64_d.dll!processBucket<1,SphereAABBTest_SIMD>(unsigned int nb, const physx::Sq::BucketBox * baseBoxes, physx::Sq::PrunerPayload * baseObjects, unsigned int offset, unsigned int totalAllocated, const SphereAABBTest_SIMD & test, physx::Sq::PrunerCallback & pcb, unsigned int minLimitInt, unsigned int maxLimitInt) Line 1621	C++
PhysX64_d.dll!BucketPrunerOverlapTraversal<SphereAABBTest_SIMD,1>::operator()(const physx::Sq::BucketPrunerCore & core, const SphereAABBTest_SIMD & test, physx::Sq::PrunerCallback & pcb, const physx::PxBounds3 & cullBox) Line 1696	C++
PhysX64_d.dll!physx::Sq::BucketPrunerCore::overlap(const physx::Gu::ShapeData & queryVolume, physx::Sq::PrunerCallback & pcb) Line 2071	C++
PhysX64_d.dll!physx::Sq::ExtendedBucketPruner::overlap(const physx::Gu::ShapeData & queryVolume, physx::Sq::PrunerCallback & prunerCallback) Line 683	C++
PhysX64_d.dll!physx::Sq::AABBPruner::overlap(const physx::Gu::ShapeData & queryVolume, physx::Sq::PrunerCallback & pcb) Line 311	C++
PhysX64_d.dll!physx::NpSceneQueries::multiQuery<physx::PxOverlapHit>(const physx::MultiQueryInput & input, physx::PxHitCallback<physx::PxOverlapHit> & hits, physx::PxFlags<enum physx::PxHitFlag::Enum,unsigned short> hitFlags, const physx::PxQueryCache * cache, const physx::PxQueryFilterData & filterData, physx::PxQueryFilterCallback * filterCall, physx::BatchQueryFilterData * bfd) Line 802	C++
PhysX64_d.dll!physx::NpSceneQueries::overlap(const physx::PxGeometry & geometry, const physx::PxTransform & pose, physx::PxHitCallback<physx::PxOverlapHit> & hits, const physx::PxQueryFilterData & filterData, physx::PxQueryFilterCallback * filterCall) Line 115	C++

I think this should be getRelativeAngularVelocity().magnitude() instead of getRelativeAngularVelocity().x ?

In the tests I've done in an older version of PhysX, the ".x" solution worked only if revolute joint axis was (1,0,0), but once it was changed to another direction, then I had to use ".magnitude()".

Please check,

Thanks

Hi,

I'm getting an compilation error for Android:

PhysX/Source/LowLevelCloth/src/neon/NeonSolverKernel.cpp:43:55: error: unknown type name 'PxProfileZone'; did you mean 'profile::PxProfileZone'?
                      IterationStateFactory& factory, PxProfileZone* profileZone)
                                                      ^~~~~~~~~~~~~
                                                      profile::PxProfileZone
../PhysX/Source/LowLevelCloth/include\Factory.h:44:7: note: 'profile::PxProfileZone' declared here
class PxProfileZone;

I think this should be profile::PxProfileZone instead of PxProfileZone ?

However even after the fix, the file won't compile.
I'm trying to use my own compilation toolchain without having to use cygwin.

////////////////////////////////////

Also another problem:
NeonCollision.cpp
NeonSelfCollision.cpp
NeonSolverKernel.cpp
Use __ARM_NEON__ which fails to compile on Android Arm64
__ARM_NEON should be used instead.
See here:
openwall/john#1998

You already test for it in
PxPreprocessor.h:

#if defined(_M_ARM) || defined(__ARM_NEON__) || defined(__ARM_NEON)
#define PX_NEON 1

so perhaps the header should be included and PX_NEON tested instead?

I used APEX 1.3 from NVIDIA Download center. For some reason, I required to use APEX 1.4.
I go to /PhysX-3.4-master/Apex_1.4/bin, but there is no any executable files, only dll files. Could someone tell me how can I get executable file? In 1.3, I used "ClothingToolCHECKED" in a bin folder

When I set
Visual Studio 2017 - Windows XP (v141_xp) platform toolset
or Visual Studio 2015 - Windows XP (v140_xp)
Then this compiles with error, because the <VersionHelpers.h> header is not available, which means that this check #if _MSC_VER >= 1800 is not good enough

Whenever running in debug or release the Android x86 builds of PhysX generates a SIGSEV in Sc::ShapeSim::getAbsPoseAligned in the call to Cm::getStaticGlobalPoseAligned. PhysX was build with NDK-11rc on Ubuntu 17.04. Is NDK 11rc supported or just 9D as mentioned in the Android build html docs? I've been getting errors building the ARM version so I cannot verify if this is an x86 only issue.

I want to ask if there is a way i can just use the collision detection of a scence without use the pyshics solver. I want to know how can i use the collision detector on physX, take this information, aind then, implement the phisics solver by my own with the information retrieved from the physX collision detector.

Since updating to 3.4 I'm experiencing an access violation whenever I remove a dynamic rigid body from the simulation, either by changing it's eDISABLE_SIMULATION flag state, or when I delete the actor. Only occurs when I build in Release mode for x64 targets; all other combinations don't experience this issue.

The calling code seems related to touch events, but the problem occurs even if there is no simulationEventCallback set and eNOTIFY_TOUCH_FOUND/eNOTIFY_TOUCH_LOST are not included in filter pair flags. Also doesn't matter what form of CCD I'm using (or lack thereof), or if I'm using GPU rigid bodies or broad phase.

Access violation:
Exception thrown at 0x00007FFE9D6B483E (PhysX3_x64.dll) in Bricks.exe: 0xC0000005: Access violation writing location 0x0000000000000002. occurred
(in ScNPhaseCore.cpp, line 2171)

Stack trace:

(sidebar: if anyone can tell me a less clunky way of sharing a stack trace for Visual Studio's debugger, I'd be grateful!)

Memory dump:
https://drive.google.com/file/d/0B6cTOEVTlAMJVHhadkV4NGlZREE/view?usp=sharing

I get these two errors when trying to build with VS2015 in Win32 Debug mode:

cannot open input file './Win32/LowLevelCloth/debug/avx/SwSolveConstraints.obj'	LowLevelCloth
cannot open file 'E:\PhysX-3.4\PhysX_3.4\Lib\vc14win32\LowLevelClothDEBUG.lib'	PhysX

Picture:

In my opinion keeping version names in folders is generally a bad idea.
I'm an engine developer working on integrating PhysX into my engine.
I need to have several hard coded paths to the physx folder:
-compiler include directories for headers
-linker include directories/files for compiler libraries
-my own toolchain for physx compilation

So when you release a future update, PhysX 3.5 or another, I would have to set it all up again.
My current workaround is I already rename the "PhysX_3.4" to "PhysX" by myself in the builder toolchain application to avoid this problem in the future. But I would prefer to have consistency between my toolchain and what's present in the official SDK.

Thank you

I'm attaching a print screen from Visual Studio showing callstack and some of the local variables.

It seems that 'interaction' variable points to a broken memory location ( mIterationType field has a value of 0x57 which is far beyond allowed enum range ).
I think the crash happens when one of the of the jointed bodies is removed at the same time when joint breaks. It's very hard to reproduce and I'm just guessing what might be the reason. We are now trying to reproduce this bug with asserts and checks turned on.

I looked for .apb specifications and found this in sources (also in previous versions of APEX):

But neither page, nor subdomain are exists.
Where I can find this information (if it open)?

Olders version had support for double precision trough PxReal. Are there any plans to reintroduce it ?

I get repeatable crashes (in debug) when just doing the following:

setRigidBodyFlag(physx::PxRigidBodyFlag::eKINEMATIC, true);
setRigidBodyFlag(physx::PxRigidBodyFlag::eUSE_KINEMATIC_TARGET_FOR_SCENE_QUERIES, true);

If I swap the order of these lines then it doesn't crash.

While in a level, the size of NPhaseCore::mInteractionMarkerPool continues to increase over time. After 15 mins or so, we're looking at > 2^16 elements. This cleans itself up when we leave the level and all PhysX actors are released. Our test case has about 32 rigid dynamics bouncing around and probably another 32 moving rigid kinematics. Lots of rigid statics.

Concurrently, we have an ActorSim whose mInteractions end up exceeding 65535, which causes a crash due to issue #12

doing "make release", gives:

greg@greg-VirtualBox:~/Desktop/Esenthel/ThirdPartyLibs/PhysX/PhysX/Source/compiler/linux64$ make release
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/PsAllocator.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/PsAssert.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/PsFoundation.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/PsMathUtils.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/PsString.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/PsTempAllocator.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/PsUtilities.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixAtomic.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixCpu.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixFPU.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixMutex.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixPrintString.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixSList.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixSocket.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixSync.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixThread.cpp...
PxFoundation: compiling release ./../../../../PxShared/src/foundation/src/unix/PsUnixTime.cpp...
building ../../../../PxShared/bin/linux64/libPxFoundation_x64.so complete!
PxPvdSDK: compiling release ./../../../../PxShared/src/pvd/src/PxProfileEventImpl.cpp...
In file included from ./../../../../PxShared/src/pvd/src/PxProfileEventImpl.cpp:31:0:
./../../../../PxShared/src/pvd/src/PxProfileEvents.h: In function ‘physx::profile::EventStreamCompressionFlags::Enum physx::profile::findCompressionValue(uint64_t, physx::profile::EventStreamCompressionFlags::Enum)’:
./../../../../PxShared/src/pvd/src/PxProfileEvents.h:125:4: error: this statement may fall through [-Werror=implicit-fallthrough=]
    if ( inValue <= UINT8_MAX )
    ^~
./../../../../PxShared/src/pvd/src/PxProfileEvents.h:127:3: note: here
   case EventStreamCompressionFlags::U16:
   ^~~~
./../../../../PxShared/src/pvd/src/PxProfileEvents.h:128:4: error: this statement may fall through [-Werror=implicit-fallthrough=]
    if ( inValue <= UINT16_MAX )
    ^~
./../../../../PxShared/src/pvd/src/PxProfileEvents.h:130:3: note: here
   case EventStreamCompressionFlags::U32:
   ^~~~
./../../../../PxShared/src/pvd/src/PxProfileEvents.h: In function ‘physx::profile::EventStreamCompressionFlags::Enum physx::profile::findCompressionValue(uint32_t, physx::profile::EventStreamCompressionFlags::Enum)’:
./../../../../PxShared/src/pvd/src/PxProfileEvents.h:153:4: error: this statement may fall through [-Werror=implicit-fallthrough=]
    if ( inValue <= UINT8_MAX )
    ^~
./../../../../PxShared/src/pvd/src/PxProfileEvents.h:155:3: note: here
   case EventStreamCompressionFlags::U16:
   ^~~~
cc1plus: all warnings being treated as errors
Makefile.PxPvdSDK.mk:179: recipe for target 'build/PxPvdSDK_release/PxShared/src/pvd/src/PxProfileEventImpl.cpp.o' failed
greg@greg-VirtualBox:~/Desktop/Esenthel/ThirdPartyLibs/PhysX/PhysX/Source/compiler/linux64$ 

PhysX-3.4/Source/Common/src/CmUtils.h line 139:
(owner.*realloc)(mData, mCapacity, mSize, PxU16(mSize+1));

This is causing a crash when the number of elements exceeds 65535 for arrays templated with IndexType PxU32 (which is the case for ScActorSim::mInteractions), due to the casting of (mSize+1) to a PxU16.

I've been playing around with GPU rigid bodies in a sandbox application, and every so often I experience a soft-crash when modifying many rigid bodies at once (between simulation ticks). You can see an example of it occurring in this video (I get it to occur at 1:21, but watch from at least 1:00 for context). It doesn't happen very often (say, 1 in 30 times doing the above), but when it does it brings down PhysX entirely.

You can see the error log spam in the error console after it occurs, but the very first errors reported are:

[PxgNarrowphaseCore.cpp:1039] memcpy failed fail! 2  700
[PxgNarrowphaseCore.cpp:1049] GPU cudaMainGjkEpa or prepareLostFoundPairs kernel fail!
  700
[PxgNarrowphaseCore.cpp:1274] memcpy failed fail!
  700
[PxgCudaUtils.h:53] SynchronizeStreams failed
[PxgCudaSolverCore.cpp:1021] GPU contactConstraintPrepare fail to launch kernel!!

The 'grenade explosion' is a fairly simple loop over all dynamic rigid bodies and adding force based on their distance and direction from the point of origin (source). I haven't seen the same/similar issue with GPU rigid bodies disabled.

The relevant code is linked above, but [here's the sandbox] I'm using in the video.

Hi,

When passing from legacy heightfields to unified heightfields we stumbled on the assert PX_ASSERT(inds[0] == vertIndices[a] || inds[1] == vertIndices[a] || inds[2] == vertIndices[a]); in PCMHeightfieldContactGenerationCallback::onEvent
Here is the call stack :

PhysXCommon64_d.dll!physx::Gu::PCMHeightfieldContactGenerationCallback<physx::PCMConvexVsHeightfieldContactGenerationCallback>::onEvent(unsigned int nb, unsigned int * indices) Line 164	C++
PhysXCommon64_d.dll!physx::Gu::HeightFieldUtil::overlapAABBTriangles(const physx::PxTransform & pose, const physx::PxBounds3 & bounds, unsigned int flags, physx::Gu::EntityReport<unsigned int> * callback) Line 929	C++
PhysXCommon64_d.dll!physx::Gu::PCMContactConvexHeightfield(const physx::Gu::PolygonalData & polyData, physx::Gu::SupportLocal * polyMap, const __m128 & minMargin, const physx::PxBounds3 & hullAABB, const physx::PxHeightFieldGeometry & shapeHeightfield, const physx::PxTransform & transform0, const physx::PxTransform & transform1, float contactDistance, physx::Gu::ContactBuffer & contactBuffer, const physx::Cm::FastVertex2ShapeScaling & convexScaling, bool idtConvexScale, physx::Gu::MultiplePersistentContactManifold & multiManifold, physx::Cm::RenderOutput * renderOutput) Line 164	C++
PhysXCommon64_d.dll!physx::Gu::pcmContactConvexHeightField(const physx::Gu::GeometryUnion & shape0, const physx::Gu::GeometryUnion & shape1, const physx::PxTransform & transform0, const physx::PxTransform & transform1, const physx::Gu::NarrowPhaseParams & params, physx::Gu::Cache & cache, physx::Gu::ContactBuffer & contactBuffer, physx::Cm::RenderOutput * renderOutput) Line 224	C++
PhysX64_d.dll!physx::PxcPCMContactConvexHeightField(const physx::Gu::GeometryUnion & shape0, const physx::Gu::GeometryUnion & shape1, const physx::PxTransform & transform0, const physx::PxTransform & transform1, const physx::Gu::NarrowPhaseParams & params, physx::Gu::Cache & cache, physx::Gu::ContactBuffer & contactBuffer, physx::Cm::RenderOutput * renderOutput) Line 282	C++
PhysX64_d.dll!discreteNarrowPhase<0>(physx::PxcNpThreadContext & context, const physx::PxcNpWorkUnit & input, physx::Gu::Cache & cache, physx::PxsContactManagerOutput & output) Line 398	C++
PhysX64_d.dll!physx::PxcDiscreteNarrowPhasePCM(physx::PxcNpThreadContext & context, const physx::PxcNpWorkUnit & input, physx::Gu::Cache & cache, physx::PxsContactManagerOutput & output) Line 436	C++
PhysX64_d.dll!PxsCMDiscreteUpdateTask::processCms<&physx::PxcDiscreteNarrowPhasePCM>(physx::PxcNpThreadContext * threadContext) Line 446	C++
PhysX64_d.dll!PxsCMDiscreteUpdateTask::runInternal() Line 519	C++
PhysX64_d.dll!physx::Cm::Task::run() Line 67	C++

Our investigation lead us to functions Gu::HeightField::getTriangleVertexIndices and Gu::HeightField::getTriangleAdjacencyIndices.
There seems to be a confusion between vertexIds, cellIds and trianglesIds.

Let's say for a ( nbRow*nbColumn ) heightfield there is :

- VerticesPerRow = nbColumn
- CellsPerRow = ( nbColumn - 1 )
- TrianglesPerRow = 2 * ( nbColumn - 1) 

But in getTriangleAdjacencyIndices adjacent triangles are calculated by adding/subtracting VerticesPerRow instead of CellsPerRow, making one of the adjacent index wrong by one.
For example :
adjacencyIndex2 = ((cell + mData.columns ) * 2) + 1;
Instead of
adjacencyIndex2 = ((cell + ( mData.columns - 1 ) ) * 2) + 1;

Similarly in getTriangleVertexIndices it is assumed that cellId == VertexId of first vertex in cell for instance :

vertexIndex0 = cell;
vertexIndex1 = cell + 1;
vertexIndex2 = cell + mData.columns;

Instead it should be :

const PxU32 row = cell / ( mData.columns - 1 );
vertexIndex0 = row + cell;
vertexIndex1 = row + cell + 1;
vertexIndex2 = row + cell + mData.columns;

because there is one more vertex per row than there is cells.

There is a few other places I have seen similar errors, you'll find an attached file containing a patch of some of the errors I found ( I only fixed those who triggered when testing there are probably others ).

0001-Heightfield-fixes.zip

It seems that unified heightfields are not safe to use yet, or maybe we missed something in our calculations.

Hi,
I am wondering if the 1.0 format for apx files is avaliable anywhere?
Regards,
Traderain

I'm using my own compilation toolchain, because the included one IMO is overly complicated (requires cygwin,..) whereas my solution just requires NDK installed + running one BAT file.

However in my compilation results I'm getting very big physx binaries.
Arm32 - libPhysX.a 123 MB
Arm64 - libPhysX.a 177 MB

Is this the expected behavior?

I've already excluded KinematicCharacterController, PVD, Serialization.

1. Rename "PhysX_3.4" folder to "PhysX" (see #47)
2. Extract attached ZIP file to the root of the repository NVIDIAGameWorks/PhysX-3.4
3. Edit "Android/build.bat" to specify correct path to the "ndk-build" on your computer
4. Run the BAT file

Feel free to modify/integrate the files into the SDK if you wish.

Android.zip

There is an issue with tracking IDs of the actors. The following function is used to obtain ID for every actor added to scene:

		PxU32	getNewID()
		{
			// If recycled IDs are available, use them
			const PxU32 size = mFreeIDs.size();
			if(size)
			{
				// Recycle last ID
				return mFreeIDs.popBack();
			}
			// Else create a new ID
			return mCurrentID++;
		}

If we take a closer look to this function we would see that ids are recycled from list of free ids. If there is a free id in mFreeIDs buffer , then new actor will obtain the id of the last removed actor (every id of the removed actor is added at the end of the mFreeIDs buffer (as we can see in void freeID(PxU32 id) method).
Now if we have a situation when we remove actor from scene and then we add a new actor, the new actor takes an id of the the removed actor. According to this we can get PxContactPairHeaderFlag::eREMOVED_ACTOR_x flag in PxContactPairHeader raised for both actors.
As we can see:

PxU16 headerFlags = 0;
	if (RigidIDTracker.isDeletedID(aPair.getActorAID()))
		headerFlags |= PxContactPairHeaderFlag::eREMOVED_ACTOR_0;
	if (RigidIDTracker.isDeletedID(aPair.getActorBID()))
		headerFlags |= PxContactPairHeaderFlag::eREMOVED_ACTOR_1;

scene just simply checks if actor id is in deleted ids.

I find a use simulate(1/60.f) and simulate(1/6000.f), they produce two difference result.

				*dest++ = trig16[0];
				*dest++ = trig16[1];
				*dest++ = trig16[2];

should be replaced with;
*dest++ = *trig16;

Hey guys, I follow the compile instructions and build libs successfully for vc14x64. It works well when I run snippets. However, When I build a new win32 console project on VS2015(include ..\PhysX_3.4\Include and ..\PhysX_3.4\Lib\vc14win64) and try to run following source code:

#include "PxPhysicsAPI.h"

#include

using namespace std;
using namespace physx;

int main()
{
PxVec3 v(0, 0, 0);
cout << "Hello World" << endl;
return 0;
}

There are thousands of compile errors:

Severity Code Description Project File Line Suppression State
Error (active) member "PxControllerDesc::PX_INLINE" is not a type name Test c:\Users\gzzhengqingxin\Desktop\TASK\PhysX-3.4-master\PhysX_3.4\Include\characterkinematic\PxBoxController.h 56
Error (active) member function with the same name as its class must be a constructor Test c:\Users\gzzhengqingxin\Desktop\TASK\PhysX-3.4-master\PhysX_3.4\Include\characterkinematic\PxBoxController.h 56
Error (active) this declaration has no storage class or type specifier Test c:\Users\gzzhengqingxin\Desktop\TASK\PhysX-3.4-master\PhysX_3.4\Include\characterkinematic\PxBoxController.h 57
Error (active) expected a ';' Test c:\Users\gzzhengqingxin\Desktop\TASK\PhysX-3.4-master\PhysX_3.4\Include\characterkinematic\PxBoxController.h 57
Error (active) member "physx::PxBoxControllerDesc::PX_INLINE" is not a type name Test c:\Users\gzzhengqingxin\Desktop\TASK\PhysX-3.4-master\PhysX_3.4\Include\characterkinematic\PxBoxController.h 67
Error (active) expected a ';' Test c:\Users\gzzhengqingxin\Desktop\TASK\PhysX-3.4-master\PhysX_3.4\Include\characterkinematic\PxBoxController.h 67

HELP! HELP! Am I missing something important????

Severity Code Description Project File Line Suppression State
I'm unable to build PhysX
this is the path of the sln file

PhysX_3.4\Source\compiler\vc14win64

Original issue:
https://github.com/NVIDIAGameWorks/PhysX-3.3/issues/21

PxMeshScale with negative scale is now supported for PxTriangleMeshGeometry.
This is nice, it allows to reuse same mesh for both normal and mirrored objects.

But this does not work for PxConvexMeshGeometry, is there a reason not to allow it?
It seems to me that it might be omitted by accident.

Visual Studio 2015 / 32bit / Debug

Usage:
  -msaa            Do MSAA Antialiasing (Slower, but better quality). On by default.
  -fxaa            Do FXAA Antialiasing (Faster, but poorer quality)
  -nbThreads n     Use n worker threads in PhysX
  -nossao          Disable SSAO
  -nhdr            Disable HDR
  -grb             Use GRB (default is on)
  -nogrb           Use software PhysX
  -maxSubSteps n   Enable up to n sub-steps per-frame.
  -vsync           Enables vsync (off by default)

Got 32 depth bits expected 24
Compiler error
Vendor: ATI Technologies Inc.
Renderer: AMD Radeon (TM) R9 390 Series
Version: 4.5.14008 Compatibility Profile Context 21.19.137.514
Error: Vertex shader failed to compile with the following errors:
ERROR: 1:1: error(#430) uniforms initialization is not allowed in GLSL 1.10.
ERROR: error(#273) 1 compilation errors.  No code generated


GL error: ..\..\sampleViewer3\HBAOHelper.cpp, line 109: GL_INVALID_OPERATION
Assertion failed: destinationLength == 0, file ..\..\sampleViewer3\Shader.cpp, line 695

APEX Project settings for Visual Studio 2015 contains macro EXCLUDE_PARTICLES=1.
Does it mean that particles are not allowed in current version of ApexSDK?

Just asking if precompiled PhysxGPU.so libraries in bin\linux64 folder support new 3.4 "GPU rigib bodies" feature?
Also as you support CUDA in Macos and ship other libs using it in Macos like Optix make sense to expose also GRB support in Macos by having PhysxGPU.dylib libraries? even with unofficial support from Nvidia?
thanks..