I came accross Texture Collection from a dev called Caden:
It seems similar to Texture2DArray, but without the limitation of resolution of Texture2DArray.
Apparently (not sure), you can place all your textures in a Texture Collection, and then in the material you can select any you need.
This means that if your game is 2D, you can use 1 material for all your Sprites. All of them regardless of resolution.
That sounds too good to be true. There must be some sort of caveat or disadvantage?
For example, Texture2DArray has the enormous benefit of using all the textures you need in one material, but it loads them all, regardless if you are using only some of them in the current level.
So I’d like a confirmation from someone who is more experienced in the Unreal.
Is Texture Collection a game changer?
Why is it not talked about anywhere.
This looks legit. Was looking into collections myself as they do readily bypass some of the more severe limitations of arrays. That he notes the collection can touch many kinds of texture resources makes sense since the thing is bindless.
I see this helping me quite a bit. I had 4pack textures for heights in a given biome, and had to juggle multiple textures to blend between biomes x, y, and/or z, but with this I can get a cheaper more-elegant solution.
I use UDIMs and they come with their own ultimate size limitation, so being able to kind of bypass that as well, with minimal changes to code, is attractive.
I could see this being just-useful across the spectrum of games you could make, not just 2d.
Remains to be proven if this is a net-gain in performance, but I’ll try and report back with my experiments.
The other thing I think could be useful is this idea of lateral-communication or horizontal-information-exchange between things that would not otherwise be able to know about the-other. The same benefit sinking multiple meshes into an RVT so grass can mask itself out when a rock is there; the rock and the grass can in way ‘communicate’ because they are sensitive to one another.
In the same way here, in the texture-space, a rock being placed in a given area can see/access the local grass-textures and paint itself in vs having to use RVT-blending or another method. Since it can reach up/out of it’s own (nominal) texture-silo and reach over and into ‘grass’, it opens up many kinds of customization options (IMHO).
In my case it can have great use because im using one Hierarchical Instanced Static Mesh Component for all my units. Though since in HISM you can only have 1 material and 1 mesh, you need to use Texture2DArray to change sprites for different instances. That is controlled using a Per Instance Custom Data float.
This works very well. The only problem then is that all your sprites need to be the same resolution, or else the Texture2DArray doesnt work.
Most of my sprites i try to fit them into 512x512.
But have also 1024x512, 1024x1024, 1024x2048, 256x256
So if you have other sprites with different resolutions, you need to create a new HISM and a separate Texture2DArray for them…which sucks.
With Texture Collection I assume this would work all with one HISM and one Texture Collection.
Is this correct? Could you confirm me if this would be possible, or if there are some inconveniences that we might be missing?
It sounds too good to be true.
Hmm how does this work with respect to runtime material instances?
For example, if you have 100 doors, all with the same mesh, and with the same unchanging material, your scene will consist of 1 mesh and 1 material.
However, if material parameters on any of the doors can change (textures, color, whatever) then that requires 100 runtime material instances. So your scene effectively has 1 mesh and 100 runtime material instances.
^ i think thats how it works?
Material instances on disk vs. runtime material instances can get a bit confusing if not specified which.
I don’t see why not. It would for sure take some clever management on the dev’s end of the house but it seems the collection is best of both worlds w/regards to TexArrays + UDIM features, w/o the same limitations.
As described in the article, the only REAL thing you need to worry about is how to determine WHICH texture you want out of a (potentially) singular collection. That value can be in a BP, in custom-data, etc, etc; where is up to you.
But functionally, I don’t see why if your game is aligned properly you could have 1 or at least a minimum of shaders.
My use-case doesn’t work in 5.6, so i might not spend the effort to test until the next hotfix, but I what I CAN say is that I am using the UDIM address-space in the same way I could use the Collection. There would be one big-mega-sheet/texture where I had the textures for every landscape layer, rock/debris meshes, plant meshes, etc and they could all look ‘across’ the spectrum of what other things looked like, since they are in the same-space, so could do all sorts of nifty things given a rock ‘knows’ what a plant could look like. Instead of using Pixel Depth Offset, or some kind of dithering to blend 2 distinct meshes, I am using master-materials to make a very-few set of things that all point to the same UDIM space and each item sorts itself out.
A collection would be a virtual 1:1 swap for the UDIM’s I’m using know, otherwise, what that person is doing in their game, I am already doing in mine, w/carrying Custom Data on things to tell it which texture-set to pick out of the UDIM space.
So, ‘yes’. The REAL trick there is to be able to code a performant shader to do-it-all..
ref - some challenges around 1-shader/draw-call and UDIM limitatons:
