利用者:Gregzaal/AO node proposal

AO Node Proposal

(See note at bottom)

Reasoning

My own reason for wanting this node is not for lighting purposes, but rather for use in creating dirt maps(though that's not to say it wouldn't be used by others for traditional ambient occlusion purposes).

The natural accumulation of dirt is very similar to how AO fakes the occlusion of light over a certain distance. Hence an AO map is often used as a dirt map. However, we currently need to bake AO to an image in order to use it in the material nodes, which means in large scenes these images take up a lot of memory. In terms of GPU rendering, memory is a lot more valuable than rendering speed - slowing down the render to calculate AO isn't a major problem, but running out of memory is fatal.

Existing Implementations

There are several current implementations of AO in cycles, however for the purposes of shading they are all at least partially flawed:

• Shader: There is of course the AO shader that is a standard Cycles closure. What the idea behind this node was, I don't know (custom render passes maybe). But this node is basically an Emission shader with an AO calculation for its strength. Since it's a shader, it cannot be used to mix or manipulate other textures and colors and is thus useless in terms of dirt maps.
• Render Pass: While this is great for compositing, again it's not useful for dirt maps. A workaround could be to render two scenes, one normal one and one with the dirty/grunge textures, and use the AO pass to do the mixing and manipulation. However this means rendering everything twice and of course would not show in a viewport render, which in my opinion is the greatest advantage Cycles has over any other render engine Blender can use. Without being able to see the dirt map in action in a viewport render in real time, shading would be extremely difficult.
• Baking: As mentioned previously, you could also bake AO to one or more images, but that brings issues with memory and the need for good UV layouts.
• OSL: I'm aware of several AO scripts, however OSL is CPU only and the scripts have some serious issues:

Problem with OSL AO used to manipulate a texture: The left image is made with OSL AO plugged into the contrast of a texture, the middle image is after a drastic levels adjustment using a color ramp, the right image is what you would expect from such a levels adjustment, but instead you get the middle one.

Features

The node would have just two inputs:

• Max Distance: This value would control the area in which the AO is calculated

Max Distance on 1 and 0.1 respectively (the Dirtmap node would be connected to an Emission shader to create this image)

• Flipped Normals: When off (0), the AO would appear normal, but when on (1) it would calculate the AO with inverted face normals. Of course an integer or float slider on the node is not ideal, an enum similar to how SSS falloff is set would be best.

Max Distance on 1 and 0.1 respectively, both with Flipped Normals on

Uses

The two major use cases of this node would be for dirt maps and scratch maps. However there are numerous other uses if you think of the inverted normals AO as a sort of thickness map, you have the ability to cheaply create shaders with fake translucency, or faked absorption, without needing to use actual translucency, SSS or glass with the Ray Length output. For distant or fast moving objects, this cheap method would be sufficient. Although physically incorrect, it may in some cases even be favourable to use this method instead of the Ray Length one, since this allows for easier and more visual manipulation of the falloff and the possibility of a custom ramp.

Dirt maps

Scratch maps

Fake translucence (only a diffuse shader used here)

Outside Blender

Adding dirt to a model is one of the most common things to do, even in areas such as architectural visualization where a client want the building to look perfect and clean, but adding a few touches of dirt in natural places helps sell the illusion of realism and bring out details in the model.

• VRay has a very popular Dirtmap shader which has a large number of parameters which, although I'm sure are useful, are not necessary to the basic function of the idea. Some of the parameters can easily be imitated with an extra node or two.
• Various plugins, scripts and shaders are available for 3ds Max and Maya (both free and commercial) [1][2][3]
• dDo, a procedural texture generator that works with photoshop, uses various baked maps to create the final textures. It doesn't use the 3d model at all, only maps such as AO, normal and cavity (small angle based scale AO) are analysed and used to figure out where certain texture details, such as dirt and scratches, should go.

Wishlist Features

These are features that would be nice to have eventually, but are not necessary to the basic function of the node:

• Occlude this object only: Only calculate the occlusion using the surface of the object itself, with no other objects contributing. This would be useful for animations, where a moving object would appear strange if the dirt map was sliding around and changing based on distance to other objects such as the ground or a character.
• Occlude this material only: Similar to the previous option, but useful for assets that have multiple objects (different pieces of a whole thing, like parts of a gun that should only occlude with each other and not the character's hand). Could also be used to avoid any artifacts caused by thin surfaces on the inverted normals mode.
• Normal Bias: Define a direction for the occlusion, for example only the underneath of a pipe joint gets rusted, rather than the whole area; or dirt accumulating only on the underside of aa overhanging balcony. (See the VRay doc). This is sometimes known as Gravity, since if the normal is set to the negative Z axis it would seem to stretch downwards as if gravity were pulling the dirt.

	Note on node UI mockup
	The two node images were created with an OSL script (with the script name and refresh button removed) - thus the Flipped Normals and Inclusion Mode are shown as integers, though the actual node should have enums instead