[Bf-cycles] Optimization project

Brecht Van Lommel brechtvanlommel at pandora.be
Wed Feb 5 18:49:09 CET 2014


Light portals would be good yes. We may end up with indoor scenes that
benefit from this, I've added it to the list. There's other tricks
possible too, like placing area lights in windows. But it would be
good if we have a standard solution that can be documented to make
indoor scenes render faster.

Adaptive sampling could work, though so far I haven't come across a
paper with a reliable algorithm. There's a big gap between showing
that render A looks better than render B, and an algorithm that you
can use to render an animation on a render farm and get predictable
noise levels. The tricky part is that small percentage of pixels that
the adaptive algorithm fails to recognize as needing more samples. If
someone wants to experiment with such algorithms on more complex test
scenes and evaluate it that would be great.

For GPU render indeed it's harder than CPU. With CPU render it should
be pretty easy to experiment with this because it renders all the
sample in each pixels in a loop.

Brecht.


On Wed, Feb 5, 2014 at 6:17 PM, Lukas Stockner
<lukas.stockner at freenet.de> wrote:
> Hi,
> I can imagine that adaptive sampling might be useful, of course staying
> unbiased or at least not introducing noticable differences. For single
> frames, the user could provide this information, but for animations some
> heuristic would be important, like the one in
> http://graphics.cs.illinois.edu/papers/importance (the noise-aware part
> that generates a importance map).
> For GPU, a array of pixel positions for every thread could be generated
> on the CPU, however, using this with tiles is problematic since
> distributing samples between tiles is much harder than just inside a tile.
> Depending on the setting of Gooseberry, light portals might also be useful.
>
> Just my ideas, of course low-level optimization will be more important,
> but this might also help.
>
> Lukas
>> 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


More information about the Bf-cycles mailing list