Automatic merge of T1.5.1-866-gbae4730e2 and 16 pull requests

- Pull request #570 at 3539862: Experimental glTF 2.0 support with PBR lighting
- Pull request #839 at d00beb9: First phase of https://blueprints.launchpad.net/or/+spec/additional-cruise-control-parameters
- Pull request #876 at f92de76: docs: add source for documents previously on website to source Documentation folder
- Pull request #882 at 9c456aa: Blueprint/train car operations UI window
- Pull request #885 at 8f94333: feat: Add notifications to Menu
- Pull request #886 at 6c0785b: Scene viewer extension to TrackViewer
- Pull request #892 at 1f5ba4c: Signal Function OPP_SIG_ID_TRAINPATH
- Pull request #896 at 5866028: First implementation of https://blueprints.launchpad.net/or/+spec/specific-sounds-for-ai-trains
- Pull request #897 at 42f1dd9: feat: Improved system information collection
- Pull request #903 at 0d6d045: Downloading route content (Github, zip)
- Pull request #907 at 9b0b04f: Bug fix for https://bugs.launchpad.net/or/+bug/2047300 Dynamic tracks disappear after long tunnel
- Pull request #908 at ad3362c: feat: supports switching adhesion precisions
- Pull request #911 at 6834af0: docs: Add refactoring as a special type of PR
- Pull request #912 at 659396e: New Triple Valve Features Vol. 2
- Pull request #914 at 5e3fe31: Adjustments to Duplex steam
- Pull request #915 at 6d911d7: Correct calculation error with curve friction

Author: openrails-bot

Source/Documentation/Manual/physics.rst

@@ -271,12 +271,17 @@ wheel adhesion. The first model is based upon an algorithm by Pacha, whilst the
 uses an algorithm developed by Polach. The Polach algorithm provides 
 a more accurate outcome and facilitates the future inclusion of track conditions. 
 However due to the number of algorithm steps required to calculate the wheel adhesion 
-value, it is more CPU load intensive then the Pacha one. This can produce low 
-frame rates for the screen display in machines with low performance specifications. 
+value, it is more CPU load-intensive then the Pacha one. On low performance PCs, this would lower the 
+frame rate for the screen display to an unacceptable degree. 
 
-Hence OR automatically senses the CPU load, and switches to the Pacha algorithm at 
-high loads and to the Polach algorithm under lower CPU loads. In this way OR attempts 
-to support the operation of lower specification computers. When OR is using the 
+To avoid this, OR senses the frame rate and switches from the Polach algorithm 
+to the Pacha one as follows.
+If the frame rate falls below 30 fps, then a switch is made to Pacha until the frame rate
+recovers to more than 40 fps. If a switch to Pacha happens more than once in a 5 minute interval
+then it will persist for the rest of the session.
+
+In this way OR provides a more accurate algorithm whilst retaining 
+the original one for lower specification computers. When OR is using the 
 Pacha algorithm, the "Wheel Adh (Max)" values will both read 99%, whereas when the 
 Polach algorithm is being used these values will be around the expected values of 30-55%.
 
@@ -288,6 +293,7 @@ The heart of the adhesion algorithm is the slip characteristics (pictured below)
    :align: center
    :scale: 70%
 
+
 The *wheel creep* describes the stable area of the characteristics and is
 used in the most of the operation time. When the tractive force reaches
 the actual maximum of the slip characteristics, force transition falls