Smooth and No Stutters - suggested solution

[Martyson]

Which plane in P3D has smooth LOC/GS indications if I may ask?

Which one does not?

[whitav8]

A couple comments:

The 24(25) flicker rate concept only applies to a dark room (theater) with a single source of bright illumination (the projector) and the persistence of the eye (50 to 100 milliseconds) in that situation - it doesn't apply to monitors. The human eye with monitors can detect stutter/jumps/improper refresh up to about 80-90 fps - this is why the FAA requirement for scene/image update is a hard and fast 60Hz for airliner(non military) flight simulators. Since that can only be accomplished for a single monitor, these simulators use a separate PC for each channel - each with a Field of View of about 50 degrees. The best military flight simulators typically aim for at least 72Hz scene update rate or so to keep the horizon line from stuttering at high roll rates. Virtual Reality requires 90 fps stereo (non VR rates of about 200 fps) to deal with high rates of scenery change as you check your six or just look sideways - the only flight sims that can do that currently are Aerofly FS2 and Combat Air Patrol 2. FSX/P3D + Flyinside uses replicated frames to meet the 90Hz goal which causes some stutter and isn't as fluid - but still is a great start for VR flight sim.

[105OE]

Which one does not?

Is this a serious question? You never noticed the microsteps the LOC/GS needles are doing instead of a continuos smooth movement in P3D and FSX???

[Martyson]

Which one does not?

Is this a serious question? You never noticed the microsteps the LOC/GS needles are doing instead of a continuos smooth movement?

Microsteps .. were we talking about microsteps here?

Do a video showing the problem you see.

[105OE]

Well, there's certainly no need to upload a video as this problem exists since ever on MS Simulators.
Suggest to fly an ILS (or LOC) approach and observe that the LOC needle is performing jerky small steps instead of a fluid continous motion when intercepting/correcting.
These jerky movements make timely and very precise corrections impossible.

[Martyson]

Well, there's certainly no need to upload a video as this problem exists since ever on MS Simulators.
Suggest to fly an ILS (or LOC) approach and observe that the LOC needle is performing jerky small steps instead of a fluid continous motion when intercepting/correcting.
These jerky movements make timely and very precise corrections impossible.

Are you referring to just the ILS gauges or all gauges in the aircraft(s) default and or payware aircraft?

Is this with the autopilot On or a hand flown loc intercept and ILS approach?

[Peter Dooley]

As I eluded to previously, frame rate is essentially only a measure of hardware performance and its ability to render a given scene as fast as possible. The more content it has to render, the slower the frame rate.

This however has nothing to do with what I am talking about when I refer to draw rate or update rate which is the speed at which the P3D software is capable of updating the scene and which is currently limited to 18 updates per second. So we can throw as much hardware as we like at it, the update rate limitation is still 18 even if we were able to get a frame rate of up to 300Fps

It is also true that different users will experience this draw rate differently depending on how much content is being drawn and how fast or slow or high or low they are flying. The truth is, irrespective of the factors above, the scene can only update 18 times per second and therein lies the problem.

[Martyson]

"The truth is, irrespective of the factors above, the scene can only update 18 times per second and therein lies the problem."

For P3D to increase updates from 18 times per second to a higher value (like 100) do they just have to change a "value" in their software (a simple fix) or do they have make many changes taking into consideration users:

CPU, OS, graphics card, payware scenery, number of monitors, monitor type, SLI, P3D settings, Nvidia profile settings are in use?

[whitav8]

I believe the 18 times per second issue only affects the redraw of some of the instrument pointers in the cockpit - it's not just the graphics but also any code that was involved in calculating that instrument's display values (scaling,etc.) The outside scene has it's own limitations due to clouds, shadows, reflections, number of polygons in the airport/city scene,etc...

The concept for the 18 per second update rate for instrument pointers came from long ago when every little bit of performance was required. Many new third party cockpits do not have that limitation - just default aircraft - unless the 3rdparty chose to use that concept. Today's CPUs do math very quickly!

[105OE]

1.Are you referring to just the ILS gauges or all gauges in the aircraft(s) default and or payware aircraft?
2.Is this with the autopilot On or a hand flown loc intercept and ILS approach?

1.The VOR/ILS gauges. If e.g. ASI, AH and ALT would be that jerky everone would complain!
Haven't come across any default or addon plane without jerky gauges yet.
2. Doesn't make any difference of course!

[WarpD]

My system must run on magic.

On my system the scene refresh is the same rate as my frame rate.
On my system the needles on my gauges move in a fluid manner without jitters or delays.

Pure magic....

Oh... and I know of no all encompassing FAA requirement for frame rates. There might be specific types of simulators required to have 60fps... but all of them... not that I'm aware of.

[whitav8]

@Ed,
Regarding FAA simulators and 60Hz, you are correct, I really was referring to just Level D, Highest Fidelity sims - not the part task trainers - FTDs.

Dave

[Peter Dooley]

The 24(25) flicker rate concept only applies to a dark room (theater) with a single source of bright illumination (the projector) and the persistence of the eye (50 to 100 milliseconds) in that situation - it doesn't apply to monitors. The human eye with monitors can detect stutter/jumps/improper refresh up to about 80-90 fps - this is why the FAA requirement for scene/image update is a hard and fast 60Hz for airliner(non military) flight simulators

Thanks Whitav8, I fully agree with you. This just further highlights how slow 18Hz actually is in a modern simulation environment. I did say right up front that 25fps would be the minimum but I have my doubts if the simulation software could deliver 60fps given the huge amount of background calculations etc that it needs to perform in order to deliver an update to any given scene. This would apply to both gauges and visual content.

I must however point out that most consumer video recorders only shoot at around 30fps so where as Whitav8 pointed out, the human eye can detect stutter up to 60 - 80 fps on military simulator and FAA spec monitors, those consumer video images on our standard home monitors and TV sets would really look ugly. I think we have to be careful not to use these specs as a benchmark. We have been satisfied with 24 - 30 fps on our monitors and TV sets for years. For interest sake, I have copied some common specs found on consumer cameras just to make my point:
4K Ultra HD Video at 24/30 fps, 2704 x 1520p / 30 fps / 25 fps / 24 fps etc

Furthermore, you are right about the 25fps being related to projector flicker in a dark environment. Truth is, P3D is intended mainly for commercial and military simulators that mostly have projected visuals on HD projectors in dark environments mixed with EFIS gauges in the cockpit running on monitors and then some analogue instruments interfaced to the simulation. So in this case, the 18fps update rate falls well short of both the projector and monitor requirement.

Lastly, I am almost certain that the update rate of the visual scene is similar to that of the panel gauge scene (18fps) and to avoid any speculation, lets invite LM to either confirm this or to give us some more insight into what the differences really are if any. We are all looking for a solution here and this is in now way a criticism.

[Peter Dooley]

Correction to typo in previous post

This is in NO way a critisism

[Peter Dooley]

I believe the 18 times per second issue only affects the redraw of some of the instrument pointers in the cockpit - it's not just the graphics but also any code that was involved in calculating that instrument's display values (scaling,etc.)

Dave raises another interesting point here regarding scaling. I will use the LOC pointer as an example.

The simulator navigation engine uses a scale of -127 to + 127 for full scale deflection left to right for the LOC pointer position. For my example, lets call these increments "127 notches" left and right of the zero point. If we then had a gauge with lets say a needle of 1 pixel wide and the gauge was sized to give 255 pixels across the outer deflection dots ( full scale deflection) then as the aircraft moved through the localizer, the needle would jump 1 pixel left or right for each notch that is passed and would appear perfectly smooth. In other words, if the localizer moved by a value of 10, the needle would move through exactly 10 pixels at the same rate.
If however our gauge was only 68 pixels across, then for every 4 notches passed we would only see the needle move 1 pixel (scaling). If on the other hand, the gauge was 510 across, the needle would appear to jump 2 pixels at a time for each notch passed but most navigation gauges in our normal simulators are not that big.

So in the case of the 255 wide gauge, that would all work fine except that if we only updated the gauge at 18fps and we were flying through the localizer at lets say 54 notches per second, then the needle will skip two pixels to every third pixel due to the update rate not being fast enough to redraw each and every notch change and the needle will then appear to stutter.

Now, in most cases, we do not fly through the localizer at such a fast rate but we do have needles and graphics moving at a much faster rate such as altitude indicator, attitude indicator, vertical speed indicator, rpm and the outside scenery to name but a few.

So with a slow update rate of 18fps, we are going to experience some degree of stutter.

Lastly getting back to the FAA requirement of 100ms, the JAR has a similar response time requirement of 150ms for full flight simulators as well as FNPT simulators which is what most of us are flying and they call this response "transport delay". What that means is, if you perform an action in the cockpit, the pilot must be able to see that response in the simulation scene or gauge within 150ms. A good example of this is if he switches the landing or taxi light on, the software must be able to update and redraw the visual scene of the illuminated taxiway or runway within 150ms.

In our case, this delay is being caused primarily by a slow update rate of 18Hz