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
