[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?

[Genma Saotome]

Laci1959, on 30 August 2021 - 10:52 PM, said:

《Wrt simple better than complex》

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

Everything needs to be complex enough to do what needs to be done and no more.

The problem inherent in software is it is often simple to code from the programmers perspective but the fact of embedding it code usually makes it much more complex to change from the end users perspective.

In addition to that, while often there is no alternative but to choose to do things in the code care must be taken when there is also a choice to do things in the data. One should think long and hard about where the better place will be given the complexity of end user situations. IOW long term what we do may well be far more simple to address in data than it would be in code no matter how simple a code change might look at first glance because the total end user environment is almost impossible to know fully.

[cjakeman]

Having dealt with the Level Of Detail Bias, can we now look at some Experimental tab options that I passed over?





The Manual reads:




I guess this option exists because the messages about shape file errors can be overwhelming and make it difficult to see other messages.

A couple of thoughts:

• Since this is all about the log file, why not move it to the Data Logger tab?
• Are there other log messages that should have an option to Show/Suppress option?

[Genma Saotome]

IIRC this is something Voldemort added because he thought it necessary to duplicate everything that was in MSTS (specifically that the .s file is using a generic diffuse shader because the texture file is missing), even if OR was reporting the same error elsewhere.

Check the code and if it looks as stupid as what I recall, yank it.

[cjakeman]

The next control in the Experimental tab is the ETCS circular speed gauge:




The Manual has:




and this text, for me at least, immediately raises the question:

Why is this something that you can turn on and off. Why not just leave it on?

Does anyone know?

[cjakeman]

cjakeman, on 01 September 2021 - 09:50 AM, said:

The next control in the Experimental tab is the ETCS circular speed gauge:

Does anyone know?

No feedback yet, but I guess this control could be removed.

The next in the Experimental tab is a group of 3:



and the Manual has:




I've not played with these controls myself. Does anyone have any comments? Are they straightforward?