[jared2982]

Good morning all,

A recent thread reminded me of something I have hoped for for some time when it comes to the way OR handles global shapes. There have been many times where I have used modified (well basically rebuilt) track shapes in routes for one reason or another. Examples would be removing or adding switch stands and changing frogs design etc... What I propose is to have OR check a local directory in the route folder or even the shapes folder for files then if it is not found OR could default to the global folder for the other files. A good example come from the route I am currently working on. It has a whole section of the route using dual gauge track. The original dual gauge track turnouts had ground throw switch stands modeled into the track shape. Using the original geometry from the Tsection.dat entries and the .s file it's self I created 4 new turnouts without the switch stands and then was able to add my own stands as signal item in RE. A much better look since the originals were too close to the track and were often hit by passing trains. As it is the route will require users to replace the original .s files in global with my new .s file or things just won't look right. This will also effect other routes using the original shapes and may cause some users to have to switch back and forth between the .s files. Of course a simple batch file can handle the swap but it would be much easier is it was never needed in the first place. Just some thoughts.

[Genma Saotome]

I recall being told there is a distance limit applied to the run of spawned cars & trucks. If so it might be useful to expand that to a vastly greater distance or perhaps unlimited.



p.s. Another thought is to allow multiple paths at street intersections in the same way that track turnouts do -- a primary and n secondaries, Adding a n% of approaching vehicles take this secondary would probably be sufficient for variety.

[Sid P.]

In earlier releases of ORTS, it was possible to create an "openrails" folder in a trainset folder, and put a modified version of the .eng file of that trainset into it. This modified .eng file was read by ORTS instead of the standard (MSTS) .eng file, and allowed the testing of different .eng files, cab view and sound files under ORTS.

It looks to me, unless I am doing something wrong, that this option has been removed (at least in X1975).

This feature was and would continue to be useful for observing and fixing differences between the behavior of MSTS and ORTS, since both can be run simultaneously.

[Genma Saotome]

I don't recall now If I put this on another wish list but the issue is before me again...

Instead of rendering terrain w/ 64 calls per tile (1 per patch) -- what I think of as rendering in patch order (e.g., one a time from #1 to #64) -- change it around and render in texture order (e.g., A.ace thru Z.ace) with as many patches as can fit sent with each draw call. 1 Texture / tile = 1 call, 2 = 2, etc. etc. I suspect there'd be a big reduction in draw calls.

Why? Well I've got 2 routes that include large bodies of water... many tiles where all 64 patches are underwater. As far as I'm concerned, 1 quad per tile would work perfectly well but since there are 64 patches it takes 64 drawcalls... for 1 texture. Getting rid of 63 drawcalls over a dozen or more tiles would be, IMO a big plus.

Which leads to a slightly tangential topic: Terrain Bias. Terrain Bias determines the resolution of the terrain in each patch; MSTS defaults to a value of 1 which, AFAIK, means use every other vertex (16m quads). A value of zero renders at 8m quads -- the best one can get). I dunno but I suppose a value of 2 might render at 32m quads, etc. etc. When Open Rails was originally released it ignored Terrain Bias and did everything as if the bias value was 0. AFAIK it's still the same today.

But WRT to rendering terrain by texture might there be too much data to pass in one call for each texture? If so, would enabling Terrain Bias solve that?

[James Ross]

Genma Saotome, on 06 February 2014 - 08:50 PM, said:

Instead of rendering terrain w/ 64 calls per tile (1 per patch) -- what I think of as rendering in patch order (e.g., one a time from #1 to #64) -- change it around and render in texture order (e.g., A.ace thru Z.ace) with as many patches as can fit sent with each draw call. 1 Texture / tile = 1 call, 2 = 2, etc. etc. I suspect there'd be a big reduction in draw calls.

Have you looked at the performance of OR with object detail level set to 0? IME, its the scenery, rather than terrain, that causes the huge excess of draw calls. (I am scheming things to help this.) While every draw call counts, so do setting up shaders and other such things in the graphics pipeline. Merging draw calls is also very hard - you have to merge index, vertex, texture data - and you get left with bigger buffers that can't be shared so easily (the index buffer for a terrain patch is shared between every patch without a hole in it).

Genma Saotome, on 06 February 2014 - 08:50 PM, said:

But WRT to rendering terrain by texture might there be too much data to pass in one call for each texture? If so, would enabling Terrain Bias solve that?

I'm not sure what you mean by 'too much data'. Almost nothing is passed during draws - all of the data goes through ahead of time in the texture, vertex and index buffers (which are absolutely not passed each time).

In the current design, terrain bias would actually make things worse, as we would not be as easily able to share things like the index buffer (see above). It would reduce the number of vertices being processed but I don't believe that to currently be any sort of bottleneck.

[Genma Saotome]

Please excuse my ignorance of the technical details... what I was trying to do is express a hope there is some way to cut the drawcalls for rendering terrain. 64 patches per tile, lots of tiles once the view distance goes out many km's... maybe a third of the total with view... the draw call count it can add up into the hundreds if not low 4 digits. I have a bunch of underwater tiles in both my routes -- they're all flattened out too so the vertices are all co-planar. Just kills me everytime I think of the drawcalls being wasted when the camera looks that way.

WRT what causes the most, I do think it would be worthwhile to actually collect data from routes. MY Goose Island route can generate 10,000-16,000 primitives in some views and you'd think it was all those buildings but no, it's the track. Look at a different route and it might be trees. There's always something. And so the solution may need a different strategy for rendering when textures are shared across many instances of shapes -- the same tree planted many times, the same building "planted" many times has been dealt with in other software... but I think with track, roads, and the way I make models there is another situation of many different shapes using common textures. A hard problem to solve no doubt.

[Matej Pacha]

I have a simple wish to add:
Sometimes it's necessary to have many MSTS (with route and global) folders, what can be easily linked to ORTS using "Installation profiles" - Add button in the menu. But what about trains? Sometimes I use the same trainset for all the routes, so I have to copy or move all the data to the MSTS folder in use. It would be great to have one Trainset folder for all routes. Or, just the option to consider one Trainset folder in more than one "Installation profile".

[gpz]

I can recommend for you too using links, built into windows filesystem. See: http://schinagl.priv...nkshellext.html

[charland]

Hi OR Guys,

This may have already been suggested but...

The ability to have more then one car spawn group. You don't usually see tractor trailers roaming around residential areas, and you don't usually see city buses out on the highway, unless you're restricted to the one car spawn system in MSTS. Might be nice to be able to have several different cars spawn lists you could make up and use in different situations.

Paul :-)

[jan111]

My only wish for the moment is to have the possibility to configure RailDriver (disabling handles) like the Cabmaker in MSTS.