[Lindsayts]

I will say I am very pleased with the discusion on this thread, nearly all the points I would like to see discusssed have been brought up in a positive fashion, Openrails IS a great rail sim, it would be truely great to see it up at the top of the tree where it really belongs.

Lindsay

[James Ross]

Lindsayts, on 10 December 2016 - 01:24 PM, said:

3 There is a perception in the outside world that Openrails is in complete an example is in signalling. In recent weeks I have seen at least 3 threads on other forums saying OR has been given away because the signalling did not work correctly (British and German). Yet the signalling in MSTS/OR is scriptable and therefore subject in some to user way control. BUT and I repeat BUT there aappears to be no user documentation or particuarly tutorials on how to fix this.

In most cases, I don't want people editing their signalling - it should just work. We are fixing issues with signalling compatibility, but it's one of the more complex areas of MSTS data and our script engine is... poor.

Just to be clear, if there was a tutorial on how to fix specific things in MSTS signal scripts so they worked in OR, we should have fixed OR instead! IIRC there is actually some information in the manual about known issues, nevertheless.

Lindsayts, on 10 December 2016 - 01:24 PM, said:

4: The apparent lack of a coordinated set tools for OR, a route editor, a consist editor, a activities editor, part of this now is a Documentation issue.

I hope that TSRE5 is helping to alleviate some of the immediate problems, but it is high time we did something ourselves. Chris Jakeman, André and myself are currently working on a high-level roadmap/vision and I am planning to write up some concrete proposals for beginning OR editor work.

And now that the manual is effectively plain text (at the source level) I hope more people would be willing to contribute.

Kazareh, on 10 December 2016 - 04:17 PM, said:

One thing I want to bring up, is Optimization. Which ORTS seems to have little to none of. I right now am down to a horrid video card, a Geforce 7300 LE. My HD 6950 died, so.

There are many aspects to optimisation and Open Rails has had many applied to it; back in 2010-2012, I spent weeks of time improving the graphics performance and loading performance (along with a few others). And then in 2013 we had bug 1152633 where Peter Gulyas provided a fix which split alpha surfaces into two phases of rendering (fixing the visual effect at the cost of doubling the draw calls for such surfaces) - this is a great example of the trade-off that has to be made between correct graphics and performance.

And then, like Goku has said, there is the MSTS content itself, which is almost universally not optimised anywhere near the levels of commercial games/AAA titles/etc.. This is likely a tooling problem more than anything, so I'm not blaming the content creators, but the results are the same: shapes that each use multiple textures and are unique to that model, then having multiple unique models... it quickly adds up. Just look at the stats in the HUD's DEBUGGING page:

• 542 primitives, 143 textures, 183 materials, 131 shapes, 7 tiles - a typical MSTS original route, Hisatsu Line.
  
• 4624 primitives, 1053 textures, 1242 materials, 656 shapes, 9 tiles - a recent, highly-detailed route: Mid-East Plus.

Mid-East Plus is doing better on primitives-per-material (3.72 vs 2.96, higher is better) but it's not much, and it's doing worse on textures-per-shape (1.61 vs 1.09, lower is better) and primitives-per-shape (7.05 vs 4.14, lower is better).

Goku, on 10 December 2016 - 10:31 PM, said:

Fast game engine requires not only code optimization but most important: content optimization.

Exactly! I have toyed with the idea of pre-merging textures into automatic texture atlases (say for all/most shapes on each terrain patch - or maybe even tile) but it's a huge amount of work. :(

Goku, on 11 December 2016 - 10:33 AM, said:

Example how deferred rendering looks like: http://www.adriancou...graphics-study/
You can see how transparend parts are rendered at the end of rendering.

Fascinating read, thanks.

[Genma Saotome]

FWIW, another data point:

• 15887 primitives, 1326 textures, 1752 materials, 1999 shapes, 274 tiles

• fps: 21
  
• primitives-per-material 9.06
  
• textures-per-shape 1.5
  
• primitives-per-shape 7.94

this is with instancing on.

I'm very suspicious about these numbers, especially the number of shapes, which, by knowing the tiles should be over 8000. I opened the same activity w/ instancing turned off. All the numbers are the same, including fps.

Something is not right.

Could it be the method of obtaining these sums does not account for shapes out on in the extended view distance tiles?

[James Ross]

Genma Saotome, on 17 January 2017 - 03:09 PM, said:

FWIW, another data point:

• 15887 primitives, 1326 textures, 1752 materials, 1999 shapes, 274 tiles

• fps: 21
  
• primitives-per-material 9.06
  
• textures-per-shape 1.5
  
• primitives-per-shape 7.94

this is with instancing on.

I'm very suspicious about these numbers, especially the number of shapes, which, by knowing the tiles should be over 8000. I opened the same activity w/ instancing turned off. All the numbers are the same, including fps.

Something is not right.

Could it be the method of obtaining these sums does not account for shapes out on in the extended view distance tiles?

Sorry, I didn't really explain the data; the primitives value is the number currently being drawn (so anything out-of-shot won't count), while all the other numbers are the current number of unique items loaded. So you have 1999 unique shapes loaded. There isn't a count of shape instances, unfortunately.

I've just realised this invalidates the primitives-per-shape numbers, but the other two are still valid (you want to be drawing lots of primitives with few materials, and you want fewer unique textures per unique shape).

[Genma Saotome]

1326 textures for 1999 unique shapes. Obviously lots of shapes are using the same texture -- no surprise really, it's track... and in my case the berms underneath them and probably roads too.

Content creators, by and large, do not create new track shapes. I suspect if you could isolate track, road, and berm shapes and textures from the above numbers the resulting ratio's would be wildly different. Only then will you gain some insight into what content creators are doing with their models.

You mentioned dynamically creating texture atlases... I suspect the results will be mixed. For something like roads and tracks (not xtracks) it would be a real boon as one texture atlas would serve for so many unique shapes. The flip side might be a big hit on VRAM use when there are lot sof models sharing texture files... but few to none sharing the same complete set. You'd reduce the draw calls but pay a big price in consumed VRAM.



continued after a long interruption...

While I think the idea of texture atlas' has merit may I suggest you allow the content creator to indicate somehow, perhaps via the .sd file, which shapes should be "atlased". I know I'd make a point of designating most cars and locomotives as they're probably the worst offenders, then my scalrail track... roads... and berms right away. As for the rest, I have my doubts.

[SP 0-6-0]

Lindsay asked for thoughts on Openrails. I can't help but to repost what a fellow member of TS.com had to say in response to a question I had asked about ORTS and the feature of TS a while back.

If you're referring to the ORTS-as-the-future situation, the fact that ORTS is nowhere near being a "finished" simulator, fails to run lots of different kinds of MSTS content correctly, i.e. headlights in the railbed, scenery-trees between the rails, brakes and adhesion all over the place, etc., surely contributes to the continued popularity and interest in MSTS. Combine that with the untoward habit of ORTS fans to promote it and talk about it as if it is already perfect, well, that's just discouraging for those of us who want it to be more compatible.

The Elvas Tower closed/members-only group is another black mark against ORTS, discouraging and, yes, elitist. ORTS is impressive for what it can do but, in my opinion, serves only a limited segment of the hobby.

"While I realize why ET operates the way it does, There is still quite a number of folks who do not understand why this site is operated the way it is? I think maybe a decent explination put up on the most popular sites might be in the best for ET until the problems are resolved."

"Second thought, ORTS advancements do not generally make the headlines on some of the popular sites as there is not much in the way of advertizing the latest happenings. I myself informed some of the other boards about the transfer tables being enabled. ORTS does need more advertising of it's advances in programming and features."

Then there's the group who wants ORTS to leave MSTS behind and become something entirely different, backward compatibility be damned. Frankly, I'm surprised how far ORTS has developed, but I know if I use it I will have to spend as much time dickering with config files and content adjustments/fixes than running the simulator, at least starting out. Some people find that fun. I don't, so I don't use ORTS as much as I did MSTS. For these reasons, it's a battlefield, or maybe more like a passive blockade or embargo.

I would like to hear back from the ORTS management about the incomplete compatibility issues with MSTS that still exist?

Robert

[R H Steele]

SP 0-6-0, on 17 January 2017 - 07:02 PM, said:

Then there's the group who wants ORTS to leave MSTS behind and become something entirely different, backward compatibility be damned. Frankly, I'm surprised how far ORTS has developed, but I know if I use it I will have to spend as much time dickering with config files and content adjustments/fixes than running the simulator, at least starting out. Some people find that fun. I don't, so I don't use ORTS as much as I did MSTS. For these reasons, it's a battlefield, or maybe more like a passive blockade or embargo. Robert

Robert, you should read the whole mission statement on the OR website. Backward Compatibility with MSTS is part of the stated mission. Also part of the mission is the future, which does do depend on compatibility with MSTS. Actually, the mission statement on the web site is worded very fairly to both OR and MSTS. Also, from my perspective the OR developers have been very conscientious and fair when dealing with problems of MSTS compatibility. I'm sure there are some complaints, but that's normal in any goup. Someday the backward compatibility with MSTS will be finalized. Folks, with more experience than myself will determine when that happens, but my honest feeling is the sooner the better.

When it does happen, there is no reason any disgruntled MSTS users who thought the task was unfinished could begin an OR branch of their own, if they possessed the coding skills and the patience to perform the work.
Anyone can keep using MSTS...some people are probably still playing...hmmm,, remember Bertie the Brain, Nimrod, and Pong....and loving it.

SP 0-6-0, on 17 January 2017 - 07:02 PM, said:

...but I know if I use it I will have to spend as much time dickering with config files and content adjustments/fixes than running the simulator, at least starting out. Some people find that fun. I don't, so I don't use ORTS as much as I did MSTS...Robert

That's like saying I became a model railroader but I refuse to glue, paint, cut wood, work in my basement, etc, etc, etc, ,,,, that's a little http://www.elvastower.com/forums/public/style_emoticons/default/crazy.gif --- not to mention the fact..That is what people have been doing with MSTS for 15/16 years, egads!

[SP 0-6-0]

R.H Steele, I agree with you but am also just passing on some of the thoughts and feelings of others for critiquing. All while trying to Beta test cars for Geatan.

Robert

[ftldave]

https://www.elvastower.com/forums/public/style_images/et_dark/snapback.png' alt='View Post' />R H Steele, on 17 January 2017 - 08:20 PM, said:

That's like saying I became a model railroader but I refuse to glue, paint, cut wood, work in my basement, etc, etc, etc, ,,,, that's a little That is what people have been doing with MSTS for 15/16 years, egads!

As the author of many of the comments reposted by Robert, I was speaking about the proportion of content editing involved with Open Rails, compared to MSTS. When MSTS was my primary trainsim, I bet my ratio of time spent running trains to editing train content was near 85%-to-15%. With OR, it's closer to 50%-50%. In that regard, current-release OR is clearly a trainsim for developers, and not for the general trainsim enthusiast.

A wise man once made this comment, actually about the need for user-friendly software: "You shouldn't have to know how to rebuild your car's engine in order to just drive around the block." I agree. Like so many open source software projects, including Linux for the desktop, the focus steers toward engineering excellence, especially new features, and not much toward ease-of-use.

[vince]

ftldave, on 22 January 2017 - 04:47 PM, said:

As the author of many of the comments reposted by Robert, I was speaking about the proportion of content editing involved with Open Rails, compared to MSTS. When MSTS was my primary trainsim, I bet my ratio of time spent running trains to editing train content was near 85%-to-15%. With OR, it's closer to 50%-50%. In that regard, current-release OR is clearly a trainsim for developers, and not for the general trainsim enthusiast. ......................snip........... "You shouldn't have to know how to rebuild your car's engine in order to just drive around the block."

But before you drive that car around the block you'd better know what that red light on the dashboard means, eh? http://www.elvastower.com/forums/public/style_emoticons/default/pleasantry.gif
And what was the ratio when you first started using MSTS?
You remember right? Early on where none of the physics worked right and every time you drove west to Cutbank you either derailed or busted a coupler!
How long did it take you to learn the Activity Editor or fall prey to the horrors of the Route Editor? http://www.elvastower.com/forums/public/style_emoticons/default/spiteful.gif

You can help with OR development by using and posting your questions.
In my opinion MSTS was much worse at the beginning. A users nightmare indeed.

regards,
vince