Solved Python Tag vs Expresso for Set Driver/Driven Behavior?

Hi,

I'm thinking of just using Python tag instead of Expresso for Set Driver/Driven Behavior. I saw it was possible.

My concern is performance. Will it give me significantly lesser FPS for a full-on python tag equivalent than expresso? Does python tag have performance quirks that I should take into account to?

My experience is only user data for the individual controls for the fingers. I couldn't tell the different but then again that was only a simple behavior.

Any thoughts on the matter are greatly appreciated.

Thank you

Hi,

to be honest, we have no benchmarks and no data on this question.

My gut feeling is, for an identical task Python may be slower than Xpresso (simply due to the Python interpreter and the need to travel tthorugh the Python layer into C4D's kernel). But on the other hand this will highly depend on the code. If it consists of just one call into C4D's API, there's probably not much to notice, instead if there is a loop constantly calling C4D's API maybe more so. But then in Python you may be able to implement stuff more elegantly compared to Xpresso, which may then again lead to an overhead on Xpresso's side.

Probably not the answer you would have liked to get...

Cheers,
Andreas

@a_block
RE: benchmarks
No worries.

I guess the only question I have is to clarify if Python tag recalculates the command for every frame?
Or does it only calculate if a value(variable) is changed?

For instance, regarding the finger driver/driven behavior, with 40 frame range, if I make a curl on frame 2, does the python tag only calculate from frame 1 to frame 40 or only frame 2?

Thank you

@bentraje The Python tag must be evaluated in every redraw of the scene (not just on every frame but far more often; try this by insert a Print in the code...) because it may not just depend on variables but on values from the scene (e.g. "if the object X is placed farther away than 1000 units then move object Y to..."). Keeping track of original values and comparing them with current values like this is nigh impossible (requiring analysis of code semantics), so the tag will be simply re-evaluated whenever encountered.

You can insert an "early exit" in the tag, of course, by testing for changed variables yourself (as you as programmer have more information on the semantics than the Python interpreter/compiler). But you will need to store the values to compare with somewhere, and you will need to take into account that the execution may not happen in frame sequence (e.g. when the user scrubs the timeline backwards).

As for the original question, I tend to put calculations into Python nodes inside the XPresso because plain math calc creates TONS of XPresso nodes that tend to become very confusing. On the other side I keep XPresso nodes whenever I want to see the affected objects in the circuit directly, or when I need a GUI for adapting something (e.g. Range Mapper with spline interface), or when the node does complicated things that I don't want to reprogram in Python (Hair intersection? ... nah, never used that ). When the whole thing is easier to maintain as a Python tag in the end, I put it into the tag...

So it's not so much a question of whether the execution is faster, it's pure convenience of the result for me.

Hi @bentraje while Cairyn already provided all the information needed, I just wanted to add that a Python Tag is nothing more than a regular TagData where its Execute method is mapped to the main method.
So Each time the tag is executed, it executes the main method of the tag.

You can find information about the Python Tag in the Python Tag Manual.

Cheers,
Maxime.

@Cairyn

Interesting "(not just on every frame but far more often)"
I guess for now I guess I'll just do it in piecemeal. Other parts in Xpresso nodes and the other python tag.
Thanks for the tip on the Python nodes on the Xpresso editor. Haven't tried it.

I would go for the pure Xpresso set-up but its a bit finicky to set-up such as identifying where the node sits in the xpresso editor otherwise it sits on top of each other (An automatic layout command would be nice).

@m_adam

Thanks for the reference!