The PhysX Project

[genetransfer]

awsome! on the rope issue streching, UDK has physx and in there editor they have a setting I think it was enable projection or something but it was a joint setting that allows for the actual visual to hold it's correct position even if the body joints are stretched past thier limits. haven't looked into physx but there might be a setting in there somewhere to deal with it unless udk made thier own workaround.

one thingg I'm curious about is when you pick up an object with the mouse and you use the mouse wheel to move it around. how is it linked to the offset. does it create a joint/spring between the body and an offset from the camera or are you setting the location of that body. just wondering as when you move the body around with the mouse it can still collide with the world objects yet seems to hold it's position very accuratley. just wondering how that's being done. as I can't find a way in ODE so far to move a physics body with that kind of speed and accuracy. thanks!

[Allan]

@genetransfer:
Your 1st point ......
The stretching of spherical joints in 'rope'  objects is definitely something I must investigate more fully. From what I have briefly read in the PhysX Forums it does seem to be a generally experienced problem. A rope or chain should be inelastic and snap when a certain force limit is exceeded. Unless the 'rope' is meant to be elastic, I would like to avoid adjusting or stretching the visual mesh in any way.

Your query.......
I am applying a directional force to the selected object which is proportional to the offset of the 3D projected mouse cursor position from the 3D centre of the object. Appropiate linear and angular dampening is applied to the object as it is being manipulated. Also, the normal cos/sin adjustments must be made to the X and Z force components,depending on the camera angle around the Y axis.

Thank you for the feedback!

[shadmar]

Wow this is really interesting Allan. I really liked the demos, they all ran smoothly on my system.

Dell laptop 1530 XPS, 4 GB
Geforece 8600M GT, 256mb
Running 7 Pro, 64bit OEM

I might have to install 3Impact and have a look.
Does this mean that its possible to integrate this in rad ?
Anyway I have to keep an eye in here now, you are/were the physics professor in 3drad.

[Allan]

Hi Shad! Welcome to 3Impact..................good to "see" you here!

Ja, I'm just taking a small break from 3DRad, investigating its parent and how it handles PhysX.........pretty good so far!

As far as integrating into 3DRad? ........we'll have to pass that question onto Fernando.

No matter where I am I'll always be the physics professor !

[Developer - Fernando]

In theory, if we can create a system (a set of functions), based on Physx, which allows us to 'wrap' all 3Impact functions that involve physics (eg iBodyCreate(), iJointCreate(), iWheelCreate() etc), then 3D Rad (and all its objects) can simply be slightly modified to use the wrapped functions, to actually switch to Physics.

But this may not be as easy as it sounds. Still, given the advantages provided by Physx over ODE, it would certainly be a BIG 3D Rad improvement!

[shadmar]

Sounds great and expensive.

[Allan]

PhysX_Test07 demonstrates the spring action of a 6DOFJoint.

The 6DOFJoint has been configured as a translational joint with movement restricted to the Y axis. By specifying a spring force in its creation, this lateral movement can be limited by the strength of the spring. The joint links together a kinematic base block actor(fixed to the ground) and a dynamic block actor, which is what springs up and down.

Using the LMB and dragging down the top block on the spring, then releasing the LMB, demonstrates the spring action. Placing the small box on top of the spring will result in the expected projectile action !

The syncronization between the visual spring and the PhysX invisible spring is not 100%, but this is probably due to the fact that the visual spring is made up of a series of frames which display according to the height of the PhysX spring at any instance.

[Mike]

Allan,

Looking fantastic.

Just doing some reading up on the Physx. But runs excellent on my Machine.

Mike

[shadmar]

Allan Test7 works excellent.
How is collision here, it can't be sphere based ? Boxes stacks really nice without floating or sinking in corners.

[Allan]

Actually, shadmar, none of the actors (or rigidbodies, in 3DRad/3Impact terms) that I've used in these tests are sphere-based. Except, of course, the spheres themselves. That's what I like about PhysX.........the 4 main rigidbody primitives (sphere, box, capsule and plane) are complete, single rigidbodies. They can be combined in any way to make up more complex multishape rigidbodies (or actors, in PhysX terms). I guess that the closest PhysX actor to a 3Impact sphere-based rigidbody, is the Convex Hull actor..........but FAR easier to define (see the teapot in Test4).......you just have to enclose your object in a hull........no fiddling around with a bunch of spheres!

Therefore........as you mentioned.......there will be none of the floating or sinking corners that you get in sphere-based rigidbodies.