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

[Genma Saotome]

Matej Pacha, on 07 February 2014 - 06:05 AM, said:

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".

Matej, I've thought about that problem for a long time and I think I now have a suggestion that would help. You know how Libraries make it possible to logically insert many directory trees (each of which "lives" on different branches of the tree) into a library making it look like they're all "living" there? And how, in the consist file, on the last value on each WaagonData line is the directory where the .wag is found?

Well if the construction of the consist path (in consist.cs) could accept multiple directories concatenated into one value when it goes for that directory name then people could do this:

End users set up new directories that organize their roster they way they like. Could be things like "Locomotives_New_1939-1954" and "Locomotives_New_1954-1974" and so on. Put their .wags and .engs into those new directories. The way you do that doesn't have to be the way I do it. Then junction those new directories into how ever many different \trainset folders they want. The OR code comes along to construct the Wagondata path and it finds "Locomotives_New_1939-1954\3dt_Southern Pacific F7" and because of the junction, it can find the right .eng file.

It's conceptually just like the MS Library concept.

You could name one of those new directories "Use Everywhere" and junction it into all \trainset folders. Whatever .wag and .eng directories you put in there would then be available, well, everywhere. :wallbash:

[Gman347]

First, I just downloaded and ran one of the latest experimental versions of OR. You guys are all doing a great job and we owe you a very big thank you. :) :good: :) :sign_thanks: Makes me think: "So much is owed by so many to so few!"

Now, what I was thinking about. (If this has been discussed before then I apologize for not knowing and bringing it up again.):

There was another thread started here a couple of days ago about a track viewer. Has any thought ever been given to having a real time track view option within the sim to allow real time viewing of where you are and where you are going? I have tried both Railworks and Trainz and as I recall they both have this feature with the ability to zoom in and out which I think is very nice. When one installs a new route into TS it takes quite a while to become familiar with the route and you can't really enjoy activities until you gain that familiarity (IMHO). Having the ability to look at a map while running would be nice. In addition to showing you your position, ideally it would also show you where the rest of the traffic is on the route.

If the goal of OR is truly prototypical operation of trains with realistic controls and physics then I guess this feature doesn't fit in but in reality I believe the latter could enhance one's enjoyment of the former.

Just Wonderin'.

Best,

Paul :D

[markus_GE]

Paul, what you´re suggesting is already there: Start ORTS in windowed mode, with the "Dispatcher Window" enabled in the options. Then press Ctrl + 9 and you should get exactly what you asked for :)

Cheers, Markus

[Gman347]

Well, I feel even dumber than if someone told me this had already been brought up!!:rotfl: Thanks for pointing that out Markus.

I didn't realize that OR worked that way. Can I claim that I missed it in the manual because it is discussed in the multiplayer section that I didn't think I needed to read? Probably not! RTFM - the whole thing!

Now, I am going to ask about one more thing that I hope is not too stupid a question. When I run the program in windowed mode two things happen that I wonder about. The primary window is stuck up in the upper left hand corner of my display and I can't move it. Also, when I press the dispatcher view does not pop up. Maybe it is under the primary display. But I need to make it visible by clicking on it the taskbar. Is that normal?

Sorry if I went somewhat off topic.:pardon:

Thanks,

Paul :lol2:

[copperpen]

Yes. The dispatcher window starts minimised. Not sure though as to why your main game window sticks in the upper left. Mine is movable like any other window.