Page MenuHome

Can't dynamically set particle birth time any more
Closed, ResolvedPublic


System Information
Ubuntu 14.10, Intel i5 and i7, nVidia and ATI cards

Blender Version
Broken: 2.70a f93bc76 Backport revisions for the 2.70a release
Broken: rB78c491e Fix T35247: Particle texture behaves incorrectly after changing the number of particles
Worked: rB9800ed5 Code cleanup: replace magic constants with more verbose bitnames
Worked: 2.69 r60991 1b6b47c

It seems that the bug was introduced in rB78c491e.

Short description of error
Previously, it was possible to use Python to change the birth_time of a particle during an animation. This allowed full control over where and when the particles would spawn. But now it fails: particles kind of insist on being born at the natural time, and the locations and velocities are wrong.

Exact steps for others to reproduce the error

  1. Load attached
  2. Play the animation. The emitter should move left-to-right, emitting particles at a constant rate, like this:
  3. Reload the file.
  4. Run the smash script. The script uses a frame_change_pre callback to detect collisions and cause particles to be born.
  5. Play the animation. The emitter should move left-to-right, emitting particles in bursts as it collides with the planes, like this:
    But actually, it does something like this in 2.70a:
    Let it play through a few times to see the full behaviour, including interaction with the point cache.

Event Timeline

Alex Fraser (z0r) added a project: BF Blender.
Alex Fraser (z0r) set Type to Bug.
Alex Fraser (z0r) created this task.
Alex Fraser (z0r) raised the priority of this task from to Needs Triage by Developer.
Bastien Montagne (mont29) triaged this task as Normal priority.

I would say this is simply not supported. Particles are totally limited in this regard, if it worked before with scripting it must be considered a lucky accident ...

Lukas Toenne (lukastoenne) changed Type from Bug to To Do.Jan 30 2015, 5:44 PM
Lukas Toenne (lukastoenne) closed this task as Archived.

Thanks for reviewing my report.

This is a feature that I would really miss if it was gone for good. My colleagues and I built a significant add-on for a client that depends on this behaviour, and removing it would mean we have to tell them that we can't support them any more.

If we develop a patch that doesn't break T35247, might you accept it?

Certainly. Sorry if closing this was a bit harsh, i'm just really frustrated with particles and generally consider them broken. If we can keep them working for a little bit longer that would be great of course, any help is appreciated!

Hi guys,

I'm Sean, I'm doing some work with Alex on his Blender project at the moment.

I've attached a patch that fixes the issue we were having after the changes made in T35247. It basically just stops the code calling initialize_particle_textures() if there are no particle textures. I found that after Alex's Python script had manually changed the particle birth_time, this function was re-setting the birth_time from data in ParticleSettings.

I've tested the patch with Alex's test file and the one from T35247 and they both run fine, have a look though and let me know if there is anything I have overlooked.



Thanks for the patch! I've committed a slightly modified version, which should fix the issue for now.

Sorry, but the patch breaks basic particle distribution. Unless we find a proper fix for this issue you will have to stick to an old Blender version or a custom build.

Thanks Lukas, could you clarify what went wrong with the basic particle distribution? I tested the patch you committed and didn't see anything obviously wrong. The test case I used was just a Newtonian particle system added to the initial cube object (attached). The original test cases also appeared to run fine.

@Sean Loh (sean_loh), revert Lukas's patch, then with default cube:

  • Go to particle systems
  • Add new particle system
  • Switch emitter to Hair

This would distribute hairs only on top and bottom faces, and some distribution will happen on one of the side faces. It should be even distribution of same length hair on all the faces.

Ah yes I see what you mean, how about this then?

I've moved the if (has_texture) statement so it only applies to the PART_EMITTER case so hair should work exactly as it did before.

Hi guys, any thoughts on this? We would really like to have this working again.