Rendering with progressive CUDA renders first frame twice

[frueter]

Hi,

I just tested using the progressive CUDA rendering to render a sequence to disk. Unfortunately this always produces a first frame at low quality, then renders the first frame again at better quality as the second frame to write to disk, and after that everything is one frame out in the sequence on disk.
Attached is my test scene.

This is in Nuke 11.1v3 using VRay 3.70.01

Once I also had the scanline option produce the first frame twice I think, but I can't reproduce this, so maybe i was just getting confused.
The addition of the progressive CUDA option is more than welcome and it'd be awesome to be bale to use it to render to disk reliably as well.


Cheers,
frank

P.S.: Can files with .nk extension please be allowed as attachments in this forum?

[georgi.dunchev]

Hey,
We thought of progressive rendering in Nuke as an enabler for faster iterations of scene/material set up with the standard scanline rendering doing the final images.
We'll see what we'll come up with as a solution and get back to you.
Thanks!

[Christophe.Cot]

Hi Frank,
Are you rendering the sequence directly with Nuke in GUI mode or in terminal mode ?
Chris

[frueter]

Hi guys,

I was afraid you'd say that. But it's soooo much faster so it's quite a tease if you can't use it for rendering to disk.

In my case I was rendering from directly from the gui (because it was so fast it wasn't worth submitting to Deadline), but ultimately it would be very nice if it worked in both cases (with errors of course when the respective GPU isn't supported).

Is there a technical reason this wouldn't work for production rendering or was this just the first pass implementation?

Cheers,
frank

[Christophe.Cot]

As you might guess, the progressive renderer works on the edge of Nuke scanline workflow in order to control the output of progressively refined image output.

One problem with the native Write node is that it takes the 1st output image of our renderer for a given context which is really not what we want when we are in progressive mode since we will output many iteration of the image either undefinitely or after reaching one of the threshold (noise, time or sample) in the progressive settings group in the renderer.
When rendering in terminal mode, the logic is slightly changed - we dont need intermediate output so we just wait for the final image determined by the threshold. In that case it should work fine.
In gui mode however, there is no straightforward way to know what is pulling the dag so the same automatic switch is not possible. It would then require an additional checkbox to manually override that behavior but then quickly it affects the usability - constantly ticking this prior rendering a write node and unticking it, or forgetting about it and redoing a render, is not really a nice way to do it in my mind.

Once I find a more elegant way to handle this then it will be implemented for sure.
Until now a solution might be to spawn locally a Nuke process in terminal mode to render your scene. This can probably even be scriptable to launch it via Nuke in GUI mode.

Let me know if that can work for you as a temporary solution.

[frueter]

Thanks Christophe, I see the issue now. Glad it will work fine in command line mode (I haven't tested that yet).
As for getting it to work in GUI mode, maybe a "beforeRender" callback could be registered that checks it the upstream tree that is being rendered contains a VrayRender node set to "progressive GPU", in which case you know you need to suppress the progressive part of it.
This callback could be registered via the VRay menu.py and would be transparent to the user.
I'd be happy to help with this if you think it could be a solution.

Cheers,
frank

[Christophe.Cot]

Reusing the beforeRender callback (and afterRender callback to close the loop potentially) might be a good idea indeed, thanks for sharing.
Let me look at this and see if I can make it work reliably. I will keep you informed once I have something working.

[frueter]

nice. let me know if I can help

[frueter]

I just rendered CUDA progressive on the farm for the first time and am seeing random frames being written multiple times as well. So it looks like using CUDA for rendering to disk is just not an option yet?

[Christophe.Cot]

Hi Frank,
Thanks for reporting this. I had a quick look and indeed I see various problems happening when rendering animated sequence via command line using progressive mode.
This is still the first pass and initially we mostly focused on more interactive look development. So other use case such as rendering an animated sequence in progressive was not yet tackled.
Obviously it has to be now so I will look at ways to make it work.
I will keep you informed on the development.
Chris

[frueter]

nice thanks! I am very excited about this feature, so fingers crossed...

[Christophe.Cot]

Hi Frank,
I have done various experiment and I am happy to share that I might have a working solution.
It still need to be finalized and tested in various use case but it won't take very long before being available in an upcoming nightly build.
I'll keep you informed.

[frueter]

fantastic news, thank you!

[Christophe.Cot]

At last, tomorrow's nightly build (ref 3.71.03) should allow doing final frame render of animated sequence via a Write node, either Nuke running in GUI or in terminal mode.
Behind the scene, a dedicated callback is installed on any created Write node which disable partial update when in progressive mode. This is automatically triggered without the need to do anything particular.
In this case, the rendering process will be terminated only when one of the 3 threshold is reached : time limit, noise limit or sample limit.

Thanks to test it and report if everything works as expected.
Enjoy !

[frueter]

Awesome, will check it out for sure!
This should work both in GUI and command line render mode, right?!