Cycles - Edges bleeding

Hi @nathanletwory,

I installed the latest WIP (6.0.17136.10381, 16.05.2017) and installed a new GTX1080 GPU.

As you can see from the first screenshot, the surface edges are bleeding through objects in the foreground.
As this behavior disappears with the zoom level / camera position, I consider this a bug that I hereby would like to report :slight_smile:

Also, this behavior doesn’t show in any other display mode.

Any trick to cure this?

Hi Frank- is it in Raytraced only that you see this? Rendered mode ok, for instance?


Raytraced doesn’t draw any edges, that is done by the Rhino display pipeline. It looks like a depth test goes wrong.

Hi Pascal,
All other display modes (Shaded, ghosted, rendered, …) are ok.
This issue only occurs in cycles.

Hi @pascal and @nathanletwory,

The issue is still there and unfortunately disqualifies cycles for producing simple presentation renderings.
(Since we got used to raytraced + edges look so much)

Here is another example of a recent project done in the most recent Rhino V6 built. (BETA 6.0.18012.13241, 12.01.2018)

As you can see on several locations, lines (edges) are bleeding through the furniture.

The same image in rendered view does not show these glitches.

If this is not an issue of the cycles pipeline but of the rhino display pipeline, you might want to kindly ask @jeff to have a look into this :slight_smile:

Would be great to have a fix for this soon!
Thanks for your effort!

@FrankS, this is indeed the underlying OpenGL pipeline that does the line drawing.

This is already reported as

@FrankS I was just looking at this yesterday…unfortunately, I can’t seem to reproduce the problem with the models I have here… I kicked it back to @jessesn to see if there was a model that could be attached to the bug report.

If you have an example (that you can part with), then I would really like to have it… The underlying OpenGL pipeline is drawing the lines yes, but the way it’s being done for Raytraced mode is nowhere near how it’s done for standard view modes…and obviously there’s a glitch in the way it is doing things…and I really need an example that shows the problem repeatedly in order to track it down.


@FrankS Are the objects that are “bleeding-thru” mesh objects or NURBS surfaces?


I finally found a model that shows the problem (sort of)…hopefully it’s enough to track it down… I’ll keep you posted.


@FrankS Can you check something for me… Can you see if any of the objects that are bleeding through are on layers that are locked? If so, what happens if/when you unlock the layer(s)?


I see that happen with a box on a locked layer behind another box. When locked the hidden box surface edges show through. They get properly culled when the layer is unlocked.

Yep, that’s what I’m seeing too…but I’d like @FrankS to confirm that’s what’s happening on his system as well…otherwise, all I’ve done is find another bug :slight_smile:


1 Like

Hi @jeff and @nathanletwory,

Thanks for your engagement!
I will try to answer your questions and help with files etc.

All NURBS surfaces, no meshes involved.

I can confirm that in the file from which I took the screenshots above, all bleeding through glitches disappear when I unlock the layer with the objects that cause the bleeding.
I can confirm this behaviour in other files too.

But, …
I set up an additional simple test file. It shows the bleeding through glitch independent from locked/unlocked layers status.

Maybe the guy in the picture is a special case, as all other objects seem to behave correctly. The guy is a single trimmed surface, with texture, self-illuminating, dense outline w/ high control point count.

I will try to find other examples. Meanwhile we can figure out what makes this guy so special :wink:

Cycles_Bleeding_BugCase_01.3dm (7.4 MB)

While @jeff figures out why this draws like it does I’d like to ask if there is a reason why you don’t use a simple plane with an image that has an alpha channel on it. That would be much better also for display performance. The guy you posted is 753 triangles, where it could do with just 2. In simple scenes with only few cardboard people it doesn’t matter much, but when you add hundreds or thousands it will.

cycles_edges_showing_bug.3dm (3.5 MB)

@jeff, with attached file when you set the material to not use Alpha Transparency in its Advanced Settings the box edges show through when the plane with material is selected.

Hi Nathan,

I agree that °in theory° the alpha channel approach would be much preferred.
It is years ago that we created this set of human silhouettes for use in your office, but I remember that there was something not working correctly with alpha channel based transparency. Admitted that we might have used not so straight-forward configuration of tweaking the display modes (custom display modes, _SetObjectDisplayMode, … ), the results were not always robust. So we decided to go for a robust method: trimmed surface with texture. The method has proven to be robust over the last years.

Problems with the alpha channel approach:
I remember the transparent area of the textured plane producing undesired effects, i think especially if it was in front of or in between other transparent objects. (like seeing through objects, that are not transparent, eliminating the display of object edges behind the alpha object, …)

Maybe I can reproduce that. I will check and get back.

Feel free to continue using your custom-made people :slight_smile: I was just wondering, but capitalizing on assets you created long ago is always good. The performance hit is not that bad, it will become a potential bottleneck only when you add huge crowds - and even then you can use block instances to mitigate at least the memory pressure problem.

I believe all of these issues have been fixed in V6… Alpha channeling and transparency mapping should now work as expected in V6…and if it doesn’t, please let us know and we’ll fix it asap.


@FrankS Note: I’m not suggesting that alpha channeling will work as a solution for your workflow and needs, since no kind of mapping tricks will be a better solution or substitute than pure geometry… I’m just pointing out that many “alpha channel” and “transparency” issues have been resolved in V6, so if you see something that you think doesn’t look correct or not what you expected, please report it.


OK, cool!. That’s good to know.
We will use alpha channel based-transparency in the future, try and report if needed. Thanks for the clarification.

Coming back to the original issue, pls find the attached screenshot and test file below. Still bleeding :wink: … in both cases. No locked layers involved.
Any hints, tricks, workarounds or fixes?

Cycles_Bleeding_BugCase_02.3dm (10.5 MB)

I found a related issue.
Not strictly bleeding is the problem here, more that edges seem to ignore semi-transparent objects (e.g. glass).

  • In Rendered mode, the edges seem to be drawn behind glass which makes them less dominant.
  • In Raytraced mode, the edges seem to be drawn in front glass. They are visually as present as if they weren’t behind something. → The visual result is irritating.

Call it bleeding or not, it seems related to the primary issue as it seems to have something to do with the drawing order.

Pls find attached to screenshots:

  • Rendered
  • Raytraced

Pls check to glass showcases.