Precedence or Priority option for materials / render-level Boolean Operations

To render materials such as water in a glass correctly, Indigo renderer, for ages, supports what it calls Precedence. Basically, instead of trying to match the water perfectly to the walls of the glass, this allows you to simply overlap the water mesh with the glass mesh, but set the glass’ precedence to a higher value than the water’s. Indigo will then render the scene as if the water perfectly touches the glass.

And even if you attempt to match up the surfaces perfectly, you’ll find that there will actually be z-fighting in Cycles, adding weird refraction patterns from the interface, that shouldn’t actually be there.

Lux renderer has an option called Volume Priority. I’m not sure if it does the same, but it kind of sounds like it:

Volumes have a priority setting, which is an integer number.
In regions where volumes overlap, the volume with highest priority is chosen and replaces all other volumes.

It’s basically just a layering system to manually resolve overlap issues.

A little while ago, I tried to mimic this using OSL with others’ solutions to similar problems referenced from there as well, but there are lots of downsides to this: It’s limited to CPU, it’s slow, and for non-convex masks or multiple objects in the same mask, it doesn’t work correctly.

It would be nice if Cycles had such a feature. I’d argue for it working for every material, not just refraction shaders and ones based on volumes.
Additionally to the above-mentioned glass scenario, this could also allow for complicated, dynamical changes in shape. Things that would be excessively hard to accomplish normally, because it’d require wildly changing topology, and because a boolean modifier is often more likely to mess up than not. It ought to be as simple as intersecting an object with a (fully) transparent shader of higher precedence (or what ever term you’d prefer) than the visible object to, for instance, cut an arbitrary hole into it.

1 Like

We would like to supported nested dielectrics for this, though no one is actively working on it as far as I know.


Yes, it is the same.

I would love a way to render nested dielectrics with cycles!

1 Like