[Csantucci]

I am a co-author of the narrow-gauge Bernina freeware route; I have a problem there: there is not (yet) a snow version of the route; one of the reasons is that the route largely uses photographic terrain textures for the summer season, and there are more than 6000 files of them for a route that is only about 60 Km long. So, due to the fact that MSTS requires one snow texture file for every summer texture file, I should create 6000 snow texture files, and many of them would have the same (not photographic) content: a snow field: so they would all be replicas of the same file, but each with a different name of course. This is a waste of disk space and also of memory space at runtime.
So I am thinking to add a small additional feature to OR: if some snow terrain texture files are missing with respect to the summer terrain textures, and there is in the SNOW folder the ORTSsnowdefault.ace file, OR selects that file for such missing files; this way disk space is spared, and also a single copy of the snow texture is loaded into memory. This does not prevent to use individual files where needed.
Before considering implementation of this simple feature, I would like to have some opinion if this can be of interest for other people, and of more general use, or if it would solve only my particular case.

[RTP]

I fully agree. Regards.

[SVRy_Steve]

That's something I've wished for and never mentioned. I hope it happens!

Steve

[That Genset Foamer]

Maybe the "default" snow texture would be the "terrain.ace" texture in the route's TERRTEX directory--giving routebuilders and end-users some flexibility in assigning it.

EDIT: Just saw the post that the default texture will be "ORTSsnowdefault.ace". I'll set that texture up on the Salinas Valley then!

[conductorchris]

Need a picture of snow? You might do better, but I just took the attached photo which you are welcome to use. Probably needs to be lightened considerably (happy to do so, if you'd like)
Christopher Parker

[captain_bazza]

A single photo of snow applied would lead to a mosaic repeating pattern [of pixels]. Maybe oneday OR will be able to mix and and randomly meld together a group of textures to avoid mosaic repitition.

Cheers Bazza.

[Hack]

captain_bazza, on 04 January 2015 - 05:42 PM, said:

Maybe oneday OR will be able to mix and and randomly meld together a group of textures to avoid mosaic repitition.

Wang - it's a Microsoft thang. ;)

Railworks uses an 8 tile algorithm (with fair results), but it would be better to use 12 or 16. Here's a white paper on the subject.

[Genma Saotome]

An alternative thought: What we're speaking of here is a relationship between a tile patch and (at least) two image files used to texture that patch (the art and the microtex). That relationship gets recorded in one of the files for that tile.

What if that logic is used to hold textures for all seasonal and precipitation conditions and to do so in a new text file? That way ALL tertex files for ALL seasons for ALL precipitation conditions are wholly independent of each other. IOW if you want to use the same tertex file for all four seasons and all three precipitation conditions you don't need to have twelve copies of it on the disk, you have twelve entries recorded on the relevant tile file. And being good software the first time any tile is read if there isn't a file holding twelve sets of data already there the program will create one and add the default data.

It might look like this:

w-012984+014219.tertex ( a suitable file name)

Autumn (
	Dry ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
	Rain ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
	Snow ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
}
Spring (
	Dry ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
	Rain ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
	Snow ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
}
Summer (
	Dry ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
	Rain ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
	Snow ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
}
Winter (
	Dry ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
	Rain ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
	Snow ( 64 "slots" to hold a file name (or names) for each of the 64 patches )
}

Patch number one can be located in the northwest corner and the rest are serially numbered, left to right, top to bottom just as one might read words in a paragraph. Each of the 64 slots is composed of at least two file names -- the top tertex file and the underlying microtex file.


Now what that allows you do to is

• fixes the KUJU limit on tertex art for seasonality,
  
• fixes the unfortunate link between active in-game precipitation and what the ground looks like,
  
• fixes the Kuju limit on route-wide water art by enabling any number of unique water files assigned to individual patches.

AND does so right now with a simple text file w/o the need for an OR Team redesign of the KUJU files. At some later date when the OR team does do a tile file redesign there will already be a body of data that could be incorporated right into a new file... or left as is.

Last, if makes more sense to list the 64 file name(s) on 64 rows instead of the one row as I wrote it, that's fine with me.

Many problems solved, including the one you raised.

[captain_bazza]

"Wang" rings a bell.

http://www.elvastower.com/forums/public/style_emoticons/default/pleasantry.gif

CB.

[gpz]

Genma Saotome, on 04 January 2015 - 08:44 PM, said:

What if that logic is used to hold textures for all seasonal and precipitation conditions and to do so in a new text file? That way ALL tertex files for ALL seasons for ALL precipitation conditions are wholly independent of each other. IOW if you want to use the same tertex file for all four seasons and all three precipitation conditions you don't need to have twelve copies of it on the disk, you have twelve entries recorded on the relevant tile file. And being good software the first time any tile is read if there isn't a file holding twelve sets of data already there the program will create one and add the default data.

It is quite easy to make such extensions to the software, but I don't know how it fits to the advance plan. I just dropped together this for you to test, but I don't want to commit it without wide agreement. Afterall this is a kind of a route format extension...

 Added-terrtex-file.zip (625.52K)
Number of downloads: 417

The zip file contains a (non-LAA) precompiled RunActivity.exe, the source patch, and a sample .terrtex file. The terrtex file is in JSON format. In case of a missing tag or empty texture string in the specific position the program will fall back to the texture specified in .t file. If the tag is not missing (e.g. Summer.Dry), but the array is shorter than the position queried, the last name will be used, thus for a single texture to be used in all positions it is enough to include that string into array only once, as it is shown in the sample file.