(Question) Should I do a single large texture or UDIM for an object like Human body?

Connor_Dang

Hi guys,
Should I do a single large texture or UDIM for an object like Human body? 
(what are the pros and cons of them in this situation)

For example:
x1 texture set for Face ( 2048 square )
x1 texture set for Head ( 2048 square )
x1 texture set for Body ( 2048 square )
x2 texture set for Arms ( 2048 square )
x2 texture set for Legs ( 2048 square )

OR
1x texture set for full-body ( 16K )

Thanks for your help.

oglu

Use UDIMs. Giant 16k textures are hard to create and inefficient for rendering. If only the head is on screen you have to load the full 16k texture.

motionblur

From the top of my head the most apparent pros and cons for a 16k sheet are these:

Pros: probably fewer render passes as everything shares one material, depending on your workflow one texture sheet might be easier to manage/texture than separate ones, maybe you can squeeze out a better texel density inf you can merge everything on one sheet.

Cons: more difficult to switch out individual parts of the mesh or even get rid of them if they aren't needed. Say you use the 16k texture sheet for your naked body and then the clothes on top. Now the clothes cover up everything except hands and face. The 16k tex still needs to be loaded into memory entirely, more difficult to optimize if you want to decrease texture resolution on individual bodyparts. You can't swap out indivitual bodypart textures.

Of course this depends entirely on your project. So this is also a kind of generic answer.

A mobile game would try to squeeze as much as possible in as few textures as possible (then again you wouldn't use a 16k tex in a mobile game to begin with, probably .

A background character in a large crowd might not justify using so many different textures while a hero character totally does.

So I'd say cost of performance and maybe managability for added flexibility and modulaity.

Others with more AAA experience than me will probably add some more points to this.

Connor_Dang

oglu said:

Use UDIMs. Giant 16k textures are hard to create and inefficient for rendering. If only the head is on screen you have to load the full 16k texture.

Thanks Oglu that's really make sense come to rendering.motionblur said:

From the top of my head the most apparent pros and cons for a 16k sheet are these:

Pros: probably fewer render passes as everything shares one material, depending on your workflow one texture sheet might be easier to manage/texture than separate ones, maybe you can squeeze out a better texel density inf you can merge everything on one sheet.

Cons: more difficult to switch out individual parts of the mesh or even get rid of them if they aren't needed. Say you use the 16k texture sheet for your naked body and then the clothes on top. Now the clothes cover up everything except hands and face. The 16k tex still needs to be loaded into memory entirely, more difficult to optimize if you want to decrease texture resolution on individual bodyparts. You can't swap out indivitual bodypart textures.

Of course this depends entirely on your project. So this is also a kind of generic answer.

A mobile game would try to squeeze as much as possible in as few textures as possible (then again you wouldn't use a 16k tex in a mobile game to begin with, probably .

A background character in a large crowd might not justify using so many different textures while a hero character totally does.

So I'd say cost of performance and maybe managability for added flexibility and modulaity.

Others with more AAA experience than me will probably add some more points to this.

Thanks for your deep explain motionblur.
Now, i know which way is suite for me Thanks again

oglu

UDIMs also do work with only one shader. No per face shaders needed. Render passes are the same for both solutions. 

Blaizer

I would use udims of 4096px. 

motionblur

oglu said:

UDIMs also do work with only one shader. No per face shaders needed. Render passes are the same for both solutions. 

That is actually really good to know. Doesn't that also depend on the engine used, though?
Even when the same shader is used, if you have to create different materials for the various UDIM sets used will that be batched into one on a skinned mesh?
Or in other words: Is there no performance impact compared to one texture sheet other than loading and unloading the individual maps from memory?

oglu

If the Engine is working with UDIMs like Unreal its only one material. 

sprunghunt

Unless  you're planning on having hundreds of characters on screen it doesn't matter if you need 4 or 5 materials per character to get a decent texture resolution. That's only 4 or 5 new sections in a scene that would have hundreds or thousands of sections in view. 

poopipe

7 2k maps doesn't add up to a 16k map. 
You need 64 2k maps to make a 16k map

Also
a 16k texture set is approx 1gb of compressed textures (for a metallic roughness material) in one lump. 
 which you don't want in a game ever

gnoop

 Do games use  UDIM nowday  ?    Or it's still multi material Id ?    Our  ancient game engine  doesn't support UDIM    but I read that Unreal does.   

  I mean in an actual game whatever Unreal is capable of?

   I believe some of its features  are designed for kind of   rendered animation rather than actual real time things.

How those UDIM tiles are  regarding  draw calls?  Same as mat ID?   using texture arrays with a single draw call ?

In a word having some performance advantage or otherwise?

 

poopipe

UDIM is nothing more than a standardised way of organising multiple materials - it has no relation to rendering at all.

Any engine that can make use of  texture arrays (or equivalent system) can render matching materials with different textures in one batch - any engine that doesn't can't.

If you want a UDIM implementation in your game you simply need to write some code that automatically assigns materials to material IDs based on the UDIM standard naming - although arguably that's unnecessary since most DCC packages support UDIMs and can presumably export the information 

gnoop

Thanks poopipe .    So it should be some per face index  like those 1001,1002  stored with the geo or it's still some code to execute during loading or run time that  assign per face mat ID  based on UV values?     

I mean if it's in the geo  already so why the code?      I never heard about storing it in  FBX for example.

  

oglu

Im not sure if thats the case. Its all done in the texture reader. You have only one material on the object. In case of offline rendering this is important for sub surface. Otherwise you get green artefacts between the material IDs cause its not the same trace set. 

oglu

This tutorial shows how we did this over 10 years ago with one shader.

https://youtu.be/ECAGPkA0l0s

poopipe

UDIMs are  for authoring/pipeline convenience and have nothing to do with what happens at render time.

The example above no doubt works but almost all the work the shader is doing is completely redundant when you can simply apply any number of materials to a mesh, tell each of them which texture in an array they should pull out based on supplied meta data (the UDIM stuff) .and then draw them all in one batch.
I'll grant that ten years ago that wasn't necessarily the case but it certainly is now.

Gnoop..Storing it in the fbx either happens automatically or would need a little bit of preprocessing at export - either way, the information about which texture set/UDIM/material is applied to a given face needs to be there and as such it boils down to a face:material assignment. 

oglu

In this case i would say thats not the case for offline rendering. There is no per face assignment happening in the background.

Doesnt UDIMs in Unreal work like virtual texturing. One giant texture and a lookup table?