Official handplane support thread - Now freeware!!
ngon master
Please post with any problems you have related to normal maps made in handplane.
www.handplane3d.com/ to download the latest build
UPDATE:
We just finished testing an update for handplane v1.1. There are some bug fixes along with one major simplification of workflow. We have added a new option for "baked in" that automatically detects how your object space map is oriented. This should reduce confusion. I am suggesting that everyone use this option instead of any of the listed baking tools in the drop down. Also, I wanted to point out that handplane will accept any object space map, even from applications that aren't listed.
v1.1 changes:
Fixed crash when right click closing from the task bar.
Fixed crash in obj file reader when negative indices were used.
Fixed output of non-square tga textures.
Fixed overwriting input image file when no suffix was specified.
Added auto detect setting to 'Baked In' option. This is now default.
Added mudbox and zbrush to 'Baked In' option.
v1.2 changes:
Improved automatic detection of object and channel orientation
Added Maya 2014 .h3d plugins
v1.3 changes
Added a beta output for Bethesda Creation engine.
Fixed an occasional bug with smoothing groups handing for Unreal output.
Added the option to select world or object space normals input.
v1.3.1 changes
Fixed a bug introduced in 1.3 related to smoothing groups handling. This bug affected multiple outputs in handplane.
Release notes video:
[ame="
http://www.youtube.com/watch?v=g3f3o81hs5w"]handplane 1.3 release notes - YouTube[/ame]
The installers will automatically patch your existing install. You will not lose any presets of application settings.
v1.5 changes
Added support for blizzard engine/ Starcraft 2
Added a button to open output directory
Recompiled Xnormal/source plugin for version 3.18.10
Direct link to build 1.5:
http://www.handplane3d.com/handplane_v1_5.rar
www.handplane3d.com/ to download the latest build
UPDATE:
We just finished testing an update for handplane v1.1. There are some bug fixes along with one major simplification of workflow. We have added a new option for "baked in" that automatically detects how your object space map is oriented. This should reduce confusion. I am suggesting that everyone use this option instead of any of the listed baking tools in the drop down. Also, I wanted to point out that handplane will accept any object space map, even from applications that aren't listed.
v1.1 changes:
Fixed crash when right click closing from the task bar.
Fixed crash in obj file reader when negative indices were used.
Fixed output of non-square tga textures.
Fixed overwriting input image file when no suffix was specified.
Added auto detect setting to 'Baked In' option. This is now default.
Added mudbox and zbrush to 'Baked In' option.
v1.2 changes:
Improved automatic detection of object and channel orientation
Added Maya 2014 .h3d plugins
v1.3 changes
Added a beta output for Bethesda Creation engine.
Fixed an occasional bug with smoothing groups handing for Unreal output.
Added the option to select world or object space normals input.
v1.3.1 changes
Fixed a bug introduced in 1.3 related to smoothing groups handling. This bug affected multiple outputs in handplane.
Release notes video:
[ame="
http://www.youtube.com/watch?v=g3f3o81hs5w"]handplane 1.3 release notes - YouTube[/ame]The installers will automatically patch your existing install. You will not lose any presets of application settings.
v1.5 changes
Added support for blizzard engine/ Starcraft 2
Added a button to open output directory
Recompiled Xnormal/source plugin for version 3.18.10
Direct link to build 1.5:
http://www.handplane3d.com/handplane_v1_5.rar
Replies
I already watched some videos, very good explanations, thank you !
What engines/programs does this tool convert normal maps for?
What is the benefit of this tool if you are already working with synced tangent calculations and what not?
Is it possible to batch bake to all supported engine/programs?
I imagine this will be handy for freelance artists that do not know for sure what engine is being used or for uploading to some asset selling sites/stores. That way the client can chose themselves what normal map works with their engine.
Since I do not have much experience with object space normal maps, what would I do with additional normal map overlays made with nVidia plugins or nDo and such?
Since OS normal maps work differently than TS normal maps I imagine a simple nVidia generated normal map overlay will not work with object space normal maps.
So in order to use additional normal map overlays, you would need to edit the exported normals after using HandPlane for each exported version.
Doing it for a single export should not be too much of an issue. But if this tool supports exporting to all engines at the same time, it might be worth looking into being able to feed an additional overlay normal map.
Anyway from what I understood, this tool will only be of use to someone if they are not sure what the engine being is will be, right? Or am I missing something?
Probably not a lot, but object space is a bit more solid if you're working on non-tri meshes or meshes that aren't smoothed yet.
Not sure.
Yeah, you'll have to edit the exported tangent normal map.
It's just generally useful. You don't have to triangulate your mesh when you bake your normal map, you can edit the smoothing after baking, you can technically edit the geometry so long as the silhouette and UVs remain consistent. Then just export to FBX, convert the object space map and you're golden.
I export my triangulated object from 3dsmax and the baked object space map with default max settings to HP.
When I choose the files and try to bake I get this.
"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."
If I choose yes the baked map comes out looking more like a broken object space map. If I choose no the map comes out like a tangent space map but with triangle errors on my cylindrical shapes.
Any ideas on this? Will continue to work it out.
The message that pops up is handplane checking the direction of the normals on the lowpoly and comparing them with what is in the object space bake. If the difference is large it shows that message. It is intended to fix y/z flip errors but it can also get triggered by things like inverted normals in the object space map.
I can't seem to get things going however.
I've done a very basic bake with mirrored UVs (offset with 1 uv space horizontally) and separate smoothing groups for top part, sides and bottom.
I've baked out an object space normal map:
I've then exported the LP as an FBX file with the following settings:
I've loaded the exported LP along with the object space normal map with the proper settings.
Here is the resulting tangent space normal map:
There is a weird detail on the new map though as highlighted.
When I put this new map into a Xoliul Shader's Normal slot, I get the following result:
I get this really nasty seam in the middle as well as a faceted look along the curved surface of my mesh.
I get the same result if I switch my target engine to Unreal 3. Although I did not import the asset into UDK, using the Xoliul Shader in Max shows the same results.
Edit: In Marmoset, the faceting disappears, along with the seem running along the top and bottom. However, it appears the the green channel is flipped on the mirrored side...
Elod- I noticed you are using an out of date fbx version (2013.3 is current), could that have something to do with it?
Quack: thanks for the tip! I'll update it.
Elod:
The other thing that is happening (what is wrong in marmoset) is that the wrong set of shells are in the offset space. Apply your normal map as a diffuse texture (and dont have anything else on in the shader) and you can see that there is an interruption in the pixel colors across that surface that is having problems. Likely what happened is that you did the object space bake with differnt shells in the 1 square than you are using to display the model.
Is the normal map that works out of max a different format or bit depth? Something is happening where the shader is breaking and there must be some variable related to the file that is causing it.
http://www.polycount.com/forum/showpost.php?p=1760374&postcount=46
With that said I did more testing because of this and realized that script may set the hard edges correctly but doesn't improve the bake of the object at all in UE3. So it was a wasted step that I will just remove from the workflow and will fix the popup handplane was giving me.
I just took the Normal map that is working (the original map baked with Max) and loaded it up in PS. I did not do anything to it, just load it up and saved it out again with the same .TGA settings (32bit). But when I apply it to my mesh, I get the errors again. It should be the exact same map... but for some reason it's not. In PS it looks completely identical, even if I reload the newly saved out map, but in Max it looks much darker compared to the original. I've tried saving that map out as .tiff and .png .. same thing. hmmmm
I`m going something terribly wrong... will keep digging to figure this out. Thanks for the help again, Alec!
Free hard edges are a good thing. I have had some trouble with that script. Max seems to dislike complicated smoothing intersections. The textools splitting by island always works for me. Also, for unreal, make sure you are using explicit normals, importing tangents, and remove degenerates is off.
Hi Malcom,
So from an artist standpoint what you want is to bake a normal map and not get shading errors (or minimize them to the extent possible in that engine). To actually achieve that goal there are a lot of things that need to be done the same way between baking and displaying the normal map. Off the top of my head:
1) Normals need to match
2) Mesh tangents need to match
3) Tangents need to be interpolated across a triangle the same way. You can have correct tangents at each vert but you will still get errors inside the triangle if the interpolation doesn't match
4) quads need to be triangle stripped the same way
Some of this can be passed around with the file exports but the interpolation cannot. handplane is designed to recreate all of this behavior so normals, tangents, and triangle stripping doesn't need to be saved into your files. From a workflow standpoint passing this data around can create huge headaches. A few scenarios where this can be a problem:
*A freelancee artist works in 3dsmax and bakes his object in xnormal using max tangents/normals. Later, an in-house artist using maya re-exports the model. The shading will break. In this case the only solution is either passing the model back through max or re-baking from scratch.
*Anyone exporting their files from 3dsmax who isn't running qualified normals in the viewport will get the wrong tangents. Not sure if nitrous affects this but I would suspect running the nitrous viewport would also output the wrong info.
*Unreal only supports imported normals and tangents with static meshes. Anything rigged will not work (so characters, guns, vehicles...).
I would also point out that if you are using xnormal, in the past (haven't done this in about a year) baking with a maya sbm or FBX did not produce a correct maya normal map. That is either just the interpolation not matching or there is something else missing from xnormal's handling of the data.
In addition to all of these issues, and the fact that you can't even pass all the necessary info in the files, it's a much more fragile workflow with dependencies between 2 or 3 applications where there are a lot of failure points. Tracking down where the problems are originating from is very difficult. handplane is the opposite approach. Any artist can get a correct normal map for any of the supported engines from any combination of tools that can make an object space normal map and correctly send the mesh, smoothing splits, and uvs to our tool. The normal maps handplane makes are actually correct for the behavior of the target engine, no dependencies.
There are also a bunch of other uses for the tool related to correcting projections but that gets more complicated.
Has anyone requested PSD support? I'd like to load up a 16bit objectspace PSD with layers, and have Handplane use all the layers as the source. In the future it would be cool if I could choose a single Group to use as the source, but that's just gravy.
Zbrush/Maya> xNormal> Game.
Perhaps we have just been overlooking the issues, it sounds like you want us to bake an object space normal map in xNormal and then run it through hand plane and choose Maya as the output format for best results. Is that correct? I'll get one of our artists at work to test it out and compare the results.
I'll need to look into it a bit more, I can't remember if we are triangulating the meshes in Maya, we must be to get anything usable out of xNormal. Not sure if the meshes are triangulated in Maya though before the low poly model is saved, I don't think our game meshes are triangulated in Maya. Is this what syncing the engine to Maya's winding order fixes?
make sure your artist uses the supplied maya plugins if they aren't force triangulating the meshes. Maya handles normals related to triangulation differently than other tools. Basically, a quad can have different normals depending on which direction it is triangulated. However, in maya there is a third possible state for an untriangulated quad. So for a quad there are really 4 possible normal orientations- internal triangulation left or right, or force triangulated left or right. The handplane exporter for maya passes the internal direction of untriangulated quads so that the normals can be correctly calculated.
Also, which version of maya are you guys using? 2013 made this all a lot more complicated when It added a rollout menu for changing how normals are weighted. 2013 should default to angle and area weighted where as 2012 and earlier was unweighted. That is why in handplane there are different outputs for 2012 and 2013 maya. I prefer to avoid area weighted normals and use the 2012 output.
Edit:
Read your post again. Yes, maya+zbrush-> xnormal object space map + handplane is the workflow you want to use. handplane makes a really good companion to xnormal for a bunch of reasons. One of the little workflow advantages is that you can use a model with no smoothing splits when you do your projections to avoid xnormal splitting the projections (or having to use a custom cage) but add in smoothing splits along UV borders for you actual game model (and the model you run through handplane) to reduce the intensity of gradients in the normal map.
I just made a quick video tutorial showing how to work with handplane, maya, and xnormal together:
[ame="
I haven't been working with maya for a while and don't know anything about 2013.5
Put the correct version of the plugin into program files/autodesk/maya2013/bin/plug-ins
After restarting maya it should be in the plug in manager. If not let me know and I will do some research into 2013.5
I'll have one of our guys rebake an existing asset following this video and see what happens. I know one of our models has excessive uv islands to get good shading in the normal map and adding edge loops wasn't an option so it would be great if this tool could get better shading on that model.
Its also very important that you genuinely *do* have an engine that is synced up to Maya as well. If you're using xnormal to bake over Maya it makes me sort of wonder if you do.
An easy way to test, is to take an existing asset, soften all of the edges and re-bake* it in maya, and then preview it in the maya viewport with HQ shading or whatever its called. You shouldn't have any smoothing errors except for really extreme cases.
Then, export that mesh and load it into your engine, and apply your Maya baked normal map. If the results you're getting in-engine don't match what you see in the Maya viewport, your engine isn't synced to Maya, in which case loading a Maya-centric normal map from handplane won't help.
*If your source mesh in has quads/ngons/etc, lock the normals and then triangulate before exporting. If you triangulate without locking normals you'll get errors, and if export without triangulating you may get errors from differing triangulation as well. You can triangulate before you bake too, but it isn't really necessary in maya(because you can lock normals).
Another thing to keep in mind re: hard edges vs bevels/edge loops. Adding in hard edges ups your in-game vertex count, similar to beveling edges or adding in edge loops. The cost to add extra bevels may be nil compared to the *real* vert count of the asset, and may allow you to use less uv seams. Your actual vert count, which is what really determines performance of a model(not triangle count), is a combination of vert count, hard edges, uv vert count, and mat id splits(not to mention draw calls, but that's another can of worms). - Sorry to side track a bit here, but its a real common misconception. If you can get your workflow synced up, the need to add excessive bevels or hard edges really goes away.
My bad. I fixed the link.
I did a little more reading about 2013 extension and it looks like those plugins will not work for you. We are trying to figure out a solution but it might take a while.
I'll post the artists exact workflow when I get into work and you can point out if we're doing something wrong. Would love to get this step by step process sorted out sooner rather than later.
Also, since we don't do any baking in Maya shouldn't we sync our engine to xNormal since that's where all our maps come from, or does syncing the engine to Maya help because the low poly's are coming from Maya?
Alec, it would be nice if you shared that handplane model you built so we could use it as a test case, one you guys are familiar with looking at it, and two I can't post any of our wip assets on this forum so I will need to make a test case model to do the tests EQ is talking about.
I will pack up the handplane model in a little while- along with a finished object space bake so you guys don't need to go the trouble of baking it again.
This should be all you need to do some tests with that model. I included the highpoly files so if you want you can rebake. Also worth pointing out- I used no smoothing splits when I made the tangent space map. In practice there is a lot of free cleanup from using existing UV splits. Oh and make sure you are previewing in viewport 2.0 and not high quality mode. There can be very very slight errors with our output in high quality mode but viewport 2.0 should be perfect.
Assert
Assert: index >= 0 && index < _size
Index out of range
C:\Projects\HandPlane\code\Vice/Array.h(188)
Break in the debugger? Cancel to exit.
Yes No Cancel
1. Load the OBJ.
2. Load the TIF.
3. Baked In = Xnormal.
4. Dest = c:\temp
5. Target = Unreal
http://dl.dropbox.com/u/5913234/handplane_OBJ_crash.rar
OBJ was saved from Max 2010 x32. TIF was generated by Xnormal 3.17.16.22338 x64.
I'm finding that the latest FBX exporter for Max 2010 (FBX 2012.2) is miscalculating the tangents and binormals, which is adding horrible seams to baked maps. Seams disappear if I disable tangents&binormals when exporting the FBX. That's why I tried OBJ.
Just to clarify your workflow. Are you getting different normal map outputs from handplane based on FBX files including tangents? That shouldn't be happening. Or are you attempting to import tangents into unreal while also using handplane generated normal maps? (if so, dont do that).
I would avoid using OBJ files in general. There are so many variations on the format that it is very difficult to work with all of them. I will download your crash files tonight and see if I can pinpoint exactly what configurations of OBJ work and don't.
I'm trying FBX because I thought Handplane wanted to be fed tangents in the mesh file. Is that true? OBJ doesn't store tangents IIRC.
FBX is the most reliable format. After work tonight I will look into this more.
Cheers mate, awesome work on the tool btw!
And here is our baking workflow. Alec, EQ, please point out flaws if you see any.
-Export high poly out of Zbrush to .obj.
-Create low poly in Maya, no triangulation, soften normals, add edge loops to fix bad shading, export as .obj.
-Create custom cage in Maya, duplicate low poly then transform component tool, then move any troublesome verts by hand if necessary, export as .obj.
-Bake high to low in xNormal.
-Export model out of Maya to game, no triangulation.
The only other sticking points I see are related to how your engine handles internal triangulation direction. If it triangles quads exactly the same as maya (or just gets passed their direction) it should be fine. The other thing is that you should be using some hard edges where you have UV splits. Normally this would cause projection issues in xnormal but you are already using custom cages which correct this issue. EQ has some good illustrations of what happens when a really gradient heavy normal map mips down.
As far as I know our engine triangulates quads the same as Maya, we had an issue in the past getting mirrored normal maps to look correct so I think it is all sorted. Do you have a suggestion for how we could test this, what if we look at a model in game with triangle wireframe turned on and compare the triangulation to the Maya viewport. I believe there is a way to draw the triangulation in Maya before you commit, draws dotted lines showing you the direction of the edges, but keeps the model in quads.