Textures: The "Layers-over-Layers-Myth"

[jost62]

Textures: The "Layers-over-Layers-Myth"
1. Why did I start this?
The reason is performance: The rumor / myth / opinion was: Covering textures TOTALLY still leaves "something" in the map which still eats up performance.

2. What do we know now?
When covering a texture TOTALLY with another texture the kuid of the covered texture dissappears out of the config.txt in that map after the SECOND saving (the second changing must include one change in the map - only then the old file becomes overwritten). That has been tested by me several times, and is confirmed by other users (see the messages above).
All testing has be done with TRS2004 - do not know about 2006/7.
That means: When loading that map there are no overpainted kuids left that use up loading time.

3. What is unanswered:
There was argued that the overpainted texture-kuids even after having dissapeared in the config.txt still may remain in the *.gnd-file - using up performance here .
I tested how the size of the .gnd-file changes by adding/reducing the number of different textures:
1 texture = gnd-file = 85 kb
7 textures= gnd-file = 85 kb
17 textures= gnd-file= 85 kb
37 textures= gnd-file= 86 kb
77 textures= gnd-file= 87 kb
Reducing it back to 2 textures through overpainting:
2 textures= gnd-file= 86 kb
That means: Adding AND reducing the number of textures indeed changes "something" in the gnd-file. The difference in loading time is irrelevant, but it might be that there is information stored in this file that uses more or less performance - even after reducing the number of textures in the config.txt.

This I can not verify as I have no idea what the gnd-file stores and what is does. Perhaps one of our experts can illuminate that for us.

My conclusion at this point for me is: Overpainted textures disappear and do not eat up performance. But perhaps one of our .gnd-file-specialists convinces me that I have to change my mind ...

 

[john259]

I am no expert at this, but I found this link that might be useful to those who dabble more seriously than I do
http://www.vsoftonline.com/blog/?page_id=58

Thanks Peter but I suspect that might not be Auran's GND file.

John

 

[Tokkyu40]

Here's one for you.
OBJECTS!!!
When you delete them in surveyor they stay there. They do not budge and are still in the map file and the config file. I put a windmill in one of my layouts and then deleted it and I still found it in the Dependecies. And do not go on about "It has been fixed in Classics". That is utter crap. Classics is what I did it on and found out about the problem in the first place.

Good luck!

Does it go away when you use "delete missing dependencies"? I had one interesting problem where I deleted a steam engine and the track it was on, and when I went back later the smoke was still coming out of where the stack used to be. Deleting all the missing objects cleared it up, but it really looked weird.

Claude

 

[RPearson]

I am no expert at this, but I found this link that might be useful to those who dabble more seriously than I do
http://www.vsoftonline.com/blog/?page_id=58

HTH

Peter

No that's a different format description. Maybe used with a game called Ragnarok - I'm not familiar with it.


@John
Auran has published the map file formats for UTC and TRS2004 although the latest copy I have has some descrepency between it and the format used by SP4 and TRS2006 and doesn't include some new objects.

Originally they were going to make it public but then required you sign an NDA to obtain a copy. I think that policy has changed but in any event if you need a copy you should send a request to the helpdesk. I'd suggest you indicate what Trainz oriented projects you're working on and why you need the map formats.

Bob Pearson

 

[john259]

Thanks Bob. It's mainly just for curiosity and playing about, I don't need or want to get into NDA's and formal agreements.

John

 

[OzBoz]

You would think, that, seeing this is a fairly basic question, and one which none of us are in a position to find the answer, Auran could come up with a firmer response than "rumours"

John, as far as I'm concerned, if it ain't in the config file, then it ain't on the map. I came by this opinion a few months ago while experimenting along the lines you posted. Until I see evidence to the contrary (and I'm not saying there isn't any) that's how I believe it works.

Painting over 30 textures with a single colour, and saving twice definitely reduces the size of the Gnd file (although not back to the 85 kb of a fresh blank board) so something has definitely been removed or changed.

Cheers

 

[john259]

as far as I'm concerned, if it ain't in the config file, then it ain't on the map

That makes sense to me. It could perhaps be checked to some extent by painting as described earlier but with non-built-in textures only, then deleting all but the last texture used and seeing if Trainz reports any problems loading the map.

It's entirely possible that a gnd file could contain debris texture data which is no longer pointed to and therefore no longer used, in the same way as a hard disk still contains deleted file data which isn't pointed to. However, I've absolutely no idea if this is actually the case or not.

John

 

[Dinorius_Redundicus]

.... It could perhaps be checked to some extent by painting as described earlier but with non-built-in textures only, then deleting all but the last texture used and seeing if Trainz reports any problems loading the map......

John

That would be a very powerful experiment. As we all know, the black screen of doom needs only the slightest hint of a missing asset in order to darken our lives. You should test it and tell us what you find. The thread is still a little inconclusive.

 

[OzBoz]

Using 10 non built-in colours, and then deleting all but the last from the config file does not remove the 9 colours when next loaded. Obviously info is being kept by the gnd file.

However, if the 10 colours are overpainted with an 11th colour, and the map saved twice, the original 10 colours are removed from the config file.

This also holds true if Erazor is used. You end up with what looks like a blank grid, but the config is showing one texture (Erazor)

Cheers

 

[john259]

Brian,

The test would be to delete the actual texture kuid folders, not just their entries in the config.txt file. I'm going to be busy today but will try to do it when I get a chance unless anyone else does it first (hint hint!).

John

 

[big_b]

I'm still fooling around in TRS2006 now I'm trying to get back to original grid from a fully textured maps & then merge them.I tried to merge these 9 before as there were but exceeded the 250 texture limit
I have successfully removed all textures in the same 9 maps of mine.No textures in the config ( checked with both CMP & CCP ) just the original grid, scenery & track.But after the merge I found up to 27 textures had re appeared from where I don't know.The entire merged route still has no visible textures.

Dave

 

[OzBoz]

John,

It seems to be pretty much as you'd imagine.

Removing the colours from the config file makes no difference. They still show up in the map, but won't reappear in the config unless you restart, or save.

Removing the colours from the config file and removing the colour's folder gives the black screen of death, even after adding a tree and saving a second time. Saving a second time just puts the colours back in the config.

If you select "delete missing assets" after the black screen, then that colour is removed from the config and map.

All you need to do then, is copy back the asset file to the downloads, and you're back to square one, without the offending colour.

None of that answers the question of performance effects of layer over layer though.

 

[john259]

Removing the colours from the config file and removing the colour's folder gives the black screen of death

Thanks Brian. So that proves that a reference to a texture required by a layout can exist in its gnd file and yet not be listed in its config.txt file. In other words, looking in the config.txt file might in some circumstances not give you the full list of textures required by the layout.

John

 

[big_b]

Thanks Brian. So that proves that a reference to a texture required by a layout can exist in its gnd file and yet not be listed in its config.txt file. In other words, looking in the config.txt file might in some circumstances not give you the full list of textures required by the layout.

John

Well In TRS2006 a board with no visible textures no textures in the config & no missing dependicies still has textures there.
Start joining a few boards & they appear in the config not in the map and it still loads no balck screen of death.But try to get into the config with CCP & you get program errors & ccp refuses to open the file

Dave

 

[OzBoz]

.But try to get into the config with CCP & you get program errors & ccp refuses to open the file

Dave

Dave,

I found that to be one of the "joys" of 2006. No way to drill down to an assets files without going through the CMP, and with all the assets folders being code numbered, you are forced to use it.

Cheers

Brian

 

[OzBoz]

Thanks Brian. So that proves that a reference to a texture required by a layout can exist in its gnd file and yet not be listed in its config.txt file. In other words, looking in the config.txt file might in some circumstances not give you the full list of textures required by the layout.

John

It would be nice if Auran confirmed what we suspect, or even gave us a hint as to what's contained in the gnd file, and whether or not we can manipulate it to cover these events.

Cheers

 

[jost62]

One of our specialists sent me a printout of a gnd-file which confirmed that texture-kuids are store/used there. He is working on more testing to find out how the gnd-file changes when adding /deleting textures.
More information to come!

 

[jost62]

The myth is proved to be a myth!!!

Believe it or not:

After several testing and analyzing the config and gnd-files the result is clear:
Totally over-painted texture disappear out of the map! (after the second saving).
There are no layers over/below layers of textures! (if totally covered)
It is true: The gnd-file stores the kuids of the used textures.But they disappear in the same way there as they disappear in the map-kuid.

Thanks to our specialist geophil: :clap::clap::clap:
He analyzed the gnd-files and could clearly show based on the data out of the gnd-files that that the covered textures disappear without leaving anything!

(We know: Myths live forever! No matter what mythbusters prove. I am afraid this will also happen to what was found out here).
jost62

 

[OzBoz]

Thank you jost62 and geophil. Just one final question.

When you say over-painted, does that include removing the old textures from the config file as well?

Cheers

Brian

 

[Switcher84]

Believe it or not:

After several testing and analyzing the config and gnd-files the result is clear:
Totally over-painted texture disappear out of the map! (after the second saving).
There are no layers over/below layers of textures! (if totally covered)
It is true: The gnd-file stores the kuids of the used textures.But they disappear in the same way there as they disappear in the map-kuid.

Thanks to our specialist geophil: :clap::clap::clap:
He analyzed the gnd-files and could clearly show based on the data out of the gnd-files that that the covered textures disappear without leaving anything!

(We know: Myths live forever! No matter what mythbusters prove. I am afraid this will also happen to what was found out here).
jost62

So let me see if I understand this if I cover a texture with another texture there is nothing under it