Object linked to scene, is not updated correctly in GroupInstance (objects with face users) #47482

Closed
opened 7 years ago by JoseConseco · 14 comments

System Information
Win 7 64bit

Blender Version
Build from here: http://blenderartists.org/forum/showthread.php?392846-New-2-77-blender-bug-release!
Broken: 2.77 Testbuild 1
Worked: not sure if it ever worked ok.

Short description of error
Basically there is problem with deleting object from group using x-key.
lets say have cube object in group.
When I delete objects using X-key, it is not deleted from GroupInstance (meaning object is somehow still linked to group, I think). This happens only for object that are freshly linked to scene. See blend file below - with simple script for linking obj to scene.

Exact steps for others to reproduce the error
short gif with bug
In attached blend file BugGroupDelete2.blend I have two groups named 'Working' and 'NotWorking' each made of 2 cubes.
Also for each group I added one groupInstance object (shift+a->GroupInstance).
Cubes from working group (redcolor) are linked to scene and when I delete any of those cubes (x-key), they disappear from groupInstance - this is ok.
Now cubes from 'NotWorking' group (yellow) are not linked to scene, so you just run script from text editor, to link those 2 cubes to scene. When you now delete any of those cubes (x-key) the are gone from scene, but not from GroupInstances. Somehow those cubes are not deleted from group.

**System Information** Win 7 64bit **Blender Version** Build from here: http://blenderartists.org/forum/showthread.php?392846-New-2-77-blender-bug-release! Broken: 2.77 Testbuild 1 Worked: not sure if it ever worked ok. **Short description of error** Basically there is problem with deleting object from group using x-key. lets say have cube object in group. When I delete objects using X-key, it is not deleted from GroupInstance (meaning object is somehow still linked to group, I think). This happens only for object that are freshly linked to scene. See blend file below - with simple script for linking obj to scene. **Exact steps for others to reproduce the error** [short gif with bug ](https://i.imgur.com/LNu0KzH.gifv) In attached blend file [BugGroupDelete2.blend](https://archive.blender.org/developer/F283800/BugGroupDelete2.blend) I have two groups named 'Working' and 'NotWorking' each made of 2 cubes. Also for each group I added one groupInstance object (shift+a->GroupInstance). Cubes from working group (**red**color) are linked to scene and when I delete any of those cubes (x-key), they disappear from groupInstance - this is ok. Now cubes from 'NotWorking' group (**yellow**) are not linked to scene, so you just run script from text editor, to link those 2 cubes to scene. When you now delete any of those cubes (x-key) the are gone from scene, but not from GroupInstances. Somehow those cubes are not deleted from group.
Poster

Changed status to: 'Open'

Changed status to: 'Open'
Poster

Added subscriber: @JoseConseco

Added subscriber: @JoseConseco
Owner

Added subscriber: @ideasman42

Added subscriber: @ideasman42
Owner

The objects have fake users, print(bpy.data.objects['Cube.001'].use_fake_user)

IIRC there is no way to enable this via the UI, though it could have been done via Python. we could change this P324, though its not a very common open for objects.

The objects have fake users, `print(bpy.data.objects['Cube.001'].use_fake_user)` IIRC there is no way to enable this via the UI, though it could have been done via Python. we could change this [P324](https://archive.blender.org/developer/P324.txt), though its not a very common open for objects.
ideasman42 changed title from Object linked to scene, is not updated correctly in GroupInstance. to Object linked to scene, is not updated correctly in GroupInstance (objects with face users) 7 years ago
Poster

ah, ok. But then still even if I link obj to scene, and then do:
bpy.data.objects['Cube'].use_fake_user=False

And delete 'Cube' with X key, it is not deleted from group.
Now I just tested this on older blender builds (with fake_user=False), and:

  • deleting works ok on another PC -where no testbuild was installed (meaning object is deleted from group, when use_fake_user=False).
  • on PC where I installed testbuild 2.77 deletion won't work even on old builds. But I'm sure It worked before installing testbuild 1. So somehow testbuild broke my script even on older blender... Only using 'user_clear' on yellow cubes works-cubes are deleted permanently from group, but there was no need for this trick before testbuild.

ps. I think there is not need for UI for fake_users, because this is mostly usefull for python scripting.

ah, ok. But then still even if I link obj to scene, and then do: bpy.data.objects['Cube'].use_fake_user=False And delete 'Cube' with X key, it is not deleted from group. Now I just tested this on older blender builds (with fake_user=False), and: - deleting works ok on another PC -where no testbuild was installed (meaning object is deleted from group, when use_fake_user=False). - on PC where I installed testbuild 2.77 deletion won't work even on old builds. But I'm sure It worked before installing testbuild 1. So somehow testbuild broke my script even on older blender... Only using 'user_clear' on yellow cubes works-cubes are deleted permanently from group, but there was no need for this trick before testbuild. ps. I think there is not need for UI for fake_users, because this is mostly usefull for python scripting.
Poster

I think I found the reason for buggy behavior.
Basically I blend file below we have red and yellow objects:

  • yellow object is member of 'NotWorking' group
  • red object is member of 'Working' group.
    The only difference is - yellow object is linked to scene when script, from text editor, is executed (this time I set fake_users to False).
    So in theory both yellow and red object should have 2 users (bpy.context.object.users): first user is group and second is scene. But red object has only single user, even though he is member of 'Working' group and scene (2 users).
    I guess this is why deleting -bpy.ops.object.delete()- red object has different result, from deleting yellow object.
    Maybe delete operator should force number of users to be 0 (bpy.context.object.user_clear()), so that object is deleted correctly from group too?

Blend file with slightly modified script (fake users set to false, and it prints number of users of red and yellow objects)
ObjectUsers.blend

I think I found the reason for buggy behavior. Basically I blend file below we have red and yellow objects: - yellow object is member of 'NotWorking' group - red object is member of 'Working' group. The only difference is - yellow object is linked to scene when script, from text editor, is executed (this time I set fake_users to False). So in theory both yellow and red object should have 2 users (bpy.context.object.users): first user is group and second is scene. But red object has only single user, even though he is member of 'Working' group and scene (2 users). I guess this is why deleting -bpy.ops.object.delete()- red object has different result, from deleting yellow object. Maybe delete operator should force number of users to be 0 (bpy.context.object.user_clear()), so that object is deleted correctly from group too? Blend file with slightly modified script (fake users set to false, and it prints number of users of red and yellow objects) [ObjectUsers.blend](https://archive.blender.org/developer/F283934/ObjectUsers.blend)
mont29 commented 7 years ago
Owner

Added subscriber: @mont29

Added subscriber: @mont29
mont29 self-assigned this 7 years ago
mont29 commented 7 years ago
Owner

Group 'usage' is a 'USER_ONE' type, i.e. (to simplfy) it does not increase usercount, but it requires at least one user. So red cubes' usercount is (or rather, could be) OK, and yellows' one is too. But behavior of yellow cube deletion is broken.

There is no reason for an object to vanish from a group once it gets removed from a scene, this sounds like undesired side-effect behavior to me, typical of how Blender used to handle 'USER_ONE' case, in a very broken way. This is supposed to be fixed in 2.77 (but only when starting from clean sane state, older files already broken won't be fixed re IDs usercount).

Object shall be removed from group with group.objects.unlink method, just like with scene.

So to me, bug here is with those red cubes (you can easily reproduce same behavior with default cube, group it, instance that group, delete cube object, it gets removed from group - this shall not happen anymore). Will investigate.

Group 'usage' is a 'USER_ONE' type, i.e. (to simplfy) it does not increase usercount, but it **requires at least one user**. So red cubes' usercount is (or rather, could be) OK, and yellows' one is too. But behavior of yellow cube deletion is broken. There is no reason for an object to vanish from a group once it gets removed from a scene, this sounds like undesired side-effect behavior to me, typical of how Blender used to handle 'USER_ONE' case, in a very broken way. This is supposed to be fixed in 2.77 (but only when starting from clean sane state, older files already broken won't be fixed re IDs usercount). Object shall be removed from group with `group.objects.unlink` method, just like with scene. So to me, bug here is with those red cubes (you can easily reproduce same behavior with default cube, group it, instance that group, delete cube object, it gets removed from group - this shall not happen anymore). Will investigate.
Collaborator

This issue was referenced by 4dd406c7b7

This issue was referenced by 4dd406c7b7bb26742a3d13f950b28c9b071766a9
mont29 commented 7 years ago
Owner

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
mont29 closed this issue 7 years ago
Poster

Thanks for quick bug fix :)
However I liked how bpy.ops.object.delete() worked previously (unlinking from scene, and group at same time) :( . I mean for most applications, when user deletes something - it is gone. It was unexpected for me (and I'm sure for other users too), that after deleting object, it was still present as group member, that it why I reported it as bug.
So maybe those three operations could be split in future : unlinking from group, from scene, deletion (unlinking from everything). But I guess this should be reported as new task, right?

Thanks for quick bug fix :) However I liked how bpy.ops.object.delete() worked previously (unlinking from scene, and group at same time) :( . I mean for most applications, when user deletes something - it is gone. It was unexpected for me (and I'm sure for other users too), that after deleting object, it was still present as group member, that it why I reported it as bug. So maybe those three operations could be split in future : unlinking from group, from scene, deletion (unlinking from everything). But I guess this should be reported as new task, right?
mont29 commented 7 years ago
Owner

Yes, I see how previous behavior kinda looked OK… But imho it was not - e.g. if you linked a same object in several scenes, then what would you expect? that it gets removed from its groups only when you have deleted it from all scenes? that pressing X would immediately remove it from all scenes and groups altogether? Those are more like design decisions…

Point is, 2.77 fixes that inconsistency (we had similar ones with e.g. images when used by ImageEditor and texture, etc.), and now has a consistent behavior. If we want to also remove objects from their group when deleting them from all scenes, then this has to be implemented on the operator level. Think a lot of issues here also comes form the fact that user cannot actually manage object datablock itself (you only have access to it through its instantiations, either directly by scenes, or indirectly through groups). But that’s no bug. ;)

Yes, I see how previous behavior kinda looked OK… But imho it was not - e.g. if you linked a same object in several scenes, then what would you expect? that it gets removed from its groups only when you have deleted it from all scenes? that pressing X would immediately remove it from all scenes and groups altogether? Those are more like design decisions… Point is, 2.77 fixes that inconsistency (we had similar ones with e.g. images when used by ImageEditor and texture, etc.), and now has a consistent behavior. If we want to also remove objects from their group when deleting them from all scenes, then this has to be implemented on the operator level. Think a lot of issues here also comes form the fact that user cannot actually manage object datablock itself (you only have access to it through its instantiations, either directly by scenes, or indirectly through groups). But that’s no bug. ;)
Poster

Yep, I totally agree this bug had to be fixed. But I was thinking about 'operator level' design change, as you described it. So the change would be:

  • change current bpy.ops.object.delete -> to bpy.ops.object.unlink (because this is what delete operator is currently doing)
  • bpy.ops.object.delete - would be new operator now -> completely deleting object from scene, groups etc. It would behave as delete operation in other apps,
  • bpy.ops.group.objects_remove(group='xxx') - no change here. This operator does what is says, unlike delete operator IMO.

English is not my native language, so maybe it wasn't clear, but this is what I was thinking about in previous post.
I have already overrode x-key with new 'real' delete operator in python, so I'm happy now :). But I'm thinking, that maybe you could implement this change in blender source code, so other users could benefit from it.

Yep, I totally agree this bug had to be fixed. But I was thinking about 'operator level' design change, as you described it. So the change would be: - change current bpy.ops.object.delete -> to bpy.ops.object.unlink (because this is what delete operator is currently doing) - bpy.ops.object.delete - would be new operator now -> completely deleting object from scene, groups etc. It would behave as delete operation in other apps, - bpy.ops.group.objects_remove(group='xxx') - no change here. This operator does what is says, unlike delete operator IMO. English is not my native language, so maybe it wasn't clear, but this is what I was thinking about in previous post. I have already overrode x-key with new 'real' delete operator in python, so I'm happy now :). But I'm thinking, that maybe you could implement this change in blender source code, so other users could benefit from it.
Collaborator

This issue was referenced by 20104beea7

This issue was referenced by 20104beea7d3bbcc32108fae935270503c251e54
Sign in to join this conversation.
No Label
Interest/Alembic
Interest/Animation & Rigging
Interest/Asset Browser
Interest/Asset Browser Project Overview
Interest/Audio
Interest/Automated Testing
Interest/Blender Asset Bundle
Interest/Collada
Interest/Compositing
Interest/Core
Interest/Cycles
Interest/Dependency Graph
Interest/Development Management
Interest/Eevee & Viewport
Interest/Freestyle
Interest/Geometry Nodes
Interest/Grease Pencil
Interest/ID Management
Interest/Images & Movies
Interest/Import/Export
Interest/Line Art
Interest/Masking
Interest/Modeling
Interest/Modifiers
Interest/Motion Tracking
Interest/Nodes & Physics
Interest/Overrides
Interest/Performance
Interest/Performance
Interest/Physics
Interest/Pipeline, Assets & I/O
Interest/Platforms, Builds, Tests & Devices
Interest/Translations
Interest/Undo
Interest/USD
Interest/Video Sequencer
legacy module/Animation & Rigging
legacy module/Core
legacy module/Development Management
legacy module/Eevee & Viewport
legacy module/Grease Pencil
legacy module/Modeling
legacy module/Nodes & Physics
legacy module/Pipeline, Assets & IO
legacy module/Platforms, Builds, Tests & Devices
legacy module/Python API
legacy module/Rendering & Cycles
legacy module/Sculpt, Paint & Texture
legacy module/Triaging
legacy module/User Interface
legacy module/VFX & Video
legacy project/1.0.0-beta.2
legacy project/Asset Browser (Archived)
legacy project/BF Blender: 2.8
legacy project/BF Blender: After Release
legacy project/BF Blender: Next
legacy project/BF Blender: Regressions
legacy project/BF Blender: Unconfirmed
legacy project/Blender 2.70
legacy project/Code Quest
legacy project/Datablocks and Libraries
legacy project/Eevee
legacy project/Game Animation
legacy project/Game Audio
legacy project/Game Data Conversion
legacy project/Game Engine
legacy project/Game Logic
legacy project/Game Physics
legacy project/Game Python
legacy project/Game Rendering
legacy project/Game UI
legacy project/GPU / Viewport
legacy project/GSoC
legacy project/Infrastructure: Websites
legacy project/LibOverrides - Usability and UX
legacy project/Milestone 1: Basic, Local Asset Browser
legacy project/Nodes
legacy project/OpenGL Error
legacy project/Papercut
legacy project/Pose Library Basics
legacy project/Python API
legacy project/Render & Cycles
legacy project/Render Pipeline
legacy project/Retrospective
legacy project/Sculpt, Paint & Texture
legacy project/Text Editor
legacy project/Tracker Curfew
legacy project/Triaging
legacy project/User Interface
legacy project/UV Editing
legacy project/VFX & Video
legacy project/Virtual Reality
legacy project/Wintab High Frequency
Meta/Good First Issue
Meta/Papercut
migration/requires-manual-verification
Module › Animation & Rigging
Module › Core
Module › Development Management
Module › Eevee & Viewport
Module › Grease Pencil
Module › Modeling
Module › Nodes & Physics
Module › Pipeline, Assets & IO
Module › Platforms, Builds, Tests & Devices
Module › Python API
Module › Render & Cycles
Module › Sculpt, Paint & Texture
Module › Triaging
Module › User Interface
Module › VFX & Video
Platform/FreeBSD
Platform/Linux
Platform/macOS
Platform/Windows
Priority › High
Priority › Low
Priority › Normal
Priority › Unbreak Now!
Status › Archived
Status › Confirmed
Status › Duplicate
Status › Needs Information from Developers
Status › Needs Information from User
Status › Needs Triage
Status › Resolved
Type › Bug
Type › Design
Type › Known Issue
Type › Patch
Type › Report
Type › To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#47482
Loading…
There is no content yet.