Is it possible to resize a c4d.VariableTag?

[karpique]

And another question: Cinema 4D crashes if target object has Vertex Color Tag and after that get update of Tpoint & Tpolygon tags. Is there a way of resizing Vertex Color Tag?

edit (Ferdinand): Forked from Copy mesh from one object to another with Python.

[ferdinand]

Hello @karpique,

I would like to point out that we ask the community here to post separate questions into separate postings, so that other users can find more easily answers when searching the forum. You can read more about the procedures of SDK support in our Forum Guidelines.

Which is why I did move your question into this new topic. We will answer it with our normal procedures in the coming days.

Thank you for your understanding,
Ferdinand

[ferdinand]

Hello @karpique,

thank you for reaching out to us. The answer is unfortunately, no, you cannot resize a c4d.VariableTag, i.e., a c4d.VertexColorTag. You can however create a new instance and copy over data from the old tag, taking the new size into account.

But I am also a bit unsure how your question is meant. When you copy over all point and polygon information from one polygon object to another, then all the old point and polygon information in the object that has been copied to, will be gone. So even if you would carry over the vertex color information, it would not make much sense anymore, as it has been created for the old topology. The crashing you did experience, most likely was caused by overwriting the target polygon object with a vertex list that was smaller than the original one. The VertexColorTag was still indexing that old and larger vertex set and then came down burning when you switched out the vertex data under his feet

When you want to just join two polygon meshes, including some tag data associated with them, I would recommend using c4d.utils.SendModelingCommand. If this is not the case, I would have to ask you to clarify what your goals are, because I currently do not fully understand them.

Cheers,
Ferdinand

[karpique]

@ferdinand thanks again, it’s more clear now!
About my concept: I’m trying to make procedural “current state to object” where result base object remains the same and only thing that changes is it’s mesh. It will allow users to direct manipulate object that has procedural source - cloner, exturde, etc, and keep all lnks to that changing mesh valid. Manipulations can include utilizing vertex colors/weights with fields, attaching stuff to points with xpresso, using object where mesh is strictly needed (like collider in thinking particles, etc). Some of that tricks can be achieved with correction deformer, but not all of them.

As far as I know c4d.utils.SendModelingCommand will create new object, so its not the case. Copying polygon and point tags is super fast so I hope there is some way to keep this operation in sync.

For instance, how VertexColorTag being resized if MCOMMAND_DELETE applied? Does SendModelingCommand held that or something else?

[ferdinand]

Hello @karpique,

About my concept: I’m trying to make procedural “current state to object” where result base object remains the same and only thing that changes is its mesh.

1. Depending on how you mean that, a solution to this ranges from trivial to extraordinarily complex. It mostly depends on your interpretation of procedural. If you just want a static one-way binding from some input X to a generator object, i.e., have an output that is not editable, then this is not hard to do. Simply write a Python Generator Object or ObjectData plugin which uses SendModelingCommand to execute MCOMMAND_CURRENTSTATETOOBJECT on that input in a temporary document and return the result of that as the cache of the generator.
2. If you however want this to be a non-static one-way binding, i.e., have the result of MCOMMAND_CURRENTSTATETOOBJECT copied into an editable mesh, this can become extremely hard to do, because this goes a bit against the principal logic of Cinema 4D. If you have an input (hierarchy) In and an output geometry Out, you could write a tag solution that simply does copy stuff from In into Out whenever it determines In to be dirty. It could also be done as an ObjectData solution, as either providing your own PolygonObject or a deformer. At least the tag solution is not much harder to do than what is being described under point one. But if you want to have some sort of persistence in modifications made by the user to Out, this will become quite complicated. Because if the user just moves the polygon with the ID 1, you might want to preserve this modification after the user modifies then In resulting in an output that also contains a polygon humans would consider to be the same as the polygon 1 from the previous output. The solution to this range from simple, like for example only preserving transformation changes made to outputs for the same point and polygon count, to complex and preserving arbitrary modifications via some form of similarity measure. Due to that inherent complexity, we cannot provide support for this, as these would be design decisions - which are out of scope of support according to our Forum and Support Guidelines.

As far as I know c4d.utils.SendModelingCommand will create new object, so its not the case. Copying polygon and point tags is super fast so I hope there is some way to keep this operation in sync.

I do not understand what here the question is.

For instance, how VertexColorTag being resized if MCOMMAND_DELETE applied? Does SendModelingCommand held that or something else?

VariableTag instances, e.g. a VertexColorTag, adapt themselves to modelling operations carried out on thier hosting geometry, no further actions are needed. C4DAtom.CopyTo is however not a modelling operation but replaces the content of one object with that of another (assuming they are of matching type). There is no way to notify the VertexColorTag of such 'change' since it has no clue how to map the old to the new data. If the new data happens to be of the correct size, it will work without any further actions, since the VertexColorTag does not care about topology, but mismatching sizes it can lead to crashes.

Cheers,
Ferdinand

[ferdinand]

Hello @karpique,

without any further questions, we will consider this topic as solved by Monday and flag it accordingly.

Thank you for your understanding,
Ferdinand