--- Operating System, Graphics card ---
gnu/linux 64 bit, nvidia gfx
--- Blender version with error, and version that worked ---
r59113 has the bug, version working = unknown.
--- Short description of error ---
In the particle instance modifier there is a position option to position the instances along the particles at a certain position from 0 to 1.
below it is a random option, presumable to randomize the positions of the instances, this does not work, instead snapping all particles to the 0 position.
--- Steps for others to reproduce the error (preferably based on attached .blend file) ---
- open the attached .blend
play with the position slide to observe how it works
now play with the random slider.
Description
Description
Event Timeline
Comment Actions
I'm seeing the same thing in my builds at revision 59138. I also saw that official release 2.67b also has the bug, whereas 2.66a does not; the random position behaves as expected. I might go hunting for the commit tonight if I'm not doing anything else.
Comment Actions
Everyone hates particle bugs!
Jeffrey - if you could help finding the commit, it would be very welcome :)
Comment Actions
git annotate shows me it was r56073 from Brecht
specifically this change from MOD_particleinstance.c:
- BLI_srandom(psys->seed + p);
- ran = pimd->random_position * BLI_frand();
+ ran = pimd->random_position * BLI_hash_frand(psys->seed + p);
Tested reverting the change and indeed it works, but should be looked at by Brecht or someone more knowledgeable then me of why the change was made and why it isn't working.
Comment Actions
I'm not sure I fully understand it but it seems that in the return of BLI_hash_frand there is an implicit conversion from int to the expected float, which is probably undefined behaviour. I would have thought the compiler or static analysis would have given a warning but I'm not sure.
This diff in that function fixed the issue for me:
- return (int)(((MULTIPLIER * X + ADDEND) & MASK) >> 17);
+ return (float)((int)(((MULTIPLIER * X + ADDEND) & MASK) >> 17)) / 0x80000000;
This also makes it consistent with how BLI_frand was returned.
Comment Actions
Fixed in r59713, thanks for the report! :)
@Anthony Edlin: many thanks for your "tracking bug" work!