<div dir="ltr">Great news! Very interested in this. I can give away a baked frame of this <a href="https://vimeo.com/53108942">https://vimeo.com/53108942</a> I's gotta be baked because otherwise it's too messy with links, symlinks hacks (for all the cows), etc.<div>
<br></div><div>Another idea for optimization would be in textures! I'm always paying special attention to the number of channels I'm using. If it's a texture with alpha then RGBA, it it's only for colors then RGB, and i it's just a matte then i'ts single channel BW. IIRC Cycles converts any kind of texture to full RGBA buffers and that's quite wasteful no?</div>
<div><br></div><div>cheers</div></div><div class="gmail_extra"><br clear="all"><div>Daniel Salazar<br><a href="http://patazstudio.com" target="_blank">patazstudio.com</a></div>
<br><br><div class="gmail_quote">On Wed, Feb 5, 2014 at 11:49 AM, Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Light portals would be good yes. We may end up with indoor scenes that<br>
benefit from this, I've added it to the list. There's other tricks<br>
possible too, like placing area lights in windows. But it would be<br>
good if we have a standard solution that can be documented to make<br>
indoor scenes render faster.<br>
<br>
Adaptive sampling could work, though so far I haven't come across a<br>
paper with a reliable algorithm. There's a big gap between showing<br>
that render A looks better than render B, and an algorithm that you<br>
can use to render an animation on a render farm and get predictable<br>
noise levels. The tricky part is that small percentage of pixels that<br>
the adaptive algorithm fails to recognize as needing more samples. If<br>
someone wants to experiment with such algorithms on more complex test<br>
scenes and evaluate it that would be great.<br>
<br>
For GPU render indeed it's harder than CPU. With CPU render it should<br>
be pretty easy to experiment with this because it renders all the<br>
sample in each pixels in a loop.<br>
<span class="HOEnZb"><font color="#888888"><br>
Brecht.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Feb 5, 2014 at 6:17 PM, Lukas Stockner<br>
<<a href="mailto:lukas.stockner@freenet.de">lukas.stockner@freenet.de</a>> wrote:<br>
> Hi,<br>
> I can imagine that adaptive sampling might be useful, of course staying<br>
> unbiased or at least not introducing noticable differences. For single<br>
> frames, the user could provide this information, but for animations some<br>
> heuristic would be important, like the one in<br>
> <a href="http://graphics.cs.illinois.edu/papers/importance" target="_blank">http://graphics.cs.illinois.edu/papers/importance</a> (the noise-aware part<br>
> that generates a importance map).<br>
> For GPU, a array of pixel positions for every thread could be generated<br>
> on the CPU, however, using this with tiles is problematic since<br>
> distributing samples between tiles is much harder than just inside a tile.<br>
> Depending on the setting of Gooseberry, light portals might also be useful.<br>
><br>
> Just my ideas, of course low-level optimization will be more important,<br>
> but this might also help.<br>
><br>
> Lukas<br>
>> Hi all,<br>
>><br>
>> With Gooseberry coming up, it would be good to start focusing on (CPU)<br>
>> optimization for the next few release cycles. For new features I still<br>
>> plan to finish volume rendering and add deformation motion blur soon,<br>
>> but besides that a more organized optimization project is something<br>
>> I'd like to spend time on.<br>
>><br>
>> See this wiki page for more details:<br>
>> <a href="http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Optimization" target="_blank">http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Optimization</a><br>
>><br>
>> There's already great work being done by Sv. Lockal and others in this<br>
>> area, on the low level optimization front, but there's many more<br>
>> opportunities. I'll try to add more detail and ideas over time, this<br>
>> is just what I could think of off the top of my head.<br>
>><br>
>> You can help out in various ways:<br>
>> * Contribute code to implement optimizations<br>
>> * Help gathering of test scenes representative of Gooseberry shots<br>
>> * Suggest practical optimizations ideas<br>
>><br>
>> It would also be cool if someone could set up some webpage with a<br>
>> graph that tracks Cycles performance on test scenes over time, maybe<br>
>> doing a render with the latest Git version once a week or so (like<br>
>> <a href="http://arewefastyet.com/" target="_blank">http://arewefastyet.com/</a>).<br>
>><br>
>> Thanks,<br>
>> Brecht.<br>
>> _______________________________________________<br>
>> Bf-cycles mailing list<br>
>> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
>> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
><br>
> _______________________________________________<br>
> Bf-cycles mailing list<br>
> <a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br></div>