Where do I find IDs?

jakub

Hi,
I can't seem to find a good way to find c4d IDs for objects, shaders etc?
The symbols.h file doesn't contain everything nor does the SDK documentation.
For example, when I want to create a mograph color shader - where do I find its ID? Not even the Shader type list has it...

Thanks!!

Cairyn

There doesn't seem to be a proper constant. You can find the numeric ID:
Create a material with the MoGraph color shader in the texture slot.
Drag the label "Texture" to the Console to examine it.
Press Return to get the current content:

>>> Mat[c4d.MATERIAL_COLOR_SHADER]
<c4d.BaseShader object called Color Shader/Color Shader with ID 1018767 at 1851402072320>
>>>

There you have the ID.
I tried to find the c4d symbolic constant by applying a script on the ID:

import c4d

def main():
    for attr in dir(c4d):
        val = eval('c4d.' + attr)
        if type(val) == int and val == 1018767:
            print (attr, val)
    print ("Loop end")

if __name__=='__main__':
    main()

But the loop ends without result.

The Maxon people may know where this hides.

jakub

Thanks! handy trick, didn't know it. That will do. Although it would be so much easier if the names/ids were part of the documentation ha

ferdinand

Hello @jakub,

welcome to the Plugin Café and thank you for reaching out to us.

While traversing the attributes of the c4d module as shown by @Cairyn (thanks!) can be helpful sometimes, it is not the recommended way to discover DescID and node type ids, as it can yield results which are ambigous.

The article Types and Symbols List in our Python documentation contains most node type and enumeration symbols used in function and method calls. The article Classic Resource Overview contains the parsed resources of the classic API, i.e., node types as object, tag and shader types and their parameters. You can also discover node and parameter ids in Cinema 4D itself with the console, as described in the article Python Console. The message system of Cinema 4D and its ids are documented separately in the article Message System. Finally, although currently not described in the documentation, an important workflow is also to grep the resource folder of Cinema 4D for a known numeric symbol value, e.g., grep the folder for 5159 to find out that its symbol is Ocube.

Cheers,
Ferdinand

Cairyn

@ferdinand said in Where do I find IDs?:

as it can yield results which are ambigous

Hm, that is an interesting statement. Of course, any enum types and/or any IDs for things like dropdowns may be ambiguous, as they all tend to start with 0. (This covers DescIDs.) Also, naturally bitfields cannot be handled that way as they combine single-bit values into one number which by default doesn't have a symbolic constant.

However, what about object IDs, shader IDs, effector IDs, etc., like in the original question? I would have expected that these are part of the program-wide, world-wide unique ID system that is also used for plugin IDs (which then also cover objects of these types again).

Depending on the internal handling (which I can't look at, of course) it is possible that C4D actually uses a hierarchical identification system, but naively I would not have expected that, since there are functions like GetType with a single numeric return value, existing on the very top of the class hierarchy (C4DAtom).

Thus my followup question - is it actually possible that objects (not enum values, containerized parameters, or GUI elements) share an ID? And if so, under what cicumstances does that happen?

ferdinand

Hello @cairyn,

no, nodes cannot share IDs in the classic API, or if they attempt to do so, only one of them will be registered on startup. This was more an answer to push a beginner into the right direction, and I had message IDs in mind but also node type ids in a more indirect sense.

When you poke around in the depths of Cinema 4D, you will find out that there are sometimes node types which are not shown to the user, and they only live in the background. Their symbol is then however sometimes very similar to a "public" node type they do accompany from the background. This mostly happens for plugin nodes (the real BasePlugin nodes), but also in some TagData cases and other stuff. When you iterate over the raw data, you must already know what is what, to make sense of it. Which is why we recommend using either the console or the article listings, as you will not find symbols there for "background nodes" which are effectively meaningless for a public API user.

Cheers,
Ferdinand

Cairyn

Thanks for the info! So far I have only encountered the "invisible" tag types in practical application; I will keep this in mind though in case I stumble over such hidden nodes.

ferdinand

Hello @jakub,

without any further questions and other postings, we will consider this topic as solved and flag it as such by Friday, 17/06/2022.

Thank you for your understanding,
Ferdinand