Hey hey! So as for the first question, the beginning section of our math will quantize the 0-1 space in to equal sections by using Floor, which rounds the value down to the nearest integer. We do this after multiplying it by the number of sections we want. So let's say we want 10 UV sections, for simplicity's sake. If our shrunken UV island has values like 0.24, 0.25 and 0.26, then we multiply it by 10 (now 2.4, 2.5 and 2.6) and then we Floor it. (Now all the values are 2) Then if we subtract 2, those values become 0 while all the other values around them are non-zero. We can Absolute them (turn the negatives in to positives) and the 0 values stay at 0. When we OneMinus the result, we get our beautiful bitmask! :) ---------- For the second part, imagine we have 2 groups of vertices. ABC and DEF. Both of these are mapped to a texture in UV0 as per normal and apper to be overlapping. ABC's UV2 values are in the "3" section of our grid, while DEF's UV2 values are in the "5" section of our grid. Texture 3 gets put through the "atlas function" to be masked on to triangles that are in the "3" section of our UV2 grid, and appears black on any other triangles. Texture 5 gets put through the "atlas function" to be masked on to triangles that are in the "5" section of our UV2 grid, and appears black on any other triangles. We can then sum the results for our desired outcome :)

To call a sampler only once, people came up with a great invention - texture arrays. =))

@@williamgodwin5582 Texture array doesnt have mip maps

made me hungry

Great analogy! I love it!

Does this work for wings too?

A texture requires another texture sample/lookup, which is a lot more expensive than using some math to separate the sections. I guess the upside is that you can mask between materials on a per-pixel level. You could also use gradient-packing to get 12 masks for an RGBA texture (0, 0.5 and 1 per channel) As for using a UDIM-style method, it's definitely a banger! I do something like that for my characters which need non-overlapping UV's for their damage painting, and it doubles up as a mask.

If you don't mind please can you share the link to the dev blog that you mentioned.. cheers...

@@0rdyin It was dev blog #11 and was about character customization: kzfaq.info/get/bejne/d5OAY8-dssnPg6s.htmlsi=am-0shksVqkSW-Ai

Update, I've been adapting lots of assets to this system and it works PERFECTLY in VR in Forward Shading, is such a game changing feature! It saved us like half the drawcalls in most cases, in some even more than half the drawcalls :D

Haha that's the exact same problem I ran in to - Vertex Colour is sacred and should be saved for more important things. They're also a bit hard to manage if you want to re-order them etc. UV maps are much easier to edit! Thanks for the kind words :)

Haha glad to hear you're digging it!!

@@PrismaticaDev Next I get to figure out if I can get some random color variation options (or get it to work with the custom data colors). I've got it partially but it's only applying to the first texture so I've got some exploring to do! :D

Yep, very good point there! Every material instance that has a different switch configuration gets recompiled as a completely different shader. I think finding the balance between having them be broad enough to encompass multiple objects, but also with as low complexity as possible is the key. For example, my “floors” instance had a couple of mostly redundant layers that only appear in 2 assets out of 20 etc

Just gotta know where to cut corners! And also there are a lot of Static Switches which are defaulted to "off" so they don't get counted in the shown instruction count in the material graph.

@@PrismaticaDev do you offer a masterial material that works with this function. The example mat you created is a ltttle hard to follow and Im currently using Easy Mapper which would tough to integrate without help.

That's a very good find! I can see why it would affect the Early Z-pass negatively, since it would be testing against all textures at once

@@PrismaticaDev That's what we thought too, yes

@@riversandwine out of curiosity, are all of your texture samplers set to "shared: wrap or just left default?

@@PrismaticaDev "shared: wrap" due to the amount of texture samplers and because it doesn't seem to have any downsides.

Yep yep! You could absolutely do that - the only reason I opt to do otherwise is since I only tend to use 1 texture per "layer" and the rest is weird colour logic. I'm not sure how MaterialAttributes blends handle empty entries (might be doing a lot of unnecessary operations even if you aren't using specular/roughness) but yeah, for big photo-real materials you sure could :)

@@PrismaticaDev Thank you for your fast reply :D I have come to stress-test my approach finally last night... BlendMaterialAttributes seems to do take into account if the values are actually different from one another - like if you are blending between materials wich all have their specular channel set to 0, the instruction count goes down a bit... nonetheless the instruction count is ridiculously high for the blend. I have tried it with an If-node, that seems to work and gets the instruction count down a bit further. You can't Switch MaterialAttributes unfortunately though, it will implicitely cast the whole attributes to a single float vaule and blows it up into your face when you try to use it as input for the MaterialAttributes node. I have an other problem with this... using one texture for each material subslot seems to use a texture sampler each... When I get to the count of 16 material subslots, the material complains about having too many texture samplers. I looked into your video and you seem to have just 4 texture samplers active at once, despite having a texture for each subslot active... how did you do that?

@@Develavid nice finds! Also, for the texture samplers thing - click the texture sample node and check the dropdown on the left hand side and set it to one of the "Shared" modes. It will combine them and allow for 128+ textures per material. It's a must-have for landscapes hahah. I don't know why it isn't the default option since it has 0 downsides, I think it's just for backward compatibility with REALLY old hardware/rendering

@@PrismaticaDev oh MANY many thanks for this tip! You are fantastic!

@@PrismaticaDev I have given this approach a bit more testing... and it seems that when using If-nodes it doesn't matter if the If applies before or after putting together the material. An If seems to just use one shader instruction either way and it's the same instruction count to do it on the texture as to do it on materials putted together with a SetMaterialAttributes node (the MakeMaterialAttributes node doesn't seem to work in ifs... I have no [swearword] clue why that is) So it might be even cheaper on an instruction count basis to create the materials seperately and If-ing them at last - maybe even doing some SetMaterialAttributes afterwards to make global things like rain, wind and such things. When you make the StaticSwitchParameter the way that you even don't calculate the if when the material is not used, it saves some juice aswell. I may be doing a pastebin in the near future if I can get myself to it so I can share the stuff - if you are interested, that is. EDIT: Nevermind, it seems it doesn't matter if you are doing two Ifs which hook to one material or two materials that hook to one If... The instruction count is the same. Apparently it is implicitely calculating the if for every material input and even optimizing itself against things that are hooked up the same way in different materials... so it may even not matter how you line it up.

I've had a look in to them a few times - definitely a very useful tool, although I'll need to look in to how they're allocated in memory. For example, if only a few of the textures are being used, the entire array is still loaded in memory (probably not the biggest deal) but if a texture needed to be changed as a one-off, would creating another texture array allocate space for ALL of the duplicate textures? From what I've read the texture arrays are more performant because they have a fixed address or something that makes it easier to find and sample, my only concern is the flexibility of it. And also apparently mipping doesn't work with them (not a big issue for me, but could be for others)

@@PrismaticaDev Yes, the texture array is always in memory (as long it's used) and in my opinion really nice for objects that are static - but these are often a lot. For example the city I am working on. Yep, these buildings are static so there won't be any changes over time. Also these building are always present, so the texture were in memory nontheless. So an array is really suitable and for me - also pretty flexible. Before doing anything, it needs to have a plan what is needed, but when this step is done, it's easy to maintain (drag & drop array). In Blender I do have a script, that is converting the materials to vertex colors (every material does have an ID and this is applied to the vertex color) and you get also a nice visual representation. About mip mapping - in my experience this is a rumour that is wrong and maybe a thing when the arrays were new in Unreal. Yes, on default you don't have mips, but when you go down the options and search for the regular mip map settings, you can turn them on. Tested it, worked. EDIT: Oh, and one of the most important benefits of using texture arrays. My whole city is consuming just two texture sampler slots (four, if you want to blend).

@@PrismaticaDev Does this mean with your method, if a material slot is not being used those textures won't be loaded into memory?

@@aukehuys2297 I can't find the docs or information on texture arrays. Is this an array in the material or a data asset that can be set up and accessed by a material?

KEKW

Hey hey! I have looked at it indeed, and it should be implementable using this same UV-island method as the masking/blending method. The only reason I haven't used it myself is because my materials are quite simple in terms of texturing compared to other games and it seemed a bit overkill, and it's also hard to know how well it scales/its performance since it's a bit more under-the-hood

Using material layers, how would you map the relevant faces on to their respective material layer? Say i've got an asset that's a wooden chair with metal legs, how would I tell Unreal that the legs need to use the metal layer and the rest needs to use the wooden one? As I understand it the layer blending happens using a texture mask, but would that not come down to the same system as this video, still needing the seperate UV channel to put the UVs on the relevant part of the mask (say that we use 0(black) for metal and 1(white) for wood, putting those UV's on either black or white)?

Sounds like an awesome read! I’ll have a look in to it :)

Hey hey! Yeah I did realise that (a little too late :P )

Aw yeah

Hello - press "1" and left click. It's a static scalar value

Hey there! You can do strips in the X and Y axis and the multiply them together to create a grid. The only trouble with a flip book is that it is taking a pre-existing texture atlas and blowing each section up to full size, where as what we’re doing is completely modular

@@PrismaticaDev thanks! I just did the vertical strips. Too much trouble to worry about a grid

It works for all styles. You can blend the moss/dirts using Vertex Colour/Paint which I also have a video on :)

@@PrismaticaDev Cool! Thank you for the video

Hey there! Just planning on PC currently, although using this method is a big time-saver as well when it comes to designing levels :) And the extra juice is always good to have for some cool effect later on

​@@PrismaticaDev Right! That seems logical, thanks! :)

Hey there! I haven't actually looked in to HLODs yet since Prismatica is a top-down game and we don't run in to many LOD issues yet haha. Definitely something I want to cover in the future

You could technically write a For loop in HLSL custom nodes and declare the variables there perhaps? I’m not too sure

Absolutely - I have a few master materials. Characters, Foliage, Props, Landscape and Trees all have logic that is very different to one another so they all have their own specific material setup.

@@PrismaticaDev Thank you very much, you are the best!

This is my question as well. By default you can only use 16 texture samples in a single material before hitting the limit on the sampler register index. So that would basically invalidate this entire process if you wanted to use full PBR materials for each of the slots. I've read that you can change the Material Expression's Sampler Source to "Shared: Wrap" or "Shared: Clamp" to get around that limit, but I'm unsure if that would be the correct way to address the issue. @PrismaticaDev It would be great to have some clarification on this.

Sure would be! :) You'd just need to add a switch for each "layer" that changes it's main UV channel's coordinates

@@PrismaticaDev awesome thanks for the info!

It's definitely more expensive than a regular shader, however compared to the cost of even just 1 extra draw call, it's miniscule. Check out my Devlog number 11 about my character material to see a comparison of 4 material slots compared to 1 (it's about a 300% gain)

@@PrismaticaDev I see, I will definitely check that out!

If you set the Sampler type to "Shared: wrap" you can have 100+ samplers in the shader :)

@@PrismaticaDev 👀oh

Did you ever figure this out?

Depends if you're using Nanite or not, which many people aren't

You can handle it that way, however this method is a little more flexible as you can have texture UVs that are outside of UV bounds. Although I'm not sure how UDIMs are handled in Unreal, so I might be wrong

Thanks for the reply, still trying to understand the UDIM in unreal I don't see how to make it into a material atlas.. I have two questions Does This videos atlas method support tiling down for high pixel density? if you choose the same slot would it blend the texture on top of eachother? @@PrismaticaDev

if it supports tiling then I think this videos method is better because virtual textures in unreal are more expensive

@@God0fTime Yep, you can scale/offset the textures to any size within the material without breaking anything, since we're only fiddling with the primary UV channel, not the "key" UV channel

so if lets say my material on section 1 was a 4k tiled cloth material, on the second section I could have a 4k hand drawn texture in a material and just offset and scale it to overlap the uv in the position I want right. if so that just makes udims pretty much pointless lol makes you wonder why this is not an engine feature.. I see they are adding uv tools to the engine so maybe we will get this built in.@@PrismaticaDev

It does increase the complexity slightly, but the benefit vastly outweighs the cost. Draw calls are the main bottleneck for rendering times, so this method can be up to 10x faster (not an exaggeration)

For these assets, they use multiple different textures - some of them are simple tiling textures (like the brick wall pattern) and some of them are baked atlases/high-low bakes. All of the textures are aligned using UV index 0, and then swapping between the textures/colours is done in UV index 1

You could use a secondary UV channel, you could also use Vertex colour which you can assign on import which might be easier. But either way you'll need to have a system figured out beforehand :) Actually now that I think of it, you can edit UV's in Unreal 5 now so that might be worth looking in to!

@@PrismaticaDev thanks kanye, very cool

soo i have successfuly implemented an atlas for my character material & merged the mesh, it has dropped the draw call from 60ish (i kinda separated the mesh by quite a lot of parts) to about 5, so thank you so much for this video! it's still a bit weird tho how there's still 5, i thought having 1 mesh and 1 material means like 2 draw calls or is there something else i don't know?

@@masgondi1 awesome to hear!! I'm sure your GPU will thank you haha. The extra draws might be from the lighting pass or from cloth sim if you're using it

Hey hey - TexCoord index 2 is being used for our "material mask" channel.

There are definitely upsides like the modularity, and downsides like the potential for extra performance impact, but at the end of the day both systems require a way to separate the sections of the material which is what the focus here is about (using UV's instead of an ID texture or vertex colours)

RGB or any texture keying requires you to have a unique texture for every asset which needs to have it's own individual unique Material Instance (so you can set the Texture param) In this method, the data is built directly in to the UV data of the meshes themselves. You could also use Vertex Colour, however it's quite difficult to do things like "select all verts with colour between 0.1 and 0.2" if you want to make adjustments like you can with the UV keying method

@@PrismaticaDev Ah that makes sense. Thanks for the in-depth response 🫂

It should still work perfectly, and all the Albedo/Normal/RoughnessMetallicAO will be in sync

I don't think Nanite bypasses drawcalls completely - from my understanding, it can "batch" together instances of the same material across different meshes since it essentially merges all meshes in to one GIGA-mesh. But it would be interesting to do some performance comparisons. This method greatly reduces draw time at the cost of shader complexity, so with Nanite it might be more performant (if using the same material across multiple meshes) to use smaller, simpler materials. Performance aside, this method is still extremely useful for ID-mapping and sectioning different parts of an object even when using Nanite

@@PrismaticaDev I did some really basic tests using a mesh with 3 materials vs 1 mesh with 1 material (fancy uv setup). Even using the same more complex 'UV mapped material' for both nanite and non-nanite version. It seems the nanite one is more performant at first glance of stats. I know most people talk about nanite using 'high poly stuff' and LOD aspect of it but my game is low poly, so the performance of material pipeline in nanite isn't talked about as much. I'll continue to investigate but I think it might be more performant, or at least have no performance loss of having independent materials now. If I find anything interesting, I'll post to prismatica discord.

@@namrog84 Would love to hear how it scales at the scene gets more complex and more different materials/meshes are added. Cheers!

You would be surprised :) From my observations and stresstests, eliminating even just 1 draw call has a much bigger impact than halving the shader complexity.

@@PrismaticaDev did you make a side by side comparison and observe fps increase with high complexity less call method? (While keeping all other parameters same)

@@loremipsum3147 Yes, I've done this in my Character Material video. With 800 character on screen, one set using a complex material in 1 draw call, the other set having 4 material slots using the simplest material possible. The difference was 50 fps and 15 fps if I remember correctly

Here's a timestamp :) kzfaq.info/get/bejne/d5OAY8-dssnPg6s.html

@@PrismaticaDev okay thanks I'm checking it right now. These results are very interesting because in Unreal Engine documentation (don't remember where exactly) Epic suggests prefering multiple material slots over per pixel control(blend/lerp) when possible, for performance.

The shader calculation isn't that much unti you start layering 10's and 10's of materials, and even then it is still up to 10x faster than using separate material slots

Hello, this tutorial should suit your needs if you follow it :)

Correct - the textures will be very "low resolution" because it's taking the colour of texture at that vertex point and using it to colour, so it's dependent on the density of the mesh. On the topic of the instruction count, the Vertex instructions are orders of magnitude cheaper. Imagine running those instructions for only 1,000 vertices vs potentially 100,000 pixels.

You would be surprised - when using this method on my characters, my frames went from 40 to 90+ with 100 characters on screen. The main thing to keep in mind is that the GPU does everything in parallel, but the CPU has to send draw calls one at a time. So it’s always a better idea to let the GPU do the heavy lifting

2 Days later maybe it's working, i simplified it from 16 to 4 for reason's but it has nice parametric and group structure now it's testing time I need to remap tree in blender. . . PS: Thank you for your creativity.

@@rotz360 it’s using a secondary UV channel - the original unwrap still exists in channel 0. Think of it like Vertex Colour, UVs are just 2 float values assigned to each vertex

It’s heavier, but the cost of sending multiple draw calls is much much more costly :)

@@PrismaticaDev oh ok thanks :D didnt know it was much more costly to have multiple draw calls. Thanks dude, still learning! :P

Can you elaborate on this more please? :)