To BIG ??
- Thread starter BRClass66
- Start date
shaneturner12
Tutorial Creator
Hi Brad,
It sounds like the assets you mention are mesh libraries, where multiple single textures are combined into one asset.
Shane
It sounds like the assets you mention are mesh libraries, where multiple single textures are combined into one asset.
Shane
Hi Shane,
As you know ive been trying my route out on a number of tests (which you've helpt me with)
Just tried my highest which is CL Ballast - 01 which is 42.71 MB and nearly covered alot of my route with it and i still get 60 plus frames per second ....so as per usual i think your right
As you know ive been trying my route out on a number of tests (which you've helpt me with)
Just tried my highest which is CL Ballast - 01 which is 42.71 MB and nearly covered alot of my route with it and i still get 60 plus frames per second ....so as per usual i think your right
shaneturner12
Tutorial Creator
I can check that one to see if I am correct - sometimes though, the large size is due to the texture being high-resolution (1024x1024 or larger).
Shane
Shane
1024x1024 is usually around 4 MB, plus there is the Normal map to consider as well which is the same size so looking at 8 MB plus for a 1024 x 1024 high res ground texture, looks like 34MB could be a 2048x2048 which can now be used. supposedly, think it was Chris ((WindWalkr) who said it's not really a problem as they are compressed in game anyway.
shaneturner12
Tutorial Creator
It could be - strangely enough, the asset mentioned is actually one of yours Malc.
Shane
EDIT: Just checked the asset - it looks like a single 2048 x 2048 texture + equivalent normal.
Shane
EDIT: Just checked the asset - it looks like a single 2048 x 2048 texture + equivalent normal.
Last edited:
Yep that's mine, contains a normal map so there are two 2048 x 2048 tga's. Normally I use 1024x1024 but it was impossible to get a good match to the ballast for my not yet released NG track.
Curiously if you open it for edit it comes to nowhere near 42MB more like 33 MB total, so something must get added by CM or it's not reading sizes very accurately.
Well doesn't matter to me Malc even if it's larger to get good quality ......just so long as it doesnt effect the FPS..
I've been checking all day on stuff on my route,Making sure things dont come into effecting the smooth running of trainz but still have eye candy
Really glad i found this out with you guy's.....means i'll look for more good textures like that for my route and know its not effecting FPS
I've been checking all day on stuff on my route,Making sure things dont come into effecting the smooth running of trainz but still have eye candy
Really glad i found this out with you guy's.....means i'll look for more good textures like that for my route and know its not effecting FPS
Just checked the biggest asset i've got in CM and its M: (P,E) UltraTreez - Sugar Maple 01 (Perfect Series / Early Fall) which is 338.23 MB
I placed 70 of these in a very short space (4 to 5 lengths of a class 66) and got 40 to 42 FPS and no lagging all ran smooth..
I've never made anything for trainz so don't know the in's and outs how assets are made , But at this size i would think it would cripple my computer but it doesn't.....and just a few months ago a small house or some building i DL was killing the FPS.
Anyone got higher than 338.23 MB not counting route/sessions and still running ok? i'd love to know.
Regards
Brad
I placed 70 of these in a very short space (4 to 5 lengths of a class 66) and got 40 to 42 FPS and no lagging all ran smooth..
I've never made anything for trainz so don't know the in's and outs how assets are made , But at this size i would think it would cripple my computer but it doesn't.....and just a few months ago a small house or some building i DL was killing the FPS.
Anyone got higher than 338.23 MB not counting route/sessions and still running ok? i'd love to know.
Regards
Brad
Hi Brad,
This has to do with the way the model is made and how the model is textured. In some cases, what would appear to be an innocuous building or other asset, can actually kill the performance. There could be way too many polygons used to create the object in the first place, causing the computer to spend time loading all the mesh into memory. In other instances, it could be the textures. Some people used double-sided textures, meaning the object has the same image on the inside as well as the outside. When this happens, the computer has to render both sides of the object, causing stutters.
John
Thanks for Reply John...
So size means nothing??...i always looked at size of assets on the DL and stayed away from them if they were to big.
So all to do with polygons and Textures ? Is there anyway to check these ?..I know veiw mesh technical details but what is a bad count of polys and whats a bad count of textures ?
And another thing is not all assets show veiw mesh technical details.
I do a check in surveyor and check the worst buffer count ..if over 100 i remove it...something Shane Turner showed me and others.
Is there another way you check ?
Regards
Brad
So size means nothing??...i always looked at size of assets on the DL and stayed away from them if they were to big.
So all to do with polygons and Textures ? Is there anyway to check these ?..I know veiw mesh technical details but what is a bad count of polys and whats a bad count of textures ?
And another thing is not all assets show veiw mesh technical details.
I do a check in surveyor and check the worst buffer count ..if over 100 i remove it...something Shane Turner showed me and others.
Is there another way you check ?
Regards
Brad
ZecMurphy
Community Assistant
Hi All
When an asset is installed using Content Manager, the textures used will have a 'compressed' version of the texture (a '.texture' file) created. As this is effectively a 'duplicate' of the original texture, it will increase the file size (by about half). File size isn't a direct cause of low performance, particularly with current assets which can be acting as 'libraries' of models for other assets (which can give improvements to performance, where each of those assets is used in the same scene). From memory, Mcguirel's trees use such a system, which increases the file size of 1 tree but means that the other two are only a few KB in size.
Where ground textures are concerned, care should still be taken to not use too many large assets. You can get away with a fair few 1024*1024 (+ normals map) ground textures, but fewer 2048*2048 ground textures (file size is a good indicator here). It's really all a game of 'balance'.
Which objects works, and which ones don't, depends entirely on the asset itself, and the composition of the scene. In some cases, an asset that doesn't work in one scene can work in another (e.g. in a scene where there are fewer objects in view). This isn't always the case, there may be assets that just simply won't work well, but in most cases it really depends on how they're used.
Of course, another part is your PC's specs, and the settings in-game. Use too many assets that are inefficient, and you'll bog things down with less details.
As to good and bad counts of textures/polys, there's no 'real' value for these, as it does depend on the asset used, and if the asset has LOD, and so on. Textures need to be kept to a minimum. For a 'normal' scenery object, 1 or 2 textures is preferable. Even better if the textures are shared between a few objects
Regards
When an asset is installed using Content Manager, the textures used will have a 'compressed' version of the texture (a '.texture' file) created. As this is effectively a 'duplicate' of the original texture, it will increase the file size (by about half). File size isn't a direct cause of low performance, particularly with current assets which can be acting as 'libraries' of models for other assets (which can give improvements to performance, where each of those assets is used in the same scene). From memory, Mcguirel's trees use such a system, which increases the file size of 1 tree but means that the other two are only a few KB in size.
Where ground textures are concerned, care should still be taken to not use too many large assets. You can get away with a fair few 1024*1024 (+ normals map) ground textures, but fewer 2048*2048 ground textures (file size is a good indicator here). It's really all a game of 'balance'.
Which objects works, and which ones don't, depends entirely on the asset itself, and the composition of the scene. In some cases, an asset that doesn't work in one scene can work in another (e.g. in a scene where there are fewer objects in view). This isn't always the case, there may be assets that just simply won't work well, but in most cases it really depends on how they're used.Of course, another part is your PC's specs, and the settings in-game. Use too many assets that are inefficient, and you'll bog things down with less details.
As to good and bad counts of textures/polys, there's no 'real' value for these, as it does depend on the asset used, and if the asset has LOD, and so on. Textures need to be kept to a minimum. For a 'normal' scenery object, 1 or 2 textures is preferable. Even better if the textures are shared between a few objects
Regards