ViewCaptureToFile of Raytrace still slow

Compared to normal viewport Raytraced, the CaptureViewToFile is still slow…

Anyonelse sees this?

Setting output as viewport size and no checks in optional stuff like transparent background so should
be same as viewport raytraced.
(If sampling done in viewport of 1000 then, CaptureViewToFile set to 1000 samples is instant, so there should be no reason why it’s so slow…)

Work around is just running on viewport then saving it with same or lesser sampling, so it’s ok… but would sometimes just having running and file saved.

I recall you are on a 4K screen. That means that the viewport most likely has a more grainy version (pixel size 2). Capturing the view will do that on pixel size 1, as a result it will rerender everything up until the set sample count.

Do you mean the default viewport DpiScale setting?

But, in that case when doing ViewCaptureToFile, after sampling is finished to the same sampling number of below would save a render which is not as high resolution as just doing ViewCaptureToFile?

It that case though, I guess the quality of render of ViewCaptureToFile is quite dependant on the DpiScale parameter… which I guess should be notified in the UI.

As doing ViewCaptureToFile is instant to save, if sampling number is same as that of the viewport… currently.

Ah yes, so when you are doing a capture with sample count set to 1000 in the capture dialog, but your viewport is still not on 1000 the rendering will be redone indeed. I don’t have a good solution for that.

Current logic:

  • viewport set to 1000, currently at 200, start capture with 1000: start a complete new render session
  • viewport set to 160, currently at 160, start capture with 1000: start a complete new render session
  • viewport set to 1000, currently at 200, start capture with 150: instant capture of current status in viewport, as required (minimum) count has already been reached
  • viewport set to 1000, currently at 1000, start capture with 1000: instant capture, as required count has already been reached.

Does that make sense

ふAll makes sense, if in all cases the image saved is of equal quality.

For the below two cases, doesn’t the render quality be lower, if in 4K displays the viewport is more blocky?

It seems the Capture function has two rendering output quality, one done from scratch (higher quality but more time) and one just saving what is shown in the viewport(quality dependant on how rough the viewport is set).
Otherwise, I don’t see how sampling on viewport then save is fast while capture from scratch takes morn time.

Maybe I should test the output quality and size of
images for both cases…

Do test.

I guess there is a tradeoff to be made here, and I am assuming users want the full resolution as end result. But I don’t think the DPI settings matter in these cases. It is about requested samples and samples ready in viewport.

Quick test done:
Tested with simple shape glass material.
With environment “AC Gava Bath”. no other changes to settings.
V6 file attached.

300sample ran.

Found out that…

  1. Raytraced in viewport of 300samples then saving the viewport @ 300samples(insta save) gives a slightly larger file size
  2. Visual quality much better on when using ViewCaptureToFile to render when zoomed.
  3. Time taken on the ViewCaptureToFile is roughly ~5times more.

Conclusion: The quality and the speed of output varies with whether finishing sampling inside viewport vs. using capture command to render.

For quick render use viewport to render and save at same sampling or lower.

For final render use capture command making sure to set sampling higher than what has finished in the viewport.

I have to check using different dpi value if that changes things. Would like to try setting the viewport resolution to same as the Capture command…

RaytracedSpeed.3dm (5.3 MB)

Zoomed image:

Took 10min Capture to File(viewport sampling not finished and paused.):

Took 1min40 to finish in viewprt and saving time instantly:

I’m looking to do the same thing and discovered that ViewCaptureToFile does not use the GPU when it does rendering outside the viewport. Could you check and see if this is the reason for the performance decrease? - Could be a bug.

@partiform, does Raytraced itself use GPU? What device is selected in Tools > Options | Cycles?

Yes, Raytraced view is set to use only the GPU (Cuda). I can confirm it uses the GPU in the Windows task manager. (below)

The issue is that when I initialize ViewCaptureToFile, I see in the task manager that the GPU is not used at all. (below) This likely why it takes so long.

The taskmanager is not a good way to check GPU usage. While using Raytraced in the viewport you can click on the namb Raytraced (Cycles) it should show the device that is being rendered with. If it is using the GPU it should show that GPU (something like Raytraced (Cycles@Radeon (TM) Pro WX 9100) or Raytraced (Cycles@GeForce GTX 1060 6GB), if it is using CPU it will say so (something like Raytraced (Cycles@CPUx4)).

The very same rendering device will be used for ViewCaptureToFile and ViewCaptureToClipboard. Doing so won’t use the UI, so taskmanager will show 0% or close to that, since no UI is being updated. To properly check if your GPU is used you should be using GPU-Z instead. This will give much better idea of GPU usage. Now, if you are rendering to a (much) larger resolution and possible to a higher NumberOfPasses count then it will indeed take as long as it need to take. When capturing view on higher resolution or to higher pass count you should consider setting the viewport maximum samples count to 2 or 3. That way you won’t be rendering two scenes at the same time, which will take extra long time.

Thank you! The GPU-Z program is great. I set up a test scene and let the viewport render to 1000 samples. - It took a little more than a minute and used the GPU constantly.

Then, I set the viewport sample count to 3 and moved the camera a little, letting it settle. After that, I set up the same task (1000 samples) at the viewport’s original resolution with CaptureViewToFile.

The GPU-Z load profile shows some strange behavior. - Any idea why it’s throttling like that?

Hmm, not sure why it would do like that. I’ll have to check the code again, but it is supposed to render all samples until the end, and only then write results to the framebuffer. What is the output of Help > System Information? Could you paste that here please?

Rhino 6 SR2 2018-3-6 (Rhino 6, 6.2.18065.11031, Git hash:master @ cd4fa1dcdec31cb58baacef0855771173af7196f)

Windows 10.0 SR0.0 or greater (Physical RAM: 32Gb)

Quadro M2200/PCIe/SSE2 (OpenGL ver:4.6.0 NVIDIA 391.33)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 3-22-2018
Driver Version:
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 4 GB

C:\Program Files\Rhino 6\Plug-ins\Commands.rhp “Commands”
C:\Program Files\Geometry Gym\Rhino3d\BullAnt.rhp “bullant”
C:\Program Files\Rhino 6\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp “Rhino Render”
C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp “RDK_EtoUI”
C:\Program Files\Rhino 6\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 6\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp “RhinoCycles”
C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp “Toolbars”
C:\Program Files\Rhino 6\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp “Displacement”

I think this may be due to having twice the same scene in memory. The capture now pages regularly in memory from host to device which can take a while.

Logged for this case.

I found another issue while testing.

Overnight, I performed a raytraced ViewCapture at 5000x3000px with 1000 passes. The output (.tiff) was a single color. (below) Could this be because the output resolution was too high? I just did the same raytraced ViewCapture with 23 passes and the output was the same. Tried again outputting to .bmp and the output was also the same.

This is a know issue. For a workaround see

RH-45147 is fixed in the latest Service Release Candidate