0
$\begingroup$

I’m a contributor to this Blender addon, which enables Blender to import/export a specialized model format for a video game. The number of custom properties needed to fully represent all the needed values is quite extensive.

The problem is when any of these custom properties are animated. For example, if an “M3 Particle” is added to the scene, performance will be OK, but if a keyframe is then added to any of its animatable properties, than the performance takes a very noticeable hit, particularly the UI will refresh very slowly, which makes working with these custom properties rather frustrating.

I have a suspicion that it is somehow related to the fact all of the custom properties exist as an extension to the scene's properties, but I don't know what solution could be come to, to actually resolve this issue without fundamentally changing the manner in which the custom data is stored. It is ideal to not do that in order to maintain backwards compatibility.

$\endgroup$
2
  • 1
    $\begingroup$ It may be more helpful to give more information about the properties themselves. How are they used (panels, operators, callbacks)? Do they have a custom update(), get() or set() functions? Do they trigger changes in the scene? Any props in particular that are worse than others? As you said, this may be a low-level issue that is beyond your addon structure. But keep in mind that keyframing will reduce performance in one way or another. $\endgroup$ Oct 18, 2021 at 17:23
  • $\begingroup$ I don't believe any of the animated props have any such functions. It does not seem to matter which gets keyframed, the effect is all the same. And none which are animated have any direct effect on the viewport. $\endgroup$
    – SolStice
    Oct 18, 2021 at 17:33

1 Answer 1

0
$\begingroup$

In a comment, I asked if your props have custom update, get or set functions, I'm referring to the update=<function>,get=..., or set=... set in the prop declaration, for example this one I found in the repo's root init:

bpy.types.Scene.m3_animation_index = bpy.props.IntProperty(update=handleAnimationSequenceIndexChange,...)

And there's many props like this from my brief glance at the addon. update is called just after the prop's value is set. And if the update function is complex (and some look to be - calling other functions, using loops), this will definitely slow the UI, at least temporarily. These callback functions may need to be optimized.

But as you said, you only see the performance dip once the prop is keyframed. Is the performance hit while changing frames, or just right after the value is changed? As much as we'd like to help, there's still little information for us to work with.

For now, my optimization suggestion above is my official answer, but answers may not be helpful unless you give a demonstrable example - ideally a blend file, but a piece of code would do too. Referencing the whole addon isn't really sensible here, especially without a sample where we can narrow the addon scope.

$\endgroup$
2
  • $\begingroup$ The slowing is constant. In cases such as an M3 particle with any keyframes on any number of properties, whether it was just added, or simply exists, the UI will slow down massively, and is not temporary. It will only go away when the UI is no longer drawing them. $\endgroup$
    – SolStice
    Oct 18, 2021 at 19:02
  • $\begingroup$ Good to know. Again, need an example to really analyze further. I will say I agree that this may very well be a low-level Blender architecture issue. If so, a minimal code snippet would demonstrate this :) There's been questions here on performance with Blender operators: blender.stackexchange.com/questions/7358/… $\endgroup$ Oct 18, 2021 at 19:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .