Only search projects.blender.org
Log In
New Account
Home
My Page
Projects
Blender 2.x BF release
Summary
Activity
Tracker
SCM
Files
Blender 2.6 Bug Tracker: Browse
[#26167] Animating inside group nodes behaves strangely
Date:
2011-02-21 18:42
Priority:
3
State:
Closed
Submitted by:
Davis Sorenson (
dsavi
)
Assigned to:
Joshua Leung (aligorith)
Category:
Animation system
Status:
Fixed / Closed
Relates to:
Duplicates:
Patches:
Summary:
Animating inside group nodes behaves strangely
Detailed description
Animating inside group nodes behaves strangely; In one case it causes an error, in another (Similar case) it will insert keyframes for the same type of node that is outside of the node group.
1. Create a node group containing a couple of nodes
2. Try to insert a keyframe for one of the properties
An error pops up.
3. Close the node group
4. Add a node of the same type as one of the nodes inside the node group
5. Open the node group again
6. Insert a keyframe on one of the properties of the node outside of the node group
The node of the same type inside the node group gets a keyframe inserted too, on the same property.
Followup
Message
Date
: 2011-02-22 14:50
Sender
:
Ton Roosendaal
I know Joshua has worked a bit on node animation, but for groups things were not working.
The issue is that fcurves find the node to work on based on a unique identifier, in the node group case this messes up... I need Joshua's feedback first, and he's probably cleaning up now after a massive earthquake in his town :/
Date
: 2011-02-27 10:46
Sender
:
Joshua Leung
Hi, I cannot reproduce the exact issue specified here in current trunk (35210).
Perhaps this is just a bug that we've fixed long ago already - certainly with the recent node-group changes, this may/may not have been an issue caused by some incomplete work there or may even have been inadvertently fixed already.
I'm aware that last time I checked, there were some issues with the RNA-pointer context that buttons in node-grouped nodes had (basically they were for some reason still using the "main" nodetree vs the group's nodetree). This was strange, since only a while earlier, I remember specifically managing to fix this issue and having everything work ok. At least when trying to test this bug earlier, I couldn't reproduce it - everything seemed to be working as it should.
Reassigning to Ton
Date
: 2011-03-01 18:02
Sender
:
Ton Roosendaal
I'll wait for Davis to test it on recent svn, and then provide us a demo .blend with the issue.
he can post that here then, and I'll reopen :)
Date
: 2011-03-02 16:51
Sender
:
Davis Sorenson
Attached a file that should demonstrate the bug. I forgot to mention my system and revision; I'm on the latest SVN at the moment at r35302, Ubuntu 10.10 32bit.
Date
: 2011-03-02 18:04
Sender
:
Ton Roosendaal
Curent svn:
- RMB on the blur node in the group, doesn't give option to insert key
- Adding blur node outside the group, it does allow me to insert keys. It then colors the group-node too, but values don't change in the group.
- Also: the menu for the group-blur node then allows to insert keys, but it doesnt work.
Conclusion:
- are group-node fcurves currently not allowed?
- code for UI buttons to find the fcurve here is not correct.. but it calls fcurve api here
Date
: 2011-03-03 12:29
Sender
:
Joshua Leung
Fundamentally I still think it's basically an issue with which NodeTree ID-block the buttons think they belong to. The keyframing-api just blindly takes whatever ID+path combination you chuck at it, checking if it can access the specified property (hence the error), so it's the responsibility of the caller (UI buttons there) to have the right ID-context set.
When testing this, trying to insert a keyframe for the blur node (inside the group) shows that UI buttons for that node think that they are still in the scene->ntree (i.e. Compositing Nodetree) vs a NodeGroup. This suggests that it's just something to do with the way that the buttons are set up for drawing (and hopefully not something more sinister deep inside the UI code internals). What exactly it is though will require some detailed checking which I don't have time for now.
Date
: 2011-03-11 04:27
Sender
:
Joshua Leung
Fixed in svn.
Attached Files:
Name
Date
Download
node_animation_bug.blend
2011-03-02 16:51
Download
Changes:
Field
Old Value
Date
By
status_id
Open
2011-03-11 04:27
aligorith
close_date
None
2011-03-11 04:27
aligorith
Status
Reopened
2011-03-11 04:27
aligorith
status_id
Closed
2011-03-02 18:04
ton
close_date
2011-03-01 18:02
2011-03-02 18:04
ton
assigned_to
ton
2011-03-02 18:04
ton
Status
Closed
2011-03-02 18:04
ton
File Added
15199: node_animation_bug.blend
2011-03-02 16:51
dsavi
status_id
Open
2011-03-01 18:02
ton
close_date
None
2011-03-01 18:02
ton
Status
Investigate
2011-03-01 18:02
ton
assigned_to
aligorith
2011-02-27 10:46
aligorith
assigned_to
none
2011-02-22 14:50
ton
Status
New
2011-02-22 14:50
ton