Copy over additional nodes with a Node Material
-
This might be a very unique use-case.
We define a custom node system that is used in Node Materials. We have a shader that references another nodes from the scene, such as materials and objects. Currently when the Node Materials is copied over to a new scene, these references are lost. Ideally, the referenced nodes should be cloned and copied over to the new scene along with the material. Is it possible to do this with the current SDK?
This was not an issue with our legacy material, since it was our custom MaterialData implementation, and so we had control over copying by overriding the CopyTo() method. -
Hey @peter_horvath,
Thank you for reaching out to us. What qualifies as a reference for you? A
BaseLink
I assume? I.e., you mean that you have node material attribute or port that is rendered asCUSTOMGUI_LINKBOX
orCUSTOMGUI_TEXLINK
, and you want to not only retain these links when copying the node, but also automatically copy over the dependencies a.k.a., links? Or am I misunderstanding you here? Because even the Cinema API (formerly knwon as Classic API) does not do this. When you have a MoGraph cloner set to object mode, and you copy it from document A to B, it will carry its children over but not the linked object.What and how is copied is defined by
NodeData::CopyTo
, but implementing carrying along all dependencies is very hard or impossible; depending on the node that is copied and the dependencies which shall be carried along. Almost impossible is for example to have a material carry along objects; because while you could hide away the materials in a custom branch of the material to get them copied with the material, the new scene would not know that it would have to unpack that inserted material. You could of course write yourself aMessageData
plugin which watches a document for materials being inserted, and then does its unpacking magic, but that is so overengineered, I would avoid that at all costs. As there is a very good chance that this either would not work at all or end up very buggy.On top of that comes that for node materials you do not own the implementation of
Mmaterial
, the material type all node materials use, so you cannot customize any of theNodeData
methods for node materials, e.g.,CopyTo
. But it is probably best that you shed some light on what qualifies as a reference for you here.Cheers,
Ferdinand -
Hi Ferdinand,
Yes, I'm referring to a reference as a BaseLink or port with a linkbox custom gui. Our legacy material using the classic API does exactly what you have described. It clones the linked node in NodeData::CopyTo(), packs it with the material and unpacks in the new scene via a scene hook/message data plugin. Not pretty, but works fine.
This level of flexibility is missing from Node Materials, so as I understand it's not possible to achieve something similar right now nor in the near future most likely. Alright, I can live with that.Cheers,
Peter -
Hey @peter_horvath,
Yes, that is currently not possible. One of the reasons why this is not possible is that a node material IS a cinema::Material, i.e., it is the generic material implementation which derives directly from
BaseMaterial
. So, it is under the hood the same as the Standard Renderer Material of Cinema 4D. At runtime it then throws anything out in its UI/description that isn't nailed to the floor when there is aBaseNimbusRef
(i.e., a node system) attached to the material and then replaces its UI content with the node system data. This is just one example, node materials rely also for all the otherNodeData
andMaterialData
things onMmaterial
.This does not mean that we could not technically think of a mechanism for how to customize copying behaviour, but it currently does not exist. Giving users control over the whole material seems a bit unlikely at the moment. I will bring up the idea with the developers of material nodes, but I cannot give any guarantees. My hunch is that they will react like I did, that this is a bit uncharacteristic behaviour of Cinema 4D. But maybe I am wrong
Cheers,
Ferdinand -
Sure, no worries, it's not a high priority, more like a nice to have feature. We can manage without this. I was just wondering if something like this could be possible already in the context of node materials. Thanks.