Reduce Mesh Dialog Missing Inputs

It appears that in the SR27 of Rhino 6 (latest at time of writing) the numerical inputs of the Reduce Mesh dialog box are missing. I have confirmed this to be the case on 2 separate PCs so it is unlikely to be an installation issue but happy to try any suggestions to revert settings that might be affecting this display.

Main PC is a Windows 10 1909 desktop.



I’m not seeing that here in an newer, in-house build, even in a very simple starting mesh wish so few facets.

Maybe try the Service Release Candidate.

Thanks for the very quick response @John_Brock
That has unfortunately gone poorly. Getting this window when trying to open Rhino in both normal mode and safe mode.
I’ve never run the Service Release Candidates before so not sure if that is to be expected but happy to open another thread for that if that’s the right thing to do or give additional information here.

Edit: Complete uninstall and reinstall of the SRC fixed this new issue but not the UI issue. The below is from the SRC:

That’s a separate issue with Windows updating.

The developers tell me this is because the Windows .NET tools on that computer are damaged.
Go into Windows Control Panel, Programs and Features, “Turn Windows features on or off”
Find the .NET Framework 4.8 tools and run a Repair on them.

Or run this installer:

That should get you sorted.

Any luck?

.NET Framework seems to be happy and, as in my edit above, a clean install of the RC fixed the issue with Rhino not wanting to load. However I can’t see any improvement on the display issue in the Reduce Mesh Options dialog. Is there any way I can provide more information to try and find the source of the issue?


Below is my full system info:

Rhino 6 SR28 2020-6-23 (Rhino 6, 6.28.20175.14591, Git hash:master @ 9ddbd1399e001a3eae701470332b5379477fa7d6)
License type: Not For Resale Lab, build 2020-06-23
License details: Cloud Zoo.  In use by: Sebastian Andraos (HAL Robotics)

Windows 10.0 SR0.0 or greater (Physical RAM: 24Gb)
Machine name: DESKTOP-AF5HO6P

Non-hybrid graphics.
Primary display and OpenGL: NVIDIA GeForce GTX 1660 SUPER (NVidia) Memory: 6GB, Driver date: 10-22-2019 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 441.08

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: 10-22-2019
  Driver Version:
  Maximum Texture size: 32768 x 32768
  Z-Buffer depth: 24 bits
  Maximum Viewport size: 32768 x 32768
  Total Video Memory: 6 GB

Rhino plugins
  C:\Program Files\Rhino 6\Plug-ins\Commands.rhp	"Commands"	6.28.20175.14591
  C:\Program Files\Rhino 6\Plug-ins\WebBrowser.rhp	"WebBrowser"	
  C:\Program Files\Rhino 6\Plug-ins\rdk.rhp	"Renderer Development Kit"	
  C:\Program Files\Rhino 6\Plug-ins\RhinoScript.rhp	"RhinoScript"	
  C:\Program Files\Rhino 6\Plug-ins\IdleProcessor.rhp	"IdleProcessor"	
  C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp	"Rhino Render"	
  C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp	"RDK_EtoUI"	6.28.20175.14591
  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\Alerter.rhp	"Alerter"	
  C:\Program Files\Rhino 6\Plug-ins\IronPython\RhinoDLR_Python.rhp	"IronPython"	6.28.20175.14591
  C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp	"RhinoCycles"	6.28.20175.14591
  C:\Program Files\Rhino 6\Plug-ins\Grasshopper\GrasshopperPlugin.rhp	"Grasshopper"	6.28.20175.14591
  C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp	"Toolbars"	6.28.20175.14591
  C:\Program Files\Rhino 6\Plug-ins\3dxrhino.rhp	"3Dconnexion 3D Mouse"	
  C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp	"Displacement"	

You could try the current display driver:

Any luck?

Unfortunately not. I just updated to SR27 on my Surface Book 2 (as it has access to an Nvidia GPU and Intel graphics) but the issue persists there regardless of the display driver in use.

Hi John,
We are working with Sebastian on a plugin making extensive use of WPF, and I just tested a hint: the bug only seem to appear when our plugin is loaded, so it is probably something like an implicit style or template being used on your numeric up/down controls instead of an explicit one. I just verified with the rhino options menu and they work properly, so since I don’t know the Rhino source code, my best bet is that the ReduceMesh dialog styling is implemented a bit too loosely.

Sorry, I can’t help with this.
Maybe this should be over in the Developer category.

Hi John,

Is that topic move something you can do, or do we need to request it from our end?


@curtisw, is there any wisdom you can provide here?

Only other thing I can think of that could be causing this is a conflicting version of Xceed.Wpf.Toolkit.dll being loaded from a plugin, or custom WPF styles being applied that conflict with the above. The latest version(s) of Rhino use Xceed.Wpf.Toolkit.dll v3.6.0, but is not always loaded right away. So, if a plugin loads their version first it could conflict with what Rhino requires.

The complication is Rhino has special code that ensures only a single version of a DLL is loaded, regardless of major versions of strong named assemblies (basically a binding redirect to the version included with Rhino). Any plugins that use WPF would probably need to keep their version of the above assembly in sync with what Rhino uses.

It might be a good idea to uninstall any 3rd party plugins to see if that makes a difference to narrow this problem down.

Dear Curtis, thank you for your input and apologies for this late follow up.
Following your suggestion I tried a few things to force WPF Toolkit to load the WPF toolkit types explicitly, and the solution was to replace the default




where Xxxxxxx is replaced by the real namespace of the target resource (cf. the WPF toolkit source).

I did this for all xmlns calls that I had in both controls and resource dictionaries and it seems to have fixed the issue, so we will distribute this fix in the next update.

I am posting the solution here as it might help other plugin developers, and you might as well be interested to use this trick to avoid ambiguities.

Best regards,