Article: Content creation for Trainz: A New Era

Don't push the envelope too hard

The community occasionally surprises us with content that pushes hard at the boundaries of what is possible in Trainz to achieve something that isn't officially supported. Unfortunately, Trainz history shows that some of these assets turn out to be incompatible with future Trainz versions. So as tempting as it is to push the boundaries and try to get the absolute most functionality possible, if your aim is to have as smooth a transition to E2 as possible, you might want to build content with a more conservative feature set, and avoid some of the more advanced community-developed features.

On the contrary: Push the envelope as hard and as often as you can! This is the way to get humanity to the stars a few centuries from now. If Auran want to stay behind on an overcrowded planet with dwindling resources, let that be their choice.

If something gets left behind that is the price of progress.

Might I express the view that a new game engine is an opportunity to get rid of some of the bottlenecks that hold us back, the performance penalty that goes with texture-replacement on the fly is one matter that springs to mind but there are others no doubt.
 
Last edited:
On the contrary: Push the envelope as hard and as often as you can! This is the way to get humanity to the stars a few centuries from now. If Auran want to stay behind on an overcrowded planet with dwindling resources, let that be their choice.
I think that someone must be putting something in the water at the moment.

A comment that relates strictly to content making in Trainz is taken as a philosophical position. More teasers Tony, the natives are getting restless and a little overwrought.

A little further thought and I've realised that maybe I'm wrong. Perhaps humanity will have future spacecraft powered by the Jet engine?
 
Last edited:
All good points, but I'm a bit concerned about the potential for massive filesizes if each asset uses .m.tbumpenv materials, or even just normal maps.

Consider a building with a typical 1024 x 1024 32-bit tga image (which is what I find is required for sharp resolution on many assets of that size). It's about 4MB. Add another 4 MB for the 32-bit normal map tga needed to complete the m.tbumpenv material. That's now 8 MB. Then double that to 16 MB if the asset has seasonal snow textures (I hardly consider snow as "pushing the envelope" these days).

Trainzdev, can you comment or offer us and our long-suffering hard drives some hope that N3V will address this issue by the time the New Era begins?
 
I do wonder why our creators have been told not to push the envelope? It suggests to me that the new engine has lower limits. I had assumed that those limits were further away not nearer, so pushing the limits with what we have now should be easily accomplished with the new engine. But Im sure our creators or N3V will tell me if I have the wrong idea?
 
I do wonder why our creators have been told not to push the envelope? It suggests to me that the new engine has lower limits. I had assumed that those limits were further away not nearer, so pushing the limits with what we have now should be easily accomplished with the new engine. But Im sure our creators or N3V will tell me if I have the wrong idea?

What James is referring to here is content creators trying to fit a square peg in a round hole. He will have a dozen examples (I might think of one shortly) where a "solution" has been found to an issue by utlizing a bug, and then with the next update, the bug is fixed and the "feature" no longer works.

So he is saying "follow the guidelines" and if you want to do something "a bit different", ask questions and think about the ramifications before rushing off creating a brand new "feature".

Regarding texture sizes, modern hardware has GB of memory and TB of storage. The E2 engine is specifically designed to handle larger textures and deal with a larger memory footprint (which is the biggest advantage of going to 64 bit).
 
What James is referring to here is content creators trying to fit a square peg in a round hole. He will have a dozen examples (I might think of one shortly) where a "solution" has been found to an issue by utlizing a bug, and then with the next update, the bug is fixed and the "feature" no longer works.
Didn't Mike10 have animated points way back when that relied on an 'undocumented feature'?
 
Hi Deane
All content, unless it absolutely does not need one, should have a normals map. Snow textures even more so, so as to give 'depth' to a simple snow mesh :)

Normals maps perform more than adding 'bumps' to a flat surface. They can also be used to make an object look more round than it is. They can also help to make that textured detail 'pop' in the right lighting (much like any real surface :) ). For example, rust can be given a rough texture in the normals map, but under just ambient light it'll look flatter.

Add to this that any object with a normals map should have a specular map. A specular map is more than just 'make the shadows less shiny'. You can use it to help those normals mapped textured 'pop' even more. Or less, it's up to you. For example, a weathered timber building with bits of paint on it. The paint will be more glossy than the timber, so a specular map lets you do this. How much work you put in is up to you. The more you put in, the better the result. On the other hand, a basic specular map may be all that's needed. This only adds a small amount more to the file size of the normals map texture (the specular map should go into the alpha channel of the .tga file for the normals map).

If you don't need transparency on your object, then using tbumpenv isn't going to have much impact on top of the above. It only adds a small amount to include the 'env' map in the alpha channel of your diffuse texture, and it doesn't have a huge impact on performance compared to tbumptex. However, it will help the object as it captures the environmental lighting much better than other materials.

For snow, having that bit of sky gloss may even be beneficial :)

Oh and it's great for windows. Take a look at the VR lamp hut I've got on the DLS. I've increased the intensity of the tbumpenv reflection in the sky parts of the window textures, so the sky actually looks (to some degree) like the sky on the route. :)

Regards
 
Regarding texture sizes, modern hardware has GB of memory and TB of storage. The E2 engine is specifically designed to handle larger textures and deal with a larger memory footprint (which is the biggest advantage of going to 64 bit).

No doubt memory is no problem, even now, but won't the huge files just lead to very sluggish load times and hence even more of the stuttering which has become a Trainz hallmark? Or will SSD's be the minimum recommended storage device?
 
All content, unless it absolutely does not need one, should have a normals map. Snow textures even more so, so as to give 'depth' to a simple snow mesh :)

That's fine for snow textures, ballast textures and any other texture that are normally seen at such a close distance to see the difference.

I wonder, however, is the use of normal maps really efficient for ground textures designed for use at great distances (e.g. to texture a hill 500 metres away from the rails)? In this case, adding a normal map isn't a waste of resources?

TS12+SP1 reports warnings for ground textures lacking a normal map, and all we know that the warnings of today are tomorrow's errors.
 
So all these underlying textures I see popping in and out are a desired feature?
Not for me, thanks!

Chris.
 
So all these underlying textures I see popping in and out are a desired feature?
Not for me, thanks!

Chris.

So comparing old with the new that we have not yet seen is the ' new normal ' for decision making.

way to be a fool sunshine.
 
What James is referring to here is content creators trying to fit a square peg in a round hole. He will have a dozen examples (I might think of one shortly) where a "solution" has been found to an issue by utlizing a bug, and then with the next update, the bug is fixed and the "feature" no longer works.
Some examples are: Animated junctions, one way traffic on roads, applying texture replacement to alter vehicle liveries, nightmode on road traffic, traffic lights. Yes, some of these use undocumented features and some of them fail to work in the next release - as I said this is the price of progress. But they do keep you guys on your toes and in many instances you respond by adding the facility in native code. If the boundaries never get probed then the demand for things like this will never arise.

So he is saying "follow the guidelines" and if you want to do something "a bit different", ask questions and think about the ramifications before rushing off creating a brand new "feature".
This wouldn't ring quite so hollow if some of your staff, Chris in particular, were a little more forthcoming in answering those questions when asked. If we look at your 4 optional Kickstarter features for instance, I've had at least partial implementations of items 1 and 4 sitting on my hard drive for months waiting for a response from your team and a fix to a bug which was supposed to have been repaired in the last hotfix.

Regarding texture sizes, modern hardware has GB of memory and TB of storage. The E2 engine is specifically designed to handle larger textures and deal with a larger memory footprint (which is the biggest advantage of going to 64 bit).
All this is probably true but you do have a tendency to assume that large textures and multiple maps automatically improve asset quality. This is far from being the case - a good small texture in the right hands can knock the socks off a 50mB file wielded with inadequate skill.

You should also be looking at the implications of having gigabytes of this stuff which many of us will never use bloating our installations. Many of us have relatively small SSD devices as C drives and I would quite like to put the TRS binaries on there.
 
Looking forward to reading the new T:ANE version of CCG where all these neat features are clearly explained with examples.
 
Looking forward to reading the new T:ANE version of CCG where all these neat features are clearly explained with examples.

Yeah, if this is going to be the same ' secret squirrel ' approach to giving info that the other guys use I'll not waste my time.

Tony .. utilize the community to move the game forward.
 
Think of the new graphics engine (E2) like your car. If your car currently won't start on a cold morning or leaks oil on your garage floor, you would expect replacing the old engine with a new one, your car will start without a problem and leave the floor nice and clean.

Regarding "secrets" I can assure you it has not been our conscious intention in the past. However, our approach for T2 will be to explain more, and involve the community more from the very beginning - as you will see in a few short days with our project on Kickstarter.
 
Think of the new graphics engine (E2) like your car. If your car currently won't start on a cold morning or leaks oil on your garage floor, you would expect replacing the old engine with a new one, your car will start without a problem and leave the floor nice and clean.

Regarding "secrets" I can assure you it has not been our conscious intention in the past. However, our approach for T2 will be to explain more, and involve the community more from the very beginning - as you will see in a few short days with our project on Kickstarter.
That only works well if the new car uses a normal key and has the keyhole in a standard location. If it is a keyless entry and you don't know the code, you'll have a had time starting in the morning.
 
All good points, but I'm a bit concerned about the potential for massive filesizes if each asset uses .m.tbumpenv materials, or even just normal maps.

Consider a building with a typical 1024 x 1024 32-bit tga image (which is what I find is required for sharp resolution on many assets of that size). It's about 4MB. Add another 4 MB for the 32-bit normal map tga needed to complete the m.tbumpenv material. That's now 8 MB. Then double that to 16 MB if the asset has seasonal snow textures (I hardly consider snow as "pushing the envelope" these days).

Trainzdev, can you comment or offer us and our long-suffering hard drives some hope that N3V will address this issue by the time the New Era begins?

Yes, but, does your color map always need to be so large ?, is it required to be the size as your normal and spec ? why use a 1 or 2k color map if a 512x512 will suffice and you use the channels wisely.
 
Back
Top