Sorry your browser is not supported!

Hi All,

This message is especially intended for Ian M, Rob K, any admins or absolutely anyone with good 3D/rotation/physics knowledge!

I noticed a topic from a couple of months ago on the Tokamak Game Physics engine, with only a few replies. Well, this neat-looking engine is now FREE for both non-commercial and commercial use. The demos look outstanding - the dynamics modelling this baby provides is faaaaast, and the demos where you can throw a cube at the stack of cubes are pure enjoyment. This is, however, a C++ engine.

Tokamak can be found at http://www.tokamakphysics.com. It has to be said - real bad documentation so far, and you need to steal chunks of sample code to get it working! Anyway, using the DBPro interface lib provided by Ian M (nice work indeed matey ), I've managed to get both the Tokamak and the ODE C++ physics engines working, and manipulating DBPro-loaded X objects to visualise the result. Most of my code is in the C++ DLL at the moment - I have DBPro commands to init, tick, and shutdown the DLL code, and the required lines to force inclusion of required DBPro libraries when the EXE is built.

It's my intention to have a go at writing a TPC DLL that provides access to one or both of these physics libraries. Physics is an awesome tool when applied correctly, and once you've figured out how to control the simulation in terms of geometry, collision, and forces, you're away. If the simulation is easy to access, even the moderately skilled developer can create a real-world simulation in minutes. I would also be able to write beginner tutorials for the DLL - I'm no physics wizard, but if I can get some of the current gripes out of the way, I'm sure I can create a usable DLL.

OK, here is a quick attempt at asking this question:

Does anyone know how to rotate an object in DBPro, so it correctly imitates a ball, which can roll in any direction?

Right, if you can't answer yes to the above, try the meaty version of the question :

The simulation is running correctly, and I can position objects OK. However, I have a problem with rotation. The physics engines represent rotation in a 3x4 matrix. DBPro specifies rotation using simple angles around the X,Y and Z axes. Someone on the ODE mailing list gave me code to convert the matrix to 3 rotation angles. If I use RotateObject() or ?RotateObject() every time step, the rotated objects seem to take on a life of their own I think it could be down to rotation axis order (although I've tried switching to ZYX in desperation, which didn't help). They spin one way, then come back. They're spinning on 2 axes I think, but the ball is only rolling 'straight forwards' if you like. I'm sure this is simple, and at the moment it's the only thing holding this back. ODE is much more stable and complete than Tokamak, but displays exactly the same problem on implementation - the rotation is more like a damn bowling ball rolling on glass! I've tested examples that come with both SDK's, written using pure DX8/9 code. They work perfectly, so I modelled my environment similar to theirs - i.e. I based my mass, friction, elasticity settings on theirs. This is why I'm convinced the problem is caused when I try to rotate the DBPro object.

Any help would be appreciated guys, I've torn out half of the hair that God has left me with, and soon I'll look too stupid to go out... (like this : )

Darren.

I might be able to help you out. I think what you are going to need is to convert from Euler angles(which is what dbpro is using) to a rotation matrix(which is what Tokamak, and DBPro under the hood, uses). I have the math for it written down somewhere. I'll see what I can do for you later when I have some more spare time.

Hi Neophyte,

Thanks a lot, that would be awesome I managed to get a reply from someone on the ODE mailing list that did the same thing (I'm trying to get *from* a matrix, *to* the values required for Rotate Object in DBP). It kind of works - the speres are at least rotating in the right direction now, but they keep 'jumping' back to a certain alignment on the axis they're rotating on.

/me and Euler not getting on

Just had another reply saying that Euler angles are possibly between -180 and +180 - going to investigate that now.

Again, thanks for the help Neophyte!

Any other replies still welcome guys!

Cheers,

Darren.

I got balls rolling, bouncing.. but I haven't done collisions with other objects yet - but it would seem the same velocity math I have so far would simply be "share" your velocity with the item you hit based on the weight of the two items... subtract the "absorbtion" from both matrials.... and you have a physics collision... the motion velocities just kinda seem to work for me.

A good rotating ball would account for friction, gravity, speed, radius, distance traveled since last frame and those maths you guys are talking about.

I put a "REAL timer ..." code snip the codebase - it kinda covers this to a SMALL SMALL degree - at least as far as making your physic "play out" the same way on any PC - regardless of clock speed gfx speed etc

The more accurate the physics - the more complicated the whole program: Case and Point: How does program decide ball rolls smooth - cube bounces, spins....jumps if corners hit...slides if side hits... like trying to make a football behave correctly in 3d space... seems tough to me - at least a LOT of code to describe how the football behaves - or whatever.

Hi Jaze,

That's what these physics engines take care of - if you want to take an active part in collision detection, you can. However, if you just want to give objects shape, properties (mass, friction, elasticity/restitution) and let them do their thing, you can. Friction with other collidable objects is all done by the physics engine. The general workflow is:

Setup physics world (set gravity etc.)
Create objects within physics library (mass, friction etc.)
Specify which objects collide if neccessary
Loop>
Run a Collision Check
Tell the physics simulation to advance by a given time
Using object information from the sim, position DBPro objects as required
EndLoop>

And that's it And believe me, the results look fantastic (check out the demos available on the Tokamak site - throwing little cubes has never been so entertaining )

Cuz I'm still a babe at this 3d vector stuff - I'm not gonna abandon the "basic" programming set I have just yet. Meaning - getting my own stuff running - and behaving - just so I can wrap a game together - using strictly dbpro ... for now is enough. Making each object totally behave (like the guys falling down the stairs) means turning over a LOT to the physics engine - and you just place your objects where the SDK tell you to. I'm kinda doing that part myself.

Like I'm more concerned on smooth timer based dispalay, making a model "think" to walk here - shoot there, and stuff...

I'm actually only doing the Timer Thing as a Shell for a landscape / scenery generator thingy.... Random World - apply a basic "physics" and then make models interact properly within. I can't commit the time I need.

Matrix to Euler, eh? Hmmmm. That is going to be a slight bit more difficult, but I think I can help. There are some considerations that need to be made beforehand however.

First off, we need to know which rotation the matrix performs. Object(model space) to inertial(World space) or inertial to object. I have a ready example of inertial to object so that is what I'll use. If you need object to inertial the process is quite similar to the one that I'll be giving.

Second, for any given angular displacement there is an infinite number of possible representations for it(ie 0 degrees is the same as 360, 720, 1080, and so on and so forth). I think that is what is causing your problems with the objects suddenly getting a life of their own. So I'm caping the range of the values. Heading(Y angle) and Bank(Z angle) are capped at -180 to +180 degrees and Pitch(X angle) are capped at -90 to +90 degrees.

Third, some matrices are messed up due to floating point round off error. So we have to be a bit carefull with are results.

Anyway, here we go.

The format for the matrix notation that I'll be using is as follows:



We can solve for Pitch(X angle) quite easily with the following:

asin(-m23) = Pitch

Now lets assume that Pitch is not equal to Zero.

Heading works out as the following:

atan2[atanfull, I think, in DBPro](m13,m33) = Heading

Bank is as follows:

atan2[once again, atanfull, I think, in DBpro](m21,m22) = Bank

That was pretty easy, except if Pitch is Zero. Then Heading and Bank need to be computed differently. If Pitch is Zero then you are looking straight up so we can arbitrally assign all rotation to Heading and get away with it. So calculate the heading as follows:

atan2(-m31, m11) = Heading

and Bank is equal to Zero.

The above explaination comes partly from 3D math primer for graphics and game development(I kinda of reworded it and omitted some of the lengthier explainations but it is essentially the same). The book also has the following C++ code to help illuminate what was just explained:



If you need object to inertial just say so and I'll post that too.

Hey Neophyte,

Thanks a bunch for the reply mate! I've tried the code, and again the objects are displaying the 'limited rotation axis' thing - they seem to rotate nicely as they roll along, but while they're still spinning, they switch to immediately rotate in the opposite direction! And then, after they've spun maybe 90 or 180 in that opposite direction, they switch again, until the ball finally stops.

I can almost see what's going wrong - it's maybe a mixture of these angles being within ranges (0..90, -180..+180) and me not translating that properly to DBPro (or the results from the calculations are still not in the range DBPro wants?). The rotation looks so close, with the only weird thing being this rotation reversal mid-roll.

I'm fairly sure I'm extracting the matrix info into the m11..m33 variables in the code. The thing is, because I don't quite understand all of the calculation, when it goes wrong I don't have a place to start - so maybe I do need the other form of calculation you mentioned, or maybe there is still something else missing

Thanks a lot for your help Neophyte, I'd really appreciate the other calculation code!

Darren.

That I was trying to get your meaning to neophyte - I didn't grasp it... but then the A* thing had me confused and with a little looking I was like... THEY call that an Algorythm? DUH! haha... isn't that like basic move here or there? hehe

So maybe I just got to play with it. The Physics engine has my eye though....but I'm currently banging out a PLUG in for DBPRO to allow me to utilize as much of my already written code I can

I can see where some of the confusion comes from because I didn't post the full explaination of how I got those values. It comes from the Euler->Matrix(inertial->object) formula. Here is how you convert from Euler->Matrix(I know you already know how to do this, DaZ_MaN_Ym, I'm just showing it to explain where I got the Matrix->Euler equations):



Since m23 = -sin(p) I could solve for p by rearranging the equation to this asin(-m23) = p as I did in my previous post.

Now that p has been defined we can also know the value of cos(p).

m13 = sin(h)cos(p)

m13/cos(p) = sin(h)

m33 = cos(h)cos(p)

m33/cos(p) = cos(h)

So to get the heading we would do this:

heading = atan2(sin(h), cos(h))

Which is the exact same thing as this:

heading = atan2(m13/cos(p), m33/cos(p))

This is why are trick here won't work when the pitch = 0 because all of the matrix elements involved are zero and we can't divide by zero.

But as I explained before, When we know that pitch is 0 that means we are looking straight up or down. So we can simplify rotation by lobbing all of it into heading and setting bank rotation to zero.

When we know that pitch and bank are equal to zero we can make the following assumtions:

cos(p) = 0
b = 0
sin(b) = 0
cos(b) = 1

And then we can simplify the above inertial->object equation from this:



Which can be simplified to:



Then heading can be computed from -m31 and m11 which contain the sine and cosine of the heading respectively.

Anyway, now that how I got the heading, pitch, and bank is clear(or at least I hope so) I can give you the object->inertial Euler->Matrix formula so you can convert it to Matrix->Euler:



Just post if you need help getting the Matrix->Euler values out of it or if you need any clarification on anything.I can see where some of the confusion comes from because I didn't post the full explaination of how I got those values. It comes from the Euler->Matrix(inertial->object) formula. Here is how you convert from Euler->Matrix(I know you already know how to do this, DaZ_MaN_Ym, I'm just showing it to explain where I got the Matrix->Euler equations):



Since m23 = -sin(p) I could solve for p by rearranging the equation to this asin(-m23) = p as I did in my previous post.

Now that p has been defined we can also know the value of cos(p).

m13 = sin(h)cos(p)

m13/cos(p) = sin(h)

m33 = cos(h)cos(p)

m33/cos(p) = cos(h)

So to get the heading we would do this:

heading = atan2(sin(h), cos(h))

Which is the exact same thing as this:

heading = atan2(m13/cos(p), m33/cos(p))

This is why are trick here won't work when the pitch = 0 because all of the matrix elements involved are zero and we can't divide by zero.

But as I explained before, When we know that pitch is 0 that means we are looking straight up or down. So we can simplify rotation by lobbing all of it into heading and setting bank rotation to zero.

When we know that pitch and bank are equal to zero we can make the following assumtions:

cos(p) = 0
b = 0
sin(b) = 0
cos(b) = 1

And then we can simplify the above inertial->object equation from this:



Which can be simplified to:



Then heading can be computed from -m31 and m11 which contain the sine and cosine of the heading respectively.

Anyway, now that how I got the heading, pitch, and bank is clear(or at least I hope so) I can give you the object->inertial Euler->Matrix formula so you can convert it to Matrix->Euler:



Just post if you need any help getting the Matrix->Euler formulas out of that or need if you need any clarification on anything that I've said(I think I've forgotten to say something but I'm just not sure what right now).

YYYYYYYYikes

Thanks Neophyte, I see you were the right person to answer this question! I'm afraid tho, that my level of maths is stopping me from understanding all that. I follow the theory OK - deciding which axes we actually need to worry about. However, it's when the Trig and equation solving rear their ugly heads that I lose mine!

Looking at this kind of calculation/code is the kind of stuff I was hoping to avoid - once the DBPro objects are behaving correctly in terms of position and rotation it should be an easy job to make the simulation available to DBPro users. Actually using these physics engines is surprisingly easy, once they're set up. My C++ code is heavily based on the DirectX C++ examples that came with the Tokamak SDK. The examples simply drop cubes, spheres and 'capsules' onto a flat plane, and they collide correctly. It's dead simple code, and shows you almost everything you need to know about getting the thing running.

I don't want to wast too much of your time with this mate - I really appreciate the help, but those are some monster replies you're writing there I'm sure it can't be much fun trying to explain Euler angles to a maths newb either

Yeah, the math can be pretty intense sometimes but Trig isn't too hard once you get the hang of it. I probably post how to convert Matrix to Euler/ Object to Inertial latter when I get the time.

But I'm not too sure that will solve your problem of the sphere spinning the wrong way half-way there though. I think it is a percision problem though I'm not sure. You could always post over on the Tokamak forums with some code examples of what is going wrong. They'll probably be able to help you more than I can since I'm not too great with C++.

You might take a close look at my simple flight sim I wrote a while back. It use quaternions to rotate the plane (actually its mesh). It's buried in the flight sim code, but the command is 'arbAxisRotation(x,y,z,d)'. The "xyz" is the vector, or line that originates at 0,0,0 to the x,y,z. And 'd' is the angle around that axis.

Basically
arbAxisRotation(0.0,1.0,0.0,yaw)
arbAxisRotation(1.0,0.0,0.0,pitch)
arbAxisRotation(0.0,0.0,1.0,roll)

However this actually alters the mesh data via memblocks so it does not benefit from 3D acceleration of your video card.

Very functional code - I haven't dug in "DUG IN" yet but I've seen enough to say - COOL BRO! Gonna dig in when I'm lesss tired - looks cool though. Good "base" for that TYPE of moving around Waypoints and plane flight paths very cool

Any progress?

I'm not sure about the others, but I've started to translate the header files for Tokamak to PureBasic so I can code up a decent .dll version that will work with Pro.

However, since I'm not entirely sure that I can use the supplied(and necessary) libs that come with Tokamak I haven't progressed far with the conversion process.

I emailed support@purebasic to ask them if I could use regular libs or if there was anything I could do to convert them without the source(you don't have access to the Tokamak libs source. Only the Tokamak team does). I'm sceptical that I will succeed as there are a few things that have baffled me as to their function. I'm not much of a C++ guru myself.

Anyway, that's all of the (meager)progress that I've made. Anyone else get any further? I'd love to skip this whole conversion process thing and let a C++ guru handle this stuff, but since I haven't see anyone here post anything about getting a working Tokamak .dll up, I've reluctantly taken the task up myself and I've got to tell ya it ain't easy. At least for me anyway.

*bump*

So has anyone made any progress or am I alone in this endeavor?

there is a camera in the elevator, and I'm watching it
would also like to hear about any progress