Here's an update on the Xnormal / Synced normals pipeline.
We found 2 steps to better sync normal map rendering:
The first step is a setting in xnormal you can change to make it better synced with our rendering:
Click the plug icon on the bottom left
Click Tangent basis calculators tab
Select Mikk - TSpace plugin
Click Configure button
Check the Compute binormal in pixel shader box.
( I will make sure the docs are updated with this)
The second step was a change to our renderer and will be available in the next release. The good news is you can go ahead and make this xnormal change and when the next version of Unreal Engine is available to you, your art will look better.
I'll test out the new UE4 implementation soon. Can you link me to jordan's post so I can determine when that updated render code is released? If it works well it is definitely something we would want to support.
I'll test out the new UE4 implementation soon. Can you link me to jordan's post so I can determine when that updated render code is released? If it works well it is definitely something we would want to support.
Quoting a post actually includes a link directly to the source.
My object space bake in xnormal is going crazy with the mirrored parts. Also I have offset the mirrored Uvs 1 tile over.
The Mirrored pieces have been symmetry modified to make the other half and welded. I used FBX for the high and the low. For the cage I used averaged normals with ray distance calculator. On the low I exported smoothing groups and tangents. On the low I set my smoothing to match my UV borders.
I went through all the 'hoops' now im still confused as to why my mirrored pieces are baking funky? Triangulation on mirrored pieces seems ok as well a perfect copy.
EDIT: Here is what happens after I run it through handplane with all the settings on AUTO.
Those colors are inverted or rotated shading. The object space source map being fed into handplane is facing a different direction than the lowpoly model it is using to calculate.
What does your object space bake look like on the model? Place colored lights on opposite sides of the model to ensure the object space normals are actually facing the right way.
My guess is that you are accidentally using a different set of shells for your object space bake as you are for the handplane conversion. Re-bake your object space map and use the exact same 3d file for your handplane conversion. You can also send the model over to me and I will nail down the cause: alecmoody@gmail.com
Ok I sent you the files.. Ive always had trouble with mirroring pieces.. with this weird shading issue.. the way id always fix it in the past is to bake different tangent space maps flipping around the channels till each piece looks right and then id compose all them tangent space maps into one final map. Which shouldn't be so difficult.. I should just offset 1UVtile and be done. Not sure what I'm doing wrong.
I made each mirroring section by deleting half of it. UVing it. Detaching it from the mesh after the uvs were done then symmetry it over and weld. Then offset mirrored pieces 1 tile over. and reattaching everything into one mesh.
I checked out your files and you object space normals are rendering backwards in maya. If your object space normals aren't right handplane will produce rotated/flipped shading to match.
To eliminate any possible problems:
Reset transforms on your low poly model
Rebake object space map
Use the same fbx file in handplane so you know that you haven't accidentally swapped teh wrong set of shells back into 0-1 space.
Prob solved! Turns out I was baking with my usual Y- swizzle cord in Xnormal I wasn't aware they all had to be + I usually bake tangent space maps. Thanks
When i use my generated normalmap in UE4 with handplane-UDK3 settings, it's all messed up. Max2013 works much better. Is it my fault? Is Max2013 tangent basis similar to UE4?
I apologize if this has been asked before but I couldn't find an answer. I was wondering if someone knew what's best to do when incorporating Hand Plane into your workflow in regards to how the object space map is baked.
When using Xnormal to bake the map and considering that the target engine doesn't support custom normals, should the low poly file include custom normals or is it best if it's imported into Xnormal without any custom ones? In both cases the output is mostly the same once the map has been ran through Hand Plane but I'm not sure what's best.
Minor update to handplane today. Version 1.4.1 is just an updated handplane xnormal plugin for Xnormal version 3.18.8. We also included the older plugin for people on 3.18.6. Version 3.18.7 got skipped.
Hello, I just tried handplane and I get some weird results when creating a normal map for max.
I downloaded a chainsaw from the dDo tutorial http://youtu.be/hncqbwkGbM4 (there's a link to the files in the video description) and it looks fine when rendered in marmoset (it seems that the author used xNormal to bake everything):
However, when I tried to convert the object space normal map for max, I got this (both viewport and render):
Also looks bad in marmoset with max tangent space enabled:
And it looks bad in UE4 as well.
I set the input to auto-detect or xnormal and output to 3ds max. I also tried changing object space to world space. Did I miss something?
I'm sorry if this is a dumb question, I've never used handplane before.
I'm been at it all day,testing it on a simple cube and I still can not figure out what's going on. I've tried meshes from Maya and Modo same shading artifact when brought to UE4.2.
heey i got some problem with handplane because if i use object space and my low poly model with soften edge it gives me a very very low normal map u need to zoom in before you can see the normal map.
UE4 is something we would like to add but it is going to be a while. Luke and I each have newborns, I have a full time job, and Luke is busy with Banished. Few people used the UE3 output so I have little reason to believe the UE4 output will be more popular.
Son Kim-
I haven't done anything with UE4 bakes but I would look carefully at how data for tangents and normals is getting passed around and used in different software. When you rely on imported normals and tangents between multiple pieces of software it is very easy for something to go wrong without an obvious cause. For example, Xnormal skips using the T-Mikk space calculation (or any tangent space calculation) when it finds packaged tangents in the lowpoly model file. That is not intuitive and most artists wouldn't think they will get two totally different normal maps depending what FBX options they check at export.
No- Whenever possible we calculate the all the data to match the target engine. This ensures that a model from 3dsmax, maya, or any other software will create the exact same tangent space result. Some game engines (like unity or source) expect to load mesh normals from the file so in those cases we don't calculate the lowpoly normals (but we do calc the tangents). This is very different than using a workflow that relies on passing tangents through the 3d file into the game engine.
There are a lot of issues that can spring up when using a workflow that relies on importing tangents- One example:
Imagine you are developing a large game with an in house team running Maya and you have an external contractor who works in 3dsmax. The FBX file the outsource artist is using when they bake and test their normals will have 3dsmax tangents packaged into it. Baking those tangents ties that model file to the source 3d package. In this case the artist could create a bake that looks good in engine, submit the file, and everyone is happy. Two months later an in house artist loads their fbx file in maya and does something trivial like change the pivot or keyframe an animation. After they are done they re-export the model and suddenly the model is shading wrong in the game. The tangent space map was baked correctly for the previous model, but because that normal map was tied to the source files tangents the new file is no longer a correct match.
This gets even messier when you consider that different version of 3dsmax use a different method to calculate tangents, and that different versions of maya use a different method to calculate normals.
The clean and simple way to build a normal mapping workflow is for the engine to calculate tangents (and not import) and for your art team to use baking software that matches the engine.
No- Whenever possible we calculate the all the data to match the target engine. This ensures that a model from 3dsmax, maya, or any other software will create the exact same tangent space result. Some game engines (like unity or source) expect to load mesh normals from the file so in those cases we don't calculate the lowpoly normals (but we do calc the tangents). This is very different than using a workflow that relies on passing tangents through the 3d file into the game engine.
There are a lot of issues that can spring up when using a workflow that relies on importing tangents- One example:
Imagine you are developing a large game with an in house team running Maya and you have an external contractor who works in 3dsmax. The FBX file the outsource artist is using when they bake and test their normals will have 3dsmax tangents packaged into it. Baking those tangents ties that model file to the source 3d package. In this case the artist could create a bake that looks good in engine, submit the file, and everyone is happy. Two months later an in house artist loads their fbx file in maya and does something trivial like change the pivot or keyframe an animation. After they are done they re-export the model and suddenly the model is shading wrong in the game. The tangent space map was baked correctly for the previous model, but because that normal map was tied to the source files tangents the new file is no longer a correct match.
This gets even messier when you consider that different version of 3dsmax use a different method to calculate tangents, and that different versions of maya use a different method to calculate normals.
The clean and simple way to build a normal mapping workflow is for the engine to calculate tangents (and not import) and for your art team to use baking software that matches the engine.
Hey Alec,
Recently trying to adopt handplane into my pipeline, then can't help but notice handplane doesn't support edit normal in 3ds max. I explicit tweak the normals of the vertex but however I tried generate from handplane using fbx or obj both give me correct result if I reset the normals. Care to share ideas for this issue?
Hi Alec,
I tried with FBX, Obj, and even export from 3ds Max to Maya for the plugin (handplane 3D exporter) but whenever handplane convert object space to tangent space it choose to ignore the custom vertex normals of the model. The output tangent space normal from handplane will only look correct if I reset the vertex normals to it's default.
I still can't tell what tangent space you are trying to output. If it is either 3dsmax, maya, or unreal you won't be able to use the edit normals modifier because we recalculate the normals to match the target engine. The advantage to this is that an artist working in maya who wants to make a 3dsmax tangent space map will get the exact same result as an artist who is baking their maps inside 3dsmax.
The source engine and unity both default to importing normals from the mesh, for those outputs we read normals out of the file instead of calculating them.
Sorry for missing the question before, the engine I trying to output will be CryEngine, but I know CryEngine support wasn't available, so 3ds Max is the nearest to what I wanted to have.
The reason why I was using Edit Normal was because it will try to average a selection of normals as much as possible, therefore reducing the need to counter the smoothing group from the normal map itself.
When I am using handplane with no custom normals, my LODs suffer normal smoothing error from when the original normal map trying the counter the mesh smoothing.
But now that you explain very clearly behind the scenes. I might tweak my workflow a little bit. Thanks for the support.
Alex I'm surprised to hear you say Handplane doesn't take Edit Normals into account when doing the output to Unreal.
Epic specifically added support for it to allow better foliage rendering.
Normal map accuracy is usually not an issue with foliage since you avoid UV seams in the middle of foliage meshes, and you're not baking to the specific mesh anyhow.
But I would imagine it matters with other meshes, especially modular ones?
Just wanted to chime in and mention that having Unreal Engine 3 support was very useful for the recent Chivalry contest - as far as I am concerned it worked perfectly well.
Sorry if that was unclear. UE4 is included in "adding some new engines." It is just lower down the list. When we were first specing out handplane unreal support was the highest priority and the most time got sunk into figuring it out. Once we started selling handplane it was clearly the least popular output (at least for commercial users).
Sorry if that was unclear. UE4 is included in "adding some new engines." It is just lower down the list. When we were first specing out handplane unreal support was the highest priority and the most time got sunk into figuring it out. Once we started selling handplane it was clearly the least popular output (at least for commercial users).
Quick question, I'm using Max to bake my object space normal map with the default -Y, then into Handplane with everything set to Auto Detect / Output for unity before using dDo to finish. Is handplane auto flipping my green for me, or should I still be ticking the box in dDo importer? Struggle to see the difference sometimes!
I have tested Handplane pretty extensively today to get my bake into Chivalry and so far it works well but if I use it I may run down into some problems down the line if I understand how the thing works. So If I bake my base mesh normals in Xnormal and then import it into Quixel suite/Substance Designer/Knald to add some additional noise/textures/material definition will they break the tangent space? Or they will operate in tangent space set by Handplane?
Like Pior, I want to pass on some gratitude for the UE3 basis support in Handplane. I frequently used the UE3 output for my last game, and fwiw I had purchased the commercial license back in the day
I have tested Handplane pretty extensively today to get my bake into Chivalry and so far it works well but if I use it I may run down into some problems down the line if I understand how the thing works. So If I bake my base mesh normals in Xnormal and then import it into Quixel suite/Substance Designer/Knald to add some additional noise/textures/material definition will they break the tangent space? Or they will operate in tangent space set by Handplane?
I am not that familiar with either of those tools. It is going to depend on how they work and what process they use to blend micro texture into the normal map. I would just test it out early in your process so you can see if it is causing issues before you spend a ton of time on it.
Thank you very much for the tool, Alec. It is pretty incredible.
I have a couple of questions. I am doing some submissions for the DOTA workshop and I am a bit concerned about LOD1. Which would be the best practices to avoid errors when optimizing for LOD1?
From what I've read some good practices to avoid shading errors are:
-Hardened edges (splits?) on all UV shell edge seams. This is due to the total vertex count being unaffected, if I understand correctly.
-Plan in advance areas that will be optimized so that you have support edges or hardened edges (I'm a Maya user ) in place to soften such errors.
If there are more, please do let me know. I come from a film/commercials background and normal maps for low resolution meshes make my head spin.
Thanks again for the great tool, it is awesome. :thumbup:
-Hardened edges (splits?) on all UV shell edge seams. This is due to the total vertex count being unaffected, if I understand correctly. This will help. Generally, if you have an area that you are worried about looking wrong with lod1 you should harden the edges that match up with UV borders nearby. Hardening edges DOES increase the vertex count but Valve only measures triangle count so it is won't affect your ability to submit the file.
-Plan in advance areas that will be optimized so that you have support edges or hardened edges (I'm a Maya user ) in place to soften such errors.
That migth be neccesary in extreme cases. Make sure you are evaluating your normals at an actual game resolution and perspective.
That is mostly right but I will respond point by point:
Thank you so much for your response. That's interesting, so hardening UV island edges increases the vertex count further?
I am going by this walkthrough:
Vertex use
When considering the use of hard edges, you need to consider the implications of such. Whenever you have a hard edge, or a uv seam, you in-game vertexs are doubled in those areas. More than your triangle count or your vertex count, the in-game vertex count is what really effects performance in most game engines.
Some general rules with that in mind:
To avoid artifacts, you must split your uvs where you use hard edges.
You do not however, NEED to use hard edges wherever you split your uvs(as some may suggest) With an Averaged projection mesh you can use hard edges along uv borders with no negative side effects. Because the verts are already doubled at your uv seams, you get it for free. Your verts do not triple or quadruple if you have both a uv seam and a hard edge in the same place.
Replies
Quoting a post actually includes a link directly to the source.
The Mirrored pieces have been symmetry modified to make the other half and welded. I used FBX for the high and the low. For the cage I used averaged normals with ray distance calculator. On the low I exported smoothing groups and tangents. On the low I set my smoothing to match my UV borders.
I went through all the 'hoops' now im still confused as to why my mirrored pieces are baking funky? Triangulation on mirrored pieces seems ok as well a perfect copy.
EDIT: Here is what happens after I run it through handplane with all the settings on AUTO.
What does your object space bake look like on the model? Place colored lights on opposite sides of the model to ensure the object space normals are actually facing the right way.
My guess is that you are accidentally using a different set of shells for your object space bake as you are for the handplane conversion. Re-bake your object space map and use the exact same 3d file for your handplane conversion. You can also send the model over to me and I will nail down the cause: alecmoody@gmail.com
I made each mirroring section by deleting half of it. UVing it. Detaching it from the mesh after the uvs were done then symmetry it over and weld. Then offset mirrored pieces 1 tile over. and reattaching everything into one mesh.
To eliminate any possible problems:
Reset transforms on your low poly model
Rebake object space map
Use the same fbx file in handplane so you know that you haven't accidentally swapped teh wrong set of shells back into 0-1 space.
Which output tangent space matches Xnormals viewer? Guessing its either Input Tangent and Computed Binormal or Input Tangent and Binormal.
When using Xnormal to bake the map and considering that the target engine doesn't support custom normals, should the low poly file include custom normals or is it best if it's imported into Xnormal without any custom ones? In both cases the output is mostly the same once the map has been ran through Hand Plane but I'm not sure what's best.
Direct link:
http://www.handplane3d.com/handplane_1_4_1.rar
I downloaded a chainsaw from the dDo tutorial http://youtu.be/hncqbwkGbM4 (there's a link to the files in the video description) and it looks fine when rendered in marmoset (it seems that the author used xNormal to bake everything):
However, when I tried to convert the object space normal map for max, I got this (both viewport and render):
Also looks bad in marmoset with max tangent space enabled:
And it looks bad in UE4 as well.
I set the input to auto-detect or xnormal and output to 3ds max. I also tried changing object space to world space. Did I miss something?
I'm sorry if this is a dumb question, I've never used handplane before.
What problems do you have with your normalmaps straight out of Xnormal in UE4.2?
Same problem as Quack(still happens in 4.2 for me): https://answers.unrealengine.com/questions/14375/normal-map-workflow-with-xnormal-is-not-working.html
I'm been at it all day,testing it on a simple cube and I still can not figure out what's going on. I've tried meshes from Maya and Modo same shading artifact when brought to UE4.2.
Son Kim-
I haven't done anything with UE4 bakes but I would look carefully at how data for tangents and normals is getting passed around and used in different software. When you rely on imported normals and tangents between multiple pieces of software it is very easy for something to go wrong without an obvious cause. For example, Xnormal skips using the T-Mikk space calculation (or any tangent space calculation) when it finds packaged tangents in the lowpoly model file. That is not intuitive and most artists wouldn't think they will get two totally different normal maps depending what FBX options they check at export.
I thought that was the purpose of handplane, to sync normals to a specified output without errors ?
There are a lot of issues that can spring up when using a workflow that relies on importing tangents- One example:
Imagine you are developing a large game with an in house team running Maya and you have an external contractor who works in 3dsmax. The FBX file the outsource artist is using when they bake and test their normals will have 3dsmax tangents packaged into it. Baking those tangents ties that model file to the source 3d package. In this case the artist could create a bake that looks good in engine, submit the file, and everyone is happy. Two months later an in house artist loads their fbx file in maya and does something trivial like change the pivot or keyframe an animation. After they are done they re-export the model and suddenly the model is shading wrong in the game. The tangent space map was baked correctly for the previous model, but because that normal map was tied to the source files tangents the new file is no longer a correct match.
This gets even messier when you consider that different version of 3dsmax use a different method to calculate tangents, and that different versions of maya use a different method to calculate normals.
The clean and simple way to build a normal mapping workflow is for the engine to calculate tangents (and not import) and for your art team to use baking software that matches the engine.
Cheers
Recently trying to adopt handplane into my pipeline, then can't help but notice handplane doesn't support edit normal in 3ds max. I explicit tweak the normals of the vertex but however I tried generate from handplane using fbx or obj both give me correct result if I reset the normals. Care to share ideas for this issue?
I tried with FBX, Obj, and even export from 3ds Max to Maya for the plugin (handplane 3D exporter) but whenever handplane convert object space to tangent space it choose to ignore the custom vertex normals of the model. The output tangent space normal from handplane will only look correct if I reset the vertex normals to it's default.
Edit:
Here is some test bake
Edited Vertex Normal
Object Space Normal
handplane Generated Tangent
After Reset the Custom Vertex Normal
The source engine and unity both default to importing normals from the mesh, for those outputs we read normals out of the file instead of calculating them.
The reason why I was using Edit Normal was because it will try to average a selection of normals as much as possible, therefore reducing the need to counter the smoothing group from the normal map itself.
When I am using handplane with no custom normals, my LODs suffer normal smoothing error from when the original normal map trying the counter the mesh smoothing.
But now that you explain very clearly behind the scenes. I might tweak my workflow a little bit. Thanks for the support.
Epic specifically added support for it to allow better foliage rendering.
Normal map accuracy is usually not an issue with foliage since you avoid UV seams in the middle of foliage meshes, and you're not baking to the specific mesh anyhow.
But I would imagine it matters with other meshes, especially modular ones?
We are in the process of adding some new engines. Unreal4 is on the list but there were very few users for the UE3 support so it is lower priority.
I don't get it "adding some new engines" and UE4 is an old engine? Probably the most popular modern engine to date.
At the end of the day Alec it's up to you guys but rest assured you will have people all over MikkTspace support :poly121:
Cheers
pete
Thanks!
I am not that familiar with either of those tools. It is going to depend on how they work and what process they use to blend micro texture into the normal map. I would just test it out early in your process so you can see if it is causing issues before you spend a ton of time on it.
I have a couple of questions. I am doing some submissions for the DOTA workshop and I am a bit concerned about LOD1. Which would be the best practices to avoid errors when optimizing for LOD1?
From what I've read some good practices to avoid shading errors are:
-Hardened edges (splits?) on all UV shell edge seams. This is due to the total vertex count being unaffected, if I understand correctly.
-Plan in advance areas that will be optimized so that you have support edges or hardened edges (I'm a Maya user
If there are more, please do let me know. I come from a film/commercials background and normal maps for low resolution meshes make my head spin.
Thanks again for the great tool, it is awesome. :thumbup:
Thank you so much for your response. That's interesting, so hardening UV island edges increases the vertex count further?
I am going by this walkthrough:
http://www.polycount.com/forum/showthread.php?t=107196
Awesome, that's some great news! This gives me far more flexibility than I thought I had. Thanks so much for your help.