Can't dynamically set particle birth time any more #43471

New Issue

Alex Fraser · 2015-01-29T12:06:33+01:00

Alex Fraser commented

2015-01-29 12:06:33 +01:00

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: 78c491e Fix #35247: Particle texture behaves incorrectly after changing the number of particles
Worked: 9800ed5 Code cleanup: replace magic constants with more verbose bitnames
Worked: 2.69 r60991 1b6b47c

It seems that the bug was introduced in 78c491e.

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

Load attached particle_birth_test.blend
Play the animation. The emitter should move left-to-right, emitting particles at a constant rate, like this:

  {F139799}

Reload the file.
Run the smash script. The script uses a frame_change_pre callback to detect collisions and cause particles to be born.
Play the animation. The emitter should move left-to-right, emitting particles in bursts as it collides with the planes, like this:

  {F139798}
  But actually, it does something like this in 2.70a:
  {F139797}
  Let it play through a few times to see the full behaviour, including interaction with the point cache.

**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: 78c491e Fix #35247: Particle texture behaves incorrectly after changing the number of particles Worked: 9800ed5 Code cleanup: replace magic constants with more verbose bitnames Worked: 2.69 r60991 1b6b47c It seems that the bug was introduced in 78c491e. **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 [particle_birth_test.blend](https://archive.blender.org/developer/F139803/particle_birth_test.blend) 1. Play the animation. The emitter should move left-to-right, emitting particles at a constant rate, like this: ``` {F139799} ``` 1. Reload the file. 1. Run the `smash` script. The script uses a `frame_change_pre` callback to detect collisions and cause particles to be born. 1. Play the animation. The emitter should move left-to-right, emitting particles in bursts as it collides with the planes, like this: ``` {F139798} But actually, it does something like this in 2.70a: {F139797} Let it play through a few times to see the full behaviour, including interaction with the point cache.

Alex Fraser commented

2015-01-29 12:06:33 +01:00

Changed status to: 'Open'

Alex Fraser commented

2015-01-29 12:06:33 +01:00

Added subscriber: @z0r

Antonis Ryakiotakis commented

2015-01-29 15:20:20 +01:00

Added subscribers: @LukasTonne, @Sergey, @Psy-Fi

Antonis Ryakiotakis commented

2015-01-29 15:20:20 +01:00

Can @LukasTonne or @Sergey check things here?

Lukas Tönne was assigned by Antonis Ryakiotakis

2015-01-29 15:29:14 +01:00

Alex Fraser commented

2015-01-29 23:40:38 +01:00

Added subscriber: @adfries

ronan ducluzeau commented

2015-01-30 11:17:20 +01:00

Added subscriber: @zeauro

Lukas Tönne commented

2015-01-30 17:41:26 +01:00

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 Tönne commented

2015-01-30 17:44:27 +01:00

Changed status from 'Open' to: 'Archived'

Lukas Tönne closed this issue

2015-01-30 17:44:27 +01:00

Alex Fraser commented

2015-02-03 10:19:26 +01:00

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 #35247, might you accept it?

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 #35247, might you accept it?

Lukas Tönne commented

2015-02-03 10:33:09 +01:00

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!

Sean Loh commented

2015-02-12 06:54:40 +01:00

Added subscriber: @sean_loh

Sean Loh commented

2015-02-12 06:54:40 +01:00

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 #35247. 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 #35247 and they both run fine, have a look though and let me know if there is anything I have overlooked.

Cheers

Sean

fix_for_T43471.patch

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 #35247. 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 #35247 and they both run fine, have a look though and let me know if there is anything I have overlooked. Cheers Sean [fix_for_T43471.patch](https://archive.blender.org/developer/F142609/fix_for_T43471.patch)

blender-admin commented

2015-02-12 10:15:25 +01:00

This issue was referenced by b2b54b0902

This issue was referenced by b2b54b0902045ec4f0c1a4cae3209be863878f5b

Lukas Tönne commented

2015-02-12 10:18:25 +01:00

Changed status from 'Archived' to: 'Resolved'

Lukas Tönne commented

2015-02-12 10:18:25 +01:00

Closed by commit b2b54b0902.

Closed by commit b2b54b0902.

Lukas Tönne commented

2015-02-12 10:19:38 +01:00

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

blender-admin commented

2015-02-14 16:40:57 +01:00

This issue was referenced by db297e7ea3

This issue was referenced by db297e7ea314ee1e0f6db796c3dfc6683f64cd22

Lukas Tönne commented

2015-02-14 16:44:47 +01:00

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.

Sean Loh commented

2015-02-17 07:02:15 +01:00

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

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.[cube.blend](https://archive.blender.org/developer/F144032/cube.blend)

Sergey Sharybin commented

2015-02-17 08:45:28 +01:00

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

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

Sean Loh commented

2015-02-18 01:15:51 +01:00

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.

fix_for_T43471_1.patch

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. [fix_for_T43471_1.patch](https://archive.blender.org/developer/F144360/fix_for_T43471_1.patch)

Alex Fraser commented

2015-05-15 03:27:19 +02:00

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

Cheers,
Alex

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

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

Can't dynamically set particle birth time any more #43471