[Bf-cycles] ray depth

David Fenner d4vidfenner at gmail.com
Mon Oct 6 01:47:47 CEST 2014


Hi cycles devs :)

Since you are in the quest of optimizing speed, and dingto recently
commited code to save memory in mix nodes and such, I would like to point
some attention into the very useful ray depth attribute. I recently
assisted to a talk done by a lead lighter at dreamworks and he would
constantly talk about how they basically painted polygons with lights to
match the concept art (they have one for every single shot). It turns out
that there were many "fake lights" used to enhance the look that had no
physical or logical sense at all, and the eye didn't even noticed, it was
all about achieving a certain look. Usually in this auxiliary lights GI was
more of a problem than help, since for example a fake rim light would
bounce very strongly into another character in an undesirable way, but for
an environment light GI was useful, so GI control per light was used.
Currently in cycles we can control how many times a light can bounce
independently of global settings with the ray depth attribute, basically by
mixing the light emission node with no shader at all, using the ray depth
attribute as a factor (with some math nodes too). The thing is that a scene
with bounces, even if we have the ray depth trick to a light so the bounce
is non existent, renders just a slow as if the bounce was actually
illuminating the scene. So I propose two things:
1) A simpler way to control light bounces (for example in light settings of
each light), because this is very very used in animation.
2) If a the bounce is black don't let it get calculated, so that a scene
with global bounces but lighted with a no bounce light renders just as fast
as a scene with no global bounces.

This is a very very used feature in high end animation production, not only
for artistic control but to optimize speed, only putting bounces in the
lights that actually need it (visually wise). Currently we can't optimize
with this and control is there, but a little clumsy.

Thanks,
David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20141005/41bcf60a/attachment.htm 


More information about the Bf-cycles mailing list