Macros and Rendering Crashes

it’s a nightmare today!

I need to get renderings done. Scene and everything is set up. now I wanted to start a renderbatch with a macro like I always do. but rhino wip crashes everytime .
try this:
_Render _-SaveRenderWindowAs C:\User\UserName\Desktop\test\batchrender-01.png _CloseRenderWindow _Enter

so I will have to check like every 10 minutes now in order to save and kick off an new rendering?! are you kidding me?
and why isn’t there a batchrender option already?
please tell me there is and I just haven’t noticed jet

context:
I use it in conjunction with snaphots - which is a great new feature. this part of the macro works fine:
-_Snapshots _Restore "Snapshot-XY" _Enter _Enter

I have created RH-40168 for investigation.

Thank you for reporting.

/Nathan

was a little in panic mode, sorry.
of course just rendering multiple shots at the same time also works fine. that did the job just fine as well.
still i think batch rendering is needed.

back to the problem:
installed the latest wip yesterday evening.
the same lines of macro didn’t make the wip crash anymore but it was still not really working.
normally the behavior was that the macro would wait for the render to finish and then go on to save the picture and close the render window. instead it saves immediately after starting the render process and closes the render window.

this morning i wanted to investigate on this a little more but now all of a sudden the same lines of macro will crash the wip again. that’s really weird since nothing obvious to me has changed.

I really hope macros work again soon, since macros are just commands and those should really work, basic stuff i think.

EDIT:
now the crashes are gone again. back to not working because not waiting for render to finish.
really weird.

I tried to work around this issue by diving into scripting.
turns out scripting is also affected by this.

scripting doesn’t help since it relies on the same commands.
so macro/scripting together with cycles is not working jet.
no problem when rhino-renderer is used.
hope you get a grip on that soon.

Have you tried latest public WIP? You should be able to use macros for rendering, saving render result, and closing the render window with it.

yes latest WIP and finally it seems to work.
probably I had a syntax error?
thanks!

Who knows (: glad it works now.

@nathanletwory
everything was fine for a long time now. yesterday evening I prepared a big batch and left the office. now I realize, that this bug is back.
again, the macro is not able to “hit the stop button” which is necessary for the macro to continue.
I used the same macro that I had used previously a couple of times without any problem.

hope this is just something simple and can be fixed for the wip/beta tomorrow?
(so now we are “BETA”, when will we see a “WIP” again?)

btw, I was really happy with the improvements in lighting and renderspeed over the last time. there was especially one wip which made a huge step.

and another little thing:
cycles doesn’t utilize the GPU correctly. utilization constantly jumps between 0 and 100%. the frequency is depending on the tile size. so with a smaller tile-size the it jumps quickly between 0 and 100, whereas on higher tile-size it keeps the 100% utilization for a longer period but also rests at 0% longer. with very larger tile-sizes, the longer resting at 0% will even make the GPU lower its frequency cause it thinks it’s time to go to idle. raytracing in the viewport utlizes the GPU correctly 100% all the time (so you could say in rendering 50% of the time it works all the time :joy: ).
I guess fixing this bug could double the render speed.
(you need a program like msi-afterburner to get good readings and a graph in order to observe this behavior. windows10 can show the GPU utilization too since the last big update, but it’s useless in this case because it just shows an averaged curve).

Hi,

For the BETA I won’t probably be making changes to Cycles for Rhino, since that isn’t going to be shipped with 6.0. My understanding is that the next WIP will come into existence when 6.0 is released.

The jumpy GPU usage probably coincides with the render results being updated to the render window. I have to do some measurements to be able to say, though.

So CfR fixes and changes will wait until I really don’t have open 6.0 issues left. That said, I think I fixed yesterday the problem with the stop button not working. So you may get the fix for it nonetheless.

oh I really hope this will do it. otherwise it will be very painful, starting all the renderings parallel and later saving them all manually.

hope we’ll be able to render at 100% utilization all the time, not like:

btw:
to me it would totally fine if the renderwindow wouldn’t get updated at all. just a simple progessbar and saving the final result to file would be enough for me.

You could use ViewCaptureToClipboard or ViewCaptureToFile commands. They have these days a RealtimePasses option that takes the amount of passes to render. So you can script display mode switch ro Raytraced, then capture directly to file.

Had noticed the new options in ViewCaptureToFile already but wasn’t sure what to do with it.
tried it, works great so far. seems to be a good workaround - even better, since I get full GPU utilization.
“100%-EveryTime” :fireworks:
done nicely with the progressbar.
I can even switch resolution per rendering. Wanted to ask how I can control the render resolution via macro anyway.

my macro looks something like this now:

_-Layer On LayerA _Enter
_-NamedView _Restore "view-01" _Enter
_-SetDisplayMode _Mode=Raytraced
_-ViewCaptureToFile Width=1536 Height=1024 NumberOfPasses=2500
"C:\folder\file-01.png"
_-SetDisplayMode _Mode=Wireframe
_-NamedView _Restore "view-02" _Enter
_-SetDisplayMode _Mode=Raytraced
_-ViewCaptureToFile Width=1536 Height=1024 NumberOfPasses=2500
"C:\folder\file-02.png"
_-SetDisplayMode _Mode=Wireframe

…cycling through different views…

_-Layer Off LayerA _Enter
_-Layer On LayerB _Enter

…cycling through different views and layers…

think there is no need to “visibly” switch the viewport to raytraced. just the output would do fine for me.

@nathanletwory
is there any difference between CfR and Raytraced?
will I get a different result regarding the quality?

and also, maybe move this thread to the “rendering-wip” section.

If you are going to do lots of rendering on one file then you should have to change to Raytraced only after each file open. Raytraced yields exact same result as CfR. ViewCaptureToFile indeed is much faster than CfR, as the render result is copied from the render device only once actually done.

For more advanced setups you may want to check out SnapShots. Great for testing different material setups, positions, view angles.

I’m so furious right now!
came back to the office late today because I knew my machine would still be rendering.
windows decided to update and restart the system, damn i’m so mad at microsoft right now!
next time I’ll just unplug the ethernet cable before I leave.

regarding what matters here:
five renderings finished before the updates, so the macro works fine.

regarding render speed:
one rendering took roughly 35 minutes to complete (1536x1024px @ 2500 samples)
before and with the standalone CfR the more or less same scene took roughly 45minutes, same resolution but at only 2000 samples.
so CfR is wasting a lot of time at the moment.

yes, had tried this, see opening post.
snapshots is great, but in this case i’d rather manage it with layers and sublayers. it depends on the project which is more usefull for me.

Yup, and as said I won’t be further looking into that until v7, when it in all likelyhood will replace Rhino Render (where CfR will be renamed Rhino Render in place of old-style Rhino Render)

1 Like

fine for me, since the ViewCaptureToFile method works really well.

btw
blender/cycles is free and open source, right?
mcneel charges money for rhino which will have cycles integrated. will mcneel pass over a certain percentage per sold license to blender or how will that work?

For features and fixes we add to Cycles we will submit patches, so the benefit goes both ways. Also, the source code to our branch (fork) of Cycles, my .NET wrapper library CCSycles and the actual plug-in code are publically available under the same license, all in compliance with Cycles’ open source license.