Cycles Clipping Plane rendering Bug

Hi Nathan,

I think I am seeing a new type oy clipping plane bug with cycles. The following model is clipped with a clipping plane, no open edges in the breps or meshes clipped.

In rendered display, they clip as expected (image 1). When using cycles’ Raytraced display style (image 2) or when rendering with cycles (image 3), the clipped surfaces are open.

Thanks - Silvan

NVIDIA Corporation
Quadro RTX 3000/PCIe/SSE2
OpenGL version: 4.6.0 NVIDIA 471.68
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 8-5-2021
Driver Version:

Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24bits
Stencil depth: 8bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 6 GB

That is indeed how it is currently implemented, and not a bug per se.

For v8 we might change this.

Hi @nathanletwory
Or if Cycles could at least pay attention to the Luminosity slider in the custom backface material. Right now it doesn’t have any effect at all - the backfaces are still “shadowed”.


1 Like

@nathanletwory thanks for your quick response.

Is there any chance you might change this already for a Rhino 7 SR? We wanted to switch to Cycles, but this is a game stopper for us.

This implementation is different to what most people are used to see from other software when clipping. When one sees only the rendering, they would assume those solid breps are open breps, which is misleading.

From an architecture point of view, a section through a solid always has to have a section face, otherwise it completely changes the meaning of what is displayed.


Hi Silvano -

I’ve added your comments to item RH-58658. That one is currently on the `Future´ list. Perhaps it will be considered for Rhino 8 but it hasn’t so far.

I’ve put that on the list as RH-65726.

1 Like

The current implementation is in line with legacy Rhino Render.

I will not be making changes to that in the Rhino 7 release Cycle, but can consider this for Rhino 8. It also largely depends on updates to the clipping planes in general that are planned for Rhino 8.

Regarding the luminosity value: this information is not passed on to RhinoCycles, so it doesn’t know about it. I’ve adapted the logged YT item to read: RH-65726 Rendering: Use luminosity value of the backface material. The subsystem with the error is the Realtime RDK.

edit: actually, I am amazed we still have this weird material definition available in our interface where you can set the luminosity. This CDisplayPipelineMaterial that has two CDisplayAttributeMaterial parts to it. It is ancient and awkward and has no place in modern rendering - IMO there should be only an option that says: custom render material for backfaces. Anyway. I’ll see if I can get the luminosity baked into the RenderMaterial that the ChangeQueue will dish out.

1 Like

Thanks Nathan for looking into it.

Just out of curiosity, I am wondering why a change in clipping plane code is required, since it is already working with the current clipping plane implementation in Rendered mode.

It is a completely different implementation. Cycles itself does not have a clipping plane feature, so I had to add that. And the way that is done is based on the legacy Rhino Render way of rendering.

Changes to how clipping planes work are planned for Rhino 8. I started updating our Cycles to the latest in Rhino 8, so it’ll coincide with that work. No doubt we’ll see improvements here, too.

1 Like

Hi @nathanletwory,

I noticed the same issue with Cycles not rendering clipped polysurfaces as solids.
For architectural visualizations, this feature is quite fundamental.
I hope this can be implemented as soon as possible.


1 Like

Hi Fabio -

For the time being, you’ll have to use the luminous backface workaround that Jakob mentioned. The issue that he reported has been fixed and tested in 7.12 that will become available as a release candidate soon.

1 Like

RH-65726 is fixed in Rhino 7 Service Release 12 Release Candidate