11 minutes ago, mpo910 said:

I do understand this very good.

This will lead to the case, that when you start a flight, all is fine because the app will choose your "in MSFS" TLOD to start with.

The downside is, that when decending, you get very high TLOD (when your Target FPS is not set to high and your machine is capable of), then when hitting the ground, the app will "fix" the last TLOD value, which was present "at" the moment you hit the ground, this is a high value, in the most cases, to high for smooth taxiing. Yesterday I got, till landing TLOD values >200,  and after I touched down it reduced quick to 105. So 105 would be the right value to maintain my "target FPS, which was 45 set by me in the app). 

With the newsest version this "105" will be around "200". That will cause stuttering.

That´s why I asked about the "fix TLOD GRound Value" set by the user.

My experience with the app has been somewhat different in that yes I might have a high TLOD when initially approaching a busy airport, but as I get closer the TLOD marches its way down and by touchdown, even with the tapering off below 1000 ft, it is very to near what it should be on the ground anyway. This suggest to me that you either have your TLOD max set way too high or your TLOD step way too low, or both, causing the app to not change TLOD down quickly enough on approach. I suggest you try the default settings and see if you can get your experience to match mine because it is certainly possible.

6 minutes ago, Cpt_Piett said:

That’s what I was thinking. In order to avoid changing TLOD on the ground, perhaps a better solution could be to gradually reduce it on descent to the in-sim value. Preferably above 1000ft AGL so that no changes will occur on final approach. 

While certainly possible to do, this breaks with the apps primary function which is to maintain FPS, not get to a particular TLOD value by a certain point. If only an app existed that already does this ... 😆

8 minutes ago, Cpt_Piett said:

It’s not an easy task to cater to so many different needs, and still manage to KISS! 💋 

Exactly!

An update on how I see the UI maturing. I want to go back to my original idea of one input item, namely Target FPS, and the rest of the options will be default or hidden unless the user clicks on the the Use Expert Settings like below:

When expert options are disabled, the app will revert to the known, tried and true default settings that will come with the app that should suit non-tech savvy users, which will likely be FPS tolerance 5%, TLOD changes enabled on the ground, TLOD minimum will be 50% of your current MSFS TLOD setting, TLOD maximum will be 200% of that setting. Decrease cloud quality will be enabled and Cloud Recovery TLOD will be set to your current MSFS TLOD setting.

For the keen observers out there, you may notice that LOD step up and down are now missing. I have done that because in my experience the step sizes required are pretty much identical to the FPS tolerance that you set. ie. with a 5% tolerance, 5 up and 5 down give the app the best chance of maintaining target FPS within the tolerance band. with 10% tolerance, the steps need to be larger otherwise it takes too long for the app to react to a TLOD change so here I have found, you guessed it, 10 up and 10 down work best. And on the lower end at say 2% tolerance, you only want small changes so 2 up and 2 down work well.

As a result, unless there is serious objection with a concrete example of a common scenario that we will all encounter or that can't be otherwise satisfied by that person using DynamicLOD_ResetEdition instead, the next version will see TLOD steps removed and they will be automatically tied to the FPS tolerance level. To compensate, the much touted TLOD changes on ground option will be introduced.

Edited February 17, 20242 yr by Reset XPDR

9 minutes ago, Reset XPDR said:

and the rest of the options will be default or hidden unless the user clicks on the the Use Expert Settings

That's an excellent idea! 👍

3 hours ago, Reset XPDR said:

Or you could do what I do when I'm in PC mode in that I use Vsync at my TV's 60Hz max refresh rate but I set my target FPS at 50 and it all works fine with no tearing.

So your FPS are fluctuating around 50 while your monitor refresh rate is 60 Hz?

But that leads to Vsync stuttering because the FPS do not match the monitor's refresh rate.

At least on my system such a setup produces significant stuttering. The only way to have a stutterfree experience for me is to have FPS fixed at the monitor's refresh rate (or a divider thereof).

What settings in NVCP do you use to get a stutterfree experience with fluctuating FPS below your monitor's refresh rate?

 

Edited February 17, 20242 yr by RALF9636

4 minutes ago, RALF9636 said:

So your FPS are fluctuating around 50 while your monitor refresh rate is 60 Hz?

But that leads to Vsync stuttering because the FPS do not match the monitor's refresh rate.

What settings in NVCP do you use to get a stutterfree experience with fluctuating FPS below your monitor's refresh rate?

It probably does stutter a little bit, but I'm an old school flight simmer where anything over 20 FPS was smooth as silk so 50 is luxury I can't say I notice it, especially since I mostly fly in VR anyway. It could be because my main monitor is a TV, but I do have it in PC mode so there is no motion smoothing going on that I know of. No special NVCP settings either.

 

1 hour ago, Reset XPDR said:

For the keen observers out there, you may notice that LOD step up and down are now missing. I have done that because in my experience the step sizes required are pretty much identical to the FPS tolerance that you set. ie. with a 5% tolerance, 5 up and 5 down give the app the best chance of maintaining target FPS within the tolerance band. with 10% tolerance, the steps need to be larger otherwise it takes too long for the app to react to a TLOD change so here I have found, you guessed it, 10 up and 10 down work best. And on the lower end at say 2% tolerance, you only want small changes so 2 up and 2 down work well.

Lol, just to show how much I or others haven't really been noticing LOD step up and down changes because when I went into my code to replace references to it with FPS tolerance instead I discovered that I hadn't even coded in LOD step down in my TLOD change logic and that it was always using the LOD step up value regardless of what LOD step down you had set. Oh well, at least it shows it shouldn't be missed too much because neither I nor others have noticed it to date. 😄

8 minutes ago, Reset XPDR said:

anything over 20 FPS was smooth as silk so 50 is luxury

That is not what I mean. I mean what is called jittering in this article:

https://docs.godotengine.org/en/stable/tutorials/rendering/jitter_stutter.html

It inevitably occurs with VSync when FPS are not matching the monitor's refresh rate (or a divider thereof).

 

3 minutes ago, RALF9636 said:

That is not what I mean. I mean what is called jittering in this article:

https://docs.godotengine.org/en/stable/tutorials/rendering/jitter_stutter.html

It inevitably occurs with VSync when FPS are not matching the monitor's refresh rate (or a divider thereof).

 

Maybe a little bit but it certainly doesn't bother me.

9 minutes ago, Reset XPDR said:

Maybe a little bit but it certainly doesn't bother me.

Understood.

I might give it another try with your tool, but so far this VSync jittering has always been unacceptable for me - it is very noticeable when flying turns.

 

Edited February 17, 20242 yr by RALF9636

Just now, RALF9636 said:

Understood.

I might give it another try with your tool, but this VSync jittering has always been unacceptable for me - it is very noticeable when flying turns.

 

I doubt this tool will improve it. If anything it will make it worse with such frequent TLOD changes, even if they are small. Nonetheless, you have helped identify that this tool may not be suitable for those that run with a frame rate cap at all, because such a cap and a tool like this that needs a tolerance band around a target FPS make their operation mutually exclusive, so thanks for that 👍

5 hours ago, Reset XPDR said:

Or you could do what I do when I'm in PC mode in that I use Vsync at my TV's 60Hz max refresh rate but I set my target FPS at 50 and it all works fine with no tearing.

I tried that.  I'm using an 10 year old ISP LG 24MP55 monitor so with the refresh rate set to 50, anything fps under 48 makes the screen jitter as I pan left or right.  I'm using a MSI 1080TI graphics card

So if the FPS goes below my refresh rate the jitters happen

I even tried locking the ingame refresh rate setting to half my montior refresh rate and the jitters it are really terrible!  

I don't understand how people can get a "smooth as silk" fluid motion when using locking at half the refresh rate.

I'll shout a meal at the local pub to anyone who can solve that for me using my current hardware 🙂

1 hour ago, Reset XPDR said:

... you have helped identify that this tool may not be suitable for those that run with a frame rate cap at all, because such a cap and a tool like this that needs a tolerance band around a target FPS make their operation mutually exclusive ...

Yes, that was my point. 😉

1 hour ago, Reset XPDR said:

... this tool may not be suitable for those that run with a frame rate cap at all, because such a cap and a tool like this that needs a tolerance band around a target FPS make their operation mutually exclusive...

Ideally there would be a way to somehow identify what frame rate the system would be able to achieve without the cap and take that "potential" FPS as a reference for your tool.

For example: There is a frame rate cap at 60 FPS (by VSync or an external limiter tool). The system would be able to achieve around 70 FPS (depending on TLOD settings) if there wasn't the cap. So 70 would be the "potential" FPS. Your tool should now keep that "potential" FPS just above 60 all the time by adjusting TLOD accordingly.

 

Edited February 17, 20242 yr by RALF9636

3 hours ago, Fielder said:

On other planes I leave Neutral at 0%. Because I can trim the rudder in the cockpit instead.

Thank you, Fielder.