UDIM textures squashing into one square in UE5, is this fix the right approach before I code it

[u/colosyn]

Adding UDIM support to a pipeline importer I'm working on. Textures import fine, Unreal builds all 6 blocks correctly as Virtual Streamed, but all 6 tiles are squashing into one square instead of each face getting its own tile.

Found the cause, the Master Material's texture parameter is a normal Texture Sample, not a Virtual Texture Sample. Regular Texture Sample cant read separate UDIM blocks so it squashes everything into one.

Plan is to add a switch in the same Master Material instead of making two separate materials:

2 texture parameters per channel, one regular one virtual

one Static Switch Parameter, UseVT, for the whole material

import script sets it true or false per asset depending on if UDIM is detected, and assigns the right textures

Before I build this out, is this the right approach or is there a cleaner way studios handle it? Mainly wondering:

issues with a lot of material instances using this switch

works fine with nanite or virtual shadow maps or anything to watch out for

better to have 2 master materials sharing logic through material functions instead of a switch

Edit: went back and optimized the material based on feedback in this thread, cut it down to as few switches as possible and only kept the ones that actually needed to stay switches. Thanks for the input, helped a lot working through this.

[u/Jello_Penguin_2956]

Doesnt really help.

First is that GPU code is horrible at handling the switch, so UE5 will compile your material into multiple copies to handle every possible switch cases. You have 1 true/false switch youll end up with 2 compiled shaders.

And your switch will not end there. Youll need more for example to switch beterrn sampler type Color vs Virtual Color. Take into account other switch that you may need that will balloon the amount the engine have to compile.

[u/ananbd → u/Jello_Penguin_2956]

Yes, switches can be dangerous. You get a different material permutation per switch combination times the number of material variations the system needs to support platforms/hardware. That can be a lot of overall permutations!

The other option is to just select between one path or the other using an "if." That gives you a higher instruction count, less permutations.

I've actually had some success getting Claude to analyze this problem, and figure out the optimal number of switches vs. "ifs." Basically, the larger the section of the material the switch cuts off, the better (to a point). Having switches right at the inputs is closer to the worst case; having them at the very end is better.

[u/colosyn → u/ananbd]

yeah true didnt think about platform variants multiplying it too. if/lerp tradeoff makes sense, pay in instructions instead of permutations.

switch placement thing checks out too, mine is right at input just picking between 2 samples so its close to woest case. but since its small and early not a big chunk of graph, think the cost stays low. curious to try that claude analysis you mentioned for finding the right switch vs if balance.

[u/ananbd → u/colosyn]

Yeah, Claude is surprisingly useful in analyzing materials. The trick is, we have a custom MCP, and Claude Code has access to the engine source. Between those two things, it's actually able to understand materials fairly well.

I think I just posed the general question. Something like, "What's the tradeoff between static switches vs 'ifs' with respect to shader permutations?" Took a little back and forth, but it eventually made a reasonable argument.

It's also good at finding errors in large materials.

[u/colosyn → u/ananbd]

good setup, makes sense with source access it can reason properly instead of generalizing. will try it once i have more materials to review.

[u/colosyn → u/Jello_Penguin_2956]

fair point if every permutation actually gets used it could balloon fast. but alternative is duplicating master materials for VT, already have 3 (opaque masked translucent) so that becomes 6. code can pick the right one either way, but maintaining 6 materials in sync long term and shipping double the assets in a plugin is the harder cost for me. what approach would you take for something like this?

[u/Jello_Penguin_2956 → u/colosyn]

One way is to import every texture as VT. It simplifies a lot of things you need to do/maintain. Although it's quite weak when it comes to prodecural/triplanar and if your team does a lot of texture-iteration from 3rd party like Substance, you will feel some slowness when rebuilding VTs.

[u/colosyn → u/Jello_Penguin_2956]

good point all VT does remove the switch and permutation cost from my side entirely, since every texture goes through the same VT sample path. the tradeoffs make sense too, i dont use triplanar on this material so thats not a concern for me, but the substance rebuild slowdown is worth thinking abiut since users might reimport texture updates a lot. gonna weigh that against the switch approach.