Cycles - Edges bleeding

@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.

@FrankS Yes, well unfortunately, that issue is going to have to remain until I can figure out a way to correctly draw wires over the top of someone else’s results. In short, I can’t know how any given renderer is going to draw a material, which means if a renderer is going treat something as “transparent”, I have no way of knowing that…Now, I understand that the material’s “transparency” is something to look at, but that’s really just a hint and not a concrete description of what the final results will be… For example: IOR may exist, and therefore, just looking at transparency would only be part of the process.

Let’s get the other issues resolved first, and then we can start looking into “guessing” at what really should be drawn. :wink:

Here are the issues I’m currently tracking down that seem to cause bleeding…

  1. Locked layers
  2. Your custom surfaces
  3. Texture mapped surfaces with “Alpha transparency” checked.

The first two have workarounds…

  1. Simply unlock the layers…

  2. This one is a bit more involved, but has to do with “Picture Frame” objects. Apparently your custom people objects are really just picture frame objects that you’ve trimmed…The issue is that Rhino still sees them as “Picture Frame” objects, and thus they undergo special processing inside the pipeline…that special processing is what is causing issues in Raytraced modes. The workaround is to strip the objects of their “Picture Frame” status…To do this, select all of your custom objects, then run “Export Selected”. When the dialog box pops up, make sure you UNCHECK the option “Save plugin data”, then save them out to some file. Now either delete or hide all of your custom people objects and import the file you just exported. That will bring back all of your custom objects, but as standard trimmed surfaces and not as “Picture Frames”… However, now that they’re no longer a picture frame, all of their isos and edges will display… So you need to select all of them and use “SetObjectDisplayMode” and set them to use a display mode that does not show wires… I’ve provided a “RenderedNoWires” mode here for you to start with… This will make your people objects look and function exactly as they did before (in any display mode), but will eliminate the bleeding in Raytraced mode.

  3. This issue has no workaround (so far) but I’m looking into it and will let you know.

Let me know if you have any questions about #2 above… I’m not sure if my instructions will be clear enough.

RenderedNoWires.ini (11.3 KB)

How about a command like ConvertExtrusion Explode blocks and the like for PictureFrames?
Maybe name it ConvertPictureframe with options to keep display mode or not…


@Willem Sure… it may be that there is something like that already… I just don’t know…and the procedure I described above is the only way I know of atm to do this… Picture Frames simply have an internal user data tag hung off of them… and there may be some command(s) that exist today that allow you to strip user data directly from selected objects… I will check.


I think it’s best to have a straightforward way to convert PictureFrames with a dedicated command. Anything else will never reach the masses.

@jeff Not critical on your workaround suggestions, just an observation that the PF lack means to convert them.



Thanks for the detailed description!

I didn’t know _pictureframe objects represent a special category. For me pictureframes were simply a surface with a self-illumination texture, with a _setObjectDidplayModes attribute to make sure the display settings override the viewport specific settings.
To identify an obejcts nature of being, I consult the properties window. When I select a “pictureframe”, it says: “Surface”. Maybe this information should be more specific, as I had no idea pictureframe was a catagory.

Anyhow, I am glad to have learned something to help us work around the bleeding glitch in this scenario.
I will let you know if I find more bugs, related to this topic here.

Thanks again,

RH-42859 is fixed in the latest Service Release Candidate