[Bf-cycles] Cycles per BSDF Bump/Normal mapping support
agustinbenavidez at gmail.com
Tue Jun 5 09:01:09 CEST 2012
Hi Brecht, I think i just finish this patch (only per BSDF bump mapping), I
follow your recommendations so i think is ready for review.
how it looks like in the ui:
I uploaded it in the patch tracker:
What is not included is normal mapping, I postponed it for the next weekend.
I also optimized several part of the added code, so i think the very little
performance lost in the GPU tests have been reduced considerably. for CPU
there is not any noticeable performance impact from my tests.
Thank you Brecht
2012/5/31 Agustin Benavidez <agustinbenavidez at gmail.com>
> 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
> 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
> 2012/5/29 Brecht Van Lommel <brechtvanlommel at pandora.be>
>> 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
>> > here there are screenshots of the working patch: (the image nodes also
>> > 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
>> > you the patch too ( Is not meant to be for review, i still need to
>> clean it
>> > up and make some stuff there better) :
>> > *) Whats left is to define if this is the right workflow. The initial
>> > is:
>> > N0: Normal input subgraph in the output node will define the first
>> > normal (ShaderData::N)
>> > N1: Displacement input in Output normal still makes bump mapping, it
>> > 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
>> > ShaderData::N as base normal already defined by N0 and N1, the bump
>> > output can be connected to normal input bsdf sockets, this normals will
>> > writen to ClosureData::N and used latter on in the bxdf sampling
>> > - For the user be able mix normals a new "mix normals" node could be
>> > 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
>> > socket?
>> > *) Internal implementation details:
>> > Bump node no longer writes directly the ShaderData::N, instead they
>> > 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,
>> > 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
>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles