Particle group instance 'Use Count' value gets reset on file-load.
Closed, ArchivedPublic

Description

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.

mpan3 (Mike Pan) set Type to Bug.Via Old WorldMar 31 2011, 11:25 PM
dfelinto (Dalai Felinto) added a comment.Via Old WorldMar 31 2011, 11:46 PM

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

dfelinto (Dalai Felinto) added a comment.Via Old WorldApr 5 2011, 11:09 PM

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.

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.

dfelinto (Dalai Felinto) added a comment.Via Old WorldJul 6 2011, 3:02 AM

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)

jhk (Janne Karhu) added a comment.Via Old WorldJul 15 2011, 3:32 PM

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.

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)

zeauro (ronan ducluzeau) added a comment.Via Old WorldAug 17 2011, 7:51 PM

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.

mpan3 (Mike Pan) added a comment.Via Old WorldSep 14 2011, 2:19 AM

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

lukastoenne (Lukas Toenne) added a comment.Via Old WorldNov 29 2011, 8:26 PM

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 :)

jhk (Janne Karhu) added a comment.Via Old WorldNov 30 2011, 5:23 AM

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.

lukastoenne (Lukas Toenne) added a comment.Via Old WorldNov 30 2011, 9:16 AM

reassigned to Campbell for fixing the library linking stuff

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 (Ton Roosendaal) added a comment.Via Old WorldFeb 16 2013, 5:04 PM

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...

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

jtheninja (Jason Clarke) added a comment.Via Old WorldJun 14 2013, 12:57 AM

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

sergey (Sergey Sharybin) added a comment.Via Old WorldNov 6 2013, 9:56 AM

Closed duplicate report [#37321]

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,

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.

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

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

lukastoenne (Lukas Toenne) closed this task as "Archived".Via WebJun 6 2014, 8:39 AM

Add Comment