Crouching & Bound/Collision Problems
by Chris Jones-Gill · in Torque Game Engine · 01/05/2005 (4:39 am) · 6 replies
Hi guys and gals,
this i need some real help with otherwise, i'm tempted to scrap my project and torque altogether!!! :-(
I implemented the Adding new positions and moves; ie swim, crouch, crawl, prone resource which works realy well, I have done all the animations i need and they work well, although the animations themselves are pants, ;-)
anyway, as the top of the resource stats "It also updates the collision/hitbox of the player, allowing them to actually fit under tight spots." It doesn't, well not in TGE Version 1.3, so question - has gg changed the way it handles the player bounding box/collision stuff?
Is there away that this can actualy work?
I did a lot of searches for crouch crouching, etc and from the gist of what little there was it seems that no matter what you do to dynamicly resize the mObjBox the model still wont fit under tight spots!!!
To be totaly honest i feel that gg has dropped the ball on this side of things as all of the fps games i have played, and still do have this functionality built in, I also own 3dGameStudio A6 Commercial, and that has the above positions built into it, so why not Torque? isn't it a real basic requirement?.
Now i'm no C++ programmer, (although i can fumble around with it) and unfortunatly do not know a good one, and also not having the money to invest in hiring one, my project has stopped dead.
So a real big please please help, and don't post a reply unless it's constuctive
Thanks
this i need some real help with otherwise, i'm tempted to scrap my project and torque altogether!!! :-(
I implemented the Adding new positions and moves; ie swim, crouch, crawl, prone resource which works realy well, I have done all the animations i need and they work well, although the animations themselves are pants, ;-)
anyway, as the top of the resource stats "It also updates the collision/hitbox of the player, allowing them to actually fit under tight spots." It doesn't, well not in TGE Version 1.3, so question - has gg changed the way it handles the player bounding box/collision stuff?
Is there away that this can actualy work?
I did a lot of searches for crouch crouching, etc and from the gist of what little there was it seems that no matter what you do to dynamicly resize the mObjBox the model still wont fit under tight spots!!!
To be totaly honest i feel that gg has dropped the ball on this side of things as all of the fps games i have played, and still do have this functionality built in, I also own 3dGameStudio A6 Commercial, and that has the above positions built into it, so why not Torque? isn't it a real basic requirement?.
Now i'm no C++ programmer, (although i can fumble around with it) and unfortunatly do not know a good one, and also not having the money to invest in hiring one, my project has stopped dead.
So a real big please please help, and don't post a reply unless it's constuctive
Thanks
#2
i suppose what I ment was by dropping the ball, is every game engine i've seen has crouching availible, or that the bounds is generated from the models animated position relavent to an eye node,
in torque this isn't the case more to the point that the bounds realy becomes a static setting,
(ie the bounds box is static based on your player.dts and its also set in the player.cs file), static settings are fine for things like cars boats helicopters etc, but not for bipeds, quadipeds - (dogs :-) )
I did originaly think that the dsq's when generated for each animation, that the engine would use that bounds box size, and as that is not the case, why link the bounds and set its inheritance
maybe it would work if all the animation was in 1 dsq file, but i hate that method, becuase if you want to tweek 1 animation it could throw up all sorts of problems,
realy I suppose that it should be more of a question, that why can't the collision of a model be dynamic based upon a node in that model, in Max6 biped generates a headnode so why can't the engine say oh right i got the head node so we'll set that as the top of the collision/bounds? - ok i know the answer thats a lot of memory used, but maybe it aint if it's only called when the key to goto that position is called?
Any thanks for your suggestions I did look into the shapeBase stuff, but got lost, if i had some sort of uml diag of the way it all flows I'd be ok,
I'll have a look and give it another day, (that'll total it to a week trying to figure it out)
thanks
01/05/2005 (9:10 am)
I understand the point that you can code it all as you want but, i suppose what I ment was by dropping the ball, is every game engine i've seen has crouching availible, or that the bounds is generated from the models animated position relavent to an eye node,
in torque this isn't the case more to the point that the bounds realy becomes a static setting,
(ie the bounds box is static based on your player.dts and its also set in the player.cs file), static settings are fine for things like cars boats helicopters etc, but not for bipeds, quadipeds - (dogs :-) )
I did originaly think that the dsq's when generated for each animation, that the engine would use that bounds box size, and as that is not the case, why link the bounds and set its inheritance
maybe it would work if all the animation was in 1 dsq file, but i hate that method, becuase if you want to tweek 1 animation it could throw up all sorts of problems,
realy I suppose that it should be more of a question, that why can't the collision of a model be dynamic based upon a node in that model, in Max6 biped generates a headnode so why can't the engine say oh right i got the head node so we'll set that as the top of the collision/bounds? - ok i know the answer thats a lot of memory used, but maybe it aint if it's only called when the key to goto that position is called?
Any thanks for your suggestions I did look into the shapeBase stuff, but got lost, if i had some sort of uml diag of the way it all flows I'd be ok,
I'll have a look and give it another day, (that'll total it to a week trying to figure it out)
thanks
#3
Try turning on the wire model of it in game, at the console type GameBase::gShowBoundingBox = 1;
The bounding box of a player is hardcoded in script, mainly for speed purposes. Its simply _much_ faster for calculations. My code should be changing that on the fly, irregardless of your animations and what not.
A more exacting method, and probably closer to what other engines do, is to use numerous smaller bounding boxes based on the nodes/bones. This resource appears to do just that, although I haven't read it closely yet. Vehicles and such pretty much operate under the same manner, so the speed difference may not actually be that bad.
Also, keep in mind the bounding box you create when modeling (standard TGE) has nothing to do whatsoever with your collision, That is simply a method of grouping used scene compentents for the exporter.
Edit: When I was originally testing that code, I created a new variable gShowMyBoxOnly, and added it to the code ONLY for the players bounding box. This helped immensely in viewing only what I cared to see.
01/05/2005 (9:49 am)
It's been quite awhile since I wrote that resource, but I see no reason it shouldn't still work. At least the bounds aspect.Try turning on the wire model of it in game, at the console type GameBase::gShowBoundingBox = 1;
The bounding box of a player is hardcoded in script, mainly for speed purposes. Its simply _much_ faster for calculations. My code should be changing that on the fly, irregardless of your animations and what not.
A more exacting method, and probably closer to what other engines do, is to use numerous smaller bounding boxes based on the nodes/bones. This resource appears to do just that, although I haven't read it closely yet. Vehicles and such pretty much operate under the same manner, so the speed difference may not actually be that bad.
Also, keep in mind the bounding box you create when modeling (standard TGE) has nothing to do whatsoever with your collision, That is simply a method of grouping used scene compentents for the exporter.
Edit: When I was originally testing that code, I created a new variable gShowMyBoxOnly, and added it to the code ONLY for the players bounding box. This helped immensely in viewing only what I cared to see.
#4
OK now i'm confussed, the only way i was able to fit under these objects was if the bounds box on my model was set before export to fit under (eg the same width length but height no higher than the models waist), and ofcourse, unless i shot kork in the foot or below the waist he wouldn't die,
the screen shots below show the bounding box around the player and the other objects. and although they aren't that clear it's obvious to see that your resource (which taught me how to add key bindings into c++ code, so i could do a walk function with animation) is working,
and thats what is confussing me - what is stopping it from going through?
standing in front of the objects
crouching and as far as i can go through
crawling and as far as i can go through
although its my own model i did try it with the default orc player as well
01/05/2005 (12:07 pm)
Hi Erik, OK now i'm confussed, the only way i was able to fit under these objects was if the bounds box on my model was set before export to fit under (eg the same width length but height no higher than the models waist), and ofcourse, unless i shot kork in the foot or below the waist he wouldn't die,
the screen shots below show the bounding box around the player and the other objects. and although they aren't that clear it's obvious to see that your resource (which taught me how to add key bindings into c++ code, so i could do a walk function with animation) is working,
and thats what is confussing me - what is stopping it from going through?
standing in front of the objects
crouching and as far as i can go through
crawling and as far as i can go through
although its my own model i did try it with the default orc player as well
#5
Is your model still staying in the crouched or prone position when you move, can you move around the map in those positions?
Eddie.
02/06/2005 (11:53 am)
I've not gone and tested this yet, but is of interest to me. Is your model still staying in the crouched or prone position when you move, can you move around the map in those positions?
Eddie.
#6
yep I can move around the whole map in those positions, I did sort of fix it however, i think the fix is wrong,
I have yet to test it in linux, (don't have a mac yet) and I also wanted to build a new model, and do all the animations from scratch to test it with,
before I post it up, and I've been too busy with work latley, anyway
it only fixes the crouch position and not the crawl position, which makes me belive my fix is definantly wrong.
anyway who needs crawling in there game right? (nice to have it though)
the fix is in the function
I called
Hope this sort of gives an idication
02/06/2005 (6:33 pm)
Hi Eddie,yep I can move around the whole map in those positions, I did sort of fix it however, i think the fix is wrong,
I have yet to test it in linux, (don't have a mac yet) and I also wanted to build a new model, and do all the animations from scratch to test it with,
before I post it up, and I've been too busy with work latley, anyway
it only fixes the crouch position and not the crawl position, which makes me belive my fix is definantly wrong.
anyway who needs crawling in there game right? (nice to have it though)
the fix is in the function
void Player::setPlayerPosition(S32 position)in player.cc after the mObjBox stuff
I called
onScaleChanged();and i am able to go through small places, in crouch position only, obviously provided the bounding box height in that position is lsmaller than the hole ;-)
Hope this sort of gives an idication
Torque Owner Brett Fattori
Now, onto the constructive stuff...
Examining the root of ShapeBase might be of more constructive. Take a look in the "ts" subdirectory of the engine. In there you will find tsShape which is where all shapes derive from.. Well, I should say they derive from tsMesh, but the collision details are loaded up as part of a shape. Now, since we don't want to be occupying tons and tons of memory for these shapes, we use tsShapeInstance to create instances of shapes.
I would suggest looking at both tsShape and tsShapeInstance and do a little research into collision details. You may be able to scale the collision details down, and then shift them down in Z to make them closer to the ground and give you more clearance. Additionally, I thought when you modeled the object, you were responsible for creating the bounding box/shape for your player. So this might just be a modeling issue and not even a coding issue.
You might also want to look at using the objectBox (which is created as a member of sceneObject in the "sim" subdirectory). But I think those are only used for castRay and projectile collisions. Anyways, this should give you a starting point. Remember, a little research goes a long way in understanding the engine that much better. :-)
- Brett