Hello,
I made a test with the same file for the Viewport Raytracing time.
Rhino 6 in 4min 24sec, gave me 184 cycles (number on the bottom left of the viewport)
Rhino 7WIP in 4min 37sec, gave me 19 cycles.
Is this expected?
I am using a slow machine, but the cycle nr difference is enormous and the definition is also very noticeable (at least in this low cycle count).
N
Are you on a Mac or on a Windows machine?
Windows. I use a Surface Pro (!) at the moment.
N
Depends a bit on whether the display is a high-DPI one or not. Between v6 and v7 the difference is that v7 at the moment doesn’t do larger pixel size, but rather renders at the actual requested resolution.
Hi @nathanletwory
I am not sure I understood.
I used the same machine, viewport and screen. Granted the viewport had a slightly different size due to the different toolbars around it. Given this the time each cycle takes should be similar, shouldn’t it?
Where do you check the “requested resolution” of the viewport?
N
Most likely what happens is that in v6 Cycles elects to use a so-called pixelsize of 2 instead of the normal 1. This means that you effectively get a scaled up version of the rendering on your screen. If the viewport resolution is 800x600 then Raytraced effectively does 400x300, but blows it up to fit 800x600.
With Rhino WIP I haven’t brought that particular feature back yet, so Raytraced will be doing now actual 800x600. That is 4 times more work, translating into at least 4 times longer rendering time.
That said, for Rhino WIP you can install a denoiser, which should give you much quicker acceptable results in the viewport and with _Render command.
I will be bringing pixelsize=2 rendering back at some point though. Hopefully sooner rather than later.
Thanks.
Yes, I forgot about the denoiser I have to try it.
I’m relation to the cycles/time/pixel, os there the same difference between R6 and R7wip if you do ViewCaptureToFile? I also have the impression is slower in R7wip but I haven’t tested it carefully.
Thanks again, N
Maybe you could post the result of the Rhino command _SystemInfo, so I have a better understanding what you are working with.
Hi Nathan
Here is the system info result.
Rhino 7 SR0 2020-9-15 (Rhino WIP, 7.0.20259.15365, Git hash:master @ 7b653f7913cee10b2bd173435b93e0202bd2ae71)
License type: Commercial, build 2020-09-15
License details: Cloud Zoo
Expires on: 2020-10-30
Windows 10.0 SR0.0 or greater (Physical RAM: 16Gb)
Non-hybrid graphics.
Primary display and OpenGL: Intel® Iris® Graphics 540 (Intel) Memory: 1GB, Driver date: 10-11-2018 (M-D-Y). OpenGL Ver: 4.5.0 - Build 24.20.100.6299
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: Intel
Render version: 4.5
Shading Language: 4.50 - Build 24.20.100.6299
Driver Date: 10-11-2018
Driver Version: 24.20.100.6299
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 1 GB
Rhino plugins that do not ship with Rhino
Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7 WIP\Plug-ins\Commands.rhp “Commands” 7.0.20259.15365
C:\Program Files\Rhino 7 WIP\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7 WIP\Plug-ins\RPC.rhp “RPC”
C:\Program Files\Rhino 7 WIP\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.0.20259.15365
C:\Program Files\Rhino 7 WIP\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.0.20259.15365
C:\Program Files\Rhino 7 WIP\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 7 WIP\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7 WIP\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.0.20259.15365
C:\Program Files\Rhino 7 WIP\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.0.20259.15365
C:\Program Files\Rhino 7 WIP\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7 WIP\Plug-ins\Displacement.rhp “Displacement”
I can only think of the high DPI issue here to be at the root of the cause for slowness.
Hi Nathan,
I made a test with ViewCaptureToFile in R6 and R7. I tried the same model with 800x400 pixels and 100 passes. R6 took 2min 27sec, R7 took 10min 40sec. But that was not the surprising thing… or at least I was not expecting this result. R6 rendered the viewport with 800x400 px as expected, R7 seems to render a 800x400 px (partial) window of the viewport.
your machine is not up to the min specs for rhino.
I am not sure why there would be difference in resolution. At least I don’t see such difference here. Resolutions are the same between Rhino 6 and Rhino 7.
Hi Nathan,
Do you mean that you cannot replicate? ViewCaptureToFile renders the whole viewport? Can the Specs differences pointed by @theoutside justify the difference outcome in R6 and R7?
It seems that if I choose a custom resolution (I did it on command line) rhino 6 scales the whole viewport to that resolution, so it renders the whole viewport. However, Rhino 7 seems to render only the bottom left pixels of the viewport until the given resolution.
So I did a test with the 4 viewports tiled. The viewports are slightly smaller than the 400px height and indeed the ViewCaptureToFile catches the whole viewport and a bit more.
There’s also a strange difference if I use the other screen that is totally off.
Sorry these last points of ViewCaptureToFile, goes a away from the topic (which was about the raytracing time difference between R6 and R7), but it came up when testing the time difference of ViewCaptureToFile in R6 and R7.
Thanks, N
@nathanletwory
Any ideas on this?
N
No ideas yet. I haven’t been able to reproduce the reported behavior (render 1/4 of viewport) yet.
