ODEScript New Thread
by Gary "ChunkyKs" Briggs · in Torque Game Engine · 08/08/2006 (11:29 am) · 99 replies
Well, it's about a year on since I last was really posting stuff, so I thought I'd start a new thread.
From my .plan just now www.garagegames.com/blogs/20342/11050
Here's some code:
icculus.org/~chunky/stuff/odescript/oderocks-2006-08-08.tar.gz
icculus.org/~chunky/stuff/odescript/odescript-2006-08-08.tar.gz
ODEScript is the C++ code. ODERocks is a mod.
If you want the crossbow bolt thing to work, you'll need to edit projectile.cc and add StaticShapeObjectType to the Projectile::csmStaticCollisionMask at the top of the file.
In-game, hold down the C key to see the little physics UI. If you're on a real client instead of a listen server, the only UI widgets that will work properly are gravity [all directions], and the add rock/add link buttons.
Gary (-;
From my .plan just now www.garagegames.com/blogs/20342/11050
Here's some code:
icculus.org/~chunky/stuff/odescript/oderocks-2006-08-08.tar.gz
icculus.org/~chunky/stuff/odescript/odescript-2006-08-08.tar.gz
ODEScript is the C++ code. ODERocks is a mod.
If you want the crossbow bolt thing to work, you'll need to edit projectile.cc and add StaticShapeObjectType to the Projectile::csmStaticCollisionMask at the top of the file.
In-game, hold down the C key to see the little physics UI. If you're on a real client instead of a listen server, the only UI widgets that will work properly are gravity [all directions], and the add rock/add link buttons.
Gary (-;
#2
08/12/2006 (6:42 pm)
I managed to compile it, but Torque crashes each time I call ode to create a boulder/link. The log doesn't show anything. 
#3
08/12/2006 (10:07 pm)
I am also seeing crashes when I try to exit the game but I can add the links and boulders. Also, I may not be doing something right here but I tried the chain and shot it after adding your script from the crossbow to one of my weapons. The chain really doesn't swing, the links just move around a bit. 
#4
08/13/2006 (2:20 am)
Fixed my compile problem :)
#5
Is this correct or have i missed anything ??
08/13/2006 (4:20 am)
I have to enable "autocontact" or else will TGE crash when the odeobject touches the ground.Is this correct or have i missed anything ??
#6
@Ron: In my original post: If you want the crossbow bolt thing to work, you'll need to edit projectile.cc and add StaticShapeObjectType to the Projectile::csmStaticCollisionMask at the top of the file.
If you did that, you may just have some mass/force things going on. The force the crossbolt applies should be something suitable for the mass of the rocks. Like, if you are seeing miniscule movements, try applying a greater force. Itt'll be in the ::OnCollision method for the crossbow bolt's datablock.
@Alien: Your compile problem was ODE not actually getting linked. Presumably you've fixed that now :-)
@Alien: Autocontact also incurs a substantial performance penalty currently without any feature improvement, unless you edited oderock.cs yourself to add features. I would suggest you leave it turned on for now
Gary (-;
08/13/2006 (4:13 pm)
@Mincetro, Ron, and Alienforce: I'll do a new version in the next day or so that should fix most of these bugs.@Ron: In my original post: If you want the crossbow bolt thing to work, you'll need to edit projectile.cc and add StaticShapeObjectType to the Projectile::csmStaticCollisionMask at the top of the file.
If you did that, you may just have some mass/force things going on. The force the crossbolt applies should be something suitable for the mass of the rocks. Like, if you are seeing miniscule movements, try applying a greater force. Itt'll be in the ::OnCollision method for the crossbow bolt's datablock.
@Alien: Your compile problem was ODE not actually getting linked. Presumably you've fixed that now :-)
@Alien: Autocontact also incurs a substantial performance penalty currently without any feature improvement, unless you edited oderock.cs yourself to add features. I would suggest you leave it turned on for now
Gary (-;
#7
icculus.org/~chunky/stuff/odescript/odescript-2006-08-14.tar.gz
icculus.org/~chunky/stuff/odescript/oderocks-2006-08-14.tar.gz
It's got rudimentary joint ghosting working now. Be warned that as it stands, your clientside prediction can end up with a subtly different physics model if joint ghosting happens very much later than body ghosting. This tends to not happen; torque's networking should be considered nondeterministic but not stupid. Taking nondeterminism into account for physics is hard.
As always, feedback is greatly appreciated, please lemme know if you try this out and it works. Or doesn't work.
For the bored, and thanks to TomFemi's crates, there are now square boxes in the simulation. You can add these with the same UI as before.
I suggest you don't add them while in the mission editor, but once they're in your mission, you can load up the mission editor, move them around [ie, stack them on top of each other], giggle at the standard pile of boxes, then shoot them all over. Then giggle some more and do it all again. See, what sucks about writing physics code is that as soon as it works, it's so much fun to play with instead of work on.
Gary (-;
08/14/2006 (11:43 am)
Here's an update.icculus.org/~chunky/stuff/odescript/odescript-2006-08-14.tar.gz
icculus.org/~chunky/stuff/odescript/oderocks-2006-08-14.tar.gz
It's got rudimentary joint ghosting working now. Be warned that as it stands, your clientside prediction can end up with a subtly different physics model if joint ghosting happens very much later than body ghosting. This tends to not happen; torque's networking should be considered nondeterministic but not stupid. Taking nondeterminism into account for physics is hard.
As always, feedback is greatly appreciated, please lemme know if you try this out and it works. Or doesn't work.
For the bored, and thanks to TomFemi's crates, there are now square boxes in the simulation. You can add these with the same UI as before.
I suggest you don't add them while in the mission editor, but once they're in your mission, you can load up the mission editor, move them around [ie, stack them on top of each other], giggle at the standard pile of boxes, then shoot them all over. Then giggle some more and do it all again. See, what sucks about writing physics code is that as soon as it works, it's so much fun to play with instead of work on.
Gary (-;
#8
08/14/2006 (12:07 pm)
Thanks for sharing Gary! Keep up the good work!!
#9
c:\copy\torque\TGE\engine\odescript\tjoint.cc(274): error C2664: 'NetConnection::getGhostIndex': Konvertierung des Parameters 1 von 'SimObject *' in 'NetObject *'
in this line:
S32 cid = conn->getGhostIndex(Sim::findObject(body1));
08/22/2006 (4:52 am)
Can anybody help ?c:\copy\torque\TGE\engine\odescript\tjoint.cc(274): error C2664: 'NetConnection::getGhostIndex': Konvertierung des Parameters 1 von 'SimObject *' in 'NetObject *'
in this line:
S32 cid = conn->getGhostIndex(Sim::findObject(body1));
#10
08/22/2006 (8:12 am)
Interesting as always!
#11
S32 cid = conn->getGhostIndex((NetObject *)Sim::findObject(body1));
Also, I'll be releasing a new version soon, that *gasp* does NO clientside prediction, but looks and works better all the same!
Turns out that using InterpolateTick and friends as they were intended and never ghosting any ODE torque objects works wonders.
I'll probably write a .plan sooner or later about the relative merits of taking your own advice
Gary (-;
08/22/2006 (10:24 am)
@Albert: Uh, yeah, oops.There's something about all the platforms except mac where it can't magically type a SimObject* as a NetObject* (SimObject is derived from NetObject). Just prefix a type on there and in the couple other places this happens:S32 cid = conn->getGhostIndex((NetObject *)Sim::findObject(body1));
Also, I'll be releasing a new version soon, that *gasp* does NO clientside prediction, but looks and works better all the same!
Turns out that using InterpolateTick and friends as they were intended and never ghosting any ODE torque objects works wonders.
I'll probably write a .plan sooner or later about the relative merits of taking your own advice
Gary (-;
#12
../../ode/ode.cpp
Seeing as everyone else seems to be doing OK, I suspect it might have something to do with me being a newbie to the SDK, and C++ in general. However, if you could help point me in the right direction, it'd be greatly appreciated.
EDIT: Stupid BBcode :(
08/26/2006 (9:19 am)
Alright. Both the ODErocks and my project now crashes on mission startup. Any ideas as to why the italicized code dies with some error about bad parameters?../../ode/ode.cpp
void dJointGroupDestroy (dJointGroupID group)
{
[i]dAASSERT (group);[/i]
dJointGroupEmpty (group);
delete group;
}Seeing as everyone else seems to be doing OK, I suspect it might have something to do with me being a newbie to the SDK, and C++ in general. However, if you could help point me in the right direction, it'd be greatly appreciated.
EDIT: Stupid BBcode :(
#13
odescript-2006-08-26.tar.gz
oderocks-2006-08-26.tar.gz
ODERocks now runs as a mod instead of a game [yay, 200k instead of 15M]. The only problem is I didn't work out how to add a keymap at runtime, if I'm only in a mod [as opposed to a game], on the client. So the little menu no longer works. If anyone wants to explain to me how to make it work, that'd be great :-).
I'm pretty sure it should be some sort of client::onMissionLoaded thing, but... not sure. Sorry that I'm making simple idiot mistakes surrounding torque :-/. This is 101 mod creation stuff, and I've ... never created a mod :cry:
Gary (-;
08/26/2006 (11:59 am)
If the group is set to zero, that will throw an error. And then crash annoyingly.odescript-2006-08-26.tar.gz
oderocks-2006-08-26.tar.gz
ODERocks now runs as a mod instead of a game [yay, 200k instead of 15M]. The only problem is I didn't work out how to add a keymap at runtime, if I'm only in a mod [as opposed to a game], on the client. So the little menu no longer works. If anyone wants to explain to me how to make it work, that'd be great :-).
I'm pretty sure it should be some sort of client::onMissionLoaded thing, but... not sure. Sorry that I'm making simple idiot mistakes surrounding torque :-/. This is 101 mod creation stuff, and I've ... never created a mod :cry:
Gary (-;
#14
good stuff !
I have one question to it. When i compare the PhysX integration with Ode Script:
The Boxes in Physx are flying fast through the air. In ODE they are flying through the air, too. But not so fast as in physx. They flying slowlier.
Is it an ajustment in ode or is ode in generally slowlier ?
THX
09/09/2006 (4:05 am)
Hi,good stuff !
I have one question to it. When i compare the PhysX integration with Ode Script:
The Boxes in Physx are flying fast through the air. In ODE they are flying through the air, too. But not so fast as in physx. They flying slowlier.
Is it an ajustment in ode or is ode in generally slowlier ?
THX
#15
What PhysX implementation are you comparing this to, by the way?
Gary (-;
09/09/2006 (12:40 pm)
Albert: increase the ode worldstep value [or for more accurate simulation, decrease it a little but do it twice], which will just speed up the simulation a fair amount. In ODEScript, it's the variable $pref::ODEPhysics::Server::WorldStepWhat PhysX implementation are you comparing this to, by the way?
Gary (-;
#16
Just thought I would ask: Is networking nearly a reality? I have been looking through the ODE docs and do not understand what the issue is with the backstepping. I understand that the ghosted object interpolates, but I did not understand why ODE prevents this from working correctly.
09/09/2006 (2:16 pm)
Quote:
Also, I'll be releasing a new version soon, that *gasp* does NO clientside prediction, but looks and works better all the same!
Turns out that using InterpolateTick and friends as they were intended and never ghosting any ODE torque objects works wonders.
Just thought I would ask: Is networking nearly a reality? I have been looking through the ODE docs and do not understand what the issue is with the backstepping. I understand that the ghosted object interpolates, but I did not understand why ODE prevents this from working correctly.
#17
Gary: Thx for reply and for the good stuff.
I'm comparing it with this ressource :
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=10258
For my project i need a better physics engine as already implemented in TSE/TGE. But decision to use ODE or PhysX is still not made. So i'm checking boh engines. But it's really hard to compare both :-D
What do you think about this ?
http://www.game-physics-engine.info
I've got an idea in my mind. May be it possible to integrate PhysX in the same way as you do with ODE. Hmmm ich have to check it but i'm not a good programmer :-D
Greetings
09/11/2006 (2:31 am)
Hi,Gary: Thx for reply and for the good stuff.
I'm comparing it with this ressource :
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=10258
For my project i need a better physics engine as already implemented in TSE/TGE. But decision to use ODE or PhysX is still not made. So i'm checking boh engines. But it's really hard to compare both :-D
What do you think about this ?
http://www.game-physics-engine.info
I've got an idea in my mind. May be it possible to integrate PhysX in the same way as you do with ODE. Hmmm ich have to check it but i'm not a good programmer :-D
Greetings
#18
@Frank: Kindasorta. Short answer: "no".
Medium answer: "not worth the effort".
Long answer: "My personal experiences are beginning to imply that you're better off by only doing physics on the server and then linearly interpolating on the client.
As with so many videos of physics objects, you'll see that ODEItem, PhysX, and my own ODE videos look awesome with clientside prediction when you have a bunch of cubes and a bunch of spheres. If you try to connect them together with joints [at least, as I do in ODE], then you rapidly come to a situation where, given torque's nondeterministic network nature, some objects have been updated, some haven't, and the joints are wigging out because they're wrong.
Also in the situation where I'm ghosting joints, they usually end up ghosted later so are attached to bodies in subtly the wrong place. [you have to attach a joint to two bodies, so you can't ghost the joint until both bodies it's attached to are ghosted]. Trying to predict stuff when your simulation is broken will never work properly.
Alternatively, you could try packing up the entire simulation into one update and send that down the network, which rapidly gets very network expensive."
@Albert: Well, there's not much I can say about PhysX that hasn't been said before. It looks really sexy, and just as soon as I can use it on platforms that I want to use it on, I'll consider it. Torque's big selling point for me was its cross platform support, and the last few times I've looked, Ageia doesn't have downloads for at least linux. Specifically, this FAQ.
Overall: Everyone seems to love PhysX so I assume it's pretty good. Since it won't run on any machine I own, I can't really form an informed opinion on it.
That other one you linked is entirely german, and I don't speak german. It's probably perfectly good if it solves problems that you have, but I don't really have a nongeneric answer for you since I can't actually read it :-/
There's some other physics engines linked on this TDN entry. Since I last looked, Newton appear to have expanded their supported platforms to include my wishlist, they may be a better bet, now.
Gary (-;
09/11/2006 (11:52 am)
Quote:Just thought I would ask: Is networking nearly a reality? I have been looking through the ODE docs and do not understand what the issue is with the backstepping. I understand that the ghosted object interpolates, but I did not understand why ODE prevents this from working correctly.
@Frank: Kindasorta. Short answer: "no".
Medium answer: "not worth the effort".
Long answer: "My personal experiences are beginning to imply that you're better off by only doing physics on the server and then linearly interpolating on the client.
As with so many videos of physics objects, you'll see that ODEItem, PhysX, and my own ODE videos look awesome with clientside prediction when you have a bunch of cubes and a bunch of spheres. If you try to connect them together with joints [at least, as I do in ODE], then you rapidly come to a situation where, given torque's nondeterministic network nature, some objects have been updated, some haven't, and the joints are wigging out because they're wrong.
Also in the situation where I'm ghosting joints, they usually end up ghosted later so are attached to bodies in subtly the wrong place. [you have to attach a joint to two bodies, so you can't ghost the joint until both bodies it's attached to are ghosted]. Trying to predict stuff when your simulation is broken will never work properly.
Alternatively, you could try packing up the entire simulation into one update and send that down the network, which rapidly gets very network expensive."
@Albert: Well, there's not much I can say about PhysX that hasn't been said before. It looks really sexy, and just as soon as I can use it on platforms that I want to use it on, I'll consider it. Torque's big selling point for me was its cross platform support, and the last few times I've looked, Ageia doesn't have downloads for at least linux. Specifically, this FAQ.
Overall: Everyone seems to love PhysX so I assume it's pretty good. Since it won't run on any machine I own, I can't really form an informed opinion on it.
That other one you linked is entirely german, and I don't speak german. It's probably perfectly good if it solves problems that you have, but I don't really have a nongeneric answer for you since I can't actually read it :-/
There's some other physics engines linked on this TDN entry. Since I last looked, Newton appear to have expanded their supported platforms to include my wishlist, they may be a better bet, now.
Gary (-;
#19
thx for fast reply. I see, it's all in german. grrrr. It's may be because he is a german book author. ^^
What do you think how far ist you implementation away from creating my be a vehicle like a car or a helicopter ?
At the moment for me is quit hard to learn three things at same time
1) advanced C++
2) coding for torque
3) ode or/and physx
So i'm glad for every help/resource i can get :-D
Thanks that you are sharing you work with us !
Greetings
09/11/2006 (1:15 pm)
Hi Gary,thx for fast reply. I see, it's all in german. grrrr. It's may be because he is a german book author. ^^
What do you think how far ist you implementation away from creating my be a vehicle like a car or a helicopter ?
At the moment for me is quit hard to learn three things at same time
1) advanced C++
2) coding for torque
3) ode or/and physx
So i'm glad for every help/resource i can get :-D
Thanks that you are sharing you work with us !
Greetings
#20
If you load up the torque demo, you'll find something called "starter racing", which uses a WheeledVehicle object in torque.
If you want a flyer, there are a couple working ones, specifically HoverVehicle and FlyingVehicle. Since you're on these forums you must have a TGE license, so I'd suggest you check out the stuff in example/starter.racing/ and engine/game/vehicles/
Gary (-;
09/11/2006 (2:55 pm)
If you're trying to implement a car or Helicopoter... torque already has those.If you load up the torque demo, you'll find something called "starter racing", which uses a WheeledVehicle object in torque.
If you want a flyer, there are a couple working ones, specifically HoverVehicle and FlyingVehicle. Since you're on these forums you must have a TGE license, so I'd suggest you check out the stuff in example/starter.racing/ and engine/game/vehicles/
Gary (-;
Torque Owner Alienforce
DLN
I have added the sourcefiles to my project and the friendclass for the odeshapes and linked to ode.
But i cant get it to work, i know i missed some easy step :/
I am running: VC2003, TGE 1.4 and ODE-6
linking...
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldSetGravity
tworld.obj : error LNK2001: unresolved external symbol _dWorldSetGravity
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldGetGravity
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldSetERP
tworld.obj : error LNK2001: unresolved external symbol _dWorldSetERP
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldGetERP
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldSetCFM
tworld.obj : error LNK2001: unresolved external symbol _dWorldSetCFM
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldGetCFM
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldStep
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldQuickStep
tworld.obj : error LNK2001: unresolved external symbol _dWorldQuickStep
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldSetQuickStepNumIterations
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldGetQuickStepNumIterations
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldSetQuickStepW
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldGetQuickStepW
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldSetContactMaxCorrectingVel
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldGetContactMaxCorrectingVel
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldSetContactSurfaceLayer
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldGetContactSurfaceLayer
tworldconsole.obj : error LNK2001: unresolved external symbol _dWorldStepFast1
etc. etc. etc.. etc..............