Anyone had any involvement in implementing rigid body dynamics under Direct3D?

Wow, none of you have EVER simulated physics as far as dynamics is concerned? jeez.. thats kinda slack.

I've not played with physics in years myself, and my most recent physics related code would have been the Particles demo I posted some time ago.

Can you imagine a modern 3D game without a realistic physics engine?

No? Me either.

It's not difficult to impart concepts such as velocity, mass and angular velocity to objects in 3D, the difficulties lay in "collision response".

This problem can be broken down to a series of intersection tests between points and planes - if a collision occurs between two objects, or between an object and a static surface (like the terrain or a wall), we are really talking about one of two major cases: a point on Object A intersects a surface in the world (whether its another object is irrelevant at this point), or, a surface of Object A is intersected by a point in the world (could belong to another object, could belong to terrain etc).

Obviously there's special cases, for example the concurrent intersection of N points (think of a cube at rest on a flat surface - theres 4 points in contact)

This lends itself to my existing intersection codebase, which can be used to test all points of A against all planes of B and vice versa, or perform more specific tests against given points/planes.

I'm thinking of implementing RagDoll Physics as a demo by loading the model from an xfile (skinnedmesh) and then just ripping its bone information into a scenegraph and applying my own rotation limit constraints at the joints, then applying simplistic "rubberbanding" physics as seen in the classic "Thrust" game from the BBC era (elasticity=0).

Have I woken anyone up yet? :)

I've not played with physics in years myself, and my most recent physics related code would have been the Particles demo I posted some time ago.

Can you imagine a modern 3D game without a realistic physics engine?

No? Me either.

It's not difficult to impart concepts such as velocity, mass and angular velocity to objects in 3D, the difficulties lay in "collision response".

This problem can be broken down to a series of intersection tests between points and planes - if a collision occurs between two objects, or between an object and a static surface (like the terrain or a wall), we are really talking about one of two major cases: a point on Object A intersects a surface in the world (whether its another object is irrelevant at this point), or, a surface of Object A is intersected by a point in the world (could belong to another object, could belong to terrain etc).

Obviously there's special cases, for example the concurrent intersection of N points (think of a cube at rest on a flat surface - theres 4 points in contact)

This lends itself to my existing intersection codebase, which can be used to test all points of A against all planes of B and vice versa, or perform more specific tests against given points/planes.

I'm thinking of implementing RagDoll Physics as a demo by loading the model from an xfile (skinnedmesh) and then just ripping its bone information into a scenegraph and applying my own rotation limit constraints at the joints, then applying simplistic "rubberbanding" physics as seen in the classic "Thrust" game from the BBC era (elasticity=0).

Have I woken anyone up yet? :)

YEAH I GUESS WE DID NOT

Guess the 2D shooter with a lookup table doesn't count?

Okay, didn't think so. :)

Okay, didn't think so. :)

2D shooters ALWAYS count - they can't help it :)

The original 'Thrust' was certainly 2D, but that didn't stop it modelling rigid body dynamics :)

The original 'Thrust' was certainly 2D, but that didn't stop it modelling rigid body dynamics :)

I have a .dxf file containing about 3260 meshes exported from poser (a bald woman), I have made a class in java(which easily could be translated to asm) that both loads from .dxf and rotates it, havent had the time to find out that for example meshes 1-300 is left arm, 301-500 is head etc and animate it

no texture, and no idea how to wrap in dx the textures right

actually had a idea to add lots of curved lines with collisiondetection against head/shoulders+apply forces on it (wind/gravity)

so theoretically, shall I think of a single hair=many many lines, gravitymodel=chain, with each part having its downward force+areaversuswind=windforce

sorry my rambling

can you please be more specific what you ask?

you maybe should add a "material class" that contains:

mass

frictioncoffecient

elasticity modul

density

weight(not the same as mass)

etc

simple bouncing when it only comes to 90degree is change xspeed sign if I bounce into one wall in that direction, change yspeed if bounce on "roof","floor" etc

bounce according to normals, like lights?

I for example stand on a metal floor that is tilted 30 degrees, I need to use trigometric to get downwards/forward force

I need to multiply gravity with frictioncoffecient for floor, to get frictionforce, to know if I slide or not

density for right material*volume of object to get a realistic mass, weight for different gravity constants

I also have an idea I tried out in dx, C++, about world model:

I am standing on a disc (sealevel sea) and everything outside this disc is changed with Y, according to (Z-discradius),(curve not linear), creating a worldmodel with horizon=edge of disc, below this disc is clipped out and far behind the "horizon" disc I might see tops of himalaya, but the base of himalaya is hidden below the horizon

no texture, and no idea how to wrap in dx the textures right

actually had a idea to add lots of curved lines with collisiondetection against head/shoulders+apply forces on it (wind/gravity)

so theoretically, shall I think of a single hair=many many lines, gravitymodel=chain, with each part having its downward force+areaversuswind=windforce

sorry my rambling

can you please be more specific what you ask?

you maybe should add a "material class" that contains:

mass

frictioncoffecient

elasticity modul

density

weight(not the same as mass)

etc

simple bouncing when it only comes to 90degree is change xspeed sign if I bounce into one wall in that direction, change yspeed if bounce on "roof","floor" etc

bounce according to normals, like lights?

I for example stand on a metal floor that is tilted 30 degrees, I need to use trigometric to get downwards/forward force

I need to multiply gravity with frictioncoffecient for floor, to get frictionforce, to know if I slide or not

density for right material*volume of object to get a realistic mass, weight for different gravity constants

I also have an idea I tried out in dx, C++, about world model:

I am standing on a disc (sealevel sea) and everything outside this disc is changed with Y, according to (Z-discradius),(curve not linear), creating a worldmodel with horizon=edge of disc, below this disc is clipped out and far behind the "horizon" disc I might see tops of himalaya, but the base of himalaya is hidden below the horizon

My animated skinmesh support requires only a single weighted mesh, along with keyframed animation data. Try exporting to .x instead of .dxf

I have built the inheriting classes for physical objects up as follows:

CTexture - Base class (does not inherit), provides loading, saving, editing and referencing functionality for Textures.

CMesh - Base class (does not inherit), provides loading, rendering and referencing functionality for Meshes.

CCullableThing - Inherits from CMesh, thus provides all CMesh functionality, as well as providing boundinggeom-based Culling functions, and a Render function which "thunks down" to call the CMesh Render if the object is not culled. Less obviously, it also provides per-object rotation and position fields.

CBullet - Inherits from CCullableThing, providing all the above support, as well as physics-related fields like velocity, angular velocity, etc.

Thus, we can create more "top level classes" like CBullet, which each have their own unique physics handlers. It would be the CBullet class which should be generalized to provide a generic physics class, maybe call it something like CRigidBody and make CBullet inherit from that instead would be an example.

As for the mathematics of planar deflections, rather than simply "Reversing the signs" of the velocity of a particle/object, we should examine the Normal of the surface that was hit, and use its Normal as the "vector of restitution", which should be a "normalized normal", ie of Unit length.

This means that a flat floor surface has a "vector of restitution" which points directly up, and that the "coefficient of restitution" is 1, which means NO energy is lost when the collision occurs. We can think of this value as being the "bounciness" of the floor, for a swamp we'd have a very low coefficient. We should never have >1 since the object would gain speed from each collision lol.

I have built the inheriting classes for physical objects up as follows:

CTexture - Base class (does not inherit), provides loading, saving, editing and referencing functionality for Textures.

CMesh - Base class (does not inherit), provides loading, rendering and referencing functionality for Meshes.

CCullableThing - Inherits from CMesh, thus provides all CMesh functionality, as well as providing boundinggeom-based Culling functions, and a Render function which "thunks down" to call the CMesh Render if the object is not culled. Less obviously, it also provides per-object rotation and position fields.

CBullet - Inherits from CCullableThing, providing all the above support, as well as physics-related fields like velocity, angular velocity, etc.

Thus, we can create more "top level classes" like CBullet, which each have their own unique physics handlers. It would be the CBullet class which should be generalized to provide a generic physics class, maybe call it something like CRigidBody and make CBullet inherit from that instead would be an example.

As for the mathematics of planar deflections, rather than simply "Reversing the signs" of the velocity of a particle/object, we should examine the Normal of the surface that was hit, and use its Normal as the "vector of restitution", which should be a "normalized normal", ie of Unit length.

This means that a flat floor surface has a "vector of restitution" which points directly up, and that the "coefficient of restitution" is 1, which means NO energy is lost when the collision occurs. We can think of this value as being the "bounciness" of the floor, for a swamp we'd have a very low coefficient. We should never have >1 since the object would gain speed from each collision lol.

What I've decided to do is the following:

We keep velocity and orientation for each Object.

Let's call this object A. Velocity is something which applies to the entire body, therefore, the velocity of all "Particles" of A all = the velocity of A, and we can keep just one common Velocity value per Object (note - we can think of Velocity as being applied to ParticleSystem A). Similarly, Orientation is something which affects the entire group of Particles which form an object, and so we keep per-object Orientation values, whichever rotation system we may be using being irrelevant.

The orientation is a set of rotations about A's origin and nominal axes. Rather than apply this orientation to all the vertices of object A when we want to perform per-vertex intersection testing for collisions, we instead apply the inverse of object A's rotation to the CENTER of object B. Thus we are examining for intersections of A with B in object A's local context (ie we are in model space of A). Once we have rotated the CENTER of object B around the center of object A, we can then determine which vertices of object A are closest to the center of object B.

At this point, we're ready to apply the first intersection test, which is just boundingsphere (radius check). If we find an intersection of the spheres, we should now apply the inverse rotation matrix of A (from earlier) to all the vertices of B, and then we can begin point-to-face intersection tests.

Should we find intersection occurs, we calculate the reactive forces PER VERTEX based on the weighted mass of each vertex, which is precalculated based on the mass of the object, number of vertices, and distance of each vertex from its origin.

Now we can calculate the forces applied to all vertices, and add them to calculate the total change to the object.

Think of it this way : imagine that an alien space fiend hurls a crate at you (since alien space fiends and crates are ubiquitously associated), now imagine that the floor is (gasp) uneven - and worse - that the alien space fiend has put some nasty backspin on the crate, and it's rotating out of control as it sails across the room ... (at the moment, all the vertices of the object have equal forces acting on them) - one corner of the crate catches on the uneven floor (an impulse is applied to one vertex of the object), and the crate's behaviour changes, as the result of the collision exerts torque (force=resistance to change in orientation over time) and reflective displacement of velocity apon that vertex. Seeing as how this vertex truly is a good neighbour, he immediately shares the resultant forces with the other vertices in that object. The net result of that can be obtained by simply adding the per-vertex forces of the object, and using the resulting values as change in object rotation and position.

Did I mention that the object has a given Mass, and that the per-vertex Mass is calculated based on the object Mass , number of vertices , and distance of each vertex to the object center of gravity? :)

We keep velocity and orientation for each Object.

Let's call this object A. Velocity is something which applies to the entire body, therefore, the velocity of all "Particles" of A all = the velocity of A, and we can keep just one common Velocity value per Object (note - we can think of Velocity as being applied to ParticleSystem A). Similarly, Orientation is something which affects the entire group of Particles which form an object, and so we keep per-object Orientation values, whichever rotation system we may be using being irrelevant.

The orientation is a set of rotations about A's origin and nominal axes. Rather than apply this orientation to all the vertices of object A when we want to perform per-vertex intersection testing for collisions, we instead apply the inverse of object A's rotation to the CENTER of object B. Thus we are examining for intersections of A with B in object A's local context (ie we are in model space of A). Once we have rotated the CENTER of object B around the center of object A, we can then determine which vertices of object A are closest to the center of object B.

At this point, we're ready to apply the first intersection test, which is just boundingsphere (radius check). If we find an intersection of the spheres, we should now apply the inverse rotation matrix of A (from earlier) to all the vertices of B, and then we can begin point-to-face intersection tests.

Should we find intersection occurs, we calculate the reactive forces PER VERTEX based on the weighted mass of each vertex, which is precalculated based on the mass of the object, number of vertices, and distance of each vertex from its origin.

Now we can calculate the forces applied to all vertices, and add them to calculate the total change to the object.

Think of it this way : imagine that an alien space fiend hurls a crate at you (since alien space fiends and crates are ubiquitously associated), now imagine that the floor is (gasp) uneven - and worse - that the alien space fiend has put some nasty backspin on the crate, and it's rotating out of control as it sails across the room ... (at the moment, all the vertices of the object have equal forces acting on them) - one corner of the crate catches on the uneven floor (an impulse is applied to one vertex of the object), and the crate's behaviour changes, as the result of the collision exerts torque (force=resistance to change in orientation over time) and reflective displacement of velocity apon that vertex. Seeing as how this vertex truly is a good neighbour, he immediately shares the resultant forces with the other vertices in that object. The net result of that can be obtained by simply adding the per-vertex forces of the object, and using the resulting values as change in object rotation and position.

Did I mention that the object has a given Mass, and that the per-vertex Mass is calculated based on the object Mass , number of vertices , and distance of each vertex to the object center of gravity? :)