Other than the memory usage, the other textures in the array are generally irrelevant when performing operations. You are trading potentially higher memory usage for fewer draw calls. Mainly, the array exists for quality of life improvement, as a replacement for texture atlases.
Dont think it works that way, else we would just have arrays of individual pixels because they load up faster being just the 1 pixel and all.
This depends wholly on how you coded thingsā¦
Probably not, if you are accessing a memeber of an array and performing operations on it, the meber being an apple or an orange shouldnāt have much of an impact on the fact you are conducting some operation with it, like slicing.
The real question here is how and what are you getting at?
The engine already does a decent job at reducing texture lookups - its built that way due to DirectX actually, so you can thank m$ for forcing everyoneās hand.
Maybe you should do just that - read up some older DX9 documentation on how it used to be done, learn from the ground up on the way it used to be just enough to ubderstand it, then swap to dx12 so as to learn what it becameā¦
Even with the documentation this isnt an easy read - but you can still build DX9 stuff in C# directlyā¦ trial and error would help.
Well memory relatedā¦ heres another question. What if 1 material uses the texture arrayā¦ and another material just uses one of the textures that are in that arrayā¦ but doesnāt use the array itself. Will unreal know its not a duplicate texture to be loaded into memory twice?
Heres anotehr questionā¦ for the arrayā¦ if your close to 1 object that uses only 1 texture in teh array, will every texture in the array highest mip level be loaded/streamed in? Or just that 1 texture?
Mips are per calculated per pixel. This will work just like any normal texture. The nearby texture will sample a different mip than the farther texture. It is still only one sample, because any given pixel only needs one of the mip levels.
Think about it in regards to what a single pixel must do. If you wanted two different mip levels to be shown for the same pixel, you would need to sample the texture twice. But if you want two different pixels to sample a texture with different mip levels, you only sample once and give each pixel a different bias.
I donāt know if you could duplicate the resource in memory by sampling it both in an array and out but I doubt it.
I canāt see why you would do that, but you could test it I guess.
well some textures are used in different shaders so its curious if the engine would understand its still the same texture in memory wether its in a texture array or out of itā¦ or maybe 2 different areas are using different arrays, but both may happen to use a couple of the same textures within themā¦ and different ones otherwise for different areas of the levelā¦
I think youāre really overcomplicating the decision. Feel free to benchmark the memory usage in this circumstance, but itās an edge case.
Put textures that will likely need to be allocated together into arrays (foliage for a single biome is a good example).
Donāt use arrays for assets textures that are unlikely to be allocated together. (Donāt put multiple biomes worth of foliage textures together, as the player is not likely to see desert plants in a jungle so those textures will be wasting memory).
This should be the decision making factor, not the edge cases.
2 Likes
Iād go further and try to see if using VT and making a 16k^2 atlas of all the textures for the jungle ends up saving any performance cost.
I doubt it would, but VT is a bit of a strange beast when it comes to āin practiceā so a test on this would be the best way to determine if you get any savings and āhow muchā that savings may end up beingā¦
Thats somewhat what they expected the VT on landscape would be useful for. Except for the system was never peoperly finished off, so it wont work as one expects it toā¦
I would think it would at least save one a sampler, but so does a texture atlas.
I thought Unreal, or many modern engines, essentially already build an atlas out of all the textures for a given app, and that a sampler-slot is more how-many times one needs to dip into that mega-texture(?).
I can say from my experience that using texture-atlases has been very beneficial to keep sampler-slots down since you can intelligently-stack textures that are mutually-exclusive, or even otherwise with temporal-blending, and it also appears that the size/cost of the texture-atlas is a bit less than the combined cost of all the textures separately; there is a bit of space-savings from whatās displayed in the app.
My TAās source VTs, so you can double-up on that as well.
Depends? When baking lights for instance, the texture atlas ends up being so infinite that you get multiple atlases in the mix.
They are definitely sampling faster, or else epic would use a different approach for cascaded shadowsā¦
I know for sure the engine builds the atlas if you bake lights.
Iām not sure if it does so for the landscape object+foliage as well.
I think the 2 are isolated unless you go out of your way to make it otherwise.
Within a shader, shared:wrap is not infinite. You have a limit (driven by dx12 i think?) On the shaders themselves.
Changing where these samples are sampled from (an atlas, a vt, etc) should have little to no bearing on final perfomance cost?
I mean, reading 1 bit takes X time on Y machine. There isnāt a way around this to load up the thing into ram, and thatās the real limit with things.
Using the 1bit from ram, that too can (and is with VT?) Be done in different ways, some working faster than othersā¦
Is it safe to say that less is faster?
In the end i think thats always the case - and why stuff that looks like Minecraft runs at 240fpsā¦
problem with virtual textures is for every uv seperate set ā¦ its actually 2 samples instead of 1ā¦ only time its not is if other textures share the same uv setā¦ for example ,normal +RMAo + Color = 3 normally but would equal 4 with virtual texture. And anytime u modify the uvs or use a seperate uv setā¦ then it adds another sample.
Understood. In my particular case, I am sharing UVs (albedo, 2chan-Normal + AO, GlossRoughDisplace), BUT it is always good to know; thanks for the info.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.