Frame Rate Independence

[sparkprime]

Uhm, i still fail to understand how maxSubSteps solves any problem. The newbie developer already knows how much time he wants to simulate, and what the timeStep is (1/60 by default).
Therefore, he knows *in advance* how many steps will be taken to compute the simulation he asked for (and how that number compares to a possible "maxSubSteps" parameter). Is that correct?

Yes, you can do it outside the function if you like. So in that sense maxSubSteps gives you nothing extra except the convenience of having it done for you.

Also, what problem does capping the number of steps solve?

You mentioned two problems:
1) That "too many" steps may have to be computed in order to simulate the desired delta.
2) That steps can take a "too long" time to compute.
Both can lead to locking the physics thread (or the whole program, if it's not multithreaded) until the physics are computed.

The 1) problem can (and IMO should) be addressed by the developer, as explained above. A helper function can be provided by Bullet, but is in no way necessary for the working of Bullet.
The 2) problem can also be solved by Bullet (by returning from stepSimulation if certain time (specified by the user) has elapsed and not all steps, or even not a single step, have been able to be computed), but again IMO it's better addressed by the developer (by profiling the different subsystems of his program, guesstimating the time it'll take to compute things, and acting consequently, for example reducing physics quality, or decreasing graphics detail, or visually warning the user but still allowing sub-realtime gameplay, or stopping the simulation, or sending the multiplayer server an "out of sync due to lack of computing power" message, or whatever).

In my opinion, the 2) problem is the worst of all, and is what would really help the most to the newbie end user.

Yeah you're right again, it could be done by the client in an internal step callback or whatever. Bullet doesn't measure the time it itself takes, it just culls steps if it's already done too many. Two different ways of solving the same problem, but measuring time would be much harder to implement portably

Now you see why we have had all this discussion about the design

[stenyak]

Ok, having read and mostly understood what was mentioned in the last page, this is a list of features i think the new API should have.

-Interpolations should be optional somehow. regardless of everything else.
-Keep the old method functionality, in order not to break the API (which in some circles is said should only happen in major version numbers).
-Provide ODE-like funcionality (single step of any size, without interpolation).

This is what i think is needed:
I think the current API *always* interpolates, is that correct? Therefore, if the new API requires being able to disable interpolations, it can not interfere with the old API.
Also, the current API may be easy for newbies, but as demonstrated in this thread, is certainly not the most intuitive or complete when you want to do more advanced things.
So i suggest we leave the old API as-is, mark it as deprecated, code a new set of stepping methods, and remove the old API in bullet 3.0.

The new API should have:
1) A way to compute a single step of time.
2) A way to interpolate, providing the time to predict.
3) A way to compute a batch of steps with automatic interpolation for simple apps (i used to say "newbies", but batch stepping can have its use beyond simple demos, of course).

The 3) can be accomplished using 1) and 2).
1) single stepping, analog to the ODE api.

Code: Select all

/** simulate the specified time in a single step.
void singleStep(time);

2) interpolations, as suggested by sparkprime:

Code: Select all

/** calculate interpolation and "other things" (which i don't know exactly what they are) the provided time into the future. since i don't know much about the "other things", the name of this method should probably be changed. */
void interpolate(time);

3a) batch stepping first option: i put a namespace just so you understand the scope of methods, not as a suggestion of final coding

Code: Select all

/** defaults to 100Hz (0.01s) */
namespace BatchStepping
{
    /** Set/get the step time used by batch stepping
    void setStepTime(seconds);
    seconds getStepTime();
    /** Computes N steps of getStepTime seconds, and interpolates the rest of time. Very similar (or equal) to current API. */
    void batchStep(time)
    {
       static seconds remaining = 0;  //not thread safe..
       time += remaining;
       if (time > 0.5) return "i assume you didn't check how much time you're really asking to simulate, and i assume that you do not want to do this, so i exit"; //IMO this should be handled by the user, not by bullet, there are so many other things we don't check for...
       for (int i=time/getStepTime(); i; i--) singleStep(getStepTime());
       remaining = time%getStepTime();
       interpolate (remaining);
    }
}

3b) batch stepping second option. again, the user must control how much time he's asking to compute. for convenience, we re-use the setStepTime data for single stepping.

Code: Select all

/** Set/get the step time used by batch stepping. By default it's 100Hz (0.01s)
void setStepTime(seconds);
seconds getStepTime();
/** Computes N steps of getStepTime seconds, and interpolates the rest of time. Very similar (or equal) to current API. */
void batchStep(time)
{
   static seconds remaining = 0;  //not thread safe..
   time += remaining;
   if (time > 0.5) return "i assume you didn't check how much time you're really asking to simulate, and i assume that you do not want to do this, so i exit"; //IMO this should be handled by the user, not by bullet, there are so many other things we don't check for...
   for (int i=time/getStepTime(); i; i--) singleStep();
   remaining = time%getStepTime();
   interpolate (remaining);
}
/** simulate the setStepTime() in a single step. provided for convinience */
void singleStep()
{
    singleStep(getStepTime());
}

[Erwin Coumans]

so, my new understanding is now this:
a.)
Bullet features 2nd kind of "frame-rate Independence", which gives you FREEDOM to sync your timer and animation with Bullet's internal 60fps as you see fit
b.)
it can do 1st - "FALLING-framerate" Independence by using stepSimulation(dt, 0), but it is not deterministic

and now, best of all,
this would resolve and explain everything for me
c.)
stepSimulation(dt, 10or100or1000or5000..) should be doing something 'visually similar' to what stepSimulation(dt, 0) in practice does or not?

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.

Surely the ODE approach is equivalent to just calling

stepSimulation(dynamicsWorld->getSteppingInfo().m_fixedTimeStep);

No, this is not equivalent. ODE doesn't subdivide the timestep in substeps. So the Bullet equivalent of ODE "dSpaceCollide+dWorldQuickstep" is:

Code: Select all

stepSimulation(deltatime, 0);

Ok, having read and mostly understood what was mentioned in the last page. [...] So i suggest we leave the old API as-is, mark it as deprecated, code a new set of stepping methods, and remove the old API in bullet 3.0.

From your comments, it seems the current stepSimulatoin API is not clear to both you and sparkprime. Before you come up with a new API design, improving your understanding of the current API and improving the existing documentation should come first. At least it should prevent developers from passing a variable substep as 3rd argument. It is very important to distinguish between timestep and (fixed) substep, don't mix them up.

-Interpolations should be optional somehow. regardless of everything else.
I think the current API *always* interpolates, is that correct? Therefore, if the new API requires being able to disable interpolations, it can not interfere with the old API.

No, the current API doesn't always interpolate.
Interpolations are optional in two ways: they happen through the motion state objects, which are optional. So if you don't create a motion state for a rigid body, there will be no interpolation. Secondly, when you disable subdivision of the timestep in substeps, by calling stepSimulation(dt,0), there is no interpolation.

The new API should have:
1) A way to compute a single step of time.

The current API does this through:

Code: Select all

stepSimulation(dt,0);

2) A way to interpolate, providing the time to predict.
3) A way to compute a batch of steps with automatic interpolation for simple apps (i used to say "newbies", but batch stepping can have its use beyond simple demos, of course).

The current API already does this through

Code: Select all

stepSimulation(dt);

The old API already provides all this functionality, so your new API would not be more complete.

Power users are recommended to derive from existing Bullet classes or customize parts of it. If their customizations are useful we will likely accept their contributions.
Hope this helps,
Erwin

[stenyak]

Thanks for the input

From your comments, it seems the current stepSimulatoin API is not clear to both you and sparkprime. Before you come up with a new API design, improving your understanding of the current API and improving the existing documentation should come first. At least it should prevent developers from passing a variable substep as 3rd argument. It is very important to distinguish between timestep and (fixed) substep, don't mix them up.

Ok, then i guess we need to know: What is substep compared to timestep compared to ODE step?
(by "ODE step" i refer to dSpaceCollide+dWorldStep/dWorldStepFast1/dWorldQuickStep+dJointGroupEmpty)
I haven't found this explained in the docs. I thought a bullet substep more or less equals an ODE step.

I think the current API *always* interpolates, is that correct?

No, the current API doesn't always interpolate.

Ok, thanks for the info.

[abaraba]

a.)
Bullet features 2nd kind of "frame-rate Independence", which gives you FREEDOM to sync your timer and animation with Bullet's internal 60fps as you see fit
b.)
it can do 1st - "FALLING-framerate" Independence by using stepSimulation(dt, 0), but it is not deterministic
c.)
stepSimulation(dt, 10or100or1000or5000..) should be doing something 'visually similar' to what stepSimulation(dt, 0) in practice does or not?
-----------------------------------------
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 degrade the simulation quality.

thank you, that makes it perfectly clear, how wonderful!

now,
the problem seem to be that stepSimulation(dt, 10or100.. ) doesnt seem to be working as good as stepSimulation(dt, 0) and this thread uncovered that stepSimulation(dt, 0) is somehow everyones 1st and "natural" way to think about "what should be happening" - it seem it would be everyones 1st choice to use it... if it was only supported and if it was deterministic - perhaps someone could make it so, but do we really need it?

1.) on game consoles:
NO, we will fix FPS anyhow and tie it up to Vsync so animation get absolutely smooth and we can design our world so the speed is rarely compromised, and even if that happens little slowdown is not a big deal - eg. GodOfWar2 on ps2

2.) on PC:
YES, probably - to try to accommodate as wider specs as possible, little slow-down is not an option as it could be BIG on some machines, while dropping FPS even down to 5-10 *IS* acceptable for low-end specs on some screens/situations

...or so it would seem by looking at it from my chair

cheers

[Erwin Coumans]

Ok, then i guess we need to know: What is substep compared to timestep compared to ODE step?
(by "ODE step" i refer to dSpaceCollide+dWorldStep/dWorldStepFast1/dWorldQuickStep+dJointGroupEmpty)
I haven't found this explained in the docs. I thought a bullet substep more or less equals an ODE step.

ODE doesn't subdivide the timestep, so there is no internal fixed substep.

In conclusion: by default Bullet subdivides the timestep in fixed sized simulation substeps. You can disable subdividing the timestep by clamping the maximum number of substeps to 0: stepSimulation(dt,0). But using a variable timestep in combination with disabled fixed substeps is not supported in Bullet. All Bullet Dynamics users, both newbie and expert, need to enable substepping or pass in a fixed time step, one way or the other.

Thanks,
Erwin

[chunky]

Regarding ODE:

Ok, then i guess we need to know: What is substep compared to timestep compared to ODE step?

Last time I used ODE, it simply didn't have any of the stuff that's being talked about in this thread. It's been a while, but I think my knowledge is still current:

You give ODE a delta, and it steps the simulation by that much, in one go. la finis.

What this means is that to do what you do with ODE [which is where you have to keep track of the deltas yourself and always step the simulation by an appropriate amount] with bullet, you can just replace dQuickStep(delta) with stepSimulation(delta, 0).

What bullet does that ODE doesn't, is wrap the loop that you have around dQuickStep in *your* code and provide it inside stepSimulation [and then interpolate]. So your ODE code that looks like this:

Code: Select all

const float myFixedStep = 1.0/60.0;
float lasttime, currtime;
currtime = gettime();
dt = currtime - lasttime;

while(dt > 0) {
  dQuickStep(myFixedStep);
  dt -= myFixedStep;
  lasttime += myFixedStep;
}

Wheras your bullet code looks like this:

Code: Select all

const float myFixedStep = 1.0/60.0;
float lasttime, currtime;
currtime = gettime();
mWorld->stepSimulation(currtime - lasttime, 10, myFixedStep);
lasttime = currtime;

And then bullet interpolates for you on top of that. It's just a question of who does certain amounts of the coding work, and bullet simply does more for you than ODE does, in this specific regard.


Regarding dynamic maxSubSteps:

If i've understood it correctly, that's obviously a bug, and allowing or even encouraging the developer to dampen it so that the simulation still somehow "works" with wrong data is not a good practice

Except how do you know? Empirically, at what point do you say "this number is too high" as the first parameter to stepSimulation? There is no way to choose a number for that, so instead you have maxSubSteps, which caps the computation time. I would consider code that passes milliseconds instead of seconds simply to have a bug that needs to be fixed. Lots of code has bugs, this is just one of them.


Regarding the new API:
I have no love of the idea of stepSimulation without parameters being a single step. That means that the same function call does two very different things, with unclear distinction to beginners. I would rather only see stepSimulation(delta) with no default argument, which people call with their time difference. A separate function, singleStepSimulation() with no arguments could singly step it.

Other questions: Does it mean anything to have interpolation turned on, but have maxSubSteps be 0 or 1?


Regarding Abaraba:
What I meant was, I felt that I answered your questions, including showing the very code that I'm using, and suggesting what I think was your exact issue which was why your code wasn't working.
Instead of just trying what I suggested, you'd post long replies and not actually try what I suggested. I tried to help to the best of my capacity despite having no obligation to, and my suggestions were 1) ignored and 2) apparently not very welcome. Which is why you got a final tired response from me.

Gary (-;

[stenyak]

Gah, the more i read, the more confused i am!

- What is meant with "interpolation"?
Does it mean computing the remainder of time (into the future) with simple linear calculations, when it hasn't been calculated due to the capping with maxSubSteps, meaning that the computation is not as realistic as it could be?
Does it mean taking 2 known world states, and doing a linear/spherical interpolation of position/rotations, for use by external entities (graphics engines)?
Does it mean taking one of the in-the-middle substep position/rotations, for use by external entities?
Or some mix of the above ideas?

- What is meant with "fixed" "timestep"?
Does "fixed" mean constant in time?
What does the "timestep" refer to? substep time, or the "deltatime" that gets divided into substeps?

- What is substeps?
Is computing 10 substeps of 0.1s equal to computing 10 "bigsteps" of 0.1s with substepping disabled? And by equal, i mean literally equal, down to the last bit of every float/double variable. That is, are substeps simply a way to make things easier to the usual coder?
Or are substeps a more elaborate and accurate way to integrate physics (analog to using, say, RK4, instead of a RK2)?

- What about determinism?
Is determinism influenced in any way by choosing substepping vs. no-substepping?
Isn't bullet always deterministic, assuming same computer/OS/drivers, regardless of the method chosen to integrate or compute physics with bullet?
These two questions should be considered with the assumption that the coder doesn't tie physics in any way to other subsystems such as graphics. Better yet, with the assumption that the coder is simply doing an off-line trace of how a ball falls from 100m of height, recording the data into a text file, with no regards to the wall-clock at all (since there's no real-time display in any screen).

Thanks again for your patience... I hope the docs can be updated after this long discussion, so that you don't suffer more because of people like me

[Erwin Coumans]

Can you please read http://www.gaffer.org/game-physics/fix-your-timestep first?

- What is meant with "interpolation"?
Does it mean taking 2 known world states, and doing a linear/spherical interpolation of position/rotations, for use by external entities (graphics engines)?

Bullet calculates and keeps two world transforms, a previous and next simulation step. If the user attaches a motion state, it will interpolates between those.

- What is meant with "fixed" "timestep"?
Does "fixed" mean constant in time?

It is a constant fixed value, default to 60 hertz during the entire simulation. If you desire higher quality, you can choose a value such as 240 hertz.

What does the "timestep" refer to? substep time, or the "deltatime" that gets divided into substeps?

timestep refers to deltatime, usually the clock time that elapsed between two frames. This is usually passed as first argument to Bullet's stepSimulation, and as only argument to ODE dWorldQuicksStep.

- What is substeps?
Is computing 10 substeps of 0.1s equal to computing 10 "bigsteps" of 0.1s with substepping disabled?

Please look into the implementation of stepSimulation, both cases will call "internalSingleStepSimulation", remember that Bullet is open source:

Code: Select all

int	btDiscreteDynamicsWorld::stepSimulation( btScalar timeStep,int maxSubSteps, btScalar fixedTimeStep)
{
	int numSimulationSubSteps = 0;
	if (maxSubSteps)
	{
		//fixed timestep with interpolation
		m_localTime += timeStep;
		if (m_localTime >= fixedTimeStep)
		{
			numSimulationSubSteps = int( m_localTime / fixedTimeStep);
			m_localTime -= numSimulationSubSteps * fixedTimeStep;
		}
	} else
	{
		//variable timestep
		fixedTimeStep = timeStep;
		m_localTime = timeStep;
		if (btFuzzyZero(timeStep))
		{
			numSimulationSubSteps = 0;
			maxSubSteps = 0;
		} else
		{
			numSimulationSubSteps = 1;
			maxSubSteps = 1;
		}
	}
	if (numSimulationSubSteps)
	{
		saveKinematicState(fixedTimeStep);
		applyGravity();
		//clamp the number of substeps, to prevent simulation grinding spiralling down to a halt
		int clampedSimulationSteps = (numSimulationSubSteps > maxSubSteps)? maxSubSteps : numSimulationSubSteps;
		for (int i=0;i<clampedSimulationSteps;i++)
		{
			internalSingleStepSimulation(fixedTimeStep);
			synchronizeMotionStates();
		}
	} 
	synchronizeMotionStates();
	clearForces();
	return numSimulationSubSteps;
}

- What about determinism?
Is determinism influenced in any way by choosing substepping vs. no-substepping?
Isn't bullet always deterministic, assuming same computer/OS/drivers, regardless of the method chosen to integrate or compute physics with bullet?

The actual clock time, delta time, fluctuates on most computers, so you won't be able to reproduce your results in a deterministic way. By using substepping, you can avoid this and create a deterministic simulation, excluding the effect of those fluctuations.

Please avoid introducing more concepts to this thread, but start a new one,
Thanks,
Erwin

[sparkprime]

ODE doesn't subdivide the timestep in substeps.

In that case I don't see why using an API that is "similar to ODE" is worthwhile. As far as I've been following, we've been talking about how to expose the substeps functionality (and associated things like forces, internal step callbacks, and motion states) in a manner that is simple, powerful, and encourages correct use. If ODE doesn't have that functionality then it's best left out of this I think.

The question I was trying to ask is that from the description you gave have given, I don't see how these calls would differ in your proposal:

Code: Select all

dynamicsWorld->internalStepSimulation();
dynamicsWorld->stepSimulation(dynamicsWorld->getSteppingInfo().m_fixedTimeStep);

From your comments, it seems the current stepSimulation API is not clear to both you and sparkprime.

I can't imagine what made you think that... The only thing I can imagine is that I overlooked the fact that your proposed new behaviour is equivalent to the old behaviour in the case of one argument, (and I've never used ODE so obviously know nothing about that).

I've read (and modified) the source code of stepSimulation. Plus provided a few mathematical insights about its behaviour, and demonstrated I can "abuse" it to do peculiar things.

I think if there is a problem, it's more in the clarity of communication...

The current API already does this through

The API is very powerful as it stands, it's just not intuitive. I wanted to add more power and make it more intuitive but it seems you only want to make it more intuitive, presumably because:

Power users are recommended to derive from existing Bullet classes or customize parts of it.

Well, that's fair enough really. I think I will do this on wednesday night and share the code here, just to make sure that there are no private members or other things that get in the way. The time for talking is over!

[sparkprime]

I have been asked to stop talking about proposed and non-existing stepSimulation APIs since it's confusing people in this thread who are trying to understand the existing stepSimulation.

If you find yourself in this position I would recommend either ignoring everything I said or being very careful about checking whether or not I am talking about existing API or not.

Sorry for any confusion.

[stenyak]

Can you please read http://www.gaffer.org/game-physics/fix-your-timestep first?

I am very aware of those concepts, and have implemented them, together with time scaling (allowing the user to increase or decrease simulation speed, aka slow/fast motion) and time pausing. Only with ODE, not Bullet. Also, i have never fed ODE with variable timesteps, so that the simulation stays stable, deterministic, etc. This is what i want to achieve in Bullet too.

Bullet calculates and keeps two world transforms, a previous and next simulation step. If the user attaches a motion state, it will interpolates between those.

(emphasis mine)
Do you instead mean that bullet calculates N world transforms, but only keeps the last 2?
I don't know what you mean with "next simulation step". Do you mean in the future? For example: If i ask bullet to simulate 1.0 seconds of physics, do those 2 transforms correspond to 0.9s and 1.0s (the last 2 computed transforms), or do they correspond to 1.0s and 1.1s (the last transform i asked for, and one in the future which i did not ask for).

- What is meant with "fixed" "timestep"?
Does "fixed" mean constant in time?

It is a constant fixed value, default to 60 hertz during the entire simulation. If you desire higher quality, you can choose a value such as 240 hertz.

Yes, i desire higher quality (i was happy with 300Hz in ODE in my old simulator), how do i change it? As i mentioned, i have never used and do not want to use variable timesteps, because i need determinism and of course stability.

What does the "timestep" refer to? substep time, or the "deltatime" that gets divided into substeps?

timestep refers to deltatime, usually the clock time that elapsed between two frames. This is usually passed as first argument to Bullet's stepSimulation, and as only argument to ODE dWorldQuicksStep.

Ok... that may be what newbies pass to ODE in their first tests, but they usually come back to the mailing list complaining, and they're told how to do it the right way. Passing that kind of "delta times" to ODE is not appropriate, even if it is allowed and even if many people make that mistake or do not care about it. I do not desire to simulate that behaviour, and never implied i wanted that functionality in Bullet either (even though it can be useful at times, for example debugging, etc. as mentioned).

- What is substeps?
Is computing 10 substeps of 0.1s equal to computing 10 "bigsteps" of 0.1s with substepping disabled?

Please look into the implementation of stepSimulation, both cases will call "internalSingleStepSimulation", remember that Bullet is open source:

I looked at the implementation, but it confused me. For example, judging by the comments, using maxSubSteps == 0, the code seems to think that i want to use variable timesteps, when it is not my case, since i already handle the delta times (so that the physics engine is always fed the exact same timestep).
I am not sure what btFuzzy does, or why it's there in first place. Also, i don't know why synchronizeMotionStates is called twice for a single substep (or N+1 for N substeps), in fact i still don't fully understand what synchronizeMotionStates does.

The actual clock time, delta time, fluctuates on most computers, so you won't be able to reproduce your results in a deterministic way. By using substepping, you can avoid this and create a deterministic simulation, excluding the effect of those fluctuations.

As i said, i don't care about actual clock time (what i call "wall time", right?), or delta times (because i already divide it into a set of equal timesteps). I was asking about the determinism in an offline, headless simulation, so that those concepts don't exist and therefore do not interfere in the simulation.

I'm not sure what concepts of my posts are considered offtopic, but i apologize for it. I thought they were relatively ontopic, but feel free to point me to them, or directly fork my posts into a new thread.

Thanks again for the explanations.

[Erwin Coumans]

I am very aware of those concepts, and have implemented them, together with time scaling (allowing the user to increase or decrease simulation speed, aka slow/fast motion) and time pausing. Only with ODE, not Bullet. Also, i have never fed ODE with variable timesteps, so that the simulation stays stable, deterministic, etc. This is what i want to achieve in Bullet too.

There are two ways: you let Bullet deal with all this (using motion states and subdividing the timestep), or do it yourself. Just set the second argument to zero, which disables subdivision of the timestep. If you have any issues with the implementation, please derive from the class and override the default implementation.

Again, if you want to manage time and substepping yourself, with similar behaviour to ODE, disable substepping, don't use/create motion states and use

Code: Select all

stepSimulation(deltaTime,0);

Hope this helps,
Erwin

[abaraba]

(Re)Designing an API...

Code: Select all

Thus newbie code.. / ..more newbie-friendly / ..so that newbies have an easy time / ..also be newbie-friendly / easy for newbies.. / The newbie developer.. / what newbies pass.. / really help the most to the newbie end user

how in the world.. newbies?
there is no such thing really.. that logic is artificial and when forced to existence can make you only do the wrong things.. you SHOULD NOT design *anything* for newbies, never, ever... the closest thing to that misthink is a designing 'graphical user interface' for children or handicapped... no TVs for newbies, no remote controller for newbies, no Xbox for newbies, no C++ for newbies, ok?

because in practice it means - trying to accommodate for someones ignorance, assumptions and every other way people can be foolish... plenty of those, futile attempt obviously, no?

why just not make documentation clear and easily accessible, maybe answer some questions properly on the forum, more importantly even - do not attempt answering questions you do not know about ..and basically encourage and make it easy for newbies to LEARN not try to accommodate all the ways they can make mistake...


how else?
you dont really have to think about API "interface" at all, not as such - look, make your code SMALLER, not necessarily in the number of characters or even lines of code but smaller in the number of *terms* you define in order to communicate information and response throughout the code.. of course it does almost always practically lead to less lines of code, less variables, less function calls, less arguments.. less of everything

and by doing so,
you would most certainly make it faster and more memory efficient as well - but the best of all, simplicity and bare logic is all you need to accommodate newbies - it will be *easy to learn*


"All other things being equal, the simplest solution is the best."
-Occam's razor




[edit:]
Bullet library is GREAT, its already very simple, *easy to learn*, fast and still having all these great features... it reminds me of OpenGL and they beautifully go together, i LOVE THAT!

note,
everyone has source code -its yours-, go on, change everything as you like... i will try your Bullet library for newbies and maybe id stand corrected, dont let me discourage you, its only an opinion..


//--------------------------------
not quite related to above but still helpful for newbies:

i believe,
Bullet demos should have its files completely separated, so they can be easier "isolated", compiled separately, browsed and generally be easier to learn from.. they share far too much code in too many files that are on too many places, there is really no point saving space and removing redundancy in this case, they're just demos..

thats what i loved about OpenGL Red-Book, its perfect example how to teach, document and demonstrate library/API

my moto would be ONE DEMO - ONE FILE, and strictly to the point what demo is demonstrating, nothing else.. its much easier to scroll up/down even a very large files than to jump left/right in multiple files


cheers,
...rainbow and lollipops, lalala la la... riding the unicorns..

[stenyak]

There are two ways: you let Bullet deal with all this (using motion states and subdividing the timestep), or do it yourself. Just set the second argument to zero, which disables subdivision of the timestep. If you have any issues with the implementation, please derive from the class and override the default implementation.

Again, if you want to manage time and substepping yourself, with similar behaviour to ODE, disable substepping, don't use/create motion states and use

Code: Select all

stepSimulation(deltaTime,0);

Hope this helps

Yes, thanks a lot, it helped. I've been reading so many different ways to do the same thing, that i didn't know which one to choose. The (dt,0) way works correctly.

I've implemented the helloWorld in my multithreaded draft. I can run several Bullet simulations at the same time at their own frequency now, and it works correctly (1000Hz seems more accurate than 500Hz,100Hz or 10Hz, but they all provide very similar results before the butterfly effect comes into play).

In case someone wants to know, this is the actual code i'm using... read the "main" method (beware that it is run in parallel with the graphics/sound/input/multiplayer/etc engines, so if your app is single-threaded, your main loop will look a bit different): http://www.motorsport-sim.org/hg/trunk/ ... hysics.cpp

(Re)Designing an API...

Code: Select all

Thus newbie code.. / ..more newbie-friendly / ..so that newbies have an easy time / ..also be newbie-friendly / easy for newbies.. / The newbie developer.. / what newbies pass.. / really help the most to the newbie end user

how in the world.. newbies?

(i used to say "newbies", but batch stepping can have its use beyond simple demos, of course).

I used the term "newbies" to refer to simple apps, but it actually applies both to newbies and to many applications. It's not my case though, since i need complete control over each of the physic steps (i'll code some networked physics, physics-based replays, and other things).


BTW, in the end, it looks like Bullet works exactly as i expected, and the only problem seems to have been communication