The most "harmful" assets

[Dinorius_Redundicus]

If you were asked to identify the technically "most harmful" asset on the Download Station without actually downloading and examining every asset, how would you do it?

It seems to me that the definition of "most harmful" would be some product of how inefficient the asset is AND how many downloads it has accumulated. This would estimate the overall load an asset has placed on the community, not just on an individual user.

Inefficiency

This is usually related to a combination of high poly count (without LOD) and/or a high number of separate texture materials (or more accurately, draw calls). Would asset File Size (as listed in CM) serve as an approximation of those two factors? If so, it could provide a quick way to get a short-list of the potentially worst culprits for closer examination. It might be especially apt for pre-TANE assets which did not have mandatory LOD requirements and were more likely to use simple m.onetex materials.

Downloads

This is more problematic. CM gives no information on the number of downloads. The DLS website does state the downloads, but it requires looking at each asset individually. Is there an N3V database listing kuids against download numbers that could be made accessible? If not, the best I can think of is to filter first by File Size (proxy for "inefficiency"), get a short-list of the worst assets and then examine each one of those on the DLS website to get download numbers.

Why do I ask?

If I could rank my own assets by how "harmful" they have been, then I could prioritize which ones to revisit and improve.

I also get requests to create and issue versions of other creators' assets under my own kuids (often to fix mesh or poly-count issues and/or to improve appearance). I have only done this on a few occasions, and only when I can cite clear permission from the original creators. Rather than wait and rely on requests for things, I could perhaps do the community more good by identifying the most popular/inefficient assets and issue improved versions of those (if permitted). They would not obsolete the originals, but they can be used to replace them.


.

 

[grazlash]

You could also trawl the forums for information on inefficient assets. I have heard mention of a "big blue crane" that could bring a computer to its knees, but these days with powerful CPU and GPU combos and RAM being relatively inexpensive, performance seems to overcome inefficiency obstacles.
I don't follow how the number of downloads matters, unless it's to count the poor mugs caught out by such assets. Most would likely have been downloaded as dependencies of a route anyway.
File size has grown recently with the introduction of PBR textured assets, so that too may be unreliable.
cheers
Graeme

 

[frogpipe]

I wish you luck.

Old assets are probably one of the biggest issues in this game. I was dearly hoping that TANE was going to break the chain on old assets - or at least include an option that had to be explicitely turned on to have old assets load after watching version after version made to look like outdated trash by primitive assets.

To be clear, many of these assets were perfectly fine for their time. But now look like putting the original Lara Croft model into a 21st century game. Unless its a game meant to look like minecraft, its a bad thing.

And that's just asthetics, nevermind performance.

But N3V themselves packed in routes, then and now, that use assets that aren't up to modern standards - because cutting out the old would leave them with very little to work with.

 

[JackDownUnder]

The pbr series, I do not use them and try to avoid them anymore as they appear to change the ground level.

 

[pware]

The pbr series, I do not use them and try to avoid them anymore as they appear to change the ground level.

That viewpoint illustrates the problem of defining the term "most harmful".

In my case I now use nothing but PBR textures in my routes and will never go back to using the old 2D (non-PBR) textures.

The term "Most Harmful" is very subjective and will vary considerably between individuals.

 

[grazlash]

The pbr series, I do not use them and try to avoid them anymore as they appear to change the ground level.

The ground level appears to change due to the height mapping of the textures. They should not be mixed with standard old style texture unless it is away from roads and tracks.
JohnnyC1 makes a huge variety of height mapped textures, enough to satisfy even the most hardcore route builders and look much better than the older style ones.
One of the bigger problems, which has yet to be rectified, is that N3V added height mapping to a range of old TS12 textures and failed to give them an entirely new KUID and just upversioned them, causing height problems on older routes which used them.

 

[H222]

Most assets by MSGSapper, even ones with LOD, are incredibly poor performing. 100k polys for objects smaller than a 20ft container, many times with no LOD at all. These are my most harmful assets and I try and steer clear of his stuff when possible. It's a shame you have to go through every asset in Preview Asset and see the damage of it just because of the nature of high poly stuff he imports in game. Many of these assets aren't designed for game use at all.

 

[pware]

I don't think that it is a good idea to "name and shame" individuals in this. I have over 600 of his assets, most of them came as "Packaged" from DLC routes or "Installed from DLS" by way of other routes. I regularly use some in my routes and all are small (in terms of file size and polycounts or triangles), they cause no issues.

The lack of LOD is true of many assets from many creators.

I am careful in choosing my scenery assets - I try to avoid those that have huge file sizes (100MB+) unless I consider them to be "worthy" and even then I only use 1 or 2 per route. The vast majority that I use are less than 1MB in size.

My thoughts.

 

[Dinorius_Redundicus]

I don't follow how the number of downloads matters.......Most would likely have been downloaded as dependencies of a route anyway.

cheers
Graeme

It's pretty simple logic really.

The poly- and texture metrics of an asset might be absolutely terrible, but if it has only been downloaded 3 times in its entire history on the DLS, then it's hardly worth the effort to fix because it's not affecting many Trainzers. Conversely, if an asset with moderately bad metrics has been downloaded 150,000 times, then overall it could be causing a lot of harm. So download popularity is quite a major factor in the ranking calculation.

If downloads are the result of an asset being a dependency in many routes (as opposed to just sitting unused in peoples' databases) then that would actually be a good reason to provide a more efficient and possibly better-looking alternative rendition of the asset. However, it's hard to know since all we have is the download number.

The pbr series, I do not use them and try to avoid them anymore as they appear to change the ground level.

I should emphasise that I'm only referring to mesh-based assets, not ground textures etc.

The term "Most Harmful" is very subjective and will vary considerably between individuals.

Agreed, which is why I tried to explain what my definition is in the opening post and why I would like to quantify it to remove subjectivity as much as possible.

I don't think that it is a good idea to "name and shame" individuals in this.

Also agreed. It's not the purpose of this thread. In reality, very few assets could end up being re-constructed (a) because it's exhausting work and (b) it requires very open permission from the original creators, so there is little point in picking on individuals anyway.


.

 

[MSGSapper]

Most assets by MSGSapper, even ones with LOD, are incredibly poor performing. 100k polys for objects smaller than a 20ft container, many times with no LOD at all. These are my most harmful assets and I try and steer clear of his stuff when possible. It's a shame you have to go through every asset in Preview Asset and see the damage of it just because of the nature of high poly stuff he imports in game. Many of these assets aren't designed for game use at all.

I have never said that I create content for low end systems, and I have been very open about that over the years. I create more for the medium to high end systems and users wanting some of the most realistic looking assets available. Realism often comes at a steep price in polys, even with LOD0 to LOD4 implemented. I have also said many times over the years that I primarily create content for my own routes but choose to share the routes and the content on the DLS for others to enjoy, if they can. Keep in mind that I also have chosen to make everything freeware to everyone even though it has cost me substantial money, well over $4500 to date and counting, to purchase these assets, and this doesn't count all the time and effort I have to put in to get these assets to work, look and function right in Trainz. I don't get much thanks for this however. Of course the alternative is that I keep the content and my routes only on my own computer system and never share them with others, which means no one but me gets to enjoy them. Is that what you want?

Personally I hate LOD which causes me a lot more work and slows my rate of production greatly. The only I reason I do LOD is to allow more people to enjoy my assets then would be able to do so otherwise.

On my system, where I create and test my Trainz content, all my assets work just fine. I guess it all comes down to the technical capability of each persons individual computer system. On my part I have a high end system which includes an ASUS NVIDIA GeForce RTX 3080 Noctua Edition Graphics Card, a 64GB ROG Maximus XIII Hero motherboard and a Samsung 870 EVO 4TB SSD among other things.

On each of my uploaded assets to the DLS I try to ensure that I provide Poly counts so the user can judge if their system can handle the asset or not. On really high poly items I tend to keep transition distances shorter to keep graphic card loads manageable. For people with low end systems there are still a lot of ways to tweak your Trainz and your routes to run PBR Based assets and high polys items. Some examples, of many, that come to mind:

1. Just use a few high poly assets and spread them out. One really realistic item in a scene can often make the difference to the railroad scene on a route.

2. Decrease the Shadow Quality setting to low or none. This alone can make a big difference for the graphically card challenged user.

3. Decrease the Maximum Draw Distance from 3000 meters to 2500 or less.

4. Decrease the Scenery Detail setting.

5. Uncheck the Process Objects Behind Camera setting.

The problem in creating content for Trainz is that the computer user base ranges from the very high end system to the very low end system. This makes it very challenging for content developers. Designing for the low end user only essentially means penalizing high end users who can use much better and much more realistic looking assets, something I am not willing to do. While I am sorry that low end users can't afford better computer hardware, in the end that is not my problem. The low end user will just have to pass on my items until such time as they can afford a better system.

Bob

 

[G.M.]

Most Harmful (suspicious/filtered out here):
-Huge total filesize, everything has to be (down)loaded once before you see or hear it
-Assets made by SketchUp /RubyTMX, not always but often inefficient, many drawcalls
-Any asset with PBR in the name, 3 textures used where 1 will suffice
-Any asset (not being a route/seesion) with build 4.7 or higher
means the creator does not understand that 4.6 is the highest you ever need to use


-"updated" assets that suddenly are more than 2x the size
-Assets with huge libraries (although using a library is not bad)
-Assets with sound files, the current trainz takes a framerate hit when sounds are used
-Assets with huge complex scripts (how much script does a wagon in the middle of a train need?)
-Assets with lots of polies but no LODs or wrong LODs (even LOD swapping uses PC power)
-Assets with .Trainzmesh, there is no good viewer or editor, so not easy to repair
-Assets with 2k or 4k textures, often the creator does not know how to UVunwrap efficiently


All these things do not matter if you want to make a 1 baseboard, screenshot route
but when you want to make a full size route, it will matter.
Less is more and KISS greetings GM

 

[BraselC5048]

How about simply "anything made in sketchup?" I've converted a lot of sketchup files into Trainz assets, by importing them into blender and reducing their poly count, and to start with in sketchup every face is doubled, everything round is 24 sided, and things are made in a horribly inefficient manner.

 

[TomasJ002]

Most Harmful (suspicious/filtered out here):
-Huge total filesize, everything has to be (down)loaded once before you see or hear it
-Assets made by SketchUp /RubyTMX, not always but often inefficient, many drawcalls
-Any asset with PBR in the name, 3 textures used where 1 will suffice
-Any asset (not being a route/seesion) with build 4.7 or higher
means the creator does not understand that 4.6 is the highest you ever need to use


-"updated" assets that suddenly are more than 2x the size
-Assets with huge libraries (although using a library is not bad)
-Assets with sound files, the current trainz takes a framerate hit when sounds are used
-Assets with huge complex scripts (how much script does a wagon in the middle of a train need?)
-Assets with lots of polies but no LODs or wrong LODs (even LOD swapping uses PC power)
-Assets with .Trainzmesh, there is no good viewer or editor, so not easy to repair
-Assets with 2k or 4k textures, often the creator does not know how to UVunwrap efficiently


All these things do not matter if you want to make a 1 baseboard, screenshot route
but when you want to make a full size route, it will matter.
Less is more and KISS greetings GM

Your problem is that our assets don´t work in your little TS2009 bubble, not the harmfull assets. Fix your title and Realize that it is not 2011 anymore bestie. Have a nice day getting angry about modern stuff on a virtual forum.

 

[JCitron]

I remember when TANE came out that some assets were outright rejected and wouldn't load due to high poly counts. Among the many models was a Smart Car and some other vehicles with 100K polys, and TANE rejected them. I would say these models are bit on the heavy side, ya think! Recently, I did a fresh install and reimported content and TRS22-Plus did exactly the same thing with some of the assets I had tucked away. Since I hadn't used them in ages, I deleted them and will no longer use them.

The problem isn't just the number of polygons. Some assets have way too large textures that take too long to load, while others use double-sided polygons with textures that don't need to be loaded that are, and others are just made inefficiently because of how they were created in the first place. Instead of using an alpha-masked image for railings or filigree on a building, the content creator instead modeled the highly detailed railings and other details. The lack of LOD is detrimental to the overall performance of the program. I know that many content creators don't like implementing LOD, but it is required for the best performance since it allow for less polygons for the same model in the distance. This is best practice regardless of the power of the video card. Future versions of Trainz will make this mandatory if it isn't already, but it would be nice if this was auto generated by the game engine for those models that don't have it. With LOD there's also the advantage of a transition between nothing to the full model instead of assets popping up suddenly.

The problem with the older models beside their lower quality, which was good in their day, is that many models use individual textures instead of UVW maps. These individual textures take time to load since they have to be read individually from disk to memory before being processed by the GPU. This is one of the biggest issues with Sketch-Up models. Instead of the UVW map, each wall is a strip of polygons and textures making the load time worse for even the simplest models. After going through the growing pains of Sketch-Up models, I use them sparingly. Used in lightly, they can fill in a scene nicely but don't go overboard with them. Having said that, I too uploaded a bunch of them to the DLS prior to us learning about their dark side and regret that now.

I too wish we had a way to tell which models to avoid without having to waste time downloading and testing. What I would like to see implemented though is a heat map to display worst performing models on our routes so we can tell where the worst-case performers are located and we can remove them.

 

[Forester1]

ThomasJ002, maybe when you have been here as long as G.M. you will know how to behave in a forum.

 

[Pendolino]

I would be happy enough if harmful assets were flagged in CM with a dedicated warning, so as to be able to replace or delete them.

Some years ago, I was making a session on a route and I noticed the FPS dropped to 5% of the average value in an area of farmland, with a single farmhouse. After a painful search among the route dependencies I found that a car parked near the farmhouse has a huge polycount and countless textures (including a 1024x1024 texture for the speedometer face ). It would be nice to be able to know in advance if an asset is an inefficient one.

 

[Therock]

While I cannot assign weight to how many downloads an asset has in my "harm" gauging, in routes that others have made that I actually use or my own routes I'll enable the surveyor statistics menu and fly around, checking the kuids associated with worst buffer and index counts, then make note of those assets and either replace them or re-optimize them if they aren't obvious offenders, such as a single track asset being the obvious "weak link" in an area with a lot of trackage.

This method only really bears fruit for assets that are already installed though. For anything else that requires I search for new assets on the DLS, I just avoid scenery with what I would deem an unreasonable file size, like the above example of a car asset with large textures wasting memory.

 

[Pendolino]

I'll enable the surveyor statistics menu and fly around, checking the kuids associated with worst buffer and index counts, then make note of those assets and either replace them or re-optimize them

I didn't ever think about this method, thanks for pointing it out!

 

[Piere]

I vaguely recall an idea that was suggested (I can't remember if it was in the context of N3V actually implementing it or not) about how useful it would be if there could be an option in surveyor where the worst performance-impacting assets in a scene could be highlighted, to help make finding them easier.

In the context of Surveyor II, making the outlines of the objects show up in red or orange to show the worst ones would be immensely useful.

Cheers,
Piere.

 

[pware]

In the context of Surveyor II, making the outlines of the objects show up in red or orange to show the worst ones would be immensely useful.

I would agree with that, it would be nice. But setting the selection of what is "worst" to everyone's satisfaction would be nigh on impossible. A poor performing asset on a low end system would not necessarily be a poor performer on a high end system.