Trainz Update Announcement (SP6)

I've tried various routes, including payware (free) "Canadian Rocky Mountain, Sebino Lake..."It works on all of them.Now I've downloaded my own route, "Margining Yard Maschen," ( Rangierbahnhof Maschen) from DLS in build 131950 and see this:

https://www.trainz.de/file-download/70864/
https://www.trainz.de/file-download/70864/
https://www.trainz.de/file-download/70864/


Here's the comparison in build: 129876 Every update after that causes errors like Screen 1

70865
According to N3V, the issue is not their crappy code and it's our fault for using too many high poly assets.
 
What a great statement from n3v, it's your own fault.In the example screenshot, there's not much built in other than a lot of track.Strangely, everything works perfectly up to build 129876,even my long-distance route runs with it.The main thing is that you have a Trainz+ subscription to pay for, because without it, you can't even start Trainz anymore, yet they release such garbage as an update.
Sorry if the translation isn't that good.
 
What a great statement from n3v, it's your own fault.In the example screenshot, there's not much built in other than a lot of track.Strangely, everything works perfectly up to build 129876,even my long-distance route runs with it.The main thing is that you have a Trainz+ subscription to pay for, because without it, you can't even start Trainz anymore, yet they release such garbage as an update.
Sorry if the translation isn't that good.
Your summary is perfect, no problem with that translation.
 
I want to weigh in here with my own thoughts on this. I jumped on the PBR band wagon almost from the beginning and have produced more PBR assets to date for Trainz then anyone else I think, so I am well familiar with the ins and outs of PBR. The industry standard for PBR textures, based on my extensive experience with CGTrader assets, is either 2K or 4K, with 4K being the more common. Trainz does not accept 4K assets, so I routinely have to scale these assets down to 2K. 2K textures allow for a lot of texture detail compared to 512/1024 or lower sized ones. What we can do today with powerful tools like Adobe Substance texture tools is orders of magnitude greater than what we could do 20 years ago in Trainz using nothing more than paint programs.

The other problem I see in Trainz is the expectation of extremely low poly counts, while at the same time desiring highly realistic looking assets such as structures and foilage. CGTrader, which is a global market for game builders looking for 3D content for games and simulations, consider the definition of low poly to be vastly higher than what Trainz users think it should be. As an example, I recently purchased a grain elevator from CGTrader that was listed as low poly, but had a poly count of over 500,000 polys! I had to "dumb down" the structure considerably by eliminating a lot of fine detail, to get it down to something Trainz users could accept, and I am sure some out there will still complain about the final poly count I arrived at (ie 79,254). It was a real shame as the pre-dumb-down structure looked beautiful, and on par with what you might see done for real world model railroading by Fine Scale Models company or other similar companies.

The albedo, normal and parameter files required for Trainz PBR support tend to be rather data intensive due to the various layers, especially in the parameters texture map, so you end up with multiple megabyte sized files. This quickly adds up if there are multiple textures in use, which is often the case. Unfortunately, this is the price you pay for PBR, which looks a great deal better than just a diffuse texture by itself, which is what we used to use prior to PBR.

Trainz has evolved toward ever more realism, but building structures and other items that look realistic comes at a steep price, even with LOD. I play a lot of state-of-the-art simulations and FPS games, and only Trainz seems to have graphics problems and "stuttering", which I continue to see, and I don't see elsewhere. I think a lot of this comes from the decision by N3V a few years back to build their own proprietary graphics engine, instead of using one of the industry standard ones such as Unreal. While N3Vs graphics engine has continued to evolve over time, some of the basic problems we saw years ago, especially stuttering, continue to haunt us today. Unfortunately, it seems to me that the graphics engine has not kept pace with the evolving demands on it.

BTW I implemented the new Treez on my recent route release of the Wilsons Mills and Mount Olive route, and I can't say I really like them all that much. The problem isn't the tree design itself, but the way-to-short distance before LOD kicks in. While the change in LOD might not be all that noticeable for a single tree, you really do notice it when it happens with a good number of trees in the same area of your vision. What I see reminds me strongly of how they implemented TurfFX and Clutter, which sort of works well for those items, but not so great for Trees.

If N3V wants the best-looking graphics of any Train simulation out there, then they are going to have to bite the bullet and tailor their graphics engine to support PBR and highly detailed content. You can't have it both ways here.

Bob
 
Last edited:
I want to weigh in here with my ownh thoughts on this. I jumped on the PBR band wagon almost from the beginning and have produced more PBR assets to date for Trainz then anyone else I think, so I am well familiar with the ins and outs of PBR. The industry standard for PBR textures, based on my extensive experience with CGTrader assets, is either 2K or 4K, with 4K being the more common. Trainz does not accept 4K assets, so I routinely have to scale these assets down to 2K. 2K textures allow for a lot of texture detail compared to 512/1024 or lower sized ones. What we can do today with powerful tools like Adobe Substance texture tools is orders of magnitude greater than what we could do 20 years ago in Trainz using nothing more than paint programs.

The other problem I see in Trainz is the expectation of extremely low poly counts, while at the same time desiring highly realistic looking assets such as structures and foilage. CGTrader, which is a global market for game builders looking for 3D content for games and simulations, consider the definition of low poly to be vastly higher than what Trainz users think it should be. As an example, I recently purchased a grain elevator from CGTrader that was listed as low poly, but had a poly count of over 500,000 polys! I had to "dumb down" the structure considerably by eliminating a lot of fine detail, to get it down to something Trainz users could accept, and I am sure some out there will still complain about the final poly count I arrived at (ie 79,254). It was a real shame as the pre-dumb-down structure looked beautiful, and on par with what you might see done for real world model railroading by Fine Scale Models company or other similar companies.

The albedo, normal and parameter files required for Trainz PBR support tend to be rather data intensive due to the various layers, especially in the parameters texture map, so you end up with multiple megabyte sized files. This quickly adds up if there are multiple textures in use, which is often the case. Unfortunately, this is the price you pay for PBR, which looks a great deal better than just a diffuse texture by itself, which is what we used to use prior to PBR.

Trainz has evolved toward ever more realism, but building structures and other items that look realistic comes at a steep price, even with LOD. I play a lot of simulations and FPS games, and only Trainz seems to have graphics problems and "stuttering", which I continue to see, and I don't see elsewhere. I think a lot of this comes from the decision by N3V a few years back to build their own proprietary graphics engine, instead of using one of the industry standard ones such as Unreal. While N3Vs graphics engine has continued to evolve over time, some of the basic problems we saw years ago, especially stuttering, continue to haunt us today. Unfortunately, it seems to me that the graphics engine has not kept pace with the evolving demands on it.

BTW I implemented the new Treez on my recent route release of the Wilsons Mills and Mount Olive route, and I can't say I really like them all that much. The problem isn't the tree design itself, but the way-to-short distance before LOD kicks in. While the change in LOD might not be all that noticeable for a single tree, you really do notice it when it happens with a good number of trees in the same area of your vision. What I see reminds me strongly of how they implemented TurfFX and Clutter, which sort of works well for those items, but not so great for Trees.

If N3V wants the best-looking graphics of any Train simulation out there, then they are going to have to bite the bullet and tailor their graphics engine to support PBR and highly detailed content. You can't have it both ways here.

Bob
And the interesting thought is with .fbx assets and Blender sources much of the current content could be moved to another engine.

John
 
It seems, that the new update is keeping the build-version 5.6. In that way you can keep the old version of TRS 22, without the update.

I can imagine, that a new main version, for instance TRS 26 or TRS 27 will have build-version 5.7. In this case, I can install the new version and ad content from my old TRS 22-installation, as I wish. I can use my TRS 22-installation futhermore, as I can do with my TRS 19-installation.

Regards
Swordfish
 
I've tried various routes, including payware (free) "Canadian Rocky Mountain, Sebino Lake..."It works on all of them.Now I've downloaded my own route, "Margining Yard Maschen," ( Rangierbahnhof Maschen) from DLS in build 131950 and see this:
Isn't this similar to a bug a while back that involve track not appearing? John, do you remember it? You developed a work around.
 
Isn't this similar to a bug a while back that involve track not appearing? John, do you remember it? You developed a work around.
Splines definitely seem to be loading in much slower than other things. As I drive down a route I'll watch tracks and fencelines be built in front of me and watch them disappear when I look back.
 
Isn't this similar to a bug a while back that involve track not appearing? John, do you remember it? You developed a work around.
The workaround for this issue was to replace heavily scripted assets. I had some beta Amtrak passenger coaches that brought the whole route down with similar-looking issues.

When I first saw this in SP6, I initially thought it was a script issue. It turns out I was off base but the memory issue is similar.
 
Shifting Roadbed
What you are seeing looks, to me, to be a PBR texture effect. That effect (and others) has been around since PBR ground textures were introduced in TRS19. It is not unique to Trainz as other sims and games that use PBR ground textures also suffer the same effects. The ground texture shown in the track close-up at about the half way point of the video looks like it is a PBR.

My theory at least.

See the Trainz Wiki at How_to_Use_S20_Tools#Using_PBR_Textures for a more detailed explanation and suggested remedies.
 
Last edited:
What you are seeing looks, to me, to be a PBR texture effect. That effect (and others) has been around since PBR ground textures were introduced in TRS19. It is not unique to Trainz as other sims and games that use PBR ground textures also suffer the same effects. The ground texture shown in the track close-up at about the half way point of the video looks to be a PBR.

My theory at least.

See the Trainz Wiki at How_to_Use_S20_Tools#Using_PBR_Textures for a more detailed explanation and suggested remedies.

Yes, the ballast is a PBR texture, one from JohnnyC1. The point is, it didn’t do this in SP5. If it had, I wouldn’t have spent months texturing the track.

Thanks for the link. I guess I’ll just flatten everything. Did look good in SP5. Actually, the CPR didn’t invest the time or money to initially ballast the track as they were rapidly going broke. So, without ballast up to the tops of the ties it could still be considered prototypical.

Cayden
 
Last edited:
Wow, what kind of update is this?

My route Midwestern Rails ran smooth in SP5 but in SP6, its a slide show no matter where I go.
I'm not going to fix it - this is on N3V to fix their code to make performance better.

Not to forget that now the builtin assets <kuid2:45324:90101:4> dash2 cab mechanism and <kuid:-25:1304> SW1500 Cab Generic - legacy update causes the red error bug to appear for all locomotives that uses this item. This has already been bug reported.
At the end, not a happy route builder.

At this point, Trainz should be open source and let us code the way how we want it while N3V has a commercial version like how other open source providers do it.

Cheers
 
Last edited:
The point is, it didn’t do this in SP5
I have seen far worse in all versions and SP updates since PBR was introduced in TRS19. SP6 has been no different. I am not complaining since PBR ground textures, even with these issues, are a huge improvement over non-PBR textures. You just have to know how to deal with the issues.
 
My route Midwestern Rails ran smooth in SP5 but in SP6, its a slide show no matter where I go.
I'm not going to fix it - this is on N3V to fix their code to make performance better.
As a test I just merged my two largest routes into a 400+MB monster ("monster" by my standards) and I am seeing a noticeable drop in the FPS, particularly in asset rich (i.e. built up urban) areas. The two separate routes (210MB and 195MB) work perfectly without any issues in SP6.

I always take a minimalist approach to asset selection (e.g. no tree splines or billboard trees, lots of LoRes assets at distances from the track, using assets with LOD data where they were suitable and available, etc) so there is little further pruning that I could do.

I will join you in waiting to see what develops with the next update or TRS26 (whichever is first).
 
It is not unplayable for me or for a growing number of other posters in this thread.
It seems we can add you to the 'growing number' of posters in this thread that now have issues! Even if you refuse to ever call them out on it.

Reading the post it seems that
(a) there is NO NEW MEMORY LIMIT being imposed (and I could not find any references to any OLD memory limits imposed by the program either), and
(b) the suggestion was made in reference to the available memory in a particular users system (i.e. a hardware and/or a Windows issue).
Whether there is some new memory limit or not, something they changed is irrefutably affecting (larger?) routes. No, I imagine there wasn't any limit before, hence if there is some kind of one now, what would that make it? It could also very well just be the typical botched coding.

Yes, there could have been something misinterpreted and they meant hardware limits instead, most likely tied to the GPU's VRAM as opposed to system RAM (I can place hundreds of third-party payware rolling stock on a detailed route at max settings without hitting 16GB of RAM, widely considered the bare minimum these days). That doesn't change the fact that if things were working fine in SP5 and don't in SP6 that the hardware isn't the problem.

Either way, the main point is how are we to know? It's been a week now and not a whisper from N3V. No, they don't tend to communicate much here outside of their occasional "We are going to communicate with our userbase now" that might last a couple of weeks before the crickets return, but there is no chance they haven't seen any of these responses on their own release thread.
 
I guess I won't install the update then for now. If it makes track splines disappear on high poly tracks and causes large routes to become unstable, then I don't want it. The issue is though that there will be routes created in the new build that probably won't work in SP5. Oh, well, I can live without those routes if it means a more stable game. I have two large routes I was working on, eastern PA and NJ using Reading and Northern 2020 route and NS Reading Line which I was improving with updated track, roads, and other things. I had raised the height of it in TransDEM which I don't have access to right now. The height raise/lower feature is gone now. And blank DEM to Bound Brook, NJ and north to past Mehoopany, PA on Reading and Northern which is a different operator past Mehoopany. The other route is Binghamton, NY through Port Jervis to Suffern and eventually Hoboken using blank DEM and blank baseboards like between south of Mahwah, NJ to near Hoboken. For those that installed it you might have to install a new version of 22 but don't update past SP5.
 
Aren't Service Packs supposed to be "Beta tested" out in the real world, before release??? My experience, is similar to some others here in the forum!!!

New large detailed route I'm helping to Beta test. (700+megs). Seems to go reasonably well in TS2022 SP5 129876. (very few high poly assets have been used in this route). It's simply unplayable in SP6.

My own 3 x merged routes into one (700megs) with some area's that are highly detailed, with lots of hi-poly content, doesn't even fully render. 10% to 20% of the content don't even appear. (I have a reasonably high end gaming computer, with a 4090 video card).
I first thought I must have stuffed something up in the SP6 service pack install. Reading some of the posts here, confirms that I'm not the only one that is experiencing some issues/problems with SP6.

The answer is quite simple for me!!! Put my TS2022 SP6 folder aside. Go back and use my TS2022 SP5 129876 install, until a "hotfix" is available for SP6 version.
That way, I'll be able to keep on trucking...

Happy trainzing all. Cheers, Mac...
 
Same here, performance is abysmal and it's pissing me off. The amount of bugs and other nonsensical whatnot have also angered me quite a bit. I don't know if N3V is going to fix this but I don't think I have hope that they will fix it but if it does then hallelujah.
 
Back
Top