Author Topic: Baker Profile / Node-based baking, my Frustration with substance Baker  (Read 6867 times)

Each project has a different workflow, each model need different settings to bake its textures.


The quote below is my frustration & why I suggest this at all:

Quote
I've encountered serious back and forth bake operations with my multi-parted weapon model.  My objective is to get assets consist of multiple parts and they would share texture maps with other in-game assets, to achieve "Borderlands" kind of weapon customization for my game project.  I know Substance supports name matching, but It only solves a part of the problem, and in some case it consumes more time.

#1: The mesh names are quite uneasy to be retained and organized over importing and exporting to multiple software.  And high poly geometry doesn't always come in the same hierarchy as the lowpoly model.  Using name matching to get correct bake result isn't much practical.

Blender to Zbrush e.g.: The top subtool's name occasionally gets changed to the save file's name, which will cause Substance Designer's name matching to be problematic.  I'm not professional zbrush user, or artist; my entire workflow of lowpoly, highpoly and texture bakes are always on the line, and it is a lot of Bake&Inspect loops.  It does consume me a lot of time.


#2: Sometimes the baker's frontal and rear ray tracing distance can be tricky to work with.  If it is too low, detail would be lost for some area with greater normal distance towards the highpoly .  If the distance is too high, then there will be artifact faces from the other meshes baked onto some tight areas.

My solution is to bake 3 normal maps each with different ray-tracing distance.  So I get a low, middle and high distance.  Then I use SVG to mask and blend them together for final result.  But then I have to do this again for Ambient Occlusion, because the ray tracing distance takes effect on all "Bake from highpoly" bakers.  It's a lot hustle to keep adding bakers and tweak its settings.

#3: The current baker sometimes can be very frustrating.  It doesn't have Clear All or Enable All option.  So every time I want to bake a different texture, I have to manually check/uncheck the check box.  What if I don't?  For example, I checked all 10 texture bakers to be enabled for baking.  I click OK, then realized, NOOOOO I don't need all 10 of them.  I can't even cancel the baking process.  It is going to continue until it is done.

#4: The current baker loads the highpoly mesh EVERYTIME when it starts a texture bake.  Even when it is set to bake from one single highpoly mesh,  it will load exactly how many times for how many bakers you enabled.  No matter how I don't mind because the OBJ loading is insanely fast.  Repeating it 3 times for 3 normal maps from same highpoly model for different distance setting is exactly 3 times more time consumed.  If it only had to be load once in the begining, the process would be two third faster.

#5:  If my model has 10 parts, I will have to repeat all these process 10 times, because each part of the mesh are using different texture sets.  Guess what else I have to change?  For each setting I overrode, I have to change the highpoly mesh's package path to the co-responding one.  Because there is only ONE common settings for all, ALL bakers that is the same type. It is very, very brain consuming and tiring to work with.

https://www.artstation.com/artwork/wip-derringer-zbrush-project <-- the project I'm talking about.  It's really more complex than you think.  Complex geometry + modular asset == struggle.  This kind of complication is basically unavoidable for a complex design/project.  And that is why a profiled or node-based baker graph would be extremely useful, smart and efficient to work with.

Baker profile:
if I have one setting I like, let me profile it, and when I need it for another model, I can simply 2-click to get the exact setting.


Node-based baker:
if I can make a graph that is going to control how my mesh is baked.  I can use it for all my meshes with personalized control over all the baking parameters.   So I plug in the lowpoly, I plug in the highpoly.  I choose to bake these textures with these settings.  And I can add another output or parameter on the fly to further improve the automation of the work.  When I go to my next mesh, use same setting, but all maps are downsized to 512x512.  Off we go.


I will shut up and shall you take my money with my definite permission if you implement these features.


PS: You gotta give some more love to Designer.  Painter is powerful and whatnot, but in its core, it still relies on Designer.

PS2: If it's possible, maybe add a feature to select special faces on the mesh to be treated differently, for example, on the lowpoly mesh, there is a Cut-In slot containing several faces.  If I use general settings for normal baking, it will create trace-through artifact from other side of the mesh.  So, If I select these specific faces, and set a different ray-tracing distance only for them, to avoid the artifact without the need of baking 2 or 3 maps and blend them with SVG map.

PS3: If Allegorithmic would add the feature described in PS2 on top of the node-based baker, I will then pledge my life-time allegiance along with my loyalty (and money) to the great Allegorithmic and Substance franchise.



PS4: If you like it, vote here:
http://allegorithmic.uservoice.com/forums/257908-substance-designer/suggestions/7480999-node-based-baker-profiled-baker
Last Edit: April 07, 2015, 10:20:14 am

Thanks for the feedback, that's really interesting!

#1 I do agree the match by name is not always easy to setup, especially with Zbrush. Unfortunately, for now we don't have technical solution for that..

#2 Non uniform frontal/rear distance is the main problem of baking, that's why some people use cages. The name matching is one solution for non cage baking, but as you mentioned, can't be applied all the time.

#3 Definitely a UI problem. Cancelling the baking process is not as easy as it sounds but I agree it's really something that is missing.

#4 We are aware of that and it can be fixed. No ETA.

#5 also something we are aware of. We plan to add an option to bake per "materials" instead of "per object". Then add a new %material macro and an option to bake all materials separately.
Product Manager - Allegorithmic


http://i.imgur.com/GnsslSs.png


Made a visual demonstration of how it would work.


The CAGIEFY node had me thinking.  The concept of Specify the ray tracing distance values for Masked mesh polygon works just like cage, but also not like using a cage.  First, on the user interaction side, there is no model editing involved other than select some polygon faces with Mesh Masking node.  Second,  It's controlled with numeric values, easy to tweak, but may lack a bit of ultimate adjustability compare to really editing a cage.  Third, under the hood, it is very similar to modifying a cage.  So maybe it is possible to change how the numeric values affect the cage.  So maybe the value controls the distance of ray tracing based on the face normal.  We could do some vector math and let the direction of the ray become more parallel or more focused on the center of all selected faces, or make the ray trace go aligned with world axis.


Since Substance Designer is node-based.  Why not make everything node based with it.  I don't think it's necessary to implement this node-based baker system inside the already awesome Graph system.  Simply Stand the baker graph alone like the pixel processor or FX map node.  Baker graph would only have baker related nodes.  So there will be less trouble getting through input and outputs.

Use models as a input node can save a great deal of hustle compare to changing the baker's settings in current SD5.

Not to mention the powerfulness of template graphs!!!!!!

I'm still working on getting more demonstration of how a perfect node-based baking system would look like, and what kind of node would be included.
Last Edit: April 08, 2015, 09:05:53 am

#3 Definitely a UI problem. Cancelling the baking process is not as easy as it sounds but I agree it's really something that is missing.

I mean... during the bake of one texture, it's not easy to cancel it.. I understand..  But it continues until All finished.  It can't be cancelled even during the finish of one until the start of next texture bake?


#5 also something we are aware of. We plan to add an option to bake per "materials" instead of "per object". Then add a new %material macro and an option to bake all materials separately.


I don't think it would be quite practical to bake per "Material", unless the "Material" is something else than what I think.  Most artist do use Color ID maps that are painted through vcol?  As far as I know, Setting up material color or vcol in Blender are pretty painful.  Zbrush however, the vCol can be really fast, but I have no clue about material in zBrush.

Quote
I don't think it would be quite practical to bake per "Material", unless the "Material" is something else than what I think.  Most artist do use Color ID maps that are painted through vcol?  As far as I know, Setting up material color or vcol in Blender are pretty painful.  Zbrush however, the vCol can be really fast, but I have no clue about material in zBrush.

Per material, I meant on the low poly model: If it contains multiple parts, each being fully unwrapped on a dedicated UV set, their is a high probability you apply a different material to it in the dcc application (just because they'll use different textures sets).

Lets say you have a character, with head, torso and arms. each part has its own UVs and its own material (each part could also be composed of multiple sub objects if you don't want to combine all objects into a single).
Importing this low poly model in SD, you'll have the choice to view the scene as today (classic hierarchy), or per material/texture set. Then, an option will allow you to bake each material (equivalent to each part, head, torso, arms), separately in a single click.

Concerning ID maps, you can indeed use the vertex color but as you said it can be painfull to set this up anywhere else than in Zbrush. You can use the material color (from the high poly) instead, but only with fbx: just apply a standart material to a part of the high poly model, set the diffuse color to whatever you want. In SD, select "color from mesh" and set the source to "Material Color". SD will read the color information and bake that onto the low poly.
Product Manager - Allegorithmic

So the per "material" bake is more complex then I thought.  And yea, it would be quite useful.  So it can bake each different UV set into different maps with different names.  The "Material" is actually refered to UV-sets or sub objects.    By all means, can't wait to try it out~!


Thanks for replying!

So I'm interested in the improvement of the baking app, and gave some feedback/made some suggestions over at polycount which I figured could be useful to post here.

Quote
So I finished my throne room entry last night/this morning, and I had been doing a lot of baking of maps in substance designer and have some feature requests about that stuff.

Adding the match by mesh name option was really cool but I think some more options for this kind of workflow could be added.

Working in zbrush with high res subtools it can be a pain to keep all the mesh names in line especially since when you save a tool, it renames the selected subtool whatever you save. So for example the helmet in your soldier01 file gets named soldier01 every time you save your zbrush tool, and you have to rename it when you go to export your high poly for baking.

In this situation I would think also matching by filename would come in handy, so even ignoring zbrush, if you named something wrong you could just rename the file instead of jumping into whatever dcc app and exporting all over. This would also have the benefit of being able to bake a certain group of high poly meshes to a low poly, like a walkie talkie that consists of many high poly pieces, but 1 low poly mesh while still allowing to bake the walkie talkie pouch and other things at the same time without intersections.

Also possibly having a delimiter system for sub meshes would also be useful in cases like the above so like walkie-body_high, walkie-antenna_high and walkie-knob_high, would all bake to walkie_low.

I also wondered if there could be a way to bake multiple low poly files at the same time, my work around right now is to just save the meshes into a single low poly file. Aside from having multiple low poly files, another "matching" interface that might work, is having some sort of list associated with each low poly mesh, or with a certain low poly selected, you could make corresponding high poly meshes visible.

On another side to baking, I had been doing a lot of baking transferred textures while making foliage. Basically I would create a base pattern in designer, which I would then map to my high poly leaf which I could move UVs around for variations etc... Then I would load up the high poly and bake both the base color and roughness (which is all I was outputting at the time). Which I would then load into another graph where I had baked normal, height, thickness etc... I figured if I needed to change the leaf base, I could do that and push it through fairly easily.

However, I found myself wanting to be able to bake out a graph itself instead of having to load each map as a separate transferred texture bake. Also there is a feature in xNormal called "Base Texture is a Tangent Space Normal Map" which won't just bake a 1:1 mapping of where each pixel is, but sort of act as a poor man's high poly (not sure how to explain it).

Lastly with the texture transfer stuff, I thought being able to load multiple maps would be useful for creating tree branches. You have the leaf material, and then the bark material, probably having some sort of options for outputting material masks too.

Whew that was a lot, a lot of this stuff only came up as I started to use Substance designer a lot more, and I'm loving it. Obviously there might very well be many technical reasons why these suggestions aren't implemented but I hope the feedback is useful.


So I'm interested in the improvement of the baking app, and gave some feedback/made some suggestions over at polycount which I figured could be useful to post here.

According to Nicolas "per material bake" might be exactly what you want for "Multi-lowpoly model bake"  like, multiple model with different UV sets come out with multiple same-purpose maps.

Matching file name IS a really good idea, except if you change the file name, the dependency link might got black-holed.

And Zbrush, yes... it's always the top subtool.  I started to save a zSphere on top of all my actual subtools, and when I work with the model, it's a bit annoying but at least it's less struggle than renaming the top subtool.  Plus you have to hold down both Alt and Shift to be able to type Underscore......  LOL




Btw, some update on the Demo for the Node-based baker idea.  It's in the attachment, the actual .sbs file.

And I admit that I am just purely stupid.  We already have one perfect tool to make example, and I went with photoshop and wasted bunch of time making shapes.  LOL

Here we go:

http://i.imgur.com/sKehK1m.png

https://forum.allegorithmic.com/index.php?action=dlattach;topic=4713.0;attach=8027
Last Edit: April 09, 2015, 08:58:22 am

Plus you have to hold down both Alt and Shift to be able to type Underscore......  LOL

I didn't know that, but even though a normal underscore visually looks like a "-" in zbrush, it actually shows up properly when exported.

WUUUUT, I never knew it actually save "-" as a proper underscore.  What a myth.

WUUUUT, I never knew it actually save "-" as a proper underscore.  What a myth.

Well what I mean is if you simply enter an underscore normally (shift and the -/_ key) in zbrush it will appear as a "-", but if you export it, and open it up in substance designer, the mesh name will have a "_" instead of a "-".

Hey Guys,

Thanks for the feedback!

Concerning the Zbrush workflow, the easiest way to workaround the name problem is to export each subtool separately:



Quote
Also possibly having a delimiter system for sub meshes would also be useful in cases like the above so like walkie-body_high, walkie-antenna_high and walkie-knob_high, would all bake to walkie_low.

That's a good idea!
Actually their are two solutions.
We can add a "delimiter" in the preference, in this case "-", everything that is after the "-" is ignored until it finds the suffix.
- myobject_low
- myobject-part1_high
- myobject-part2_high

or

We could ignore everything that is after the suffix:
- myobject_low
- myobject_high-part1_write_everything_you_want
- myobject_high-part2_blabla

The second option does not need a delimiter to be set in the preferences.

What do you guys think about it ?


Product Manager - Allegorithmic

Hey Guys,

Thanks for the feedback!

Concerning the Zbrush workflow, the easiest way to workaround the name problem is to export each subtool separately:



Quote
Also possibly having a delimiter system for sub meshes would also be useful in cases like the above so like walkie-body_high, walkie-antenna_high and walkie-knob_high, would all bake to walkie_low.

That's a good idea!
Actually their are two solutions.
We can add a "delimiter" in the preference, in this case "-", everything that is after the "-" is ignored until it finds the suffix.
- myobject_low
- myobject-part1_high
- myobject-part2_high

or

We could ignore everything that is after the suffix:
- myobject_low
- myobject_high-part1_write_everything_you_want
- myobject_high-part2_blabla

The second option does not need a delimiter to be set in the preferences.

What do you guys think about it ?

With the zBrush issue, it doesn't have anything to do with you guys, its just whatever subtool is selected when you save your tool... is named whatever you saved your tool as. So as brentliu131 suggested, a workaround is having a zsphere in the subtool stack that gets renamed instead of the subtools where you want to preserve the name so you don't have to rename a subtool everytime you export your meshes.

For the naming convention of sub meshes once it works where you can match multiple high poly meshes to a single low poly, that is fine for me.

So if I understand correctly in the second case anything to the left of the "_high" would be matched to the corresponding "_low" so
myobject_low would match to myobject_high-part1 and myobject_high-part2_blah and so on?

Hey Guys,

Thanks for the feedback!

Concerning the Zbrush workflow, the easiest way to workaround the name problem is to export each subtool separately:



Quote
Also possibly having a delimiter system for sub meshes would also be useful in cases like the above so like walkie-body_high, walkie-antenna_high and walkie-knob_high, would all bake to walkie_low.

That's a good idea!
Actually their are two solutions.
We can add a "delimiter" in the preference, in this case "-", everything that is after the "-" is ignored until it finds the suffix.
- myobject_low
- myobject-part1_high
- myobject-part2_high

or

We could ignore everything that is after the suffix:
- myobject_low
- myobject_high-part1_write_everything_you_want
- myobject_high-part2_blabla

The second option does not need a delimiter to be set in the preferences.

What do you guys think about it ?


I think this workaround isn't very helping.  To begin the baking process with matching name is a very easy concept, but the work in extra for figuring out how it would actually give me a perfect result I want is very complicated.

With my own experience, Explode the low and highpoly into spaces and export as a separate mesh for baking Normal map is even faster than trying to figure out the namings.

Why struggle with naming when we already have an easy way (even though it's the old way) of doing it.

The thing about naming I don't like,

#1: "Name" changes when you feel you need to.  It is somewhat OCD-ish.  For the name matching system, we would have to rename all other co-responding meshes if we decided to change any.

#2: Typo is always a problem.  No matter how experienced people are, they will typo moment to moment.  And text isn't a particularly interesting thing to look at.

#3: Texts are hard to define and control.  Text matching is only 1 to 1, or 1 to many as the "de-limiter" gets in.  There are moments where maybe I need to cross-bake multiple parts, then Name Matching won't be too useful, and it may actually get in the way.


Wouldn't it be easier to able to manually connect multiple highpoly to the lowpoly instead of matching the names

Personally I think exploding is easy enough for the low poly, but it can become a pain for the high poly meshes. Also you normally require a non exploded set of meshes to get proper ambient occlusion, which adds more complications into the mix. As you add more meshes you need to explode them also, I would rather just learn a naming convention and skip all of that shit.

#1. I don't really see this as a big issue, in the current scheme, even if you have to change filenames, it wouldn't affect any matching since the current system uses the mesh names.

#2. I suppose there will always be that issue, but not really a reason to not implement a feature.

#3. You described some complicated problems initially with having to do multiple bakes and composite in photoshop afterwards, but not wanting to use a cage. Admittedly I haven't done any super complicated bakes in SD yet, but your description of compositing different bakes with different cage depths and masking out with svg etc... sounds wayyy more complicated than just using a cage.

Manually assigning high poly meshes to low poly meshes regardless of name matching would be an interesting option. It would have some complicated UI consequences, maybe when you select a certain low poly, have checkmarks visible next to the high poly files it's associated with?

I'm sure Allegorithmic would love to give us a graph based baking system, or manual high to low matching but we might have to wait awhile for that, whereas the name based matching could be something they are actually able to implement quicker and easier.