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