Reflections
- Thread starter davesnow
- Start date
So now even if the creator forgot to include a diffuse texture it is still considered error free? And it is N3V's fault too? :hehe:
What an amazing amount of power and influence they have. Although it is a rather sporadic influence since most creators managed to put in the diffuse texture anyway so I wouldn't count on it always working.
What an amazing amount of power and influence they have. Although it is a rather sporadic influence since most creators managed to put in the diffuse texture anyway so I wouldn't count on it always working.
Dinorius_Redundicus
kuid 68213
There is obviously fault on both sides. On the one hand we have creators who, for whatever reason, didn't include a diffuse map in a material despite the Wiki saying one is required. On the other hand, N3V has never flagged this fault with an explicit validation error. They trap so many other texture errors, why not this one which is a pretty major violation? It would have saved this current situation from developing.
The fact that the game internally substitutes a white or now pink/green checkered map for a missing diffuse map was never made public by N3V, as far as I know. Creators who made the mistake didn't realise it because all they saw (in the older Trainz versions) was a shiny texture of some sort, and no error messages to say it was actually wrong. The problem was fairly well hidden from view until the pink/green thing came along. So I think a little empathy for the content creators is warranted here.
The fact that the game internally substitutes a white or now pink/green checkered map for a missing diffuse map was never made public by N3V, as far as I know. Creators who made the mistake didn't realise it because all they saw (in the older Trainz versions) was a shiny texture of some sort, and no error messages to say it was actually wrong. The problem was fairly well hidden from view until the pink/green thing came along. So I think a little empathy for the content creators is warranted here.
Maybe I missed something but I'm wondering if the green tinges are the green part of the substitute texture. In one of my experiments I could just see the substitute texture but it was very faint. It seems to me that there are considerable variations of the intensity between assets.
For Zec: I'm up in Sydney for the weekend but will continue to play with my test assets, including a test in the latest TRS19 beta, when I get home. I haven't bothered with the latest TANE beta but I guess I can have a look.
At this point, I think the only solutions are to use IM meshes with m.reflect and a diffuse texture or go for PBRMetal and TB4.6. I can't get FBX and m.reflect to work. i.e. with a gloss/reflective effect.
For Zec: I'm up in Sydney for the weekend but will continue to play with my test assets, including a test in the latest TRS19 beta, when I get home. I haven't bothered with the latest TANE beta but I guess I can have a look.
At this point, I think the only solutions are to use IM meshes with m.reflect and a diffuse texture or go for PBRMetal and TB4.6. I can't get FBX and m.reflect to work. i.e. with a gloss/reflective effect.
On the bright side 
this could be used as an opportunity to cull the herd. Removing any asset that has missing textures from the installed set is a quick if drastic fix. For those made by creators no longer with us, this might be the only solution, unless they consigned their source files to someone else.
Should N3V have flagged this as an error ? Sure. Can it be tested and flagged without opening the source file? I don't know.
this could be used as an opportunity to cull the herd. Removing any asset that has missing textures from the installed set is a quick if drastic fix. For those made by creators no longer with us, this might be the only solution, unless they consigned their source files to someone else. Should N3V have flagged this as an error ? Sure. Can it be tested and flagged without opening the source file? I don't know.
On the bright side
Which brings us back to the previous discussions that TRS2019 should never have been conceived as a platform for old content. Something I was greatly in favour of but got shouted down by the herd who still want to run their Trainz CE and UTC when there are plenty of versions that cater for the content of yesteryear.
So far as practical solutions are concerned, why not an option for users to have the "faulty" textures display as a dark grey colour rather than the garish green of the replacement? This might make it harder to track down where the faults are but then the author of the asset should no and for the end user, less dis-pleasing on the eye.
To deliberately exclude older content just because it is old would be an even worse situation. An object created with a missing texture is faulty whether old or new. I would rather have the garish green so they can be easily identified and quickly corrected if possible or removed if not. Many older objects are perfectly fine, well made and should be welcomed in the newest versions of Trainz. If they don't pass muster, then discard and replace.
ex-railwayman
New member
Yes, you can't withdraw these assets off the DLS, as they are fine for older versions, indeed, I have plenty of Dave Snow's freight wagons installed in T:ANE, they all use his Barber S trucks, they've been downloaded nearly 150,000 times, since 2012, so, they must be OK in older versions of Trainz, otherwise this problem would have been flagged up ages ago, and if you fiddle about with them now they might be made obsolete in all the assorted freightcars they've ever been used on for the last 6 years.
Cheerz. Steve.
Cheerz. Steve.
Last edited:
If someone has the original source files, then yes, the fault is as easy to fix as adding the missing texture to the appropriate place in the mesh. The problem is for those objects where there is no source file, for whatever reason - files lost, the creator is gone or not interested.
Barring some other fix method, leaving them on the DLS just lets others trip over the same error. Perhaps a warning could be added to any potential download attempt. Some people might like green tinged shadows, so a heads up could be given, then if they are still downloaded, no complaints will be accepted.
Barring some other fix method, leaving them on the DLS just lets others trip over the same error. Perhaps a warning could be added to any potential download attempt. Some people might like green tinged shadows, so a heads up could be given, then if they are still downloaded, no complaints will be accepted.
The problem with that option, Vern, is that new versions of Trainz are issued every couple of years. The amount of work required to create new stuff to suit each new version would enter into the realm of ridiculous.
Not every time, obviously. But at some point a line has to be drawn. Should really have been done with TRS12 to TANE but TANE into TRS2019 would have provided a perfect cut off. the old content doesn't go away, it remains available to the version of the game it was created and optimised for.
I agree. The argument for making a complete break with the past was debated in these forums when TANE was first announced. It is a very attractive argument for the benefits it would bring in terms of assets that can look far better and make better use the new technologies available in the new release. The downside is the time we would have to wait for these newer and better assets to be come available and the fewer number of "expert creators" that would be capable of creating them. Take a look at the latest (as of today) 100 uploads to the download station - 69 of them are for TS12 and only 4 for TRS19 (and 3 of those are layouts).
With the way that Trainz is evolving the knowledge and expertise needed to create scenery and rolling stock assets with the new technologies, for example PBX, is way beyond my resources and capabilities not to mention the time needed.
Well it is still about the "green" tinge caused be faulty assets and what to do about them. So fix those that can be fixed but what about the rest? Do they stay or do they go - that is the question? How it is ultimately decided will set the pattern for similar future issues. Most have already made it clear where they stand and why in this and many previous threads. Saying it again will not solve the problem. I think the ball is now in N3V's court. Oh to be a fly on the wall as this is debated internally. One thing is almost sure, whatever the solution, some people will not be happy while others will rejoice. Or could they find a solution that satisfies both camps?
I tried with FBX and metadata files and it failed with a missing texture (albedo) that I thought was ironic. I believe the metadata parser is only looking for PBR material names but I could be wrong.
Perhaps N3V could extend the format to include legacy materials. It should solve the problem of the diffuse texture not being identified in the IM or FBX files without the need to reverse engineer those meshes.