I have a single object with three different UV maps, currently using a single grayscale texture each; if I were to channel pack the three textures in a single RGB image, would there be a way to use the different UVmaps to drive any channel coordinates after the texture node?
So the end result would be: three UV maps, a single channel packed texture?
It could be done, but the only ways I could think to do it would be really sloppy. You’d have to use three separate copies of your image texture to drive each of your individual UV channels. Something like this…
Thank you!
Would that triplicate the drawcalls or would it have minimum impact on them?
I’m not savvy about the engine calculations part of asset creation, and the dev that will use the asset in Unreal, even less so.
I’m not exactly savvy on that subject either. I’d imagine that it’d save on memory, since it’s not having to keep any separate textures resident, but it’d still eat up extra draw calls for each repeated texture node in the set.
I think it’s not about the number of draw calls but for only one uvmap there is only one texture lookup and now there are three… and three color separations and one combination of the colors of the texture. The image itself is loaded only once…
Also if this is used in Unreal… then there has to be made a shader setup in unreal… this may be differently solved. ( Blender does have not (likes also OSL) the "usual pixel and fragment shaders… like in GLSL… that’s maybe the reason why OSL was “inlcuded” so easily… )
So doing this in blender is “just to see how it looks like”… and tells you nothing about the posible performance…
…and… i’ very curious how this would be used and usable to texture any asset 
i’ very curious how this would be used and usable to texture any asset
Well it’s far from ideal.
But the dev has 0 experience in shaders, and did not provide any design / tech doc; so, knowing that there would be ~20 different assets, with the same material, and that I would tackle only one asset, I had to establish a material that could be shared between them, for consistency, for the other artists.
The current setup has a palette on 256x256texture, that two different UVmaps use, one for color, and one for emission drivers; and two (but I decided since to throw away one of them) 2K textures: one for roughness / metalness (that two different UVmaps use for each aspect), and one for grime, with its UVmap (this one I threw away).
Then I fed the same map + UVmap of roughness to the height of the normal, with a very low effect.
(in the screenshot, top left the R/M texture; bottom left, the R/M UVmap over the color texture, to show that all the UVmaps are colliding/overlapping, while diffrent, and can’t be added before the texture node in the graph).
This way, the material can easily be reproduced in Unreal.
But yeah, I had to throw away the channel packing idea, because of the 4 UVmaps.
You might still be able to pull it off. I think UE allows up to 4-8 separate UV maps per object.
I just glanced through this video, so I don’t know exactly how pertinent it is to what you’re doing, but the guy’s showing how to use multiple UV sets for objects, and is exporting from Blender into Unreal.
…this… i have a to bookmark…
because just reading it now… thinking ahhh… hhhmmm ummm… is not enough…
Thank you! I have to think a bit about it; at a glance, apart the masking it’s not different from what I did, but he says that 3 UVs could be already heavy on memory, and since the model itself is already not exactly low topology, I guess we (the dev at least) have to test it in engine.
Thank you again for your answers, they clearified a lot 
well…
1 UV = 2 values for a 2D vector per vertex:
depending on the system
1 UV = 2 int (2 byte)
1 UV = 2 float (4 byte)
3 UV’s = 6 values
compared to per vertex:
I think the texture(s) itself occupies more RAM than the actual geometry…
A texture of 1024 * 1024 * 4 (RGBA) byte = 4 mega bytes needed…
→ divided by 12 equals
That’s some hardcore street maff there, Doki.
Amazing work! Thank you!
