[Bf-cycles] Optimization project

Mon Feb 10 18:59:37 CET 2014

Arnold has no progressive mode, per se, so we'd have to be comparing
to the Branched mode of Cycles.

Basically what I mean is that I can render an object with a single SSS
shader to a noise free state, and then do the same with my Sum of
Gaussians shader which has six layers of SSS, and the second shader
takes only ~5% longer to reach the same number of samples/noise level
in Arnold. I'll post some example images when I'm on my desktop.

On Mon, Feb 10, 2014 at 8:13 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> It depends on what you mean exactly by this penalty. For Cycles the
> path tracer and branched path tracer work different. In the former
> cases it will pick one of the layers at random for each AA sample, in
> the latter case it will do all layers for each AA sample. So for the
> branched path tracer there is a higher cost but also less noise per AA
> sample.
>
> So it's not clear to me if you are talking about total render time to
> achieve some level of noise, or time per AA sample. If Arnold only
> gives a slight speed hit but more noise then I guess it does what we
> do in the non-branched path tracer. There's some tradeoffs between the
> two ways.
>
> It may be something else in the importance sampling that needs work if
> it's more about noise / render time.
>
> On Sun, Feb 9, 2014 at 10:43 PM, Matthew Heimlich
> <matt.heimlich at gmail.com> wrote:
>> Not sure at all how it's done, but it might be a good jumping off
>> place to think from: In Cycles, you get a huge penalty every time you
>> add another layer to SSS, while in Arnold working with six layers of
>> SSS gives only a slight speed hit over using just one. Any thoughts?
>>
>> On Sun, Feb 9, 2014 at 4:02 PM, Daniel Salazar - patazstudio.com
>> <zanqdo at gmail.com> wrote:
>>> Ok, I will very soon provide you with WIP scenes, at least to understand why
>>> it is so scary slow :)
>>>
>>> Daniel Salazar
>>> patazstudio.com
>>>
>>>
>>> On Sun, Feb 9, 2014 at 2:59 PM, Brecht Van Lommel
>>> <brechtvanlommel at pandora.be> wrote:
>>>>
>>>> I don't have any great ideas to improve raytraced SSS performance,
>>>> there's two tweaks we can do on the list now and general BVH
>>>> performance improvements should help also. There's probably more we
>>>> can do but I'm not sure what at the moment, analysis of some real
>>>> world scenes should reveal some ways that it can be improved.
>>>>
>>>> On Sun, Feb 9, 2014 at 8:33 PM, Daniel Salazar - patazstudio.com
>>>> <zanqdo at gmail.com> wrote:
>>>> > We are using SSS for our very simple part of the teaser. A single
>>>> > character
>>>> > on outdoors lighting. Its surprising how much of a speed penalty there
>>>> > is
>>>> > with SSS :p Of course for a few seconds in the teaser it's alright  but
>>>> > I'm
>>>> > foreseeing our project will be an SSS and hair frenzy!! :D
>>>> >
>>>> > On Feb 9, 2014 12:00 PM, "Marco G" <digitalbath86 at hotmail.com> wrote:
>>>> >>
>>>> >> Hi,
>>>> >> about hair, haven't seen any specific paper link to help shading and
>>>> >> rendering speedup.
>>>> >>
>>>> >> Is there anything already implemented so far, or other ideas?
>>>> >> Reading at the pdf, the recent Importance sampling from Marschner et
>>>> >> al,
>>>> >> could be used in conjunction with Dual scattering,
>>>> >> i remember reading in this mailing list, people willing to integrate
>>>> >> dual
>>>> >> scattering.
>>>> >>
>>>> >> Dual scattering -
>>>> >> http://www.cemyuksel.com/research/dualscattering/dualscattering.pdf
>>>> >>
>>>> >> Importance sampling -
>>>> >> http://cg.ibds.kit.edu/publications/pubhanika/2013_hairbrief.pdf
>>>> >>
>>>> >> A quote from the paper:
>>>> >>
>>>> >> "Our sampling scheme can be used for direct illumination sampling
>>>> >> (where indirect illumination may be approximated by Dual Scattering
>>>> >> [Zinke et al. 2008]) and also for indirect illumination, where
>>>> >> sampling at each vertex of a random path is used to create photon
>>>> >> maps within hair volumes [Moon et al. 2008] or within a variety
>>>> >> of unbiased path-tracing algorithms"
>>>> >>
>>>> >> Thoughts?
>>>> >>
>>>> >> MG
>>>> >>
>>>> >>
>>>> >> > From: brechtvanlommel at pandora.be
>>>> >> > Date: Wed, 5 Feb 2014 17:02:11 +0100
>>>> >> > To: bf-cycles at blender.org
>>>> >> > Subject: [Bf-cycles] Optimization project
>>>> >> >
>>>> >> > Hi all,
>>>> >> >
>>>> >> > With Gooseberry coming up, it would be good to start focusing on
>>>> >> > (CPU)
>>>> >> > optimization for the next few release cycles. For new features I
>>>> >> > still
>>>> >> > plan to finish volume rendering and add deformation motion blur soon,
>>>> >> > but besides that a more organized optimization project is something
>>>> >> > I'd like to spend time on.
>>>> >> >
>>>> >> > See this wiki page for more details:
>>>> >> >
>>>> >> >
>>>> >> > http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Optimization
>>>> >> >
>>>> >> > There's already great work being done by Sv. Lockal and others in
>>>> >> > this
>>>> >> > area, on the low level optimization front, but there's many more
>>>> >> > opportunities. I'll try to add more detail and ideas over time, this
>>>> >> > is just what I could think of off the top of my head.
>>>> >> >
>>>> >> > You can help out in various ways:
>>>> >> > * Contribute code to implement optimizations
>>>> >> > * Help gathering of test scenes representative of Gooseberry shots
>>>> >> > * Suggest practical optimizations ideas
>>>> >> >
>>>> >> > It would also be cool if someone could set up some webpage with a
>>>> >> > graph that tracks Cycles performance on test scenes over time, maybe
>>>> >> > doing a render with the latest Git version once a week or so (like
>>>> >> > http://arewefastyet.com/).
>>>> >> >
>>>> >> > Thanks,
>>>> >> > Brecht.
>>>> >> > _______________________________________________
>>>> >> > 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
>>>> >>
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles