[SP 0-6-0]

That post about RTrainsim is mine. I am glad to see it brought up here again. I did mention it earlier but the topic was ignored.

I did manage to get in contact with the author and he said that the code is in C++ and he has no knowledge of C# or what to really do with Rtrainsim right now.

If anyone wants to take up the task of trying to work with the author and intergrate some of Rtrainsim's features that would be pretty dang slick. He even has some of his own shaders that are pretty decent.

Chris, I will get back to and hopefully more involved in that research for the guide lines for MSTS models. I've been slackin lately because of personal problems.

Robert

[James Ross]

Genma Saotome, on 07 May 2017 - 12:17 PM, said:

IMO you need three different road maps.

Do you think it's worth having them completely separate? I have tried to cover these areas somewhat with the labels on the existing roadmap, but I'd admit the balance of items is probably not right.

Genma Saotome, on 07 May 2017 - 12:17 PM, said:

Do a wide open critique of the present "world of rendering" as used by OR. What are the differences between where OR is and where OR would be if it were started anew this summer? Toss out the available features you'll never need (e.g., explosions, the physics of falling objects) and examine what's left for its utility; first pass at anything that's not eye candy but instead enhances performance, and then a different list for eye candy. Don't get hung up on tools/ platforms, etc., but instead focus on features that would serve the goal of a better simulator. Do a quick check on what's the average VRAM on GPU cards today vs. 5 years ago and what that might imply. Whatever looks right for this sim is the new target. Then what is the plan for going from where OR is to where it should be? That's your technical road map.

I'd guess this roughly maps to the "Visual", "Audio", and "Performance" labels. Seems to be a fair number of items here.

An interesting proposal for figuring it out; have you or anyone else done a thought experiment like this for OR recently? Not sure if this would work as a group thing or if we should pick someone to go away and do it alone, and compare results.

Genma Saotome, on 07 May 2017 - 12:17 PM, said:

You'll need a different road map to address content -- across the board. This should be from file design to tools.

I guess we have the "Editor" label, but nothing else focused on content. That's a clear lack. :(

Genma Saotome, on 07 May 2017 - 12:17 PM, said:

The last road map is stuff within the game loop. Most of that is already done and you've got a good idea already where improvement can be made. Deal with the other two road maps first.

"Gameplay" and "Simulation" labels. We do seem to have a reasonable amount here.

[Genma Saotome]

James, I don't think it matters all that much what form of final product you have so long as your team covers all three topics. But keeping them separate might make it easier to track progress on each.

My suggestion on rendering is intended to get you guys to pull back a bit from the what package is after .xna thinking and to look more broadly at what features that are available offer OR the most. For example, my own sense of the matter is the routes I use are typically CPU bound. Is that because all rendering goes thru one thread or because there is no texture atlas created anytime between 3d modeling work and game time? Maybe it's the .s format that slows things down. Or .ace files. I expect different solutions are available for each of those... how would you choose which one to fix first? What if you picked one that seemed right... but in fact doesn't make much of a difference to performance? TQC says let the data guide the way so maybe figuring out how to use some of those nVidia and/or AMD tools is the right first step. It might look good on a resume as well and/or a darn interesting thing to do.

Content is not simply "the editor". What do you have in your roadmap to generate anything in \tiles? What do you have to project near terrain? Distant mountain terrain? Goku's editor handles those one by one and last time I looked uses 90m resolution DEM data. DEMEX, a 15 year old utility can do hundreds of tiles per pass using 10m resolution DEM data. You need a 2d editor as well as a 3d editor (as anyone who has ever used Mosaic will tell you). Add any questions surrounding the nature of the .s file, the data structures for content (such as that suggestion I made regarding rolling stock) and perhaps wrap up with an activity editor (because the timetable product, which is really interesting in many ways, doesn't do dark territory at all and IMO doesn't do North American freight railroading as well as it should). W/o a very good means to create new content OR becomes a (msts) bug in amber.

[Goku]

Genma Saotome, on 08 May 2017 - 03:49 PM, said:

Content is not simply "the editor". What do you have in your roadmap to generate anything in \tiles? What do you have to project near terrain? Distant mountain terrain? Goku's editor handles those one by one and last time I looked uses 90m resolution DEM data. DEMEX, a 15 year old utility can do hundreds of tiles per pass using 10m resolution DEM data.

I told you many times, that TSRE can use HGT files in any resolution.

[James Ross]

Genma Saotome, on 08 May 2017 - 03:49 PM, said:

James, I don't think it matters all that much what form of final product you have so long as your team covers all three topics. But keeping them separate might make it easier to track progress on each.

Okay, I'll keep them in the Trello board for now, just using labels:

• Technical roadmap (Visual, Audio, Performance)
  
• Content roadmap (Editor, Content)
  
• Game loop roadmap (Other, Gameplay, Simulation)

Genma Saotome, on 08 May 2017 - 03:49 PM, said:

My suggestion on rendering is intended to get you guys to pull back a bit from the what package is after .xna thinking and to look more broadly at what features that are available offer OR the most. For example, my own sense of the matter is the routes I use are typically CPU bound. Is that because all rendering goes thru one thread or because there is no texture atlas created anytime between 3d modeling work and game time? Maybe it's the .s format that slows things down. Or .ace files. I expect different solutions are available for each of those... how would you choose which one to fix first? What if you picked one that seemed right... but in fact doesn't make much of a difference to performance? TQC says let the data guide the way so maybe figuring out how to use some of those nVidia and/or AMD tools is the right first step. It might look good on a resume as well and/or a darn interesting thing to do.

I believe we've had some of the NVidia tools working on OR before (there's some code specifically so their HUD works properly IIRC). I'd love to have the time to explore this area again but that simply hasn't been possible recently.

FWIW I expect the lack of large texture atlases is key to the current CPU-bound issues, although the current alpha blending solution hurts badly too. :( Definitely would appreciate someone doing investigatory work in this area!

Genma Saotome, on 08 May 2017 - 03:49 PM, said:

Content is not simply "the editor". What do you have in your roadmap to generate anything in \tiles? What do you have to project near terrain? Distant mountain terrain? Goku's editor handles those one by one and last time I looked uses 90m resolution DEM data. DEMEX, a 15 year old utility can do hundreds of tiles per pass using 10m resolution DEM data. You need a 2d editor as well as a 3d editor (as anyone who has ever used Mosaic will tell you). Add any questions surrounding the nature of the .s file, the data structures for content (such as that suggestion I made regarding rolling stock) and perhaps wrap up with an activity editor (because the timetable product, which is really interesting in many ways, doesn't do dark territory at all and IMO doesn't do North American freight railroading as well as it should). W/o a very good means to create new content OR becomes a (msts) bug in amber.

I've tried to add the big-name items to the content roadmap (using a new label "Content", to go with "Editor") but please let me know of anything that I've missed.

I've tried to put things in a relatively sensible, incremental order - but with each new file format, there is an editor. This doesn't have to be a separate application - it could simply be integrated functionality in an existing OR application.

[Genma Saotome]

You don't have a 2d editor.

I assume you have no experience w/ Mosaic; Take the contributed track viewer, add a function to display a gray scale relief map of the terrain, another to show the exposed water layers. The displayed grid can be whole tiles or individual patches. Provide a side window that displays any terrtex art -- what's in use in the route, what's on disk that you've pulled in. Select any number of patches by a mouse dragline... click on one of the textures in the side window and bang, 300 patches have anew tertex. Toggle a checkbox and select a different microtex file. Bang, that's now changed too. Allow for water textures to be applied just like terrex instead of KUJU's one water for everything. Mosaic also allowed DM tiles to be terrtexed this way. I have no recollection whatsoever as to how DM was textured with different art using KUJU tools.

With KUJU all of that was done, pretty much, one patch at a time.

Why would anyone want to do that sort of work in a 3d editor where you are limited to the few tiles you can see?

John Safford's Mosaic 2.0 beta had a UI that included toggles to display on/off procedural track, shape track, Mosaic track (whatever that was) which, if you think about it, suggests a map oriented approach to locating track and roads. No functions were included to do that... but if you check out what current tools used by Geographers you come across both track and road vector files set in the context of latitude/longitude coordinates. Even if all that was used for was to generate markers to follow in your world editor it would be a big step up. If the vector data could be projected into a route, perhaps only as an editable template from which procedural roads and tracks could be generated -- emphasis on editable -- that portion of routes could be built in a fraction of the time we know using KUJU tools.

It's not a requirement per se... many existing routes were made w/o Mosaic, none w/ GIS road and track data, but if the vision could be built it would be a HUGE reduction in the amount of time needed to create a route.

[Lindsayts]

Genma Saotome, on 08 May 2017 - 03:49 PM, said:

James, I don't think it matters all that much what form of final product you have so long as your team covers all three topics. But keeping them separate might make it easier to track progress on each.

My suggestion on rendering is intended to get you guys to pull back a bit from the what package is after .xna thinking and to look more broadly at what features that are available offer OR the most. For example, my own sense of the matter is the routes I use are typically CPU bound. Is that because all rendering goes thru one thread or because there is no texture atlas created anytime between 3d modeling work and game time? Maybe it's the .s format that slows things down. Or .ace files.

The reason for openrails being CPU bound is the vast amount of data that is required by the GPU to render a frame, is beyond a single CPU to transfer. The answer is two threads to transfer the data t the GPU, one of the simplest to implement is have one thread for shape data and a second for texture. I believe this is beyond the XNA tool kit. This has for a long period been a serious issue for modern graphics cards and why the real high end cards do not perform as good as they could.

Note: this is an issue for all programs trying to render a world in reall time.

Lindsay

[Genma Saotome]

Lindsayts, on 09 May 2017 - 11:49 PM, said:

The reason for openrails being CPU bound is the vast amount of data that is required by the GPU to render a frame, is beyond a single CPU to transfer. The answer is two threads to transfer the data t the GPU, one of the simplest to implement is have one thread for shape data and a second for texture. I believe this is beyond the XNA tool kit. This has for a long period been a serious issue for modern graphics cards and why the real high end cards do not perform as good as they could.

Note: this is an issue for all programs trying to render a world in reall time.

Lindsay

There are all sorts of ways to cut up the workload -- shapes in one thread, terrain in the other... or track and road shapes in one thread, everything else in another. Or add a third for textures. And there might be a huge variation from one route to another. But the point is people can guess all day long about what might be a solution but getting in with the right toolset and letting the data guide the answer is what I'm recommending. And part of the answer might include pre-processing existing content, stuff like porting .s files to a different format that will be read by the loader software. TQC is wide-open thinking after understanding what the data is saying, change, measure again, repeat exercise as needed.

[James Ross]

Genma Saotome, on 09 May 2017 - 05:24 PM, said:

You don't have a 2d editor.

Looks like we had a miscommunication; I have renamed the cards to better reflect what they are, and added basic descriptions to further explain the proposed items. In short: all the editors except the final "Route editor" (now called "World editor") are primarily 2D, having nothing more than previewing in 3D.

Genma Saotome, on 09 May 2017 - 05:24 PM, said:

I assume you have no experience w/ Mosaic; Take the contributed track viewer, add a function to display a gray scale relief map of the terrain, another to show the exposed water layers. The displayed grid can be whole tiles or individual patches. Provide a side window that displays any terrtex art -- what's in use in the route, what's on disk that you've pulled in. Select any number of patches by a mouse dragline... click on one of the textures in the side window and bang, 300 patches have anew tertex. Toggle a checkbox and select a different microtex file. Bang, that's now changed too. Allow for water textures to be applied just like terrex instead of KUJU's one water for everything. Mosaic also allowed DM tiles to be terrtexed this way. I have no recollection whatsoever as to how DM was textured with different art using KUJU tools.

The terrain editor (now "2D terrain editor") is intended to cover these functions.

Genma Saotome, on 09 May 2017 - 05:24 PM, said:

Why would anyone want to do that sort of work in a 3d editor where you are limited to the few tiles you can see?

Believe me, I'm expecting a lot of the tools to work only - or primarily - in 2D and for most of the initial route creation to be done in 2D. :)

Genma Saotome, on 09 May 2017 - 05:24 PM, said:

John Safford's Mosaic 2.0 beta had a UI that included toggles to display on/off procedural track, shape track, Mosaic track (whatever that was) which, if you think about it, suggests a map oriented approach to locating track and roads. No functions were included to do that... but if you check out what current tools used by Geographers you come across both track and road vector files set in the context of latitude/longitude coordinates. Even if all that was used for was to generate markers to follow in your world editor it would be a big step up. If the vector data could be projected into a route, perhaps only as an editable template from which procedural roads and tracks could be generated -- emphasis on editable -- that portion of routes could be built in a fraction of the time we know using KUJU tools.

Ah, "world editor", that's a useful phrase I think for the fully 3D editor experience.

I hope the new names and descriptions on the cards helps. Please do start new threads, or continue existing relevant threads, to discuss what features each editor should have, and whether the collection of editors makes sense (did I miss something out entirely? Are two really too similar to separate? Etc.)

And thanks again for all this input; it's very valuable having people who've actually created content, especially routes, around. :)

[cjakeman]

cjakeman, on 01 May 2017 - 11:28 AM, said:

I've created a blueprint at Launchpad.net for the combined task of recruiting and supporting new developers.

Just wanted you all to know that our first volunteer is already getting started and had picked a bug to work on under supervision.