Data loss between saves for custom node trees #36024

New Issue

Paul Kilgo · 2013-07-05T20:45:09+02:00

Paul Kilgo commented

2013-07-05 20:45:09 +02:00

%%%--- Operating System, Graphics card ---
Ubuntu 13.04, Radeon HD 5000/6000/7350 Series

- Blender version with error, and version that worked ---

Nightly build, r58014
2.68-RC

No known working version.

- Short description of error ---

Between saves, Blender appears to lose node tree/node data when using a simple custom node editor.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Install and enable nodetest.py as an add-on for blender, save user preferences
Open example.blend
Make some changes (add/duplicate nodes) and save (either save over, save as, save copy, does not seem to matter)
Close/reopen blender
Open example.blend again, or a copy of it.

Expected behavior: changes persist

Observed behavior: node tree and nodes are missing
%%%

%%%--- Operating System, Graphics card --- Ubuntu 13.04, Radeon HD 5000/6000/7350 Series - Blender version with error, and version that worked --- Nightly build, r58014 2.68-RC No known working version. - Short description of error --- Between saves, Blender appears to lose node tree/node data when using a simple custom node editor. - Steps for others to reproduce the error (preferably based on attached .blend file) --- 1. Install and enable nodetest.py as an add-on for blender, save user preferences 2. Open example.blend 3. Make some changes (add/duplicate nodes) and save (either save over, save as, save copy, does not seem to matter) 4. Close/reopen blender 5. Open example.blend again, or a copy of it. Expected behavior: changes persist Observed behavior: node tree and nodes are missing %%%

Paul Kilgo commented

2013-07-05 20:45:09 +02:00

Changed status to: 'Open'

Brecht Van Lommel commented

2013-07-06 14:00:17 +02:00

%%%This is standard Blender behavior, if a datablock has 0 users (as shown in the node menu), it will be removed by the garbage collector the next time you load the file. The same happens for materials, textures, meshes, .. . You can press the F (fake user) button to keep the nodes even if there is not other datablock using this node.

There is a big missing feature in the python API though, which is that you can't actually define create such links between datablocks yet. Hopefully that will be added soon, for now I guess the workaround is to enable the F button.
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes%%%

%%%This is standard Blender behavior, if a datablock has 0 users (as shown in the node menu), it will be removed by the garbage collector the next time you load the file. The same happens for materials, textures, meshes, .. . You can press the F (fake user) button to keep the nodes even if there is not other datablock using this node. There is a big missing feature in the python API though, which is that you can't actually define create such links between datablocks yet. Hopefully that will be added soon, for now I guess the workaround is to enable the F button. http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.67/Python_Nodes%%%

Lukas Tönne commented

2013-07-08 13:52:12 +02:00

%%%Yes, the issue with missing data block references (pointer properties) needs to be solved. However, it is not the actual issue in this case.

The problem has 2 parts:

The node editor space has a pointer property to the currently edited node tree. The type of node tree is checked for validity on loading, i.e. if the type of the linked node tree is not registered it gets reset to NULL. Now, when an addon is not enabled globally but only in a specific file all the types it registers only get registered after the data is loaded, at which point the node editor tree is already reset.

This behavior was a precaution to avoid invalid data access, but should not actually be needed any longer. The editor will just display dummy nodes in flashy red warning color in case the types really don't get registered after loading.

For standard trees this pointer usually gets set from context based on the active material etc. (you can implement that for pynodes as well using - ). In that case the node editor space does not increment the user count, as it just references data from the context. But in the case of custom pynode trees from bpy.data.node_groups these trees are not actually referenced anywhere else - so the data blocks are considered unused and get discarded. For now i've changed user counting in the editor along the same lines as image editor: add an "real" user for the editor to avoid losing transient, unlinked data blocks.

Ultimately of course we want to link such trees in other places, at which point the bpy pointer property enters again. If you are interested, i've made a little workaround for "simulating" such properties (- [x], see IDRefProperty function and IDRefContainer decorator), example usage in - [x]. They simply store the name string and wrap a python property around it to return a true pointer, depending on property option also sets fake user by default to avoid user count problems.

The bug is fixed in SVN. Thanks for reporting!

http://www.blender.org/documentation/blender_python_api_2_67_1/bpy.types.NodeTree.html#bpy.types.NodeTree.get_from_context
https://www.gitorious.org/blender-trunk/addons/blobs/geometry_nodes/py/scripts/addons/geometry_nodes/util.py
https://www.gitorious.org/blender-trunk/addons/blobs/geometry_nodes/py/scripts/addons/geometry_nodes/node_group.py%%%

%%%Yes, the issue with missing data block references (pointer properties) needs to be solved. However, it is not the actual issue in this case. The problem has 2 parts: 1) The node editor space has a pointer property to the currently edited node tree. The type of node tree is checked for validity on loading, i.e. if the type of the linked node tree is not registered it gets reset to NULL. Now, when an addon is not enabled globally but only in a specific file all the types it registers only get registered *after* the data is loaded, at which point the node editor tree is already reset. This behavior was a precaution to avoid invalid data access, but should not actually be needed any longer. The editor will just display dummy nodes in flashy red warning color in case the types really don't get registered after loading. 2) For standard trees this pointer usually gets set from context based on the active material etc. (you can implement that for pynodes as well using - [x]). In that case the node editor space does not increment the user count, as it just references data from the context. But in the case of custom pynode trees from bpy.data.node_groups these trees are not actually referenced anywhere else - so the data blocks are considered unused and get discarded. For now i've changed user counting in the editor along the same lines as image editor: add an "real" user for the editor to avoid losing transient, unlinked data blocks. Ultimately of course we want to link such trees in other places, at which point the bpy pointer property enters again. If you are interested, i've made a little workaround for "simulating" such properties (- [x], see IDRefProperty function and IDRefContainer decorator), example usage in - [x]. They simply store the name string and wrap a python property around it to return a true pointer, depending on property option also sets fake user by default to avoid user count problems. The bug is fixed in SVN. Thanks for reporting! - [x] http://www.blender.org/documentation/blender_python_api_2_67_1/bpy.types.NodeTree.html#bpy.types.NodeTree.get_from_context - [x] https://www.gitorious.org/blender-trunk/addons/blobs/geometry_nodes/py/scripts/addons/geometry_nodes/util.py - [x] https://www.gitorious.org/blender-trunk/addons/blobs/geometry_nodes/py/scripts/addons/geometry_nodes/node_group.py%%%

Lukas Tönne commented

2013-07-08 13:52:12 +02:00

Changed status from 'Open' to: 'Resolved'

Lukas Tönne closed this issue

2013-07-08 13:52:12 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Data loss between saves for custom node trees #36024