[Genma Saotome]

IMO "can be seen" or "comes into view" will explain things better than "comes into play".

[cjakeman]

 Genma Saotome, on 28 August 2021 - 11:47 AM, said:

IMO "can be seen" or "comes into view" will explain things better than "comes into play".

Good point. I'll adopt that.

[cjakeman]

As mentioned earlier, I wasn't planning to make any changes to the existing options until after OR v1.4 is released.

However, there's no reason why improvements to the Manual already agreed above cannot be included in v1.4.

I've submitted a Pull Request for changes to text for the following options. The Unstable version does not update the manual, so you won't be able to see the changes until it has been approved and merged into the Testing version:

• Dynamic shadows
• Forced red at station stops
• Level of detail bias
• Override non-electrified route line-voltage
• Shadow all shapes
• Super-elevation
• Vertical sync
• Viewing distance

Thanks for your help so far.


Once we have finished the Experimental tab, there is still the General tab and some options on the main Menu form.

[cjakeman]

Still looking more closely at the Experimental options that concern the visual aspects, what should we make of this one?




The Manual reads:




We already have the Viewing Distance option:



I'm unsure if this checkbox enables and disables the Viewing Distance option or serves to override it.

If I examine the code, the checkbox refers to Level Of Detail (LOD) and the comment in the code is:

// If set, extend the lowest LOD to the maximum viewing distance.

The code seems to ensure that an object does not disappear even though its LOD values should take it out of view as the camera is moved away.

Is this a fix for content with bad LOD values?

What does it have to do with Viewing Distance?

[James Ross]

 cjakeman, on 29 August 2021 - 11:47 AM, said:

I'm unsure if this checkbox enables and disables the Viewing Distance option or serves to override it.

It's been a long time since I touched any of the relevant code, but IIRC the problem is that every LOD - including the final, lowest-detail, one - has a maximum viewing distance for itself. So, beyond that distance, the shape disappears. And since MSTS only did up to 2km viewing distance (excluding distant mountains), most shapes include a maximum viewing distance for the last LOD of ~2km - since anything higher would not matter to MSTS.

Because Open Rails can go beyond 2km viewing distance, to make most shapes appear at all beyond 2km, you need to do one or both of the following:

• Scale up all the LOD maximum viewing distances so the lowest-detail LOD is >2km - this is what "Level of detail bias" does when you turn it up (e.g., +100% = double the maximum viewing distance)
  
• Remove the maximum viewing distance limit for the lowest-detail LOD - this is what "Extend object maximum viewing distance to horizon" does

So, in summary, the extend to horizon option keeps the LOD behaviour as written in the shape file except that the object never disappears, whereas the detail bias changes all the LOD levels (but can't extend beyond double the original distances).

I'm inclined to believe that the extend to horizon option should simply be hard-coded as on - turning it off will only affect >2km viewing distances, and effectively the same effect can be achieved by setting viewing distance back to 2km.

[cjakeman]

 James Ross, on 29 August 2021 - 12:58 PM, said:

I'm inclined to believe that the extend to horizon option should simply be hard-coded as on - turning it off will only affect >2km viewing distances, and effectively the same effect can be achieved by setting viewing distance back to 2km.

That makes a lot of sense.

So we've identified another option that has become redundant - simplify is good, complexity is the enemy :-)

[Laci1959]

Quote

Remove the maximum viewing distance limit for the lowest-detail LOD - this is what "Extend object maximum viewing distance to horizon" does

Hello.

This used to try to conserve computer memory in a similar way to the Word object density discussed earlier.

There are objects that can't be seen 2000 meters because they are that size. Just think of a dog. Does anyone see the middle of the prairie without binoculars so far away from it?

It seems a little irrelevant to me. Maybe there is a solution when the object builder adjusts the actual distance according to the size of the object? I know it would involve a lot of work. The Great Plain ( Alföld 7.2 ) is working with route 5000 objects, and new ones are constantly being added as the track grows.

Sincerely, Laci 1958

[Weter]

...Compared to display pixel's size: if smaller, than pixel, when being seen from given distance-then not displayed.

[Genma Saotome]

As long as there is some means to see things further away that 2km I'm happy.

Long term I do believe it would be better to have MaxLODDistance(nnn) in the .sd file because one size fits all solution will try and display grass and bushes much further away than the GPU thinks is reasonable which means we paid for unnecessary draw calls and bought lower fps.

[Laci1959]

 Genma Saotome, on 30 August 2021 - 09:16 PM, said:

Long term I do believe it would be better to have MaxLODDistance(nnn) in the .sd file because one size fits all solution will try and display grass and bushes much further away than the GPU thinks is reasonable which means we paid for unnecessary draw calls and bought lower fps.

This is a very good solution and simpler than I thought. Thanks.

Quote

simplify is good, complexity is the enemy

This is usually true, but should it apply to everything?