Reflections

Are there any others that I should postpone purchasing until the green wheel issue is sorted?

Click to expand...

None of my K&L engines have the green wheel treads. A couple have the appearance of painted black wheel treads ( the CN N4a & N4b) where they look just right in T:ANE. It looks like the Frisco engine has this. I don't have the B&O engine in question. I'm holding off for a bit to see what happens, though I'd sure like to get the Q-3. Many of my davesnow stock has the green treads, though. Desperate to keep them in the game, I swapped trucks on many of them where it would work till it gets sorted out.

Best to All,
smyers

I would like to view more screenshots of this Green and distorted reflections

Dinorius_Redundicus said:

I have little doubt these errors will be fixed in time. What concerns me more than the bug itself is what it says about the standard of N3V’s quality control. To put out an early release without (apparently) verifying that the legacy texture materials are still rendered correctly is quite staggering. I mean, it’s not exactly a subtle or hidden fault in some unimportant aspect of the program. How was such a fundamental flaw not noticed? I hope the company is asking itself that question as well as looking for the technical fix.

Click to expand...

I think what has happened here is now that we've gotten used to the bright and shiny, literally speaking, new version, we're now seeing the faults that weren't reported before such as the green wheels and other things. Unlike previous versions, including T:ANE, there are a lot of new things here which took sometime to get used to, but once that nice new car smell is gone and gum is left on the carpet, we're now beginning to see the faults.

but once that nice new car smell is gone and gum is left on the carpet, we're now beginning to see the faults.

Click to expand...

Well said, JCtron. They appear to be many and varied. Check the "shadow" on the HP Trainz SD40 compared to the built-in Geeps behind it. This excellent engine is from the NARM website...



The CN box car is one of Dave's 60' HiCubes. They're beauties, too. You can see the green wheel treads.

Best,
smyers

@ JCitron - No, you shouldn’t pass it off like that. My point was that N3V should have picked up these particular faults if they had done anything like systematic checks on how the new game engine handles legacy texture materials. The fact that they were only discovered by users indicates such checks were not done. And that’s pretty shocking given that the main advance in TRS19 is in the realm of textures and graphics.


.

Where is "LIKE" button here?

Dinorius_Redundicus said:

@ JCitron - No, you shouldn’t pass it off like that. My point was that N3V should have picked up these particular faults if they had done anything like systematic checks on how the new game engine handles legacy texture materials. The fact that they were only discovered by users indicates such checks were not done. And that’s pretty shocking given that the main advance in TRS19 is in the realm of textures and graphics.


.

Click to expand...

The developers, speaking of Chris B, aka Windwalkr, says they don't use the program (aka play with Trainz) so they wouldn't see this, but I do agree with you the internal QA team should have caught the Captain Obvious things before releasing the earliest beta.

To be fair to the early testers, we didn't have any third-party assets to test and could only play with built-in stuff that didn't exhibit these issues. It wasn't until just before the public early access that we could really import our other content and then that was only a week before the this SAAS version came about.

I've been checking through various rolling stock I've imported now that we can, and I have found that some bogies are fine while others are not so maybe the fix isn't as bad as it seems if it's only one dependency affecting a whole bunch of stuff then a single asset update will fix them all. Maybe it's easier than that and this can be fixed in the game code because stuff worked before and it doesn't now.

Having looked at the bogey wheels shown in Dave Snow's opening post (referred to later as <kuid2:101046:101215:1>) I can see that the m.reflect material on the rim surface was made incorrectly. It is missing a Diffuse texture and only has a Reflection map, which is a contravention of what's in the Wiki. I guess this is an example of what Zec alluded to in an earlier post as a material configuration issue.

The puzzling thing is why it wasn't ever flagged as an error and still appeared to work in previous Trainz builds and why it still wasn't flagged as an error in TRS19 where it clearly does not work.

The other examples such as lack of Specular control mentioned by clam1952 are probably different types of error and still of concern as to how they were not spotted prior to release.

.

This green texture issue has been present since the first release of TANE. There are many assets such as the Heisler found a few pages back that will exhibit green wheels in TANE. Around half of my assets were at fault for this for the exact reason.


The improper way:


Since it's a m.reflect material, the game is looking for the diffuse. To fix it, just add a diffuse in addition to the reflection and it will work. Why the K&L loco is showing this happen in TRS19 but not TANE is curious. Maybe Chris can comment on this.

The fault is completely at the artist, not N3V. I asked this issue to Chris in the past and E2 is "smart" in the sense that it detects when issues such as this happen. JET did this, but it was unpredictable whether or not it actually will show an error.

JCitron said:

The developers, speaking of Chris B, aka Windwalkr, says they don't use the program (aka play with Trainz)

Click to expand...

Anyone else see the problem here?

norfolksouthern37 said:

Anyone else see the problem here?

Click to expand...

It's not usually seen as a problem. It is common for the development team to be functionally separate from the QA team so that the QA process is not driven by what the developers expect to happen, but rather by what QA has defined as the required outcome. See here for a more detailed discussion.

norfolksouthern37 said:

Anyone else see the problem here?

Click to expand...

Nope. It par for the course.

But if the cause is missing diffuse textures, how is that N3V's fault? TRS19 tries to substitute something which happens to show a green tinge. Which would be a warning that something is missing. If previous versions didn't put in a stand-in, perhaps that was really a fault since it allowed assets with missing textures to slide by into the next version.

Stopping the stand-in process by TRS19 might fix the appearance issue now at the unknown cost of something perhaps more important down the track not working. Fixing the problem at the source will require work by each creator but result in "better" objects. Just how many objects are there that are affected by this?

So, if I may, can I go back to my question in an earlier post in this thread. If I don't have the original source files, can I somehow edit the tga files of an asset to remove the greenness?

Phil

Hi All
Just a clarification, many of our team members are not active users of Trainz (ie they do not spend their spare time playing Trainz, instead pursuing other things that are of interest to them). The Dev team do regularly use Trainz when required by the tasks that they are working on. Our QA team is separate to our dev team, and it is the QA team that 'play' Trainz during work time (much of this is testing reported bugs, but general 'play' as well). Other members of our team do actively play Trainz as a hobby outside of work, however we can't require any members of the team to do this outside of work time.



In regards to the reflection texture issue, it appears that in this case the diffuse texture has either not been specified in the material settings, which does not appear to trigger an error to occur. Instead, because there is no texture defined, Trainz will replace it with the green/pink checker placeholder texture.

In this case it appears that some assets may have encountered a bug where Trainz did not display this placeholder texture, and as such they looked something like expected (albeit probably with a lot more reflection texture than desired, since no diffuse texture was displayed). A bug fix was made around the time of TANE SP3 or with TANE SP3 HF1 (currently in beta), which may result in these assets (that have this issue but did not previously display the placeholder texture) now showing the placeholder texture.

I have submitted a task for our team to investigate making this show as an error for assets that lack a required texture for the material type specified.

However to actually resolve the issue, it is up to the creator to ensure that a diffuse texture is specified with these materials.


In regards to the general handling of legacy materials, these WILL appear different in TRS19. With the introduction of PBR, all objects must be rendered through the PBR system, and as such older content will have their materials (using the available textures, including any available specular or 'reflection intensity' maps) emulated as PBR using some fixed conversion algorithms. As such they will not look the same as in previous versions of Trainz, but exactly how different will depend on the materials, and the textures themselves in those assets.

We have made quite a few changes to the legacy material emulation since the initial TRS19 Early Access release. The current public beta build does include the majority of these changes from memory, and most assets will look a lot better after these changes.

Also, @pcas1986, for the issues you are seeing with the .m.reflect material, please check that you do have the latest public beta build, and then if you still see these issues please submit a bug report ( https://n3vgames.typeform.com/to/xRdryu ) with some example assets with source files.

philskene said:

So, if I may, can I go back to my question in an earlier post in this thread. If I don't have the original source files, can I somehow edit the tga files of an asset to remove the greenness?

Phil

Click to expand...

Hi Phil
Unfortunately, because no diffuse texture (ie no visible texture) has been specified, there is no way to fix without the original source files, as the asset needs to have a diffuse texture specified in the material and then re-exported. The problem is that there is no tga file referenced, and Trainz is having to substitute a placeholder texture in it's place to actually be able to display the object.

In TS12 and earlier, it would have appeared as a pure white texture, but with TANE a pink/green checker texture is used for the placeholder so as to ensure that it is obviously an issue, and hopefully the creator will then resolve it.

So Zec, just to be perfectly clear TANE SP3 HF1 will break legacy assets just like TRS19? Is that correct?

I have not had a chance to check this specific report in TANE SP3 HF1, so can't say if this particular bug fix was introduced in SP3, or SP3 HF1.

My comments relating to legacy materials/legacy assets and their emulation for PBR ONLY apply to TRS19.

Regards

So basically (as predicted) we are back to N3V blaming the creators and not the changes they have wrought in the program that has made previously error free content faulty. Grrreat…

When N3V are charging the price they are for TRS2019 whether as a one off purchase or the monthly subscription, I would expect the in house devs and programmers to be thoroughly playing and testing the changes made, particularly in regard to how they work with older content - given all the hoo hah about maintaining backward compatibility. It's their b...dy job for heavens sake!

Maybe time to check out 64 bit TS2019.

Hi All
I have tested the asset kuid2:101046:101646:1 in TANE (build 94916, the current public non beta version) here, and it definitely shows the green wheel tires on the bogies. It is not quite as intense as in TRS19 (which does use different algorithms to convert the existing materials to the PBR materials), but it is still there.


Unfortunately, this issue does appear to be a specific mistake by the content creator of the assets that show this issue, where the creator has literally left out the MOST important texture reference in their material setup, the literal visible texture (ie there is no visible texture on that mesh, so Trainz isn't being given something to actually display!).

The reflection is then added over the top of this by a varying intensity (as set in the material settings by the creator). If you have the intensity set to 50%, what should Trainz show under that reflection when nothing is specified and it is a requirement that something be specified (As per the material specifications on the wiki)? It will show a placeholder, the same as when a ground texture is missing it will show the default grid (not pretty, but tells you something is missing).

In this case a bug has caused the missing diffuse texture to be handled incorrectly, now in TRS19 (and in current TANE builds as well) this is being handled correctly. The problem is that it won't look good, but it is correctly substituting a missing texture with the placeholder texture. It's then up to the creator to ensure that they are correctly specifying a diffuse texture with this material.

The material outlines in the TrainzDev wiki for 3DSMax (also applicable to GMax, and the same rules should be used when configuring materials in blender) very specifically show that a diffuse is part of this material.

It is not our fault that a creator has incorrectly configured their textures/materials, it is entirely up to the creator to ensure that they are correctly configured. If they are not, then there will be unexpected issues occur in the future.

Regards