Batch rendering with cycles

hi,

if i had to render a lot i used to generate a simple macro with grasshopper. i could simply copy the data and paste it into the rhino console or drag n drop the output txt-file into the rhino viewport.

instead of cameras or namedviews i always set up spotlights with _-SetSpotlightToView NewSpotlight.
with the new cycles render plugin this process doesnā€™t quite work. sample count got to have a max value of course. but when it has finished sampling, the render window wonā€™t close with the command _CloseRenderWindow, i will still have to manually click the ā€œstop renderingā€ button and then my macro will continue. of course i donā€™t want to interfere manually after every rendering.

is there a workaround?
or even better: will there be a native solution for batch rendering with cycles? maybe somehow connected to this?
never tried scripting - would that provide a solution for now?

btw, i havenā€™t worked with cameras jet. what can a camera do that my spotlight-method canā€™t? i guess iā€™m missing something, right?

here are the files.
the gh-file that generates the macro and a rhino-file with four spotlights which are accordingly named. just change file-destination and file-name in the gh-def.
makro_gen_render 15.gh (7.9 KB)
batchrender 001.3dm (177.5 KB)

Iā€™ll have to check the integration with scripting. Thanks for bringing this up.

all it would need, would be for cycles to ā€˜stopā€™ the rendering after it reaches the preset sample count. then the render window could be closed with the _CloseRenderWindow command.

so i guess itā€™s to early to talk about batch functionality for cycles at this point?

No, just tested this and it seems to work.

  1. Set my samples limit to 100 using _RhinoCycles_SetRenderOptions
  2. Open _MacroEditor and pasted below macro

_Render
_-SaveRenderWindowAs D:\Temp/RenderTest.png
_CloseRenderWindow

After running the macro, the render starts, renders 100 samples, saved the file to the location specified and closed the render window.

Tested with (6.0.17067.22331, 08.03.2017) and v0.1.0

What i found not right is the speed when using the render window. I got twice the time compared to viewport rendering, even when it first looks like it now renders using tilesā€¦but somehow till progressive

c.

2 Likes

@clement

thank you so much, clement. it was just too much in one line.
this works now:
makro_gen_render 18.gh (14.0 KB)

Thanks for testing. One thing less to worry about!

i have to revisit this matter.
the render-macro works fine with small/fast renderings. but when i want to render a higher quality (resolution 1600x1200 and up, final quality, 300 samples and up) the same macro will again not be able to stop the finished rendering and close the render window in order to start the next rendering. again i have to click the ā€œstop renderingā€ button myself in order to help the macro continue its work.
i tried performance mode, no screenssaver and even disabled rhinoā€™s autosave function. nothing helps, seems like whenever a rendering takes longer than a few minutes to finish, the macro will not be able to stop the rendering and close the renderwindow.
itā€™s really weird.
any suggestions what this might cause?

@clement alerted me of this issue. Iā€™m trying to get it fixed before this weeks WIP.

Thatā€™d be PEBCAK - I foobarred.

ok, i thought iā€™m stupid or crazy or both.
glad to see iā€™m not the only one with this problem :relieved:

@hitenter, just curious, if you have Cycles for Rhino set as current renderer, can you still fluently work with the raytraced viewport ? On my side, this is impossible as it causes a noticable lag in the UI. Once i change to Rhino as current renderer, it runs better, so i only change to Cycles for Rhino if i want to render a larger view than viewport size, then once done i switch back to Rhino.

btw. the bug that you cannot access the Save button in the render window before the Stop button has been pressed has been reported. This happens even when the sample limit has been reached and may be related to the macro problem.

c.

yes i experience this lag too, it is pretty intense.
also i noticed, that some shadows donā€™t seem to be working/appear in the raytraced viewport. but if i render with the cycles plugin the shadows appear like expected.

i guess there is still a lot of work to be done with lights and materialsā€¦

c.

The lag is most likely due to all previews being rendered with Cycles as well. Unfortunately the preview job queuing system isnā€™t that smart, so there is quite a bit of overhead there. Not much I can do about, Iā€™m afraid.

I just pushed

and

That hopefully will help with the RenderWindow stopping issue.

These changes are currently pending to get into Rhino master, hopefully theyā€™ll make it into the upcoming public WIP release.

Custom materials (and plastic, but those are close to custom material)

https://mcneel.myjetbrains.com/youtrack/issue/RH-37339
https://mcneel.myjetbrains.com/youtrack/issue/RH-38199

/Nathan

looks like the fix didnā€™t make it into yesterdayā€™s WIP :disappointed:
(WIP 2017-Mar-14)

so no over-night rendering jet :cry:

@nathanletwory

I was hoping the new Cycles for Rhino v0.1.2 plugin you just released would help.
just tested it - still manual stop klikking necessary :unamused:

it seems to me, that this is not related to any settings? seems to me this only happens, when the rendering takes more than a certain amount of time?

EDIT:
no, i was wrong. itā€™s not related to time. it seems to be the sample count. the macro is able to stop every rendering with up to 255 samples, regardless of the resolution or quality. but at 256 samples and up, stopping the rendering will only work manually.
why 256?

I have no limits set to 256. The 0.1.2 did not address this issue, it will be addressed in a future WIP release as the bug is somewhere in the RhinoCycles core.

HA, YOU DID IT!
looks like the ā€œ256 sample limit - bugā€ is gone since the last wip (WIP 2017-Apr-4).

thatā€™s great, thank you.
i know what my office-pc will do over night :laughing:

Cool! I did nothing, but Iā€™ll gladly take the credit (:

well, i checked with the WIP 2017-Mar-28 and the bug was still there. regardless what file or scene or settings, automation wouldnā€™t work over 255 samples.

now with WIP 2017-Apr-4 that strange limit is gone - i did a quick test, again with different files at 300 samples and this time the macro had no problem closing the render window and continue.

tomorrow morning iā€™ll know if it also works flawless with very high sample counts - guess iā€™ll try something like 10.000 samples.
then iā€™ll also know if i can call my system ā€œrock-stableā€ or not :worried:

1 Like