V8 material editor slow

Hi McNeel
It seems like the V8 material editor is just sluggish and… slow. Simple things like changing materials names and, well, actually just changing from one materials to another in the list makes the whole thing grind to a - brief, but noticeable - hold. We are not talking several seconds, but just this really brief lag, that will cause my flow to break; super annoying! Am I the only one seeing this?


Rhino 8 SR5 2024-2-14 (Rhino 8, 8.5.24045.19001, Git hash:master @ de27eef23abd767f7a85b8f4858b28e5dc50338e)
License type: Evaluation, build 2024-02-14
License details: Cloud Zoo
Expires on: 2024-03-07

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

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA Quadro RTX 4000 (NVidia) Memory: 8GB, Driver date: 10-18-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 537.70
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port 0
- Secondary monitor attached to adapter port 1

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: 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: 10-18-2023
Driver Version:
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

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 8\Plug-ins\SolidTools.rhp “SolidTools”
C:\Program Files\Rhino 8\Plug-ins\Commands.rhp “Commands” 8.5.24045.19001
C:\Program Files\Rhino 8\Plug-ins\WebBrowser.rhp “WebBrowser”
C:\Program Files\Rhino 8\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 8\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 8\Plug-ins\IdleProcessor.rhp “IdleProcessor”
C:\Program Files\Rhino 8\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 8.5.24045.19001
C:\Program Files\Rhino 8\Plug-ins\RhinoRender.rhp “Legacy Rhino Render”
C:\Program Files\Rhino 8\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 8.5.24045.19001
C:\Program Files\Rhino 8\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 8\Plug-ins\MeshCommands.rhp “MeshCommands” 8.5.24045.19001
C:\Program Files\Rhino 8\Plug-ins\IronPython\RhinoDLR_Python.rhp “IronPython” 8.5.24045.19001
C:\Program Files\Rhino 8\Plug-ins\RhinoCycles.rhp “RhinoCycles” 8.5.24045.19001
C:\Program Files\Rhino 8\Plug-ins\RhinoCode\RhinoCodePlugin.rhp “RhinoCodePlugin” 8.5.24045.19001
C:\Program Files\Rhino 8\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 8.5.24045.19001
C:\Program Files\Rhino 8\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 8\Plug-ins\SectionTools.rhp “SectionTools”
C:\Users\jn\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\PanelingTools\2021.3.2.446\PanelingTools.rhp “PanelingTools”

I guess I need a bit more information. Does this happen in any file, say you make a fresh new file and 10 materials? How many materials do you have in the material editor?

Are you using the material in Grid view, List view or Tree view?
Did you just install Rhino 8 SR5 when you experienced this slowness? After a new install, shaders need to be recompiled and this can slow down things until that process is complete.

Hi @Gijs
Sorry for being so light on the details. As mentioned, it’s not really slow… just… a little laggy ! I haven’t been using V8 much for production work, but on and off during the the whole WIP cycle, and I reckon it’s been there for a while, but not too sure. I’m just getting started on V8 “for real”, and just thought I’d hear if anyone else was seeing the same thing.
I’m always working in Tree view. Actually just tried List and Grid and both seem more responsive - weird! Maybe it actually had something to do with the shaders recompiling. I’ll test further and let you know, but right now most of my cores are busy rendering (Keyshot), so for now everything is laggy :joy: Hopefully I can give you something more substantial to go by. Usually I’ve got no more than 10-15 materials, but sometimes with a slew of 4K textures in there. I’ll see if I can find you a file that seems laggy to me. As always, thanks for responding :slight_smile:

Thanks, I do see some performance issue with a rather large file (in terms of amount of materials) which I just logged.

It seems that v8.5 materials are laggy compared to v8.4 and earlier. I’m working in a large-ish file at 75mb containing 65 materials. One of them uses a 2.6mb texture file. If I change the number repeats in mapping, I get the spinning beach ball for about 3 seconds.

hi @John_Williams I am just trying this in a larger file with more materials on a larger texture (approx. 13000 x 2300) and dragging is slightly slower on that size, but I don’t get any spinning beach ball.
Can you send me your _SystemInfo?
If you have a file that shows this behavior it would be helpful to send that in for inspection, thanks

Here’s sys info. How shall I submit project file (75mb)?

Rhino 8 SR5 2024-2-13 (Rhino 8, 8.5.24044.18002, Git hash:master @ 3070dad8e8cced9e1b333ad92cd445f22730c23e)
License type: Commercial, build 2024-02-13
License details: Cloud Zoo

Apple macOS Version 14.1.2 (Build 23B92) (Physical RAM: 64GB)
Mac Model Identifier: MacBookPro18,2
Language: en-US (MacOS default)
.NET 7.0.0

Metal GPU Family Apple 7
Metal GPU Family Common 3
Metal GPU Family Mac 2
Graphics processors
Apple M1 Max
Thunderbolt Display (2560 x 1440 @ 60.00Hz)
Color LCD (1728 x 1117 @ 120.00Hz)
LED Cinema Display (2560 x 1440 @ 60.00Hz)

USB devices
Logitech: USB Receiver
Apple Inc.: Apple Thunderbolt Display
Apple Inc.: FaceTime HD Camera (Display)
Apple Inc.: Display Audio
Apple, Inc: Apple Keyboard
SanDisk: Cruzer Snap

Bluetooth devices

Third party kernel extensions

Third party plugins
/Users/johnwilliams/Library/Application Support/McNeel/Rhinoceros/8.0/MacPlugIns/bella_rhino.rhp/libbella_dotnet_native.dylib

Rhino plugins that do not ship with Rhino
/Users/johnwilliams/Library/Application Support/McNeel/Rhinoceros/8.0/MacPlugIns/bella_rhino.rhp “Bella”

Rhino plugins that ship with Rhino
/Applications/Rhino 8.app/Contents/Frameworks/RhMaterialEditor.framework “Renderer Development Kit” 8.5.24044.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Commands.rhp “Commands” 8.5.24044.18002
/Applications/Rhino 8.app/Contents/PlugIns/NamedSnapshots.rhp “Snapshots” 8.5.24044.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RDK_EtoUI.rhp “RDK_EtoUI” 8.5.24044.18002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/MeshCommands.rhp “MeshCommands” 8.5.24044.18002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoRenderCycles.rhp “Rhino Render” 8.5.24044.18002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCycles.rhp “RhinoCycles” 8.5.24044.18002
/Applications/Rhino 8.app/Contents/PlugIns/AnimationTools.rhp “AnimationTools” 8.5.24044.1002
/Applications/Rhino 8.app/Contents/PlugIns/SectionTools.rhp “SectionTools” 8.5.24044.1002
/Applications/Rhino 8.app/Contents/PlugIns/RhinoRender.rhp “Legacy Rhino Render” 8.5.24044.1002
/Applications/Rhino 8.app/Contents/PlugIns/RhinoLabsTools.rhp “Rhino Labs Tools” 8.5.24044.1002
/Applications/Rhino 8.app/Contents/PlugIns/Displacement.rhp “Displacement” 8.5.24044.1002
/Applications/Rhino 8.app/Contents/PlugIns/PanelingTools.rhp “PanelingTools” 8.5.24044.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoDLR_Python.rhp “IronPython” 8.5.24044.18002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/GrasshopperPlugin.rhp “Grasshopper” 8.5.24044.18002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCodePlugin.rhp “RhinoCodePlugin” 8.5.24044.18002

@John_Williams you can upload a file here


here is a model with two cubes, a few materials & textures, rendering in SR4 raytraced with a small 1024x1024 noise texture:

rendercontent-slowness.3dm (1.7 MB)
systeminfo.txt (2.4 KB)

this is on a 5950x so there is plenty of cpu available, and while I am changing a texture parameter, the whole cpu goes to 100%, so I have no idea how people use this it at all with a less powerful cpu


same on mac, that part is barely usable… but ok i must be used to it already, anything texture related was always super slow, but then again in v8 it became even slower :frowning:

I am not sure but if you collapse the Graph section, does it then improve the responsiveness? And I also noticed that the Tree view is slower than list/grid.

Same using the above example file on a 13700K.
Closing graph view didn’t seem to make any difference. This is 8.5.24037.14001.

It’s a bit strange, when you use the slider just before the Raytraced starts on the CPU, you can move it easily it seems, and then once raytraced starts, the lag begins and sometimes gets a bit worse until a plataeu of badness.

the graph is closed in my example

as a user, I always use the tree because grid/list views are not useful for materials that link to textures and such, you are always clicking through links to get anywhere, or trying to use the breadcrumbs

according to what I see writing a render plugin that has a lot of render content classes, this is showing a general problem with the render content system, and as encephalon says, it has always been sluggish, but without sliders to grab and move interactively in v6/7, it was hidden a bit

to explain why I think this, I’ll show a specific example using my plugin

I carefully avoid touching RenderContent from code until absolutely necessary, pushing interactive changes directly to my viewport renderer, and only committing data to the render content (i.e. calling RenderContent.EndChange) when the user finally releases a slider

one out of, say 5 or 10 times, when EndChange is called, rhino sits thinking for up to several seconds

in this video, EndChange is only being called when releasing a slider

this could be helped by choosing some value other than ChangeContexts.UI when calling BeginChange, but these are indeed UI changes, and using another value would break other things (hard to remember exactly what, as it was a long time ago that I experimented)

I have commented out all my undo-related code and don’t support undo in my render content, to avoid even more long pauses of rhino

I have added plugin preferences that say “don’t render material previews if preview size is less than x” and “don’t render material previews at all”, to let people control whether they get N instances of my renderer being spun up just to update thumbnails

these are the types of things I do to try to avoid the general sluggishness we are seeing in this thread


This is true, the old numeric steppers changed the value once compared to the sliders that change the value a lot of times causing the lag. So the problem was not as visible as it is today. However I still think we have a lot of places to optimise and one is the graph section. I will try to identify them all and I think we can make it better by fixing them one by one. How good it will get I cannot say, but not worse.


added RH-80446 Color adjustment slider: give preference to the UI interaction
as a start and will test/log other sliders where necessary.


@maxsoder – digging further into this, I have pinpointed what appears to be the main cause of lag issues shown in my previous screen recording, and it is texture generation

here I have instrumented when my plugin is asked to provide a texture evaluator, the setup for that (the CreateEvaluator, CopyToNode, and nodePrep lines), its constructor (the create texture evaluator N for output name lines), and dispose, and we can see that sometimes, rhino locks up between the evaluator’s constructor, and when it is disposed

as before, what you are seeing is attribute changes being sent directly to my renderer as a slider is moved, followed by a single BeginChange/EndChange being called on the render content, when the slider is released; I have toyed with using ChangeContexts.Program instead of ChangeContexts.UI and it seems to make some difference (we are seeing ChangeContexts.UI above), but ultimately does not avoid the issue

I am able to avoid the issue by returning null from RenderTexture.CreateEvaluator instead of an actual texture evaluator, and will be temporarily adding a global plugin setting to allow users to disable texture previews by that method

my texture evaluator is very fast (it is the same code used at render time in bella, at every ray impact), but to avoid there being any question about it, in the video above I have completely replaced the evaluator code with just returning a magenta Color4f, which can be seen in the 4th material preview in the list

this looks to me like a threading issue, with some mutex trying to be locked with a timeout, or similar

4 posts were split to a new topic: Slow performance on imported obj that has no texture coordinates

That seems to be my same issue:

I have problem with just one object due my old pc, but Rhino answer is the same.

I have partially solved restarting raytracing after rendering from the bottom bar and thanks to Nathan advices, but looking at your System compares mine there seems to be more.


Your is a Mac, mine is a PC