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)
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?
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
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?
@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.
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.
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.
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
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.
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
