Yeah sorry by synched I meant "matched" as you said in your original post, I wasn't very clear in writing that.
Do you mean that because your ts nm is not in xNormal's tangent basis, that any conversion of that map though xN will be flawed because of this mismatch? For what you're using the ts-to-os map for (dDo) it doesn't seem like it would matter? As an example, the Mud filter in dDo uses the direction from the OS NM correct? Since the details added by nDo aren't going to be large forms, are there any filters that you would actually want to take the nDo details into account?
Basically I'm thinking:
1) Does it actually matter that the OS map in dDo has your nDo details or not? (I would assume no but test the specific case you're working with)
2) If yes, does it matter that the ts map converted by xN to os 'matches' the ts nm. (Ie will the mismatch cause any problems in the final outputs from dDo? I would assume no, but again why not just test it?)
The answer to both of your questions would be yes, it can matter a lot.
There are many included filters with dDo that are small scale and orientation dependant that even minor normals errors could throw off. Mud is not the only example, sun bleaching is a nice filter I can think of off the top of my head. There is also lots of custom applications that one could make with their filter creator.
And, as you know, unsynced tangent basises can lead to very big, or very minor problems depending on the asset and the way its been set up as well as the target renderer. If we are going through the trouble of staying synced with handplane, why leave one step unsynced? it would sort of ruin the point.
With this feature, My perfectly synced normals workflow would be as such:
Bake WorldSpace (3ds max) -> Handplane w/ Unity tangent space (So that I am synced with 3Do, nDo 2's Previewer) -> Edit this map in nDo2 (adding details not in the high poly) -> convert this nDo2-edited map back with Handplane to an additional WS/OS normals map.
At this point I end up with two maps:
An nDo2-edited Tangent Space Normals map that matches dDo's unity previewer perfectly, ready for texturing.
An nDo2 edited World Space map that can be used in dDo for orientation dependant detailing/filters
And the best part is that this "Final" (nDo 2 edited) World-Space map could once again be converted to match, perfectly, any target engine that handplane supports, and I would have perfect textures from dDo with accurate normals in it's interactive previewer.
And, as you know, unsynced tangent basises can lead to very big, or very minor problems depending on the asset and the way its been set up as well as the target renderer. If we are going through the trouble of staying synced with handplane, why leave one step unsynced? it would sort of ruin the point.
When talking about normal maps yeah, having them synced with your target engine can be quite important. I'm having trouble understanding how the accuracy of the OS nm could be detrimental to the textures computed by dDo though. Maybe when I get my pc back up and running I'll muck around with this stuff to see if I can get a better understanding of what's going on.
Minor inaccuracies with your objectspace normal map in dDo should be little concern, ddo uses OS maps for directional based effects and things like that, which does not need the same level of accuracy as tangent space normal maps.
It would be nice to demonstrate the technique you described at the end of that last video, in another video, showing the specifics and limitation of that method. Specifically, seeing your approach to fixing bad shading on a particular asset with the support loops added post-bake, and then regenerating the Handplane normal map.
Awesome videos, it's always great having tutorials to share where people actually talk about how normal maps work, and tips to fix common issues, such as edges being too sharp.
Alec asked me to take a look at different tangent spaces for Beth games, so here's a test in Fallout: New Vegas. Baked with a single smoothing group. http://youtu.be/JYdGi3UDRBA
Still comparison:
Actual release version with SGs split at UV breaks, baked straight in 3ds max:
thanks for putting that together. I think overall the max output looks better. One nice thing with handplane is that you can bake a big sculpt mesh inside xnormal but still get access to a 3dsmax TB map.
The little lock icon at the top-right of the Inspector is a godsend when you're selecting other stuff, btw. Should save you having to re-select your mesh each time you want to throw a new normal map on it.
The little lock icon at the top-right of the Inspector is a godsend when you're selecting other stuff, btw. Should save you having to re-select your mesh each time you want to throw a new normal map on it.
The third output is handplane's "input tangent and binormal" option. This does something similar to xnormal when you bake with "use exported normals" checked where it uses normals and tangents found in the file to bake the normal map. Both handplane outputs look better than the xnormal UDK workflow.
Just to let the developers know, xrg shared in another thread that Blender now supports exporting sharp edges as smoothing groups to OBJ (and soon to be implemented to FBX). I tested myself, and found that Handplane finally picks up on exported hard edges from Blender, instead of averaging the normals of the low poly mesh. Blender users can now take full advantage of Handplane as an awesome tool that works with meshes with more than one smoothing group!
Tried handplane again today, and sadly I'm still getting the error I mailed you about a while ago.. my resulting normal map looks like a mashup of both OS and TS maps. I bake using sbm (xnormal) and use FBX for handplane's calculations..
What was your email called? Did I respond to the issue when you emailed me last time?
Your problem sounds like the most common support question I get- so far, in almost all cases this is caused by a different set of shells used to bake the object space map as are used for the tangent space calculation. The problem areas, are they mirrored or repeated elements? An easy first debug step for handplane is to apply your object space normals to the object (before sending anything into handplane). More often than not these problems can be seen before handplane is used. You can also double check that your object isn't storing a bunch of transform info by running a reset xform.
Also, for fun you can try loading the broken normal map into engine. It should still look correct, just with inverted or rotated shading on the problem areas.
Hi Alec, thanks for the swift reply! (My mail was titled "Handplane odd output")
The only difference between the models I baked with vs the one I fed to handplane is that I used sbm for baking in xnormal and fbx for handplane. This mesh is light on the mirroring, there's one mirrored area (moved outside 0,1), which correspondingly shows up black in xnormal's 3d viewer straight after baking. The funny thing is, other shells altogether are giving me grief, looking like a wacky OS normal map, while most of the handplane output texture certainly looks like a regular TS map.
I'll throw it into an engine soon, in marmoset it certainly looked off.
Thanks again, and I didn't mean to come over as nagging or anything.
Any new regarding maya 2014 H3D exporter plugins???? cause Im not getting good results when converting object to tangent , Im using obj format for my LR mesh . And , Im not really sure about it , but in your maya / handplane workflow , you dont show ur uv islands ( hard edges should be split??) and I dont know if I should harden /soften edges before bake in Xnormal
I've used Handplane with xnormal before and it worked great! This time I wanted to bake from 3dsmax to get better control over the projection cage but once I pass my object space normal map I end up with a not so tangent looking map.
Here are the steps I took:
1. These are the settings I used to generate the obj space norm.
2. That's what I get (looks good)
3. Before using Handplane, I tested the map in 3dsmax and it looked ok. One thing to note is I have to check "Flip Green (Y)" for it to display properly.
4. These are the settings in Handplane. It renders without any pop-up message.
5. This is the result. As you can see, it looks more like object space rather than tangent.
I reseted Xformed before exporting my low res (although I'm not sure the matrix of an object can be exported). I made sure the normals are in the right way. I set it to "auto detect" but I get the exact same thing.
Hey cptSwing, I took all the elements of my mesh and placed them at 0,0,0 (that's what you mean right?) I Xformed it and tried again but I get the same result.
I had also tried copying the mesh way off to left on X and got all the parts together like they should be (I usually tried with all the elements move apart from each other so there wouldn't be any intersections) and tried with that. Here's the funky artwork I got:
Also, I made sure there wasn't any duplicate polygons.
I tried again with the sphere but I exported with FBX. It now looks like a tangent map but it still have weird streching across the map. It has to be about export settings.
I think I found the solution. I re-exported as OBJ and made sure to uncheck "Flip YZ-axis (Poser-like)". It worked for my sphere test. I'll try with my gun.
Hey Oliver,
Please email me your object space map along with your max scene. Also, it appears that your fbx plugins could use an update (there is a good chance this is the cause of your problems).
Any new regarding maya 2014 H3D exporter plugins???? cause Im not getting good results when converting object to tangent , Im using obj format for my LR mesh . And , Im not really sure about it , but in your maya / handplane workflow , you dont show ur uv islands ( hard edges should be split??) and I dont know if I should harden /soften edges before bake in Xnormal
maya 2014 plugins for 64bit are included in the handpane 1.2 installer.
I am trying to pass a world space normal map baked from a highpoly subtool in ZBrush 4R4 along with the lowpoly mesh (doesn't matter if I take the exported mesh from ZBrush or a completely smoothed one from Maya 2010 and exported as OBJ) into handplane. But I get similar results like olivierth.
Also handplane pops a message at me when I set its "Baked In" setting to ZBrush telling me that it seems like my object space map has its y and z swapped.
Every bake - regardless of setting it to Auto Detect or to ZBrush - results in a tangent map that looks way too colorful in my eyes and doesn't shade correctly in Maya 2010.
It is uncertain to me if ZBrush's non-tangent normal map (which it calls World Space Normal Map) can be called an Object Space Normal Map at the same time because there shouldn't be any transforms on the mesh. It rests in the center of the world, so theoretically WS and OS should match, no?
We have added a checkbox for lowpoly object export to ignore any transforms on the low poly. If the object is baked in world space instead of object space the normal map is effectively double rotating and causing the strange colors. That map output is still a tangent space map, it just has its shading rotated, hence the weird colors.
Also, I would only use "auto detect" for baked in and the pop up about y/z is standard. There isn't a good way to predict the y/z orientation of both the lowpoly and the object space map.
Thanks for the ultra fast reply. I used version 1.2 of handplane. Is that checkbox in there or is there a newer version? I'll have a look when I am back home ... again, thx Alec
Edit: forget what I said in this posting - that blob mesh seems to shade correctly in Maya although the tangent map looks unsually colorful.
But the issue with my other mesh still stands. I'm trying to save the mesh in different rotations / file formats and see whats happening.
Edit: POSSIBLE SOLUTION
For whatever reason - thx Alec for pointing me in that direction - I had to rotate the exported lowpoly obj mesh (that came from ZBrush) in Maya 180 degree about its Y (up-)axis.
I then had to export this mesh to obj again, provide it to handplane and let it do its calculation as usual in combination with the WS normal map from ZBrush.
The resultant tangent space normal looks as expected - no crazy color gradients, almost all nice blueish tones.
Hi Alec, thanks for doing so much support for handplane
I'm testing it for our studio to use right now, and have run into a bug. I'm baking the normals for this character's face in xnormal. The mesh is mirrored and the UVs are stacked, but I've tried this stacked and with the other half offset by 1 and had the same result. The normal appears to bake fine, but the conversion to unreal through handplane is causing a weird artifact around the mouth. There's no special geometry or UV action happening to account for it. When I convert to unity instead of unreal, the problem doesn't occur. I've attached a pic of the error, with a shot including a UV overlay so you can see how the artifact follows a specific group of polies. I'm going to continue testing this today but would love any insight if this is something you've encountered.
Hi Ted,
Thats a new one. What does 3dsmax output look like? Also, what 3d package and file format are you using? I'm looking into this, if you are able, can you send over a lowpoly along with the object space map?
Replies
tangent to object is something we have been discussing for a while and do plan to add.
Hey Alec, Thanks for the quick reply, I am looking forward to it.
The answer to both of your questions would be yes, it can matter a lot.
There are many included filters with dDo that are small scale and orientation dependant that even minor normals errors could throw off. Mud is not the only example, sun bleaching is a nice filter I can think of off the top of my head. There is also lots of custom applications that one could make with their filter creator.
And, as you know, unsynced tangent basises can lead to very big, or very minor problems depending on the asset and the way its been set up as well as the target renderer. If we are going through the trouble of staying synced with handplane, why leave one step unsynced? it would sort of ruin the point.
With this feature, My perfectly synced normals workflow would be as such:
Bake WorldSpace (3ds max) -> Handplane w/ Unity tangent space (So that I am synced with 3Do, nDo 2's Previewer) -> Edit this map in nDo2 (adding details not in the high poly) -> convert this nDo2-edited map back with Handplane to an additional WS/OS normals map.
At this point I end up with two maps:
And the best part is that this "Final" (nDo 2 edited) World-Space map could once again be converted to match, perfectly, any target engine that handplane supports, and I would have perfect textures from dDo with accurate normals in it's interactive previewer.
.
When talking about normal maps yeah, having them synced with your target engine can be quite important. I'm having trouble understanding how the accuracy of the OS nm could be detrimental to the textures computed by dDo though. Maybe when I get my pc back up and running I'll muck around with this stuff to see if I can get a better understanding of what's going on.
[ame="
and the second video is the first in a series comparing different normal map outputs in game engines. This one is for source:
[ame="
Still comparison:
Actual release version with SGs split at UV breaks, baked straight in 3ds max:
Unless Bethesda have changed that to a custom one at some point.
I'm basing this on...
https://support.gamebryo.com/index.php?app=wiki&page=LSmaxMaterials13
Which seems to suggest there's 3 options; Max, ATI or Gamebryo. Although this page suggests that ATI is the default? https://support.gamebryo.com/index.php?app=wiki&page=LSwriteNSFs5
The little lock icon at the top-right of the Inspector is a godsend when you're selecting other stuff, btw. Should save you having to re-select your mesh each time you want to throw a new normal map on it.
Wow, I can't believe I didn't know about that.
The third output is handplane's "input tangent and binormal" option. This does something similar to xnormal when you bake with "use exported normals" checked where it uses normals and tangents found in the file to bake the normal map. Both handplane outputs look better than the xnormal UDK workflow.
[ame="
You can skip to the end to see deferred rendering but it looks perfect.
[ame="
Your problem sounds like the most common support question I get- so far, in almost all cases this is caused by a different set of shells used to bake the object space map as are used for the tangent space calculation. The problem areas, are they mirrored or repeated elements? An easy first debug step for handplane is to apply your object space normals to the object (before sending anything into handplane). More often than not these problems can be seen before handplane is used. You can also double check that your object isn't storing a bunch of transform info by running a reset xform.
Also, for fun you can try loading the broken normal map into engine. It should still look correct, just with inverted or rotated shading on the problem areas.
The only difference between the models I baked with vs the one I fed to handplane is that I used sbm for baking in xnormal and fbx for handplane. This mesh is light on the mirroring, there's one mirrored area (moved outside 0,1), which correspondingly shows up black in xnormal's 3d viewer straight after baking. The funny thing is, other shells altogether are giving me grief, looking like a wacky OS normal map, while most of the handplane output texture certainly looks like a regular TS map.
I'll throw it into an engine soon, in marmoset it certainly looked off.
Thanks again, and I didn't mean to come over as nagging or anything.
I've used Handplane with xnormal before and it worked great! This time I wanted to bake from 3dsmax to get better control over the projection cage but once I pass my object space normal map I end up with a not so tangent looking map.
Here are the steps I took:
1. These are the settings I used to generate the obj space norm.
2. That's what I get (looks good)
3. Before using Handplane, I tested the map in 3dsmax and it looked ok. One thing to note is I have to check "Flip Green (Y)" for it to display properly.
4. These are the settings in Handplane. It renders without any pop-up message.
5. This is the result. As you can see, it looks more like object space rather than tangent.
Did I do something wrong?
Thank you for helping!:\
Help!
Also, what do you need to get a different tangent system working? I am interested in a unique output for our proprietary engine. Thanks!
Then you shouldn't have to tick Flip Green in your material and Handplane might like it better.
I had also tried copying the mesh way off to left on X and got all the parts together like they should be (I usually tried with all the elements move apart from each other so there wouldn't be any intersections) and tried with that. Here's the funky artwork I got:
Also, I made sure there wasn't any duplicate polygons.
Help!
Are there specific export settings I need for my obj?
I think I found the solution. I re-exported as OBJ and made sure to uncheck "Flip YZ-axis (Poser-like)". It worked for my sphere test. I'll try with my gun.
Please email me your object space map along with your max scene. Also, it appears that your fbx plugins could use an update (there is a good chance this is the cause of your problems).
alecmoody@gmail.com
You shouldn't need a common pivot but handplane may get confused by rotational transforms. I think this is something we can fix going forward.
Also, the y/z flip should be handled by auto detect correctly, its strange that it is solving your issue.
maya 2014 plugins for 64bit are included in the handpane 1.2 installer.
I'm using 3dsmax 2012. Could that be the reason the fbx is out of date?
Also handplane pops a message at me when I set its "Baked In" setting to ZBrush telling me that it seems like my object space map has its y and z swapped.
Every bake - regardless of setting it to Auto Detect or to ZBrush - results in a tangent map that looks way too colorful in my eyes and doesn't shade correctly in Maya 2010.
It is uncertain to me if ZBrush's non-tangent normal map (which it calls World Space Normal Map) can be called an Object Space Normal Map at the same time because there shouldn't be any transforms on the mesh. It rests in the center of the world, so theoretically WS and OS should match, no?
Also, I would only use "auto detect" for baked in and the pop up about y/z is standard. There isn't a good way to predict the y/z orientation of both the lowpoly and the object space map.
But the issue with my other mesh still stands. I'm trying to save the mesh in different rotations / file formats and see whats happening.
Edit:
POSSIBLE SOLUTION
For whatever reason - thx Alec for pointing me in that direction - I had to rotate the exported lowpoly obj mesh (that came from ZBrush) in Maya 180 degree about its Y (up-)axis.
I then had to export this mesh to obj again, provide it to handplane and let it do its calculation as usual in combination with the WS normal map from ZBrush.
The resultant tangent space normal looks as expected - no crazy color gradients, almost all nice blueish tones.
Yay, no cage needed.
I'm testing it for our studio to use right now, and have run into a bug. I'm baking the normals for this character's face in xnormal. The mesh is mirrored and the UVs are stacked, but I've tried this stacked and with the other half offset by 1 and had the same result. The normal appears to bake fine, but the conversion to unreal through handplane is causing a weird artifact around the mouth. There's no special geometry or UV action happening to account for it. When I convert to unity instead of unreal, the problem doesn't occur. I've attached a pic of the error, with a shot including a UV overlay so you can see how the artifact follows a specific group of polies. I'm going to continue testing this today but would love any insight if this is something you've encountered.
cheers
Thats a new one. What does 3dsmax output look like? Also, what 3d package and file format are you using? I'm looking into this, if you are able, can you send over a lowpoly along with the object space map?