With 2019 I am seeing trees grow from KB to up to 20MB. I am assuming that is 20MB per tree as put down on the route? Or does it use the same 20MB in multiple places? I am concerned with placing a mountainside full of these trees on a route and bringing the whole thing to a stop... How are the megabytes of tree assets accounted for once I get into driver mode?
Quick question on trees
- Thread starter Forester1
- Start date
The larger content size is due to LOD, multiple textures, and other stuff. This is the same with all other content.
The trees themselves aren't really on the route. They are referenced in the map.obs file (objects file), but exist in their own content folders elsewhere in your Trainz content on disk.
The trees, or any object for that matter, gets loaded into memory and graphics memory. Once loaded there should be little impact in TRS2019. This wasn't always the case with TS12 and below. Since content is cached by the system, if you use more than one of the same tree, such as in a pine forest, you'll have only one "real" tree loaded and the others are referenced in memory off of that tree. These other trees are called instance objects in the 3d modeling and animation world.
Back in another life way back in 1995, I worked for a training company that specialized in plastics manufacturing. I worked with the 3d modeler and we built the animated scenes and training program products. There was one particular introduction showing a room full of highly detailed injection molding machines. In that scene was only one "real" model. All the others were instance objects. If the modeler had loaded up a room full of actual models, the computer couldn't render the animation due to the amount of processing power needed to animate each and every machine. Only one machine was animated physically using the same kinds of things we do for locomotives and other animated assets. The instance objects followed along and performed the same animation at the same time because they were linked to the main object.
Keeping that in mind. You'll find you'll have better performance using a single tree or a small number of trees for the forest rather than a huge amount of different trees. This holds true for towns, cities, and other places where there's lots of repetitive objects. When building a town, I will put various detailed objects near the tracks, but in those locations away from the tracks, I will use the same object to fill in. This reduces memory overall.
Hope this explains it.
The trees themselves aren't really on the route. They are referenced in the map.obs file (objects file), but exist in their own content folders elsewhere in your Trainz content on disk.
The trees, or any object for that matter, gets loaded into memory and graphics memory. Once loaded there should be little impact in TRS2019. This wasn't always the case with TS12 and below. Since content is cached by the system, if you use more than one of the same tree, such as in a pine forest, you'll have only one "real" tree loaded and the others are referenced in memory off of that tree. These other trees are called instance objects in the 3d modeling and animation world.
Back in another life way back in 1995, I worked for a training company that specialized in plastics manufacturing. I worked with the 3d modeler and we built the animated scenes and training program products. There was one particular introduction showing a room full of highly detailed injection molding machines. In that scene was only one "real" model. All the others were instance objects. If the modeler had loaded up a room full of actual models, the computer couldn't render the animation due to the amount of processing power needed to animate each and every machine. Only one machine was animated physically using the same kinds of things we do for locomotives and other animated assets. The instance objects followed along and performed the same animation at the same time because they were linked to the main object.
Keeping that in mind. You'll find you'll have better performance using a single tree or a small number of trees for the forest rather than a huge amount of different trees. This holds true for towns, cities, and other places where there's lots of repetitive objects. When building a town, I will put various detailed objects near the tracks, but in those locations away from the tracks, I will use the same object to fill in. This reduces memory overall.
Hope this explains it.
Yes John, that helps a lot. Sadly some of the older 2.9 trees in smaller files that used to look great are turning transparent in 2019, so I am forced to the newer, larger versions. Only slightly off topic, but are the way-too-common spiky, dead looking branches an artifact of not matching the leaves up with the branches, or are they deliberate designs? It is often hard to find a tree that doesn't look like that. Or have cut tops, or cut branch stobs like no one would ever prune like that.... 
Dinorius_Redundicus
kuid 68213
Yes John, that helps a lot. Sadly some of the older 2.9 trees in smaller files that used to look great are turning transparent in 2019, so I am forced to the newer, larger versions. Only slightly off topic, but are the way-too-common spiky, dead looking branches an artifact of not matching the leaves up with the branches, or are they deliberate designs? It is often hard to find a tree that doesn't look like that. Or have cut tops, or cut branch stubs like no one would ever prune like that....
Seasonal effect maybe? You might have your environment set at a winter month. This is when some trees become bare (and is nothing to do with snow, which is not a season, or at least not supposed to be).
Last edited:
That will do it. I generally keep my routes to June thru August because I prefer the warmer months to begin with and want to avoid spikey branches.
Great explanation John, and as a hobby programmer I should have known that
back to the learning curve for me!I don't think it is seasonal. An example are the trees by dmdrake. Just looking at them in Open-Preview Asset in CM. Unfortunately, my EDBR is extra "E" this time around. Will post a screenshot when I can...
Edit: Sorry, that was about Transparency, but no, the spiky branches aren't seasonal either I don't think. Same thing. CM Open-Preview Asset and rotate the view around. Will post screenshots when I can...
Edit: Sorry, that was about Transparency, but no, the spiky branches aren't seasonal either I don't think. Same thing. CM Open-Preview Asset and rotate the view around. Will post screenshots when I can...
Last edited:
Dave's trees suffer from another ill related to alpha-blending. I can't remember if there's a fix for that or not.
The spikey trunks and branches. Yeah post a pic when you can. Some trees are made better than others, authors not mentioned so not to cause hurt feelings, but winter and season do cause spikey branches. The issue could be region causing this. You may have a "summer" month selected on the calendar, but the region is pointing south of the equator. This will cause the trees to show bare trees in June through August. I ran into this not too long ago and it took me a little bit to find what the problem was, but it made sense afterwards.
Dinorius_Redundicus
kuid 68213
It’s very easy to see if an asset is seasonal or not. Open its config file and if it has a season-selector container, it’s seasonal.
The spikey trees suggests those poorly-made speedtrees that Auran foisted on us at one stage, but that’s a guess. Why don’t you quote a few kuid numbers so anyone can check?
The spikey trees suggests those poorly-made speedtrees that Auran foisted on us at one stage, but that’s a guess. Why don’t you quote a few kuid numbers so anyone can check?
The issue with older trees is that the creators broke the rules as it concerned transparency in the old Auran Jet game engine.
That engine supported 256 levels of transparency primarily for glass surfaces like windows. For all other objects, you were suppose to stick to 1 bit alpha maps (black and white) for transparency. Old style billboard trees are made using several planes onto which you mapped your tree image. To make the background of that image invisible, you used a black and white alpha map with the shape of the tree in white and the background in black. The game engine just displayed the tree image. These trees worked but did not look great as there was a clear edge to the tree image.
Dave and others discovered that you could use gray-scale alpha maps to feather out the edge and the appearance of the tree improved greatly but at a cost of performance. With a 1 bit alpha map, the game engine had to calculate just once to determine if the player's POV showed tree or what was behind the tree. With a grey-scale alpha map of say 16 shades of grey, the game engine had to make 16 calculations to determine whether the player's POV was seeing tree, background behind the tree or some mixture of both. So 100 of Dave's trees performed like 1600 trees.
TS2009 or TS2010 introduced Native mode and compatibility mode where the player could choose between having those assets bog down the engine or not. Native mode was much faster but the trees had a ghost like appearance. Compatibility mode behaved just like before. Finally TS12 did away with compatibility mode.
Now in TS12 you could somewhat fix Dave's trees by opening for edit and converting the alpha map image to just black and white. The ghost like appearance disappeared but the trees again had a hard edge. I tried this for a tree in TRS19 and I couldn't get it to commit properly. I assume that the new E2 engine has different requirements for alpha maps.
William
That engine supported 256 levels of transparency primarily for glass surfaces like windows. For all other objects, you were suppose to stick to 1 bit alpha maps (black and white) for transparency. Old style billboard trees are made using several planes onto which you mapped your tree image. To make the background of that image invisible, you used a black and white alpha map with the shape of the tree in white and the background in black. The game engine just displayed the tree image. These trees worked but did not look great as there was a clear edge to the tree image.
Dave and others discovered that you could use gray-scale alpha maps to feather out the edge and the appearance of the tree improved greatly but at a cost of performance. With a 1 bit alpha map, the game engine had to calculate just once to determine if the player's POV showed tree or what was behind the tree. With a grey-scale alpha map of say 16 shades of grey, the game engine had to make 16 calculations to determine whether the player's POV was seeing tree, background behind the tree or some mixture of both. So 100 of Dave's trees performed like 1600 trees.
TS2009 or TS2010 introduced Native mode and compatibility mode where the player could choose between having those assets bog down the engine or not. Native mode was much faster but the trees had a ghost like appearance. Compatibility mode behaved just like before. Finally TS12 did away with compatibility mode.
Now in TS12 you could somewhat fix Dave's trees by opening for edit and converting the alpha map image to just black and white. The ghost like appearance disappeared but the trees again had a hard edge. I tried this for a tree in TRS19 and I couldn't get it to commit properly. I assume that the new E2 engine has different requirements for alpha maps.
William
Thanks for that Wreeder. That helps my understanding a lot. I don't want to post KUIDs with authors (unless they are Auran ), so maybe a few pics when I get done working today. What Dinorius says may well be what I am seeing, but I think others have that as well. I must say Auran's are sometimes atrocious! I found just ONE Jeffrey Pine, and it was a twisted, distorted mess looking more like a bristlecone up on the mountaintops. And the only Douglas firs looked horrible. Fortunately I got clued in by Funnnyfarm's Great Northern Scenic route that the Hemlocks are decent substitutes.
), so maybe a few pics when I get done working today. What Dinorius says may well be what I am seeing, but I think others have that as well. I must say Auran's are sometimes atrocious! I found just ONE Jeffrey Pine, and it was a twisted, distorted mess looking more like a bristlecone up on the mountaintops. And the only Douglas firs looked horrible. Fortunately I got clued in by Funnnyfarm's Great Northern Scenic route that the Hemlocks are decent substitutes.Take a look at RMM's conifers.
Elka = Spruce that look like Christmas trees.
Sosna = Pine trees such as log poles and pitch pines.
If you have Roy's routes, check out his spruce trees. They're pretty nice as well.
I agree N3V's have a lot to be desired except for perhaps a handful. We have to keep in mind that someone made the trees for them and they don't make the content themselves. Who made it, who knows.
Elka = Spruce that look like Christmas trees.
Sosna = Pine trees such as log poles and pitch pines.
If you have Roy's routes, check out his spruce trees. They're pretty nice as well.
I agree N3V's have a lot to be desired except for perhaps a handful. We have to keep in mind that someone made the trees for them and they don't make the content themselves. Who made it, who knows.