@Rob Ainscough
once entry is injected and .agn updated respectively all will remain in place unless removed,
it doesn't need to run more than once,

 

7 minutes ago, jabloomf1230 said:

I'm not entirely sure why you think that it should be dynamic.

pondering the same :) 

Edited August 4, 20187 yr by Chris Bell

6 minutes ago, Chris Bell said:

@Rob Ainscough
once entry is injected and .agn updated respectively all will remain in place unless removed,
it doesn't need to run more than once,

I'm pretty sure that it is included in exe.xml (or add-on.xml) to check for missing autogen and correct those errors.

i believe you can run it through exe.xml to run a check;
if not mistaken its compared against SDK autogen.xml version,
not new entries unless the SDK version manually updated as well to reflect new entries,
 

@Rob Ainscough
i think you may be confusing the M in ACM? it stands for Merger,

Edited August 4, 20187 yr by Chris Bell

@Rob Ainscough Any news regarding your tests? Eagerly waiting for your video ;-)

YouTube just finished processing my video to 4K here: 

I tested on 3 PCs

7700K 1080FE SSDs (2160p @ 60Hz capped to 29.5 via NI)
8700K 1080Ti  SSDs (1440p @ 60Hz capped to 29.5 via NI)
7900X TitanXP  SSDs (2160p @ 30Hz)

Results were the same on all computers.  Summary:

1.  TFR = Unlimited with high graphics settings will increase the probability of stopping Autogen batches from rendering
2.  TFR = xx frames with lower FFTF values (below 0.33) will increase the probability of stopping Autogen batches from rendering
3.  The TFR = Unlimited issue is NOT specific to any add-on and can be repeated in a default P3D V4.3 and P3D V4.2
4.  If the Autogen system gets far enough behind on rendering it stops rendering completely (pause will not recover processing) and will require a scenery reload (map a controller button to it).

Graphics settings are dotted thru-out the video.  When add-ons were used (final last test towards end of video from LFLI - EGLL complete flight) I was running TFR=31, FFTF = 0.33, Vsync ON ... Add-on list was extensive (Orbx FTX Global, Orbx OpenLC EU, Orbx HD Trees, Orbx Vector, HiFi AS4, Turbulent Flora, FSDT LSGG Geneva, LLH Creations LFLI, ChasePlan, PILOT's NG 2018 Mesh, FSFX Packages, UTLive, ENVTEX/ENVSHADE, and a few others).

I kept the flight test between 0 - 7000 ft and speed of 400-500Kts and heading the same direction (about 333).  GA aircraft tend to fly slower so they will put less stress on the Autogen batch system ... so experiment (Unlimited with Vsync make work sufficiently for low and slow flights, and/or lower FFTF values if using TFR = xx).

I have NOT tested with the FSPS Dynamic FFTF product, I have purchased but not had time to try it yet.

I have made LM aware, but it's most likely an "expected" result and who knows what the future might bring.

Cheers, Rob.

“Who knows what the future might bring”

I like the sound of this cryptic statement 🙂

 

8 hours ago, Rob Ainscough said:

YouTube just finished processing my video to 4K here: 

I tested on 3 PCs

7700K 1080FE SSDs (2160p @ 60Hz capped to 29.5 via NI)
8700K 1080Ti  SSDs (1440p @ 60Hz capped to 29.5 via NI)
7900X TitanXP  SSDs (2160p @ 30Hz)

Results were the same on all computers.  Summary:

1.  TFR = Unlimited with high graphics settings will increase the probability of stopping Autogen batches from rendering
2.  TFR = xx frames with lower FFTF values (below 0.33) will increase the probability of stopping Autogen batches from rendering
3.  The TFR = Unlimited issue is NOT specific to any add-on and can be repeated in a default P3D V4.3 and P3D V4.2
4.  If the Autogen system gets far enough behind on rendering it stops rendering completely (pause will not recover processing) and will require a scenery reload (map a controller button to it).

Graphics settings are dotted thru-out the video.  When add-ons were used (final last test towards end of video from LFLI - EGLL complete flight) I was running TFR=31, FFTF = 0.33, Vsync ON ... Add-on list was extensive (Orbx FTX Global, Orbx OpenLC EU, Orbx HD Trees, Orbx Vector, HiFi AS4, Turbulent Flora, FSDT LSGG Geneva, LLH Creations LFLI, ChasePlan, PILOT's NG 2018 Mesh, FSFX Packages, UTLive, ENVTEX/ENVSHADE, and a few others).

I kept the flight test between 0 - 7000 ft and speed of 400-500Kts and heading the same direction (about 333).  GA aircraft tend to fly slower so they will put less stress on the Autogen batch system ... so experiment (Unlimited with Vsync make work sufficiently for low and slow flights, and/or lower FFTF values if using TFR = xx).

I have NOT tested with the FSPS Dynamic FFTF product, I have purchased but not had time to try it yet.

I have made LM aware, but it's most likely an "expected" result and who knows what the future might bring.

Cheers, Rob.

Thanks Rob for testing.

 

 

 

Rob - food for thought!!! Thanks for taking all the time and trouble to compile this video - much appreciated!

Adm.

what would we do without you Rob!
above and beyond 💜

Edited August 10, 20187 yr by Chris Bell

22 hours ago, Rob Ainscough said:

......I tested on 3 PCs

7700K 1080FE SSDs (2160p @ 60Hz capped to 29.5 via NI)
8700K 1080Ti  SSDs (1440p @ 60Hz capped to 29.5 via NI)
7900X TitanXP  SSDs (2160p @ 30Hz)

..........

Cheers, Rob.

Understandable, brilliant! Thank you very much!

I finally understood what the "enemy" was: Shift "z" twice! What is gained in Fps with the unlimited option is in fact a false "friend" for me.

By putting at 25fps + Vsync ON I gained in fluidity. Of course on big airport addons + some aircrafts like Fslabs and so...it's a little more "jerky" but the feeling remains nevertheless very pleasant, much more pleasant and flyable than with the unlimited option in the same conditions...without counting the advantage of the Autogen regained...

Thanks again and Regards,

Edited August 11, 20187 yr by DrumsArt

It was Rob's painstaking video that finally persuaded me away from my long-time "Unlimited" TFR setting - which I've been using for a fair while, as it gave me a fairly decent frame-rate and was *silky-smooth*.

Like many people here, I was beginning to get frustrated by this autogen [not] re-drawing problem. Has it got worse with progressive P3D "updates", I wonder? I used to get around this by re-loading the scenery (I have key mapped for it) but found I was having to do it increasingly often.

Anyway - I bit the bullet, and am so glad I did! My system is too old and jaded (just like me!) to benefit from any FFTF tweaks, so it's left at the default 0.33, with TFR set to 31 (my monitor is 60Hz) and VSync set to on.

I'm getting a few "long frames" (micro-pauses) but I can live with that, as I can now enjoy full-blown autogen throughout the length of the trip.

Thanks to all that have contributed to this interesting (and rewarding!) thread - and especially to Rob .

Adam.

 

2 hours ago, Adamski_NZ said:

TFR set to 31 (my monitor is 60Hz) and VSync set to on.

I'm getting a few "long frames" (micro-pauses) but I can live with that, as I can now enjoy full-blown autogen throughout the length of the trip.

Use 29 not 31. Also 29 yields an increase of 6% throughput.

...look at it this way. Say we have a 60Hz monitor - do we lock at 60 (assuming a fast enough system)?

Look at the monitor more closely and we see it's most likely wobbling between 59 and 61, or slightly worse.

So do we set 61 or 59? If we go for the higher frequency we lose frames since mostly the monitor shows less than 61.

So to set the higher fps is a mistake and also takes more power to produce frames that are lost.

 

Edited August 12, 20187 yr by SteveW

6 hours ago, SteveW said:

...look at it this way. Say we have a 60Hz monitor - do we lock at 60 (assuming a fast enough system)?

Look at the monitor more closely and we see it's most likely wobbling between 59 and 61, or slightly worse.

So do we set 61 or 59? If we go for the higher frequency we lose frames since mostly the monitor shows less than 61.

So to set the higher fps is a mistake and also takes more power to produce frames that are lost.

 

Shouldn't be the other way around? Let's say the monitor refresh wobbles between 32 ms (a bit more than 31 Hz) and 34 ms (a bit more than 29 Hz).

If I set the target frame rate to 29 fps, every frame is produced every 34.48 ms, a longer time than 34 ms, so every frame should be lost?

4 hours ago, Murmur said:

Shouldn't be the other way around? Let's say the monitor refresh wobbles between 32 ms (a bit more than 31 Hz) and 34 ms (a bit more than 29 Hz).

If I set the target frame rate to 29 fps, every frame is produced every 34.48 ms, a longer time than 34 ms, so every frame should be lost?

No.

 

Here's a graph of around 20fps so it shows up better:

 

As you can see pushing an extra frame or two simply induces stutter and takes up process time that is wasted.