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

Agustin Benavidez agustinbenavidez at gmail.com
Thu May 31 07:31:36 CEST 2012


Hi Brecht,

*-I don't think we should have a material normal output...*

Normal output is there mostly for convenience, my original idea was to
implement a edge node effects, and for efficiency, output the normal was
better than generate
the bump mapping, (you know it gets executed 3 times with bump).
No problem if we don't implement that output, as long as we can at least
add a new node that can allow us to modify the shader normal
(ShaderData::N), or add/modulate to it, I think it will be very convenient,
than connecting each time bsdf when you want it applied globaly.
That node can also have some convenient options to transform to
tangent/object space to write procedurals textures with vectors and apply
to the mesh easily. and other normal related functions.

*-In svm_node_set_bump, the intensity can replace the fixed 0.1f value,
rather than multiplying h_c, h_x, h_y...*
Okay, i though about that too, but i wasn't sure, so then we should set the
default Bump Intensity to 0.1 to not break backwards compatibility with
previous scenes/expected behavior?

*-The image node normal should never get sRGB => linear conversion*
Thanks for clarify, my bad, any way that wasn't the proper implementation,
just something quick to play with, proper implementation is using blender
convention as i commented in the patch.

*-I think normal inputs for BSDF's should get added on top of the*
Got it.

*-Would be interesting to test if this affects performance, storing the
normal per shader closure.*
Some blenderartist folks made some test with/without the patch and with the
GPU. Four different materials A, B, C and D without using the new sockets
only with displacement and without it:

@Bao2: ( linux, cuda 4.2 )
A: 0.6 % performance lost   (diffuse, No bump)
B: 0.8 % performance lost   (diffuse, bump)
c: 0.7 % performance lost   (mixed glossy and diffuse, bump)
D: 1.0 % performance lost   (mixed glossy and diffuse, no bump)

@kgeogeo: (didn't ask)
A: 2.0 % performance lost
B: 1.6 % performance lost
c: 2.9 % performance lost
D: 2.7 % performance lost

@rebogey ( WinXp 32,  cuda 4.2  )
A: 2,1 % performance lost
B: 2,4 % performance lost
C: 2,6 % performance lost
D: 2,3 % performance lost

I still didn't test the CPU, i am writing you at 2am here, more death than
alive. Hopefully this weekend i can sit down and finish it with
your recommendations, trying to see if i can optimize it as much i can.

Thanks you Brecht

Agus.



2012/5/29 Brecht Van Lommel <brechtvanlommel at pandora.be>

> Hi,
>
> 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.
>
> Brecht.
>
> 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
> >
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20120531/4a93cfd6/attachment.htm 


More information about the Bf-cycles mailing list