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

In the forum often the opinion is shared, that overpainting textures leaves hidden layers of textures (5 or 12 or more) "below" the "covering" texture, such eating up performance.
Testing this in TRS2004 proved this being a myth: Covering old textures totally with a new one makes all the overpainted textures disappear in the map!

"Edit Sept30 refering to posting #38 for those who want a shortcut through the discussion: All testings proved that totally over-painted textures disappear out of the map! (after the second saving). And: There are no layers over/below layers of textures! (if totally covered). End of Edit"

That was the test:
Step 1. I opened a new baseboard and placed 20 textures there;


saved and closed Trainz.

Step 2. Listing the map in TrainzObjectz lists the 20 textures as expected:



Step 3. Then I reopened the map in Trainz again and over-paint the textures with one other texture totally:


Again: Save, and close Trainz.

Step 4. Listing the map in TrainzObjectz: great dissapointment, even worse - it still shows the 20 overpainted textures plus the new one used for overpainting.

Now you think you got me? :hehe: Wait:

Step 5. Again I opened the map in trainz, and added one extra texture (it even could be the same used for overpainting). In the following screen I placed the blue spot in the center:


Step 6. Again: Save, and close Trainz.

Step 7. And now: List the map in TrainzObjectz: And oh wonder:


The old 20 textures have disappeared, only the new two are listed.

Step 8. Still not believing? Then test it yourself: Go back to Step 1 and start ....

Additional comment: To all who found after overpainting the old textures still in the map:
In my experiment the overpainted textures dissappiert only after the SECOND saving! And you have to change in this second round at least one item: If no change is made you can press "Save" and it will make no "Save" because the program knows that nothing was changed. By changing one item you force the program to save - and it seems in this second save process the overpainted textures are deleted from the map-file.
And of course: You have to do this overpainting thoroughly. We all know that if you only paint over a texture shortly, you still have transparency where two (or more?) textures are shining through the other. In this case of course the old texture still in the map.
And: Before opening Trainz every time I deleted dispatcher.chump.

Shall I call this thread "The Myth-Buster" or "Believe it or not"?

jost2

I think you are confusing yourself, nobody has said that the textures are there to be seen, as you found, only the VISIBLE textures appear in the map file as shown by TO. As TO was not designed by Auran and was not intended to show all the details in the map files, just the ones important to us, your result is not surprising.

However, what is being said, and this was confirmed by Auran a long time ago, is that the previous textures are still recorded as having being used at each point and only finally disappear when they reach the bottom of the five layer stack.

Your final comment confirms what happens. A light 'dusting' of one texture allows the one/s below to show through which would indicate that more than one texture is recorded as remaining in the stack.

I would prefer to believe what we were told by the program designers.

Cheers

Narrowgauge

Well, I prefer to believe what I can see from the evidence not what someone tells me.

The textures that disappeared from the file were not 5 layers deep. They only had one, or at most, two textures on top of them (ie. red or red+blue) so something is wrong with that concept.

Are you saying they really were gone from the file once covered by another texture and that it is just a failure of TO to detect the true number of textures until after 2 saves are done? That's what is most confusing to me.

This is easy to reproduce, and when you do, don't use TO.

I copied the op's suggestions and the 3rd layout did indeed only have the 2 textures in the config file. (I looked at the config file directly, not TO)

I'll ask Aidan and James of what they've seen in the code in this respect.

Alan_Yeomans said:

This is easy to reproduce, and when you do, don't use TO.

I copied the op's suggestions and the 3rd layout did indeed only have the 2 textures in the config file. (I looked at the config file directly, not TO)

I'll ask Aidan and James of what they've seen in the code in this respect.

Click to expand...

Sounds like he's on to something. If it isn't in the config file, it isn't in the route...

I'm suspecting somewhere between UTC and 2006, the way textures are handled might have been changed, providing us with this perhaps unintended, but much welcome, benefit.

rumours from rumourers

* Loading, making one change purely so you can save, and then resaving is known to clean out unused stuff from the map.

* One to watch out for the 'texture passes' slider - if you don't have it on full, you could be leaving bits of the texture in place even if you can't see them. I'd recommend having the 'texture passes' slider always at the maximum when doing any texturing work in surveyor, even if it makes your machine a little slower. (QFT -Alan)

* Another one is the session. Often loading *just the map* with no session and resaving that can be different to loading a map with a session loaded too, and resaving both. Some versions are known, for example, to add the session dependencies onto the map as well as the session.

* the textures might not be saved in the config, but residual details may be stored in the map or gnd file



Im not 100% certain on the accuracy of these rumours

Alan

Thanks for checking with Aidan, it would be nice to get this 'storm in a tea cup' calmed down either way.

Is Windwalkr still available to consult. I think this is where the information came from.

I think that we are talking of two different things here. No one is denying that only the visible textures appear in the config.txt however it appears from comments on the old forum and the earlier information from Auran that the texture information still exists in a five item list for each vertex point and thus has to be processed by the game engine.

Norbert who created 'Erazor' would have found what actually exists, perhaps he could comment whether 'Erazor' deletes only the visible layer or all underlaying layers. Hiballer also did some later work with Norberts code, he may have some information.

Cheers

Narrowgauge

Interesting...

Hmm, this is a thread I'll definitely have to subscribe to.

I'm not at the point in my route where I'm doing some major texturing, but when I do get to that point, I'll want to know the best way to keep framerates as high as possible.

Just like science, more experiments, facts and data are necessary before we can make an undeniable claim or theory. Still, I am hoping Josht62 is right though...

:wave:

Gisa ^^

I originally started testing this after trying to merge modules to create a route & started loosing textures as they exceeded the 250 limit.So i was trying to delete textures to be able to join maps & re texture to stay below the limit

TRS2006

On an existing map using Erazor

After up to 11 passes leaving only the grid with no visible textures
Then CMP syas there are still textures in the map ( 5- 6 ) are usually left behind in CMP believes they are dependencies of that map.

On an existing map using textures only

An existing map fully textured with 25+ textures
After about 4-6 complete covers with texture CMP has the grid + 3 textures

On a single board up to 11 overlapping layers it will eventually get down to 2 textures plus the grid

The texture cover method works well. Better than erazor in my tests.

Dave

This is really getting interesting! I think I also have to subscribe to this thread !
@Alan_Yeomans: Thank you for you hint: I myself looked now without TrainzObjectz directly into the file world/custom/maps/nameofthemap/config.txt and found - as you described - there only the remaining two texture-kuids.

That means to me clearly - if nobody brings better evidence - that the other textures are finally deleted. My understanding is: If a kuid is not in the config.txt of the map, it
1. will not be loaded
2. can not be "hidden" or "invisible"
3. can not eat up performance.

@narrowgauge: This leads to my understanding that if a texture is not loaded it also can not be somewhere in a "five layer stack". Where I can easily agree with you: "A light 'dusting' of one texture allows the one/s below to show through which would indicate that more than one texture is recorded as remaining in the stack." But that is not what my experiment did: I TOTALLY covered the old texture.

@big_b: My experiment has nothing to do with that helpful tool Erazor. The function of Erazor hast to be tested separately - as you do.

Perhaps Alan's hint may play role: "to watch out for the 'texture passes' slider - if you don't have it on full, you could be leaving bits of the texture in place even if you can't see them. I'd recommend having the 'texture passes' slider always at the maximum when doing any texturing work in surveyor, even if it makes your machine a little slower. (QFT -Alan)" If you talk about the first slider from top (I have the German names, so I am not quite certain what you mean) I had set it in this experiment at 70% (the second at 60%, the third at 100%).

I am curious what we will find out ... Alan: I like your "rumours from rumourers" :wave:

Man wheres Mythbusters when you need them:hehe:?

WileeCoyote

jost62 said:

My understanding is: If a kuid is not in the config.txt, it
1. will not be loaded
2. can not be "hidden" or "invisible"
3. can not eat up performance.

Click to expand...

Not so. The config.txt will be updated by Surveyor using the .gnd file. It's the .gnd file that holds primary information about ground textures. There is the central texture table with its upper limit of 250. Each entry consists of the KUID and a reference count. And there are all the ground vertex attributes which define scale, rotation and opacity for each texture used with an individual vertex. These attributes refer to the central table for the KUID and contribute to the reference count.

When creating a .gnd file in TransDEM (HOG and MapMaker are similar here) I do not bother with KUID references in config.txt. Surveyor will load all the ground textures I write into the .gnd file despite the fact that config.txt does not list them yet.

The question was always about .gnd file handling by Surveyor, whether a) a texture attribute entry for a vertex will be automatically deleted once its opacity factor reaches zero and b) the central table entry will also be deleted once the reference count reaches zero. I think both is very much the case, although I have to admit that I never explicitly analysed the different stages.

Thank you, geophil.
Interesting! Already Alan pointed in that direction: " * the textures might not be saved in the config, but residual details may be stored in the map or gnd file".
I tried to look in the .gnd-file (using editor - ok, should know better: makes no sense ). Perhaps someone else has more knowledge how to find and understand the content of the .gnd-file ...

O B J E C T S ! ! !

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!

Try this

To follow up on what geophil has said, Open the config.txt file for the map and delete the textures. Save it then open the map and see if the textures are gone.

William

I did the texture test of:
1. Placing 9 small texture patches on a blank baseboard,
2. Covering those 9 with 1 larger texture,
3. Placing 1 small texture in the middle of that in 2.

I got the same TO results as shown in jost62's original post. I also examined the .Gnd binary file with a hex editor and it was the same size in all 3 cases indicating that all the texture info remains even tho only a few of them are listed in TO and/or displayed by Trainz.

Bob

rweber95 said:

I did the texture test of:
1. Placing 9 small texture patches on a blank baseboard,
2. Covering those 9 with 1 larger texture,
3. Placing 1 small texture in the middle of that in 2.

I got the same TO results as shown in jost62's original post. I also examined the .Gnd binary file with a hex editor and it was the same size in all 3 cases indicating that all the texture info remains even tho only a few of them are listed in TO and/or displayed by Trainz.

Bob

Click to expand...

Not necessarily. If the .gnd file has slots for 250 textures (I've no idea if it does or not), then the file size wouldn't change no matter how many textures there were, just the hex bits identifying the textures would, but there'd still be the same amount of them. Now if it dynamically adds or subtracts bits for each texture, that would indicate what you suggest.

I know the .IM files have bits for mesh texturing features even if they aren't used by the Trainz exporters (which is why it was possible to hack self-illumination into objects back in the old days). The size of the file didn't change, as the bits were already in there.

No you're wrong Magic. The table varies in size based on the number of texture kuids that it contains. The format includes a 4 byte integer indicating the number of textures used and a sequence consisting of a 4 byte float and an 8 byte kuid for each texture indicated by the count. Therefore the table size varies and is a total of 12 bytes times the number of textures. The float indicates the number of references to the texture in the gnd file vertex table and the format indicates that 0 is not used so presumably when the reference count is reduce to 0 the texture kuid is removed.

Bob Pearson

Gentz,

Obviously without wishing to infringe any commercial secrets, is the format of the gnd file in the public domain anywhere?

John

.gnd file format

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