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

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:
http://www.pasteall.org/pic/show.php?id=32728

I uploaded it in the patch tracker:
http://projects.blender.org/tracker/index.php?func=detail&aid=31716&group_id=9&atid=127

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
Agus,

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
> 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/20120605/61afb11f/attachment.htm 