@ferdinand Thank you, the code runs well. └(^o^)┘

Hi, @Manuel. I understand, thank you. All the best, .... YB

Hello @jpheneger, without further questions or postings, we will consider this topic as solved by Friday 02/06/2023 and flag it accordingly. Thank you for your understanding, Maxime.

Thank you Ferdinand for your time, and also providing a high / low level solution. As far as I can tell it works all as intended - my code now results in clean colors "measured". (in lowlvl R20 and highlvl 2023) I found a small discrepancy with render instances but that's another topic. Cheers, mogh

Hello @herrmay, Yes, it can be a bit cumbersome to write a whole abstraction layer, but most of the time it is avoidable to do that in the first place. In your case it should be pretty simple. Iterate over all layers you want to save to disk. Get the MAXON_CREATOR_ID UUID of each layer and its data container. Write the UUID and the data container to disk using JSON or HyperFile, I would recommend the latter as it will be less work. You only must convert the UUID bytes to a string, put the string into the file, then the data container and you are done. If you want to, you could also store all layer data in one file per document, or just have one giant file for all documents. Later load these hyper file fragments back and do what you want with the data. When you need the original node, traverse the layers in the active document for a node with the stored UUID. You could also make things fancier and search in all open documents or even store the document path in your serialized data and load that document. Saving things in the document container is a possibility too, you should make sure though to use a plugin ID for that. Cheers, Ferdinand

Hey @mogh, just to clarify: I found that bit of the documentation before you pointed it out, but in my mind I could not link "needs a document" to "the object has to be present" ... Well, the documentation clearly states it: doc (Optional[c4d.documents.BaseDocument]) – The document for the operation. Should be set if possible. Must be set for MCOMMAND_JOIN, MCOMMAND_MAKEEDITABLE, MCOMMAND_CURRENTSTATETOOBJECT and MCOMMAND_SPLINE_PROJECT. If you set the document, the objects which you pass to this function have to be in the same document. So pay attention that you use one send_modeling_command per document for objects. But that could be more visible. I'll see if I can rework the function documentation a bit to make that important information more prominent. Cheers, Ferdinand

@ferdinand thanks for your generoso help. I already send you an email with an zip file , and some notes in the front of the codes. Have a good day!

Hi @ferdinand, Thanks a lot one more time for all the detailed examples and informations. I finally opt to a data container of the node, mostly due to the fact that the hooks are volatile and need to be set all the time. I also ran some tests with globals without having encounter issues, but indeed you need to be careful when handling this approach. Cheers, Christophe

Hello @wickedp, I have forked your questions as they both did constitute new topics, find them here: Rendering into Multipassbitmap Depth Pass Adding Layers to a MultipassBitmap Cheers, Ferdinand

Hi there, Was the issue fixed on R2023 or R2024? Thanks, Christophe

Great to hear! One thing I forgot to mention: For ICONID1 XXX and ICONID2 YYY you can use any of the built-in icon IDs as listed here. When you want to use your own icons, you must make sure the icon IDs are registered before the node which is using them in its description. Simply put the c4d.gui.RegisterIcon call before the RegisterXXXPlugin call of the plugin using them. Cheers, Ferdinand

Sounds like what I'm doing should be OK then. If I run into any problems, I'll pop back in for further advice. Thanks @ferdinand, your help is always appreciated. We can close this one. WP.

Thanks for the reply. No problem if it's not backwards compatible. We will adapt our code to the latest version of the SDK. Thank you.

Hello @ferdinand Thanks a lot for the code above, I really appreciate your help. I changed a few things for match what I was looking for and now it's working perfectly. Thanks again!

Hi Manuel, Thank you. I've been expecting this. Hope such support will be added sooner or later Our app: finalmesh.com Alex

Hi @Dunhou you can't control the Make Preview plugin, you have to rewrite the function yourself with all the tips previously shared in this topic. Cheers, Maxime.

No worries, everything is fine, that is what we are here for, to clear up things. When you have questions I encourage you to open a new thread so that we can see what we can do. And this is also an open forum, so you can ask questions to the community if you want to. But unless pointed out specifically otherwise, we assume things to be support requests. Cheers, Ferdinand

Hello @kbar, Thank you for reaching out to us. This is a tricky one to answer, and my first instinct was that this is not too surprising due to what you do with your GeListHead, but the devil lies in the detail. In general, I would say that the safest route would be the one many of our implementations take: Displaying elements that are not part of the "standardized" branches of a scene graph via a DescriptionCustomGui wrapped by a custom GUI of yours which is part of a description of a (set of) node type(s) you provide. The FieldList data type/GUI does this for example. Overview Simply adding a custom branch in form of a GeListHead to a node of your choice will not make this custom branch discoverable via BranchInfo. This is because there is hard-coded data in the Cinema 4D core for this branch discovery. You can of course manually traverse the branches of your node. In the Attribute Manager SetObject implementation, this hardcoded branch structure is not being checked directly as far as I can see, but the Attribute Manger modes rely implicitly on it. You can register new Attribute Manger modes with ActiveObjectManager_RegisterMode which binds than that mode to a hook as for example shown in [1] (for materials in this case), see the MESSAGEHOOK documentation for details. It shows the case for tags as used internally. The object mode case is much more complex, but it will effectively fail on AOM_MSG_GETATOMLIST in your scene setup because the traversal done there assumes objects to appear in "object " branches only - which is not true in your case. Solutions I personally would still consider the DescriptionCustomGui route the safest way, especially because the GUI has the DESCRIPTION_OBJECTSNOTINDOC flag which allows you to also display orphaned nodes. Implement your custom attribute manager mode, which can deal with your custom scene traversal structure and mark your nodes with NBIT_ACTIVE so that the hook can find them. Regarding Xpresso nodes: They have their own branches which are respected in the AM implementation. As a warning: There are also quite a few hacks in the AM for Nodes API and shader nodes, especially regarding the traversal. In general, I would consider this non-regular scene structure of yours a problem with the AM because of how often Cinema 4D internally relies on a specific makeup of branches. It could very well be that you implement your AM mode, and everything will then work fine, but I cannot guarantee that. Which is a further point why I personally would gravitate towards the first solution. Cheers, Ferdinand [1]: static GeData MaterialMessageHook(const BaseContainer &msg, void *data) { switch (msg.GetId()) { case AOM_MSG_ISENABLED: return true; case AOM_MSG_GETATOMLIST: { BaseDocument *doc = GetActiveDocument(); if (!doc) break; doc->GetActiveMaterials(*((AtomArray*)data)); return true; } break; } return false; }

@ferdinand Yes. it's solved. Thank you.