4th and last BoiledDownDemo - Katamari Damacy remake

No more BoiledDownDemos... imagine, i was banned permanently from
Open Source Physics Forum for asking this question... go figure!

Aug 29, 2008
good morning,

>>"Bullet simulation internally only supports constant, fixed, non-varying time steps."
- please allow me to derive from there and rephrase my question to this:
How to achieve constant simulation_flow in real-time in despite of internal constant time steps and low computer speed, i.e. physics simulation to run in real time even if that means only 1 FPS of animation?

i dont want to question the ways Bullet does things,
i want to explore all the ways how we could *externally* or anyhow else support varying time steps, basically i want to talk about timerLoops and how to fix, cap and generally use and be in control of deltaTime, not necessarily about stepSimulation() ...about using Bullet on common PCs where different computer speeds vary greatly and also hand-held, mobile, or otherwise low-end machines where we might have to settle for deltaTime > 1/60, and about situations where we "struggling" with time, these situations:

a) deltaTime= 1/40 ~ 1/90

or even worse:

b) deltaTime= 1/10 ~ 1/50

stepSimulation(dt, 0) does it!
internally even ..its just not supported, but it looks pretty good to me, so before going to do anything external, id like to know everything about what we already have inside, and so let me ask:

1.)
"not supported", in this case, looks more like "something will not work properly in some cases" .. with that being more precise and knowing where exactly do things go wrong with (dt, 0) the next question will have more sense

2.)
having dt= 1/10 ~ 1/50, is there any point in trying to EXTERNALLY achieve the effect of (deltaTime, 0) or it already does "pretty good job"?

3.)
is it practically possible to modify Bullet so that (dt, 0) works always "correctly" and so be supported ..or is that flaw in my logic and is theoretically impossible to have "both" in the same time?

and so in the light of that,
please let me do this question again:
"stepSimulation(dt, 10or100or1000or5000..) should be doing something 'visually similar' to what stepSimulation(dt, 0) in practice does or not?"

1st answer was:
>>"Indeed, except that calling "stepSimulation(dt, 0)," with a large dt is unsupported and creates all kinds of artifacts. The big difference with calling stepSimulation(dt, 10or100or1000or5000..) is that the latter doesn't degrate the simulation quality."

thanks again,
i find that to be true... but, is there more to it?

extended question: c-2.)
"having dt= 1/10 ~ 1/50, stepSimulation(dt, 10, 1/60) should be doing something 'visually similar' to what stepSimulation(dt, 0) does?"

i find that is not the case on my computers, so i wonder if this is correct to say as well: - calling stepSimulation(dt, maxSubSteps>1, fixedTimeStep) with dt > fixedTimeStep is unsupported too, while dt <= fixedTimeStep is supported, so in other words - interpolation works, but extrapolation does not? (or the other way around)

cheers,
sorry for all the fish

*** thread DELETED, banned ..what the?! ***

Sep 4, 2008
nVidia PhysX Tips:
Timing - Trade off fixed timesteps:
- Few substeps: moon gravity effects ???
( - A lot of substeps: physics can be the bottleneck )

- is this common thing in Physics Engines?
- can someone please explain what "moon gravity effects" means and what exactly are they talking about there?
- i must assume it is about some - loss of precision - otherwise there would be no observable effect at all, and they would not call it "trade off", right?

- but the most confusing is why would subSteps be responsible for anything like that?

thank you

Sep 4, 2008
>>"Assume you have to step the world 160 ms forward in time. You use a fixed timestep of 16ms which means you need t take several stubsteps to simulate the full intervall. If you clamp the maximum number of substeps to maybe five than you loose the rest of the timestep which will slow down the physics. Maybe they call this moon gravity effect."
- thank you!!

i thought i was chasing completely another issue there, but it all makes sense now. its all because of the subSteps.. unbelievable, i knew about it without even realizing it because i thought it was something else.. uh, never mind that

anyway, here's what i think... you must be right,
after all, that is the only case where we use subSteps - when deltaTime > fixedTimeStep

more precisely, the only time we actually really need it is when one stepSimulation() takes more time than it was supposed to simulate...

the worst thing with it is that in all-other-cases we want to set maxSubSteps as high as possible, but again, only hoping that computer is fast enough to execute one simulationStep in less time than fixedTimeStep, otherwise it will be cut off sooner or later...

its even worse than that because the time it takes to render the scene is of course in play too.. quite often assumed to be the dictating factor in "computer speed" which is wrongly referred to as FPS ..and this, very much and very directly is connected to the fact that someone invented maxSubSteps in the first place

and if all this is true, "moon gravity effect" SHOULD NOT be related to gravity or any other forces, it would affect everything as it practically just causes less number of simulation steps per real-time second and with fixed time step that simply means general "slow-down" - as you said, but the byproduct might also be a drop in FPS all too sudden as time to execute stepSimulation() approaches fixedTimeStep

so i think "maxSubStep" is wrong way to go about it,
as it does not really "solve" anything and it causes troubles on the way..

i propose 2 solutions,
but lets see if i got this whole thing wrong?

thanks

Sep 5, 2008
>>"Here is an article that might help you.. GafferOnGames, Fix Your Timestep!"
- thats right,
man, you got good instincts!!

not me unfortunately, so it took me quite some time..
now before i realized, in the last message for which i thank you very much, that these two are actually connected i show how and why that algorithm might be a terrible choice..

there is even an "emulator" i made of that algorithm and you can see how bad it works in some particular cases, also you can compare it to one of my "half-solutions" algorithms and note how fpsTensor variable in my solution does a much nicer job without introducing any capping or any MAX. number of anything..

does that make sense?
feel free to correct or point anything that you think or suspect is wrong...

Sep 5, 2008

..and it works!

here is quick-hack Bullet implementation of the algorithm i was talking about...
in "btDiscreteDynamicsWorld.cpp" replace "btDiscreteDynamicsWorld::stepSimulation" with this:
//--------------------------------------------------------
#include <stdio.h>
static btClock realTime;
double simDT, anmDT, STEP;
double secCnt, deltaTime = 0.0;
int cnt, FPS, SPS, fpsTensor= 60;
int btDiscreteDynamicsWorld::stepSimulation( btScalar timeStep,int maxSubSteps, btScalar fixedTimeStep)
{
    deltaTime= double(realTime.getTimeMicroseconds())*0.000001f;
    if(deltaTime > 0.75) deltaTime= 0; STEP= fixedTimeStep;
    m_localTime+= deltaTime; realTime.reset(); FPS++;
    saveKinematicState(fixedTimeStep); applyGravity();
    anmDT= deltaTime - simDT; if(cnt > 0) simDT/= cnt; cnt= 0;
    while( m_localTime >= fixedTimeStep )
    {
        cnt++; SPS++; internalSingleStepSimulation(fixedTimeStep);
        m_localTime-= (simDT >= STEP)? simDT+(STEP*anmDT*fpsTensor) : STEP;
    }
    synchronizeMotionStates(); clearForces();
    simDT= double(realTime.getTimeMicroseconds())*0.000001f;
  return cnt;
}
//--------------------------------------------------------

...re-compile and voila ...no more moon-walking!
there is no need to change anything anywhere else, it completely disregards the timeStep and maxSubsteps that your games, demos and Bullet demos pass as arguments, they not really required to be supplied if this function is supposed to deal with time allocation anyway

..in case you have fast CPU im not sure if you will notice anything because everything will work as before.. or maybe even better? ..but if you try benchmark demos or have slow CPU you will definitively notice the difference, if you used maxSubSteps > 1

this is still only half-solution and it goes ON when (simDT >= STEP), that is when one simulation step need same or more time to execute than what is 'fixedTimeStep', it seem to be quite nice and visually smooth effect... but until then, its just like the old algorithm - bit choppy as simDT gets close to STEP - its a *VISUAL BELL* that tells you to lower down you simulation frequency or optimize the physics... former can be included in algorithm so it handles it automatically if that is acceptable for the end application, so that fpsTensor work left and right in regards to fixedTimeStep and pivot simulation speed and animation around desired FPS keeping it smooth on both sides around that critical fixedStep value

# anmDT
(time used to render the whole scene once)

# simDT, N
(time used to complete one simulation step, number of iterations)

# deltaTime= (simDT * N) + anmDT
(time used to simulate and render last frame)

# FPS, SPS
(animation Frames.Per.Sec, simulation Steps.Per.Sec)

+++ put this anywhere in above code to print some stuff:
//*** Print stuff ---------------------------------------------
secCnt+= deltaTime;
while(secCnt >= 1.0)
{
printf("anmDT=%.4f simDT=%.4f >= fixDT=%.4f FPS=%d SPS=%d \n",
deltaTime-simDT, simDT, STEP, FPS, SPS);

FPS=SPS= 0;
secCnt-= 1.0;
}
//--------------------------------------------------------------

does that work for everyone?
..if so, im delighted, if not - let me know!

*** messages DELETED, banned ..what the?! ***