[longiron]

As a route builder using both Goku and native MSTS tools, I fully appreciate the desire for accuracy. I also understand the tradeoffs that any simulation introduces attempting to mimic the real world. These range from the inability of the terrain grid to represent real world landscapes (especially mountainous terrain) to the inability to accurately represent track work (lack of curved turnouts in Scalerail); to the inability to lay track where you desire because of the application limitations (cannot lay track across multi-tile boundary).

All I can hope for is that the USER EXPERIENCE accurately reflects the route that I'm building - not that it's accurate to less than 1 meter.

[Garry]

I wonder what would be achieved by changing the mapping system used by TSRE5 and OR. This change would probably mean that any route made using MSTS Route Editor, and also those currently being made using TSRE5, would no longer run.
So we would be left with the only simulator for which you could write and run activities would be MSTS.

The wait for new routes using the new mapping system would be long, I have been working at my route for over a year, 16km of track but not all scenery done, and 15 minutes by train. Would I start it again with a better more accurate mapping system. No.

So lets be thankful for what we have got. Open Rails, a simulator that is much better than MSTS, that is progressing and developing. TSRE5, a route editor that makes it possible to create a route something like the original, and is so much easier to use for most things, than the old MSTS route editor that crashed and messed up the track database at every opportunity.

Lets say thanks to those who have created OR and TSRE5 and go on from here.

Garry

[Genma Saotome]

railguy, on 10 September 2017 - 07:20 AM, said:

accuracy required increases. So, the debate about the accuracy of the OR geographic "model" should not be a foggy debate about opinions of accuracy, but rather about what level of accuracy is acceptable for purposes of the sim.

Fair enough... let's discuss this:

IMO there is a big difference between accurate and perfect. I rather doubt anybody is seriously wanting perfect in OR. Accurate, OTOH, is ill defined, which is to say each route builder, each end users fills in the blank definition themselves. For myself, as a route builder, "Accurate" means I can choose when and where I push the product in the direction of perfect. In practice that means the software either fixes some very crude problems left over from KUJU and allows me a range of choices in what reference information I can use (there will always be variation within and between national sources of data). IOW, for the most part, ONE answer isn't the answer. For example:

• Terrain is projected into tiles using the least distorted method that is mathematically practical. Or rephrase... no more Goode-Homosoline when you start building a route. If there are several types of projection avail;able where some work better than others in different places inteh world, then a choice of several methods to project DEM data.
  
• Terrain projection will accept multiple levels of resolution.
  
• Terrain projection will accept multiple image formats. This may necessitate use of GIS software for conversions to acceptable formats.
  
• Editor imports and applies images to terrain, either as textures for the end product or as temporary work aids. Images can be from Google Maps or national geographic sources -- the metadata for application must be lat & lon.
  
• Editor must be able to repeatedly "halve" terrain resolution on tile subsets. Mesh at edges mapped between resolutions. Editor must record for OR which data file to display for each part of the tile. IOW, if the base grid is 8m the editor should be able to change that mathematically to 4m grid on a subset of a tile and do so repeatedly, going from 8 to 4 to 3 to 1m grid as desired by the route builder.
  
• Edges between DM and near terrain and mathematically resolved to avoid white gaps.
  
• Route builder can move terrain to 3dmodeling and back again as a shape file (there is an experimental tool for this now).
  
• The appearance of water can vary from one body of water to another as well as within a single body of water.
  
• The altitude of water is just another editable terrain mesh, visible only when the ground mesh is below the the water mesh.
  
• The altitude of snow on the ground is just another editable terrain mesh, visible only when the ground mesh is below the the snow mesh.
  (*)Editor can move any object n meters in d direction using values entered by the user.

There are probably a few more but I'll stop there.

From my perspective the route builder chooses the level of accuracy he builds into his route... high, low, somewhere in between. EVERYTHING else, from paths, activities, the entire perception the end user has, is built upon that foundation. How far towards perfect might be known only to the route builder... but let's not overlook this fact: HE PUT IN THE TIME. HE BUILT IT FOR HIS OWN SATISFACTION. My perception of how OR has played out over the years is these facts have never been appreciated and as a result whatever routes are still being built can be no more accurate than a KUJU route... which is to say terrible skewed. Bogus, really.

Last comment... having been part of the charter team for the OR project I'll add that at that time there were discussions about accuracy and the consensus of opinion was the goal was to push the envelope whenever possible. No consideration was to be given for old, obsolete hardware and operating systems, no consideration was to be given for simply replicating KUJU's solution. The ONLY backward looking aspect was to carry old KUJU content forward because it would give end users something to do with their new game... something that was not done when Railworks issued their game.

Put another way, AFAIR there was never any intent to build a replacement for KUJU's AE and RE. There would be new file definitions and new tools to work with those file definitions and those tools would be working with modern reference data. What we have today is tools still working within a 2001 design. Accurate? Hardly.

[SP 0-6-0]

He/She does have alot of control over the quality of the route being made. But, The issue still is the basic discrepancy between MSTS RE and Goku's Tool both of which are supposed to be based on the same projection system. The issue has and still is the problem of a coding issue in Goku's tool that still needs to be rechecked for arithmetic errors and coding.

Robert

[Genma Saotome]

SP 0-6-0, on 11 September 2017 - 09:38 AM, said:

He/She does have alot of control over the quality of the route being made. But, The issue still is the basic discrepancy between MSTS RE and Goku's Tool both of which are supposed to be based on the same projection system. The issue has and still is the problem of a coding issue in Goku's tool that still needs to be rechecked for arithmetic errors and coding.

Robert

Robert, I edited my post while you were writing yours... please review the last two paragraphs.

As for the problem you mention, AFAIK Goku decided on his own to do everything he has done. His design phase was made wholly independently of anything and everything the OR team has talked about and/or has done. It's a LOT of work and it is useful... but at it's core it is still just a replacement for KUJU's RE. IMO it is not what an OR editor could be.

[James Ross]

Genma Saotome, on 11 September 2017 - 09:29 AM, said:

Put another way, AFAIR there was never any intent to build a replacement for KUJU's AE and RE. There would be new file definitions and new tools to work with those file definitions and those tools would be working with modern reference data.

You are remembering correctly; while a lot of the functions in KUJU's AE and RE will likely exist in the OR AE and RE (and intermediate tools), they'll be based on today's knowledge, data formats, etc., as well as what people in this community want. For example, your example of being able to arbitrarily increase the resolution of specific areas of tiles: this would be a great way to combine large expanses of rolling terrain with accurate right-of-way terrain, and I definitely want to do something along these lines.

[Goku]

TSRE will have Kuju AE replacement, except activity simulation:

http://www.elvastowe...post__p__225162

Release date is still unknown. It would definitely go faster, if I'll be able to set up kickstarter or something to get some support.

[Genma Saotome]

James Ross, on 11 September 2017 - 10:22 AM, said:

You are remembering correctly; while a lot of the functions in KUJU's AE and RE will likely exist in the OR AE and RE (and intermediate tools), they'll be based on today's knowledge, data formats, etc., as well as what people in this community want. For example, your example of being able to arbitrarily increase the resolution of specific areas of tiles: this would be a great way to combine large expanses of rolling terrain with accurate right-of-way terrain, and I definitely want to do something along these lines.

Don't overlook what could be done with three terrain meshes -- water, land, snow. Three files; what is visible is a boolian operation to show what's highest. The GPU can do that for you is you pass it the data. A bit trickier in an editor tho as the developer needs to edit all three layers.

[Goku]

I think it is much better to use objects like "3d transfers" for water. It is how it works in most modern game engines. Do not reinwent the wheel.
.. but why we are talking about it in this topic? :)

[Lindsayts]

I do not know if this will be any help but here goes............

There are two problems with Goode homosline projection, MSTS, OR and TSRE5 all treat the tiles as flat and square, while the output of Goode Homosline is flat, the ONLY place on earth its tiles are square is in central Africa. this mean nearly all terain in OR/TSRE5 has some distortion and thisn can get quite significant.

The second problem with Goode Homosline is that the mathematics treat the world as spherical, the problem being the earth's shape is ovoid, ie a flattened sphere, its diameter at the poles being less than the diameter at the equator. This makes distance bewteen points in the world model inaccurate. In Victoria Australia this effect reduces distances in a route by about 1.5%. I personally regard this as unexcatable.

A way forward would be to use Transverse Meractor projection, it can produce tiles the are flat AND truly square, the mathematics published for it account for the worlds true shape so both of the above points are covered. There are at least 2 opensource projects that will do conversions to Transverse Meractor around so the work does NOT have to be tackled from scratch. What would be required in both OR and TSRE5 is to modularise the geo conversion routines so they can easily be replaced by another projection.

I use a world model that is quite different to the above, it being the one used by at least 2 flight sims, to use it though in OR it (OR) would need a big rewrite, so its likley to be unexcaptable.

Note: I think both OR and TSRE5 are VERY good, it does annoy me though that there is this relatively small problem with the world model.