Avoid animation flicker - Suggested settings?

[juang3d]

Hi there.

I used recently Corona in a project with more than great results :D

Now I have a project in front of me where I have to do a more complex 3D, similar to an Arch&Viz project, but not exactly that, so I'll have to do a video of a house with some interior animation, some object animation an so and I want to avoid flickering in the animation to avoid repeating render.

Are there any suggested settings for this? It's not going to be a static scene, it will contain moving objects.

Also, should I do a precalc phase fo all frames and save it, or corona does not work that way?

I can't think of more question right now, but I'm sure I'll have some more, so I'll ask than :)

BTW I'll use daily builds probably because I'll have to work in 2015 (probably, if I can stay at 2014 then I'll use A6 unless I see something in daily builds that makes me go for it)

Cheers!

[mirokurcik]

just use the PT + PT method and will not have any problem. Test the optimal number of passes and then give a limit.
too little noise is also ok, when you have this AE plugin:
http://www.redgiant.com/products/all/denoiser-II/
really nice and clean result.

[Captain Obvious]

You can pre-generate the HD cache, which will prevent flickering by locking the lighting to a single solution. However, that also means that the indirect lighting won't really update to accommodate for moving objects, so that's not going to work. Corona does not have temporal interpolation like V-Ray does (where you pre-generate one cache per frame, and then blend between them).

You can either do full path tracing for both primary and secondary bounces (PT-PT), which is guaranteed flicker-free. However, it is also significantly noisier than PT-HD Cache.

However, I've actually had some success with PT-HD. The trick seems to be to turn up the sensitivities. I did one test where I doubled the directional and normal sensitivities from their defaults, and I set position sensitivity to 80. That rendered completely flicker-free. Turning up the HD cache accuracy might also help.

For post-processing, the one I've had best success with is RE:Vision Effects' DE:Noise, but I'm sure the Red Giant product works well too. This can help both with per-pixel noise from the path tracing, as well as the flickering from the HD cache. If you are able to render out motion vectors and have access to either Fusion or Nuke or some other such high-end compositing hardware, you can use the motion vectors to apply even better deflickering/denoise in post.

Finally, if you're rendering an animation, use bucket mode, not progressive! You get much better results that way because the bucket mode can sample some areas more than others, which can really help deal with difficult noise. Progressive mode always samples all pixels by the same amount, which can be suboptimal.

[Ludvik Koutny]

The cases where bucket mode is better than progressive are a minority. So unless you have very specific reason, you should not use bucket, but stick to default.

[Tweekazoid]

unfortunately, rebus render farm does not support progressive, so in that case our only option are buckets which sucks

[maru]

Guys, you can set buckets to work EXACTLY the same as progressive rendering (initial samples in bucket mode is the same as passes in progressive mode). The only limitation is that with buckets you can't really render with precise time limit.

[Captain Obvious]

The cases where bucket mode is better than progressive are a minority. So unless you have very specific reason, you should not use bucket, but stick to default.

I disagree. I haven't been able to produce a single test case where buckets didn't outperform progressive for the same amount of render time. The only disadvantage is that you can't really, you know, render until it looks good enough. But that doesn't work for animations anyway.



Edit: what I do with buckets is use something like 10 base samples, and then 3-4 passes with the default noise threshold. That seems to work well. Adjust number of passes and base samples to taste. Buckets don't work well with too few base samples. In some scenes you may be better off with more base samples and fewer passes.

[maru]

I haven't been able to produce a single test case where buckets didn't outperform progressive for the same amount of render time.

It's not that simple. In some cases bucket rendering could decide no more samples are required and ignore some pixels, and rendering the same area without adaptivity would produce completely different result. But generally you are right, bucket rendering will be faster because, well, it's how it works. On the other hand, there might be cases where some image looks acceptable after X minutes in progressive mode and bucket rendering needs more time to finish current pass.

Edit: what I do with buckets is use something like 10 base samples, and then 3-4 passes with the default noise threshold. That seems to work well. Adjust number of passes and base samples to taste. Buckets don't work well with too few base samples. In some scenes you may be better off with more base samples and fewer passes.

This is highly dependant on the kind of scene you are rendering. Buckets are good if you have a huge, flat, noise-free area. In such case, progressive renderer will sample all the pixels for each pass anyway. Using default noise threshold will probably produce noise in noisy GI areas - this, as you wrote, can be fixed by increasing base samples but it's pointless to increase base samples very much because for each new pass you get 4 times the amount of previous samples and this will probably lead to render time higher than using progressive rendering. :)

[Captain Obvious]

It's not that simple. In some cases bucket rendering could decide no more samples are required and ignore some pixels, and rendering the same area without adaptivity would produce completely different result. But generally you are right, bucket rendering will be faster because, well, it's how it works. On the other hand, there might be cases where some image looks acceptable after X minutes in progressive mode and bucket rendering needs more time to finish current pass.

Unless something is very very wrong, it shouldn't produce completely different results. The only thing that should happen is more noise. Corona isn't exactly unbiased, but it's close enough to unbiased that the actual AA settings or number of passes rendered should only ever effect the amount of noise.

This is highly dependant on the kind of scene you are rendering. Buckets are good if you have a huge, flat, noise-free area. In such case, progressive renderer will sample all the pixels for each pass anyway. Using default noise threshold will probably produce noise in noisy GI areas - this, as you wrote, can be fixed by increasing base samples but it's pointless to increase base samples very much because for each new pass you get 4 times the amount of previous samples and this will probably lead to render time higher than using progressive rendering. :)

Most images contain large regions that require less sampling than certain small regions. A typical image probably has some areas that are clean enough after 50 passes, and some areas that take 500 passes. Using progressive rendering means you're stuck rendering the whole image to 500 passes, which is clearly inefficient. What I find works best is setting the base passes high enough to clean up the simplest bits of the image, and then enough passes to clean up the rest. The base/passes settings basically correspond to min/max AA samples in more traditional engines, like with V-Ray's adaptive sampler.


The only real advantage I can see of using progressive mode is that it's more predictable and can be stopped at any time, making it the ideal choice for when you have a set amount of time to render an image to a variable quality level -- if you need to deliver the image at 8 PM, simply render it in progressive mode until 7:30. That works less well with buckets, because if you stop it mid-pass you might see the outlines of buckets between where it had finished the new pass and where it was still showing the old.

[juang3d]

However, I've actually had some success with PT-HD. The trick seems to be to turn up the sensitivities. I did one test where I doubled the directional and normal sensitivities from their defaults, and I set position sensitivity to 80. That rendered completely flicker-free. Turning up the HD cache accuracy might also help.

Hi guys.

Sorry for the late reply, the Captain-Obvious answer is working perfectly, when I raise the position sensitivity to 80 it eliminates flicker and still is a lot faster than PT+PT, I'm using bucket mode anyways, it feels faster, I don't know if it's true, but it feels that way.

I've also raised the other two options to 8, I'm not sure if it's too much or if they are helping or just making the render longer, because I don't fully understand those options, but at least I'm getting flicker free animation for the time being, this was a fast test, I'll have to confirm later with a more final scene.

Thanks to everyone and cheers!!!

[snakebox]

Sorry to revive this topic!

But it holds some very useful information about the current state of Corona when used for animation.

I do also have a question, which HDcache load method do you use when using PT+HD and bucket render like this. Do you calculate the HD cache new every frame? or do you append?

Thanks

[juang3d]

Hi Snakebox.

Why are you sorry? Hehehe :)

I cannot append because the render is done in a farm, so not all the computers have the previous frame info,so it is being calculated per frame, but the call time is minimum, around 1 minute for 40 minutes frame, so it is pretty fast.

Cheers!