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.
 

Attached Files:

Name Date Download
node_animation_bug.blend 2011-03-02 16:51 Download

Changes:

Field Old Value Date By
status_idOpen2011-03-11 04:27aligorith
close_dateNone2011-03-11 04:27aligorith
StatusReopened2011-03-11 04:27aligorith
status_idClosed2011-03-02 18:04ton
close_date2011-03-01 18:022011-03-02 18:04ton
assigned_toton2011-03-02 18:04ton
StatusClosed2011-03-02 18:04ton
File Added15199: node_animation_bug.blend2011-03-02 16:51dsavi
status_idOpen2011-03-01 18:02ton
close_dateNone2011-03-01 18:02ton
StatusInvestigate2011-03-01 18:02ton
assigned_toaligorith2011-02-27 10:46aligorith
assigned_tonone2011-02-22 14:50ton
StatusNew2011-02-22 14:50ton