Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

haphazardlynamed

Jakobsen Adv.Char.Physics Flaws?Limitations?

This topic is 5276 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hello, I've been messing around with Jakobsen's particle physics model after reading that article(dont have a link directly, but im sure youve all heard of it) maybe some of you who have also used it can have some ideas letsee, my primary concern: say we take 4 verticies and connect them with constraints so they for a box -4 sides and 2 diagonal constrains ; the basic shape from the article how do I find the effective moment of inertia of the system? im using the box to make a modern Lunar Lander game, with really nice crashing physics, but to do this im going to need to know that box's moment of inertia so i get attitude thrusters working right... need to fire at the right times to start and stop rotation for the right amount of degrees....(my control system is not the oldstyle Lunar lander where you tap thrusters on and off yourself, here the user specifies an exact direction and the autopilot code controls the thrusters to get there) and on an interesting but not too urgent side note: has anyone else noticed just how important the order that constraints are applied can be? Jakobsen doesnt really touch it in his article... but ive found some wierd opportunities for bugs like, given that box, if you apply the edge constraints in say a counterclockwise order, you can get from numerical drift a rotation force on the box as a whole or... alternative stable structures since they dont apply simultaneously its possible to get a cyclic deformation that remains stable over frames, my main example of this was a box where 2 adjacent corners got swapped, so the box became twisted thus instead of 4 even sides and 2 long diagonals, they become 2 sides the same length, 2 sides long(the diagonals) and the diagonal bars become short (origionally the sides) [edited by - haphazardlynamed on June 7, 2004 12:41:12 AM]

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by haphazardlynamed
how do I find the effective moment of inertia of the system?

im using the box to make a modern Lunar Lander game, with really nice crashing physics, but to do this im going to need to know that box''s moment of inertia so i get attitude thrusters working right... need to fire at the right times to start and stop rotation for the right amount of degrees....(my control system is not the oldstyle Lunar lander where you tap thrusters on and off yourself, here the user specifies an exact direction and the autopilot code controls the thrusters to get there)



usually, you don''t That one of the main reason why you''d use the particles physics, so you don;t have to calculate the moment of inertia, angular momentum, ect...

Calculating moments of inertia usually involces integrating sample point masses over a volume (area, in 2D). So I guess you could do just that, sample the triangles in the mesh of the lunar lander, and calculate the moment of inertia that way. Or just use the particles themselves as sample points and calculate the inertia matrix.

You can try to convert the particle body into a rigid body, by deriving angular momentum, linear momentum, position and direction from the position of the particles.

quote:
Original post by haphazardlynamed
and on an interesting but not too urgent side note:
has anyone else noticed just how important the order that constraints are applied can be?


yes. your model might drift in a particular direction. It''s not great. You can alternate the order of solving the constraints (one increament from 0->NumCOnstraints, then next time decrement from NumConstraint->0).

to strengthen the box, you should put a central particle. also, you should not allow particles to drift too much after a collision. If you find a particle colliding so hard a constraint length gets flipped maybe you should consider re-doing the collision test 1/2 the time step, and try again, or simply allow the particle to penetrate the collision surface so it does not get totally squashed. Or you should do just that, squash the model at that point (re-calculate the constraints''s rest length with the new particle position), or remove the particle.

I think in your situation, I''d ditch the particle stuff, and use a simple rigid body approach. The particle stuff is good, but very hard to control. It''s better for things that do not need to be controlled, like ragdoll, ropes, clothes, blobs and soft bodies...

Share this post


Link to post
Share on other sites
I think I have a good solution to the box drifting problem:
- keep consecutive constrains on opposite sides of structure (symmetrical ordering)
- consecutive constrains should be mutually exclusive (no shared verticies when possible)

so, if we have our ascii art box here....
(yeah, it doenst look good less you paste it to notepad with monofont)

A-----B
|\ /|
| \ / |
| / |
| / \ |
|/ \|
C-----D

then the constrain order should be:
AD, BC (diagonals)
AB, CD (horizontals)
AC, BD (verticals)
Note that for each set of 2 constrains, the ordering didnt matter since they shared no vertices, and they were symmetrically opposed, (AD, BC <==> BC, AD)
also the order of the horizontal vs the vertical group can be swapped without consequence, since they influence seperate coordinate axis and thus wont mess each other up

So you end up with a box that does not drift, and does not have a tendancy to rotate left or right.

This doesnt however, solve the problem of alternative stable configurations. Or the issue of total inversion of the structure.


As for my Lunar Lander game....
the main reason Im using this particle stuff (and not rigid body)
is that this is going to be extended to 3D
(thats also the reason for my odd indirect control system, thruster tapping controls are tough when you have more than 1 axis)
...and I dont know the math for rigid body in 3D
- dont understand quaternions, and dont want to use lib code blackbox, so id rather go with jakobsen, since its something i understand
plus it looks really nice for tumbling the lander down cliffs, and the particles/vertices for collision detection are already there

I dont necessarially need to find exact moment of inertia..(i hope)..since I dont want direct/exact control over the lander anyhow
the user controls it through a level of abstraction,
user's mouse sets a goal orientation, lander 'AI' has to match it as best as possible given the physical limitations (gravity, terrain, ?damage?)
So, maybe all i need is a good thruster algorithm... ex: if angle to goal is + thrust clockwise, if angle to goal is - thrust counterclockwise
but that particular method is not very good i know from experience, since you'd end up overshooting the goal and occilating back and fourth
any ideas on that? thruster algorithm to arrive at destination with zero velocity? (given an unknown moment of inertia, probably a greedy algorithm...)




[edited by - haphazardlynamed on June 8, 2004 5:57:58 AM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!