problems with car physics

Game Engine, Players & Web Plug-in, Virtual Reality, support for other engines

Moderators: jesterKing, stiv

Post Reply
steve_t
Posts: 30
Joined: Tue Nov 05, 2002 7:10 am

problems with car physics

Post by steve_t » Fri May 21, 2004 4:38 pm

When animating a car in a game the center of the car must be over the back wheels to get proper rotation without the back wheels slipping all over the place. When I apply rigid body physics to my car it puts the center of the mass at the center of the object. Thus all the weight is over the back wheels and the car acts really funny.

I s it possible to do one of the following:
- add a rotation center for an object
- have a separate mass center for the object

thanks,
Steve

gorgan_almighty
Posts: 41
Joined: Wed Oct 16, 2002 12:26 pm
Location: Kent, UK

Post by gorgan_almighty » Wed May 26, 2004 9:27 pm

No i'm afraid not. Can't you make do without the car being a rigid body? I wouldn't have thought it would make much difference when it comes to a shape such as a car.

Keith. 8)

z3r0_d
Posts: 289
Joined: Wed Oct 16, 2002 2:38 am
Contact:

Post by z3r0_d » Thu May 27, 2004 1:13 am

gorgan_almighty wrote:No i'm afraid not. Can't you make do without the car being a rigid body?
the old way to do cars was using the fhrot and fh settings for materials

this would make your car flip really weird when upside down, and it would be impossible to go up steep hills, but it could be tweaked to rotate reasonably to be parallel to the ground

steve_t
Posts: 30
Joined: Tue Nov 05, 2002 7:10 am

Post by steve_t » Thu May 27, 2004 6:25 am

The old way of doing car physics was merely OK. There were lots of problems with having realistic colisions between cars and bariers or other cars.
With rigid body physics using a square bounding box lots of oportunities opened up.

I am not willing to settle for just good enough when it looks like greatness is soo close.

All I need is a way to use an empty to specify where the object rotates from. How about making an edit object actuator caller "rotate center", where you could specify an empty or object that is parented to the object which would be the new center for rotation.

Any help would be much appreciated

Saluk
Posts: 110
Joined: Wed Oct 16, 2002 6:52 am

Post by Saluk » Thu May 27, 2004 8:55 am

Yeah I see what your saying. Would it be possible to use two boxes parented to each other? I know in the old engine you couldnt parent dynamic to dynamic but I havent had the time to explore all the new possibilities. Beyind that it would be nice if the center of mass would always be placed at the handle of the object (the pink dot) rather than the actual center of the square.

But if you can use the two boxes, just put the boundary between the boxes where you want the center of rotation

dmao
Posts: 5
Joined: Wed Apr 07, 2004 3:12 am
Location: New Orleans, LA

Post by dmao » Tue Jun 01, 2004 8:02 am

I too am making a racing game and have found the physics to be a problem. Reading this thread really got me thinking- If we could parent dynamic objects to one another, that would solve a LOT more than just the center of rotation issue.

Even with rigid body boxes for collisions, using just one dynamic object is just a really bad hack. It's no different than sliding a book across a table- the second you hit a bump, the touching edge will catch since it's simply a box with zero ground clearence.

My solution would be to use the rigid bodies in conjunction. Time for a visual aid!

Image

This would solve so many problems when it comes to vehicles! You could do vehicles with true 2 or 4 (or more) wheel drive and steering, adjust tire grip with the cylinder's width and friction settings, apply brakes by simply stopping the wheels' rotation, and no longer have to deal with other really bad hacks when dealing with the first really bad hack :D. We'd no longer have to use python to adjust turning speed with velocity, invert turning when in reverse, or to simulate the wheels spinning. Plus, no more RotFH foolishness. Suddenly you have a realistic, yet simple vehicle- albeit with a very stiff suspension ;)

Literally, the only thing stopping this is inability to do dynamic-to-dynamic object parenting, though I'm sure it's not a simple thing to implement. Still, it's some food for thought. The next step after that would be a simple spring system to simulate the suspension, but that's a whole other complex issue in itself.

Till then, I'm gonna keep using the usual spheres for my cars. In my experiences, bounding box collisions have many advantages, but having a car flip over when it hits a slope is a deal breaker for me.

z3r0_d
Posts: 289
Joined: Wed Oct 16, 2002 2:38 am
Contact:

Post by z3r0_d » Tue Jun 01, 2004 6:42 pm

dmao wrote:Literally, the only thing stopping this is inability to do dynamic-to-dynamic object parenting, though I'm sure it's not a simple thing to implement. Still, it's some food for thought. The next step after that would be a simple spring system to simulate the suspension, but that's a whole other complex issue in itself.
....
this is _exactly_ what ODE could have allowed, but how would there be an interface to that?

each object in ODE is connected by a joint. There are several joint types. Joints that don't do anything (I forget what it was called), cept join two objects

hinge, two hinge

universal joint

ball joint

spring joint

and a motor can put force into most of these, and they have different dynamic properties.

so, I guess blender would need an interface to that, and a way to change the settings for their motion in real time without stopping the simulation. This would be necescary because it is _really_ annoying to run simulation, stop it, tweak the settings, restart the simulation, test the settings, repeat.

dmao
Posts: 5
Joined: Wed Apr 07, 2004 3:12 am
Location: New Orleans, LA

Post by dmao » Thu Jun 03, 2004 5:06 am

z3r0_d wrote:so, I guess blender would need an interface to that, and a way to change the settings for their motion in real time without stopping the simulation. This would be necescary because it is _really_ annoying to run simulation, stop it, tweak the settings, restart the simulation, test the settings, repeat.
I took a look at ODE's docs last night :shock: Amazing stuff. Is anyone still working on ODE integration? I remember there was a lot of progress a little while back, but it seems all that stopped when we got SOLID & Sumo back.

Interestingly enough, Softimage is now using (and improving) ODE, so it definitely can be done smoothly. And just imagine- our beloved Blender could be sharing sourcecode with XSI :wink:

PS, about tweaking settings while running the gameengine, why not just setup a script to increase/decrease actuator values with hotkeys?

Rebel
Posts: 0
Joined: Sat Aug 02, 2003 6:59 am
Location: South Africa

Post by Rebel » Thu Jun 03, 2004 6:39 am

This is a most intersting thread, but I have a question. What are you guy's doing to steer the cars. Keyboard? That's boring! I would love to see Blender being able to read the joysick or other analogue inputs. The doppler effect also does not work if you want do get views where the cars ride past the camera. It just goes louder or softer between the speakers if you use the 3-D sound. There is no frequency shift.

If Blender could do these things, it would make it a much better development system for games. Good luck with the car projects.

Keith

erwin
Posts: 5
Joined: Mon Oct 21, 2002 9:10 pm

easter egg: using ODE point to point constraints

Post by erwin » Thu Jun 03, 2004 12:50 pm

easter egg ;-)

You can use ODE constraints like point 2 point constraint in the current tuhopuu version.

get
http://www.erwincoumans.com/blender/p2p.blend
to see how ;-)

Someone can pick up the python physics integration and add more constraints etc. to allow for cars.

Saluk
Posts: 110
Joined: Wed Oct 16, 2002 6:52 am

Post by Saluk » Thu Jun 03, 2004 5:48 pm

You can use pygame to read the joystick, I'm not sure if other analogue inputs such as steering wheels are supported etc.
(pygame.org)

Rebel
Posts: 0
Joined: Sat Aug 02, 2003 6:59 am
Location: South Africa

Post by Rebel » Sat Jun 05, 2004 7:02 am

Saluk wrote:You can use pygame to read the joystick, I'm not sure if other analogue inputs such as steering wheels are supported etc.
(pygame.org)
Thanx Saluk, it looks like I'll just have to learn some programming. It would be nicer to have this feature available in the Blender realtime stuff. I had a look at Pygame, and I luv the logo!

joeedh
Posts: 31
Joined: Wed Oct 16, 2002 10:30 pm
Contact:

Re: problems with car physics

Post by joeedh » Wed Jun 09, 2004 9:18 pm

steve_t wrote:When animating a car in a game the center of the car must be over the back wheels to get proper rotation without the back wheels slipping all over the place. When I apply rigid body physics to my car it puts the center of the mass at the center of the object. Thus all the weight is over the back wheels and the car acts really funny.

I s it possible to do one of the following:
- add a rotation center for an object
- have a separate mass center for the object

thanks,
Steve
Forgive my stupidity. . .but. . .why not simply change the position of the object's origin point?

joeedh

animats
Posts: 15
Joined: Fri Nov 08, 2002 8:18 pm

Post by animats » Sat Oct 16, 2004 10:40 pm

If we could parent dynamic objects to one another, that would solve a LOT more than just the center of rotation issue.
What happens when you parent dynamic objects to each other? If they're rigidly connected, are the resulting group center of mass and inertia tensor computed properly? From testing, I suspect not.

There's no reason this shouldn't work right for rigid collections of bodies. Joints require a better physics engine, of course.

If a developer needs code to do the math for combining inertia tensors, I have that around somewhere.

Post Reply