[Bf-cycles] Cycles per BSDF Bump/Normal mapping support

Brecht Van Lommel brechtvanlommel at pandora.be
Tue May 29 18:33:01 CEST 2012


Nice, do not have time right now to review it closely, but some feedback:

* I don't think we should have a material normal output, the
displacement output is there because it can affect both the geometry
and the shading. But for a shading only thing like normal maps I think
we can just use BSDF sockets.
* I think normal inputs for BSDF's should get added on top of the
default normal from bump/displacement mapping.
* The image node normal should never get sRGB => linear conversion,
this is non-color data and should not be affected by color spaces. I
also don't think the image node is the place to control normal map
intensity, that should be done elsewhere, if it should be done at all
for normal maps.
* In svm_node_set_bump, the intensity can replace the fixed 0.1f
value, rather than multiplying h_c, h_x, h_y.
* Would be interesting to test if this affects performance, storing
the normal per shader closure.


On Tue, May 29, 2012 at 4:41 PM, Agustin Benavidez
<agustinbenavidez at gmail.com> wrote:
> Hi Brecht,
> I was implementing a contour/bevel shader node, and i though it could
> convenient to have a input normal socket to connect the contour node there.
> Messing with the code i end up implementing per bsdf bump/normal mapping.
> here there are screenshots of the working patch: (the image nodes also have
> initial basic normal mapping support too)
> http://www.pasteall.org/pic/show.php?id=32464
> http://www.pasteall.org/pic/show.php?id=32414
> http://www.pasteall.org/pic/show.php?id=32412
> Also if you want to take a quick look at the implementation details i attach
> you the patch too ( Is not meant to be for review, i still need to clean it
> up and make some stuff there better)  :
> http://dl.dropbox.com/u/65979653/BlenderComunityShare/Patchs/Own/NormalOutput_PerBSDFNormal_0.7.diff
> *) Whats left is to define if this is the right workflow. The initial idea
> is:
> N0: Normal input subgraph in the output node will define the first shader
> normal (ShaderData::N)
> N1: Displacement input in Output normal still makes bump mapping, it will
> make displacement and bump mapping as needed, the normal generated here is a
> modulation of the normal already defined in N0
> - Bump Nodes in the user interface will compute the bump normal using the
> ShaderData::N as base normal already defined by N0 and N1, the bump normal
> output can be connected to normal input bsdf sockets, this normals will be
> writen to ClosureData::N and used latter on in the bxdf sampling functions.
> - For the user be able mix normals a new "mix normals" node could be added,
> is not clear if it should be a new node or upgrade the vector math node
> adding that option and a mix input socket.
> - Image node:  still needs to let the user specify the normal
> space whether is world/object/tangent space. Also a control "intensity"
> could be added to attenuate the normal before output it in the normal out
> socket?
> *) Internal implementation details:
> Bump node no longer writes directly the ShaderData::N, instead they output
> the normal generated. To set the normal to ShaderData::N, there is a new
> small node "SetNormal" this will be only used once in the shader graph, and
> right now is used to set the normal defined by the subgraph in the input
> normal of the output node.
> Obviously you have something to say here. I'll wait for your advice on this
> whether improve it or reimplement it in an other way.
> Thank you for you attention.
> Agus,
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles

More information about the Bf-cycles mailing list