For the basic case you want to be able to switch between baked and procedural, or image textures and attributes, without having to rewire sockets from an image texture node in between. So it definitely should not be the default or a requirement.
If you are sampling the image multiple times you are likely also baking on another domain. For example for a triplanar shader you’d be baking the texture to a plane in a way that’s entirely unrelated to the mesh shape, and then sampling it. Perhaps there is some way to do that with an image output and additional settings, or you have to bake that image on a separate planar mesh.
This sounds more complicated? If I am a texture artist, I would prefer to think of a texture as a 2D image (static or not), and the mapping/baking should be separated from the texture itself?
Texture Channels node seems to obfuscate all these details from users: you are outputting a set of Material Inputs, it can be UV-mapped or Triplanar or Some-other-projection, it can be procedural or baked; to properly bake them you may also need Mesh input (to extract UV or just planar).
That’s a lot of things to keep track, I believe there is an easier mental model: a “Texture Material” node outputs a set of 2D Images, they can be procedural or static, but you map them as always using Image Texture node.
End users of this “Texture Material” node only need to understand Image Texture node can now accept an Image input, and it comes from the Texture Material node.
As for relinking sockets, if “Texture Channels” node are able to reconnect automatically to shader node when its output changes, why can’t it reconnect to Image Texture node?
Yes this is more nodes in Shader editor as a result, but it also mean not having to dig into Texture Node editor to see if the mapping is somehow wrong. I feel Texture Channels node are stealing functions from other nodes and will cause more complication in troubleshooting.
Thanks for the talk, look forward to your reply; but I will let others comment on this design.
(PS: I am trying very hard to not mention anything “substance” or “smart”.)
If you want to bake a 2D texture for use with arbitrary projections, then inputs like normals, AO, curvature become meaningless in texture nodes.
I can see how it could be useful to bake in a 2D domain without those inputs available, but that would require more than just changes to the sampling afterwards. You then also need to specify somehow that it should evaluate/bake the texture in a 2D domain unrelated to the 3D mesh shape.
I don’t think that’s fundamental to the design, we should not conflate the domain the texture is being evaluated in with the data type to store the baked result.
Looking at this specifically from a games workflow (but also a performance perspective).
Baking within Blender:
As expressed in the design idea, this could be huge. A way I could see it working is roughly like this:
I’ve made a procedural skin texture for a character I’m working on. But I want to see it in an animation, so I want to speed up the performance.
There’s a “Bake current material node” option that effectively bakes all the texture inputs I’ve used (roughness, normal, etc) into image files. This material setup is created after my current nodes/procedural material, but linked to it. My original node graph is basically grouped and disabled.
-Now I get better performance, but if I want to now paint some details on my character i can just start building out from there. I can then bake again, etc etc.
but what would be very cool is if I wanted to go back and adjust that original skin material. Make it a different color or change the noise value, then I could, because it’s still disabled in its group. Then I could rebuild my finished material start to finish either manually or automatically.
These textures could then be used to easily export for external applications in the same way that some NLE video editors can used the pre-rendered timeline to speed up final rendering.
Baking for external programs (Unity, Unreal, etc):
We need presets. Something that can be setup for engines like Unity or Unreal. Users can setup the channels or outputs they needs, and Blender will know how to package the roughness or transparency channels into the final output files so that they work well in these major engines. And it should be one export/bake. The user selects their preset, or checks the output channels they need, if they need openGL or Direct X oriented textures, and an output directory. Then you click export/bake, whichever makes sense. And that’s that. All procedural, image based etc get mixed down and output to those 3-6 etc images, ready to drop into a Unity material and go.
This would make Blender an even more incredible tool for indie games, when things can change quick.
希望CA属性的显示,可分为CRGBA,五种独立通道显示模式。这样会极大的方便绘制其它浮点属性通道.
I hope that the display of CA attributes can be divided into CRGBA, five independent channel display modes. This will greatly facilitate drawing other floating-point attribute channels.
It’s exactly the way I expect node based baking to work with maybe one drawback, that it is a bit scattered in the way you get the bake passes information, example:
PBR: Get’s it’s bake results from PBR BSDF inputs
Blender: Bake passes found in the Blender Bake Tab
Bake Wrangler: Additional passes provided by Bake Wrangler that are not PBR specific
Here is a setup I’m using to bake multiple decals to one plane, note that it uses a collection as input and a specific mesh as a target! Also it can use a higher “Pass Resolution” than the “Output Resolution” for very crisp anti aliased bakes. Currently whenever I add a new decal I first bake it in a lower resolution and whenever I’m satisfied with the result I set the pass resolution at 8k and let it bake in the background while I continue working.
Currently I get my Vertex color info by routing them trough metallic, roughness BSDF outputs etc. But it would be cool to directly output a Vertex Color attribute for baking. Also I abuse the Subsurface color channel to output AO (R) that does not get affected by Alpha, Height info (G) and a custom color for normal masking (B)
100% and bake wrangler is great, totally agree with most of this and would use the workflow you outlined!
On the off chance we need some even more simple to make it to an earlier deadline, I would like to provide a slightly alternate vision where the baking nodes are found along side the shader nodes:
RGB input added to image nodes (Toggle-on/off (off by default)), with selected NodeTree datablocks for the baking node (instead of selected image).
I have a RCS post about it here:
I’m sure we could extend from there to have additional layer functionality work within the existing image node slot?
Thoughts?
This other thought is just a shout out to, nobody in particular… also not to the post I’m replying to here. (please hold your pitch forks)
Sorry to go slightly off topic but; Can we please show some love for the blender team? They aren’t a faceless corporation, you’re dealing with human beings. Let’s not let these discussion become a cross examination court date, let’s keep things friendly and professional, as that would make anyone happier to engage.
Don’t annoy developers with this question. If something does not under development right now it always means that there is not enough people to work on it. What we can do is just support them with money.
