利用者:Bartekmoniewski/Cycles Baking Proposals
目次
Cycles Baking Proposals
In this page I will write some suggestions on Cycles texture baking. I'll try to present this informations for developers but also for regular Blender users. Be sure to check out attached .blend files and mockups. They contain essence of the idea. If you want to add your suggestions here or have better solutions you can discuss it on Cycles baking topic linked below. This page will be edited regarding the feedback and development state of Cycles baking.
http://blenderartists.org/forum/showthread.php?326534-Cycles-baking-is-here/
Lets get started.
STANDARD MAPS
Generation of standard maps for modern game engines
Many modern engines have a bit different approach of creating and rendering materials than what people are accustomed to. There is strong trend of Physically Based Rendering (PBR) which is next step to realistic graphics. Shaders based on laws of physics require special maps. I'm happy to tell you we can almost bake those maps with Cycles. Some of them can be made from current bake passes in Compositor, other can be done by hacking nodes a bit and baking them as diffuse_color pass. This proposal is about having them as typical bake passes for the ease of use.
You can learn about PBR here: http://www.marmoset.co/toolbag/learn/pbr-theory, http://www.youtube.com/watch?v=LNwMJeWFr0U, http://seblagarde.wordpress.com/
Concept
There are two popular methods of creating and rendering PBR materials.
First one is "Specular model". It uses map named Albedo as color of diffuse surfaces and Color Specular map to deal with reflectivity power and color. Very similar to Cycles shaders and materials in older engines. To create metallic effects like gold in this method, Albedo is set to pure black and Color Specular is set to bright yellow for gold-like reflectivity tint.
Second method is "Metallness model" and works a bit differently. As you may already know, in real world surfaces can be Metallic or Dielectric. Metals tend to colorize reflection based on material Albedo. So in this case Albedo represents color of all surfaces and Metallness map is used to define where surface behaves like metal and where it doesn't. Gold can be made from yellow Albedo color and Metallness set to 100%. Brightness of Albedo controls power of specularity of surface.
Both methods use the same Glossy/Roughness map to define how sharp reflections are.
Main idea is to mix all shaders together and bake into maps all those primary properties of materials surfaces. This maps should be treated like other bake passes so artist may enable them along with Normal, AO, Diffuse_indirect and so on. User would enable "Standard Maps" check-box in Bake Properties to generate those maps. Right under those there should be a switch for defining the baking mode - Metallness or Specular. Below I will explain how Cycles can generate Standard maps for both models.
- Albedo map
- In Specular model this map can be created by combining current color passes: diffuse_color, transmission_color, subsurface_color, emit_color. Note that glossy_color pass is not taken into account here.
- In Metalness model glossy_color pass should also be mixed with other color passes.
- Glossy/Roughness map
- Material surface glossiness or roughness in gray-scale map. Same for both models. Note that simple mix of diffuse and glossy roughnesses probably won't work. The roughness map created that way will result in a in-game material looking different than the one in Cycles. In bake properties there should be an option named "Restrict Roughness" which ignores roughnesses other than glossy/glass shader. This will be needed to create proper maps looking similar in both Cycles and game engine.
- Color Specular map
- In Specular model this is basically current glossy_color bake pass.
- Specular doesn't exist in Metallness model because color and power of specularity is taken from Albedo.
- Metalness map
- This map is not used in Specular model.
- Unfortunately we don't have any information about actual metalness of surface in Cycles. To create a material with input like that a decent shader network is needed. One way to generate metallness map is binary mask that indicates where Gloss Shader color has any saturation and where it doesn't. This will be as accurate as it can with current tools. Second and probably better solution is presented below in the next section of this proposals.
Mockups
Look at this node graph to see how data may flow through shader tree to generate few of those standard maps. In this example "Specular model" was chosen as a bake mode. Albedo is made without glossy shaders.
Option "Restrict Roughness" is enabled so Diffuse Shader roughness value is not mixed in final map.
 Node graph with descriptions. Click Here for high resolution |
CUSTOM MAPS
Generation of maps from custom outputs in shader tree
New engines allow to use layered materials and material masks to mix different shaders in-game. This can work just like Mix nodes in Cycles. With custom maps support we can split Cycles materials into smaller portions, and generate separate maps that will be mixed in real-time engine.
Many types of information can be baked with custom maps. Some of them can be Standard type maps described in first section of this proposal and we can call them "Custom Standard Maps". They need to be connected to shaders output socket and maps baked this way will provide us with standard maps of this specific shader (ans all the nodes plugged to it).
Other color and non-color data like values or color masks or vectors can be baked as "Custom Data Maps". This nodes can be connected to any color, value or vector outputs sockets. In game engine maps generated this way can be used to mix real-time shaders.
Baking portions of current passes (like diffuse_indirect) can be considered. Those may be called "Custom Pass Maps". This will allow artists to create very complex baking procedures in conjunction with Compositor Nodes.
Workflow
Two things need to be done in order to create custom maps:
- User will need to check "Custom maps" option in baking properties.
- Custom Maps Outputs nodes should be present in shader tree. Users will be able to add those from node Add menu under "Baking Outputs" category.
Items in Node Editor's Add menu:
- Baking Outputs
- Custom Standard Maps node
- Custom Data Maps node
- Custom Pass Maps node
In each of this nodes user can check which maps will be baked. In Custom Standard Maps node both types of bake methods (Metallness and Specular) can have there own check-boxes. This will be easier and will give more control than switching modes in bake properties.
For clear organization of baked maps nodes should have text inputs where user can specify a Suffix for a set of maps. For example, if we type in "Lava" then Albedo map generated from this node will be named "Custom_Albedo_M_Lava", where "M" stands for Metallness bake model.
If user doesn't specify Suffix, maps will be named with numbers in typical blender manner. Custom roughness baked from third output node will display as "Custom_Roughness.002". This is only in case of naming errors. From workflow standpoint it is best to define all suffixes to distinguish the maps from each other.
Check-boxes fo bake passes in Custom Standard Map node:
- Abledo S (Specular model)
- Abledo M (Metallness model)
- Roughness
- Color Specular
- Metallness
Mockups
See this node graph to understand how custom maps can be created and where users can plug output nodes.
 Node graph with descriptions. Click Here for high resolution |
BAKE MODES
There should be two bake modes, Standard and Camera Projection. Standard mode is how blender works right now. In this mode informations that depend on view are not baked or not baked the same way as in normal render. That behavior is sufficient for most baking purposes, like baking ambient occlusion or lighting. View-dependent information like specular reflections are calculated in-game anyhow.
Second bake mode should be Camera Projection. To bake textures that way scene has to contain one Active Camera that will be used as an observing point. In this mode all informations that show in normal renders can be taken into account.
You may ask what the benefit of baking textures that way is and answer would be: Faking!
Most of mobile games today use only diffuse color maps. Even if some devices can run advanced graphics, games are still created for mid-range phones which don't have much performance yet.
Baking comes very handy in this kind of graphics. Camera Projection bake can be used in many ways like faking highlights, reflections, subsurface scattering. Even overlaying textures from camera or baking mist to background environments can be achieved with this bake mode.
A switch that changes baking modes should be one of the first buttons in Baking Properties.
The big question is how to deal with back side of objects baked that way.
VIEW-DEPENDENT NODES
In relation with Camera Projection and Standard bake modes some kind of dealing with view-dependent information has to be done.
Camera bake is simple because all nodes would be included in rendering calculation. I will focus on Standard mode.
In fact even simple Diffuse Shader in Cycles is view-dependent - we can see it when roughness is set to 1. However baking shaders view-dependent data can give good results in Standard bake mode. On the other hand we have view-dependent mixing nodes and their outcome can't be baked in Standard mode or can cause random effects.
In Standard bake mode view-dependent nodes need to be ignored to result proper baking. Probably this will mostly be used to deal with Fresnel and Layer Weight nodes.
To be ignored, nodes have to pass information about their view-dependency to other linked nodes first. Note that nodes may or may not be view-dependent based on which output socket is linked.
When information of view-dependent node goes to a Mixing node input, it excludes that input from baking. All nodes which mix or add outputs of the same type can perform this kind of action. Whenever user runs Bake, Info Bar should display a notification with a number of ignored nodes.
List of current view-dependent nodes and sockets witch make nodes view-dependent:
- Fresnel
- Layer Weight
- Camera data
- Texture Coordinate
- Camera
- Window
- Reflection
- Geometry
- Incoming
- Parametric
- Backfacing
- Wireframe
- Pixel Size Factor
- Light Path
- Is Camera Ray
- Ray Lenght
List of all current nodes that mix outputs of same type:
- Mix Shader
- Add Shader
- Mix Color
- Math
- Vector Math
- Checker Texture
- Brick Texture
(A may missed some nodes, contact me if you know.)
Mockup
Look at this node graph to see where view-dependent nodes are detected and how mixing nodes deal with them.
 Node graph with descriptions. Click Here for high resolution |
