Cycles - long load times before rendering

I am trying to understand what makes Cycles load slowly before rendering, I had some files that crashed so I tried a few things but I still don’t fully get it. I made a test file with less geometry and ran some tests, I post the results and my questions here.

First, my systeminfo:

Rhino 8 SR13 2024-11-12 (Rhino 8, 8.13.24317.13001, Git hash:master @ ca3666c3ebed2b9567e10930077bfa0884f65db9)
License type: Commercial, build 2024-11-12
License details: Cloud Zoo

Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 32GB)
.NET 7.0.0

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce RTX 3060 Ti (NVidia) Memory: 8GB, Driver date: 11-6-2024 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 566.14
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port 0

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
GPU Tessellation is: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

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

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 11-6-2024
Driver Version: 32.0.15.6614
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 8 GB

Rhino plugins that do not ship with Rhino
C:\Users\Administrator\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\SubstanceImporter\2.0.7\Substance.Win.rhp “SubstanceImporter” 2.0.7.0
C:\Program Files\Doliwa Workshop\Rhino Nature\Rhino Nature.rhp “Rhino Nature” 1.0.4.16355

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.13.24317.13001
C:\Program Files\Rhino 8\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\Calc.rhp “Calc”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”
C:\Users\Administrator\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\PanelingTools\2024.8.20.677\PanelingTools.rhp “PanelingTools”

I took one part of one of my models and ran 4 tests on it. I am trying to understand if adding textures is the problem or if it is something with PBR materials.

The first test is using just the surfaces with a default material, it took 3 seconds to load the render window and 1.5 seconds to render at 50 samples.

The second test is using the same surfaces but with a PBR material. It took 17 seconds for the render window to open and 1 min and 50 seconds to process geometry tree and start rendering. The rendering took 2.89 seconds at 50 samples.

The third test is using just one of the surfaces with the same PBR material. It took 3 seconds to load the render window, almost no time to process the geometry tree and 0.72 seconds to render at 50 samples.

The fourth test I tried to mesh before but the results were the same as the second test.

I am trying to understand if there is a problem with my system or file or something I do or if this is normal. If this is normal why is it so? Why can blender start the cycles render instantly in the same scenario? Blender also has load times before rendering to load meshes and textures but on the same PC this geometry with these textures would load instantly.

What exactly handling adds/edits mesh instances do? That seems to take the longest before the render starts.

I am interested to find out more about what to do and what not to do when using Cycles in Rhino so I don’t crash it and also to understand the differences between Cycles in Rhino and Cycles in Blender (if there are some clear limitations to bear in mind, I understand and accept the ones about nodes, mixed shaders… I am more interested in speed and handling geometry and textures).

Thank you!
Mircea[grid]





[/grid]
Test File.rar (10.5 MB)

Here that file starts to render almost right away. So, no that is not normal. I don’t see anything in your systeminfo that looks suspicious.

1 Like

Try disabling these, restart Rhino and see if it makes any difference.

1 Like

Thank you for your replies

I disabled the plugins and even uninstalled them, no difference.

I am still trying to understand what “Handling adds/edits mesh instances” does and why it takes much longer if materials are applied (bump?, roughness map?) Is there something specific that adds a lot of time? Maybe UV mapping?. Blocks don’t seem to help either, if I have multiple identical blocks they are counted separately and add to the computing time.

You can see in my attached screenshots that handling took about 1 min 45 seconds for about 800 rectangular meshes. The render time is 3.76 seconds only.

I tried another thing and joined the 800 or so meshes into one mesh. You can see the screenshot for that also, only 2 seconds to handle just one mesh and 1.86 seconds to render. :))) So I wonder why I cannot render so fast if I don’t mesh and join the meshes. Maybe something about mapping that needs to be calculated separately?

I am an architect so maybe my understanding of software is a bit crude but any explanation that would make rendering directly in Rhino more efficient would be greatly appreciated.

It might seem weird that I try to get it too fast and that 1 minute 50 is not fast enough but fast switching between shaded and raytraced would help a lot during the development of projects.

Thank you!
Mircea

Well Gijs has said he doesn’t see the delay, so “why” to any of this is the question they’re trying to figure out, something odd is going on. It generally takes some time because every single thing in the scene is being copied to the video card.

1 Like

This particular test file starts and renders in the viewport in about 1 second on both my Windows desktop an Macbook Pro. I test the viewport because that cuts out any time “lost” by Rhino constructing the render window and focus exactly on the time RhinoCycles needs from switch to Raytraced to first pixel on the screen.

Blender != Rhino. The Cycles integration in Rhino, RhinoCycles, has to jump through hoops to get the data out of Rhino into Cycles, between unmanaged code (C++) and managed code (.NET)

From Rhino 8.13 onwards data processing has been parallelized more, but still isn’t fully parallelized as can be. Mesh instances equates pretty much to object count. If you have thousands, or tens of thousands of objects in Rhino this will take some time.

If you want to optimize startup times then often it is useful to extract render meshes and then join them based on material. If you have a thousand objects with the same material going to one object to load is much faster…

FWIW any perceived slow start times != crashing Rhino. Before this you haven’t mentioned crashing. Crashing Rhino is when the program disappears, potentially with an error message, and has to be started again.

Anyway, if you like digging into logs then you can set the advanced option (Tools > Options > Advanced) RhinoCycles.VerboseLogging to true, restart Rhino and switch a viewport to Raytraced. When done with rendering in the viewport run the hidden command RhinoCyclesShowLog and check the log :slight_smile: Share a log of a couple of Rayraced or Rhino Render runs in one Rhino session here and we can go through it.

1 Like

Thank you! I tried creating single mesh objects based on materials and that works very well, instant loading for 80,000 faces. I will probably need to reinstall Rhino, if you and Gijs could both start the render in 1 second even for the 840 or so separate surfaces with the added material but on my end its slow on two different PCs something might be wrong here. I am still puzzled as to why 840 surfaces with a default material load instantly but 840 surfaces with an added material load in 1 min 30 seconds, it is as if the texture is not loaded only once, the same thing happens for blocks, but again that is maybe happening only on my system.

Instead of reinstalling it should be enough to do a repair. Windows > Apps > Rhino > Modify > Repair.

1 Like

I got two logs out from the same file initially attached to this thread. The first log is for the 840 surfaces with the wood material and the second is for the same surfaces with the default material.

I am very curious to what those two logs tell you, maybe they show the culprit :smiley:

Thank you!
Mircea

second log - default material.txt (969.0 KB)
first log - wood material.txt (977.4 KB)

The logs indeed show a longer startup time in the first one. Rhino appears to be taking its time before passing on the data to RhinoCycles, 15 seconds. The handling of the data also appears to be taking longer then necessary.

The test file takes around 2.7 GB of RAM when switching to Raytraced. GPU VRAM it is using ~3.8GB. I wonder if the slowdowns you are seeing are potentially due to your system having to swap memory to disk. Do you have many other applications open at the same time? What is typically RAM usage on your system before you switch to Raytraced? And GPU memory utilization?

1 Like

I think I found the culprit. Your question about RAM made me think about the other PC, I told you I could replicate the same problem on another PC, and that has an RTX with 16GB of VRAM so I thought it couldn’t be the VRAM but they have something else in common … I use Google Drive and have my library of textures there.

I made another test now, for the 840 surfaces with the wood material I made another identical material but copied the texture files to Desktop. The total time including loading and rendering went from 1 min 55 seconds to 24 seconds.

Maybe it should have been obvious to me. Thank you very much for your time.

Mircea

1 Like