Page MenuHome

group objects and their counts become mismatched in particle system "use count" list
Closed, ArchivedPublic


System Information
Linux Mint 18 Cinnamon 64-bit

Blender Version
Broken: official release 2.79a, latest build 2.79.3 76122bc8f00
Earliest release with bug was 2.78a; 2.78 had a different bug (all counts become 1).

Short description of error
Sometimes particle system's render->group->use count (dupliweight) list will rearrange (alphabetise) object names but not the counts, so they become mismatched.

The bug occurs on changing values in the redo panel, or on loading a saved file.

Exact steps for others to reproduce the error

  1. Add a monkey ("Suzanne")
  2. Add it to a group "test"
  3. Select default cube, add a particle system.
  4. Under particle system->render panel: set render type to group; select "test" for dupli group; enable use count; and set the count for Suzanne to 25.
  5. Add an ico sphere ("Icosphere")
  6. Under object properties->groups panel, add it to the group "test".
  7. Now, EITHER: add another object, and change some value for it in the T-Panel (redo panel); OR save and reload the file (the list will show "no object" at first - mouse over it or something to update it).

EXAMPLE FILE (produced by following steps 1-6 then saving)

Expected Results:
Ideally nothing should change, but if it must, the count list (Suzanne: 25, Icosphere: 1) should become (Icosphere: 1, Suzanne: 25).

What happens instead:
The list becomes (Icosphere: 25, Suzanne: 1).



Event Timeline

Philipp Oeser (lichtwerk) claimed this task.
Philipp Oeser (lichtwerk) triaged this task as Confirmed, Medium priority.

Can confirm this, looking a little further now, but if that gets a timesink, I might need @Bastien Montagne (mont29) to have a look here

possibly related T53628 (but that needs reconfirmation once a solution is found here)

OK, actually group indices seem to update/change on save then reload...
Hm, apparently that has always been the case [checked back to 2.74]

can easily be verified in python, too:

  • add cube, STRG+G
  • check['Group'].objects[0] [should result in 'Cube']
  • add suzanne, add to 'Group'
  • check['Group'].objects[0] [should still result in 'Cube']
  • save file
  • check['Group'].objects[0] [should still result in 'Cube']
  • reload file
  • check['Group'].objects[0] [should now result in 'Suzanne']

If that is the case, then relying on storing the group index in ParticleDupliWeight.index and restoring the objects from that said index is not a good idea, I guess?

stored in write_particlesettings
not restored in lib_link_particlesettings
but in psys_check_group_weights

Hm, what to do? do this namebased instead? Can we change/force above said change of indices before writing the file (so we dont run into the mismatch later?)
Of course I could be missing something, happy to try something more, but kindly asking @Bastien Montagne (mont29) for advice before I sink more time here... [just assign back to me and I will try more]

so group objects are not reordered on read file, but according to Dr @Sergey Sharybin (sergey) bloody depsgraph can reorder them at some point. This is sort of can of worms, and probably not worth spending too much time on it since it will be fixed in 2.8 by CoW (i.e. depsgraph will no longer ever touch to actual DNA data).

So think this can be closed as 'known bug, won't fix in 2.7x, will be fixed in 2.8'?

Philipp Oeser (lichtwerk) closed this task as Archived.Apr 16 2018, 9:37 AM

as @Bastien Montagne (mont29) said, we will archive this then as 'known bug, won't fix in 2.7x, will be fixed in 2.8'