Unique name for RenderContent

Is there an API function to check if the new name I would like to set for a RenderContent item is unique or not? Or how do I iterate over all the RenderContents to check it?


@andy, can you help with this?

Any info about this?


I don’t think there is an API function that gives you a unique name. But if you were to use a name that already is in use your new content would get automatically a new name based on the name you try to give. For instance Material would be Material (1) or something similar.

You can iterate over different RenderContent using:


If I try to change it programmatically, it allows me to set any name it seems, so I can generate duplicated names.

I don’t know if duplicated names is a risk for the Rhino app or not… But If I can iterate over all the important RenderContents, I can generate a proper (not duplicated name). So if I check environments materials and textures to be sure the name is not used, is it a correct solution?

As I see now unique name is required only among similar types? So material names should be unique but that is OK to have the same name for a material and an environment?


You should be able to use the same name for different types. I just tested through the GUI, I was able to create a RenderEnvironment, a RenderTexture and a RenderMaterial, each originally named BLA.

You shouldn’t have to worry about that. As I said earlier Rhino will automatically change a name if there is already a RenderContent of the same type with the same name:

import Rhino
import System
import scriptcontext as sc

def SampleAddRenderMaterials():
    blue_material = Rhino.DocObjects.Material()
    blue_material.DiffuseColor = System.Drawing.Color.Blue 
    for i in range(3):
        blue_render_material = Rhino.Render.RenderMaterial.CreateBasicMaterial(blue_material)
        blue_render_material.Name = "A name"


This gives

The difference here that I don’t add new material, I want to rename existing material. In that case it doesn’t correct the given name it seems.


Hmm, right, that is a bit unfortunate.

import Rhino
import System
import scriptcontext as sc

def RenameAllMaterials():
    for rm in sc.doc.RenderMaterials:
        rm.Name = "Some other name"


That indeed gives us a set of RenderMaterials that all have the same name…

@johnc, is the RDK supposed to rename such new names also when changed on the fly?

I see that trying to give the same name in the UI it appears to see for itself already there is a similarly named material already, and doesn’t let you. What about the programmatic interface? See the small Python snippet in this reply.

Hi Márton,

I work at the C++ level which RhinoCommon is built on, so any information I give might be inaccurate from the RhinoCommon point of view. I hope Nathan can iron out any inaccuracies.

  • At the moment there is no C++ SDK function to check that a name is unique.
  • When you change a name through the SDK, you can set any name. In Rhino 7 I have added a new C++ function that will allow the ‘unique check’ to be done as well. Eventually that will replace the existing function. I’m afraid it won’t help you yet.
  • The name-is-unique check is done per content kind (material, environment, texture) but not per type (paint, metal, glass, etc.) So you can have a material with the same name as a texture.
  • Rhino automatically makes a name unique when a content is attached to the document but not when a content is renamed.
  • Having multiple items with the same name will not do any harm. Render Contents are identified using a unique instance id which is distinct from the name. The name is purely for human readability, so don’t worry if you do have duplicate names.

I see Nathan has answered the iteration question and for now that might be a workaround for V6. Another workaround would be to detach the material from the document, rename it, and reattach it. Rhino will then make the name unique. None of these solutions are optimal. I will discuss this with @andy at our meeting tomorrow.


Thank you for both of you! It is more than enough information for me:)


Nothing to add to what @johnc wrote. He covered all bases.