Standard shader + Detail Texture UVs + Lightmap UVs?

Hello,

From what I understand, in Unity 5 the standard shader can use a secondary UV set for detail textures, however this is also the UV channel used to store lightmaps. Will we have to choose between having baked lightmaps or having detail textures?

Alternatively, does the realtime global-illumination mean we won't have to rely on baked lightmaps anymore?

It would be great if someone could clear this up!

 

I'm not sure, but I don't think it uses a second UV set for detail textures.

 

I have asked the same on different threads but got no answer so far what is very annyoing to me.

 

The dropdown allows you to select either UV0 or UV1 for the detail texture. Texture data isn't actually stored in the UV channel, it's just the UV coordinates. So you can use UV1 for both lightmapping and detail textures if you want.

 

But then that means your detail map UVs would have to be suitable for lightmapping, meaning no overlapping, even space distribution etc. In a detail texture you'd usually repeat a tileable texture across several faces, so you'd have many of your UV's overlapping which wouldn't work with lightmaps.

 

If you are not sure, why are you answering?

 

Because I wasn't able to check it right away, but I remember it worked fine with ligthmapping? It uses UV0 by default, and works fine with custom tiling and offset.
You should probably stop brainfarting in the threads that you have nothing to contribute to.

 

Absolutely correct.
Lightmaps have nothing in common with detail maps.
Lightmaps also influence on specular, so they need a separate shader-channel with a separate UV-Set:

1. Albedo, Gloss, Spec,... UV0
2. Lightmap UV1
3. Detailmap UV2
...

Unitys Standard shader does not provide this.
Please correct me if I´m wrong.

 

"Stored" may not be the term to use but he is right. You may be able to use UV1 for detail but it will be dumb luck since this UV set is optimised for lightmapping. This is almost useless if we don't have a proper control of this UV content.

We need more UV channels: this has been asked a long time ago by the users and I don't understand why we are limited to a UV shared with an other feature.

 

You are right and every map should have it's own UVx and tiling choice instead of imposing albedo, gloss, normals, etc to share the same UV set.

 

It doesn't make sense to have separate UV sets for every map.

 

It doesn't make sense to you and that's my point: the user shouldn't be limited to what makes sense to someone else.

I use the separate UV sets so I can break textures tiling paterns and have materials that look as good from afar than they do closer without using heavy textures.

This may not apply to most cases but is still very useful if you want to optimise your scene.

 

Most maps could share the same UV sets yes, but there are still plenty of cases where more than two UV sets is required. My main point with this thread is regarding the standard shader, which is going to be Unity 5's default shader for most materials, which supports a wide variety of features including detail maps with secondary UVs. However I imagine they don't expect us to choose between baked lightmaps and detail textures, both of which are useful and important techniques for realism in games.

After some googling I discovered a lot of threads about this issue, and one comment mentioned it may be coming in Unity 5.0, and I read another comment which seemed to say that the current beta supports more than 2 UV maps, though I didn't find any mention of this elsewhere.

So multiple UV sets may be Coming Soon(tm), I am just wondering how it might work... will "generate lightmap UVs" in the importer check for existing UV's on the secondary UV set, and if so, either move them to a new UV set, or simply generate a new UV set for the lightmaps?

Or are we supposed to just stop using baked maps and move to realtime GI? GI looks fantastic, but I have a feeling it would work best when mixed with baked maps. Especially if you had a big map, and you wanted the distant land/objects to look shadowed, but use GI up close.

 

Real time GI still uses baked maps so lightmaps UVs are still going to be usefull on bigger volumes like walls.

Multiple UV set won't be a problem since modellers sofware can manage a lot of them: I can go up to 99 channels in 3dsmax. But Unity will have to be clear about what channel does what so users don't get mixed-up.

Also, UV0 and UV1 are, respectively, channel 1 and channel 2 in Max. I don't know which one is the standard, (if there is one) but they might want to check it out before it gets confusing for some users.

 

I have nothing against more UV sets for different "features" of the material. Albedo, spec, gloss and normals though are maps that are tightly coupled and it doesn't make sense to have spec or glass map use a different UV set from albedo and normals. Detail map is what you need to break tiling and to make things look good at different distances.

 

You're correct about detail maps break tiling and make things look good at different distances, and also save texture memory and bandwidth. However no-one has mentioned using specular or gloss maps with a different UV set, which I agree doesn't make sense in most cases. The topic at hand is specifically about whether lightmaps would clash with detail maps in the new "standard shader".

 

@Marc Saubion said that, that's why my comment about it not making any sense had this quote:

 

Once more, it doesn't make sense for you, this doesn't mean this isn't a useful feature.

For example, when I'm making a tile floor, I might need a spec map of 1 tile while the normal and occlusion are 4 tiles.

This is the exact same workflow than detail map, but more evolved: it just gained a normalmap, I don't see how it could hurt to have more options.

 

Wasnt that what you were doing? Yep it was.

 

I know this post is old, but I'm having the same problem,
I searched on google but not found a solution, I asked in other threads and also not get an answer.
Someone there discovered how to solve this problem?

@duck post this image in another thread



UV3 is to "Whatever you like".
So, to have normal + detail normal + baked lightmap, i have to apply the detail normal in UV3 ?

Anyone know how to do it ?

 

In your Input struct, just create "float2 uv4_DetailNormal" (you can name the DetailNormal part anything you want).

The in your surf(), when you do your tex2D for the detail normal map, instead of using IN.uv_MainTex, use IN.uv4_DetailNormal, so that it samples the texture based on that UV.

 

I got the kind of issue but now related to Normal map misorientation due to the UVset0 . Can you help me on that please ?

https://forum.unity3d.com/threads/5-5-detail-normalmap-issue-with-standard-shader.451315/

 

Related Issue. I have an object with normal map that is NOT tiling, and main albedo that is NOT tiling. Now I want a detail map that IS tiling. this is possible unless you are working with 3dsMax, to tile textures and have them match, (i have been told) you have to scale the object uv's with a modifier and are unable to just set the tiling in the texture. This of course messes up the normal and main albedo tiling. Is there any way to get the tiling to match. I can get the scale to match but not the alignment. IE if I want to bake lighting in vray and have brick grout lines match, I cannot!!!!

 

Just multiply your in.UV by how much you want to tile, and only use that multiplied value as the UV value when you sample your detailNormal.

 

I'm running into this problem now as well. Going by the table posted above, I have a custom-made UVs in UV1, which still tile, but are unwrapped differently. The Standard shader allows me to select between UV0 and UV1, but I can't use UV1 if I generate lightmap UVs, as it'll overwrite whatever I did in UV1 myself.
I'm a little confused as to why the choice isn't between UV0 and UV3, since UV3 isn't a reserved channel. I'm not a max user, and I can't afford it, so does anyone have any suggestions for how I can move my UVs from UV1 to UV3?

Thanks

 

Yes it's very strange that they expose UV1 as the other option for the detail map slot when it's going to be overridden for most people. For our project, I simply wrote a AssetPostprocessor script that would check if there are UV1s on an object, and copy them to the UV3. The importer would also make sure Generate Lightmap UVs was off, to prevent our UVs from being overridden before they could be copied and then just use https://docs.unity3d.com/ScriptReference/Unwrapping.GenerateSecondaryUVSet.html to generate the lightmap UVs manually if needed.

 

hi to all. We've run into this problem too, I attach corrected Standard Shader (made from builtin_shaders-2018.1.0b9), that uses UV3 for detail and here is python scrypt for Blender, that get all models in scene, and if any of them have 2 or more UVs it duplicates UVs in way, that detail UV from UV1 go to UV3.

Steps:
- Download and unzip uv_tools to "C:\Program Files\Blender Foundation\Blender\2.78\scripts\addons"
- activate UV Tools - addon in Blender

- open uv3_add_script.py from archive "uv_tools" in Blender.TextEditor or copy/paste text from it to empty script
- backup models!!!!!!!!
- open models, that HAVE 2 UVs in Blender ( if more or less, script just skip mesh)
- Run script

- check is UV3 correct or not

- PROFIT!!

For moving into other versions, here is key-changes in shaders
in UnityStandardInput_UV3.cginc

Code (CSharp):

1. struct VertexInput
2. {
3.     float4 vertex   : POSITION;
4.     half3 normal    : NORMAL;
5.     float2 uv0      : TEXCOORD0;
6.     float2 uv1      : TEXCOORD1;
7.     float2 uv3      : TEXCOORD3; // added
8. //#if defined(DYNAMICLIGHTMAP_ON) || defined(UNITY_PASS_META) // commented
9.     float2 uv2      : TEXCOORD2;
10. //#endif // commented
11. #ifdef _TANGENT_TO_WORLD
12.     half4 tangent   : TANGENT;
13. #endif
14.     UNITY_VERTEX_INPUT_INSTANCE_ID
15. };
16.  
17. float4 TexCoords(VertexInput v)
18. {
19.     float4 texcoord;
20.     texcoord.xy = TRANSFORM_TEX(v.uv0, _MainTex);
21.     texcoord.zw = TRANSFORM_TEX(v.uv3, _DetailAlbedoMap); // ((_UVSec == 0) ? v.uv0 : v.uv1)
22.                                                           //changed to v.uv3
23.     return texcoord;
24. }
25.  

 

Hi @mitaywalle ,

Thanks for sharing. Really helpful.

We are having the same problem, and the Python script and cginc seem to be working with Unity 2018.2.2f1, using a deferred render path. We are trying to make this work with a forward render path, and so far no luck. Would have any advice for us?

Thanks!

 

Sorry, have no idea why this shouldn't work in forward

 

Because you only changed the referenced "Core" CGINC files for the Deferred and Meta passes in your

Standard_UV3.shader

. So the other passes, which are for Forward rendering, are still using the other StandardCore files and thus the default TexCoords method, not yours. You would need to modify

UnityStandardCoreForwardSimple.cginc

to include the texcoord3, as well as

UnityStandardCoreForward.cginc

to reference that modified cginc. And then replace the references to this one in your

Standard_UV3.shader

forward passes.