Particle group instance 'Use Count' value gets reset on file-load. #26712

New Issue

Mike Pan · 2011-03-31T23:25:22+02:00

Mike Pan commented

2011-03-31 23:25:22 +02:00

%%%Please see sample file and run LoadMe.blend, notice that the object count (highlights in white in the screenshot) is always reset to zero everytime the file loads. This only happens when using linked groups from an external file.

%%%

%%%Please see sample file and run LoadMe.blend, notice that the object count (highlights in white in the screenshot) is always reset to zero everytime the file loads. This only happens when using linked groups from an external file. %%%

Mike Pan commented

2011-03-31 23:25:22 +02:00

Changed status to: 'Open'

Dalai Felinto commented

2011-03-31 23:46:21 +02:00

%%%Hi Janne, do you think you could take a look at this?
It actually resets to 1. It happens on Blender 2.5beta6 and the 2.57RC.

Thanks
%%%

%%%Hi Janne, do you think you could take a look at this? It actually resets to 1. It happens on Blender 2.5beta6 and the 2.57RC. Thanks %%%

Dalai Felinto commented

2011-04-05 23:09:40 +02:00

%%%Janne, My guess is that by the time it tries to read the particle group elements, the group library hasn't been re-located. So if the pointer is not yet valid it assumes there is no group? Let us know if there are any tests we can help with on our end.%%%

Dalai Felinto commented

2011-05-14 02:19:46 +02:00

%%%Another sample file to test the problem attached (firstframe_bug.zip).

*main.blend - main file, it should start with the right counting, but it fails. change frame to 2 and back to 1 to get the right counting.*main.py - script called automatically at launch time (thanks to the ScriptLink.blend linked in object. It tries to set the right counting for the group objects in the init() function. However when the driver is called this is still too early. So it only works if called later.
*ScriptLink.blend - a "script link" for 2.5. It will call main.init() once, and then main.loop() every time you change frames.*asset.blend - file with a group that is used to build the reef
//reef.blend - a mesh with a Hair particle using the group from asset.blend

It's a more complex file, but it should help to test the problem once the basic file is working.
Thanks Janne.%%%

%%%Another sample file to test the problem attached (firstframe_bug.zip). *main.blend - main file, it should start with the right counting, but it fails. change frame to 2 and back to 1 to get the right counting.*main.py - script called automatically at launch time (thanks to the ScriptLink.blend linked in object. It tries to set the right counting for the group objects in the init() function. However when the driver is called this is still too early. So it only works if called later. *ScriptLink.blend - a "script link" for 2.5. It will call main.init() once, and then main.loop() every time you change frames.*asset.blend - file with a group that is used to build the reef //reef.blend - a mesh with a Hair particle using the group from asset.blend It's a more complex file, but it should help to test the problem once the basic file is working. Thanks Janne.%%%

Dalai Felinto commented

2011-07-06 03:02:33 +02:00

%%%Note, even if we create a script in the Text Editor to set the particles AND set it to 'register' it still fails (so even registered scripts run after the libs are correct)%%%

Janne Karhu commented

2011-07-15 15:32:45 +02:00

%%%Better late than never I guess :), fix committed in r38413. After setting the counts and saving the file again things should now load correctly too. Modifying the group in the library file can still break the connections between the actual objects and the counts, but this really can't be avoided as there's no proper data to relate objects in a linked group between loads.%%%

Dalai Felinto commented

2011-08-03 22:20:33 +02:00

%%%Hi Janne,
there is still a bug when we add another layer into the system. please see the attached "link_par_group.zip".

*asset.blend - two local objects that are part of a Group (Billboards Group)*reef.blend - an object that has a particle system which display the asset group. this object is part of another group called "Reef_Final"
//main.blend - main file, importing the "Reef Final" group as group instance.

Have we gone too deep? or this is something that can be fixed as well?
Thanks

reef.blend sets the usercount with no problems.
main.blend shows the reset usercount (you can see that there is no green obj in reef.blend)%%%

%%%Hi Janne, there is still a bug when we add another layer into the system. please see the attached "link_par_group.zip". *asset.blend - two local objects that are part of a Group (Billboards Group)*reef.blend - an object that has a particle system which display the asset group. this object is part of another group called "Reef_Final" //main.blend - main file, importing the "Reef Final" group as group instance. Have we gone too deep? or this is something that can be fixed as well? Thanks reef.blend sets the usercount with no problems. main.blend shows the reset usercount (you can see that there is no green obj in reef.blend)%%%

ronan ducluzeau commented

2011-08-17 19:51:08 +02:00

%%%You can solve the problem by linking particles' emitter in final blend.

Instead of creating group in reef.blend, you can create a group from the proxy in final blend. %%%

%%%You can solve the problem by linking particles' emitter in final blend. Instead of creating group in reef.blend, you can create a group from the proxy in final blend. %%%

Mike Pan commented

2011-09-14 02:19:18 +02:00

%%%Ronan, your solution doesn't seem to work once you save and reopen the file. The counts value gets reset still.%%%

Lukas Tönne commented

2011-11-29 20:26:57 +01:00

%%%I tried to figure out what exactly is going wrong here, but there is some complicated stuff going on with linking on multiple levels.
The immediate reason this fails is that the dupli group for particle display is not lib_linked at the point the particle settings are linked, so the dup_group->go->ob pointers are invalid. The subsequent check in psys_check_group_weights then removes the weights and replaces all by 1.

The problem then seems to be of a more general nature, regarding the order of lib_link_all calls made in read_libraries:

The first library contains the linked group with the particle system, which lib_links the group itself and the particle settings block (at this point the dupli group has not been linked, leading to the error above!)
The second library link call then also contains the dupli group and display objects, but the particle settings are already tagged and don't try to link again

Might be a simple fix for people with expertise in this area, but not so much for me :)%%%

%%%I tried to figure out what exactly is going wrong here, but there is some complicated stuff going on with linking on multiple levels. The immediate reason this fails is that the dupli group for particle display is not lib_linked at the point the particle settings are linked, so the dup_group->go->ob pointers are invalid. The subsequent check in psys_check_group_weights then removes the weights and replaces all by 1. The problem then seems to be of a more general nature, regarding the order of lib_link_all calls made in read_libraries: - The first library contains the linked group with the particle system, which lib_links the group itself and the particle settings block (at this point the dupli group has not been linked, leading to the error above!) - The second library link call then also contains the dupli group and display objects, but the particle settings are already tagged and don't try to link again Might be a simple fix for people with expertise in this area, but not so much for me :)%%%

Janne Karhu commented

2011-11-30 05:23:30 +01:00

%%%Lukas: nice to see you came to a similar non-conclusion as I did at some point :) I have a feeling this kind of linking is a bit outside of what the current system was designed to handle, so nasty things are bound to happen. If the library & group system gets some refactoring during the pre-mango development sprint I hope that this can get fixed too as currently this goes a bit too deep into the library system design for me too.%%%

Lukas Tönne commented

2011-11-30 09:16:13 +01:00

%%%reassigned to Campbell for fixing the library linking stuff%%%

Campbell Barton commented

2012-10-26 07:35:32 +02:00

%%%fixed use count and linking issue,
51644, 51645.

There is still an issue with firstframe_bug.zip updating.

assigning to Janne (IMHO this would be better as a seperate report, its quite possibly not even a related bug)
%%%

%%%fixed use count and linking issue, 51644, 51645. There is still an issue with firstframe_bug.zip updating. assigning to Janne (IMHO this would be better as a seperate report, its quite possibly not even a related bug) %%%

Ton Roosendaal commented

2013-02-16 17:04:18 +01:00

%%%I loaded firstframe bug, and i notice particle rotation errors... is that the issue?

All particle rotation issues could be collected in a massive todo in wiki...%%%

%%%I loaded firstframe bug, and i notice particle rotation errors... is that the issue? All particle rotation issues could be collected in a massive todo in wiki...%%%

Campbell Barton commented

2013-02-20 13:43:52 +01:00

%%%The issue in firstframe_bug.zip is a glitch on load with particle rotation that corrects after an update/framechange iirc.%%%

Jason Clarke commented

2013-06-14 00:57:42 +02:00

%%%The initial bug appears to have risen again in 57372. Use-count is again getting lost on file load.%%%

Sergey Sharybin commented

2013-11-06 09:56:45 +01:00

%%%Closed duplicate report [#37321]%%%

Riccardo Giovanetti commented

2014-02-10 17:43:19 +01:00

Added subscriber: @Harvester

Riccardo Giovanetti commented

2014-02-10 17:43:19 +01:00

Hello Janne,
from time to time I review some of the oldest bug reports to see if they got fixed despite not being updated or closed. So I created from scratch and saved two files with the official 2.69 release, one with a few primitive meshes grouped together, and a second .blend file from which I linked the grouped meshes in a particle system, attached to a subdivided plane, with "Counts" option enabled. I then noticed the following:

Blender 2.69.0 (r60995), official release: The issue is still there, count values reset to 1 for all items.
Blender 2.69.10 (hash b105d2ac), from the buildbot repository: The issue seems apparently and hopefully to be fixed; when I open the second file with the particle system it keeps the correct count values.

Regards

Hello Janne, from time to time I review some of the oldest bug reports to see if they got fixed despite not being updated or closed. So I created from scratch and saved two files with the official 2.69 release, one with a few primitive meshes grouped together, and a second .blend file from which I linked the grouped meshes in a particle system, attached to a subdivided plane, with "Counts" option enabled. I then noticed the following: - Blender 2.69.0 (r60995), official release: The issue is still there, count values reset to 1 for all items. - Blender 2.69.10 (hash b105d2ac), from the buildbot repository: The issue seems apparently and hopefully to be fixed; when I open the second file with the particle system it keeps the correct count values. Regards

Riccardo Giovanetti commented

2014-03-06 11:35:53 +01:00

Hello Janne,

A quick update on this issue. Tested with the current release candidate 1 of Blender 2.7.0 (hash 19f7f9a) and I can confirm that the use count still works fine when directly linking a group of objects for another file (first level linking) but it doesn't with a second level or multiple level linking as per example file link_par_group.zip.
To be correct, it works at first when you add the linked group reef_final from file reef.blend into a third file (multiple level linking), but the use count is then lost at the next opening of this third file.

About the firstframe_bug. zip example I confirm that the second/multi-level linking works after running first the linked in script and then updating the frame number, at this point the correct use_count is recalculated correctly. Sort of workaround and perhaps a clue on where further investigations can be done.

Hope it's clear enough and thank you for looking into this matter.

Hello Janne, A quick update on this issue. Tested with the current release candidate 1 of Blender 2.7.0 (hash 19f7f9a) and I can confirm that the use count still works fine when directly linking a group of objects for another file (first level linking) but it doesn't with a second level or multiple level linking as per example file link_par_group.zip. To be correct, it works at first when you add the linked group reef_final from file reef.blend into a third file (multiple level linking), but the use count is then lost at the next opening of this third file. About the firstframe_bug. zip example I confirm that the second/multi-level linking works after running first the linked in script and then updating the frame number, at this point the correct use_count is recalculated correctly. Sort of workaround and perhaps a clue on where further investigations can be done. Hope it's clear enough and thank you for looking into this matter.

Janne Karhu was unassigned by Sergey Sharybin

2014-05-29 10:14:03 +02:00

Lukas Tönne was assigned by Sergey Sharybin

2014-05-29 10:14:03 +02:00

Sergey Sharybin commented

2014-05-29 10:14:03 +02:00

@LukasTonne, shall we consider it TODO as a part of particles re-work project?

Lukas Tönne commented

2014-05-29 10:41:51 +02:00

Yes, no point in trying to fix this i guess.

Lukas Tönne commented

2014-06-06 08:39:59 +02:00

Changed status from 'Open' to: 'Archived'

Lukas Tönne closed this issue

2014-06-06 08:39:59 +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

Particle group instance 'Use Count' value gets reset on file-load. #26712