Home Technical Talk

Introducing Handplane Baker

13567
AlecMoody
ngon master
Offline / Send Message
Pinned
AlecMoody ngon master
Hello Polycount,

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.com

Updates:

To get updates grab a new installer from gumroad. You can verify your version in the about window


11/12/2016 - v 0.9.3

*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

*Warns users if they are baking without an output folder set

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



Please test our tool, break it, and post bugs and feedback in this thread. You can also find more info on the tool at http://www.handplane3d.com  The help page has lots of detailed information and provides a quick overview of the features.













Replies

  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    i resent as 14 so you can mess around
    Okay, more testing with this. you exported your mesh with isoline display on so it was missing a bunch of edges. For some reason handplane isn't loading the smoothing when it gets an OBJ from an isoline export. I am assuming it is getting tripped up generating normals from the ngons. That is something we can fix.

    If I re-export as an OBJ after turning off isoline display the result is what you would expect.
  • skyline5gtr
    Offline / Send Message
    skyline5gtr polycounter lvl 9
    AlecMoody said:
    i resent as 14 so you can mess around
    Okay, more testing with this. you exported your mesh with isoline display on so it was missing a bunch of edges. For some reason handplane isn't loading the smoothing when it gets an OBJ from an isoline export. I am assuming it is getting tripped up generating normals from the ngons. That is something we can fix.

    If I re-export as an OBJ after turning off isoline display the result what you would expect.
    wow that is wierd, good catch i never would have thought that was the reason lol
  • pior
    Offline / Send Message
    pior grand marshal polycounter
    I think your mesh loading window looks nice. I am open to that but I am slightly concerned it will be more confusing to first time users.

    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.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    I wanted a button that said "add meshes" but that page is becoming cluttered and it was too busy.
    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.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Anyone who has had crashing who wants to test this build before we put it in an installer and push it to gumroad, grab it here:
    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.



  • Esprite
    Offline / Send Message
    Esprite polycounter lvl 9
    If you use the FBX exporter plugin in Zbrush you can export a mesh with smoothed normals (snormal).  Seems to work just fine for Handplane :smiley:


  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    There is a new build on gumroad

    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.

  • Joopson
    Offline / Send Message
    Joopson quad damage
    Tried it yesterday, with a high and low from zbrush, and it was crashing on "bake".
    But bringing them into maya first, and reexporting, allowed them to bake just fine.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    That was patched today. Redownload off of gumroad for 0.9.2
    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.
  • patrickchu
    Offline / Send Message
    patrickchu polycounter lvl 4
    Hi, newbie here. May I know that how does it different from Xnormal HP to LP workflow? Could you pls explain how the different projection group works beside the typical HP LP workflow and is there anything I needed to know b4 using this baker? Thanks
  • Piggyson
    Offline / Send Message
    Piggyson polycounter lvl 5
    Hey Alec,

    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

  • OccultMonk
    Offline / Send Message
    OccultMonk interpolator
    This looks really promising and can't wait to give it a try.

    I do however have a request and that is rather than just supporting a workflow whereby you split your HP into separate meshes based on material ID, you adopt a 3D max like option "match material ID's". 

    I work on models which splitting them and regrouping parts of the models according to their material ID to avoid bits of model being baked onto other parts would just not be feasible. I can see your current workflow would be OK for small (in physical size) models and ones where you only have say 30 or so separate elements to consider. However models I work on are made up of thousands of separate objects, several millions of triangles and are structured in layers logically. I group these thousands of objects into logical and localised meshes and the prospect of mashing up all of the layers and mesh groups to work for baking does not fill me with joy. This "match material ID" is literally the only reason I still solider on with 3D Max default scan line baking. Having the match material ID option means your bake will only project from your low poly model to correspondingly matched material ID geometry on your HP. No exploding required and it's just a case of setting up a 3 or so multi sub material, apply it to your high and low models and go around setting the material ID via modifiers or polygon selections and edits. Each mesh would then contain multiple material ID geometries and it matter about changing the logical layer and mesh structure just for baking. 

    Hopefully this makes sense, but if not happy to describe in a more detailed doc the predicament but a quick look at anyone of my threads would give you an idea of the models in create..

    Great work!

    Whisky

    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!
  • EarthQuake
    You wouldn't need to export each object as a separate file, or set up a unique group for every object to do this sort of baking, you would only need to have enough groups to ensure that parts aren't overlapping. Even with extremely complex meshes this could probably be accomplished with less than 5 groups.

    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.
  • Stromberg90
    Offline / Send Message
    Stromberg90 polycounter lvl 11
    Sweet :)

    Some nitpicks:
    -Name missing on the taskbar, only icon.
    -Option to use file name from the first mesh or similar.
    -When browsing for folder/file location, you can keep clicking in the "..." button, to open more windows, maybe disallow that and bring the current one to the front.
    -Buttons with grey text, to me that says they can't be clicked on, which is not the case in handplane.
    -A lock icon like photoshop, so that texture width and height changes together.

    Not sure if my post got "lost" but it seems like that, so I'm going to quote myself ;)
  • OccultMonk
    Offline / Send Message
    OccultMonk interpolator
    You wouldn't need to export each object as a separate file, or set up a unique group for every object to do this sort of baking, you would only need to have enough groups to ensure that parts aren't overlapping. Even with extremely complex meshes this could probably be accomplished with less than 5 groups.

    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.

  • katzeimsack
    Offline / Send Message
    katzeimsack polycounter lvl 17
    Nice release :)

    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!
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    This looks really promising and can't wait to give it a try.

    I do however have a request and that is rather than just supporting a workflow whereby you split your HP into separate meshes based on material ID, you adopt a 3D max like option "match material ID's". 

    I work on models which splitting them and regrouping parts of the models according to their material ID to avoid bits of model being baked onto other parts would just not be feasible. I can see your current workflow would be OK for small (in physical size) models and ones where you only have say 30 or so separate elements to consider. However models I work on are made up of thousands of separate objects, several millions of triangles and are structured in layers logically. I group these thousands of objects into logical and localised meshes and the prospect of mashing up all of the layers and mesh groups to work for baking does not fill me with joy. This "match material ID" is literally the only reason I still solider on with 3D Max default scan line baking. Having the match material ID option means your bake will only project from your low poly model to correspondingly matched material ID geometry on your HP. No exploding required and it's just a case of setting up a 3 or so multi sub material, apply it to your high and low models and go around setting the material ID via modifiers or polygon selections and edits. Each mesh would then contain multiple material ID geometries and it matter about changing the logical layer and mesh structure just for baking. 

    Hopefully this makes sense, but if not happy to describe in a more detailed doc the predicament but a quick look at anyone of my threads would give you an idea of the models in create..

    Great work!

    Whisky

    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!
    I am open to suggestions for a reasonable solution.  I have never needed this many separate projections and having a hard time visualizing the need. Are you guys wanting to split projections on every individual piece of geo? I usually only split on areas where I know I will have a problem-  I think when I did this bradley model years ago it was all one group without issue:
    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?


  • Stromberg90
    Offline / Send Message
    Stromberg90 polycounter lvl 11
    I would like name matching as well.

    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).
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    We are planning to expand the command line tool and provide some documentation. Also, the bake project (hpb) files are fairly straight forward and we can document them as well. I can imagine doing this kind of functionality through a script or seperate small gui that generates a hpb file with large numbers of groups.

    Isn't setting up perfect naming conventions for 1000 high and low objects a giant pain in the ass?
  • Stromberg90
    Offline / Send Message
    Stromberg90 polycounter lvl 11
    I would still combine objects to make it easier to handle, and my lowpoly objects are often larger pieces that has a number of hp pieces with matching names.

    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 :)
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Yeah, the HPB files are plain text. The gui just generates HPB files and then sends them to handplaneCmd.exe for baking.  Right now it only functions with one project file at a time but we can make it run multiple files or add other features as requested.
    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.


  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    shenric13 said:
    I see a lot of potential with this tool. I've been doing a few tests and I have just a few points of feedback.
    1. For me, when i choose the .png export format I get no files generated after the bake is complete.
    2. I was wondering if there are any plans to add an option to isolate the baking process to uv's that are in the 0-1 uv space?
    3. Could we get a cancel button?


    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.
  • shenric13
    Looks like the uv's were a overlapping mat ID, so i got that worked out. Thanks for the Info.
  • OccultMonk
    Offline / Send Message
    OccultMonk interpolator
    AlecMoody said:
    This looks really promising and can't wait to give it a try.

    I do however have a request and that is rather than just supporting a workflow whereby you split your HP into separate meshes based on material ID, you adopt a 3D max like option "match material ID's". 

    I work on models which splitting them and regrouping parts of the models according to their material ID to avoid bits of model being baked onto other parts would just not be feasible. I can see your current workflow would be OK for small (in physical size) models and ones where you only have say 30 or so separate elements to consider. However models I work on are made up of thousands of separate objects, several millions of triangles and are structured in layers logically. I group these thousands of objects into logical and localised meshes and the prospect of mashing up all of the layers and mesh groups to work for baking does not fill me with joy. This "match material ID" is literally the only reason I still solider on with 3D Max default scan line baking. Having the match material ID option means your bake will only project from your low poly model to correspondingly matched material ID geometry on your HP. No exploding required and it's just a case of setting up a 3 or so multi sub material, apply it to your high and low models and go around setting the material ID via modifiers or polygon selections and edits. Each mesh would then contain multiple material ID geometries and it matter about changing the logical layer and mesh structure just for baking. 

    Hopefully this makes sense, but if not happy to describe in a more detailed doc the predicament but a quick look at anyone of my threads would give you an idea of the models in create..

    Great work!

    Whisky

    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!
    I am open to suggestions for a reasonable solution.  I have never needed this many separate projections and having a hard time visualizing the need. Are you guys wanting to split projections on every individual piece of geo? I usually only split on areas where I know I will have a problem-  I think when I did this bradley model years ago it was all one group without issue:
    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?



    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.
  • OccultMonk
    Offline / Send Message
    OccultMonk interpolator
    I want to add that it would be great to have a good baking solution for models that consist of hundreds of separate objects. It takes a lot of time, especially the re-baking and error correction with so many parts. There is probably an even better/smarter solution for this that linking by name. Something automatic based on volume of the lowpoly object and the encapsulated highpoly models. That would be rather advanced, but it could theoretically work. If the system can somehow detect what lowpoly and highpoly objects should be linked. For now linking by name is a good enough solution.
  • cookedpeanut
    Offline / Send Message
    cookedpeanut polycounter lvl 12
    Also are there plans to sell this, if not why not put it up on Github so the few of us who know a thing or two could make some branches..?
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    No plans to sell this exactly. We have talked about doing an alternative paid version targeted at studios who want to implement their own workflow specific features - things that aren't common enough to justify adding to the tool for everyone. If we do sell something it will be under a separate branch and won't replace the free baker. We have also talked about opening up the code for community development. Xnormal has had an SDK for years and there have been limited community development efforts. Community code development is something I am open to but there are three of us in this company and it would need to discussed in detail. Also, once you go that route, you can't really change paths.

    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.
  • JoseConseco
    Offline / Send Message
    JoseConseco greentooth
    Are there plans to make command line api to access handlpane from other software? Something like allegorithimc  batchctools?
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Substance integration is something I am interested in but I don't have concrete plans to share. If we do it, it will likely be in the other direction. Bake your files in handplane and get something set up inside substance painter quickly. I like substance and want to support it as an easy workflow.

    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.
  • JoseConseco
    Offline / Send Message
    JoseConseco greentooth
    Well the batchtools from allegorithmic  was just example of command line program that can bake texture maps, from provided 3d models. I did not meant handplane to be used with substnance but maybe if someone want is that is ok. 
    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 :) Great work!
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    If you want to poke around in it now it is a very simple system. The gui creates a bake project file which is plain text. The handplaneCmd.exe takes the baker project files and does the actual baking.
  • JoseConseco
    Offline / Send Message
    JoseConseco greentooth
    Awesome! I will test it ASAP, maybe next week.
  • pior
    Offline / Send Message
    pior grand marshal polycounter
    Heya Alec, just ran two tests.

    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 !
  • Ezykeyal
    Offline / Send Message
    Ezykeyal polycounter lvl 5
    As much as I would love to start using this software by default because of its awesome features and fast rendering speed, I can't quite yet at the moment as I'm struggling with a few inconsistencies compared to my regular xnormal outputs. I'm not sure if it is because of the handplane baker's algorithm or if it is something I can easily remedy by changing a few hidden/unexplained settings. I'll try to explain the issue as detailed as I can with the virtually identical bake I did comparing the two and will also provide additional feedback after of some extra features that would make this software replace xnormal for me.

    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 :pensive:

    -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
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    When you don't use a cage, xnormal splits projections at hard edges. This is the wrong behavior in 99% of cases since it introduces gaps and double projections along edges. The side effect of splitting projections is reduced skewing on surfaces like this. Check this thread: http://polycount.com/discussion/147227/skew-you-buddy-making-sense-of-skewed-normal-map-details/p1


    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.



  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    pior said:
    Heya Alec, just ran two tests.

    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 !
    Some OBJ files are not loading the correct smoothing info in the baker right now. Can you send me that OBJ file? In one case, it was being triggered by an OBJ with a bunch of ngons.  Ngons or not, it should still load the correct smoothing- if the mesh is from mudbox I am guessing there aren't ngons. The another possibility, we default to hard edges on high poly models that have no normals or smoothing info. That is for zbrush viewport parity. Either way, we have at least one bug related to OBJ smoothing on high poly meshes and we should also add an option to force high poly models to be smoothed.

    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.


  • pior
    Offline / Send Message
    pior grand marshal polycounter
    Files sent !

    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 !

  • kolayamit
    Offline / Send Message
    kolayamit polycounter lvl 13
    Is it possible to add drag and drop OBJ's option in HandPlane, currently not able to drag and drop anything. So far loving this!!
    Also where can i find material preset(Load Library option)?
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Drag and drop is a good idea. I am imagining it as dragging files over the + button.
  • OccultMonk
    Offline / Send Message
    OccultMonk interpolator
    Could you build in rounded corner shading too?

    http://polycount.com/discussion/146280/smooth-edge-shading-legitimate-technique

    (Not as important as the linking by name though :-))
  • am0000
    Offline / Send Message
    am0000 polycounter lvl 6
    Hi Everyone,

    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" :smile: .
    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 :wink:

    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 :smiley:


    PS : sorry for my very bad english...:s
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Is your model triangulated before you bake? Those look like the triangle changing direction. We are working on how we handle quads for triangle direction in each engine now.
  • am0000
    Offline / Send Message
    am0000 polycounter lvl 6
    Thx for your quick response :)

    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
    Offline / Send Message
    AlecMoody ngon master
    can  you email me your high and low?
    alecmoody@gmail.com
  • am0000
    Offline / Send Message
    am0000 polycounter lvl 6
    Sure !
    Models sent ;)
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    So the unreal 4 map with inverted green channel is correct in unity 5.3. I think a last minute communication breakdown caused us to get these reversed. For now, unity 5.3 users should bake unreal 4 and invert the green. I still need to test unreal 4 to see if it should actually be a green channel inverted u5.3 output.
  • am0000
    Offline / Send Message
    am0000 polycounter lvl 6
    ho yeah, you' re right , inverse green channel from UE4 output and the result is great in unity !
    Thank you very much for your  amazing support.

    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 :blush:   
    *Clap clap*  to the devs !


  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    Here is an easy way to approach sampling AO in handplane baker. We will probably modify the GUI to work more like this so noise level/render time becomes independent of super sample and resolution settings. With the current method of directly specifying samples, it is very easy to oversample when increasing resolution and super sampling, leading to unnecessarily long render times.

    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:







  • RockSPb
    Offline / Send Message
    RockSPb polycounter lvl 5
    Hello! Great tool!
    What you think to add tesseletion pipline to your tool? 
    https://www.youtube.com/watch?v=CZCJF4cGPjc
    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.
  • AlecMoody
    Offline / Send Message
    AlecMoody ngon master
    We are going to implement something similar to that. It didn't make first release. Basically, users in input a tesslelated model with matching UVs. The projections will all be done with that model but tangent space calcs will be done using the original low.
13567
Sign In or Register to comment.