handplane - new tangent space tool in public beta
ngon master
handplane has been released and support has been moved to this thread:
http://www.polycount.com/forum/showthread.php?t=116899
Hi Polycounters,
handplane is a new tool being developed by Luke Hodorwicz and myself with the goal of solving tangent basis mismatch issues across multiple game engines. We are currently at an early beta status and wanted to open the tool up to more people for feedback. handplane is not a baking tool but instead acts as a tangent space calculator. The basic workflow is object space normals + lowpoly model = engine specific tangent space normals:
There are several key advantages to this workflow:
1)
You can keep baking in the software you already use. This also means that the tangent space result becomes package agnostic. For example, you can make a maya tangent space normal map as a 3dsmax user who bakes in xnormal.
2)
Because baking and tangent space generation are separated into different processes the bake itself doesnt care what your normals look like. Baking becomes just a system of creating projections. As long as you arent breaking your UVs, you can make changes to smoothing and topology on your lowpoly model without having to actually rebake everything. In this case you would just run the new lowpoly model + original object space normals back through handplane for a tangent space map that reflects the changes made to the model.
3)
Taking that idea further, you can bake with higher tessellation proxy geometry in order to solve projection issues like cylinder cap waviness and detail skewing. There is also the potential for generating normal maps for lod stages that dont create smoothing errors with the lower detail models.
We are looking for as much feedback as we can get from polycount members. This includes interface issues, bugs, workflow confusion, and small details of usability. Please post here, PM me, or email alecmoody@gmail.com In all cases please include your name, and information about what kind of work you do (where you work, what engines you are using, what kinds of assets...)
[size=+2]handplane has been released
http://www.handplane3d.com[/size]
changes detailed here:
http://www.polycount.com/forum/showpost.php?p=1710509&postcount=117
This discussion has been closed.
Replies
If you find that your tangent space maps are coming out odd colors this is most likely a Y/Z up issue. A common case for this is if you export a low from 3dsmax (z up) but are using an object space bake from Xnormal (Y up). To fix this go to more options and then hit the y/z toggle option in the input section. This cant be solved by channel flipping since a y/z up issue is a 90 degree rotation and not an axis inversion.
Maya Users:
There are a set of plugins for maya 2013 for a custom model format for your lowpoly meshes. This is necessary if you dont want to fully triangulate your models. Maya generates different normals for un-triangulated quads but the tangent basis still needs to know the internal triangle direction. This plugin passes the triangle direction for each quad while keeping the correct normals.
Tangent basis outputs:
Both 3dsmax and Maya tangent basis outputs are close to perfect. Both output options should be able to handle arbitrary topology and badly put together assets.
For the three game engines the output is better than any conventional pipeline but not perfect. More specific information about those engines below:
Source:
A much closer match than 3dsmax tangent basis (and far better than using Maya). We have good documentation on this and are still working on figuring out where remaining errors come from. In practice this is a huge improvement over anything else available.
Unreal:
Similar in quality to the new xnormal -> UDK workflow released in the July UDK build. However, this DOES work with skeletal meshes since it does not rely in importing tangents/normals from the object. It is very important that you do not enable any options in UDK to import this information (NO EXPLICIT NORMALS BUTTON) as this will break the result. It is our understanding that there are some internal precision compromises being made inside unreal that ultimately limit the final quality. This is a huge improvement over the old explicit normals pipeline and using normal maps from max, xnormal, and maya. Also, be sure to uncheck remove degenerates on your import as this can also create errors.
Unity:
Again, not perfect but better than any conventional workflow (James O'Hare has an xnormal plugin that should provide similar results). In this case we are limited by documentation quality. It took us several months to get any information to be released and getting further support is difficult. Anyone who has more access to this information is welcome to contact us.
One obvious sample is this test asset I did for the tool:
This was baked in xnormal, converted to max tangent space, and previewed with the 3point shader.
Always had problem with normal simmetryzing, as it shows no problem on marmoset but does with Xoliul and 3point shader. Will try it asap
I hope companies will encourage this instead of doing information retention, I only see better content here !
Expect results comparable to that unreal image I posed for unity. You will still need the occasional split or supporting loop but more often then splitting smoothing at UV borders will solve things.
Also, everyone please post the results of your testing.
thats a good question. We have been working with 16bit tiff files but adding tga support would be a good addition.
Great stuff on 3d Motive, any way we could get a tut on this new tool?
And I second tga support.
Although I have one question. Will be there an inverse option to provide tangent space normal and low poly model to receive object space normals? Or it is already possible to achieve is some kind of way?
Good luck!!
quickly thrown together test in UDK. minus the conversion from tga to tiff and back for import into udk this turned out so much better than i would have thought, especially considering the terrible lowpoly, unwrap, smoothing and cage
no bugs discovered yet, will test it on some proper things next.
Yes, this is planned. Assuming developers know what the original map was baked in, and that the tangent space normals aren't horribly compressed, you should be able to do the conversion back to object space and then again into a target space. This would let developers on current projects improve their shading quality without having to go back and rebake anything.
That result looks great divi.
The reason in starts with object space maps is that for the most part, all applications agree on how they work. This limits the number of conversions required so as not to compound errors from multiple conversions together.
Your bake workflow should look identical except that you will just tell the software to output object space/world space instead of tangent space. From a projections standpoint, object space are no easier to bake. However, object space bakes will shade correctly with any geometry.
I assume that I'll convert object space to Max tangents for viewing and texturing my model, then convert it to Source tangents when I need to export out of Max. Does that workflow seem right?
You could work that way. Since source is like the other two engines in that it isn't perfect I would do a quick normals test before you consider the lowpoly/baking complete. If that all looks good you can just preview your normals in max in object space.
One note here, if you are doing any mirroring you would want to convert to a TS map that is max specific for preview. Otherwise simply using the OS map in max would mean errors on any mirrored/instanced parts(if the instances have been rotated).
Unless you have a shader that supports object space mirroring.
alecmoody@gmail.com
Here is the object space normal map I started with:
Here is the tangent space map that HandPlane gave me:
Looking good! I went to test it out and then realized that there were some problems with it.
Here is the model with a tangent-space map straight from Maya:
And here is the same model with the tangent-space map from HandPlane:
I am probably fucking something up, but I am not super sure what it is. The problems seem localized to certain areas. The sockets on the sides where the arms meet the torso are fixed up though! So that's promising.
I should probably mention that this map is only applied to the center object in those screenshots, his torso. The problem is most visible right in the middle of his forehead around the seam.
Any ideas?
alecmoody@gmail.com
Jason,
The middle image in his post is the object space map. The normal map covered in gradients is the handplane output. Those gradients are more or less correctly compensating for the crazy smoothing on the surface of that mesh.
By changing green to Identity, it clears up the other problems the map gets by switching modes like that.
alecmoody@gmail.com
Oh also, in the target engine you have the option to Input Tangent and Binormal information, is this feature still locked since there is no way to actually input that information yet.
Thanks again
Im using udk soon so this will be definatly be getting used!
How does change the creation of low poly ? You don't need supporting loops anymore to remove skewed detail ? Sorry if it is already answered but Ir really can't find anything about mesh creation changes.
Also...did I win?
[redacted]
Edit:fixed, problem was 3ds generating a bad .fbx file.
added OBJ support and TGA support to the list of requested features.
https://docs.google.com/document/d/1QeRqBU9OZN3mz5AHiQqT5aR8hYTLlvtQF1PQxyC5kiI/edit
getting that. However if I enable compatibility lets say with Windows XP SP3 it works fine.
edit: I have win7 x64
I actually get that error too. Up to this point I have been the only one so it wasn't a priority. I will add this to the list. one thing that is strange about this error is that if you reboot and try again it will usually work. I think it is some sort of memory management windows 7 uses. What do your system specs look like?