How to display Dib Texture in Wireframe/Shaded mode? (C++)


I want to display an object having a material with a dib texture in Rendered mode other than what the viewport is currently set to.
I followed the instructions in, but the texture does not appear in modes like Wireframe or Shaded.

Here I attach a sample reproducing the issue:
cmdSampleShadingDibTexture.cpp (4.9 KB)
This was made from the link above + this sample to create a dib texture.

Is this possible? Or dib textures are restricted to Rendered mode?

Thank you,

I believe this is the case. @jeff, is this true?

– Dale

As far as I can tell, all that is being requested here is what gets done for Picture objects. No?

A material with a diffuse texture channel set is assigned to an object’s material, and then that object’s display material ID is set to “Rendered” (i.e. SetObjectDisplayMode Mode=Rendered)

What am I missing?


Hi @jeff,

The sample that I posted adds a sphere with a dib texture on top of a red material that looks like this:

Though, I need the dib texture to appear also in Shaded mode (instead of the red material). The sample is supposed to do that but for some reason it does not work. It should look like this:

I got the above picture by going to
Rhino Options > View > Display Modes > Shaded > Shading settings > Color & material usage setting to Rendering material instead of Object’s color.
Is it possible to do this through code (and only for a particular object)?


Yes, but now ALL objects in Shaded mode will use their render materials… You’ve basically now just turned your Shaded mode into Rendered mode…

To get individual objects to always use their render material, regardless of what display mode (view) they’re in, you need to select the object(s) and run SetObjectDisplayMode and then select the “Rendered” mode in the command line.

That being said, yes, this can be done through code, but it can get pretty tricky because it’s a “view-based” not just object-based.

IMO, since you’re writing the code yourself… Here’s what I would do/try…

Override the object’s display attributes in the SC_OBJECTDISPLAYATTRS conduit channel…and then when executing in that channel, set m_pDisplayAttrs->m_pMaterial equal to the material you want. Rhino will then use that material when drawing the object in the future draw channels. Note: This requires that you be able to identify your object somehow… which can be done using the channel attribute’s object member m_pChannelAttrs->m_pObject

if ( m_pChannelAttrs->m_pObject == YOUR_OBJECT)
  m_pDisplayAttrs->m_pMaterial = YOUR_MATERIAL;

Note however, that m_pMaterial is a CDisplayPipelineMaterial which consists of two materials (front face and back face), which are really just ON_Material derivatives. If you do not want the back face material used…then just set the front face material and nothing else (m_pDisplayAttrs->m_pMaterial->m_FrontMaterial = YOUR_MATERIAL)

If I get time today, I will look at the example you posted and tweak it to do what I think you want… But, if you manage to get this working please let me know so that I’m not doing anything unnecessary.



Any tweak you can provide will be very much appreciated. You can even just provide the body of the conduit drawing the object with the render material, and assume the object is referenced as a conduit member.
I wonder how to reference the material, maybe through the material index?

Many thanks,

Hi @jeff,

I noticed, after digging more into materials and conduits, that there is actually a difference between displaying an object with its render material, and displaying a dib texture.

Your instructions led me to properly draw an object with its render material regardless of the display mode they are in. However, I didn’t manage to display a dib texture in Shaded mode, even though the object was being correctly displayed in its render material (a red color if you run the example I posted). Even if I run SetObjectDisplayMode on an object with a dib texture and select Rendered while being in Shaded mode, this does not work.
So maybe there’s some point in the C++ SDK where the interaction dib textures/display mode is not exposed, or not exposed enough? In that case, could that be asked as a wish item?

I barely know dib textures from this sample, and that they appear in their own category ‘Color’ for a material:

Though, I have the feeling, correct me if I’m wrong, that dib textures can be very powerful to override mesh vertex coloring in the case of rectangular meshes, faster and more efficiently. The reason is that dib textures provide direct pixel-shading function, while for mesh vertex coloring I have to allocate and position the vertices/pixels on my own.


Hi @Pablo_Garcia-Amorena,

Sorry, I was a bit swamped today and couldn’t get to this…

I think part the problem you’re running into is that you’re using the RDK and creating RDK textures and RDK materials… and although that might seem like it should work, the RDK is primarily used for “Rendering” and not necessarily “Display”. There are some things you can do to get the RDK materials to work in the display, but they’re somewhat tedious and convoluted (especially if/when textures are involved). The best thing to do is to just work with an ON_Material definition… Your example already sets up an ON_Material, now all you need to do is create an ON_Texture and using AddTexture(), add it to the material.

Rhino does this in many places within the pipeline, the best examples of this are the Shaded Analysis Modes… Zebra and EMap analysis modes, cook up textures from dibs, and override the current display material much like how I’ve described in this thread… In fact, you could probably implement your solution as a Shaded Analysis Mode…depending on what the overall goal is. If you think that might sound like something you’d like to try, then see CRhinoVisualAnalysisMode for more details.

In the mean time, I’ll try to throw something together that uses the conduit override I mentioned earlier.


P.S. Texture mapping instead of vertex coloring is a pixel-based operation, yes… However, texture look-ups are also an interpolated operation…which means you can still suffer from “pixel-stretching” if and when a “texel” ends up being larger than a pixel… For example: Zoom into a given triangle…the closer you get, the more pixels are required to represent that triangle, however, the same texel is still going to be used for a given interpolation…which means eventually it’s going to be bigger than a single pixel. The best way to truly get a 1:1 pixel color is to do it in a fragment shader…which is beyond the scope of this thread at the moment.

Hi @jeff,

This, together with creating ON_Texture textures from code (see (C++) How to apply a texture to a Plane from an in-memory array), solved the issue, many thanks! :smiley: