Graphic bugs in rhino 6

Hi all.
I have some graphic bug in rhino 6, in last service release as same as in last service release candidate.

Lines, like grid, curves or edges are everywhere “1.1x wider than normal”, so they not appear correctly thin as they should.
The normal wireframe rendering i’m used to is that every cuve is just 1 pixel wide (with AA off), here in RH6 i have almost every curve displayed somehow “dirty”.
Also i’ve found the “Focal blur” menu is blurred! … how ironic XD
See attached .gif to understand.
If I active GPU tessellation the problem is somehow more evident, or the same.

Here is my system info:

Rhino 6 SR4 2018-4-10 (Rhino 6, 6.4.18100.1591, Git hash:master @ b6485d60ae29d5ee76751120dc9232f8b172e934)
Licence type: Commerciale, build 2018-04-10
License details: Cloud Zoo. In use by: Riccardo Majewski ()

Windows 10.0 SR0.0 or greater (Physical RAM: 16Gb)
Machine name: SHARKOON-AMD

Radeon RX 580 Series (OpenGL ver:4.5.13497 Compatibility Profile Context 23.20.788.0)

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

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

Vendor Name: ATI Technologies Inc.
Render version: 4.5
Shading Language: 4.50
Driver Date: 11-2-2017
Driver Version: 23.20.788.0
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 8 GB

C:\Program Files\Rhino 6\Plug-ins\Commands.rhp “Commands”
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”
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\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 don’t know if it matter, my cpu is ryzen 1800x.

Just bought licence… hoping in a fix.

Thanks everybody for the support.


I can’t edit the main post because i get an error “The tag “unhandled” may only be removed by staff.”
Sorry for the bad layout…

Here is the difference in curve rendering.
See how RH5 is exactly 1 pixel wide… like, an absolute minimal perimeter needed to “contain” the bucket command in paint… in the RH6 version there are more, ugly and unneeded pixels.

You have no anti-aliasing enabled. You probably need to go into Tools > Options > Views > OpenGL and set some anti-aliasing.

1 Like

As you can see in the .png it is not antialiasing because its not grey-scale pixels, those are completely black(0,0,0).
Antialiasing is disabled in both RH5 and RH6, as I want it to be.

( I can’t work properly with AA on, I’ll lose a lot of useful details. In fact i think AA for cad is just dumb… but more generally, AA is a smoothing that fakes the shapes, i prefer to see original clean and sharp shapes. )

In RH5 wireframe mode render curves/edges/grid flawlessly with AA off.

EDIT: i didn’t explain well what happen in the .gif. Other than that “dirty” curves rendering, the axes and the grid line at 0 (horizontal to view) change it thickness ±1 pixel, its not an error of the .gif, sometimes it really go 2x (the axys) or disappear (the grid).

EDIT 2: also the “Make 2D” form/window have all elements blurred out as the “Focus Blur” shown in the .gif .

EDIT 3: also the selection window
The problem is only for horizontal lines. It’s like the pixel are not rendered 1:1 but something like 1:1.001 .
RH5 is fine in this matter too.

Edit 4: it happens in both, horizontal and vertical lines (just horizontal for the selection window tough).
Here i’m just zooming out:
Orthogonal lines should never be 2pixel wide…
(I tried and, even with AA on the effect is washed away somehow, but still visible)

The fastest way to see if the problem i’m having occur is to see if a circle is “clean” or not.

Sorry for the spam, I hope it helps.

Up? Any hope?
In wireframe mode i can set windows pipeline instead of openGL and that fix the problem, but i cant set the same for all the other modes.

Up again?

I’ve logged it under RH-46636.

At every update i hope it’s fixed, working with AA on make everything blurred, feels like… “imprecision” everywhere. And even AA can’t hide the problem, actually it make it randomly worse for orthogonal lines:

Any news for this?

Hello - it looks like the bug report above is ‘in progress’ currently.


Hi @maje90 ,

This should be fixed in the SR8 release candidate that we released yesterday.

Hi @stevebaer,

It is still there, also I don’t see RH-46636 mentioned in that Serengeti post.

I take the opportunity to explain once more “what” and “why”.
(I don’t want to be pedant, I just want to be sure the situation is clear… RH6 is lovely perfect already)

(Antialias OFF)

(pic explain itself better at 100% zoom)

Blue are 2 identical curves overlapped.
Black is a curve overlapped with a rebuilt version (500 points!)

In rhino 5 you can easly spot that: with a fast glance you can understand blue is “ok” but black are 2 (or more) non-identical curve overlapping, because of the “dirty” pixel width of the black curve.

In rhino 6 you can’t do that, both (blue and black) curves appears to be “dirty” all the time.
Even lines!

This is a single line in rhino 6:
(AA off)

Hi Riccardo,
I was focused on purely vertical and horizontal lines as those need to get special cased to land exactly on pixel centers to look their best. I’ll check out the other cases that you mention in your most recent post.

@maje90 it would be great if you could test the latest build of the day to see if things look better

Make sure to have the WireThicknessScale set to it’s default value of 1


I’ve tested that .exe in 3 different machines and I had the same results:
No change.

Single straight line, top view, AA off, testWireThicknessScale=1, (GPU tessellation on/off is the same to me)

Changing “testWireThicknessScale” doesn’t do any good, curves start to being disjoined, pixels missing.
Below 1 works only if GPU tessellation is ON, otherwise any value do the same as 1…

I was playing around and…
I’ve “found” this:
(you can see differences in thickness even here in the 45° tilted square :\ … )
Each pixel should turn “on” only when the curve touch the internal dual square of the pixel itself.

and so:
pixel (13.2 KB)

Probably this “rendering” is a completely different stuff from a low level openGL rendering… it’s insanely heavy for just a curve…
This is just to see how i think it should be the final appearance (like in rhino 5).

RH-46636 is fixed in the latest Service Release Candidate

Tried (6.8.18219.371, 07/08/2018) on 2 different machines: to me the problem is still there.
AA=off, straight lines have inconsistent width. An so all the other curves (grid lines too).
(testWireThicknessScale=1 but also any other value doesn’t help)

Did you refer to this release or another incoming?

Is this still in list?
It was said as “fixed” but both 6.8 and 6.9 didn’t solve it.
It is still there.

Please try the SR11 release candidate. Turn off GPU tessellation and run “TestLineSmoothing”. This uses the GPU line drawing routines for 1 pixel wide wires.

SR11 (6.11.18310.7201, 06/11/2018), same result on 2 different machines:

TestLineSmoothing enabled
still “dirty”; every orthogonal line can randomly be rendered wider while zooming (or moving/scaling the curve), or it is always wider if you just draw it.

With TestLineSmoothing disabled orthogonal lines are ok … but inclined lines and curves are still “dirty”.

… Can you guys replicate this or it is just me?

Are you testing with GPU tessellation off ? Also make sure that all of the lines are a single pixel. I was hoping to see something different, but it doesn’t look like this is helping your situation