ODE Torque Stuff

#41 @David: That's pretty much a totally different tool than what I have right now, and would be, in essence, a totally different thing. If you want to work on one, knock yourself out!

I haven't even tried the KODE demo yet, as I don't have windows. In short, anything that doesn't run on at least OSX and Linux, and possibly windows, is essentially of no use, or interest, to me.

Gary (-;

#42 Random code drop, again. Ignore the obviously broken console spam, it's just me trying to get my clientside objects to work right. Clientside prediction, here we come [not there yet, but working on it :-)]

icculus.org/~chunky/stuff/odescript/odescript-2005-07-25.tar.gz
icculus.org/~chunky/stuff/odescript/oderocks-2005-07-25.tar.gz

oderocks is the torquescript mod thingy I'm using right now. Start TGE with -game oderocks. Once you get into the game, hold down C for the on-screen physics menu. Don't bother trying to use this across a network yet. Don't bother trying to realistically use this for *anything* yet.

If you don't want to try it out yet, but want to see what it does, the functionality is exactly the same as in the PhysicsUI2.mov movie in one of my posts above.

Gary (-;

#43 Great work Gary.
I really like what you are doing here :)

#44 Glad you like it!

Gary (-;

#45 This is incredible stuff Gary. It is going to totally change how Torque based games can be made. Thank you for all you are doing.

#46 @Ron: Thank-you!

To be honest, I strongly doubt that it'll revolutionise Torque games in general, but I do at least have a hope that it'll add a choice for more physics related stuff, for those that want it.

In other news, clientside prediction almost works. All the objects are getting ghosted and their necessary information is being passed. And then you set $pref::ODEPhysics::Client::Prediction, and it segfaults. BOO YA

Gary (-;

#47 Anything new Gary?

I wanted to see if you were going to have this stuff in what you are doing.

Character and vehicle ragdoll

Multiplayer support.

#48 Nothing really new to show right now.

Ragdolls, I intend to do once I sort out clientside prediction. Vehicles, we'll have to see. All the facilities to do vehicles in pure script are already there. There question will be whether or not I want to implement a vehicle in C++. The whole ODEScript philosophy means that you shouldn't need to implement a vehicle in C++. The only reason I'm messing with ODEShape is to come up with something minimal that can leverage ODEScript.

It should be noted that I'm still using torque's collision detection. This means that all the reasons everyone dislikes Torque vehicles right now, won't be fixed by my work. Because of how ODE solves collisions, there's a good chance that vehicles /et al/ will squidge out of the ground rather than just get stuck, like in normal Torque. We'll have to see.

I strongly suggest that if you want vehicles, you try the canned torque ones, and go from there. If there's anything that they can't do, *then* try a more complex physics system.

Multiplayer support already exists in the way I do it, so much as I completely ignore it all, work within the normal Torque system, and it works itself out. Finishing clientside prediction will make it seem a lot better though.


Let me repeat that for everyone who's not clear: This is not a magical solution for all physics for everyone. For most people, most of the time a magical solution to physics *already exists within torque*, and you should really look into that before concluding it's not sufficient.

The reason I'm doing all this is because I have a shopping list of features I'll need for the game I have in mind and will eventually write, and Torque's physics do not solve the problems that I have, but ODE does.

Gary (-;

#49 I understand what you are saying in terms of vehicles, I asked because I tried Akio's demo and his vehicle collision was greatly enhanced by it. Also I just wanted to say again thanks for all of the work you are doing.

#50 @Gary: I want to applaud your sane approach to all this. :)

#51 @Ben; Me? Sane? Wooo, you need to step away from the crack pipe.

Also, thank-you :-)

Gary (-;

#52 Gary starting abit of this and was looking at your code. Do you use your code in conjunction with the ODE include files or is it a replacement/update?

#53 Not entirely sure I understand the question, but hope this is the answer;
I haven't modified stock ODE [I'm using 0.5 here], or copied any of the stock ODE files into my torque code; I'm treating ODE as a random static library on the system, as if it were any other library.
I just #include , and link using -lode, and expect your compiler to know what that means.

In other words, exactly the opposite of ODEItem

Gary (-;

#54 Hey Gary!

Any news? Im trying to work with some physics too... but a lot of problem in my path! =/

Maybe u can help me!
Im trying to make a DXBall in 3D... something like a NO GRAVITY room, with a ball kicking on everything it see! hehe

What do u think?

Thanks

RW

#55 Heya

Just a ball in a giant no gravity room is trivially implementable using RigidShape. Just edit rigidshape.cc around line 45, and change
const F32 sRigidShapeGravity = -20;
to
const F32 sRigidShapeGravity = 0;


Thar ya go; a ball type thing in zero gravity.

Gary (-;

#56 Ok ok... gravity i can change...
Thanks Gary..

But, new problem... When the ball, hits the wall.. or something... it looses velocity...
I dont want this!

I just need someone kicking over the time.. hehehe Never stop!
Can u help me? With this?
Im reading the RigidShape code but, a lot of velocities... i dont know where need to change...
trying one to one.. but, some time the ball doenst collides anymore.. =/

Can u help me?

Thanks

RW

#57 You need to have absolutely no friction or energy loss (bounce at full energy) to have it never stop. Also, you shouldn't need engine code for gravity, shouldn't you just use a physical zone with gravity set to 0?

#58 The problem of Physical Zone is that: The physics doesnt gets objects.. only the player.,..
well.. my tests here say me that.. ;P

#59 Thanks to Gary for putting in the effort on this - I agree with others above that this is a vital part of the engine.

It has been very quiet on this thread for a while now.. anyone having any success integrating it? How about a complete howto?

I suppose I could write one but ... in true n00b fassion..
my boulders seem to fall straight through the ground and the ODEShapeData::onCollision() functions never gets called.

What am I missing? Do you need to explicitly enable collision detection or something? I thought the idea was that all GameShapeBase extensions automatically got included in collision detection with terrain... hmmmn.

Can someone suggest where the best place to debug this is?

thanks in advance

Dan

#60 Well... i think the oncollision() is only called when the player collide with the boulder...
Not with the TERRAIN or INTERIORs...