The most "harmful" assets

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.
Maybe just highlighting the lowest performing asset would be enough. That would align with a system of any performance.
 
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

To be honest, some of the statements are true but some aren't even proved by facts. Some problems You mentioned are rather creator's choice.
- There's nothing wrong with PBR as long as there are no excessive drawcall counts. M.onetex and m.tbumptex assets can be as toxic as m.pbrmetal ones
- "4.6" is rather creator's choice since they are likely to use new TRS19 versions and they want their content to be used in the same version
- huge libraries may contain tons of files but ironically assets that use large libraries tend to load quicker than the assets that have none of its files in the library
- .trainzmesh? Really? Despite the fact that there's an editor but it is paid. How we - as content creators - can change it if we can't change sources of the game itself.
- 2K textures (4K is pure nonsense atm) aren't bad if used correctly. The worst case can be an asset that doesn't have proper mapping and each wall has a seperate texture.
- At last, there are routes where there's a majority of PBR assets (both objects and ground textures) that perform just as fine as older routes.
However, I do agree that SketchUp assets shouldn't be tolerated. I know it from my experience that they will always perform badly and look awkward in some ways. If we have an opportunity we should teach its users how to use 3DS Max or Blender (GMax isn't the way either)
Now something from me.
Assets that are harmful to performance have:
- no LODs or lazy LODs (aka. LOD0 is a model, LOD1 is nothing)
- excessive number of drawcalls and textures (lack of proper mapping)
- too many alpha textures
- too great texture resolution for the asset that doesnt require hi-res textures
- obsolete configs from times of TS2009 and below
- poorly optimized scripts or even ones that kill the game
Harmful to cosmetics:
- pixelated textures
- weird shading and smoothing
- poor mapping
That's my 2 cents. :)
 
Personally I hate LOD

And therein lies the harmfulness - LOD is a LITERAL industry standard in any and every video game, and potentially the single most important facet in content creation. Without it, you create a screenshot renderer, not a game.

And if I'm lowering my draw distance from 15,000m to 3000m to account for ONE creator's assets? I don't think the game and my settings are the problem in that situation.

-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

G.M., all of these points may have been relevant in the day of 256MB memory but they aren't now. PBR is not some demon, and why would someone with an install of a Trainz build 4.7 backdate their content to 4.6 and not accurately test that that content actually works Seems pretty irresponsible to be suggesting to people to change build numbers to something they can't test. It sounds like you want to use simple pm meshes and 512x512 textures and make a route that would've looked fine in 2004. But most of us don't want that. We want a healthy balance. Scripted rollingstock is bad? ok, lol

And Trainzmesh is not rippable and protects a creator's mesh. I would've thought that's reasonably important to a lot of 3D creators.
 
Last edited:
I vote for the <kuid2:46162:250831:11> HP Intermodal hub as a major contender. It blankets its surroundings and to do much work in its vicinity one must move it to a separate layer and hide it. (It also has too much roadway built in for most use other than the Marias Pass routes, which seem to be its home territory.) At the same time, it is irreplaceable, being the only asset that does what it does (and does it well.)

Many of the large Industrial Buildings have tentacles, too.

:B~)
 
When I designed floor plans for a client I often put in one room that had no door, why?
To see if the client had actually studied the plan I made and start the discussion.


The whole point in this good thread (ty Deane) everything works together in this wonderful game
it is hardly ever about just 1 asset.
Older Content Creators had to struggle with the limitations of then current systems
they learned to have the best results with minimal polies/texture sizes etc.


Now that our PC's are faster, more is possible, but still far from unlimited.
I daily have to repair a lot of content or help people make content,
so see a lot that harms the game and try to point in a more efficient direction.
It is a Simulation, not every nut and bolt has to be there, you just simulate
its not about the software used but how you master it and how you know to limit yourself.


Again on a single baseboard, it does not matter much, but big routes you just need to be
aware what to use and make.


a few tips:
-IrfanView has a property screen that shows how fast a texture loads
-the main screen in TRS19 and up gives a good indication how fast a rolling stock item shows up
-the built-in viewer in CM gives good info about an asset, polies/drawcalls/Lods etc


have fun creating, greetings GM
 
There are assets with scripts that are simply game crippling. N3V has obsoleted the library functions that caused most of the damage so they probably won't work in later versions of Trainz unless you enable compatibility mode. AFAIK, you now cannot upload an asset with those functions used in a script. Some of the changes required to correct those assets need scripters with serious programming experience.

I literally don't understand the opposition to creating LOD meshes. Blender has functionality to reduce mesh sizes automatically so its really not that much work. The only challenge I have is with the lowest LOD where it is ideal to produce a simple boxy like model perhaps with its own simple material.

I doubt if PBR, as used on models such as buildings, locos, etc, is any more of a resource drain given that TS19 and TS22 use some tricks to make the tbump materials act like PBR. Maybe the latter is more resource expensive.

In the last 5 years or so, I believe Blender, and the many texturing tools that support it, have moved somewhat from the artistic side of the community to the gaming industry. An awful lot of tutorial models are based on monsters, game warriors, and hard surface models such as weapons and military equipment. These models are invariably very high poly, use multiple materials per model, and often with 4K textures. But there are retopology tools to reduce those models to gaming sizes.

Perhaps it is time for N3V to introduce some kind of config tag that warns a potential downloader that this is a "high end" model and probably needs a decent computer to use it.
 
Any asset that does not have LODs is a definite no for me.

Quick question. Some people have mentioned that Sketchup assets should be avoided, but how do you know if an asset was created with Sketchup in the first place?


(I personally use Blender and Substance for all my homemade assets, usually 1K PBR textures. All with LOD.)

Regards,

John
 
....Sketchup assets should be avoided, but how do you know if an asset was created with Sketchup in the first place?

In the Description part of config.txt they usually have a sentence like "Another model created in Google SketchUp and exported to Trainz with RubyTMIX." On the DLS website, the Description is visible, and searchable, but CM can't do that.
 
Quick question. Some people have mentioned that Sketchup assets should be avoided, but how do you know if an asset was created with Sketchup in the first place?

Some creators who use Sketchup are honest and upfront in identifying that fact in the description tag.

In other cases there are clues such as a very large (many 10s or even 100s of MBs) file size for a small/simple scenery asset. If you look at the Preview Asset option in CM they will invariably show a very large number of triangles.

However probably the best guide is to use the Performance Analyser in CMs Preview Asset option.


  1. Just select (highlight) the asset in CM
  2. Right click and select Open then Preview Asset
  3. In the Preview Asset window click the Mode drop down box and select Performance Analyer.

The display area in the Preview Asset window will be filled with copies of the asset out to the horizon in all directions (it rotates the scene through 360deg). It may take a minute or two before the asset with all its animations (if it has any) is fully displayed.


  • You will get the first clue by noting how long it takes the display window to appear with all the copies - the longer the delay the poorer the performance
  • Then note how smooth is the rotation - a "jerky" rotation indicates a poor performing asset.

My suggestions
 
Last edited:
Sketchup isn't necessarily the daemon it's made out to be. Used with care assets made with it can be no worse that anything else that's on the DLS. Plucking completed models out of the Sketchup library though and converting them for Trainz, - that's another thing entirely.

(Comment by H222)And Trainzmesh is not rippable and protects a creator's mesh. I would've thought that's reasonably important to a lot of 3D creators.
A fair enough comment, - only if an asset built with Trainzmesh has a fault and its maker doesn't do anything about fixing it then in the bin it goes. At least with .im problems can be repaired, - which is something I've done countless times with older assets where their maker might not be around anymore. And by the way I've never ripped off anybody.

(Comment by H222) G.M., all of these points may have been relevant in the day of 256MB memory but they aren't now. PBR is not some demon, and why would someone with an install of a Trainz build 4.7 backdate their content to 4.6 and not accurately test that that content actually works Seems pretty irresponsible to be suggesting to people to change build numbers to something they can't test. It sounds like you want to use simple pm meshes and 512x512 textures and make a route that would've looked fine in 2004. But most of us don't want that. We want a healthy balance. Scripted rollingstock is bad? ok, lol

You make it sound like running Build 4.6 is going back to using a 486 DX4-100 and grainy pixelated models. There's plenty of quality layouts about that were made in Build 4.5 and 4.6 and they definitely don't look like they belong in TS2004; - though I certainly have seen more than a few TRS22 layouts that look like they belong there. Ultimately it comes down to the skill of the layout builder and throwing armloads of 'magic' hi-tech assets at a layout doesn't necessarily make it any good.
 
Last edited:
Sometimes, as I've found out the hard way, what would be an okay asset to use becomes a dead ringer horrible framerate killer not because it's bad to use but because the asset has become corrupted in some fashion. On one of my routes, I had placed some buoys on a river to mark the channel. They looked okay and were about the size of ants in the scope of everything else but being a river channel, I thought they were needed.

Initially, everything was fine then one day I had awful stutters in the vicinity but not exactly near those assets. I would start driving, get to that area and the program would pause for what seemed like an eternity as if all the oxygen was sucked out of the system. After this lengthy pause, the program would pick up where it left off and act as if everything was fine. Coming back through the same area, everything ran smoothly as if nothing was amiss. After removing, replacing, and updating assets in the area, to no avail, I came back to the ant-sized buoys sitting in the river channel. I deleted them and everything was fine after that. I downloaded them again and placed them in and everything has been fine since.
 
There are some key factors that affect your choice of assets to avoid being considered:

1. At TB 3.8 Speedtreez Mk 5 became obsolete. Any route containing them would require an awful lot of work to replace them for TANE and later versions of Trainz.

2. Similarly, any asset that is KIND "Bridge" is obsolete at TB 3.8.

3. The list goes on; tag 'alias', Paintshed, tag 'divider', Kind 'scenario', Chunky Track, in fact anything that inherits 'iTrack'.

4. Builtins (4793), Packaged to date (64,000), plus additional DLC, Code of Conduct violators (500+), ~192,000 Obsoletes, modified Scripted assets that nix legacy assets, Nothing you can do about them.

5. Legacy assets galore that need LOD, and Authors are not active are dead in the water. But the only indication is last time they uploaded an asset or commented in the forum.

6. Any asset, no matter what TB, that has Poly issues as defined by VE codes that is faulty. Months of 10 hour days has gone into identifying these assets has resulted in a list of ~2,000, If N3V can identify VE Codes why haven't they provided a VE code filter in CM?

Is this an efficient use of a resource in very short supply. There is a dearth of "Humans" with the right skills to carry out this work and a willingness to devote hundreds of hours. This was highlighted this week by the loss of Malc from the CRG when he succumbed to cancer complicated by covid. Since Aug 2016 CRG has dwindled from the original enthusiastic crew of xxx down to 3 or 4 active Creators and Fixers. Maybe AI bots can help but CM meh!

What the future brings we all are waiting with bated breath for HD TERRAIN that will supposedly repair and update pre-HD assets.

In the meantime Dean, can I suggest that you focus on any asset that has LOD but needs converting to LM format. aka VE 82 mostly Kind Traincar; Use CM filters 'Locomotive', 'Rolling Stock' or 'Train Vehicle'.

Another fruitful endeavour would be what of Euromodeller's prolific output of 'EMT PEOPLE', or 'DHR2' assets for Himalaya Railway are salvageable, he was only part way through this task before he died.

Ian
 
Last edited:
Absolutely agree with pware above in post #29:- Have to say that I typically use the Performance Analyser in Content Manager's built-in Preview Asset tool as a way of vetting out seemingly problematic assets.
It is an excellent indicator of the likely performance - or non-performance - of an asset in Driver mode. It also allows you to see the transitions between LoDs and provides numeric values allowing for comparison to alternatives.
 
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.


Again, thank you for posting this tip. I didn’t even know about the Surveyor Stats facility, but I am well-aware of the underlying problem.


As an example, I have a forty-mile UK route. I’m not the original author but, with his approval and for my own use, I’ve backdated it from the 1990’s to a 1930’s steam era operation. For the most part, it operates perfectly in TRS19, except for an unknown gremlin that manifests itself between mileposts 28 to 34. At this juncture, first the rail, then chairs and finally sleepers start to disappear leaving the train running on thin air just above ground level. Within this section there is a station where some 60% of the assets fail to load as the train approaches. Halt at the station and the assets slowly reappear. Restart the train and the rail again starts to disappear but eventually restores itself and the final six miles operate perfectly.


The GTX 1060 temperatures are generally 44 to 53 degrees throughout but increase to around 63 within the fault section.


Following discussion with the route’s originator I transferred it to TRS22 where it performs perfectly but with much the same temperature variations.


Following on from post #17, I enabled the Surveyor Statistics menu and panned through the entire 40-mile route. The Buffer and Index counts consistently identified just three Kuids from two authors. “No names – no Pack Drill” but these were the principal bullhead rail that I’d used for the entire back-dated route and two grass and shrub splines, that I’d used over a substantial part of the route. My initial thinking was that this still leaves unanswered the question as to why the disappearing asset fault should appear in only one section. The highest Rail Buffer count anywhere was 24 with a corresponding Index count of 2368989. The highest grass and shrub counts were in the problem area and were Buffer-23 and Index-2131056.

Are the accumulated totals for rail and greenery at the root of the problem?

The Surveyor Stats were also showing 30 – 33 FPS throughout the entire route.


Following pware’s suggestion – post #29 (and PC’s endorsement), I’ve put these same three Kuids through the CM Performance Analyser test. The images all appeared within 2 - 3 seconds, and they all rotated smoothly. I can only add that the rail has a triangle count of 631858 and the two shrub/grass splines have counts of 9257600 and 2874240.

As a novice in this arena my biggest problem is understanding the full significance of these figures and whether I’m even looking at the right figures. Perhaps, like John Citron, I should be looking for some other, as yet, unidentified malingering asset.

John
 
Just a thought, but one other thing that I have always wanted is the ability to right-click assets while still on the DLS and select "List dependencies". Then I would not only be able to see if it has unknowns, but also if any of the dependencies are oversized. Sometimes I have been surprised by what looks like a quick download taking forever because it ends up having a huge dependency. Of course, recent libraries can be giants, but they often are something else I did not expect. Not a problem for those with permanent FCTs, I suspect.
 
If you look at an item on the DLS website and click the Download page link, it will show you the item and all its dependencies on the DLS. Click on the Detailed link with your right mouse button and choose Open in new tab to see the size of each dependency. Close the tab and choose another item. Slow but it works.
 
Sorry, I should have been more clear. I meant using CM to look at the DLS. I only use the DLS web site if I have to, and I would like the day-to-day ability to have "List Dependencies" on the CM for the DLS.
 
I think I have resolved the problem. Possibly a straightforward A-B-C solution for some but for me more of an interesting learning experience.


I went back the Settings/Surveyor Statistics menu and revised this facility to operate in Driver mode. I then set up a typical steam hauled train some 2/3 miles short of the problem area and set off in Cab mode at around 10/15 mph. The Buffer and Index counts for the three assets were as before; the GTX 1060 temperature hovered around the same 46-degree mark and the FPS remained at the standard 30-32.

The first and I believe the only indicator of any problem came when the FPS figure started fluctuating and then dropped from the standard 30 down to 15, for a total travel distance of about ¾ of a mile just before the station. It then picked up and reverted to the standard figure of 30.


I have now carried an extensive revamp of all the vegetation assets on either side of the track in this area, eliminating almost entirely, one specific asset – significantly, not one of the original three that were identified as suspect.


Further test runs were performed with all the same constants maintained and just one brief FPS blip from 30 down to 29.


Thank you for all your suggestions. They certainly got me thinking in the right direction.

John
 
In the meantime Dean, can I suggest that you focus on any asset that has LOD but needs converting to LM format. aka VE 82 mostly Kind Traincar; Use CM filters 'Locomotive', 'Rolling Stock' or 'Train Vehicle'

Ian

Ian,

If an asset already has LOD, but just needs converting to .LM.txt format, it doesn't need anything other than a config edit. That's sounds like a job for a master scripter.

I'm more interested in mesh editing to reduce poly's and fix glitches, create LOD meshes, and texture re-work to reduce draw calls and improve the visuals. I can only do that kind of surgery on .im-based assets whose author's permit such modification and kuid re-assignment.

I'm not sure what Euromodeller's license permits or what format his meshes are in, but such open licenses are pretty rare. I will do some checking.

davesnow and bendorsey do allow that kind of thing, and they use the .im format. I’ve already done a few reconstructions of their assets. I'm currently surveying their catalogues for further suitable candidates against the criteria outlined in the opening post.

I’m currently working on davesnow's Grain processing facility 2014 DES, <kuid:101046:102571>. It weighs 153 MB in CM, has over 37,000 triangles, 18 texture materials from no less than nine(!) 2048x2048 maps, no LOD and over 37,000 downloads, so it fits my criteria quite well.

Past experience indicates that each asset typically takes at least 1 month of 8-hour days to finally knock it into a condition worth uploading. So I doubt that my feeble efforts are going to reduce the CRG's massive fix-and-release list by any significant degree.

:confused:

~Deane


.
 
Last edited:
Most Harmful (suspicious/filtered out here):
...
-Assets with huge libraries (although using a library is not bad)
...


Hi Guys,

Let me share with you my experiments with mesh libraries.
It is a very useful thing imho, but many creator "fall into a trap" and it is the .fbx file itself, leaving them in the content folder...
As content creator I also use mesh libraries with hundreds of .trainzmesh file on low-end PC, I also had lots of doubt in the past, I also asked in another thread if there are any limit for the number of files as I had no idea why it is uneffective...

Then I did a test...
My test results (TRS2019 SP5)

If you leave the FBX file in the content folder after importing the asset, the result will be
- the exported cdp file will be extremely huge.
- possibly bug - Trainz will use it in the background (I have no idea for what reason since .trainzmesh file already exists - but I am curious...) using tons of memory, ~100% CPU Load
- only a couple of FPS (between 2-5 FPS)...

After removing the FBX files and re-committing the asset:
- small content size
- small cdp filesize
- HUGE FPS

Isn't it interesting? ;)


Krisz
 
Last edited:
Back
Top