koobas.hobune.stream
Shader Graph texture limit?
How many individual textures can you supply to an HDRP Lit shader made with Shader Graph?
And I am explicitly excluding texture arrays.
More info: My game world is made of 72 tiles. I use a lookup texture to handle game logic and some shading. One of the values it looks for is water, which is a large part of the game world. Since the entire texture is black (in the case of water) and has no game logic value, to save gigabytes of (V)RAM, I can split up the game world further and further to omit as many purely black textures as possible. I can do that with textures easily (programatically), but splitting up meshes is not as trivial and it would increase the draw calls dramatically, aswell as reducing the amount of saved (V)RAM, since it would introduce new (duplicated) edges. As an absolute minimum I need to be able to supply up to 64 textures to a shader, or think about splitting up meshes.
Additionally, if anybody has a different optimization approch, I'm all yours.
I don't know about any hard limit (there may well be one though) but using that many textures is a bad idea for other reasons. Sampling textures takes time and you would always sample all textures in the graph, even if only one has an effect on the result. Try using a single Texture 2D Array instead where each element is one of the tiles. That way you only need to sample once and you can have as many textures as you like.
Edit: Here is an example shader graph for building a world from tiles. The world texture contains one pixel per tile that is then used as an index for the texture array. The texture array contains the actual tiles. Make sure that the world texture is set to point sampling (not bilinear).
Example graph
(I had to do it via Google Drive because somehow the picture upload isn't working. Hope this works for you)
The problem with texture arrays is that every texture has to be of equal size. $$anonymous$$eaning I cannot instert a 32px x 32px, purely black texture ins$$anonymous$$d of an 8k one to save, in total, gigabytes of (V)RA$$anonymous$$.
Perhaps I misunderstood but I thought you wanted to split the game world into tiles so that you could just leave away the empty tiles (or at least use the same tile for all empty areas).
Anyway, even if you need differently sized textures, you could still use multiple Texture Arrays (one for each size). All I'm trying to say is that I wouldn't just put 64 separate textures into one shadergraph, even if it's possible (which it might not be, idk). You'll have to combine them into fewer texture objects one way or the other if you want good performance. Another option for that would be a texture atlas, that way you could have differently sized areas but the math would be a bit more complicated.
I think you've understood me completely but just for clarification I'll give you an example:
Suppose you have 4 "connected" meshes. Let's say each mesh's material has a 4x4 texture array associated with it. Now: many textures are completely identical (i.e. purely black - symbolizing water). [0,2] and [1,1] and [1,2] for material A, none for material B, 14 out of 16 for material C and another random number for material D.
I'm pretty sure you understood this from the start :)
Either way... typing this reveals my ignorance to myself. Yes, each texture has to be of equal size in a texture array... so I can't use a 32x32 tex to replace an 8k texture, sure, BUT can I (real question) supply the same, purely black, 8k texture (reference) to multiple entries in the same texture array without increasing (V)RA$$anonymous$$ cost? $$anonymous$$eaning I'd end up with a single purely black 8k texture (ins$$anonymous$$d of like 100), which is then supplied to multiple texture array entires in multiple texture arrays?
