How can I influence display order of Rhino objects?

Hi! For a project we definded an own Displa Mode. One objective is to enabling different display attributes for different data types (e.g. switching easily mesh edges on/on when doing reverse eng., having a different color for meshes and surfaces, switching all objects of a special data type like mesh on/off etc.). This works well in general.

We have now also different colors for edges of untrimmed surfaces compared to trimmed surfaces. Unfortunately it looks very “crissling” when we have common edges (trim edge meets an utrimmed edge with different colors). maybe later on I could send a screen shot. I thought one way to avoid this ist to influence the display order dependent on the data type. E.g. display first meshes, that trimmed surfaces and then untrimmed surfaces.

When I use the SC_DRAWOBJECTS channel in my display conduit I can handle each object, but have no influence to the order of display. Ist teher a way to do it?


Hi @Peter_Salzman,

A screen capture will probably be useful.

@jeff, can you jump in here?

– Dale

I’m out until mid next week… I can look at it then…


Not currently. All surfaces, extrusions, and meshes are placed in a single “draw bucket”. We would need to give you a way to sort this bucket.

I will attach a few screen shots to make it hopefully more clear. First 2 Rhino screen shots (wire and shaded) from our PlugIn to show the problem - common wire edges in different colors are interfering making the display a bit crozzling:

And here corresponding scvreen shot how we would expect it to be:

In the Rhino display modes this effect does not show up, because all wires have the same color.

After thinking about it I’m not so sure anymore, that the display order would solve it. I guess the wire interference comes from the Z Buffer and another display order would probably not help. I started a bit to play with AntiAlias and different tesselation (equal tessellation on both sides should reduce the problem). But the different surfaces are not connected (like a Brep) and so equal tessellation on both sides cannot be guaranteed in a real part.

Any idea would be highly appreciated.

Hi Peter,

This looks more like “Z-fighting” than “draw order” issues… and unfortunately, you cannot force a specific pixel to render over another one, when both occupy the exact same depth in the z-buffer…and which pixel “wins” is entirely up to the GL implementation.

The way Rhino tries to solve this type of problem is by “nudging” the z value either towards the camera or away from it, depending on what’s trying to be solved. This can be “attempted” by using the SetZBiasMode(...) method on the pipeline… I would start by calling:


…prior to drawing the lines you want “on top”…

If that doesn’t solve it completely, you can try adding a number to the parameter…like so:

dp.SetZBiasMode(ZBM_TOWARDS_CAMERA + 1);

…but I wouldn’t go any further than +2, as it will most likely give your lines a “hovering” effect.

Also, you should make sure that you put the pipeline’s z-bias mode back to the way it was prior to setting it, otherwise, it can/will mess up other draws, and will most likely negate the effect you’re looking for… This is done like so:

int   oldZBM = dp.ZBiasMode();


However, if the objects you’re trying to influence are not your own (i.e. They’re just rhino objects being drawn by Rhino), then it may be harder to get the results you’re after… You would need to probably first prevent Rhino from drawing the wires, keeping track of which objects you’ve prevented wires for, then once Rhino has finished drawing, go back and draw the wires, but bias them towards the camera as I’ve shown above.

Without a complete understanding of what it is you’re doing, this is all speculation on my part… Chunks of working code, and possibly a plugin example that shows exactly what it is you’re doing, and what the expected results are, would help me not only see the exact problem, but it would help me show you what can be done or added to solve the problem…assuming it can be solved at all. Otherwise, pictures and descriptions of the problem and expectations are too wide open for interpretation, and we can just go around and around trying this, that, and the other…never landing on a solution.

Hope that makes sense.

Hi Jeff,
thank you very much! The “dp.SetZBiasMode” did the trick. It looks much better now! See new screen shots below.

In my case I want to influence objects that are drawn by Rhino (e.g. surface edges, mesh edges). I modified the colors like this

m_pDisplayAttrs->m_EdgeColor   = FaceColor;
m_pDisplayAttrs->m_NakedEdgeColor = FaceColor;
m_pDisplayAttrs->m_MeshWireColor = MeshColor;

I also draw additional stuff depending on user input in an own display dialog. I figured out the dp.SetZBiasMode( ZBM_TOWARDS_CAMERA); helps when I set it in SC_DRAWOBJECT channel for specific objects.

In my conduit I set now the mode back to ZBM_NEUTRAL when other objects are shown. There should no influence to the general Rhino display, because I’m doing all this only, when the user has chosen our own Display Mode. All those changes are not called, if another Display Mode (like Rhino Wire or Rhino Shaded) is active.

Or should it be better in any case to go back to the remembered ZBias value insted of using ZBM_NEUTRAL?

Hi Peter,

In my opinion, it’s always better to return the system state back to the way it was before you changed it… this allows you to stack things if necessary, and it also should allow for any unforeseen problems when/where the bias mode could change from underneath you… I realize you’re ensuring that this only happens when your display mode is active…however, there is really no way to keep other plugins and conduits from messing with things…so the goal is that “everyone plays nice” inside the Rhino sandbox :slight_smile: So if you change something that Rhino uses to draw, then you really should put it back so that others can expect it to be what Rhino thinks it should be…if that makes sense… Rhino hauls off and just resets everything before each frame just in case, but it’s the plugins and conduits that are all running in line with each other per frame that you need to worry about… so I would just always save the current setting, change it to your liking, do your thing, and then set it back… doing so will guarantee that nothing will be wrong coming out of your code.

Hope that helps.