OTOY Forums

HI, I remember one of pillar features for OR 3.0 was/is different store/caclulation of Film buffer (now to Host RAM instead keeping it to VRAM) and it was been mentioned that we will be able to save film buffer at any time and then continue rendering later at sample level we already reached/stored (did i got that right?).
So i wonder since OR 3.0 release date is May 15th (9-10 days from now) i wonder when will this feature come to Test/plugins ? I've tested Beta 3.0.10 plugin and i can't seem to find that feature yet ?

Is that still in progress or given up on that feature ?

Thanks

It will be implemented in the upcoming beta 1 Standalone. The implementation on the plugin side may take a bit longer since there is some work required to make it work there.

abstrax wrote:It will be implemented in the upcoming beta 1 Standalone. The implementation on the plugin side may take a bit longer since there is some work required to make it work there.

Thanks for quick reply abstrax, that's good news. I was afraid that feature is maybe dropped. It is/should be very cool feature, we had something similar in LightWave FPRIME many many years ago (10+) and it was fantastic tool for animations, we could render first pass/rough animation very quickly and go to composition software working while renderer refines frames to next level(s) of quality.
Not sure how is your implementation mean tot work but if is not already IN that way plelase consider to have automatic save of buffer set in X minutes per user so that FPRIME similar process could be used in OR3 also.

cheers

The ability to store the render states of a full animation may not make it into 3.00, but I will put it on the to-do list.

Marcus, don't you need this feature in the event that one loses internet connection while in ORC session?...

FrankPooleFloating wrote: Marcus, don't you need this feature in the event that one loses internet connection while in ORC session?...

As far as I know, ORC is basically running render jobs on the cloud and you don't have to be connected with it all the time.

abstrax wrote:

FrankPooleFloating wrote: Marcus, don't you need this feature in the event that one loses internet connection while in ORC session?...

As far as I know, ORC is basically running render jobs on the cloud and you don't have to be connected with it all the time.

Yes - ORC is asynchronous. In addition to exporting your scene to ORBX and dropping that into the ORC web page to render (as we did last year for RTM), you now have a more seamless option that skips this step.

You can 'send' a render target to ORC from within the host app or SE (along with delta changes to the RT since the last sync with ORC ) and ORC will add the render job to the same queue on orc.otoy.com that tracks render jobs started from manually uploaded ORBX file. The new delta sync system also has version control, so you can go back to earlier snapshots that have been synced with ORC.

We have a budget of ORC credits we will allocate to users after beta 1 is out to more robustly test delta syncing using the full 3.00 feature set (including pause/resume film buffer transfer).

Goldorak wrote: We have a budget of ORC credits we will allocate to users after beta 1 is out to more robustly test delta syncing using the full 3.00 feature set (including pause/resume film buffer transfer).

Excellent, looking forward to test that, especially pause/resume and resume locally and vice versa.

thanks

I am very new to v3, and if I understand the above posts correctly, Resume Render is a new function in Standalone. If so, how do you set it up? I just lost a render due to a power outage and a dead UPS battery.

I did see the Load and Save Render State menu items and indeed, you can do it there, but it is not an automatic feature, with every screen update. Could this be done with a LUA script?

i add my thumb up to resumable render like Fprime, i spent 599$ years ago for Fprime license exactly for this feature, the ability to render out a rought animation, move to compositing and other task rought materials and in the mean time refine render and stop only when we are good in progressive pass. also if today after since 12 years computer are a bit faster (only a bit, moore law lie from too many years) we also need a more optimization, and resumable pass could be a great step for a better and flexible workflow.