[Bf-cycles] Ideas

Brecht Van Lommel brechtvanlommel at pandora.be
Thu Oct 27 17:15:59 CEST 2011


On Thu, Oct 27, 2011 at 6:04 AM, David <db4tech at yahoo.co.uk> wrote:
> Idea 1:
> Since render times can be quite long to clean up indirectly lit areas...
> How do you feel about the idea of adding the option of automatic progressive
> render saves?

Yes, this could be done, I still want to do a number of improvements
to make it possible to continue renders, use different seeds, etc.
Automatic saving could be part of that.

> Idea 2:
> Future render optimizations...
> Is it possible to focus sample passes based upon light intensity within a
> scene,
> darker areas receiving more sample passes than lighter areas (which already
> clean up very quickly)?
> If this isn't already happening with Cycles, would it provide a significant
> speed boost?

Adaptive sampling is something I'd like to work on at some point.
Darker vs. lighter areas aren't always the right solution though, it
would need something more clever to find noisy pixels.

> Idea 3:
> While rendering, trying to close Blender shows a popup warning window in the
> centre of the screen,
> "Blender is currently rendering, are you sure you want to close the
> program?" Yes/No
> I did this by mistake after just over 10 hours of rendering... :(
> While closing other open program windows (which were in front of Blender),
> I accidentally closed Blender before I had saved the ongoing render.

The "are you sure you want to quit" dialog is something that some
users have been asking for, but this isn't really something that
should be solved in Cycles, more a general usability issue in Blender.
It actually exists already on Mac, someone still needs to add it on
Windows and Linux.

> Idea 4:
> Aperture size scale...
> 'f/ stop' as an option to 'Aperture size', so users can use which they feel
> most comfortable with?
> (Shallow depth of field) f/0.9, f/1.4, f/2, f/2.8, f/3.2, f/4, f/5.6, f/6.3,
> f/7.1, f/8, f/11, f/16, f/22 and f/32 (Depth depth of field).

This could be added, it might require only python scripting to do
this, since we now have update callback functions for properties which
could update the other. Maybe someone here thinks it's fun to code
this? :)

The documentation currently mentions the relation as: aperture size =
focal length / (2 f-stop)

I don't know how focal distance comes into this, but this is the same
formula as in the renderman standard and pbrt.


More information about the Bf-cycles mailing list