Moving around INSIDE vehicles?
by John Vanderbeck · in Torque Game Engine · 01/13/2004 (3:54 pm) · 67 replies
Ok bear with me as this might be hard to explain. Heck the topic doesn't even probably make sense so thanks for taking a look :p
I've never to my knowledge seen this done. It would be extremely difficult even in my own engine, so doing it in Torque is beyond me as i'm still learning the ins and outs.
What we need to do is have very large vehicles which allow players to move around inside them. As an example, take a submarine. The submarine is a vehicle which moves around the map under the control of one or more players. In the normal sense for torque these players would be mounted into the vehicle. This is traditional for vehicles. Heres where it gets tricky. Instead of mounting players into the vehicle, I need them to be able to move around inside the vehicle (or on top of EG an aircraft carrier) just as if they were moving around on the map. Imagine for example standing on the deck of an aircraft carrier. You are on the vehicle, and the vehicle is moving ikn relation to the map. You are also free to move around on the vehicle though. Fights will take place inside and on these larger vehicles.
Does that make sense? If so this is probably the point where i'm told i'm crazy and its impossible. Unfortunately that word isn't what I want to hear :) I'm not asking anyone to write this for me, but point me in the right direction. The lack of documentation for Torque makes it very difficult to do anything that is outside the scope of "hacking tribes 2".
I've never to my knowledge seen this done. It would be extremely difficult even in my own engine, so doing it in Torque is beyond me as i'm still learning the ins and outs.
What we need to do is have very large vehicles which allow players to move around inside them. As an example, take a submarine. The submarine is a vehicle which moves around the map under the control of one or more players. In the normal sense for torque these players would be mounted into the vehicle. This is traditional for vehicles. Heres where it gets tricky. Instead of mounting players into the vehicle, I need them to be able to move around inside the vehicle (or on top of EG an aircraft carrier) just as if they were moving around on the map. Imagine for example standing on the deck of an aircraft carrier. You are on the vehicle, and the vehicle is moving ikn relation to the map. You are also free to move around on the vehicle though. Fights will take place inside and on these larger vehicles.
Does that make sense? If so this is probably the point where i'm told i'm crazy and its impossible. Unfortunately that word isn't what I want to hear :) I'm not asking anyone to write this for me, but point me in the right direction. The lack of documentation for Torque makes it very difficult to do anything that is outside the scope of "hacking tribes 2".
#42
but i feel that you are right... the simpler the solution, the better... and since i'm finally getting serious about coding Torque, and managed to get my first player avatar mount working... within the next day or two i'm going to be pursuing a solution, in script only... which will allow someone to board a vehicle and move around on/in it...
don't hold your breath though :) this is purely a concept, and my torqing skills are rudimentary at best currently...
... but it does seem interesting enough to look into... before 1.4 comes out with the forecasted moving platforms.
--Mike
06/26/2005 (7:42 am)
While that's cool and all... i think that getting 4 people to mount a vehicle is a degree simpler than having a moving platform with the ability to move around on/in it... like the aircraft carrier or a large spaceship as mentioned before...but i feel that you are right... the simpler the solution, the better... and since i'm finally getting serious about coding Torque, and managed to get my first player avatar mount working... within the next day or two i'm going to be pursuing a solution, in script only... which will allow someone to board a vehicle and move around on/in it...
don't hold your breath though :) this is purely a concept, and my torqing skills are rudimentary at best currently...
... but it does seem interesting enough to look into... before 1.4 comes out with the forecasted moving platforms.
--Mike
#44
I feel the things I *need* are the means to walk about on/in a 3D shape, even if at times there is a roof over your head while doing so, and to be able to more through doorways within it and up/down staircases and ladders that may be encountered on the 3D polymesh.
Is this all within 1.4's projected capabilities?
tone
06/26/2005 (8:08 am)
The part I hope to avoid is having BSP interiors AND polygon models, as the tools for creating these interiors (and suturing them onto polymeshes?) are unfamiliar to artists and not as capable as their preferred 3D tools. I am willing to forego benefits of culling the geometry by BSP means if I can punt on every having an artist think about a dualistic artpath.I feel the things I *need* are the means to walk about on/in a 3D shape, even if at times there is a roof over your head while doing so, and to be able to more through doorways within it and up/down staircases and ladders that may be encountered on the 3D polymesh.
Is this all within 1.4's projected capabilities?
tone
#45
http://dreadnoughtproject.org/deckwalk.avi
You'll note:
1. Complex ship model which moves about under arbitrary external stimuli (waves and hyrdo I will provide)
2. walking up stairs
3. walking through doorways and into spaces where I may have floors, overheads, and walls surrounding me, with or without windows permitting an external view
4. No strong need for AI characters to navigate the deck in this manner
Will TGE 1.4 be close to having the capabilities shown in the video?
tone
06/26/2005 (8:41 am)
I posted a 7MB AVI which demonstrates everything I need to see happen in Torque:http://dreadnoughtproject.org/deckwalk.avi
You'll note:
1. Complex ship model which moves about under arbitrary external stimuli (waves and hyrdo I will provide)
2. walking up stairs
3. walking through doorways and into spaces where I may have floors, overheads, and walls surrounding me, with or without windows permitting an external view
4. No strong need for AI characters to navigate the deck in this manner
Will TGE 1.4 be close to having the capabilities shown in the video?
tone
#47
There's another thread that discusses a "ship" that "sails".... but its really a DIF... not a DTS.
06/30/2005 (2:46 pm)
@Thc-03: Its not a vehicle... Its a carefully crafted DIF object made to operate like a vehicle if I am not mistaken.There's another thread that discusses a "ship" that "sails".... but its really a DIF... not a DTS.
#49
this provides a limited, predetermined set of movements for a player character on a moving platform, and is discussed here http://www.garagegames.com/mg/forums/result.thread.php?qt=32262 in post 5...
it may be of some help... it's a simple, script based only, solution... so it should work fine for a pc, mac, linux client...
i think that doing stuff like this will be a lot easier to implement in 1.4, but... until 1.4 is formally blessed and released... this looks like what i can use...
if it propagates across the server to the various clients... i'm testing a client/server code implementation now...
--Mike
07/20/2005 (7:30 am)
Ok... i finally made a lil progress with this... with some insights by a few more experienced and generous Torquers here, i got something working that is based on animating the mount node joints within the model...this provides a limited, predetermined set of movements for a player character on a moving platform, and is discussed here http://www.garagegames.com/mg/forums/result.thread.php?qt=32262 in post 5...
it may be of some help... it's a simple, script based only, solution... so it should work fine for a pc, mac, linux client...
i think that doing stuff like this will be a lot easier to implement in 1.4, but... until 1.4 is formally blessed and released... this looks like what i can use...
if it propagates across the server to the various clients... i'm testing a client/server code implementation now...
--Mike
#50
I'd really like to see this made standard, and augmented with
1. C++ and scriptable methods to permit rotations and translations (and queries for the same) for an object expressed in the coordinate space of its parent, e.g.: moveInParentBy(Point3F), getYaw()
2. the maintenance of lists of mounted sceneObjects within the parent sceneobject (as in ShapeBase's mounting logic)
3. ShapeBase's mounting functionality made to employ this as the underlying basis
My application is ALL about wildly articulated objects (one ship has >1700 SceneObject equivalents in the prototype). I thought this sort of geometry building was the essence of graphic engine work, and am surprised it is required as some quirky little facet of TGE.
---- edit ----
To assist any trying to use the above, there were two things not mentioned in Ben's otherwise excellent description. You'd figure them out soon enough, but here they are:
1. You need to add function declarations in the .hh file for packUpdate() and unpackUpdate()
good luck! I'm going to try it out and maybe fulfill some of the ambitions outlined above
tone
08/26/2005 (2:05 pm)
With some regret, I am working Ben's temporary code into my codebase.I'd really like to see this made standard, and augmented with
1. C++ and scriptable methods to permit rotations and translations (and queries for the same) for an object expressed in the coordinate space of its parent, e.g.: moveInParentBy(Point3F), getYaw()
2. the maintenance of lists of mounted sceneObjects within the parent sceneobject (as in ShapeBase's mounting logic)
3. ShapeBase's mounting functionality made to employ this as the underlying basis
My application is ALL about wildly articulated objects (one ship has >1700 SceneObject equivalents in the prototype). I thought this sort of geometry building was the essence of graphic engine work, and am surprised it is required as some quirky little facet of TGE.
---- edit ----
To assist any trying to use the above, there were two things not mentioned in Ben's otherwise excellent description. You'd figure them out soon enough, but here they are:
1. You need to add function declarations in the .hh file for packUpdate() and unpackUpdate()
U32 packUpdate(NetConnection *, U32, BitStream*); void unpackUpdate(NetConnection *, BitStream*);2. Similarly, you need to define SceneMountMask in the header by adding it where shown:
enum SceneObjectMasks {
ScaleMask = 1 << 0,
SceneMountMask = 1 << 1, // added
NextFreeMask = SceneMountMask << 1 // changed
};good luck! I'm going to try it out and maybe fulfill some of the ambitions outlined above
tone
#51
Actually, most graphics work revolves around minimizing the number of different things you're asking the hardware to do. Every state change has a cost.
08/26/2005 (4:28 pm)
Thanks for posting the missing pieces. ;)Actually, most graphics work revolves around minimizing the number of different things you're asking the hardware to do. Every state change has a cost.
#52
i'm curious to see/hear what progress or grief you've been experiencing...
thx
--Mike
08/30/2005 (9:10 am)
Anthony... how's it going with your code merging...i'm curious to see/hear what progress or grief you've been experiencing...
thx
--Mike
#53
I have had some success with it.
SceneObjects in my sandbox now support
// "mounts" (in the old vernacular) a given object to this one
// the child will follow this object about as though mechanically joined
// the position of the child in world space is not altered in any way
// returns false if the effort would result in a cycle in the scene graph
bool addChild(SceneObject *o);
// similar to above, but in cases of success the new child is moved such that
// its new world position matches the given transform EXPRESSED IN
// TERMS RELATIVE TO OUR PARENT'S COORDINATE SYSTEM
bool addChildAt(SceneObject *o, MatrixF &atThisTransform);
// similar to above, but the child's orientation in world space is not disturbed
bool addChildAt(SceneObject *o, Point3F &atThisPosition);
// the given child becomes a root in the scene graph
// returns false if o is not a direct child of this scene object
bool removeChild(SceneObject *o);
// returns the parent to this object, or NULL if this is a root object
SceneObject *getParent() const;
// these are helpful for iterating through the children
U32 getNumChildren() const;
SceneObject *getChild(U32 index) const;
// similar to getNumChildren, this is recursive
U32 getNumProgeny() const;
// returns transform within parent (or world transform, in case this is a root object)
// in all cases, this is in the coordinate space of the parent object
MatrixF &getLocalTransform() const;
// see above
void setLocalTransform(MatrixF &f);
// a raft of others, such as get/setLocalPosition()
Any changes to a SceneObject's transformation (in any coordinate space) brings all progeny along for the ride.
Where I'd like to go from here:
1. rename present functions that presumptively name themselves things like setPosition() and setTransform() into something like what they ARE: setAbsolutePosition() and setAbsoluteTransform(), while renaming the "Local" ones to the shorthand names setPosition(), etc. The simple fact is that when you have a parent object, any changes that are NOT relative to it become exceptional circumstances and that is when the additional typing should be done. Verify that the demo apps still "just work" (since everything is a root object in them).
2. recode the SceneObject::mount() stuff to use the above functionality as its basis. Behaviors such as not permitting a mounted Player to move in his hovercraft seat are simply parametrized characterstics of how he is attached to his parent.
3. little bits such as track absolute velocity of all SceneObjects dynamically if they are cast off to become root objects (by judging their absolute velocity as the sum of the absolute velocities of all parent objects plus their own velocity relative to their parent). In this way, reality is REAL. For intance, throwing a ball from your car as it rides a merry-go-round should not require you (the game coder) to do more than calculate the throwing trajectory as if you were at rest. This would also be helpful as an elegant start for walking on moving things.
4. add many more user-friendly scripting hooks than are found at present
What I lack is sufficiently strong understanding of how to make this networked in TGE (though I may be there already). I suspect that I want to
1. get RID of mRenderToWorld, and make mObjToWorld serve this function (so that SceneObjects ONLY have data structures within them which actually pertain to the 3D relationships of the moment)
2. create a MoveHandler class tree, each instance of which will have a mNetworkTransformToWorld
3. give each SceneObject a pointer to a MoveHandler responsible for maintaining state and logic for how Moves drive interp/exterp behaviors
but then, what do I know? I could just be deluded.
Michael, if you'd like to help or just want to see what I have now, let me know. I think I have your email.
tone
09/02/2005 (12:37 pm)
Michael... I have had some success with it.
SceneObjects in my sandbox now support
// "mounts" (in the old vernacular) a given object to this one
// the child will follow this object about as though mechanically joined
// the position of the child in world space is not altered in any way
// returns false if the effort would result in a cycle in the scene graph
bool addChild(SceneObject *o);
// similar to above, but in cases of success the new child is moved such that
// its new world position matches the given transform EXPRESSED IN
// TERMS RELATIVE TO OUR PARENT'S COORDINATE SYSTEM
bool addChildAt(SceneObject *o, MatrixF &atThisTransform);
// similar to above, but the child's orientation in world space is not disturbed
bool addChildAt(SceneObject *o, Point3F &atThisPosition);
// the given child becomes a root in the scene graph
// returns false if o is not a direct child of this scene object
bool removeChild(SceneObject *o);
// returns the parent to this object, or NULL if this is a root object
SceneObject *getParent() const;
// these are helpful for iterating through the children
U32 getNumChildren() const;
SceneObject *getChild(U32 index) const;
// similar to getNumChildren, this is recursive
U32 getNumProgeny() const;
// returns transform within parent (or world transform, in case this is a root object)
// in all cases, this is in the coordinate space of the parent object
MatrixF &getLocalTransform() const;
// see above
void setLocalTransform(MatrixF &f);
// a raft of others, such as get/setLocalPosition()
Any changes to a SceneObject's transformation (in any coordinate space) brings all progeny along for the ride.
Where I'd like to go from here:
1. rename present functions that presumptively name themselves things like setPosition() and setTransform() into something like what they ARE: setAbsolutePosition() and setAbsoluteTransform(), while renaming the "Local" ones to the shorthand names setPosition(), etc. The simple fact is that when you have a parent object, any changes that are NOT relative to it become exceptional circumstances and that is when the additional typing should be done. Verify that the demo apps still "just work" (since everything is a root object in them).
2. recode the SceneObject::mount() stuff to use the above functionality as its basis. Behaviors such as not permitting a mounted Player to move in his hovercraft seat are simply parametrized characterstics of how he is attached to his parent.
3. little bits such as track absolute velocity of all SceneObjects dynamically if they are cast off to become root objects (by judging their absolute velocity as the sum of the absolute velocities of all parent objects plus their own velocity relative to their parent). In this way, reality is REAL. For intance, throwing a ball from your car as it rides a merry-go-round should not require you (the game coder) to do more than calculate the throwing trajectory as if you were at rest. This would also be helpful as an elegant start for walking on moving things.
4. add many more user-friendly scripting hooks than are found at present
What I lack is sufficiently strong understanding of how to make this networked in TGE (though I may be there already). I suspect that I want to
1. get RID of mRenderToWorld, and make mObjToWorld serve this function (so that SceneObjects ONLY have data structures within them which actually pertain to the 3D relationships of the moment)
2. create a MoveHandler class tree, each instance of which will have a mNetworkTransformToWorld
3. give each SceneObject a pointer to a MoveHandler responsible for maintaining state and logic for how Moves drive interp/exterp behaviors
but then, what do I know? I could just be deluded.
Michael, if you'd like to help or just want to see what I have now, let me know. I think I have your email.
tone
#54
09/02/2005 (3:05 pm)
Anothony, I would like to be of help. If you email me your changes I can work on it.
#55
i don't know how far i can go, my expertise with the engine has
primarily been in scripting... but i would be glad to take a look at
what you've got... see what i can do...
and it would be nice to see it in action as well...
please feel free at your convenience to send some stuff up...
thanks
--Mike
09/02/2005 (3:52 pm)
Hey there Anthony... sounds like you've done quite a bit... i don't know how far i can go, my expertise with the engine has
primarily been in scripting... but i would be glad to take a look at
what you've got... see what i can do...
and it would be nice to see it in action as well...
please feel free at your convenience to send some stuff up...
thanks
--Mike
#56
thread link here
11/14/2005 (5:57 pm)
I'm working with a version of Ben's code above as well, and running into a problem with ghosts and my linked objects, in case somebody else has run into the same problem maybe you could respond in that thread thanks.thread link here
#57
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9093
As of this moment, the link to the download on that page is broken. If it has not been fixed already, look lower on that page for a link to my own copy of it on my own server.
tone
11/17/2005 (7:00 am)
FYI, my resource on attaching sceneobjects to others in a hierarchy of coordinate spaces has been posted.http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9093
As of this moment, the link to the download on that page is broken. If it has not been fixed already, look lower on that page for a link to my own copy of it on my own server.
tone
#58
I've gone a different route here guys... mainly due to my lack of solid progress doing this any other way...
i use an animated mount node on a model... the node is animated to move around to all the positions the 'player' needs to be on a ship or sub...
while this sorta limits the freedom of moving to every spot, it does allow me to have the player go to each of the crew positions while the ship is moving...
... and it is a lot easier :)
--Mike
11/17/2005 (8:14 am)
Anthony... that sounds really cool... i'll have to take a look at it...I've gone a different route here guys... mainly due to my lack of solid progress doing this any other way...
i use an animated mount node on a model... the node is animated to move around to all the positions the 'player' needs to be on a ship or sub...
while this sorta limits the freedom of moving to every spot, it does allow me to have the player go to each of the crew positions while the ship is moving...
... and it is a lot easier :)
--Mike
#59
I'm a newbie to the Torque engine, but it seems to me that if you're going for realistic ship motions, you would just need to change the collision behaviour to handle friction between you and the surface currently under you. It seems to be the case (I haven't tested this - it's only based on what I've read) that friction is assumed. My idea of the torque model of friction could be expressed as: "A body in motion will come to rest if no keys are pressed." whereas a different model would be: "A body in motion will gradually assume the motion of the object under it's feet if no keys are pressed."
Of course, I might be completely wrong. This might already be in version 1.5.2 and totally irrelevant. I shall have to check when I get home tonight. :o)
Jonathan
01/25/2008 (4:47 am)
Is the problem that friction does not exist for collisions between two DTS shapes, rather than the inability to mount an object?I'm a newbie to the Torque engine, but it seems to me that if you're going for realistic ship motions, you would just need to change the collision behaviour to handle friction between you and the surface currently under you. It seems to be the case (I haven't tested this - it's only based on what I've read) that friction is assumed. My idea of the torque model of friction could be expressed as: "A body in motion will come to rest if no keys are pressed." whereas a different model would be: "A body in motion will gradually assume the motion of the object under it's feet if no keys are pressed."
Of course, I might be completely wrong. This might already be in version 1.5.2 and totally irrelevant. I shall have to check when I get home tonight. :o)
Jonathan
#60
The collision setup doesn't handle realistic physics details like dynamic friction. It's all extremely simplified for performance in stock TGE, which means you won't have objects passing force on to each other at all.
The easiest solution is to implement a physics engine, for example with the PhysX resource that's out there, and make your players and vehicles (or whatever you want to apply force to each other) PhysX objects. At this point, they'll interact pretty realistically simply because of the quality of the physics sim.
That said, if you don't want to go that far, there has been a resource release based on that sceneobject attachment code that works quite well for faking this effect. You'll find it in the "Platforms Players can Ride" thread by Ramen-sama.
While this setup is designed to attach a player to a moving platform on a defined path, you can easily change the object types involved to attach a player to a moving vehicle. You'll need to fix the vehicle->player collision checks (ie totally remove them) so that the vehicle doesn't think it's "stuck" on the player, but the effect is pretty solid for an aircraft carrier, submarine, or whatever you want to do with it.
Whether this effect is worth the trouble is a totally different discussion. There could certainly be synchronization errors in real-world multiplayer (never tested that). A cheaper approach is to simply fake it; put the player into a static model of the ship outside the normal bounds of the level and have them interface by remote with the actual Vehicle object. The disadvantage here is obvious: you can't actually see anything that should be happening outside the vehicle (if it has windows, for example) unless you're controlling it from 3rd person view. This really wouldn't work for anything but a submarine or spaceship, as either one of those can get away with having no windows.
Note that in TGEA you could get away with placing a camera on the actual Vehicle object and rendering its view on a viewscreen, though this is a potential performance sink.
02/21/2008 (5:01 pm)
3 year resurrection, however this is still a good topic.The collision setup doesn't handle realistic physics details like dynamic friction. It's all extremely simplified for performance in stock TGE, which means you won't have objects passing force on to each other at all.
The easiest solution is to implement a physics engine, for example with the PhysX resource that's out there, and make your players and vehicles (or whatever you want to apply force to each other) PhysX objects. At this point, they'll interact pretty realistically simply because of the quality of the physics sim.
That said, if you don't want to go that far, there has been a resource release based on that sceneobject attachment code that works quite well for faking this effect. You'll find it in the "Platforms Players can Ride" thread by Ramen-sama.
While this setup is designed to attach a player to a moving platform on a defined path, you can easily change the object types involved to attach a player to a moving vehicle. You'll need to fix the vehicle->player collision checks (ie totally remove them) so that the vehicle doesn't think it's "stuck" on the player, but the effect is pretty solid for an aircraft carrier, submarine, or whatever you want to do with it.
Whether this effect is worth the trouble is a totally different discussion. There could certainly be synchronization errors in real-world multiplayer (never tested that). A cheaper approach is to simply fake it; put the player into a static model of the ship outside the normal bounds of the level and have them interface by remote with the actual Vehicle object. The disadvantage here is obvious: you can't actually see anything that should be happening outside the vehicle (if it has windows, for example) unless you're controlling it from 3rd person view. This really wouldn't work for anything but a submarine or spaceship, as either one of those can get away with having no windows.
Note that in TGEA you could get away with placing a camera on the actual Vehicle object and rendering its view on a viewscreen, though this is a potential performance sink.
Torque Owner Berserk