Walking Vehicle Development Discussion
by Robert Brower · in Torque Game Engine · 08/24/2002 (8:19 pm) · 11 replies
Hello, I'm Robert. I'm working on a new kind of vehicle for my game project, a walking vehicle. I'd like to a development discussion on this topic and form a tiger-team of interested people who can work together to solve this problem.
There are 2 approaches to creating a walking vehicle that I am aware of.
1. You could create an animated character model and create a new vehicle datablock. It could
be done entirely in script I think.
2. You could create leg models comprised of various pieces and move them programatically.
This is kind of like what is done in the racing mod. The vehicle has 4 wheels.
Each wheel has a shape and a hub and a spring and these objects are moved programatically based on applied forces, etc.
See WheeledVehicle::advanceTime(), WheeledVehicle::updateForces(), and WheeledVehicle::extendWheels() in wheeledVehicle.cc.
There are pros and cons to both approaches. Let's talk about them. Although 1 is easier and faster to impliment, could you imagine if the wheels and shock absorbers in the racing mod didn't move up and down independently based on the terrain and applied forces? It would be like going back in time to the days of ATARI's Pole position Racing game. You just don't get the same physical and visual effects or realism. 2 is more complex, introduces more code, more mathematics and will take some time to develop and tweak to spec but the image in my mind is so much more real, so much more like the racing mod in that the legs of the vehicle will truly walk, with their feet touching the ground. There will be a spring in it's step and it will sort of bounce a little bit based on terrain and
applied forces like the wheels do in the racing mod.
I intend to, at first, create a bipedal vehicle like what was used in the star wars story line. Once the legs are understood and characterized and coded, it should just be a matter of adding them to any walking vehicle, just as wheels are to wheeledvehicles.
The body can be a box for all I care, BUT!!! The body will move up and down based on the overall springyness of the legs. for example, if you jump off of a ladder, your knees will buckle underneath you when you hit the ground. The ammount of buckling at the knee is a function of the springyness of the leg and the applied downward force of the body. To achieve a steadycam effect on the body of the vehicle with the feet gripping the terrain is the goal. With the right tweaking we can get the body to bounce up and down slightly like a horse and then 4 legged vehicles will be a snap.
If this sounds interesting and useful to you then I invite you to join me in this discussion. I hope to hear from you!
Robert
There are 2 approaches to creating a walking vehicle that I am aware of.
1. You could create an animated character model and create a new vehicle datablock. It could
be done entirely in script I think.
2. You could create leg models comprised of various pieces and move them programatically.
This is kind of like what is done in the racing mod. The vehicle has 4 wheels.
Each wheel has a shape and a hub and a spring and these objects are moved programatically based on applied forces, etc.
See WheeledVehicle::advanceTime(), WheeledVehicle::updateForces(), and WheeledVehicle::extendWheels() in wheeledVehicle.cc.
There are pros and cons to both approaches. Let's talk about them. Although 1 is easier and faster to impliment, could you imagine if the wheels and shock absorbers in the racing mod didn't move up and down independently based on the terrain and applied forces? It would be like going back in time to the days of ATARI's Pole position Racing game. You just don't get the same physical and visual effects or realism. 2 is more complex, introduces more code, more mathematics and will take some time to develop and tweak to spec but the image in my mind is so much more real, so much more like the racing mod in that the legs of the vehicle will truly walk, with their feet touching the ground. There will be a spring in it's step and it will sort of bounce a little bit based on terrain and
applied forces like the wheels do in the racing mod.
I intend to, at first, create a bipedal vehicle like what was used in the star wars story line. Once the legs are understood and characterized and coded, it should just be a matter of adding them to any walking vehicle, just as wheels are to wheeledvehicles.
The body can be a box for all I care, BUT!!! The body will move up and down based on the overall springyness of the legs. for example, if you jump off of a ladder, your knees will buckle underneath you when you hit the ground. The ammount of buckling at the knee is a function of the springyness of the leg and the applied downward force of the body. To achieve a steadycam effect on the body of the vehicle with the feet gripping the terrain is the goal. With the right tweaking we can get the body to bounce up and down slightly like a horse and then 4 legged vehicles will be a snap.
If this sounds interesting and useful to you then I invite you to join me in this discussion. I hope to hear from you!
Robert
#2
I think programatic 2(+!) legged walking would be mighty difficult to get looking good.
08/25/2002 (4:30 am)
Could you not just replace the player model when he entered the 'vehicle' and then use the standard DTS animations for the walking etc.?I think programatic 2(+!) legged walking would be mighty difficult to get looking good.
#3
That way, you animate the leg movements as per normal, but on slopes you have different foot placements and center of mass.
Of course doing some sort of kinematic thing would be cool too, but its really not necassary.
Phil.
08/25/2002 (6:52 am)
Best Approach, IMHO is to have a normal DTS animation (like the players legs) but have a blend between two different extreme angles (say 45 degree's up and down), which would animate the feet and balance centers.That way, you animate the leg movements as per normal, but on slopes you have different foot placements and center of mass.
Of course doing some sort of kinematic thing would be cool too, but its really not necassary.
Phil.
#4
08/25/2002 (7:00 am)
Right, that should do the trick too offcourse.
#5
You might be able to get a working hexapod, but simulating a running animal (like a horse) that looks good is going to be very difficult.
Doing it in code presents the problem of getting it to work so it doesn't fall over.
It may work, but there is no guarentee that the final solution is going to be any fun to play.
08/25/2002 (8:17 am)
My own opinion would be to just animate it by hand. You might be able to get a working hexapod, but simulating a running animal (like a horse) that looks good is going to be very difficult.
Doing it in code presents the problem of getting it to work so it doesn't fall over.
It may work, but there is no guarentee that the final solution is going to be any fun to play.
#6
Besides the basic difficulty of getting a generic IK system programmed, you'd probably have to add to the DTS format to carry along all the joint and joint constraint information.
Definately not a simple task, though.
08/25/2002 (8:55 am)
Well, if you were to write a generic enough Inverse Kinematics system into Torque, you could definately get programatic foot placement to work, and to look quite good.Besides the basic difficulty of getting a generic IK system programmed, you'd probably have to add to the DTS format to carry along all the joint and joint constraint information.
Definately not a simple task, though.
#7
08/25/2002 (9:18 am)
Joe, when you just animate it and do nothing in the code it looks bad... with feet sticking in the ground or too far above the ground. Phill's solution would be the best. As it is both code and a regular animation.
#8
I am cleaning up a code snippet release to conform the player model to the teraain which would solve many of the interpenetration issues.
I am suggesting that a total code solution might not be the best approach. If someone were to get it to work, I'd be all for it, but I don't see a robust legged character vehicle system being in a workable state anytime soon.
08/25/2002 (9:57 am)
I am not suggesting nothing be done in code. I am cleaning up a code snippet release to conform the player model to the teraain which would solve many of the interpenetration issues.
I am suggesting that a total code solution might not be the best approach. If someone were to get it to work, I'd be all for it, but I don't see a robust legged character vehicle system being in a workable state anytime soon.
#9
Last night I brought up the subject in #GarageGames chat. Here is what people had to say about our idea. There's the beginning of an algorthm in the following chat text.
In order to procede with any of the 3 options we have before us we need very simple models to work with. They don't have to be any more complicated than boxes that fit together like a stick figure. We need a box for a body, a box for the thigh, the shin, and the foot.
Will anyone volunteer to create these difs?
--------------------------------------------------------
Im starting a mini project... creating walking vehicles. You're all invited to join the discussion...
http://garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=6818
crime games are big right now
i cant get the bar ontop my heart
its above it
nm
i had wrong position
anyways
im such a crackhead lol
gonna play som OMF
i didnt make background invisible lol
* KallDrexx has quit IRC (no Client Exiting)
how do you control the z-order of drawing?
is it just the order you define them in?
.3ds file is 3dstudios?
whats the name of the program? 3dstudios something or another
* Disconnected
* /join: not connected to server
Session Close: Sun Aug 25 00:01:33 2002
Session Start: Sun Aug 25 00:01:55 2002
Session Ident: #garagegames
* Now talking in #garagegames
* Topic is 'http://www.garagegames.com -- Indie Games Central'
* Set by rickg on Fri Aug 23 22:31:13
* Defiant has joined #garagegames
grrrr.... i can smell cat puke but i cant find it
brb hunting for it
* ChanServ sets mode: +o CapnRook
* ChanServ sets mode: +o rickg
lol
ewww nice thought
gross
heh
* ChanServ sets mode: +qo Adrian-MGT Adrian-MGT
* Adrian-MGT has left #garagegames
its driving me mad as i sit here and try to use the PC
* spock is now known as Guest17634
driving you to me?
ouch
now rook's gotta worry about the puke and the stench of that pun
:D
* astonge has joined #garagegames
cant find it... but i did find a nice strong fan to keep me upwind :)
* Guest17634 is now known as Spock
* ChanServ sets mode: +ao Spock Spock
<_|moomoo|_> .
* SaiyaJin has joined #garagegames
* SaiyaJin has quit IRC (Quit: Im a freedom fighter no remorse raging on in holy war soon there'll come a day when your face to face with ME!!!!)
the thingamathon is tomorrow
huh?
<_|moomoo|_> huh!
thingamathon on scifi channel
reboot
it ends with widescreen version of The Thing....you get a chance to win The Thing video game
* Disconnected
Session Close: Sun Aug 25 00:14:23 2002
Session Start: Sun Aug 25 00:17:53 2002
Session Ident: #garagegames
* Now talking in #garagegames
* Topic is 'http://www.garagegames.com -- Indie Games Central'
* Set by rickg on Fri Aug 23 22:31:13
* alexs has joined #garagegames
* ChanServ sets mode: +o alexs
* Deviun has joined #garagegames
* pauldana has joined #garagegames
* _|moomoo|_ has quit IRC (no _|moomoo|_ has no reason)
if an object is moving in circles on a given plane, then how do you calculate the x,y cartesian coordinate of the object on that plane? Its based on radius and angle ... anyone know the formula?
* _|moomoo|_ has joined #garagegames
yes... just a sec
<_|moomoo|_> heh, there is a 'raistlin' on's about msg
y=r cos (theta)
x=r sin (theta)
thanks
theta must be in radians
didnt have to get up and walk to the other side of the room and grab books off the shelf. thanks.
hope you didnt =)
sohcahtoa
<_|moomoo|_> theta the angle between r and y axie?
r=radius
sohcahtoa?
<_|moomoo|_> when is theta=0>
360
o degree
<_|moomoo|_> point to y dir or x dir?
its relative
* Deviun has quit IRC (Quit: )
sin oposite hypotonuse, cosine adjacent hypotinuse, tangent opesite adjancent
<_|moomoo|_> relate to y or x?
soh,cah,toa
<_|moomoo|_> if theta relate to x, its opposite
sin=o/h, cos=a/h, t=o/a
good stuff
lol
degrees to radians
?
you have this in your head?
<_|moomoo|_> if theta relate to x, x=r*cos(theta)
there are 360 degrees in a circle and 2 pi radians
<_|moomoo|_> in most math, theta is related to x
hes a mad wizard, of course he does
360 = 2pi?
<_|moomoo|_> which makes mad wrong
yep
so pi times 2 = 360.00?
i some times get them backward
2*pi*rad = 180
pi times 2 is like 6.8 somet6hing
er 360
lol
2*pi*radius=360?
yes
great thanks =)
what do you know about ovals?
a form of circle
(x + a)^2 + (y + b)^c = r^2
what is the factor that dictates how elongated it is?
yep
no way, that was for circles..
y becomes bigger than y
x becomes biger than y
sorry
i need to plot an oval basically
we know how to plot a circle. you covered that.
how do we go from circle to oval
on paper?
<_|moomoo|_> scale the r while going around :)
lets say i want an object to move in an oval on a given plane. I need to know degrees or radians, radius for circle. what is the 3rd parameter for plotting oval?
there's a better way to do it
ah scaling
robert: http://gamedev.net/community/forums/search.asp?mode=doit
err, that won't work
a correct statement
from the gamedev forums: The parametric equation for an ellipse is x=a*cos(t) and y=b*sin(t)
so solve that to a standard equation and you're all set :P
thanks bro
thats it!
x2/a2 + y2/b2 = 1,
those should be ^2
and the 1 should be r^2
x^2/a^2 + y^2/b^2 = r^2
its amazing how fast geometry slips out of the mind
i decided to work with the idea that a foot (part of the leg in a bipedal creature) moves in a circular or oval direction on a set plane. It is obstructed by the ground during it's cycle of travel whereupon there is a weight transfer onto the foot equal to half the overall weight of the body inversely proportional to the ammount of weight taken off of the lagging leg
thereby maintaining balance
inversely proportional?
you'd be doubling the weight after each step
yeah in other words as weight is taken off the rear leg it's put onto the front foot
* JMargaris has joined #garagegames
ahh ok nevermind i misunderstood that
it's not cumulative through more than 1 cycle.
does this idea or my concept of the math seem sane?
as far as a simulation goes?
then... here's the kicker
i like the way the wheels in the racing demo work. I can use a similar mechanism of ray casting from the middle of the decending foot to the terrain at it's point of maximum extension. If the foot is above the ground then the location of foot changes, it goes down and hugs the terrain like a shock absorber with some bounce.
ah my dream
<_|moomoo|_> ray cast?
it shouldnt be that hard..
though a foot spreads weight out
im not sure if approximating it with a point will work
yes in a perfect model
you won't get ankle-bending initially
<_|moomoo|_> ray cast on poly is expns
i can use the angle of the shin bone against the terrain to figure out the angle of the angle joint
ray cast is done in the racing demo on all 4 wheels
you trying to make feet follow the terrain?
I only need 2 legs
yes
feet follow terrain
that would be great because right now it looks pretty bad
ray casting on a poly only does like 2 vector functions and a dot product, i think
could be, either way im doing less my vehicle will have only 2 legs
although the idea of a one legged hopper is interesting
lol
imagine a pogostick pack in tribes 2 haha
thats actually very doable.
just in script
you'd be pushing it if you did it in script..
the physics would be pretty jumpy
the wheels in the racing mod are scripted
its interpolated to good nice
<_|moomoo|_> prob is find out which poly to cast
<_|moomoo|_> poly changes as LOD changes too
you cast from the center of the bottom of the tire, you cast from teh center of the bottom of the foot. That would be a parameter so you could tweak it.
you use the bounding boxes
<_|moomoo|_> if the ray is verticle downwards, there is no need to do interccpt
<_|moomoo|_> just use the plane equation and set y=0
yes
is 0 always relative to the terrain ? or worldspace in your statement
<_|moomoo|_> oh.. .z, not y, its the twisted right hand in torque
in other words the same thing as the tire code
<_|moomoo|_> Ax+By+Cz+D=0
thats what they are doing
<_|moomoo|_> you know x and y
<_|moomoo|_> want to get have z
<_|moomoo|_> just put all data into that equation, save you from ray cast
no you know x and y right... you have to have the intersection of x and the y of the terrain at that spot
(a-x)(b-x)(c-x)....(y-x)(z-x)=?
<_|moomoo|_> no need
<_|moomoo|_> A, B, C D are constant on one plane
<_|moomoo|_> you have x, and y,
<_|moomoo|_> so -Z=(Ax+By+D)/c
<_|moomoo|_> and the pont will by x,y,z
okay
y is actually z in worldspace tho right?
<_|moomoo|_> y is upward
<_|moomoo|_> oh.. no
<_|moomoo|_> y is north
<_|moomoo|_> z is upward
<_|moomoo|_> x is east
im mean its all relative but in a leg, x and y are the coords based on the circle that the foot is making while your looking at the profile of the subject
strictly mathmatical philosophy speaking... those dorections are any diredction you choose them to be
<_|moomoo|_> if y is north, x must be east
<_|moomoo|_> wiseversa
<_|moomoo|_> z must be upward intorque
given any plane... a ray in any direction can be named x
the model pieces of the legs must fit together so I guess spherical or rounded joints are desired so they seem to blend
a ray normal to x and on the plane is y
<_|moomoo|_> model space coord doenst need to be insync with world space
a ray normal to both x and y is z
true
<_|moomoo|_> model space * world transform matrix = world space
woooooo
math lesson by moo!
* pauldana has quit IRC (Connection timed out)
<_|moomoo|_> with in centain space, it always z up, y front, x left
<_|moomoo|_> in torque
scaling of the x or y param in the oval can be a function of forward velocity so that the legs appear to reach further when the vehicle is sprinting
a new parameter to the datablock
what do you think of that idea?
* alexs is now known as alexs[cs]
<_|moomoo|_> the question is if the scripts can be interpated fast enought to do inverse kinematic
is that what i am doing here? inverse kinematic?
<_|moomoo|_> you r trying to
<_|moomoo|_> which i think is a bad idea :)
trying to keep it as simple as possible. I think it's a great idea =)
<_|moomoo|_> depends on the number of level of the hierarchy, it could be very costly
the racing demo uses a lot of the ideas mentioned in this discussion. it does ray casting on all 4 wheels. it also uses interpolation to make it smooth.
<_|moomoo|_> keep in mind, in IK, the end point affects their parent objects, and the parent objects also affect their child
the tires are rotated and moved up and down. the springs also. I don't really think this is much different.
* CapnRook has quit IRC (Quit: night)
<_|moomoo|_> only 2 or 3 levels on the hierachy
<_|moomoo|_> for a suspension
<_|moomoo|_> ther r 4 or 5 levels on a human hierarchy
yep. i only plan to have 3 joints per leg.
<_|moomoo|_> depends how detail you want to go
3 jointed legs
<_|moomoo|_> thats 4 levels
hip, knee, angle
I'm listening =)
<_|moomoo|_> that also need to some how deal with the predefined animation set
<_|moomoo|_> and make sure the predefined animation doesnt override the ik calc
yes. the math we've been talking about deals with with.
<_|moomoo|_> troublesome
we can use the bounding boxes
<_|moomoo|_> generally not worth the effort, huge amount of work, little bit improvement :)
defined joint diameters
little bit improvement?
<_|moomoo|_> visually
let me ask you... imagine the racing mod without the wheels and shock absorbers and car all moving up and down.
<_|moomoo|_> it works on terrain
<_|moomoo|_> what if you got into a building?
<_|moomoo|_> what if there is sevel level of building, r you try to locate the polygon by going throught all polygons in the building?
vehicles can go inside building the rules of physics dont change
How do you mean?
<_|moomoo|_> try it and find out :)
if it works and looks nice then i will have created something new
<_|moomoo|_> it needs to be 'efficient'
thats for sure
and precise
wont look good if the joints dont fit together all the time
<_|moomoo|_> the amout of processing power is multiply as the number of ik model used
<_|moomoo|_> in most time, the human will be a tiny little dot on the scren
i plan on using 3 very simple models for the first prototype, then increase complexity of the model to gage the speed
well 4 coutjing the body
I'll be glad when i get this put together =)
<_|moomoo|_> mw4's method is much cheapr
Anyways, I plan on saving this chat text so I can post it in the forum in the discussion thread.
what or who is mw4 and where is the method?
<_|moomoo|_> just sync the foot's z with teh surface's normal whenever the foot hits something
<_|moomoo|_> realistic enought and its very cheap
<_|moomoo|_> 2 cross products, done
can you explain that again... lil bit more simpler =)
<_|moomoo|_> mw4 = mechwarrior4
how does that look when you're running up a hill
<_|moomoo|_> it looks you runing up a hill
okay so your talking about syncing the z of the foot to the terrain. how does that doffer from the wheels in the racing mod? thats what they are doing there
<_|moomoo|_> only syn the dir
<_|moomoo|_> not change the parent's position
robert, do you want to make the feet at the right height or the right angle? or both?
both
<_|moomoo|_> better of changin the code
<_|moomoo|_> instead of messing around with script
oh yeah im into the c++ stuff heavily now reading all this stuff.
I see where the code needs to go
the wheels on a car are different because the springs can compress and stretch
for a leg it isn't that simple
if the leg needs to go higher you can just shove it upwards
can't
WheeledVehicle::advanceTime(), WheeledVehicle::updateForces(), and WheeledVehicle::extendWheels() in wheeledVehicle.cc.
* Uksi has joined #garagegames
hello
<_|moomoo|_> .
hey
man I need to get out of the habit of eating nothing but coffee
try to eat sugar and coffee
I'm thinking food would be good
moomoo ... each joint is like a spring
or has a spring forcer
force
they all have to add up in that hierarchy as you said just like the wheels and springs and body in the car.
its all somehow cumaltive
on the body
gives it some springyness
springs are different, they can compress
as well as bounce
I plan to use springs
your legs can't compress, they can only bend at joints
are we talking about humans here?
the thigh, shin, and feet are all seperate objects
no not humans
ah ok
<_|moomoo|_> its not that simple, rob
3 jointed legs like on starwars
<_|moomoo|_> the problem of IK is rather complicated
How do you mean moomoo
he doesn't need to use IK
this is not IK
<_|moomoo|_> for human?
IK is a LOT more involved
not for human, for robat thing
<_|moomoo|_> that still ik
this is robot thing
you can fake it easily
<_|moomoo|_> inverse kinamitic
not as good as human.
we dont bounce much we have good algortithms
just stretch and compress each spring the same amount
<_|moomoo|_> doesnt matter if its human or robot
yes it does, because robots have springs
<_|moomoo|_> you still need to calc all the object on the hiearchy chain/kinamatic chain
no you don't, why should you?
<_|moomoo|_> to negotiate the result
this isn't a physics simulation
the point is too look good
when you climb up a ladder, and jump off from the top, your knees buckle under you (unless you hold them rigidly straight and you wouldnt do that else you'd break your leg) when you hit the ground.
your muscles are like springs
robert not really
they can apply force, they can absorb force
<_|moomoo|_> in human ik model, you have this spring thing too :)
or resist
<_|moomoo|_> thats where you define the fiction of ea h joint
<_|moomoo|_> and the expected behivour
Robert the thing is if you want the feet to end up in a certain place
muscles, apply force. is this a correct statement?
figuring out how they get there is not as easy
<_|moomoo|_> that only increase the complexity
you aren't applying force, you are choosing an end destination
with a spring it is easy, just compress or extend the spring
<_|moomoo|_> a rigid joint is much simpler to implenet
thats right JM, but I've decided to use a simple oval as the pattern looking at the problem from the side.
the oval stretching will be a factor of speed
from the oval i can plot xy of the foot
what is the oval? The hip, knee, foot?
<_|moomoo|_> use your jump example, it involve coordinated 4 objects
the oval is the foot
<_|moomoo|_> hip/upperleg/lowerleg/foot
Uski>?
Uksi?
hip joint, thigh, knee joint, shin, angle, foot
the question is how do all of those move
to get the foot to the right place
im explaining it
08/25/2002 (10:56 am)
Sounds like we have a 3rd option. This is to have 2 objects that mount togather. Animated legs in a dts, and rotating body in dts. This is also a good approach and one we should consider developing so that we can compare how it looks and feels to that of our fully animated model.Last night I brought up the subject in #GarageGames chat. Here is what people had to say about our idea. There's the beginning of an algorthm in the following chat text.
In order to procede with any of the 3 options we have before us we need very simple models to work with. They don't have to be any more complicated than boxes that fit together like a stick figure. We need a box for a body, a box for the thigh, the shin, and the foot.
Will anyone volunteer to create these difs?
--------------------------------------------------------
* KallDrexx has quit IRC (no Client Exiting)
* Disconnected
* /join: not connected to server
Session Close: Sun Aug 25 00:01:33 2002
Session Start: Sun Aug 25 00:01:55 2002
Session Ident: #garagegames
* Now talking in #garagegames
* Topic is 'http://www.garagegames.com -- Indie Games Central'
* Set by rickg on Fri Aug 23 22:31:13
* Defiant has joined #garagegames
* ChanServ sets mode: +o CapnRook
* ChanServ sets mode: +o rickg
* ChanServ sets mode: +qo Adrian-MGT Adrian-MGT
* Adrian-MGT has left #garagegames
* spock is now known as Guest17634
* astonge has joined #garagegames
* Guest17634 is now known as Spock
* ChanServ sets mode: +ao Spock Spock
<_|moomoo|_> .
* SaiyaJin has joined #garagegames
* SaiyaJin has quit IRC (Quit: Im a freedom fighter no remorse raging on in holy war soon there'll come a day when your face to face with ME!!!!)
<_|moomoo|_> huh!
* Disconnected
Session Close: Sun Aug 25 00:14:23 2002
Session Start: Sun Aug 25 00:17:53 2002
Session Ident: #garagegames
* Now talking in #garagegames
* Topic is 'http://www.garagegames.com -- Indie Games Central'
* Set by rickg on Fri Aug 23 22:31:13
* alexs has joined #garagegames
* ChanServ sets mode: +o alexs
* Deviun has joined #garagegames
* pauldana has joined #garagegames
* _|moomoo|_ has quit IRC (no _|moomoo|_ has no reason)
* _|moomoo|_ has joined #garagegames
<_|moomoo|_> heh, there is a 'raistlin' on
<_|moomoo|_> theta the angle between r and y axie?
<_|moomoo|_> when is theta=0>
<_|moomoo|_> point to y dir or x dir?
* Deviun has quit IRC (Quit: )
<_|moomoo|_> relate to y or x?
<_|moomoo|_> if theta relate to x, its opposite
<_|moomoo|_> if theta relate to x, x=r*cos(theta)
<_|moomoo|_> in most math, theta is related to x
<_|moomoo|_> which makes mad wrong
<_|moomoo|_> scale the r while going around :)
* JMargaris has joined #garagegames
<_|moomoo|_> ray cast?
<_|moomoo|_> ray cast on poly is expns
<_|moomoo|_> prob is find out which poly to cast
<_|moomoo|_> poly changes as LOD changes too
<_|moomoo|_> if the ray is verticle downwards, there is no need to do interccpt
<_|moomoo|_> just use the plane equation and set y=0
<_|moomoo|_> oh.. .z, not y, its the twisted right hand in torque
<_|moomoo|_> Ax+By+Cz+D=0
<_|moomoo|_> you know x and y
<_|moomoo|_> want to get have z
<_|moomoo|_> just put all data into that equation, save you from ray cast
<_|moomoo|_> no need
<_|moomoo|_> A, B, C D are constant on one plane
<_|moomoo|_> you have x, and y,
<_|moomoo|_> so -Z=(Ax+By+D)/c
<_|moomoo|_> and the pont will by x,y,z
<_|moomoo|_> y is upward
<_|moomoo|_> oh.. no
<_|moomoo|_> y is north
<_|moomoo|_> z is upward
<_|moomoo|_> x is east
<_|moomoo|_> if y is north, x must be east
<_|moomoo|_> wiseversa
<_|moomoo|_> z must be upward intorque
<_|moomoo|_> model space coord doenst need to be insync with world space
<_|moomoo|_> model space * world transform matrix = world space
* pauldana has quit IRC (Connection timed out)
<_|moomoo|_> with in centain space, it always z up, y front, x left
<_|moomoo|_> in torque
* alexs is now known as alexs[cs]
<_|moomoo|_> the question is if the scripts can be interpated fast enought to do inverse kinematic
<_|moomoo|_> you r trying to
<_|moomoo|_> which i think is a bad idea :)
<_|moomoo|_> depends on the number of level of the hierarchy, it could be very costly
<_|moomoo|_> keep in mind, in IK, the end point affects their parent objects, and the parent objects also affect their child
* CapnRook has quit IRC (Quit: night)
<_|moomoo|_> only 2 or 3 levels on the hierachy
<_|moomoo|_> for a suspension
<_|moomoo|_> ther r 4 or 5 levels on a human hierarchy
<_|moomoo|_> depends how detail you want to go
<_|moomoo|_> thats 4 levels
<_|moomoo|_> that also need to some how deal with the predefined animation set
<_|moomoo|_> and make sure the predefined animation doesnt override the ik calc
<_|moomoo|_> troublesome
<_|moomoo|_> generally not worth the effort, huge amount of work, little bit improvement :)
<_|moomoo|_> visually
<_|moomoo|_> it works on terrain
<_|moomoo|_> what if you got into a building?
<_|moomoo|_> what if there is sevel level of building, r you try to locate the polygon by going throught all polygons in the building?
<_|moomoo|_> try it and find out :)
<_|moomoo|_> it needs to be 'efficient'
<_|moomoo|_> the amout of processing power is multiply as the number of ik model used
<_|moomoo|_> in most time, the human will be a tiny little dot on the scren
<_|moomoo|_> mw4's method is much cheapr
<_|moomoo|_> just sync the foot's z with teh surface's normal whenever the foot hits something
<_|moomoo|_> realistic enought and its very cheap
<_|moomoo|_> 2 cross products, done
<_|moomoo|_> mw4 = mechwarrior4
<_|moomoo|_> it looks you runing up a hill
<_|moomoo|_> only syn the dir
<_|moomoo|_> not change the parent's position
<_|moomoo|_> better of changin the code
<_|moomoo|_> instead of messing around with script
* Uksi has joined #garagegames
<_|moomoo|_> .
<_|moomoo|_> its not that simple, rob
<_|moomoo|_> the problem of IK is rather complicated
<_|moomoo|_> for human?
<_|moomoo|_> that still ik
<_|moomoo|_> inverse kinamitic
<_|moomoo|_> doesnt matter if its human or robot
<_|moomoo|_> you still need to calc all the object on the hiearchy chain/kinamatic chain
<_|moomoo|_> to negotiate the result
<_|moomoo|_> in human ik model, you have this spring thing too :)
<_|moomoo|_> thats where you define the fiction of ea h joint
<_|moomoo|_> and the expected behivour
<_|moomoo|_> that only increase the complexity
<_|moomoo|_> a rigid joint is much simpler to implenet
<_|moomoo|_> use your jump example, it involve coordinated 4 objects
<_|moomoo|_> hip/upperleg/lowerleg/foot
Torque Owner Very Interactive Person
So, the moving of the legs should be done in code and depend on the surface the thing walks on. Not an easy task, but the only way it'll look good.
Also don't forget this whole thing should be dynamic. So it should be able to have 2 to 8 legs. AND!!! not only side joints (spider) or human joints... but also reverse joint (like chicken legs). If all these things are taken into account, this new vehicle class could be used for anything from a horse, to a mech (even spider shaped mechs) or a giant turkey ;)