PhysX 3.x Plugin

#121 Triangle mesh's with multiple materials are now done. I'll provide Timmy with the code in a few days, just gotta find it all and package it. Please credit Glenn S. and myself if you wouldn't mind Timmy!

Also static shape collision won't be hard, I might throw that in too before i send it off to Tim (something I need regardless, why not do it)

Finally contributing something, it's about time from me haha.

@Tim/Andrew is there a way to enable smooth sphere collisions like physX 2 and unity have?

- Jeff

#122 With the credit of work done, take a look at the cloth stuff and just copy what andrew has done in the license text.

Is the static shape collision not currently working? I thought i tested that before but obviously not.

*Edit:

You guys are talking about StaticShape datablock huh? I was confusing it with tsStatic class.

#123 ya the staticShape class, not TSStatic. sorry for not specifying.

#124 @Paul Weston:

You where talking about StaticShape too and not tsStatic class?

Either way adding collision support to StaticShape should be simple enough, once i get stupid ms excel to stop crashing everytime i save, i can finish the benchmark results & i'll get to it ;-)

#125 If anyone could give me some guidance I'd be very thankful. I'm trying to create a ragdoll shape. I create a new ShapeBase class, give it a mesh (player), add some PhysX shapes to it (PxSphericalJoint, PxRigidActor) and then every frame the PhysX updates I move the nodes on the ShapeBase mesh, based on the PhysX positions? Does this sound correct?

#126 Yes I meant StaticShape :)

The PathShape resource creates a new object type - PathShape() which is a static shape and thus does not collide in PhysX.

Thanks so much for offering to fix that up, and the vehicles too... I will watch the thread eagerly for updates.

This community continues to deliver in spades, great job everybody!

Think I may have just built the next huge game sensation with this, stay tuned lol.

Cheers
P

#127 @aussiemandias:
Yeah that does sound like you are heading in the direction. When you update the mesh with the physx positions how are you doing that? Just a code snippet should be good enough

#128 I have updated the repo with support for physics representation of the StaticShape. It will now contain two new fields for the datablock

enablePhysicsRep (default true)
collisionType (default "Collision Mesh")

Collision types:
"None"
"Bounds"
"Collision Mesh"
"Visible Mesh"

This was all copied from tsStatic class so it should be fairly consistent with that.

I must admit i have done very little testing of this, do report any problems if you find any.

#129 Now that both tsStatic and StaticShape have enablePhysicsRep added to them, i am beginning to think that maybe they should both be disabled by default because this is changing the way they both fundamentally work and anyone trying out the physx branch my get a bit of a surprise as this does change the default behaviour compared to what they would be used to with the stock T3D.

Thoughts anyone?

#130 The shape in my code doesn't seem to be drawing properly in the debug mode (the box is invisible). It's a little hard to see but it's 1x1x1 underneath the white player.



As you can see my render mesh is ontop of the box, but the Px3Player is not? So I can walk on it, but nothings showing up? Here's how I create it.

pastebin.com/jAr0ZNbC

I copied most of it from Px3Body. Anything obvious I'm doing wrong?

#131 Wow, you guys are awesome!

Confirmed that the Static Shape collision is working now... However there is a little quirk with the PathShapes.

These are derived from StaticShape, so for the most part work fine now - when at rest, the platforms are solid and the player collides with them. The player can jump on top, and the console confirms that the PathShape attach code is trying to fire... But when the PathShape starts moving, the player falls through and cannot get back on. The attach code is broken somehow, perhaps because it is based on a raycast looking down (and I saw elsewhere that PhysX player raycasts need to be done a certain way).

In our original build, we had this same code in place for both players and vehicles, so we could move them up and down on elevators. As it stands, I can still stick a vehicle to the platform and it stays stuck, it's just the player that is not sticking.

Here is the relevant code from player.cpp, where the PathShape resource attempts to attach the player to the platform. Can anyone please guide me on the correct syntax for a PhysX raycast here, if that is what is required?

// PATHSHAPE   GAMBITREALM
// This Function does a ray cast down to see if a pathshape object is below
// If so, it will attempt to attach to it.
void Player::updateAttachment(){
   Point3F rot, pos;
    RayInfo rInfo;
    MatrixF mat = getTransform();
    mat.getColumn(3, &pos);
    if (gServerContainer.castRay(Point3F(pos.x, pos.y, pos.z + 0.1f),
        Point3F(pos.x, pos.y, pos.z - 1.0f ),
        PathShapeObjectType, &rInfo))
    {
       if( rInfo.object->getTypeMask() & PathShapeObjectType) //Ramen
       {
          if (getParent() == NULL)
          { // ONLY do this if we are not parented
             Con::printf("I'm on a pathshape object. Going to attempt attachment.");
             ShapeBase* col = static_cast<ShapeBase*>(rInfo.object);
             if (!isGhost())
             {
                this->attachToParent(col);
             } 
          }
       }
       else
       {
          Con::printf("object %i",rInfo.object->getId());
       }
    }
    else
    {	 
       if (getParent() !=NULL)
       {
          clearProcessAfter();
          attachToParent(NULL);
       }
    }
}
// PATHSHAPE END

I also have another bit of code elsewhere with a similar issue, can't get it to work in PhysX because of the raycast syntax - need to know how to do a PhysX raycast so I can put in an If/Else statement in these bits of code.

Thanks again, so great to have new advances every day here!

Oh and Andrew, thanks for letting me know about the Cloth being a standard TSStatic with a flag, I'll give it a try.

Cheers
P

#132 @Aussiemandias:

Try using the PhysX Visual Debugger(PVD) developer.nvidia.com/physx-visual-debugger. The way the plugin is setup it will only work in debug build. It's a great tool to visualize the scene as PhysX sees it. On tip for PVD is to set the coordinates->up axis to Z+ in the preferences will save you having to do any funky camera rotations ;-)

Just quickly looking at your code nothing obvious is sticking out that you might be doing wrong.

@Paul

To cast a ray using physics, just use PHYSICSMGR to grab the appropriate physics world and there is an overloaded castRay function. Much cleaner this way rather than accessing physx directly.

I'll go back over the code a bit more and do some testing, i was rather hurried yesterday and didn't even test the PathShape.

#133 @Timmy and Paul

That is most likely because the shape is not kinematic. When you have moving objects, they should be kinematic and use the moveTo functions in physX instead of setTransform. A little more coding on someones part now hehe. moveTo calculates a velocity while setTransform doesn't calculate a velocity, ignoring dynamic collisions. At least thats what i did back in the day of PhysX 2.8 with Torque.

Edit: didn't realize that this mounts an object to a moving object, maybe I should have retracted what i said and just use raycasts like you said...(read those posts wrong) still it might be a good idea to implement kinematic moveTo functions or whatever they are called.

#134 Oh yeah on another note, I have got the default vehicles working when a physics plugin is active :-), there are a few issues i'm still working through but it does work.

Aah yes, jeff is correct. In fact the code i posted yesterday never updates the physics bodies position either, i'll take a look later on.

#135 Tim you ninja'd me lol.

Awesome work btw c:

#136 Haha i think we both did

#137 With some of these changes going on, a few of the updates now are not entirely physx based but rather physics based (i.e work with all physics plugins) and it's slowly growing further and further from the T3D development branch. I don't really want to just keep creating branch after branch for people to choose from as it's confusing and difficult to maintain.

From the beginning i only really set out to just create a working physx3 plugin(pretty much what the physx3_basic branch is) and now quite a few people have jumped on board and contributed some nice work, admittedly most of this is physx3 based but now some of the stuff is generic physics based.

Any advice/thoughts everyone how we should structure this thing? Do we create yet another branch and call it physics_extended or something and leave physx3 branch for physx3 only stuff? This has the problem that the two branches would than overlap on certain stuff and would be a pain adding stuff to both. Than the big issue is getting some of these changes back into the official T3D, i think some of it would get accepted and maybe some might not?

#138 @Paul:

Hold that thought with the raycasting, the problem jeff mentions is something i completely overlooked (this also affects the vehicle stuff i am doing too). Leave this one with me, i don't think i will be able to solve it without adding extra functionality to the PhysicsBody class actually :-( I'll see what i can do.

#139 They'll be more information about the goals and directions of the new steering committee soon, but I can tell you now that I'll be heavily advocating full integration of all the PhysX 3.3 code into the main branch. We just need to pick through it and make sure it adheres to all standards and has no impact on existing behavior.

Unless I missed a big change, most of the alterations outside the physx3 folder aren't too far reaching and should be fine for integration after some testing, review and revisions. Or at least I know my code could use some of that, I haven't touched it in a few weeks.

#140 Ok that's good to hear about the committee. Yep, there are no far reaching changes.