Xnormal to 3DS max normal map using Handplane.

GIS3000

Hi everyone,

I'm currently testing out Handplane 3D 1.5 as a normal map translator.

My stuff is baked in Xnormal and the normal maps are used in Unity 3D. However, I'd like to be able to see my model with normal map in the 3DS max view port.

Here are my results.

So far, things baking in max look perfect in max. 

As expected, Xnormal's bake is incompatible with 3DS Max's view port as they calculate Tangents differently.

However, Handplane's conversion is not perfect either.

I baked the normal map in Xnormal using 16bit Tif object space normal map and converted it to 3DS Max using Handplane 1.5. 

What could be the issue? Could it be the obj export options? FBX seems to produce the same issues.. I've attached some files here for anyone the take a look.

Regards
GIS3000

GIS3000

Anyone?

thanks

Prot

Hi,

I saw some mistakes in your folder.
For the cube, you have to split all the faces with a little padding between them or you will have error when you will bake.
You have to prepare the low poly with smoothing group too.
These two errors lead to the black gradient you have.

The difference between Unity and 3Ds Max for the normal is only the green channel (you can invert it in photoshop) because of the driver used (openGL and DirectX, same as unity and unreal).
That's why the black gradient is from front to far.

You have really good explanations here : http://wiki.polycount.com/wiki/Texture_Baking

I've attached a file with an example.

Regards,

GIS3000

Hi thanks for the time!

I understand your method. In essence, it breaks up the cube into 6 different hard faces with each face its own UV shell so that they do not effect each other. 
similar to this video where there are instances when smoothing groups must be used to solve smoothing errors and over coming some limitations.
https://www.youtube.com/watch?v=ciXTyOOnBZQ

But what I'm testing right now is normal map tangent space sychronization. I do not think that its the UV layout or the smoothing that's an issue.

For example, the cube you see on the left was baked in 3DS max and renders perfectly. However, you have issues with xnormal and even the handplane translator cannot make it perfect.

As for the difference between Max and Unity normal maps, it is more than just  the green channel. They use different normal map tangent basis calculations.

Max uses its own method of calculating its normal map tangent basis. Xnormal, unity and UE4, blender and Substance all use Mikk Tangent space. That's why a normal map baked in Xnormal, will look perfect in Substance, unity and others.

The cube on the right uses a normal map baked in Xnormal and displays errors in 3DS Max. Please note that the green channel has already been flipped. That same texture renders perfectly in Substance painter and Unity as show here.


Its discussed heavily in many  threads like this one.
http://polycount.com/discussion/174385/synced-tangent-basis-workflow-from-3ds-max-to-unity-5

Now the issue is getting xnormal or handplane normal maps to display perfectly in Max. But yes, xnormal bakes look great in Unity.

I think that your method is more of a work around, which I think would be great in many situations. Thanks!

Once again thanks for your time! I'll be looking into it for the time being.

regards
GIS3000

pior

Considering that displaying the assets in Max is just for extra preview purposes (since your actual, final target is Unity) I personally don't see the point in trying to make the assets display perfectly accurately in the Max viewport.

Of course it would be best to do so ; but if you end up having to Handplane/convert all your texture assets just for the sake of this extra little convenience, I would say that this is probably not worth it.

poopipe

If you set max to use maya tangent space in preferences you'll find mikktspace baked normals display "mostly OK"  if not correctly.  If you're using fudges like split UVs at hard edges it should do a good enough job for previewing. 

It's probably worth bearing in mind that making LODS that share textures will screw any plans you have of working fully synced anyway so I wouldn't get too hung up on it. 

GIS3000

Thanks for all the replies.

I guess you are all right. Is it worth the time and effort? It could just be a limitation.

Besides, many models today are chamfered, which reduces the  need for perfect normal map syncing . Check these out.


The handplane converter DOES help thou. And now with the Handplane baker, I can speed up my zbrush bakes. And the results are excatly the same as baking in Xnormal and converting using Handplane 1.6.

Anyway, thanks for the discussion. Your replies really helped me with my investigations.

Regards
GIS3000