the render progress bar window which pops up immediately indicated to me that the rendering would take ages. if I just set the same viewport to raytraced, finishing the same amount of passes/samples is much quicker.
I used MSI afterburner to check the GPU behavior and noticed the following. with “normal” raytraced viewport the GPU memory usage would be around 5GB, for the particular file I had in use. with ViewCaptureToFile the GPU memory usage would spike to the max of my available GPU memory which is 8GB.
with a simple test scene and a smaller resolution the behavior was the same. when using ViewCaptureToFile the GPU memory usage roughly doubles compared to using raytraced viewport.
I attached the test file though I assume this issue is not related to any particular file. Untitled.3dm (116.7 KB)
my tile size is set to 256x256 _-RhinoCycles_SetRenderOptions tile_x 256 tile_y 256
why does ViewCaptureToFile need double the amount of GPU memory? this seems to be the reason why it also takes much longer and makes it unusable because it can easily eat up all available GPU memory.
If your viewport is still raytracing when you do the capture you’ll get essentially two scenes being rendered at the same. This explains both the slowdown and the increased memory usage.
What you instead could do is to script this with Python, since then you can:
set up the vp with the size you want to render at
set its display mode to Raytraced
wait until the viewport is done with the amount of samples you want (essentially do something like wait for say 1 second, check the vp status, if not ready, go back to waiting)
do the vp capture, which now will directly capture the vp, not start a new session
damn, I had hoped I could live without scripting, seems like I can’t avaide it anymore.
anyway, in order to make the capturetofile method work with raytraced, I suggest that one should not need to actually set the viewport to the desired display mode before using viewcapturetofile. for example adding a dropdown to the viewcapturetofile dialog box (or option to the command) where the desired display mode can be chosen without at the same time setting the viewport to that display mode.
I’ll whip up a python script tonight or tomorrow too if that helps.
You can also use TestPackageManager and install rhino-render-next, which is essentially Raytraced as the _Render command, after which you should be able to script just that and never change to Raytraced mode. That might be the nicer way for you.
How was your journey with scripting, 3 years later?
I was also reluctant but now I love modeling.
Before I didn’t, it was just too clunky. With a few simple scripts you can really make your workflow so much smoother and fun
Well, actually I managed to get around starting with scripting. grasshopper turned out to be the simpler solution. I just threw the neccessary commands into gh. then it is just a few components that operate on text (like “concatenate” and “replace”). with that I can generate a big macro txt that has everything I need, including queuing renders through different material assingnements, views etc and also of course getting all those details appear in the final filenames. big macros that always work perfectly for me.
grasshopper saved me from having to start scripting
btw, most fun thing about this was that I could use gh in fullscreen, no rhino viewport needed, since there is no geometry involved at all, just simple text manipulation.
