Node animation, removing nodes keeps FCurves.
Closed, ResolvedPublic

Description

In the attached file:
- delete the composite node.
- add a new composite node.
... notice the new nodes button is still animated.

This is a bug, removing the node should remove the animation data too.

dingto (Thomas Dinges) added a comment.Via Old WorldSep 24 2012, 7:17 PM

Joshua, can you please check? :)

ton (Ton Roosendaal) added a comment.Via Old WorldOct 19 2012, 5:49 PM

Another bump for Joshua! Although I presume he could use another maintainer to help doing animsys issues...

zeauro (ronan ducluzeau) added a comment.Via Old WorldOct 23 2012, 7:01 PM

Same problem occurs for almost everything (nodes, modifiers, shapes ...)

dfelinto (Dalai Felinto) added a comment.Via Old WorldOct 1 2013, 6:18 PM

fixed on r60495, thanks for the report Campbell ;)
I will fix modifiers and others separately.

dfelinto (Dalai Felinto) closed this task as "Resolved".Via Old WorldOct 1 2013, 6:18 PM
dfelinto (Dalai Felinto) added a comment.Via Old WorldOct 1 2013, 7:56 PM

(modifiers and others will be postponed actually. Bassam raised some points towards not changing that)

bassamk (bassam kurdali) added a comment.Via Old WorldOct 1 2013, 8:32 PM

I'm chiming in here for the record:
blender currently refers to objects by name. i.e. animation curves point to object names
this causes *a lot* of side effects.
the fixes to these side effects (such as this fix) can be worse than than the disease, i.e. : you are now deleting user data, potentially data that took a lot longer to create (animation is time consuming!!!) than adding/deleting a node.
for general case (i.e. modifiers bones etc.) it would be better to postpone fixing this, since especially with bones, it would result in havoc of removed animation, faaaar more expensive and irreplacable than deleting an animation channel when figuring out the problem.

The situation is made worse when users are not in the habit of naming things. nodes are terrible in this regard, since the name isn't even exposed anywhere, just the label.
One possible non destructive solution is not to re-assign automatic names (i.e. if Node.001 has been used, not to make a new node called Node.001)

This could be made better if data had, in addition to a name, a uid of some sort. Not user editable, and reasonably guaranteed not to have collisions within the scope it is active in. But this sort of change is pretty big and might also be worth postponing to make a good design for it: for instance, it might impact action reusability on different armatures with same bone names but different uids.

Add Comment