[ebnertra000]

I would rather this feature be made not only route-specific, but also curve-specific, to be specified by the route builder. I can't count how many times I've had mainline curves refuse to superelevate, while curves on industrial side-tracks will every time. Apart from the environments, it's probably one of the things that drive me mad the most

[Weter]

Quote

not only route-specific, but also curve-specific

Exatcly, what is needed.
I have noticed, that berms are disappearing under superelevated tracks, as this sections are being substituted by dynamic tracks, as I was adviced.

[steamer_ctn]

R H Steele, on 22 August 2021 - 11:29 AM, said:

I wish many of these options --- and super elevation is one --- could be saved for certain routes...made route specific if you will....it really comes down to a checklist of options to remember to set for certain routes, forget something, and restart the activity or timetable. Apologies, I know this is not on point...but thought I'd mention it again.

There are currently two aspects to consider about superelevation in OR. There is a visual (how the train looks when it is in the curve) and a physics element (how the train performs when in the curve). Currently these two elements are "disconnected".

The parameters in the options menu set the visual superelevation, whilst the physics element is set by default parameters, or can be set within a route by parameters added to the TRK file. The assumption with the physics parameters settings is that it is a "global" setting reflecting the fact that the track designers will design the same radius curves to the same superelevation standards. If it is desired to have the same radius curves with different superelevation values then each individual curve would need to be specified in the track database (which is not possible at the moment).

The advantage of the TRK file approach is that it can be added to legacy routes using a INC file (this could be a standard default file that any user could include on any route). Also I don't think that the visual approach amount of superelevation varies with different curve radius as only one value of superelevation is able to be entered via the options menu (not 100% sure about this without rechecking the code).

It would also be good to combine the two different input setting approaches together so that the visual and physics element use the same values.

[Genma Saotome]

Peter, is the .trk plus .inc feature documented in the manual?

Long term it seems the right solution would be implemented via the world editor... some similar to the existing set of contiguous track sets currently in use with the necessary data to produce both the correct look and behavior. It might even work with section track shapes.

[steamer_ctn]

Genma Saotome, on 22 August 2021 - 03:52 PM, said:

Peter, is the .trk plus .inc feature documented in the manual?

There is a long section of information generally on superelevation .

The TRK file is described in section 15.15.

Genma Saotome, on 22 August 2021 - 03:52 PM, said:

Long term it seems the right solution would be implemented via the world editor... some similar to the existing set of contiguous track sets currently in use with the necessary data to produce both the correct look and behavior. It might even work with section track shapes.

I agree, as this would allow allow curves with/without superelevation to exist in the same route, rather then a generic approach. For example, curves in yards typically would not have superelevation, and similarly branches off main lines may not have superelevation.

However I suspect that this is some way off as it would require changes to both OR and the track editing tool.

[cjakeman]

The next Experimental option came, I think, from James.




The Manual reads:

6.10.2 Automatically tune settings to keep performance level
When this option is selected OR attempts to maintain the selected Target frame rate FPS ( Frames per
second). To do this it decreases or increases the viewing distance of the standard terrain. If the option is
selected, also select the desired FPS in the Target frame rate window.

It's quite a neat algorithm. According to the code, the Viewing Distance is automatically adjusted between 500 and 10,000 metres to achieve the frame rate target.

If the Vertical Sync setting is active, then that mechanism is already trying to achieve a frame rate target. In this case the algorithm adjusts the Viewing Distance by instead monitoring the CPU load to ensure the Vertical Sync can achieve its target.

At the same time, the algorithm also adjusts the Level of Detail Bias - a control that's also on the Experimental tab:






I've not heard of any comments about this Automatic Tuner. Does anyone use it?

Since this does the job automatically, do we still need the control Viewing Distance?

[Weter]

I guess, that decreases GPU load by the price of excessive loading of CPU by extra computing of that algorythms themself (not a simulation process actually)
Am I right?

[pschlik]

It's been a long time since I used automatic tuning. Last I remember it had a habit of increasing draw distance a bit too far and causing FPS to fall far below the 60 fps target setting. Left a bad taste-but perhaps I could give it a try again.

[roeter]

Quote

Since this does the job automatically, do we still need the control Viewing Distance?

Yes, because not everybody sees 60 fps as the holy grail.
I run a coastal route and like the far views so I always set viewing distance to 10.000 m, regardless of what it does to the fps.
Besides, this route has a hefty timetable and it's the amount of active trains which affect the fps more than the number of objects, so this tuning would have little use, it could reduce the viewing distance to 0 and still not reach 60 fps.

Regards,
Rob Roeterdink

[cjakeman]

roeter, on 24 August 2021 - 12:23 AM, said:

Yes, because not everybody sees 60 fps as the holy grail.

The target frame rate is a user setting. Doesn't have to be 60 fps.

Anyway, several people have already advised that all visual controls should remain available to the user, so I had better not propose dropping any of them.