[Questions] Large Texture Atlas with Unload unused textures
3 posters
Page 1 of 1
[Questions] Large Texture Atlas with Unload unused textures
It was discussed previously that placing multiple textures into one file could improve the performance.
Let's say I have an 512x1024 texture file consist of 20 station name signs.
But if I enable the Unload unused textures options, and the texture atlas got unloaded after it's passed by the camera
Would this result in more lag spikes, as everytime you have to load the same 512x1024 texture again when you approach a station instead of loading something like 128x64 everytime you approach?
Thanks!
Let's say I have an 512x1024 texture file consist of 20 station name signs.
But if I enable the Unload unused textures options, and the texture atlas got unloaded after it's passed by the camera
Would this result in more lag spikes, as everytime you have to load the same 512x1024 texture again when you approach a station instead of loading something like 128x64 everytime you approach?
Thanks!
Re: [Questions] Large Texture Atlas with Unload unused textures
I fear this would result in much higher RAM usage and longer track loading times.
Re: [Questions] Large Texture Atlas with Unload unused textures
Again, the answer here is that it's complex
Your 20 station name signs example however is a perfect case of what *not* to use an atlas texture for.
You're only likely to have a single face visible from this texture at any given time, and the slow part is switching the active texture.
The best use of a texture atlas for is on things that can be combined into a single mesh draw call.
For example, this would be something like a station / platform in a single combined mesh.
Our 'classic' BVE modelling method would be something like one texture for the platform wall, one for the surface, one for the building front etc.
The single slowest operation for the renderer is switching between textures as it draws each item. On the other hand, vertices within a single combined draw call (once uploaded to the GPU initially) are essentially free.
The second-best use of a texture atlas is for frequently used textures on opaque faces. (Ballast, track components, grass etc.)
As opaque faces can be drawn in any order, the renderer will sort these in order to minimize the number of texture switches required.
It does not however combine these into a single mesh draw call (only things within the same static object), so taking the station example above, this would be marginally slower.
Using a texture atlas on transparent / alpha faces is less to be helpful, as these must be sorted by depth. (drawn rear to front)
The moment the renderer has to switch texture, you negate the benefit of the texture atlas.
With regards to RAM usage, this is another complicated area.
As a good rule of thumb, *so long* as you don't exceed the available RAM / VRAM, once the loading process is complete, it makes absolutely no difference. If however, you need to swap out textures from VRAM to system RAM or even to disk, this is a killer.
Your 20 station name signs example however is a perfect case of what *not* to use an atlas texture for.
You're only likely to have a single face visible from this texture at any given time, and the slow part is switching the active texture.
The best use of a texture atlas for is on things that can be combined into a single mesh draw call.
For example, this would be something like a station / platform in a single combined mesh.
Our 'classic' BVE modelling method would be something like one texture for the platform wall, one for the surface, one for the building front etc.
The single slowest operation for the renderer is switching between textures as it draws each item. On the other hand, vertices within a single combined draw call (once uploaded to the GPU initially) are essentially free.
The second-best use of a texture atlas is for frequently used textures on opaque faces. (Ballast, track components, grass etc.)
As opaque faces can be drawn in any order, the renderer will sort these in order to minimize the number of texture switches required.
It does not however combine these into a single mesh draw call (only things within the same static object), so taking the station example above, this would be marginally slower.
Using a texture atlas on transparent / alpha faces is less to be helpful, as these must be sorted by depth. (drawn rear to front)
The moment the renderer has to switch texture, you negate the benefit of the texture atlas.
With regards to RAM usage, this is another complicated area.
As a good rule of thumb, *so long* as you don't exceed the available RAM / VRAM, once the loading process is complete, it makes absolutely no difference. If however, you need to swap out textures from VRAM to system RAM or even to disk, this is a killer.
Gothpaladinus, SP1900 and LXQt like this post
Similar topics
» Can we log to log file that is the unused object list?
» Texture states like object states for texture
» Loading textures
» Large BVE link collection
» Incorrect Line-spacing in Large HUD
» Texture states like object states for texture
» Loading textures
» Large BVE link collection
» Incorrect Line-spacing in Large HUD
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum