Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Calculating Unity's tangent basis for xNormal?

Discussion in 'Shaders' started by SONB, Jan 12, 2010.

  1. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    I think, you should post your code anyway. Even if there's nobody who can continue what you begun now, there's a chance that he/she will appear later.
     
  2. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    Ok guys, sorry for the very late reply. Was not following this thread...

    So short version on how Unity computes the tangent space is: it's Eric Lengyel's code that computes the tangent basis per triangle. Then over whole mesh, some tangent space averaging happens if the spaces of neighboring faces are close enough. Finally, in the shaders the binormal (err... bitangent) vector is always computed from normal tangent. So the tangent space is always orthonormal; which means you can't have much skew in your UV mapping.

    We could and should switch to something more standard robust (e.g. Mikkelsen's code) at some point, but we haven't done that just yet.

    For now though, if anyone wants to write some plugins for external tools like xNormal, here's our tangent space computation code: https://gist.github.com/2843984. Nore that it won't compile out of the box, I just pasted relevant portion of a larger file. But it should give the idea actual details what's going on.
     
  3. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Aras, I could hug you! Thank you :D

    I'll try and get this implemented tomorrow and see where it gets me.
     
  4. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Quick question;

    CreateTangentSpaceTangentsUnsplit ()

    I take it this is what happens when you untick the "split tangents" box.

    When it's the "split tangents" option is selected, is it the same function except with the default 89 value for the smoothing angle or is there a different function for that?
     
  5. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    From what I can see, the tangent space calculation is the same; and the "unsplit" part of the function name is some historical artifact only.

    What the "split tangents" option does, is before tangent space calculation, it makes the vertices across UV seams to be unique. So that later on the code that tries to merge similar tangent spaces in adjacent faces never does that if UV seam was involved.
     
  6. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Gotcha. I'm doing that already in my code anyway, so that's cool :)
     
  7. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    OFFTOP:

    Farfarer,
    I don't believe in god, fate and that kind of things. But looks like something like that is actually there.
    You just decided to abandon what you tried to do - and look what happend. Graphics Developer we've been waiting for so long had finally visit this thread. I guess, it's your sacred destiny to write this xNormal plug-in and share it with community. :)
     
  8. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Aye, nae pressure... :p
     
  9. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    No pressure, just trying to inspire you. :D
     
  10. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Welp, I got it integrated with xNormal and compiling eventually. The results are closer, but still a little off.

    I think it's because I'm taking some slightly different routes with my code compared to Unity's (which I only realised would have such an effect after I'd turned my PC off for the night and lay in bed).

    I'll try and sort that out tomorrow or Sunday, if/when I get time.
     
  11. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    No matter what issues you have now, you're still doing a very important job. If/when your xNormal plugin will be finished and published - it will be a fantastic news anyway. Even though there's no production-ready results yet, I guess, it's incredibly difficult task. And it definitely worth doing it.

    Just wanted to thank you for what you're doing.
    I'll try to keep silence in this topic from now on since I have nothing to say on the subject (as I did for the first few pages). Like, I guess, most visitors of this topic do. Since we're not programmers.

    But I'd like to let you know that we may be invisible, but we're cheering for you. :)
    And what you're doing is awesome.
     
  12. Tim-C

    Tim-C

    Unity Technologies

    Joined:
    Feb 6, 2010
    Posts:
    2,221
    I'm really looking forward to seeing the quality difference.
     
  13. Ippokratis

    Ippokratis

    Joined:
    Oct 13, 2008
    Posts:
    1,521
    Hi,
    I have took a different path,
    I used Sculptris to create a bump map on a model, imported the model and its bump map ( grayscale image ).

    $Screen Shot 2012-06-03 at 10.30.59 AM.png

    I leave unity handle tangents creation and normal map texture creation (from bump).

    The results are ok :
    $Screen Shot 2012-06-03 at 10.55.34 AM.png


    An example workflow would be :
    1. Make a mesh in a 3d modelling program, using quads. There are some restrictions on how to make the model (max 24 "connections" to a vertex, max 4 edges to a polygon, more to find out ).
    2. Import in Sculptris to create texture and bump maps, it has some nice paint tools.
    3. Animate in a 3d modelling program.
    4. Import in unity

    Now I work on a shader that allows using bump maps and lighting in a custom toon shader. The first results are not that bad:

    $Screen Shot 2012-06-03 at 10.30.43 AM.png
     
    Last edited: Jun 3, 2012
  14. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    I tried this method, too. But there's one huge disadvantage: any bump map is actually a height map. And standard 8-bit color depth is usually not enough to represent details in normals using height map. But it's enough to represent it using normal map. It's hard for me to explain it in english. But in fewer words, you can have a veeeeery insignificant height variations (which simply won't be stored in 8-bit height map) while normal variations in this point are very noticeable. I can create some screenshots later if it's difficult to understand what I tried to explain here.
     
  15. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Still having issues with this. In the same place as before, even with the new code.

    Essentially, the FBX file isn't always particularly well optimised. There are sometimes multiple verts that share identical values (position, normal and UV coordinates) but have a new indice in the master list. So you end up with a duplicated vertex and that creates a split in the mesh where there shouldn't really be one.

    When I'm making the arrays for Unity's tangent basis calculator (i.e. converting the data I have access to in xNormal into the format that the code Aras provided uses) I run checks and optimise these duplicated vertices down to one vertex rather than 2 or more because it seems that's what Unity also does.

    The issue is that the tangents generated at those points where there were splits are wrong by a small amount.

    If I don't optimise the duplicated verts, then I get huge splits in tangent space that are just plain wrong.

    For example here are the raw tangents as exported from xNormal to an image. I have a shader to compare these tangents against the vertex tangents that Unity generates and output the absolute difference in those values, to let me know that the tangents are the same. I've already tested the raw normals the same way - they are identical to what Unity imports.

    Top; Unoptimised vertices, you can clearly see the big splits.
    Bottom; Optimised vertices, this has no splits, just like the tangents Unity generates. What Unity generates looks pretty much identical to this, but not quite.

    You can see from my test shader, that the tangents are still incorrect. The effect is exaggerated tenfold in this image, for clarity. The fuzzy dark grey polys are fine but the whiter areas show the difference between mine and Unity's tangents. Same shade of grey across poly = good, gradient towards white = bad.



    Any thoughts?

    I've tried using the unoptimised mesh and averaging the tangents at the split verts. Both before and after orthogonalisation. Results are worse than using the optimised mesh.
     
    Last edited: Jun 6, 2012
  16. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Never mind, got it working!
     
  17. Ippokratis

    Ippokratis

    Joined:
    Oct 13, 2008
    Posts:
    1,521
    Farfarer :
    It wasn't changing the warp mode from repeat to clamp, right ?
     
  18. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Haha, no. Not quite that stupid, but close. Seems it was a precision issue.

    I had been using xNormal's own Vector class for storing the tangents and binormals, rather than Unity's custom Vector3d struct.

    xNormal's class uses floats to store the components and Unity's uses doubles.

    I didn't think it'd make much difference, but I changed it all over to use Unity's Vector3d class and voila :)

    So I need to run a few final checks and see what method does the best conversion from object to tangent space for Unity's shaders. Give it a run through some test cases then - all things well - release it as a beta.
     
  19. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Quick update, I've found and ironed out some issues with the binormal being generated incorrectly at edge cases. So now everything is perfectly synced - normals, tangents and binormals. Meaning I'm getting perfect bakes out of xNormal for Unity's normal mapped shaders :D

    Meaning... it works \o/

    I still want to try and speed up some of the vert optimisation code, running a bake on a 13k tri mesh I had takes a lot of processing. And I'll need to build it for the latest version of xNormal, too.

    So probably won't be released 'til next week or so as I'm off to Download festival tomorrow until Monday :)
     
  20. brn

    brn

    Joined:
    Feb 8, 2011
    Posts:
    320
    Congrats Farfarer,

    Fantastic news on allot of hard work!
     
  21. Tim-C

    Tim-C

    Unity Technologies

    Joined:
    Feb 6, 2010
    Posts:
    2,221
    You know you can not write all this without posting some pics ;)
     
  22. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Sorry, was at work doing it while waiting for automated tasks to finish. Didn't have time for pics.

    As an example, here's the mesh copenhagenjazz was testing on with the previous (broken) version, which I've been doing most of my testing on;
     
  23. copenhagenjazz

    copenhagenjazz

    Joined:
    Oct 2, 2005
    Posts:
    45
    James youre a genius. Well done!

    UT should send you a bag of money :)
     
  24. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Last edited: Jun 13, 2012
  25. DangerSnoot

    DangerSnoot

    Joined:
    Nov 23, 2009
    Posts:
    213
    Downloading now. Not been this excited to try out software since Skyrim came out.

    You're an absolute legend! If ever we meet I'll buy you a pint.
     
  26. J_Moller

    J_Moller

    Joined:
    Jan 24, 2012
    Posts:
    7
    Thank you Farfarer.
     
  27. DangerSnoot

    DangerSnoot

    Joined:
    Nov 23, 2009
    Posts:
    213
    OK, I've had a shot with it, but can't seem to get it to work. It throws this error when I try to bake;

    "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

    Have tried with obj, fbx and 3ds files, created new meshes to try from scratch and attempted to create extremely simple ones which would use very little memory. Models also don't appear correctly in the 3d viewer. Everything works fine again when I swap back to Mikk - TSpace.
     
  28. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Argh, I've had this issue too. Not with my plugin specifically, just in general with xNormal. I thought it had been fixed in the latest release.

    It seems certain models or combinations of file formats cause it to throw that error but I've not found out exactly what. Sometimes it works and sometimes it doesn't.

    Oddly, I've found that altering the vertex normal settings of the high poly mesh from exported to averaged can fix it sometimes.

    What are you exporting from? Are you exporting with explicit vertex normals? I think I foolishly took out my fallback for when a model doesn't come with it's own normals.
     
  29. DangerSnoot

    DangerSnoot

    Joined:
    Nov 23, 2009
    Posts:
    213
    Gah, I'm such an idiot. I've just forgotten to export vertex normals, I'm almost certain that's what it is. I'm so used to xNormal calculating them that I just ignore the box on export. I'm using Blender 2.61 so I don't think the exporters for FBX or 3ds have the option, but I know it does for obj. Give me a few minutes to get my stuff up and running and I'll see if that fixes it.
     
  30. DangerSnoot

    DangerSnoot

    Joined:
    Nov 23, 2009
    Posts:
    213
    Yep, problem solved. Normals are looking sexier than ever. Thanks again!

    $Block test.png
     
  31. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Yeah, next step is to replicate Unity's normal algorithm so that meshes fed in without normals can work just as well when telling Unity to Calculate rather than Import normals.

    *groan* :p
     
  32. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    I guess I'll need to paste our normal calculation code then? :)
     
  33. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Definitely no rush for that one, heh. I've got a lot of other stuff to be getting on with. Gotta do a full rewrite on a core component of my game, shaders to write for people...

    So folk can deal with requiring explicit normals, that's easy to export :p
     
  34. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    Sorry for such a late post. I've got a chance to test Farfarer's plug-in only now. I mean, to test on real-production example.

    I have made 2 variants of the same lowpoly model (character's shoulder armor). They have absolutely the same topology, but are different in edge smoothing and UV-mapping:
    1. has hard edges where they're supposed to be. Therefore, has a lot of UV shells since every hard edge has to be at UV seam.

    2. has a single UV shell and hard edges are only at UV seams. All the rest edges are smooth.


    Then I have baked 4 normal-maps, using MikkTSpace and Farfarer's UnityTSpace plugins for both of these models.

    Here's what I have in Unity as a result:



    As you can see, yes, using UnityTSpace for smooth mesh makes some sence: normals look better then with smooth-edged MikkTSpace-bake. But both maps baked from smooth-edged mesh looks just horrible compared to both other maps (baked with hard edges and UV seams on them). Which are exactly the same, no matter were they baked using default xNormal TSpace or Farfarer's plugin.
    So, yes, using Farfarer's plugin gives you some advantages. But eventually you still have to do it old-school: manually create all the hard edges and make sure that all of them are at UV seam.

    Didn't want to offend Farfarer. He did an amazing work anyway.

    Some details:
    Models were exported from Maya to OBJ with normals and smoothing. The same OBJ's were imported both to xNormal and Unity. Unity's settings were default: Normals set to "Import", Tangents set to Calculate, "Split Tangents" checkbox ticked.
    Textures were baked at 1024*1024 to png. PNG's were imported in "True Color" mode in the same resolution.
     
  35. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Interesting. UV seams at hard edges is just good UVing, regardless of what you bake it in.

    What's strange is just how identical the results are - there should be some tiny difference at least.

    Any chance you could throw me the meshes over? See if I can figure out what's up?
     
  36. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    I guess,some difference is there. But it's so tiny that it's impossible to keep it in 8-bit image, so resulting normal maps are identical. Or maybe there's just some little bug. :)

    Just got a permission from our project manager to upload this model. Here it is:
    0-Shoulder-Hi.7z - Hipoly mesh exported from Zbrush.
    1-Shoulder-Lo.7z - Both lowpoly meshes used for test + cage file for them. All OBJs are exported from Maya.
    2-NormalMaps.7z - resulting normalmaps I got from xNormal.
     
  37. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Thanks. I'll take a look.

    By the way, you use objs for importing into Unity in your real production environment? Not FBX?
     
  38. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    I had a look at it. I think that's as good as you'll get without normalizing the light direction per-pixel. Nothing I or any other baking method can do about that :/

    The issue is that the light direction is calculated per-vertex and therefore the light direction your shader gets per-pixel is interpolated between the 3 values at each vertex of the polygon (meaning the light direction vector gets shorter as you get further away from the vertices). Also, the greater the difference in light direction between the vertices, the more exaggerated the shortening effect becomes.

    So when you do dot ( normal, light direction ) to work out the lambertian lighting value, you end up with a value that's less than it should be. Meaning the lighting gets darker as you get closer to the centre of the polygon.

    However, normalizing the light direction per-pixel means that you're getting the dot product of two normalized vectors, giving the lighting value the correct amount.

    Same deal with spec, you'll need to normalize the view direction per-pixel as well, if you want that to be as good as possible.
     
  39. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    The shader I used for the screenshots above is default Unity's "Bumped Diffuse".
    You have mentioned a shader with per-pixel normalizing of view/light vectors. Do you have some? If you do, could you share it here, please? I still can't get some free time to get familiar with writing CG shaders. So if I could get 2 normal-mapped shaders (the one using per-vertex light calculation and the other using per-pixel), I can then at least compare them and remember how I need to modify default Unity shaders to make them work as good as they should.

    As for OBJs - no, we use FBX. But it's exporting GUI has SO MANY OPTIONS that I prefer to use OBJ for simple tests. You don't need all that stuff for test, right? :)
    For production we use automatic export to FBX via our "standard" presets.
     
  40. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Yeah, it's just best that the object you bake with is identical to the object used in the game. There could be differences that throw off the results is all :)

    This'll normalize the light direction in the pixel shader;

    Code (csharp):
    1.  
    2. Shader "Debug/Normal Map Only" {
    3.     Properties {
    4.         _Color ("Main Color", Color) = (1,1,1,1)
    5.         _MainTex ("Diffuse (RGB) Alpha (A)", 2D) = "white" {}
    6.         _BumpMap ("Normal (Normal)", 2D) = "bump" {}
    7.     }
    8.  
    9.     SubShader{
    10.         Tags { "RenderType" = "Opaque" "Queue" = "Geometry" }
    11.    
    12.         CGPROGRAM
    13.  
    14.             #pragma surface surf NormalsOnly exclude_path:prepass
    15.             #pragma target 3.0
    16.  
    17.             struct Input
    18.             {
    19.                 float2 uv_MainTex;
    20.             };
    21.            
    22.             sampler2D _MainTex, _BumpMap;
    23.            
    24.             void surf (Input IN, inout SurfaceOutput o)
    25.             {
    26.                 o.Albedo = float3(1.0);
    27.                 o.Normal = UnpackNormal(tex2D(_BumpMap, IN.uv_MainTex));
    28.             }
    29.  
    30.             inline fixed4 LightingNormalsOnly (SurfaceOutput s, fixed3 lightDir, fixed3 viewDir, fixed atten)
    31.             {
    32.                 lightDir = normalize(lightDir);
    33.                 float NdotL = dot(s.Normal, lightDir);
    34.  
    35.                 fixed4 c;
    36.                 c.rgb = s.Albedo * saturate ( NdotL ) * _LightColor0.rgb * atten * 2;
    37.                 c.a = 1.0;
    38.                 return c;
    39.             }
    40.  
    41.         ENDCG
    42.     }
    43.     FallBack "VertexLit"
    44. }
    45.  
     
  41. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    Just tried your shader...
    I don't want to look like the one annoying guy. But no, it didn't help:

    This weird contrast on some edges - I don't think it's what supposed to be. The most weird thing here is that these artifacts appear randomly - 2 of them are at smooth edge (inside UV shell, not at UV seam) and one is at hard edge (at UV seam).
     
  42. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Hmm, you're right.

    I'll debug it some more, see if I can figure out what's up... will probably take me a couple of days, I've got a lot of stuff on at the moment.
     
  43. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Well, I've found the issue, but it's not one that I can easily put a blanket fix in for.

    The issue is that when you import your normals and calculate your tangents, the "Smoothing Angle" option for your mesh object is greyed out, but it's still used when calculating the tangents.

    What you can do to fix this issue is set Normals to Calculate, change Smoothing Angle to 180, then set Normals back to Import and it will recalculate the tangents using the same smoothing as my plugin uses.

    It's a fiddly workaround but you could set up an AssetImporter script to automatically set Smoothing Angle to 180 on mesh import.



    So the options for a more permanent fix are either...

    • The guys at Unity make Smoothing Angle default to 180 "behind the scenes" when Normals are set to Import.
      + Solves everything.
    • Or do I set the Smoothing Angle I use in my code to the Unity default of 60.
      + Solves default cases.
      - Creates ugly seams in the resulting normal maps when a tangent split occurs but a UV/normal split doesn't.
      - Creates incorrect normal maps for users who have changed this value from it's default setting.
    • I set up user options for my plugin to allow the user to specify the Smoothing Angle for their bakes.
      + Solves all cases.
      - Creates ugly seams in the resulting normal maps when a tangent split occurs but a UV/normal split doesn't.

    My feeling here is that it's a bit of a bug/flaw with the way Unity handles things. If you're importing the normals, the smoothing angle shouldn't really have any effect on any part of the mesh 'cause the smoothing's already been done. I'll report it when I get home this evening and see what happens :)



    I didn't come across this issue while developing the plugin because I had been exporting all of my test-case models with one smooth group. So I had just put the Smoothing Angle up to 180 regardless of whether I set Normals to Import or Calculate. D'oh!
     
    Last edited: Jun 21, 2012
  44. Kuba

    Kuba

    Moderator

    Joined:
    Jan 13, 2009
    Posts:
    416
    Please do. It would be great if you could attach all the relevant info (the mesh, xNormal version you used, your plugin, etc.).

    Cheers!
     
  45. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Will do :)
     
  46. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Submitted, Case 472207.

    Ta :)
     
  47. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    Farfarer,
    Just read your post. Great thanks for the solution. :)
    As for me, it doesn't matter if it is a bug or not. What matters is that now we have at least a way to fix it. So we can now use "normal" normal-maps. :)
    Of course, it would be better if Unity team fix that somehow, so that we won't need to manually set all this stuff after importing each mesh. But for now it's at least fine. Not good, but not bad either.

    I can't test your method right now, so tired after very hard day. Sorry for that.
    I'll test it tomorrow at this model (and some other, much more complex) and report here if it gives sufficiently good result or not.

    OFFTOP (a little):
    What I can say now is that I think you really shouldn't even try to fix this issue in your plugin. That's definitely Unity's issue. And Unity team should fix it, not you. You have already done more then enough to create "dog-nails" for their veeeery ugly normal-mapping mechanism (not sure if "dog-nails" sounds good in english, I hope you understand that I meant "kind-of-temporary-fix").
    We have a workaround for now. Not so bad. And if we want to have it good then we shouldn't even try to reanimate something what was born dead. We need to have a complete replacement for that with proper one. As I remember, some of Unity developers have mentioned in this thread that they're going to replace their entire tangent-space calculation algorithm with MikkTSpace. And he mentioned that they're going to do it in v4, which is almost released.
    I think, this is the best solution. So what we can do now is simply wait for v4. For current projects at Unity 3.5 we've got your plugin and this is enough. Thanks again. :)
     
    Last edited: Jun 21, 2012
  48. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    Whoa, whoa.

    We said "yeah perhaps we should just implement MikkTSpace". This is very different from "we're going to implement MikkTSpace". And certainly much different from "we're doing to do this in Unity 4".

    Do we want to do that? Yes. Did we promise to do that? No.

    Just trying to avoid "bbbut they promised!" drama again ;)
     
  49. Farfarer

    Farfarer

    Joined:
    Aug 17, 2010
    Posts:
    2,249
    Eh, MikkTSpace is good solely because it's a standard created that's supposed to have concrete methods for dealing with problem cases. It's not a superior method nor does it give better results, it just gives consistent results when you feed it bad or ambiguous data.

    The important thing is that the baker and the renderer replicate the tangent space matrix identically... doesn't matter what standard or method you use. Which is the situation we have now :)

    Currently only xNormal and Blender support MikkTSpace and it's not really likely that anything else is going to. If Unity3D picks it up as they said they were investigating (not promised!) then that's cool, but you won't notice a difference in the quality of the normal maps rendered in-game between MikkTSpace and UnityTSpace. Also, only xNormal or Blender users would be able to generate MikkTSpace normal maps.

    So long as the tangent basis in baker and renderer are synced, you won't notice a quality difference. Whether it's MikkTSpace, UnityTSpace or anything else...
     
  50. Lex-DRL

    Lex-DRL

    Joined:
    Oct 10, 2011
    Posts:
    139
    Farfarer,
    Just tested the new method.
    There are 3 screenshots below:
    • Default method:
      • A lot of hard edges: every noticeable corner has hard edge on it.
      • Therefore, a lot of UV shells: every hard edge must be at UV seam.
      • Baked in xNormal using default MikkTSpace.
      • Mesh imported to Unity with default import settings.
    • Your plugin used:
      • Not so many UV shells. There are only a few of them just to make it unwrapped with minimum distortion.
      • Again, each edge at UV seam is hard. All the rest edges are smooth.
      • Baked with your plugin.
      • Imported the way you described.
    • The same as previous + your debug shader used.
    And here's what we have in Unity:

    There are still some artifacts. The most notticeble are:

    I have already asked our project manager to send you these meshes, too. He let it, but only personally to you, not here in this thread. I send you a PM with the links to the meshes.

    I don't know about technical details. But normal-maps generated in xNormal are visually the same for me as a 3D artist both in xNormal 3D viewer and Maya viewport. They may differ in some insignificant aspects. But visually they are exactly the same. I even never thought about this tangent basis things before. I was just baking the mesh in xNormal and had it exactly the same in Maya.



    Aras,
    Sorry for misunderstanding you.

    Anyway, even with this being said I don't think it's good idea for you guys to further enhance current normal-mapping mechanism in Unity. You'll spend too much time to implementing and debugging what's already implemented and debugged. On the other hand, it's impossible for guys outside Unity team to make current mechanism good anyway.

    Was normal-mapping implemented in Unity for a long time? Yes. Was it implemented good enough? No.
    And I agree with you, you really should switch to MikkTSpace as soon as possible. Maybe not in v4 or even in v4.1. But really soon. About 4.5 tops.
    Because proper normal-mapping isn't a technology of tomorrow. It's even not a technology of today. It's yesterday's technology. And each modern engine has at least a tool to bake proper normal maps.

    Even our very small team, that haven't released any game for now (2 projects are in development, 1 will be released soon) have a very hard thinking about switching to UDK for our next project. Even considering their very... "interesting" pricing policy and very high difficulty of customization.

    If I get it right, you have announced DX tesselation in Unity 4. I don't know if it will be implemented like normal-mapping is in Unity currently or it will be done as good as in engines like UDK or CE. But I think it will be very strange if new Unity has DX tesselation (doesn't matter proper one or "kind-of-proper") and still don't have a proper normal-mapping.

    Sorry if I expressed myself so blunt. I didn't want to tell something like "You guys are making a very bad engine", no! What I tried to say is "Current Unity has some disadvantages. Not many, but they are huge."
    Some of this disadvantages are not so important, but some of them (like normal-mapping and lens flares) are crucial. If you fix that, then I really believe a significant part of all the world developers will switch to Unity (maybe except the ones that are doing AAA-class FPS). Again, I'm telling that as a 3D artist, not as programmer.