Solved OBJECT_INPUT Child Updating

Hi @JohnThomas, thanks for the clarifications.

looking at your first post (and code), it was unclear to me if you sticked already to the information we discussed, time ago, about spline generation and child objects (GetVirtualObjects or GetContour) but looks like that your full code was already capable to return the desired output.

Searching more in depth in Cinema 4D code, I've stumbled across a piece of code about the dynamic tags, mostly related to performances reasons, that ignore tags on virtual objects unless they have been created by cloner/fracture/particle emitter/array. This explains the reason of your plugin failing to retrieve the proper geometrical data due to the dynamic tag being ignored .

However, as you've experienced already, removing the OBJECT_INPUT flag makes Cinema 4D thinking of your plugin not using virtual objects from children and, consequently, having the dynamics tag ignored no more but still letting you use that data from objects being nested under your plugin.

Below a simple example obtained by implementing BaseObject::GetContour, BaseObject::GetVirtualObjects() and registering the plugin as OBJECT_GENERATOR | OBJECT_ISSPLINE. This represent a workaround to the actual system limitation so corner cases which might be hard to fix might appear on more complex setups.

Thanks for the reply.

Other than the corner cases you mentioned would not including OBJECT_INPUT, in a plugin that is using it sub-objects as inputs, result in issues with Cinema outside the scope of my plugin?

John Thomas

Registering a plugin without the OBJECT_INPUT should work with regard to retrieving data from children but it will require you to manually create and touch the dependency list in order to clean children caches and hide them from the scene.

Best, R

Thanks for the response

I know how to create and touch the dependency list but if I put my object, without the OBJECT_INPUT flag, as the child of something like a Cloner will Cinema be able to properly interact with it or could that lead to problems?

John Thomas

Hi @JohnThomas, looks like it does.

Cheers, R

Thanks for the response.

After removing OBJECT_INPUT as a flag the children of my plugin are no longer removed if my object is made editable. Is there a workaround to this without losing the benefits of removing OBJECT_INPUT? I have already implemented the dependence list for the child objects.

John Thomas

I've spent more time working on it and have still not found a solution. Any help would be greatly appreciated.

John Thomas

Hi @JohnThomas, I apologise for late answer but it slipped through.

As workaround for the specific case mentioned above, you can implement an NodeData::Message() and intercepting the MSG_EDITABLE_END message (please note that it's private and its usage is not recommended) you can delete your children after the "make editable" process has completed.

Best, R

Thanks for the response.

I tried using the code below to get the children and it does not properly return that there are child objects.

case MSG_EDITABLE_END:
{
	BaseObject*     op = (BaseObject*)node;
	if (op != nullptr)
	{
		if (op->GetDown() != nullptr)
		{
			ApplicationOutput("Down");
			BaseObject *down = op->GetDown();
		}
	}

        break;
}

Is there a different way that you are meant to use to get the child objects to do the method you suggested?

John Thomas

Hi @JohnThomas , the data passed in the method is actually carrying the destination object.

The code should look like

...
	if (type == MSG_EDITABLE_END)
	{
		BaseObject* dstObject = static_cast<BaseObject*>(data);
		if (!dstObject)
			return false;
		BaseObject* child = dstObject->GetDown();
		if (child)
		{
			child->Remove();
			BaseObject::Free(child);
		}
	}
...

Cheers, R