Junk Files Uploaded to DLS

[johnwhelan]

That is simply not true.

I suspect you are thinking of SketchUp which seems to create a different texture material for almost every polygon.

Whilst it is possible to map to a single texture with GMAX if you look at many GMAX creations they do tend to have a lot of small texture files.

Cheerio John

 

[Dinorius_Redundicus]

Whilst it is possible to map to a single texture with GMAX if you look at many GMAX creations they do tend to have a lot of small texture files.

Cheerio John

That is completely down to the creator’s choice (lack of care or knowledge), not any inherent limitation of gmax.

Remember that in the early days of Trainz, gmax was almost the default 3D program because it was free and promoted by Auran via their customized Trainz Asset Creation pack. Creators were generally inexperienced and learning as they went along. They often copied the worst habits of other creators because it was easy and there was little in the way of validation checks to stop this. It resulted in several years worth of assets with laughably high texture- and poly-counts, and no LOD’s.

To blame gmax for that is just plain wrong.

 

[pcas1986]

For general information:
Since the release of the latest Trainz 2022 service pack, the maximum number of different textures (tga, png, jpg, etc.) supported without warnings or errors is 8. This means that if you make an object or train with more than 8 textures and install it on a Trainz 2022 build, it will fail, but if it has a lower build and you install it on Trainz 2022, it will only receive a warning.
To prevent future issues, it's best to limit the number of textures per item to 8.

I ran a test on this with a Blender icosphere that had just 80 tris but 10 PBRMetal materials and it failed as you said with an excessive chunk amount but it did work with 8. Eight PBRMetal materials is actually 24 textures/images. So, I suggest the limit is 8 materials rather than textures.

There may be other factors at work here so I'm not 100% sure on this issue.

I also know that excessive numbers of polys (tris) will split into multiple chunks but I'm not sure the 8 chunk limit applies in that case. I see a lot of chunk limit warnings for assets I work on for others or repairs. Don't recall seeing errors though.

It would be nice if N3V were to publish a WiKi page of these limits.

 

[pcas1986]

...

Remember that in the early days of Trainz, gmax was almost the default 3D program because it was free and promoted by Auran via their customized Trainz Asset Creation pack. Creators were generally inexperienced and learning as they went along. They often copied the worst habits of other creators because it was easy and there was little in the way of validation checks to stop this. It resulted in several years worth of assets with laughably high texture- and poly-counts, and no LOD’s.
...

I've seen quite a few examples of that when repairing assets for the CRG but don't know any practical way of repairing them. So they get repaired with the same issues.

 

[johnwhelan]

That is completely down to the creator’s choice (lack of care or knowledge), not any inherent limitation of gmax.

Remember that in the early days of Trainz, gmax was almost the default 3D program because it was free and promoted by Auran via their customized Trainz Asset Creation pack. Creators were generally inexperienced and learning as they went along. They often copied the worst habits of other creators because it was easy and there was little in the way of validation checks to stop this. It resulted in several years worth of assets with laughably high texture- and poly-counts, and no LOD’s.

To blame gmax for that is just plain wrong.

And I totally agree, I used GMAX for many years.

Cheerio John

 

[Dinorius_Redundicus]

I've seen quite a few examples of that when repairing assets for the CRG but don't know any practical way of repairing them. So they get repaired with the same issues.

There is no way to fix high texture and -poly counts, lack of LOD without extensive mesh surgery, condensing texture maps to atlases and UV re-mapping. All of that is well outside the CRG's remit. I have done such repairs and improvements (including addition of normal maps) to assets from other creators when requested and permissions allowed. However, it's not an enjoyable task.

That's why it's good news that N3V is finally cracking down on excessive textures and so on. Just 20 years late.

 

[KotangaGirl]

I believe that it also creates textures for all the surfaces that you will never see which increases the file count and contributes to its well known memory penalty.

If care is taken to remove hidden surfaces these problems with creating assets with Sketchup can kept under control. Most problems come from models being taken directly from the Sketchup depository and put directly into Trainz without any modification.

 

[JCitron]

If care is taken to remove hidden surfaces these problems with creating assets with Sketchup can kept under control. Most problems come from models being taken directly from the Sketchup depository and put directly into Trainz without any modification.

My brother and I were discussing this yesterday. He said to import the assets into something else and create a UVW map of the textures and use that instead. How to do this, is out of my braincell capacity and I'll leave that as vague as I remember it.

 

[Dinorius_Redundicus]

My brother and I were discussing this yesterday. He said to import the assets into something else and create a UVW map of the textures and use that instead. How to do this, is out of my braincell capacity and I'll leave that as vague as I remember it.

That’s the same process I described in post #26 above, essentially re-building the asset by lots of mesh editing, texture reconstruction and UV re-mapping. It’s even more work if proper LOD meshes and/or modernised textures need to be created.

It is much better if potential “junk” assets are brought up to standard by their owners before uploading. The new validation criteria that Frank_Dean referred to will hopefully ensure that happens by stopping junk uploads “at the border”.

 

[JCitron]

That’s the same process I described in post #26 above, essentially re-building the asset by lots of mesh editing, texture reconstruction and UV re-mapping. It’s even work if proper LOD meshes and/or modernised textures need to be created.

It is much better if potential “junk” assets are brought up to standard by their owners before uploading. The new validation criteria that Frank_Dean referred to will hopefully ensure that happens by stopping junk uploads “at the border”.

That's what I thought. He said it a bit differently.

 

[Frank_Dean]

I make my objects with the old Gmax, once made, previously I put the 2012 build and now the Tane build, but I test them with TRS2022 PE 129336.
I found out about the number of textures by chance, when making some groups of objects. Before SP5 I made a group of 15 graves with 15 textures, I tested it in 2022 SP4 and I had no errors or warnings. Just in those days the 2022 SP5 came out, and the previous group of 15 graves with a build 4.5 when installing it presented only a yellow warning of excess of textures, but it was usable.
I kept redoing the number of graves in the group and by the time it reached 8 graves with 8 textures, it no longer presented the warning in Trainz 2022 SP5.
You can still use objects with many textures, as long as you have the build lower than SP5 or 5.6, you will only have a warning.

 

[Dinorius_Redundicus]

Even 8 materials is generous (in my view) but I suppose N3V does not want to be too draconian. It should be seen as a very rare exception, not common practice.

N3V have been advising us for many years to minimise the number of materials - 1 being ideal, but perhaps 2 or 3 at most, not 8. To achieve that, they strongly recommend the practice of packing multiple smaller images into 1 larger image, otherwise known as a “texture atlas”. It is quite easy to do in graphics programs that support Layers.

 

[martinvk]

Just because "too many polys" is hard to define should not stop the validating process to reign in those objects that are so far over the limit they are in another world.
N3V needs to publish target limits based on usage and type of object. That way creators have a target to aim for. Without any targets, we will constantly have these discussions about objects that are too big, have too many polys, too many textures, etc.
Not something the community can fix, N3V need to step up to the track, provide guidance and enforce it.

 

[johncarter]

I think the file admission filter for Trainz should be upgraded to a Tane build from 3.9 to 4.5.

This filter would prevent objects or trains with many polygons and no LODs.
Currently, you can upload to DLS with a 3.5 build and thousands of polygons, or even over a million.

As an example of a junk object, there's one that was uploaded to the DLS today, July 3rd, and it's an author who only has that object. Based on the object's username, it must be from China. Some characteristics of this object:

-Chinese username translation: -Chinese-style architecture - Panjin Liaohe Oilfield No. 1 Senior High School
-Size before download according to the Content Organizer: 94.5MB
-Size after download according to the Content Organizer: 227.5MB
-Size in folder format: 208MB
-Build: 3.5
-Type: Fixed-track
-Mesh: Single mesh: bodytrainzmesh of 58.3MB and its body.fbx of 33.7MB, and uses a text file.lm for a single mesh.
-Textures: 9 TGA textures, 7 of which are very large (16MB) and could easily be reduced to a quarter of that, as they don't have much detail.
-Polygon count when opened in the viewer (Preview Asset): 1,378,036 polys
-When you put a 3.5 build and download it in Trainz 2012 it will not be usable because it has a trainzmesh mesh.

For all the reasons above, I'm saying it's a junk file.

Totally agree keeping the DLS clean and high-quality benefits everyone. It’s frustrating to sort through junk files when looking for legit content. Maybe stronger moderation or a rating system could help filter things better.

 

[pware]

I fear that the only thing that would satisfy all these requests for higher quality content on the DLS would be human moderation. Someone would have to open every uploaded asset to check its contents, poly count, textures, LOD compliance, etc, etc. And while they are doing that they should also check that the thumbnail actually matches the asset (I am surprised that no-one has mentioned that one), do a translation for all the assets that do not have English in their titles and descriptions (and no, English is not the most commonly used language anymore) and a translation for those assets that have a totally cryptic title as well as assets where the creator does not bother to add a description.

Of course, assets that have missing dependencies would have to be rejected if there is no information on where they can be found.

All of this would take time so uploaded assets may not appear on the DLS for at least a week (or perhaps much longer???) and so they would have to deal with the complaints from frustrated asset creators.

Who wants to volunteer? (not me)

 

[whitepass]

For general information:
Since the release of the latest Trainz 2022 service pack, the maximum number of different textures (tga, png, jpg, etc.) supported without warnings or errors is 8. This means that if you make an object or train with more than 8 textures and install it on a Trainz 2022 build, it will fail, but if it has a lower build and you install it on Trainz 2022, it will only receive a warning.
To prevent future issues, it's best to limit the number of textures per item to 8.

That can not be right as you need 10 textures just for ARN.

 

[Frank_Dean]

That can not be right as you need 10 textures just for ARN.

The test I did was not a train, it was an object of the type "Building" with a build 4.5, installed in TRS2022 SP5 with up to 8 textures does not present neither warnings nor errors.
With more than 8 textures in an "IM" mesh, it only shows warnings of the type:
Example of a group object of 30 tombstones, using 32 textures, installed in SP5:
VE166: 32 combined chunks (of 32 source) in .im file:
VE275: Excessive chunk count 32 in mesh file: tombstones.im

I do not have explanation of why with 8 textures or less it does not present warnings and if they are more than 8 warnings VE166 and VE275 appear.
If that same group object of 32 textures with build 4.5, we raise the build to 5.6 and we install it in SP5 build 5.6, the warnings become errors and it is unusable.

Sorry if I am not understood correctly, I use translators and maybe there could be some mistake.

 

[martinvk]

Two issues here, bloated objects that have no technical errors and objects with errors depending on the build.
The first would take a lot of work as pware rightly pointed out. I for one wouldn't mind waiting a bit longer if the result is a cleaner DLS.
As for the second, that would be harder to regulate. Someone who deliberately uses a lower build number to get around errors is not being nice to those who rely on build numbers for their work. Limiting newer versions of Trainz to newer build number would needlessly hamper those who rely on older objects because new ones have not been produced (yet). Don't know of an elegant solution for this.

 

[pcas1986]

That can not be right as you need 10 textures just for ARN.

Every time I do an ARN mesh and material setup I think the number rendering process is archaic and needs an update. This would surely be a candidate for a texture atlas layout of the replacement numbers arranged in a particular order. N3V introduced native ARN support some years back but didn't touch the mesh side of it AFAIK.