I wanted to speed up a vehicle (OgreOde::Vehicle).
Therefore I changed the _vehicel->getEngine()->setRevLimit(100). (is this the best way or is there a better one)
The good news was, that my vehicle was now really fast (as I wanted it) BUT a great problem occured. (I don't know the correct english word, so I'll try to explain it).
It looks as if the framerate would be very low,as if the car sometime gets stuck for a little time. But I have 150fps, so it doesn't seem to be a performance trouble. It can also be reproduced using the landscape example. The best way to see it is to set the maxHeight=0 in the landscape.conf in the media directory of ogreode.
I browsed the forum but didn't find a post where people talked about this problem. I already applyed the patch from this post http://www.ogre3d.org/phpBB2/viewtopic. ... ht=ogreode
Any idea what could be the problem, or how I can fix it?
oh, before I forget. I'm using ogreode from the cvs (2005-02-01) and the last stable release of ogre. (Hastur)
Yet another ogreode question/problem
- charlie
- Greenskin
- Posts: 146
- Joined: Mon Nov 15, 2004 1:43 pm
- Location: Austria
- Contact:
- monster
- OGRE Community Helper

- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
- Contact:
Do you mean the movement of the vehicle is jittery or jerky?
If so, that's probably because, to get a more stable simulation the demo uses a "stepper" that always steps the world by a fixed amount. Whilst this is good for the solver it's bad if you've got very fast moving objects, because the fixed time step means that the physical world can sometimes be slightly out of step with real time. For example, if the time step is 1/100th of a second and only 0.0099 of a second has passed then the physical world won't get stepped, but your eye will expect the objects to have moved based on what they were doing in the previous frame. This is only really noticable for fast moving objects because it's only when they're moving fast that there's a big difference between where they are and where your eye expects them to be when there's a small difference in physics world time and real time.
You can work around this by changing the line that says;
to say
This stepper does a number of fixed time steps, followed by a small "clean up" variable sized step to ensure that the physical world and real time are always exactly in sync. Whilst this might look smoother it might be a slightly less stable simulation because the solver won't like the variable timesteps.
The ultimate solution is to use completely fixed timesteps and interpolate positions and rotations for the "clean up" step, rather than actually stepping the world. That's something I might get round to looking at sometime, but not right now.
Currently that's the only way!
But as it says in the comments;
Hopefully I'll be working on the drivetrain functionality sometime in the near future to make it a more complete simulation. Just don't hold your breath!
If so, that's probably because, to get a more stable simulation the demo uses a "stepper" that always steps the world by a fixed amount. Whilst this is good for the solver it's bad if you've got very fast moving objects, because the fixed time step means that the physical world can sometimes be slightly out of step with real time. For example, if the time step is 1/100th of a second and only 0.0099 of a second has passed then the physical world won't get stepped, but your eye will expect the objects to have moved based on what they were doing in the previous frame. This is only really noticable for fast moving objects because it's only when they're moving fast that there's a big difference between where they are and where your eye expects them to be when there's a small difference in physics world time and real time.
You can work around this by changing the line that says;
Code: Select all
_stepper = new OgreOde::ForwardFixedQuickStepper(time_step);Code: Select all
_stepper = new OgreOde::ExactVariableQuickStepper(time_step);The ultimate solution is to use completely fixed timesteps and interpolate positions and rotations for the "clean up" step, rather than actually stepping the world. That's something I might get round to looking at sometime, but not right now.
I changed the _vehicel->getEngine()->setRevLimit(100). (is this the best way or is there a better one)
Currently that's the only way!
But as it says in the comments;
Code: Select all
// Set the engine (and other drivetrain) parameters, lots of work still to do here- charlie
- Greenskin
- Posts: 146
- Joined: Mon Nov 15, 2004 1:43 pm
- Location: Austria
- Contact:
Thanks monster!! Worked....
But I'll try my best.
Looking forward for the next release. The screenshots you posted in the forum where simply great...Hopefully I'll be working on the drivetrain functionality sometime in the near future to make it a more complete simulation. Just don't hold your breath!
Well, I'm completely new to 3d programming and am just for about a month now looking into ogre more seriously. And physics.... that is a dark chapter in my knowlledge. Without ogreode I would never had a chance to get a realistic vehicle moving. So basically I'm just a user of the api without really understanding what's behind...The ultimate solution is to use completely fixed timesteps and interpolate positions and rotations for the "clean up" step, rather than actually stepping the world. That's something I might get round to looking at sometime, but not right now.