Number of Init() calls in ObjectData

a_block

Hi,

quick question regarding the behavior of ObjectData plugins in C4D R25 (25.010 to be precise).

This does not pose a functional issue for me. Yet, I'd like to understand what is going on and what has changed.

The described behavior can be easily replicated with a simple print within Init() of py-rounded_tube_r13.pyp.

The question is the number of Init() calls happening upon a manual parameter change in Attribute Manager by user.

In C4D R21 I get zero to one calls depending on the parameter changed.
Main Radius change does not seem to trigger Init() at all.
Axis changes end up in one call to Init().
I had expected to always get called, due to the backup object on the undo stack being created. Yet, I'm perfectly fine with getting less calls, even if I do not understand the difference in those two parameters.

But in R25 I get multiple calls to Init(). Even more funny, the number of calls is not even constant when changing the same parameter over and over.
Changing Main Radius I get one or two calls into Init().
Changing Axis I seem to get always two calls into Init().

So there's definitely a change in behavior and the new behavior is not even static, it seems. Confusing.

ferdinand

Hello @a_block,

thank you for reaching out to us. I can reproduce your problem and it is not just limited to ObjectData, but extends in fact to everything that is a BaseList2D. The problem is being caused by the fact that even classic API scene objects are internally handled as assets (at least partially). It starts with R25, S24 is still fine.

There is unfortunately not much you can do to mitigate this, as you would need access to the C++ stack trace which leads to the Python bindings of Init being called, in order to distinguish a good from a bad ' Init call. Which you have not in Python. You could do some system clock gymnastics or similar dicey things, which I am sure you can write yourself and also know what a bad idea it would be.

You also cannot offload work to __init__ or __new__ as the Python object is reallocated every time (which I am sure you are aware of, but othe users might not be). The easiest pattern to avoid all this mess would be to use the MAXON_CREATOR UUID of a node representing your plugin to manage your data manually. In the process of writing a quick example I did however find out that this problem also breaks UUIDs.

    def Init(self, op):
        """The py_rounded_tube example Init().
        """
        print(bytes(op.FindUniqueID(c4d.MAXON_CREATOR_ID)))
        ...

Printing out the UUID of the attached node for the py_rounded_tube in S24 on multiple parameter changes in a row:

And the same code in R25, yikes:

I will reach out to the developers to see what we can do about this. I am not sure if the multiple calls issue will be fixed, as the problem is tied to the default value system of the asset system and the code which causes this behavior looks quite intentional. The underlying UUID problem must be fixed IMHO, as it is quite important for more complex Python stuff, but we will see.

Thank you for pointing this out.

PS: Your GeDialog stuff has not been forgotten, it is still cooking .

Cheers,
Ferdinand

a_block

Hi Ferdinand,
thanks for the quick and detailed answer, even trying to find workarounds. I had hoped, I could spare you this extra effort by saying, that it's no functional issue on my end.

I am already satisfied with the confirmation. Often it is enough to be able to stop worrying about my own mental integrity.
And while this new behavior certainly will not improve performance, I can happily ignore performance issues beyond my own responsibility.

Regarding the GeDialog stuff: No worries, either. As mentioned back then, no future fix/solution can help me there and I went down a different route to get the project done with support for R19 to present. Yet, I'm thankful for your tenacity and that the issue is still being researched. Some meals simply need time to develop their flavours.

Thanks and cheers,
Andreas