I don't really follow what you are saying in the last post but- Just because a normal map is multicolored does not make it a world or object space map. If you rotate the shading on a tangent space map 90 degrees you will get a non blue normal map. In your case it sounds like you just need to set handplanes input maps to "auto detect". If you are getting odd colors in your tangent space map on particular shells you should try resetting transforms, and then carefully looking at how the light reacts to your model when using your world space map. If you world space map has rotated or flipped shading, the tangent space map made from handplane will also have rotated shading. Often these issues come about from messy workflows when working with mirrored or repeated geometry.
Also, what kind of seams are you getting in unity? Unity in forward mode will always show some light shading seams. You can test this in unity by loading a blank normal map (solid 128,128, 255). Deferred lighting + handplane will give you zero shading errors and essentially no seams (very very light, this is just a reality of using normal maps).
Edit:
What object format are you using? I think I understand your issue now. You are sending an OBJ out of max but when you baked to object space you got rotated shading. This is because obj wont pass object transforms. Generally you want to use fbx files with object space maps. If you are using obj files world space will produce the correct result since world space ignores transforms entirely.
Contestants:
- 3dsMax tangent space Green Up (green channel flipped)
- Handplane: fed with 3dsmax worldspace normal map
- Farfarers TUnitySpace
This is the unwrap, single island, done in Max with really minimal distortion, one face has some slightly visible stretching when viewed with a checker. Deliberately cut more seams.
Here are the results:
Handplane:
Farfarers UnityTSpace:
3dsMax:
All these are small seams, I think, and they are only visible when zoomed in:
When the objects are viewed in a game scene with a bird-eye camera or isometric view, the seams aren't visible. Also the color contrast is even here, possibly more color detail will lead the viewers eye away from seams:
Zoomed out:
In an FPS game the programmers can create proper shaders to make these seams go away, if they do, these seams aren't such a problem anymore. I think these seams are bearable. Will try a normal map generated from an FBX and post results if they are better.
Tried feeding a triangulated FBX to Handplane with Tangents and Binormals, smoothing groups and an object space normal map. No change in forward rendering, minimal seams are still there. Deferred possibly makes these seams go away and a specific shader geared towards this process, but I don't know how to do in the shader what Farfarer suggested. Anyway, these are good enough results for me.
If you're using that in Unity - have you fixed the smoothing angle?
Set Tangents and Normals to "Calculate", set Smoothing Angle to 180, set Normals to "Import" and then Tangents to "Calculate".
There's a bug in Unity where it'll split the tangents based on the normal's Smoothing Angle value even if the mesh uses imported normals. These instructions will fix that.
It's worth noting that the results will only be "perfect" in deferred rendering. In forward there's still some visual oddities... I've not found a good way to fix those other than converting the TS map to OS in the fragment shader and doing the lighting in object space - unfortunately that's a real pain to do efficiently or eloquently inside of surface shaders ('cause they put everything in tangent space if you use a normal map and you can't tell it not to).
Also, my xNormal plugin and Handplane should give identical results. You can check in Photoshop if you put them on top of each other and set the blending mode of the top one to difference - the texture should end up being black (except for the padding which might be extended from the UV islands differently).
Sogun,
Just to illustrate forward rendering seams in unity. Try taking a screenshot of a fourth version where the normal map is a solid 128,128,255 file. Also, when you are evaluating the quality of normal maps it is better to give it something where the normal map has to do more work. example: [ame="http://www.youtube.com/watch?v=UWToeCw1B24"]handplane unity comparison - YouTube[/ame]
By the way, if you're using Handplane and Unity (or my xNormal plugin) you can try this out, it'll fix up the import settings for normals and tangents on any model that Unity imports into your project.
It beats having to set the options each time, at least...
Note: It will do this for ALL models imported into your project. For any models already imported, right click on the asset in the Project pane and select Reimport from the menu.
I've got a line in my tangent normal map, and I've tried to get rid of it, but I haven't got a clue what the problem is. It's baked in 3DS Max. I tried to reset the xform, triangulated before bake and export and as you can see the local/object normal map hasn't got the lines, so it seems like there's something happening when using Handplane. What do you guys think?
I've already checked that and there were no duplicated verts. I used the same mesh for baking and Handplane. Since the line is not in the object/local normal map it seems like its something that happens when using Handplane. I tried to use an OBJ for Handplane and it removed the lines showed above, but introduced another error/artifact.
When baking world space normal maps, (in this case 3DSmax, but it's the case with Maya too), I had to bake at 16 bit in order to avoid the problem seen in the image below. Further, when using Hand Plane to convert the world normal to a tangent normal, I had to keep it at 16. If I let Hand Plane convert to 8 bit for me I would get the same bad result. After generating my 16 bit tangent space normal map through Hand Plane, I then used photoshop to convert to 8 bit. PS has much better supersampling as you can see. They may already be working on this, but this is one area Hand Plane can improve so others don't run into the same issue I did.
Are you sure you're just not seeing compression artifacts in the form of banding? Often a VERY light noise layer over top of the normal map will remove that...
The normal texture is not compressed in the image. The pattern is in the actual texture. I tried what you suggested on the hand plane compressed version of the normal map by adding a light noise layer and it did obscure it a little, but it's still there. I think 99% of the time this would work for most objects (like characters and such) but on smooth, shiny surfaces like a car it's very unforgiving. Photoshop does add a nice even slight noise when converting from 16 to 8 without any of the broken compression artifacts.
I think photoshop adds a slight noise when converting 16 to 8 bits.
Actually I just discovered this. IF you drag a 16bit image into an 8bit, it adds that noise. If you convert the original 16bit image into 8bit and then drag into another 8bit, you do not get that noise.
Messed up, I know. Took me weeks of going WTF till I finally figured it out.
Its not noise so much as it is dithering. Theres basically two ways you can convert an image to a lower bit depth, one by simply replacing the colors with the closest value in the low bit depth, which generally results in stair stepping, and two, dithering.
When it comes to baking 8bpc images, Max dithers and Maya doesn't, so you'll see similar differences there as well.
Its not noise so much as it is dithering. Theres basically two ways you can convert an image to a lower bit depth, one by simply replacing the colors with the closest value in the low bit depth, which generally results in stair stepping, and two, dithering.
When it comes to baking 8bpc images, Max dithers and Maya doesn't, so you'll see similar differences there as well.
3dsMax renders images fine, it only adds dithering when saving. It's turned on by default.
To turn the dithering off in 3dsmax go to Customize/Preferences/Rendering and uncheck the "True Color" checkbox.
I'm having this error while trying to Bake the Normal Map from HP.
"The Object space map appears to have normals that don't match the yz flip and xy directions of the input mesh. Would you like to apply the detected settings instead?"
And when I Click 'Yes', the given map has no information written on it at all. All channels are empty.
Anyone know why this is happening?
I use 3dsMax and xNormal
Thanks!
Same issue using maya
Do you want to see the file ?
thanks
I have a problem that occurs when using handplane, I made normalmaps in 3DSMAX 2014 and put them together in photoshop(left image).
But when I render out the handplane normalmap I get this (right image), what could be causing this problem?
Obi-bram, you have some overlapping UVs. It looks like there is a cylinder unrwap ontop of your UV sheet. Also, set handplane to auto-detect for your input settings.
Shoganato:
Please email me your fbx file along with your object space normals: alecmoody@gmail.com
I'm getting some issues generating normals for a simple mesh, the object space normal map looks good on the model, the tangents are being imported into UDK fine, but I'm getting some heavy gradients on the normal map, even on flat areas of the model that shouldn't have any issues.
I figured out it was an issue with the output settings, is anyone else having issues getting the website to load? I wanted to update to the latest release.
What 3d software are you using? The release online has issues for maya people. We are about to release 1.4 which should fix all of the bugs related to unreal output.
Not sure what is going on with the website- loads here fine with a hard refresh. If anyone else is having issues please let me know.
Has anyone ever gotten an error that makes the normal a plain gray surface? I got that a couple times and I don't know how to fix it. I got it before but it seemed to fix itself.
Has anyone ever gotten an error that makes the normal a plain gray surface? I got that a couple times and I don't know how to fix it. I got it before but it seemed to fix itself.
Has anyone ever gotten an error that makes the normal a plain gray surface? I got that a couple times and I don't know how to fix it. I got it before but it seemed to fix itself.
Hi GhostDetector, I took a close look at your model and there were a number issues. I have had a few other workshop people send me models with the same mirroring issue so I thought I would post what I found here for others to see.
First, that obj file doesn't appear to contain smoothing information. What 3d software are you using? Use FBX if possible. If handplane isnt getting the smoothing info it can't do it's job (probably the cause of the grey map output).
The bigger issue here is how your UVs are put together. Here is an image of where your UVs overlap:
Overlapping is fine but you need to offset one copy into the next UV square like this:
Also, the way you have set up this mirroring doesn't create symmetrical normals and you will never have a correct bake as a result. Overlapping UVs requires having the exact same normals on each copy. The triangulation direction of a quad matters so the normals at on each of these copies are not the same.
Example quads- notice that the red triangulation on the flat area of the axe and the edge strip meet up:
However, if you rotate to the other side of the model you can see that they triangles do not meet:
The easy solution here is to not stitch your edge polygons to the flat faces of the axe.
Lastly here are some other issues with the model that will cause you to have problems:
Sorry, Not until crytek is willing to share information with us. We tried implementing their TB based on old documentation and it did not look good. One of their licensees also tried to get them to share info with us and it never went anywhere. The last attempt we made was a build that loaded their model files and attempted to create tangent space maps from the packaged tangent/normals- it looked really bad.
Edit:
It is possible that we were correctly creating their tangent space but they are doing something abnormal elsewhere in the code that makes a big impact on the result.
Hi Everyone,
We made handplane a freeware tool today. When handplane 1.4 releases we will not be using the existing licensing system. For current builds I have uploaded a license file to the handplane website.
There is still more to do with handplane and Luke and I would like to develop a baking tool. I have a giant wishlist of features for a baking tool and I think that would be something others would benefit from as well.
Ultimately we would like to implement anything we can get solid documentation and support for. Very few of the engines we have added were easy to get working, even if we had good information.
Awesome news Alec! Glad to hear this worked out so well. What's next for you?!
AlecMoody There is still more to do with handplane and Luke and I would like to develop a baking tool. I have a giant wishlist of features for a baking tool and I think that would be something others would benefit from as well.
A baking tool that uses material id's without having to explode meshes would be most welcome.
however, i seem to have a problem downloading the latest version. the link from the homepage comes back with a 404. something you are already aware of?
thanks for the heads-up. i found out that my ad- and javascript blockers caused the issue. the link was clickable but everything afterwards turned fuzzy. normally it's pretty easy to spot the cause of website functionality failing, in this case however the 404 error threw me off.
I'm trying to get a UDK map, but for some reason I keep getting artifacts like this one:
I'm using max 2012 to bake the OBJSPC and an FBX file.
The strange thing is that other target engines (like Max, Source etc...) work fine. Can anyone help?
What do your smoothing groups look like and what FBX settings are you using? Feel free to send me the object space and FBX file to test on. alecmoody@gmail.com
Replies
Also, what kind of seams are you getting in unity? Unity in forward mode will always show some light shading seams. You can test this in unity by loading a blank normal map (solid 128,128, 255). Deferred lighting + handplane will give you zero shading errors and essentially no seams (very very light, this is just a reality of using normal maps).
Edit:
What object format are you using? I think I understand your issue now. You are sending an OBJ out of max but when you baked to object space you got rotated shading. This is because obj wont pass object transforms. Generally you want to use fbx files with object space maps. If you are using obj files world space will produce the correct result since world space ignores transforms entirely.
Contestants:
- 3dsMax tangent space Green Up (green channel flipped)
- Handplane: fed with 3dsmax worldspace normal map
- Farfarers TUnitySpace
This is the unwrap, single island, done in Max with really minimal distortion, one face has some slightly visible stretching when viewed with a checker. Deliberately cut more seams.
Here are the results:
Handplane:
Farfarers UnityTSpace:
3dsMax:
All these are small seams, I think, and they are only visible when zoomed in:
When the objects are viewed in a game scene with a bird-eye camera or isometric view, the seams aren't visible. Also the color contrast is even here, possibly more color detail will lead the viewers eye away from seams:
Zoomed out:
In an FPS game the programmers can create proper shaders to make these seams go away, if they do, these seams aren't such a problem anymore. I think these seams are bearable. Will try a normal map generated from an FBX and post results if they are better.
Set Tangents and Normals to "Calculate", set Smoothing Angle to 180, set Normals to "Import" and then Tangents to "Calculate".
There's a bug in Unity where it'll split the tangents based on the normal's Smoothing Angle value even if the mesh uses imported normals. These instructions will fix that.
It's worth noting that the results will only be "perfect" in deferred rendering. In forward there's still some visual oddities... I've not found a good way to fix those other than converting the TS map to OS in the fragment shader and doing the lighting in object space - unfortunately that's a real pain to do efficiently or eloquently inside of surface shaders ('cause they put everything in tangent space if you use a normal map and you can't tell it not to).
Also, my xNormal plugin and Handplane should give identical results. You can check in Photoshop if you put them on top of each other and set the blending mode of the top one to difference - the texture should end up being black (except for the padding which might be extended from the UV islands differently).
Just to illustrate forward rendering seams in unity. Try taking a screenshot of a fourth version where the normal map is a solid 128,128,255 file. Also, when you are evaluating the quality of normal maps it is better to give it something where the normal map has to do more work. example: [ame="
It beats having to set the options each time, at least...
https://gist.github.com/Farfarer/6903839
Note: It will do this for ALL models imported into your project. For any models already imported, right click on the asset in the Project pane and select Reimport from the menu.
I've got a line in my tangent normal map, and I've tried to get rid of it, but I haven't got a clue what the problem is. It's baked in 3DS Max. I tried to reset the xform, triangulated before bake and export and as you can see the local/object normal map hasn't got the lines, so it seems like there's something happening when using Handplane. What do you guys think?
Actually I just discovered this. IF you drag a 16bit image into an 8bit, it adds that noise. If you convert the original 16bit image into 8bit and then drag into another 8bit, you do not get that noise.
Messed up, I know. Took me weeks of going WTF till I finally figured it out.
When it comes to baking 8bpc images, Max dithers and Maya doesn't, so you'll see similar differences there as well.
3dsMax renders images fine, it only adds dithering when saving. It's turned on by default.
To turn the dithering off in 3dsmax go to Customize/Preferences/Rendering and uncheck the "True Color" checkbox.
Same issue using maya
Do you want to see the file ?
thanks
It was exported from maya 2011
But when I render out the handplane normalmap I get this (right image), what could be causing this problem?
Shoganato:
Please email me your fbx file along with your object space normals: alecmoody@gmail.com
Thanks anyway.
Not sure what is going on with the website- loads here fine with a hard refresh. If anyone else is having issues please let me know.
Overlapping UVs?
Hi GhostDetector, I took a close look at your model and there were a number issues. I have had a few other workshop people send me models with the same mirroring issue so I thought I would post what I found here for others to see.
First, that obj file doesn't appear to contain smoothing information. What 3d software are you using? Use FBX if possible. If handplane isnt getting the smoothing info it can't do it's job (probably the cause of the grey map output).
The bigger issue here is how your UVs are put together. Here is an image of where your UVs overlap:
Overlapping is fine but you need to offset one copy into the next UV square like this:
Also, the way you have set up this mirroring doesn't create symmetrical normals and you will never have a correct bake as a result. Overlapping UVs requires having the exact same normals on each copy. The triangulation direction of a quad matters so the normals at on each of these copies are not the same.
Example quads- notice that the red triangulation on the flat area of the axe and the edge strip meet up:
However, if you rotate to the other side of the model you can see that they triangles do not meet:
The easy solution here is to not stitch your edge polygons to the flat faces of the axe.
Lastly here are some other issues with the model that will cause you to have problems:
Polygons missing form handle:
http://gyazo.com/692f02a6fe654159507de09b822de74e.png
inverted normals on back side of axe:
http://gyazo.com/381a227f839faf75811cae0eb39d944b.png
Border edges/non welded areas:
http://gyazo.com/ecdedefbcf54e60021cd35f9a1502097.png
Edit:
It is possible that we were correctly creating their tangent space but they are doing something abnormal elsewhere in the code that makes a big impact on the result.
We made handplane a freeware tool today. When handplane 1.4 releases we will not be using the existing licensing system. For current builds I have uploaded a license file to the handplane website.
Is there any other tangent basis(es?) you would like to implement, like id tech for example
A baking tool that uses material id's without having to explode meshes would be most welcome.
however, i seem to have a problem downloading the latest version. the link from the homepage comes back with a 404. something you are already aware of?
The link is working for me. You are clicking the blue button to download?
thanks for the heads-up. i found out that my ad- and javascript blockers caused the issue. the link was clickable but everything afterwards turned fuzzy. normally it's pretty easy to spot the cause of website functionality failing, in this case however the 404 error threw me off.
I'm using max 2012 to bake the OBJSPC and an FBX file.
The strange thing is that other target engines (like Max, Source etc...) work fine. Can anyone help?
http://handplane3d.com/handplane_1_4.rar
Change log:
Removed licensing system for transition to freeware
Improved handling of smoothing groups related to Unreal Output
Created an Xnormal plugin to bake directly into Source engine tangent space
Created SMD importer for Xnormal
UI Tweaks
Video overview:
https://www.youtube.com/watch?v=VHsN2Wg-X5Y