[Bf-cycles] update delay

Cristobal Atria cristobalatria at gmail.com
Wed Feb 19 01:12:07 CET 2014

I would definitely use this option with complex scenes. I have been on the
same situation described above by David.

Cycles works great on normal scenes, but when the scene gets massive it has
no sense to look at those first few noisy samples that won't tell you
anything about the final image (and actually confuses your brain, making
you forget about the previews image you are trying to compare with the new
one, etc)

There should be an option to skip showing those first few noisy samples, so
that they are rendered but not displayed until noise level is acceptable.
Or may be a viewport buffer to compare with previous image. But I think the
idea of "delay the first viewport update" would do the job.

2014-02-17 16:43 GMT-03:00 David Fenner <d4vidfenner at gmail.com>:

> If I may add something else, maybe it would be even better if we could
> have the update done in user defined time steps. Let's say this options:
> option A: first update delay = 2sec (for example)
> option B: update steps:  = 1 sec
> The thing is, no one needs or wants to be looking at fast moving noise,
> not only it isn't useful, but it hurts the eyes and can give you headaches
> (from experience). In simple scenes the noise clears up so fast that it's
> not really a problem, but it's not the case with complex ones. If we could
> see, for example, instead of sample 1, 2, 3, 4, 5...40, 41,... etc.
>  something like, 0, 30, 40, 50, 60... it would be much more useful and way
> more easier to the eyes.  From 0 to 30 would be option A (first update
> delay), then from 30 on foward it would be option B, (10 sample delay).
> From a certain point foward it is always better to see still images than
> "moving" ones.
> 2014-02-17 16:30 GMT-03:00 David Fenner <d4vidfenner at gmail.com>:
> Hi, I tested the reset timeout option, however it seems that this just
>> waits longer to start sampling from 0, instead of starting sampling right
>> away but waiting a while to show us the first image, which is what would be
>> really helpful. The thing is just to skip the noisiest part of the process,
>> to be able to compare better, from a well sampled image to another one,
>> even if you have to wait a little longer.
>> 2014-02-17 16:10 GMT-03:00 Brecht Van Lommel <brechtvanlommel at pandora.be>
>> :
>> Hi,
>>> There's a hidden option that I think does what you are asking for. If
>>> you go into the outliner, choose datablocks view, and then go to Scene
>>> > Cycles Render Settings > Reset Timeout, you can set that value to
>>> 2.0s instead of 0.1s. We could expose this in the UI, it was added
>>> there mostly for debugging but if it's useful to users then why not.
>>> Brecht.
>>> On Mon, Feb 17, 2014 at 7:51 PM, David Fenner <d4vidfenner at gmail.com>
>>> wrote:
>>> > Hi there. I want to propose a very small thing that will be extremely
>>> > helpful. Right now interactivity with cycles is good to see what you
>>> are
>>> > doing, however it can also be helpful to "compare" images. Sometimes,
>>> when
>>> > you have a complex render, you have to make two f12 renders to compare
>>> the
>>> > changes, because you need to see a descently well sampled
>>> > highlight/material/displacement or anything to decide which one you
>>> like
>>> > more, specially when you are at the "fine tuning" point. Right now, the
>>> > interactive process let's you have quick previews of what you are
>>> doing, but
>>> > doesn't let you compare, because when you make a change on a complex
>>> render
>>> > the resampling process doesn't make an "instant" comparison, and the
>>> first
>>> > noise rounds confuse your eyes and the fine detail you wanted to
>>> compare
>>> > fades away from your brain easily. So f12 is required.  Right now, if
>>> you
>>> > start with a resolution of 512 (viewport settings) things get a bit
>>> better,
>>> > but you still can't make this "fine tuning" comparisons that are very
>>> very
>>> > important for high quality/detailed work. What I want to propose is a
>>> > feature to optionally delay the first viewport update as much as you
>>> want
>>> > (for example two seconds), this way, when you make a change, you
>>> compare a
>>> > descently sampled image to another one descently sampled, and you can
>>> enter
>>> > a fine tuning stage currently imposible without f12. Usually the render
>>> > process, and I say this out of experience, starts out with how it is
>>> now to
>>> > see the "macro" of things, yet it ends with a process of small
>>> comparisons
>>> > and tests. This feature would make you wait for a while longer for an
>>> update
>>> > (only a small while), but the update would be worthwhile to look at,
>>> and
>>> > would let your brain see an instant comparison, retainging the last
>>> image
>>> > and seeing the new one right away, so it can process the two better and
>>> > decide upon it.
>>> > I know you can make a very small box to see detail, but that doesn't
>>> give
>>> > you a "mood" or "feel" of the big picture. It is very frecuent to have
>>> a few
>>> > renders and make comparisons, constantly going back and foward with two
>>> > pictures of the same frame, it happens a lot in compositing too, it
>>> allows
>>> > the "artistic" desicions to take place. This feature would allow this.
>>> > Thoughts? I'm sure many people that work with cycles day by day start
>>> > increasing the viewport start resolution to get slower but more
>>> accurate
>>> > updates, not only to make fine tuning comparisons but also to ease the
>>> eyes
>>> > a little. If this could be taken a little further (only optionally) it
>>> would
>>> > benefit everybody.
>>> >
>>> > David.
>>> >
>>> > _______________________________________________
>>> > 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/20140218/6d90a770/attachment.htm 

More information about the Bf-cycles mailing list