I am trying to match the Rhino materials with my own plugin materials. The RDK is not providing the material editing capacity I need, so I have a dictionary of materials, indexed by Material.Id. Unfortunately the Rhino Material.Id seems to change when you assign a material by drag-and-dropping onto geometry that already has a material assigned. I assume this is a bug? As am example, create 2 planes, assign a material to both planes (“material1”), then assign a new material (“material2”) to both planes - and this sequence create 2 copies of “materials2”, one with the Id of “material1”.

To cope if the above situation I need to capture when a Rhino material has been renamed. I am trying to use Rhino.RhinoDoc.MaterialTableEvent to do this. However the MaterialTableEventArgs.OldSettings.IsReference is always true, and MaterialTableEventArgs.OldSettings.UseCount is corrupt (usually a number > 2000000). I assume these are also bugs.

  1. So, if there any way to trap when a Rhino material is selected in the Rhino Material panel?
  2. Is there any way to determine if a MaterialTableEvent (modify) is due to a material assignment, or a material being renamed?
  3. Does anyone have any other suggestions I can try.

Thanks in advance.


(Steve Baer) #2

Hi Paul,
Thanks for pointing out the bugs in IsReference and UseCount for the material table event. I see that and am looking into making a fix for it. @andy will probably have the best idea for suggestions since he has his head much deeper into how we deal with materials in the SDK than I do.

(Steve Baer) #3

Did you look at the EventType on the eventargs passed to the material table event? There are several different eventtypes (Added, Deleted, Undeleted, Modified, Sorted, Current)


Yes - both renaming and assigning a material triggers the event with a Modified eventtype. It doesn’t seem to trigger when you select a new material (should that trigger a “Current” eventype?). I might be able to achieve the outcome I’m after by storing the Material.Id in the userdata.

Thanks for the replies. I appreciate the quick responses.



Interestingly - I cannot currently reproduce the issue with the corrupt IsReference and UseCounts! So it is potentially an intermittent issue.


Further investigation reveals that MaterialTableEvent is Rhinocommon appears to be somewhat troubled. For example, renaming a material results in a modify event being triggered for all materials. Maybe it is my poor understanding of Rhinocommon materials, but you can have two materials with the same name, and the MaterialTable find function only returns 1 (presumeably the first). So there is no unique identifier for a material. The Id is unique, but transfers between materials when you assign those materials. Copying one material over another results in a MaterialTable that has more materials than the Materials panel.

(Steve Baer) #7

It’s definitely a bug. I just fixed this in the source so you’ll get the fix in SR6


Thank you. Much appreciated.

(Andrew le Bihan) #9

This is the new way that stuff works in V5 - there has never been a material table browser before, and the way the material system was designed before V5, it was never meant to support that. As a result, if you want to figure out what’s happening with the materials in the material editor, you have to use the RDK. There’s no other way.

Once the RDK is running the materials, as it always is in V5, the CRhinoDoc::m_material_table is really just a repository for materials used in the display.


Thanks Andy

Perhaps my understanding of the RDK material system is not correct. Is there any way to determine when the selected material in the Material panel has changed using the RDK? Do you know of any code samples demonstrating the implementation of materials with the RDK?



(Andrew le Bihan) #11

Yes - the attached plug-in demonstrates many things about the RDK in C++. If you want RhinoCommon, I can clean something up for you - but I should let you know that it really is still a WIP. KB)

As for getting a selection changed event - that’s actually fairly tricky, because there are multiple editors. But basically, you will need to watch for this:

virtual void OnContentSelected(const CRhRdkContent* pContent, const IRhRdkContentEditor& editor) { }

However, since multiple selection is now available since the SDK was first published, there’s a new custom event that handles that - see

// Custom event for multiple content selection.
RHRDK_SDK extern UUID uuidContentMultipleSelection;

And you will find that a CRhRdkContentMultipleSelection is passed into pvContext - so you can safely cast it if the uuidCode is set to uuidContentMultipleSelection.

  • Andy


Thanks - very useful.

Another probable bug…assigning a material to a rhinoobject is not issuing a ModifyObjectAttributes event (and I believe it should). Also, the documentation for ModifyObjectAttributes is incorrect (cut and paste error from DeselectAllObjects).


(Steve Baer) #13

Thanks for pointing out the documentation error. I just fixed this so it should show more relevant (but probably still useless) information :wink: