RESOLVED: AWPRaycastVehicle - wheels drifting away…

Software: Away3D 4.x

chufraise, Newbie
Posted: 03 September 2012 10:25 AM   Total Posts: 6

Hiya all!
I’m having some issues with AWPRaycastVehicle. I’m new at away physics, and I’m trying to build some sort of basic car demo, just to learn how phys engine works.

I have created an instance of AWPRaycastVehicle, added the wheels and everything. It all look fine, but as you can see in the linked swf the wheels are drifting away when you apply engine force to the car.

It’s hard to find extensive documentation on the subject, but I found some google docs here

In the paragraph called “Suspention Constraints” I read this: “the suspension limits stops the wheels penetrating the chassis, or flying off the vehicle.” But I can’t seem to find any property called suspentionLimit on AWPWheelInfo nor in AWPVehicleTuning.

Here is the link the swf

and here is some code that shows the parameters I’ve set:

var body AWPRigidBody = new AWPRigidBody(carShapechassi500);
   
body.activationState AWPCollisionObject.DISABLE_DEACTIVATION;
   
body.linearDamping 0.1;
   
body.angularDamping 0.1;
   
body.friction 0.9;
   
body.position = new Vector3D(015000);
   
   
   
//   main.physicsWorld.addRigidBody(body);
   
AWPDynamicsWorld.getInstance().addRigidBody(body);
   
// create vehicle
   
var turning AWPVehicleTuning = new AWPVehicleTuning();
   
turning.frictionSlip 20;
   
turning.suspensionStiffness 200;
   
turning.suspensionDamping 0.85;
   
turning.suspensionCompression 0.83;
   
turning.maxSuspensionTravelCm 10;
   
turning.maxSuspensionForce 8000;
   
   
_vehicle = new AWPRaycastVehicle(turningbody);
   
AWPDynamicsWorld.getInstance().addVehicle(vehicle);
   
//   _vehicle.
   
   
   // add four wheels
   
_vehicle.addWheel(BLW, new Vector3D(-200,0,340), new Vector3D(0, -10), new Vector3D(-100), 50100turningtrue);
   
_vehicle.addWheel(BRW, new Vector3D(200,0,340), new Vector3D(0, -10), new Vector3D(-100), 50100turningtrue);
   
_vehicle.addWheel(FLW, new Vector3D(-200,0,-355), new Vector3D(0, -10), new Vector3D(-100), 50100turningfalse);
   
_vehicle.addWheel(FRW, new Vector3D(200,0,-355), new Vector3D(0, -10), new Vector3D(-100), 50100turningfalse);
   
   for (var 
i:int 0_vehicle.getNumWheels(); i++) 
   
{
var wheel AWPWheelInfo _vehicle.getWheelInfo(i);     wheel.wheelsDampingRelaxati     wheel.wheelsDampingCompressi     wheel.suspensi
    wheel
.rollInfluence 0.01;   
   


Help anyone?

 

   

Avatar
loth, Sr. Member
Posted: 03 September 2012 01:58 PM   Total Posts: 236   [ # 1 ]

hello is not from your settings
is your loop try to update physics at start
and use

// speed of physics simulation 60 fps
private static const TimeStep:Number = 1.0 / 30; // or 1.0 / 60
private static const FixedTimeStep:Number = 1.0 / 60;

// update physics engine in your loop
_physicsWorld.step(TimeStep, 1, FixedTimeStep);

 

   

chufraise, Newbie
Posted: 03 September 2012 06:50 PM   Total Posts: 6   [ # 2 ]

Yes, that did it!!! You’re a genius, thanks!!!

 

   

John Brookes, Moderator
Posted: 04 September 2012 11:26 AM   Total Posts: 732   [ # 3 ]

To me its a bug.
If your doing step(1.0/60, 1, 1.0/60) your using a fixed frame rate.

If you do variable
step(deltatime, 6, 1.0/60);
You still get the same issue.

My guess is updateWheelTransform is only being called every frame and not for the substeps.

ringo, Yang Li ?

 

   

macaan, Newbie
Posted: 04 September 2012 11:40 AM   Total Posts: 30   [ # 4 ]

I had the same experience like JohnBrookes, tried the update with dynamic steps but same problem with the wheels….

I think your guess is right

 

   

Avatar
loth, Sr. Member
Posted: 04 September 2012 12:24 PM   Total Posts: 236   [ # 5 ]

the most important is update physics before 3d engine

physics maintains an internal clock, in order to keep the actual length of ticks constant. This is pivotally important for framerate independence. The third parameter is the size of that internal step.

It’s important that timeStep is always less than maxSubSteps*fixedTimeStep, otherwise you are losing time. Mathematically,
timeStep < maxSubSteps * fixedTimeStep

When you are calculating what figures you need for your game, start by picking the maximum and minimum framerates you expect to see. For example, I cap my game framerate at 120fps, I guess it might conceivably go as low as 12fps.
At 120fps, the timeStep I’m passing will be roughly 1/120th of a second, or 0.0083. The default fixedTimeStep is 1/60th of a second, or 0.017. In order to meed the equation above, timestep doesn’t need to be greater than 1. At 120fps, with 1/60th of a second a tick, you’re looking at interpolating [as opposed to more accurately simulating] one in every two ticks.
At 12fps, the timeStep will be roughly 1/12th of a second, or 0.083. In order to meet the equation above, maxSubSteps would need to be at least 5. Every time the game spikes a little and the framerate drops lower, I’m still losing time. So run with 6 or 7. At 12fps, with 1/60th of a second per tick, you’re going to be getting maybe five genuine simulation steps every tick.

By decreasing the size of fixedTimeStep, you are increasing the “resolution” of the simulation.

When you pass Bullet maxSubSteps > 1, it will interpolate movement for you. This means that if your fixedTimeStep is 3 units, and you pass a timeStep of 4, then it will do exactly one tick, and estimate the remaining movement by 1/3. This saves you having to do interpolation yourself, but keep in mind that maxSubSteps needs to be greater than 1.

 

   

John Brookes, Moderator
Posted: 04 September 2012 12:43 PM   Total Posts: 732   [ # 6 ]

Thats a great cut paste of
http://bulletphysics.org/mediawiki-1.5.8/index.php/Stepping_the_World

let me just add the first bit.

The first parameter is the easy one. It’s simply the amount of time to step the simulation by. Typically you’re going to be passing it the time since you last called it

 

   

Avatar
Dexx, Newbie
Posted: 09 September 2012 11:32 PM   Total Posts: 6   [ # 7 ]

Yeah… I also have this issue when using delta time. I get the time with the following code:

var now:Number getTimer();
var 
elapsed:Number = (now lastCallTime) / 1000;
physicsWorld.step(elapsed10);
lastCallTime now

Where lastCallTime is a static property of the class. Thus I believe this either should be documented in another way or the [Resolved] mark should be removed.

 

   

Avatar
loth, Sr. Member
Posted: 10 September 2012 10:05 PM   Total Posts: 236   [ # 8 ]

yes delta time not working on car
a speed méthode is world.step(1/60, 4);

 

   

John Brookes, Moderator
Posted: 18 September 2012 01:24 PM   Total Posts: 732   [ # 9 ]

Been playing with this issue and recompiled the physics swc.
Really easy fix and the first random guess wink
I just set interpolate to false in updateWheelTransform

If you all could try this swc with your vehicles and with/without delta time.
Any issues?

 

File Attachments
AwayPhysicsDT.zip  (File Size: 608KB - Downloads: 298)
   

macaan, Newbie
Posted: 18 September 2012 01:54 PM   Total Posts: 30   [ # 10 ]

Cool! It’s working

 

   

louis87, Jr. Member
Posted: 13 March 2013 08:31 AM   Total Posts: 46   [ # 11 ]

Hello People,

do you know when is going to be added this feature in the dev branch?

thanks

 

   
   

X

Away3D Forum

Member Login

Username

Password

Remember_me



X