[Bf-cycles] Optimization project

Daniel Salazar - patazstudio.com zanqdo at gmail.com
Wed Feb 5 19:08:43 CET 2014


Great news! Very interested in this. I can give away a baked frame of this
https://vimeo.com/53108942 I's gotta be baked because otherwise it's too
messy with links, symlinks hacks (for all the cows), etc.

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?

cheers

Daniel Salazar
patazstudio.com


On Wed, Feb 5, 2014 at 11:49 AM, Brecht Van Lommel <
brechtvanlommel at pandora.be> wrote:

> 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
> _______________________________________________
> 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/20140205/1f837817/attachment.htm 


More information about the Bf-cycles mailing list