PhysX 3.x Plugin

#341 You're awesome,thanks :)

#342 Got it working i'm pretty sure paul. using this script it's firing the echo when i drop a PhysicsRigidShape on a TSStatic at the correct time

function RigidPhysicsShapeData::onCollision(%this, %obj, %col)
{
   if (%col.getClassName() $= "TSStatic")
   {
      echo("Hit TSStatic object");
   }
}

*Edit:
Updated repo, let me know any problems paul.

#343 Wow, excellent! Going to try now will let you know.

#344 What about Bullet Physics, anyone know how that's going? Last I used it, scaling a shape didn't update the collision hull with the scale.

#345 OK, that is really really cool :)

We can now do everything we want in terms of blowing walls apart, etc.

The only thing I noticed that I'm surprised I didn't catch before, is that the mass setting does not seem to have any effect in the new RigidPhysicsShape datablock...

If I drop two physics boulders side by side, one using the standard PhysicsShape and the other the new RigidPhysicsShape, I can make the regular one immovable by increasing mass to 100 - however the RigidPhysicsShape still seems to be stuck at a mass of 1 no matter what I adjust in the datablock, it can be easily rolled using the machine gun.

Would love to have the same control over mass, etc, with the new shapes that we have with the old ones. We could then make different block types do varying amounts of damage when they hit the player, based on their mass (a block of Iron would hurt a lot more than a block of wood for example). Already have mass working on all the blocks in terms of how easy it is to move them, just want to use the same setting to calculate relative damage when a rigidphysicsshape version of the block hits the player.

Other than that, no bugs to report and all collisions seem to be firing as they should with the new RigidPhysicsShape. It's really great to have the two types of shapes to choose from for varying applications.

Thanks again!

#346 @Paul:

Updated repo with a fix for that mass problem, i didn't notice that ShapeBaseData defines it's own mass and this was conflicting with the mass field in RigidPhysicsShape, easy fix :-)

#347 Can you do that any faster? Lol

Super cool, thanks :)

#348 Everything works great!

Here is a quick video showing a new level idea I'm working on, where you have to rush to the top of a large ramp while avoiding falling boulders... you can see the boulders knocking walls over and blowing up C4 blocks and crushing other blocks into pieces, neat stuff :)

https://www.youtube.com/watch?v=rQh9KdCDrmA

#349 nice work paul :-)

#350 Anyone following this physx3 stuff i have changed it around slightly. Now there is two branches only:

Basic: github.com/rextimmy/Torque3D/tree/physx3_basic
Advanced: github.com/rextimmy/Torque3D/tree/physx3_advanced

Advanced is what "testing" branch was before. The testing branch was based off physx3 branch. That was all very confusing and hard for people to follow.

I have decided i will not be keeping the other physics plugins updated anymore in physx3_advanced, it will be physx3 stuff only. Remember physx3_basic will never get any new features, only bug fixes and this branch is due to go into T3D in version 3.7.

#351 *Repo branch update: physx3_advanced

Fixed an issue when moving static physics bodies. This really only applies when you are moving static bodies around in the world editor. Physx3 will complain about it. This should fix that.

#352 Is it a bad idea to move rigid bodies with "setGlobalPose"?

#353 It only applies to static actors. Dynamic actors is fine to use setGlobalPose. With static actors, you just need to remove them from the scene first, than setGlobalPose and than place it back in the scene.

#354 *Repo branch update: physx3_advanced

Replaced the write lock method used.

I apologize to anyone that has any modifications based on physx 3.3 because this may well affect you. The new way to write physx scene information is to first lock the scene for writing, than update "data" and than unlock the scene for writing. Before this update you just simply called releaseWriteLock, than update "data" and left it at that.

Now you must:

// Lock scene for writing - replaces mWorld->releaseWriteLock()
mWorld->lockScene();
// Do something that writes to the scene. E.g:
mActor->setGlobalPose( px3Cast<physx::PxTransform>(transform) ); 
// Unlock the scene - this is new
mWorld->unlockScene();

Also mWorld->ReleaseWriteLocks() (note the s) is now replaced with the equivalent mWorld->lockScenes() and mWorld->unlockScenes()

#355 @Paul:

Would your current project benefit at all from Apex support? I just recently started a project and i am going to be implementing the destruction and particles from the apex module (not doing the clothing). Check here developer.nvidia.com/gameworks-physx-overview.

#356 Wow - you are just rocking along here! Great work!

#357 @Timmy - WOW that looks awesome!!!!!

Yes please :)

Can you explain roughly how that destruction works? Do we just build our models in a certain way and then PhysX can blow them apart?

Would be a huge improvement over just using the standard T3D destructible code that really only just pops an explosion in the place of a destroyed object... In Blockabout, we build certain structures out of blocks that get converted to PhysX objects when hit, so they are already exploding all over the place, but am curious how using this new Apex method could open up new ways of blowing things to pieces :)

Thanks!

#358 Oh, and was wondering if you still had on your radar to maybe look at the player code, to enable impulse forces so we can blast him into the air with grenade explosions, etc?

The explosions currently make all sorts of other PhysX objects respond to the impulse, just not the player who stays put on the ground even if he steps on a proximity mine...

I think it would be a nice feature and would make the player a bit more consistent with how other objects react in the physics engine.

Just a thought, if you have some time :)

Thanks
P

#359 Rather than explain it there are some good vids about it here developer.nvidia.com/apex-destruction-physxlab-tutorials.

It's going to take a little while to integrate it all because it is fairly complicated. Once complete it allows the artist to come up with some pretty cool stuff and they don't need to care about how it works under the hood, it will actually be far easier to get destructible content working.

Sorry i haven't had a chance to do anything in regards to the player ;-)

#360 Cool, thanks for the update, I'll check out those vids :)

P