[Genma Saotome]

Look in the \lo_tiles folder. The file types are all the same as in \tiles so all the same attributes are available. The software knows and acts upon the presence of tile data in both folders. The key point is the game code does not allow the tiles to overlap: DM tiles are, by definition, further away from the camera than near terrain.

So... if we assume the view distance for near terrain is the old MSTS 2000m then the near terrain processing will do the tile for the camera plus one tile further out in each direction. If DM is turned on and there is data in the \Lo_Tiles folder then the DM processing takes over and processes the DM tiles.

What I don’t know is what happens when the near terrain overlaps with the DM terrain. One sensible solution is to simply not process the DM patches that would overlap the near terrain tile (IIRC that would be 4 DM patches) per near terrain tile.

There is a visual error that often occurs from the fact that DM and near terrain data is for different mesh; Near terrain using an 8m grid. Offhand I do not know what the DM grid is, except that it is larger.

The visual error occurs when the near terrain grid includes a drop in altitude that does not occur at the same location in the DM grid. The result is a visible white gap. Not being able to correct that in MSTS the advice was to drop the DM terrain 10-30m below the near terrain. That usually solved the problem (but not always). I have long thought a better solution would be to either procedurally generate a hanging curtain along the edges of each DM tile, say a descent of 50m, and add the necessary UV data from the terrain mesh to this curtain. A more complex solution would be to dynamically change the mesh of the DM tile along any edge where it is adjacent to a near terrain tile… but I suspect that would be much harder to do and not necessarily better than a simple hanging curtain.

The process to generate DM tiles is done IN RGE (there is an icon that toggles the display of both tile types. The quad tree for DM goes into \td, I think using the file suffix of .tdl

The process to project terrain is rather strange: You use DEMEX and you must first project DEM data into a different route directory than the one you actually want them to be placed. I’ve set up a route for this purpose called \DEMEX. So I always project the DEM data into \DEMEX\tiles. The I must run KUJU’s RE and open the DEMEX route. That will generate buffers and whatever else that action does. I then return to DEMEX and invoke a function to move all of the files from \DEMEX\Tiles to \my_real_route\Lo_Tiles. Repeat as needed until done. The \DEMEX route is used in all cases of generating DM tiles and is not used for anything else.

Questions?

[Goku]

Genma Saotome, on 28 October 2017 - 04:00 PM, said:

DM tiles have different names. They're not accessible in KUJU's RE, only DEMEX and Mosaic. AFAIK you can do anything to a DM tile that you can do an ordinary tile... except place objects, setup water, and/or draw. Each DM tile has an 8x8 array of patches. Each patch is equal in size and position to a 2x2 array of ordinary tiles.

Everything wrong. I'm surprised how you could say that.

1. Each tile has the same kind of name - the name is position in binary tree of the world. Bigger tiles have shorter names, because their binary path is shorter.
2. There is nothing like DM tiles and ordinary tiles. All are the same, just different parameters. RGE can create Tile size 2048km, 4096km, 8192km, 16384km, 32768km (I-V). You can populate bigger tiles, but nothing happens ... (VI and bigger)

https://i.imgur.com/PvjfzZa.png

3. They are accesible in KUJU RE and you can do everything with them you want, textures, height - even place objects because World files are independent of Terrain in MSTS (in TSRE it's difficult ..) and .w files always have 2x2km size.
4. Overlapping tiles are not accesible in MSTS RE because you can't create them in RGE. At least KUJU team didn't wanted this, but you can trick RGE and create these overplapping tiles.
5. Each MSTS tile created using RGE has 16x16 array of patches, even "DM" (Tiles 16x bigger than .w file). The .t file format supports any number of patches and tile size, but I don't think different vaules are used anywhere.

[Genma Saotome]

p.s. there are \Lo_tiles folders in the original KUJU routes of Europe, Japan2, and USA2.

[Goku]

You said I can create the big tiles using RGE.

[Goku]

Anyway, support for different tile sizes has very low priority for me. I'd rather do other things first - including working trains. Only exception if many people will demand this feature and pay for it, like it's done with AE.

[Genma Saotome]

Am I am surprised you don't understand that \DM tile data is not in the \tiles folder, That DM tiles will, in almost all situations, overlap near terrain tiles and do so safely because (1) you cannot place objects on a DM tile as DM tiles do not have a corresponding .w file, and (2) are rendered at a different point in time using some method of a boolean merge to ensure they're not rendered on top of near terrain.

They are conceptually different to the route builder. Sure, they may be identical file types but they are USED FOR DIFFERENT PURPOSES. You know, not everyone sees the world as a coder does Goku. One of the great difficulties of the I.T. world is to build a team of great coders that includes somebody, ideally more than one person, who has some grasp of how the end users actually use the software and cares more about that than coding the slickest function you've ever seen. If the plastics industry was populated with the vision of most programmers all have buckets of plastic pellets instead of plastic cups, key caps, clam-shell packaging, and flexible clear wraps to cover out leftover food.

[Goku]

Quote

(1) you cannot place objects on a DM tile as DM tiles do not have a corresponding .w file

There is nothing like corresponding .w and terrain tiles. It is independent system in MSTS.
In TSRE it works a little different because I didn't knew much about terrain quad tree when terrain support was done.

Quote

Am I am surprised you don't understand that \DM tile data is not in the \tiles folder

Ok, I see the above answer.

[Goku]

Anyway, there is no difference for me between tiles and "low resolution" tiles. If TSRE could support different size tiles than 2048x2048km, making support for second set of tiles wouldn't be a problem.

[Genma Saotome]

IMO there is no need for TSRE to support different sized tile files in either \tiles (for near terrain) or in \lo_tiles (for DM terrain). The one size (the smallest area data acceptable to each directory) should be enough. There many be other people with different opinions but AFAIK there are very, very few routes that use multiple area sizes as near terrain and none that use multiple area sized as DM tiles.

There are only two things that come to mind for what TSRE could do with whatever is in \Lo_Tiles and that is generate the terrain mesh and provide a emeans for applying a texture for each patch. I will guess you already have code suitable for those steps, leaving the unanswered questions of (1) how to toggle back and forth between presenting near terrain and DM terrain to the TSRE user and (2) whether it would be worthwhile to display both (as OR does) so the route builder has a complete view of his work product. I think it would be good to show both, just like in OR, but I'm not going to fuss if that is not done. I do think it is essential for TSRE to provide for the projection and texturing as I mentioned above; I you don't then route builders will continue to depend on older tools to do that.

[Genma Saotome]

p.s. WRT timing, I can continue to use multiple tools to do what I need to do. My comments above are intended to help you understand functional gaps in TSRE for matters you should eventually add to TSRE if your goal is to replace the older editing tools used by route builders.

[Goku]

Quote

IMO there is no need for TSRE to support different sized tile files in either \tiles or \lo_tiles. The one size (the smallest area in each directory) should be enough. There many be other people with different opinions but AFAIK there are very, very few routes that use multiple area sizes as near terrain and none that use multiple area sized as DM tiles.

If you need two sizes, it's the same work like any size.

I don't say it can't be done, but for me there are more important things like new tracks and procedural objects and procedural terrain textures. Everyone will use that and almost no one uses LO_TILES, so the choice is obvious.

[Garry]

Hi Goku
I think the progress you have made with TSRE is staggering, it has made route building so much better. Thank you.

LO_Tiles --- I have 2 Swiss routes in progress and both would look much better if I could produce distant mountain tiles. If this was possible at some future date using TSRE I would certainly make use of it. I think that some way to toggle between near and distant would be the way to go, it is not too important how the route looks in TSRE, I always change to OR for a final look.

Procedural objects -- I think I read on an earlier post that these are similar to the way track and some other objects are produced in TrainSimulator2017. If so it would be great to produce curved platforms and bridges, and would be a good place to start to see how the texturing works as the curve progresses.

Procedural track -- I have started route building in TrainSimulator several times. Each time I have been defeated by complicated trackwork on a station approach. Trying to get double slips and crossings to render properly drove me nuts, and I was glad to get back to the "out of the box" track in MSTS.

Garry

[Goku]

Garry, on 30 October 2017 - 07:38 AM, said:

Procedural track -- I have started route building in TrainSimulator several times. Each time I have been defeated by complicated trackwork on a station approach. Trying to get double slips and crossings to render properly drove me nuts, and I was glad to get back to the "out of the box" track in MSTS.

Procedural tracks doesn't mean flexible tracks. I don't know why people use this term the wrong way all the time ...
Procedural means only that shape is generated using algorithm, not manually by human: https://en.wikipedia...ural_generation

Only true thing is that if you want to have flexible tracks, you need to have procedural generated tracks first.

[Garry]

Hi Goku
So is the advantage of procedural tracks, that they produce smaller file sizes, so that OR gets faster frame rates? But initially for a route builder they will only produce straight tracks (and objects), so the object can be made any length as required by the geography of the route requires.
If this is the way they are used, how would it deal with the arches of a viaduct, or a platform with lamps placed every 25 metres?
I will be interested to see how this develops.
Garry

[Goku]

The advantage is:
- you can make all new tsection.dat shapes that are best for your route. Making it by hand is tremendous work.
- you can use as many track templates and textures in one route as you want.
- faster loading.
- and of course flexible tracks in the future.