Introducing Handplane Baker
This is a long time coming for us- Handplane is now a full baking tool. Our goal with handplane baker is to build the most efficient baking tool for a production environment and make it free. We have a lot of cool features that should save you time and effort. I did a video overview of the tool which you can watch here:
https://www.youtube.com/watch?v=ACkX_t3QDnU&feature=youtu.be
You can get handplane baker on gumroad as $0+ name your own price here:
https://gumroad.com/l/znpF#
If you find a bug or have an issue- please take screenshots. If you get an error, or see some behavior that is clearly broken, please save a handplane project file and pack it up along with your models, then email them to me: alecmoody@gmail.comUpdates:
To get updates grab a new installer from gumroad. You can verify your version in the about window
*Fixed Issue where some users reported not having the correct Visual C++ distribution after installation
*Pressing the bake button while in progress now cancels the bake
*8 bit TGA output
*Added dithering for 8 bit outputs
*Fixed PNG not writing correctly for some users
*Added an option to generate smooth highpoly normals when no mesh normals are found
*Improved loading of mesh normals for high poly models
*Improved stability with large resolution and high sample count bakes
*Added option to suppress warnings for mesh triangulation
*Set default back ray distance to 5
*Added a button next to the output path that opens the output folder in explorer
*Included our old tangent space calculator, handplane 1.6 in the installer.
v 0.9.2
*Fixed some low level bugs exposed by meshes missing important information (texture coordinates, normals)
*Added notification for bake failures when models are missing texture coordinates, normals, or other critical info.Patch 0.9.1 <- download a new installer from gumroad
*Fixes FBX issues some users were having
*Sets default image format to tiff 16
Some of the highlights:
Fast and all CPU based
I have been doing my testing on 10-20 million triangle meshes. Loading and baking models that large is super quick. With the exception of our ray trace AO, all of our output maps are extremely fast. The raytrace AO is the slowest output but we also have an alternative post process AO that is very quick/smooth and works well in many circumstances. For a benchmark on large mesh handling (with an i7 4770k): A 20 million triangle mesh takes about 6 seconds to load into memory, building the projection structure takes an addition 5 seconds, and baking a 2k 4x super sample tangent space map takes 7 seconds. Totaling 18 seconds for a final quality 2k bake of 20 million triangles.
Projection groups
This lets you bake multiple meshes on top of each other into one output map. No more exploding models. Projection groups also let you do things like isolate ambient occlusion within a group, assign ray projection distances to multiple models at once, and assign materials. Here is an overview of the model loading and projection setup page of our UI:
PSD material output
You can create, save, and share libraries of material base colors. Assign them to pieces of your models and they are baked into an organized PSD set up with layer masks, ready for you to paint on. I am really hoping people post and share their material libraries so we can build a central repository for everyone to work from. You can name and edit colors for 3 material properties in the editor like this:
This is very flexible, and can be used for metalness, specular, or even something like dota2 material output. For dota2 output you would name your channels color, mask1, mask2 and then for the mask layers adjust each RGB color channel to set your desired metalness, color warp... We still need to figure out an a clean way to handle the alpha channel properties for specular exponent and self illumination. You can use the matID swatch color to get an additional 3 color channels but they aren’t masked nicely like the others. Suggestions are welcome.
The resulting PSD pulls in all the naming and colors done in handplane and looks like this:
New tangent space outputs
In addition to all of the tangent space outputs in older version of handplane we have added support for Unity 5.3, Unreal 4, and Source 2. All of these have also been ported to the tangent space calculator which I will post separately as handplane 1.6.
Future plans:
*More fast AO output options and improvements to what we currently have.
*I would like to look into substance painter integration or find ways to make our tool work seamlessly with substance.
*Figure out why exporting a model as FBX, and then exporting a second copy with push modifier results in a different file size. This is a pain for cages.
From suggestions:
*figure out FBX issue (someone who has this issue needs to send me files so I can reproduce it)
*Create warning with option to cancel when users bake without an output location set
*Add a button to the UI to open the output location in explorer
*.tga support <- Also make sure 8 bpp output is dithered
*Set tiff to default output. Personally, I don't like PNG files.
*Create a user editable default project
Replies
If I re-export as an OBJ after turning off isoline display the result is what you would expect.
Well, for what it's worth I am a new user and when I clicked this + sign at the left of "Highpoly models" I was totally expecting some kind of hierarchy tree to unfold as opposed to an explorer window to open. Even merely putting the little button on the right instead of the left would be a step in the right direction.
(I know I know, this is very minor stuff but hey, I thought I'd bring it up ! No reason not to follow established standards
As for example projects/models : maybe it is just a matter of offering such ressources as a separate download. I know for certain that had I access to such files I would be testing the hell out of the program already as opposed to having to dig through old assets. But of course I understand that it is also important to have users test out the tool with their own files to spot hard to find issues like the ones with isoline display on OBJ export.
I generally think those interface tweaks are good, but low down the priority list. If I could implement them myself I would but I don't want to take up programmer bandwidth on them yet.
I do think small UI details matter when its all considered as a whole. One thing we did on the original handplane that we brought into the baker - justifying long paths to the right to show file names and not root drives. I do not know why more software doesn't do this since its the info I always want to see in a file path.
www.handplane3d.com/2016-05-10-handplaneBaker_v0_9_2.rar
With this build, instead of crashing, it will provide a warning in the log window about what components were missing. This is one of the example models earlier that was missing normals and UVs:
Just to make sure people are reading this correctly, only the low poly model failed to load. The bottom two red notices are what happens when it cancels the bake.
Also, the crashes today were only indirectly related to the missing components so we are hoping that other people experience crashes we couldn't reproduce will have their issues fixed in this build. If you continue to have crashes with this build please try to post detailed info and ideally send meshes.
v 0.9.2
*Fixed some low level bugs exposed by meshes missing important information (texture coordinates, normals)
*Added notification for bake failures when models are missing texture coordinates, normals, or other critical info.But bringing them into maya first, and reexporting, allowed them to bake just fine.
OBJs from zbrush have no mesh normals so they throw an error when used in the low poly slot. In the newest build that is printed in the log window.
Hopefully we are done fixing critical issues and can move on to minor bugs, UI tweaks, and new functionality.
I was testing the baker using a purely ZBrush workflow and wanted to share two quick tests with ya.
The precision and speed is really nice; both these tests are done without any custom cages (the one is just a ZRemeshed model with quick UV Master uvs.)
For the process I ended up exporting out the highres from ZBrush with Subtool Master as *.OBJ's then exported the GameRes model out as an *.FBX from ZBrush (so that it would get smooth normals.) The results are just using all the maps generated from Handplane baker (cav and curve were plugged in for gloss/spec) then thrown into Marmoset Toolbag (no substance or dDo applied.)
Really liking the precision on this, excellent work! Keep it up!!
I saw there was a command line executable? There any documentation for that?
-Joseph
I agree with this. I have models that consist of 200-250 separate lowpoly objects. There has to be a better way than to create 200+ groups manually. As models get more and more complex they will consist of more objects. This is especially true for Virtual Reality, where geometric shape is very important, and less can be solved in the Normals map. So for example a game prop will consist of many separate pieces instead of a welded mesh.
Substances baker, can link High and Lowpoly by name by using suffixes like _HP and _LP. At least implement something to automatically link high and lowpoly, or create the groups automatically. In time this workflow is too slow.
I really hope for a baker that can solve this!
For instance, let's say you have a chain. This chain is comprised of 100 individual links in both the high and low. To create bake groups, all you would do is select every other chain link in both the high and low and merge them into an object/export them as a obj file or whatever. The alternative with name matching is to painstakingly ensure that each 100 links have the correct names and are separate objects in both high and low. I'm not sure about you, but selecting every other link would be faster by a huge magnitude for me to do.
So I would suggest trying this out before dismissing it.
I understand all that, I know many baking techniques/workflows, but baking many objects remains a problem. You always get baking errors and have to remake parts, adjust highpoly and lowpoly topology. By the way, naming can be done automatically with maxscript. I use maxscript to link the high and lowpoly meshes inside 3dsmax.
I'm happy with the bakes and it was rather quick considering I tested it on a Surface Pro 4. Curvature is great, so much better than substance. Projection groups are awesome, better solution than name matching.
You will definitely get my DOTA shares!
Some suggestions:
1. My model was triangulated using "turn to poly" in Max. I didn't use the triangulate option in the obj exporter. Handplane always gives me a warning, that my model isn't triangulated.
2. A Projection Group always needs a lowpoly at the moment. I tried to add an AO ground plane or an AO character mesh, but got errors because of the missing lowpoly
3. Can you make an average normals / raw normals projection switch per projection group? Most people bake with average normals projection, so they don't get holes at hard edge corners. But sometimes baking with the raw normals gives you better, less distorted results. Substance has a switch for all objects, which is already nice. Per group would be awesome!
http://alecmoody.com/10/index.html
Linking high to low based on file name seems flawed to me. Aren't you limited to a single high poly for each low at that point? Creating groups from file names is definitely something we can do but the UI is not intended to work that way and its going to be a really long list to scroll through.
Ideas?
The way the naming could work, and works in substance.
Is that Box_LP would match with Box_HP, Box_HP_Part1, Box_HP_A and so on.
So for any lp piece you could have a endless amount of hp pieces that would match.
Not sure if the UI would need to reflect the name matching, since you might have only 1 hp and lp fbx, the names are contained in the fbx, for my dropship I had 3 fbx sets using name matching(Body, cockpit, interior).
Isn't setting up perfect naming conventions for 1000 high and low objects a giant pain in the ass?
Guess part of the advantage is that you set up everything in your 3D package, since it reads it all from the fbx.
Edit: Good to see the hpb format is so simple, opens up the possibility for some good plugins/scripts
to bake with the command tool: handplaneCmd.exe /project project.hpb
Also, we may change the command line function names if we release a more polished and documented command line tool.
There is a problem with png files right now, for now just use tiff. Make sure you grab the newest build, we switched the default image format to tiff.
Baking should be isolated to UVs in the 0-1 right now. Are you seeing other behavior?
A cancel button is a good idea.
I have made weapons where there are 250 separate pieces. It makes for a much better model than trying to do it with normal maps. My Sage character also uses 200+ unique lowpoly objects. There was no way to get the same results with only normal maps. Models will get more complex, especially for Virtual Reality.
There are probably multiple ways to go about this, but one possible solution is to implement the Substance naming workflow on top of the current workflow. The ability to create groups manually. But also an option (checkbox) to automatically link by name within that group. So you could thoratically create one large group (or a few), and the program would link Lowpoly and Highpoly models within that group automatically. Then somewhere there should be a setting to define what Prefix or Suffix will be used (like in Substance baker). So you can choose naming conventions like name_LP or name_low or name_Lowpoly or LP_name.
From my perspective, the direction we go is based off of how well this does for us. If our workshop share doesn't grow and we decide we want to try a more conventional method to get some revenue back out, we will think more about the paid version with SDK for studios.
How would people want that to work? I am imagining handplane spitting out a substance project file with everything set up to start painting.
My concern with working from the other direction, having people control handplane from inside substance, is that there is a lot of necessary UI to control features of handplane we would have to replicate inside substance.
We will be documenting the command line and the bake project file formatting so users can come up with new ways to use the tool.
I would be interested in command line access to your baker. I have some experience creating blender addon for baking models directly from blender in batchtools. With this addon, there is no need to manually export objects, I just group all highpolly objects in one prefab then mark it as highpolly, then I choose lowpoly, then select maps to bake and with one press of button everything is exported and baked in batchtools.
From image in first post, I can see your software works in similar way - you can bake multiple highpoly objects in one lowpolly obj. But your baker still requires manual import of files, then setup of all options etc. This could further automated if users could access your baker from command line.
So I am glad you plan to document command line and I hope I will have time to test your app soon
1 - Best case scenario
Using a lowpoly and its corresponding highpoly (both .OBJ) things seemed to go as expected workflow wise. The AO bake in particular was pleasantly fast. However I am noticing a few problems, some of which might be related to the fact that the models are very small in terms of generic units):
- The TS bake seems to have failed, even though the OS bake went fine.
- The AO and OS bake both appear noisy and/or faceted. Since the highpoly model was exported straight out of Mudbox as OBJ I would expect it to come in smooth.
2 - Worst case scenario
For this "thought experiment" I am imagining using the highpoly OBJ used in the previous test, but a lowpoly model that I know to be out of whack scale wise (that is to say, not my original bake model but rather an "end of the pipeline" model which had been adjusted scale wise and location-wise for game use). Now of course I would not expect such a case to bake properly since these factors are outside the scope of a baker, BUT, this highlights the fact that there is something missing when it comes to error prevention: a simple 3d viewer able to load lowpoly models as well as very dense highpoly sources, letting the user check if everything is in order before baking.
Xnormal allows to do this just fine - here I can tell that my highpoly model is 100 times smaller than the low and positioned differently :
Furthermore, there is also a need for a post-bake 3d viewer displaying the bake results on the lowpoly model in realtime, in order to let user check all the outputs without any need to load up their 3d program of Toolbag.
I hope this makes sense !
The issue I'm running into is that I'm getting slightly skewed mesh projections which I don't get with xnormal.
I never have to fiddle with xnormal using values between 10 to 50 for min/max ray distances and 95% of the time I get the perfect result.
All settings are virtually identical between the two softwares:
-8K render, 64 pixel padding
-No cages used
-16 bit TIFF format
-16x supersampling (vs xnormals 4x AA)
-Tried playing with the ray offsets but seemed to make no difference
-Using the unreal4 preset
The following example is a small portion of the complete render which may not seem like much but it matters to me
*Skewed/offset Handplane Baker render (compare the 3 circle shapes)*
*Expected result Xnormal render (perfect circles)*
If you decide to request the files from me, not sure how I'm going to get the 9mil high poly version over to you
-Additional/missing features that I would love to see:
When rendering an AO map, I love maximizing the spread angle in xnormal to 179.50, something that I can't do in this software or am unaware of.
Having the choice of a uniform or jitter AO/cavity
No render-to-texture options, would love to have a similar interface like in the material preset settings to be able to specify textures to be rendered and projected onto an image.
Currently unable to maximize black and white values for a heightmap like in xnormal's interactive normalization pop-up.
A deeper explanation about the various numbers, sample radii, sample count and how they will affect the final render.
After a single render the software becomes slightly sluggish, not sure if its keeping allot of stuff in memory, xnormal's RAM bar is a nice thing to have so you know when to clear/purge/close/restart.
Please let me know if you need additional info!
Many thanks,
Hayo
I believe we use low poly normals to determine ray direction when there is no cage. If you want more control over ray direction, use a cage or add a few verts to control skewing.
"Having the choice of a uniform or jitter AO/cavity"
We have plans for improving both the raytrace and TSAO
"Currently unable to maximize black and white values for a heightmap like in xnormal's interactive normalization pop-up.
A deeper explanation about the various numbers, sample radii, sample count and how they will affect the final render."
This is something I would like to implement. Ideally, automatic min max values and the ability to adjust from there. I do not like the heightmap tonemapper popup in xnormal since it interrupts the bake process and is awkward to use. There will also be a lot more documentation. For now, the critical adjustments are highlighted in the help section of the website and can be quickly loaded by hitting the ? button. We currently expose more options than I think are necessary.
"After a single render the software becomes slightly sluggish, not sure if its keeping allot of stuff in memory, xnormal's RAM bar is a nice thing to have so you know when to clear/purge/close/restart."
I haven't seen this on my machine. Are other people seeing this? Gui performance can get slow when you have a lot of stuff loaded and is something we need to work on. It should not be getting progressively worse between bakes.
I'm not sure why the TS bake failed and I haven't seen a tangent space bake fail in that way before. Are you on the latest version 0.9.2? If so, are you getting any warnings about missing information in the low poly model? Missing mesh normals. If you can pack up your files and send them to alecmoody@gmail.com I will take a look and report back. Also, if anyone else has seen tangent space output that looks like this, please chime in. This is the first time I have seen that.
As far as viewer goes, I am hesitant to add one unless we can make navigation work well with meshes of all scales. It would not be a difficult or time consuming task to add a simple viewer- However, I wouldn't want to implement one that didn't feel easy to navigate or natural in all circumstances. Also, every feature is being planned around being compatible with really dense meshes, this is to be forward looking so we don't build features that become unwieldy in a time when 50 or 100 million triangles is common. Basically, when you commit to having a viewer for high poly models, you need to make sure you can load and display them on a video card in a timely fashion - I don't want users waiting minutes for gigs of mesh data to make its way to a video card and I don't want the video card to become a bottle neck on how many polygons someone can work with.
A viewer for final bake results- again I am hesitant. It is something I would like to have but I'm not sure it is feasible. The final normal map result on screen is more complicated and often mitigated by more factors than people are aware. I wouldn't want the tool to display what looked like a correct result unless we were totally sure it would look 100% identical in engine.
As for a mesh viewer and a result viewer: indeed some of this stuff is hard to make 100% perfect (especially when it comes to displaying the result of a specific tangent space for instance) but I am personally not thinking of it from that angle alone. What I mean by that is that it would not be just about displaying a perfect result, but also and perhaps more importantly about providing an error prevention system for the user.
Did the bake go well ? Were there any missed rays ?
At the moment there is no way to do that without inspecting the generated textures and loading them + the model into a viewer like Toolbag2. Not a huge deal of course since it does not take too long to setup, but based on past of collaborations with other artists there are definitely cases when people do not necessarily take the time to thoroughly check their results in the target engine before passing over their files. I've also run into the case of artists just merely looking at their TS normalmap bake to check if it is "pretty", not understanding that gradients are not necessarily a bad thing. Note that I am not necessarily blaming such practices, as they naturally come from the fact that few baking environments provide an intuitive result checker.
Handplane baker potentially providing a simple viewer reproducing the conditions of the various supported engines would be a great way to avoid that and would instantly position it as a next generation baking tool, I think.
Just my 2c !
Also where can i find material preset(Load Library option)?
http://polycount.com/discussion/146280/smooth-edge-shading-legitimate-technique
(Not as important as the linking by name though :-))
I'm testing HandPlane baker with a model already baked with Xnormal (to Unity 5.3) for easy comparison.
This software is awesome, easy to use and run faster (except AO
Thanks to the Developers for sharing this and for their many helps and updates.
My first test was a big fail : all my exported maps were "empty"
The problem was on my side, because the pivot point of my HP model was not at the same place that my LP model ( This is not a problem with Xnormal so i don't see it immediately).
After solving this mistake, my second test was much better !
Some little errors to some places like @Ikifenix >>> Errors solved by change "Back Ray Offset" value to 10 (like you said). Thx for the tip, it works fine to me
Now, there are still some errors that i can not solve :
here is a screenshot from unity 5.3 :
On the left, LP model with normal map from X normal.
On the right, same LP model with normal map from Handplane Baker.
The Low Poly model is from Blender (v2.76) WITHOUT sharp edges. All model has a Smooth shading.
Same srceershot with errors surrounded in red :
and a detailed view :
Maybe these errors can be fixed by adding sharp edges on LP model ?
Many thanks,
Good testing to all
PS : sorry for my very bad english...:s
The LP and Cage models are triangulated.
the LP model in blender, with "triangulate" modifier :
then, LP model was duplicate and i've added "displace" modifier to make the CAGE :
Maybe the problem comes from the Cage triangulation :
When i duplicate LP model with "triangulate" modifier and add it "displace" modifier to make the cage, is it possible that blender calculates (randomly) a different triangulation?
The result is that LP model has a different triangulation than the cage ?
alecmoody@gmail.com
Models sent
Here is screenshot of the result (UE4 output from Handplane baker, with inversed green channel) :
Now, i will test other maps output (AO, cavity,...) for this model, to find good parameters.
Then, i'll rebake other models from same scene with Handplane baker for full test.
But i am pretty sure that i'll include Handplane baker in my workflow.
Easy to use, intuitive, elegant and very usefull. This software is a gem, i already love it
First determine the total pixels of resolution divided by a 1024x1024 map - For example a 1024x1024 map is 1, a 1024x2048 is 2, a 4096x4096 map is 16 and so on. Another way to think of this is if a 1024 map is a tile, how many tiles make up your output size. We will call this Pixels
Pixels*AO Samples*Super Samples = Target sample noise level
For a final bake you should be looking for a target sample noise between 300 and 800 - depending how it is going to be used and the material properties. A rock might need less than a clean white wall. More than that and you are probably over sampling past the point of diminishing returns. We are also going to implement some sample smoothing so noise is reduced.
Some examples for a target noise level of 320. The times listed here are just for the AO calc, 20 million triangle highpoly model, i7 4770 with all cores being used. Notice how similar the render times are regardless of resolution.
Right click images to view full size for evaluation.
1024x1024 map:
2048x2048 map:
4096x4096 map:
What you think to add tesseletion pipline to your tool?
By now you need to manually do all steps to convert world space to tangent space normal.
It's take lots of time to do this stupid technical work. Especially if something went wrong.