Advanced Question [SOLVED]Is it possible to lock framerates in Orbiter2010

[Michael_Chr]

Working on this project with Gattispilot
http://www.orbiter-forum.com/showthread.php?t=34875&highlight=athlete
We have come across a problem which is caused by what must be regarded as exessive framerates.
I have a system where - if the scenario is benign - I will exerience sometimes more than 1600 FPS. This is off course using the latest DX9 driver by Jarmonik with the patch provided by Jededia.
Normally this doesnt cause any problems but with this vehicle we experience movement jitters and also jumping when resetting the touchdownpoint lower.
The amount of jitters and jumping is directly related to the number of framerates ie. lower framerates much less and thereby jitter and jumping.
So...while trying to figure this out I would like to ask if anyone know of a way to set a max FPS rate rate in orbiter 2010 on a global level (or Using DX9).
Framerates in excess of say 60 are useless anyway....So in this case less is actually more (or better)

Best regards
Michael

 

[martins]

I don't see how an increase in the sampling rate can make the discrete physics worse, unless you are trying to do something unphysical.

In your concrete case, the physical parameter in question is the speed at which you lower the touchdown points. From one frame to the next, the touchdown points should be lowered by dx = v dt, where v is the speed at which the gear moves down, and dt is the frame interval.

If you lower the points instantaneously all the way in a single frame, then of course the results will become framerate-dependent, and will approach an infinite value of v as the frame rate gets higher. This will in turn generate huge contact forces and blow your vessel into interstellar space.

If behaviour becomes instable at high frame rates, it's a sure indication that something's wrong with the physics model. Instability at low frame rates is a different matter, and a lot harder to fix..

The next orbiter version will even feature time step subsampling to allow higher frame rates in the physics subsystem than what the graphics card can provide. This is required to model surface interactions robustly, which typically occur on very short time scales.

 

[Urwumpe]

If behaviour becomes instable at high frame rates, it's a sure indication that something's wrong with the physics model. Instability at low frame rates is a different matter, and a lot harder to fix..

Especially that one.

If you design autopilots for Orbiter, remember that you have no fixed sampling interval even on your own machine. Your control loops must be capable of handling that, either by making the control loops more stable but slower and less accurate, or by filtering the measurements of Orbiter and working only with already filtered measurements (so that the time is no longer an important factor).

And if you do your own physical calculations, remember that shorter time steps can add more noise to them via derived inputs, not less.

 

[Michael_Chr]

Thanks guys for your input.
We will continue to stride along :thumbup:

Per Aspera Ad Astra

 

[Kyle]

1600 FPS? That's quite a setup! On my computer I'm lucky to get 20 FPS.

 

[Ripley]

Wasn't there something called vsync to cap one's fps?

...And BTW, which patch?

...This is off course using the latest DX9 driver by Jarmonik with the patch provided by Jededia...

 

[Michael_Chr]

1600 FPS? That's quite a setup! On my computer I'm lucky to get 20 FPS.

1600 is only in a very benign and simple scenario. I have seen as low as 30 in very dense scenarios. Like this:
http://www.orbiter-forum.com/gallery/showgallery.php?cat=674&ppuser=

...And BTW, which patch?

Jededia made a patch to latest DX9 driver by Jarmonik because there was a bug in the original code that affected IMS. See link below:

http://www.orbiter-forum.com/showthread.php?t=28837

You only need this patch if you nedd to run IMS in DX9

 

[N_Molson]

I have seen as low as 30 in very dense scenarios. http://www.orbiter-forum.com/gallery...at=674&ppuser=

This is quite extreme. You definitively have quite a good rig !

 

[kuddel]

Hi Michael,
to get back to the original question:
As far as I know there are two parameter in the D3D9Client.cfg which you can use:

FrameRate = 200
EnableLimiter = 1

What they do should be obvious . FrameRate values are in fps (frames per second)

But to limit the time-steps more precisely you should use the 'vSnc' setting at the launchpad.

To quote the D3D9Client manual (Doc/D3D9Client.pdf):
[...]
FPS Limiter
With this option enabled a frames per second limiter is enabled that will limit the number of
frames that will be rendered per time interval (per second that is). Limiter FPS value is set
using D3D9Client.cfg
This feature is created to reduce unnecessary GPU/CPU load. Not to produce a stable frame
rate. Improper setting can cause extreme tearing on the screen. Setting the frame rate limiter
to 200fps usually works pretty well. It is recommended to use vertical sync feature from a
video tab instead of this.
[...]
/Kuddel

 

[martins]

Another question to the original poster:

Is the jitter problem caused by the high frame rates per se, or rather by variations in frame rate, which may be more pronounced if the average frame rate is high to start with?

A good debugging tool to test this is the "fixed frame rate" option under the Debug section of the Extra tab. If you set a very short fixed time interval, this mimics a high, but constant frame rate independent of computer performance and scene complexity, so it should make things repeatable and thus easier to debug.

If the problem goes away with this, it would suggest that frame rate variability is to blame. This could be to do with inconsistencies in state updates and race conditions, e.g. inconsistent mix of state updates in clbkPreStep and clbkPostStep.

Note that in Orbiter 2010, the physics updates are slightly dirty - if one vessel depends on the state of another vessel, the order in which vessels are updated may affect the outcome, because on query you might receive either the pre-step or the post-step state (this doesn't affect vessels across a docked assembly, which is updated separately).

In the next version, this will be treated more cleanly. During update, each vessel has a "current" state and an "update" state. Only the current state is public and can be queried by other vessels, while the update state (i.e. the next time step being computed) is private to each vessel. Only once all vessels have updated themselves, they swap their update state to the current state simultaneously. This disentangles the interdependency of state updates, and may make it easier in the future to parallelise the updates.

 

[BruceJohnJennerLawso]

Wasn't there something called vsync to cap one's fps?

...And BTW, which patch?

Yeah, because monitors refresh at 60Hz, sometimes the graphics update loop will have their main event loop capped at 60 FPS max to avoid issues with tearing (stuff not drawing in the correct order since the monitor cant keep up with the physics engine)

IIRC, I think Vsync for Orbiter was posted on the Altea site?

I would agree with all of the above, by definition high frame rates should not cause problems in a physical model. Maybe check and see if there are any issues with converting between variables of different precisions?

Good Luck

 

[orb]

IIRC, I think Vsync for Orbiter was posted on the Altea site?

I don't know how it's with specific graphics clients, because I don't use any at this time, but isn't that simply achieved by removing checkmark from "Disable vertical sync." checkbox without using any add-ons?

 

[Loru]

Yeah - enabling Vsync should tie your framerate to your display frequency.

 

[jedidia]

Ok, all this talk about fixed and/or caped framerates is making it really hard not make an Ubisoft joke... :shifty:

This will in turn generate huge contact forces and blow your vessel into interstellar space.

Iiiiiinteresting... I never realised that the gear deployment produced actual force. I always thought it was more of a visuals shift kind of thing, not an actual physical force applied to the vessel.
This explains perfectly well why my experiment to hack in terrain detection for UCGO cars via adjusting touchdown points didn't work the way I expected it to all those years ago :lol:

 

[Michael_Chr]

Hi Michael,
to get back to the original question:
As far as I know there are two parameter in the D3D9Client.cfg which you can use:

FrameRate = 200
EnableLimiter = 1

What they do should be obvious . FrameRate values are in fps (frames per second)
/Kuddel

This works pretty well for me - Just for clarity for anyone else in the future reading this post. When editing D3D9Client.cfg (in orbiter root DIR) Orbiter launchpad has to be closed. Non-compliance with this may cause that the original values are reinstated in this file upon exit/restart of Launchpad (speaking from experience :rofl

Another question to the original poster:
A good debugging tool to test this is the "fixed frame rate" option under the Debug section of the Extra tab. If you set a very short fixed time interval, this mimics a high, but constant frame rate independent of computer performance and scene complexity, so it should make things repeatable and thus easier to debug.

If the problem goes away with this, it would suggest that frame rate variability is to blame. This could be to do with inconsistencies in state updates and race conditions, e.g. inconsistent mix of state updates in clbkPreStep and clbkPostStep.

Tried this procedure. Setting fixed frame rate to 10e-3 on my system creates an environment which is pretty close to realtime. The jittering and jumping is quite consistant which then leads to the conclusion that framerate variablity here is not the culprit here. The high framerate is.

But it seems that a locked framerate of 60 FPS will give a good consistant result (which is what we need right now just for testing). We still need to look into the matter because a lot of users will experience lower than 60 FPS and this should still produce a consistant and predictable result.

Thanks all for your input...really a great help (and I'm sure I also speak on behalf of Gattispilot)

 

[gattispilot]

Let me explain what we are doing. Maybe it is wrong.

Basically the Athlete has 7 robitic arms. 6 seen 1 invisible. The invisible one is what changes the touchdown points. Why invisible is so the base will remain level. If it is based off of 1 limb you move then that touchdown point would change.

So like a robotic arm at the end is an attachment point. In this case it is not an attachment but a vector. That is located at where the tire would hit the surface.

arm_tip[0] = _V(-4.237, -8.51, 0);
	arm_tip[1] = _V(-4.237, .01, 0);
	arm_tip[2] = _V(-4.237, .01, -1);

so arm_tip[0] is where the tire would hit the surface.

so in the animation:

rmsG_anim[9] = new MGROUP_ROTATE(LOCALVERTEXLIST, MAKEGROUPARRAY(arm_tip), 3, _V(-4.23, -8.51, 0), _V(0, 0, 1), (float)(894 * RAD)); // -447 .. +447
	anim_JOINT8G = CreateAnimation(0.0);
	hAC_arm1 = AddAnimationComponent(anim_JOINT8G, 0, 1, rmsG_anim[9], parent);

So as that limb moves so does arm_tip.

But all we want to change is the Y value.

so:

oldy = (arm_tip[0].y);
	if (oldy > -.01) oldy = -.01;

	SetTouchdownPoints(_V(0, oldy, 1), _V(-1.6, oldy, -1), _V(1.6, oldy, -1));;

so then touchdown y values changes as the y value of the animation.

so here is where the animation changes.

sts->JOINT1G_proc = min(1.0, sts->JOINT1G_proc + (t1 - t0)*ARM_OPERATING_SPEED);

const double ARM_OPERATING_SPEED = 0.01;

The question I have is even though the touchdown point isn't moving the vessel moves in time acceleration

---------- Post added 12-19-14 at 06:18 AM ---------- Previous post was 12-18-14 at 07:48 AM ----------

We determined the constant checking of touchdown points was causing this:

I thought this would fix it but it doesn't.

void TRIATHLETE::clbkPostStep(double simt, double simdt, double mjd)
{


oldy = (arm_tip[0].y);
	if (oldy > -.01) oldy = -.01;
	if ((MODES == 1 || MODES == 2) && (oldy1 /= oldy)){
		 { SetTouchdownPoints(_V(0, oldy, 1), _V(-1.6, oldy, -1), _V(1.6, oldy, -1));; }

		oldy1 = oldy;

	}

So in modes 1 or 2 check to see if the y value is NOT the same as current y value if is is then changed touchdown points. If if is the same then do nothing.

 

[Urwumpe]

Unequality is "!=" not "/=" ... "x /= y" is the syntactic sugar for "x = x / y"

In your case the term "oldy1 /= oldy" should always be evaluated as true unless any of the two is zero.

 

[gattispilot]

Thanks:thumbup:

I think that fixed that. But he reports a difference of traveled speed depending on framerate.

 

[Urwumpe]

Thanks:thumbup:

I think that fixed that. But he reports a difference of traveled speed depending on framerate.

Yes, because you are likely not making use of the parameter simdt of the prestep or poststep callback. I don't know where and how you define t1 and t0, but I suspect you do it wrong since in the usual case in physics, t1 - t0 should be simdt.

 

[orb]

unless any of the two is zero.

Only the first one (dividend). Infinity is "true", too, and 0.0 / 0.0 returns infinity.