Why arent the wheels connected to Havok

[Roofy]

Ok I am totally lost with this havok thing. I am trying to understand what gets
attached to the havok physics engine when designing a car racing game. However,
after downloading both the jeep car and the remote control car games from
director-online havok archive site, I noticed something very stange. While
trying to decipher the code on both files it seems to me that the wheels are
not attached to the Havok physic's engine. Now I could be wrong, but I wanted
to ask you guys if this is correct, and if so, then how do the wheels follow
the car as well as stay on the ground and without going through the ground? I
am asking this becuase I could not pick it out through its lingo. There are so
many behaviours attached to the 3d world that it is impossible to know where
Director starts to read each behaviour.

I understand a little bit about havok, such as if you want something movable
then you attach a movable rigid body to it and if the object is fixed then you
would attach the fixed rigid body to it. In addition, I also know a little bit
about mass which sets the weight of the object. However, it seems to me that
both of these games are way too advamced for me especially when just for now
all I am trying to unserstand is how the wheels of a car can follow the body of
the car and also for the wheels to stay on the ground and without them going
through the ground.

[Roofy]

Ok, lets start with the small stuff first, and maybe this will answer my
original quesdtion. Looking at the jeep demo, what is the magnet object model
for? Is that what the chassis and the wheels follow on and does this magnet
model work like how real magnets do?

[Agustín María Rodríguez]

Roofy wrote:

> Ok, lets start with the small stuff first, and maybe this will answer my
> original quesdtion. Looking at the jeep demo, what is the magnet object model
> for? Is that what the chassis and the wheels follow on and does this magnet
> model work like how real magnets do?
>

IIRC, the example you´re talking about has a "chassis" whose model
consists in 4 wheels and the car itself it´s only attached to the
chassis by a spring or dashpot to give the amortiguation effect.

HTH,
--
Agustín María Rodríguez

[url]www.onwine.com.ar[/url] > Macromedia Director demos & code

[Roofy]

[Q]IIRC, the example you?re talking about has a "chassis" whose model
consists in 4 wheels and the car itself it?s only attached to the
chassis by a spring or dashpot to give the amortiguation effect.[/Q]

ok, I might be wrong on this, but after pressing play and typing the following
syntax in the message window...
form the jeep demo ....
put member("blankHavok").lineardashpot
put member("blankHavok").spring.count

and from the RemoteControl Car demo
put member("carHKE").lineardashpot
put member("carHKE").spring.count



... doing this in both files and after pressing play, I get an emplty list
returned back for the dashpot and 0 for the count of the spring. So I don't
think there are any dashpots nor springs on either demo. However, what I am
concluding is that I think they are using 2 custom handlers called
initializeHover and updateHover which is somehow detecting the chassis and its
wheels if they collide or not. I did a test by disabling both of these custom
handlers and by doing so, the chassis would fall through the wheels and land on
the ground instead. On the other hand, if these 2 custom handlers are causing
this effect, then I srill don't understand how the the wheels are following the
chassis. Therefore, I am wondering if it would be easier to use modelsUnderRay
considering that all I am trying to do is do collision detection? What do you
think?

[Agustín María Rodríguez]

Roofy wrote:

> [Q]IIRC, the example you?re talking about has a "chassis" whose model
> consists in 4 wheels and the car itself it?s only attached to the
> chassis by a spring or dashpot to give the amortiguation effect.[/Q]
>
> ok, I might be wrong on this, but after pressing play and typing the following
> syntax in the message window...
> form the jeep demo ....
> put member("blankHavok").lineardashpot
> put member("blankHavok").spring.count
>
> and from the RemoteControl Car demo
> put member("carHKE").lineardashpot
> put member("carHKE").spring.count
>
>
>
> ... doing this in both files and after pressing play, I get an emplty list
> returned back for the dashpot and 0 for the count of the spring. So I don't
> think there are any dashpots nor springs on either demo.

Sorry, I thought you were talking about this demo:

[url]http://director-online.com/havok/demos/demo-dashcar.html[/url]

> However, what I am
> concluding is that I think they are using 2 custom handlers called
> initializeHover and updateHover which is somehow detecting the chassis and its
> wheels if they collide or not. I did a test by disabling both of these custom
> handlers and by doing so, the chassis would fall through the wheels and land on
> the ground instead. On the other hand, if these 2 custom handlers are causing
> this effect, then I srill don't understand how the the wheels are following the
> chassis. Therefore, I am wondering if it would be easier to use modelsUnderRay
> considering that all I am trying to do is do collision detection? What do you
> think?

Actually, this RayCastCar demo uses modelsUnderRay() for collision
detection of the wheels with the ground:

-- For each wheel do
repeat with i = 1 to pWheelPointList.count
pIsHoveringList[i] = false
worldWheelPoint = pChassisMDL.transform * pWheelPointList[i]
intersectDetails = pMember.ModelsUnderRay(worldWheelPoint,
worldDownDir, 2, #detailed)

So the physics and control are applied to the chassis and the wheels are
just "floating". At which distance should they float is what
modelsUnderRay() is used for.

This doesn´t mean that you don´t need Havok at all and you can use
modelsUnderRay() instead since havok handles all the driving physics and
MUR just the distance of the wheels to the chassis.

Regards,
--
Agustín María Rodríguez

[url]www.onwine.com.ar[/url] > Macromedia Director demos & code

[roofy]

Agustín María Rodríguez wrote:

> Roofy wrote:

> > [Q]IIRC, the example you?re talking about has a "chassis" whose model
> > consists in 4 wheels and the car itself it?s only attached to the
> > chassis by a spring or dashpot to give the amortiguation effect.[/Q]
> >
> > ok, I might be wrong on this, but after pressing play and typing the following
> > syntax in the message window...
> > form the jeep demo ....
> > put member("blankHavok").lineardashpot
> > put member("blankHavok").spring.count
> >
> > and from the RemoteControl Car demo
> > put member("carHKE").lineardashpot
> > put member("carHKE").spring.count
> >
> >
> >
> > ... doing this in both files and after pressing play, I get an empltylist
> > returned back for the dashpot and 0 for the count of the spring. So I don't
> > think there are any dashpots nor springs on either demo.

>
> Sorry, I thought you were talking about this demo:
>
> [url]http://director-online.com/havok/demos/demo-dashcar.html[/url]
>

> > However, what I am
> > concluding is that I think they are using 2 custom handlers called
> > initializeHover and updateHover which is somehow detecting the chassis and its
> > wheels if they collide or not. I did a test by disabling both of these custom
> > handlers and by doing so, the chassis would fall through the wheels andland on
> > the ground instead. On the other hand, if these 2 custom handlers are causing
> > this effect, then I srill don't understand how the the wheels are following the
> > chassis. Therefore, I am wondering if it would be easier to use modelsUnderRay
> > considering that all I am trying to do is do collision detection? What do you
> > think?

>
> Actually, this RayCastCar demo uses modelsUnderRay() for collision
> detection of the wheels with the ground:
>
> -- For each wheel do
> repeat with i = 1 to pWheelPointList.count
> pIsHoveringList[i] = false
> worldWheelPoint = pChassisMDL.transform * pWheelPointList[i]
> intersectDetails = pMember.ModelsUnderRay(worldWheelPoint,
> worldDownDir, 2, #detailed)
>
> So the physics and control are applied to the chassis and the wheels are
> just "floating". At which distance should they float is what
> modelsUnderRay() is used for.
>
> This doesn´t mean that you don´t need Havok at all and you can use
> modelsUnderRay() instead since havok handles all the driving physics and
> MUR just the distance of the wheels to the chassis.
>
> Regards,
> --
> Agustín María Rodríguez
>
> [url]www.onwine.com.ar[/url] > Macromedia Director demos & code

ok, Thanks AGustin. The demo link you gave me is a lot easier except
for one thing. I was wondering if you anyone else could explain its
math theroy to me considering I do not understand it. Now, just to make
sure where on the same page the code below is from the Dashpot car
demo.

on collision me details
normalV = details[4]
axis = 1
if( abs(normalV[axis]) < abs(normalV[2]) ) then axis = 2
if( abs(normalV[axis]) < abs(normalV[3]) ) then axis = 3
normalV = pTurnAxis
normalV[axis] = 1
if( 0.01 > (normalV.length - 1) ) then pSurfaceContact =
pSurfaceContact + 1
end

now I understand what abs does and what pSurfaceContact stands for,
but what are we trying to find so that we know to add 1 to the current
pSurfaceContact? Meaning could you give me some numbers as an example,
such as what are some possiblities that normalV[axis] could be? In
addition, why are we checking to see if we want to use the 2nd axis or
the third axis? Meaning the part that says....

if..... then axis =2 or if..... then axis = 3