After creating a convex mesh actor above the terrain and apply a small linear velocity to the body, the object reverts to its cooked orientation and falls through the terrain. Simple geometric ( box, sphere and capsule ) actors react correctly.
Could you please post a PhysX Visual Debugger capture?
Thanks,
Mike
I’ve attached an sample PVD capture, this time however, I’m using a box actor, those seem to fall through as well.
boxthroughterrain.zip (4.51 MB)
Hi
- why dont you use a newer version of PhysX - maybe there was a issue in your version.
Most recent is 3.2.4.
Update: Now your PVD works.
Hm. Its seems very strange - I didnt saw the forces, but did you add multiply forces after it should
touch the PxHeighfield? ( It rotated strange…)
As I saw there was no contacts in the PVD
(but I didnt have enough time and knowledge about PVDs to prove it!)
Maybe you cooked your PxHeighfield wrong - or… your timestep is wrong.
I actually had for almost one year a similar issue with a ragdoll and every PxActor, ( randomly after large framedrops )
due to the fact that I didnt use a semi fixed timestep. ( Old code ) After I´ve fixed it, everything was working fine.
Currently I’m doing cross-platform development ( Windows + Linux + Android ), and updating to 3.2.4 with only Windows support wouldn’t help since I want all platform to be on the same version especially for testing purposes.
The box was created above the terrain in a sleeping state. The box is then awaken ( via user input ). No force is added to the box so the only force that should be acting on the box in the simulation would be gravity. I have a previous version on the software that works correctly with the same setup with the only exception being the presence of a contact filter shader for the scene. Stepping through the code, indicates that the simulation is detecting the collision.
My filter shader implementation is posted below:
physx::PxFilterFlags PxSimulationFilterShader( physx::PxFilterObjectAttributes attributes0, physx::PxFilterData filterData0,
physx::PxFilterObjectAttributes attributes1, physx::PxFilterData filterData1,
physx::PxPairFlags& pairFlags, const void* constantBlock, physx::PxU32 constantBlockSize)
{
pairFlags |= physx::PxPairFlag::eRESOLVE_CONTACTS;
pairFlags |= physx::PxPairFlag::eSWEPT_INTEGRATION_LINEAR;
pairFlags |= physx::PxPairFlag::eCONTACT_DEFAULT;
pairFlags |= physx::PxPairFlag::eTRIGGER_DEFAULT;
return physx::PxFilterFlag::eDEFAULT;
//return physx::PxFilterFlags();
}
Hi,
oh, I see thats not possible to change to 3.2.4.
Hm. How do you update your PhysX simulation?
As I said before, when you update in the wrong way - it works often.
But … randomly its make undesired thinks like object fall through the ground etc.
Could you show us how you update your Physx?
I’m updating the simulation just like in the SDK user guide. The Windows version is a where I made some recent changes. The Linux version without the changes works fine. I enabled CCD and added a filter shader to the Windows version, the Linux version is using the default filter shader. Even when I switched to the default filter shader it still doesn’t work. The filter shader callback listed above get hit upon initial contact (verified in the debugger ), then it seems as if collision is disabled afterwards. No response seems to get calculated which I’m assuming should happen if I added eRESOLVE_CONTACTS to the pair flag. The terrain is of type RigidStatic and the box is of type RigidDynamic ( non kinematic ) if that helps.
Finally solved this issue. The culprit was setting the thickness of the terrain. The thickness value was counter-intuitive to me. I was assuming positive values for thickness would extend from above the terrain to below the terrain, but it seems to be reversed…or my understanding of the value is still reversed…lol. Setting thickness to the negative of what I wan the thickness to be resolved the issue.
Hi
Thats great news. Its also a little bit funny which cause the issue.
Maybe the terrain is upside down so you have to use negative values. ( strange? )
Anyway have fun with your new working PxHeightField :)
Thanks…its impossible to have the terrain upside since, all that is passed to the SDK is the heightfield, not a tri-mesh. I could see being not rotated correctly around the up axis which use to be the case ( just needed to switch the rows with the columns ).
Hi.
Okay. But do you have any problems with that?
Or is everything working fine?
Everything thing else works fine…thanks for all your help…always good to have a different outlook.