P3Dv4.3 : my observations

[Pete Dowson 558]

7 hours ago, Rob Ainscough said:

you gents have been around a long time and I know you know FFTF changes can result in blurries.

This is the reason for FFTF dynamic. Blurries don't occur when low and slow, or at airports, when one might experience worse frame rates, but having the FFTF value increase to normal values as your aircraft climbs makes sense. I use the program and am very pleased with it. You can have it altitude or frame rate based -- both work for me as my frame rates only really suffer low and slow or at airports. No such problems flying between airports.

Pete

 

[Mitch24 194]

Can anyone tell me if there has been any leads on this blurries issue yet? 

[Chris Bell 165]

just to clarify i am not referring in any of my comments to the use of the program mentioned to set these values!
i am not familiar with it nor commenting on it just the variable in question and its values,
as if manually setting these values in Prepar3D.cfg,

Edited July 29, 2018 by Chris Bell

[Cruachan 705]

44 minutes ago, Chris Bell said:

im sorry Mike your FFTF usage premises contradict itself,
FFTF is not intended to increase performance in harsh approaches or takeoff's!
by reducing FFTF interval value you are in effect increasing load on your system by instructing it to cycle faster!
hence inducing blurries potential; especially when rendering a much wider terrain radius!

as Rob advised earlier this creates an artificial effect of higher frames as you cycle through faster a much smaller radius as you come closer or in a demanding scenery,

Hi Chris,

I’m guessing you haven’t tried it for yourself...yet! Believe me, arguments aside, it does work. Blurries are the least of my worries as I taxi around a busy hub. I am only interested in the fidelity of the immediate environment along with a reasonable frame rate that ensures acceptable fluid image updates. FFTF Dynamic does that for me and the FFTF value is then changed appropriately as I ascend into the skies and depart towards more frame rate friendly scenery.

Regards,

Mike

[Pete Dowson 558]

4 hours ago, Chris Bell said:

that may work for FSX, this is still a discussion about P3D v4.3 right? 

The FFTF dynamic program works fine with 4.3. I don't think it was ever released for FSX. It's been a really great help for my system -- previously I always used FFTF at 0.01 to get usable frame rates at dense airports, and had to put up with the resulting blurries (refreshing scenery now and then -- I even had a button for it). It gives me the best of both worlds.

Pete

 

[Chris Bell 165]

i'm not arguing Mike ❤️
i'm terribly sorry if this is the tone i give,
i  am merely giving a rational explanation rather than "it works" or "i think it works",
to me its very logical and makes perfect sense 

Edited July 29, 2018 by Chris Bell

[Pete Dowson 558]

5 minutes ago, Cruachan said:

hence inducing blurries potential; especially when rendering a much wider terrain radius!

Exactly why you can set it to increase with altitude. 😉

Pete

 

[Cruachan 705]

8 minutes ago, Chris Bell said:

i'm not arguing Mike ❤️
i'm terribly sorry if this is the tone i give,
i  am merely giving a rational explanation rather than "it works" or "i think it works",

Oh, I can assure you that it works...please give it a try, Chris. Everything you have said is true and the clever FFTF Dynamic utility is exploiting those realities to help us out in some very challenging situations. I would never consider running with a fixed FFTF value of 0.01* in all situations - that's asking for trouble! However, it can be very helpful for short periods just as I have described.

*In fact I never use a value as low as 0.01, I prefer 0.05 or even 0.15. Still experimenting!

Best regards,

Mike

[Chris Bell 165]

@Pete Dowson
ooh i get why its set back to default .33 at higher alt,
at lower altitude lowering this value is not actually freeing up frames,
its just cycling faster creating an artificial effect of higher frames in lower lod's,

@Cruachan
for a minute there i was not doubting anyone reporting this is not seeing increased frames in those tight situation,
your rational to why this is happening is misguided; despite the increase in frames readout,
you are in effect inducing overload on your system when lowering these values,

and again im not doubting the end results when doing so im am basically backing that up :) 

[Cruachan 705]

Hi Pete,

Actually that was Chris...but quite happy to take the credit!

Regards,

Mike

[Cruachan 705]

1 hour ago, Chris Bell said:

FFTF is not intended to increase performance in harsh approaches or takeoff's!

Hi Chris,

In the end I suppose it all boils down to how one defines performance. The nuts and bolts of how this is achieved really doesn’t matter. What does matter is what is perceived on screen and the FFTF Dynamic utility does that for many of us. Go on Chris, I dare you, give it a shot!

Regards,

Mike 😉

[Chris Bell 165]

imo it does Mike!
as clever as it is; it is still an "exploit" and not by design,
one should be clearly aware and wise to this when deployed,

(not to take from the tool developer;
it will take me less than 5 seconds to write a script that does this )
 

Edited July 29, 2018 by Chris Bell

[Guest]

I'd recommend reading Beau's response very very carefully, I think some might not be understanding:

Quote

While jobs that create/load terrain texture run in the background, the jobs that request textures based on distance from the user run on the main thread. If these jobs don't get enough time to run, you can see delays in your terrain loading.

Jobs that run on the main thread are given a certain amount of time each frame. If you internally limit, these jobs get however much time is left. 30fps = 33ms, so if the main work is done in 23ms, then these jobs get 10ms to play with which is ok. If your main frame work takes 31ms, they only get 2ms, and you may see delays. With unlimited, the jobs time slice is determined by a percentage of the frame which is configurable in the Prepar3D.cfg using:

FIBER_FRAME_TIME_FRACTION (default is 0.33 or 30% of the frame time).
MIN_FIBER_TIME_SEC (Default is 0.001 or 1ms)
MAX_FIBER_TIME_SEC (Default is 0.1 or 100ms)

Lets say you're actually getting 60fps but externally limiting down to 30. The extra 16ms is being wasted sleeping rather than doing terrain loading requests. The part of the system calculating the fiber time percentage thinks you're running at 60fps because it's counting time form the start of the frame rather than the total time of the previous frame.
Perhaps you should try bumping up the fiber time fraction or min fiber time to ensure that more time is spent doing work and less time is spent sleeping.

The last sentence is key.

Cheers, Rob.

[Chris Bell 165]

its also important to note that this manipulation is "suggested only" when locking frames externally!
as long as frame are not restricted externally there is no need to compensate or interfere as sim can calculate these cycles most efficiently on its own, 

[Cruachan 705]

53 minutes ago, Chris Bell said:

as clever as it is; it is still an "exploit" and not by design,
one should be clearly aware and wise to this when deployed

Absolutely! No argument there.

LM designed their simulator around a specification which, for most of us is very familiar and yet, in many respects, has become a distant memory. Our differing installations must frequently seem at odds with the sim’s creators and yet these sometimes require the simulator to perform under some pretty tough, some would say unreasonable and unrealistic, conditions. While not by design it is still possible and tools such as the FFTF Dynamic utility help us to achieve our goals. This objective has not been accomplished by existing design, but instead by creative invention that is exploiting and manipulating a core feature made available to us by the sim’s Developers.

Regards,

Mike