Particles + force fields lead to crashes in some cases #40957

New Issue

Kai Kostack · 2014-07-05T09:53:21+02:00

Kai Kostack commented

2014-07-05 09:53:21 +02:00

System Information
Windows 7 x64, GTX 480

Blender Version
Broken: 2.71
Worked: unknown

Short description of error
When using a particle system together with a radial force field (maybe others too) it appears in some cases, mostly when the particle count is changed and rebaked, that some particles behave oddly or that the scene even crashes when rendering the animation (perhaps even two different bugs).

Exact steps for others to reproduce the error
This one is not easy to reproduce as it's not always visible that there is going something wrong. I noticed it when trying to emit lots of particles over a mesh surface with sorted elements in one direction. When introducing force fields into the scene and changing the particle count, it started. Some areas of the mesh didn't emit particles anymore or the rotation of particles seemed to suddenly jump to different values and other weird stuff happening.

When updating the force field settings like enabling and disabling one of the checkboxes then the simulation worked again but while rendering it crashed after like 10 frames or so and sometimes immediately.

Try to render a full animation from the attached blend, it should crash like described. If you delete the force field, save and reload (into a fresh Blender instance) then it should render fine again.

bug3c.blend

**System Information** Windows 7 x64, GTX 480 **Blender Version** Broken: 2.71 Worked: unknown **Short description of error** When using a particle system together with a radial force field (maybe others too) it appears in some cases, mostly when the particle count is changed and rebaked, that some particles behave oddly or that the scene even crashes when rendering the animation (perhaps even two different bugs). **Exact steps for others to reproduce the error** This one is not easy to reproduce as it's not always visible that there is going something wrong. I noticed it when trying to emit lots of particles over a mesh surface with sorted elements in one direction. When introducing force fields into the scene and changing the particle count, it started. Some areas of the mesh didn't emit particles anymore or the rotation of particles seemed to suddenly jump to different values and other weird stuff happening. When updating the force field settings like enabling and disabling one of the checkboxes then the simulation worked again but while rendering it crashed after like 10 frames or so and sometimes immediately. Try to render a full animation from the attached blend, it should crash like described. If you delete the force field, save and reload (into a fresh Blender instance) then it should render fine again. [bug3c.blend](https://archive.blender.org/developer/F96766/bug3c.blend)

Kai Kostack commented

2014-07-05 09:53:21 +02:00

Changed status to: 'Open'

Kai Kostack commented

2014-07-05 09:53:21 +02:00

Added subscriber: @KaiKostack-3

Lukas Tönne self-assigned this 2014-07-06 15:15:16 +02:00

ronan ducluzeau commented

2014-07-07 01:43:30 +02:00

Added subscriber: @zeauro

ronan ducluzeau commented

2014-07-07 01:43:30 +02:00

I confirm a crash at frame 65 if I directly press animation button after opening attached .blend.
But If I bake partcle system before render, I can render full animation without problem.

I did not succeed to reproduce crash from scratch.

I am used to take attention to cache. During 2.5x, first attempts of rewriting particles and smoke creation, rendering of particles or smoke was rarely successful without a previous baking.
It is why there are so many buttons to bake.

For me, "Free all Bakes" button does not work.
"Update All to Frame" only works if a setting was changed.
It does not create cache steps between last cache step and current frame if nothing was changed.

I confirm a crash at frame 65 if I directly press animation button after opening attached .blend. But If I bake partcle system before render, I can render full animation without problem. I did not succeed to reproduce crash from scratch. I am used to take attention to cache. During 2.5x, first attempts of rewriting particles and smoke creation, rendering of particles or smoke was rarely successful without a previous baking. It is why there are so many buttons to bake. For me, "Free all Bakes" button does not work. "Update All to Frame" only works if a setting was changed. It does not create cache steps between last cache step and current frame if nothing was changed.

Kai Kostack commented

2014-07-07 02:22:16 +02:00

I used baking everywhere but it crashed anyway, and this very early not as late as frame 65. On what OS are you working on? I have learned that Linux is much more "unconcerned" when it comes to bad memory access other than Windows, making it even harder to reproduce errors.

ronan ducluzeau commented

2014-07-07 12:21:15 +02:00

Ubuntu 14.04 64bits 32 Giga

Lukas Tönne commented

2014-07-07 14:11:15 +02:00

I can't reproduce this with the test case (arch linux 64). Tried rendering the animation, playing it, caching, ... And i'm running address sanitizer, so any memory errors should likely be catched ...

Lukas Tönne removed their assignment 2014-07-07 14:13:35 +02:00

Lukas Tönne commented

2014-07-07 14:13:35 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2014-07-07 16:37:16 +02:00

@KaiKostack-3, @zeauro: what render device are you using, cpu or gpu? Does it happen only on render, or also viewport preview render, or opengl viewport as well?

Kai Kostack commented

2014-07-07 19:09:09 +02:00

Rendering in CPU and GPU crashes for me immediately on this file. Before starting the actual rendering process. Viewport rendering also crashes. I didn't test the latter for this file before, but in other files it worked most of the time.

ronan ducluzeau commented

2014-07-07 19:28:04 +02:00

I used CPU.

Kai Kostack commented

2014-07-09 10:19:22 +02:00

So, I did some deeper testing and can provide some more concrete info now.

As for the crashes, I start to believe that they aren't related to the particle system problem, so indeed two different bugs. Because the official release doesn't crash, only very recent builds from graphicall and my own. The crashing I described is similar to that what other users experienced and noted recently on blenderartists .

Let's focus instead on the weird particle and force field behaviour problem again. Two more test files:

bug3d.blend

If you play the animation on this one, you will notice that the explode modifier is finished before the emitting range of the particle system ends. Even on rebake nothing is updated. (I decimated the sphere beforehand and resorted new elements.)

bug4a.blend

The second file shows arbitrary jumps of the rotational vector of the particles caused by the noise value of the force field. Just play the animation.

So, I did some deeper testing and can provide some more concrete info now. As for the crashes, I start to believe that they aren't related to the particle system problem, so indeed two different bugs. Because the official release doesn't crash, only very recent builds from graphicall and my own. The crashing I described is similar to that what other users experienced and noted recently on [blenderartists ](http://blenderartists.org/forum/showthread.php?216113-Brecht-s-easter-egg-surprise-Modernizing-shading-and-rendering&p=2681776&viewfull=1#post2681776). Let's focus instead on the weird particle and force field behaviour problem again. Two more test files: [bug3d.blend](https://archive.blender.org/developer/F97153/bug3d.blend) If you play the animation on this one, you will notice that the explode modifier is finished before the emitting range of the particle system ends. Even on rebake nothing is updated. (I decimated the sphere beforehand and resorted new elements.) [bug4a.blend](https://archive.blender.org/developer/F97154/bug4a.blend) The second file shows arbitrary jumps of the rotational vector of the particles caused by the noise value of the force field. Just play the animation.

Sergey Sharybin commented

2014-07-09 10:21:51 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-07-09 10:21:51 +02:00

Can;t reproduce neither on windows nor on linux. It could be threading related. So here're the questions:

Does it happen if you run blender with -t 1 command line arguments?
What CPU you guys have?

Can;t reproduce neither on windows nor on linux. It could be threading related. So here're the questions: - Does it happen if you run blender with -t 1 command line arguments? - What CPU you guys have?

Kai Kostack commented

2014-07-09 10:31:34 +02:00

With -t 1 it doesn't crash. This [build ]] and this [ http:*www.graphicall.org/110 | build are crashing without the parameters.

i7-980X

With -t 1 it doesn't crash. This [build ]] and this [[ http:*www.graphicall.org/110 | build ](http:*www.graphicall.org/103) are crashing without the parameters. i7-980X

ronan ducluzeau commented

2014-07-09 21:39:22 +02:00

@Sergey, My CPU is an i7 4770K.

@KaiKostack-3,
For bug3d.blend :
I agree that there is a problem with cache of your particle system.
Maybe it is the result of playing animation with decimate modifier before applying it.
Particles emmited from object's origin is kind of caracteristic of an unchecked "Use Modifier's stack " option.
But I am able to solve it simply by erasing cache before rebake.
Free Cache button does not erase it. It just remove its protection to be rewriten.
You have to change a physics setting and restore it to erase cache.
If you don't do it ; a rebake will just protect uncorrect cache without overwriting it.

For bug4a.blend :
I don't kow if it is considered as a bug in current design.
Maybe user have to accept noïse as an interval of field strength centered on strength value.
I mean maybe it works internally as Random values of particle system velocity.
Anyways, it is not a big problem. A user can animate it to set it to 0 at start and increase it, according to the way strength is increasing.

@Sergey, My CPU is an i7 4770K. @KaiKostack-3, For bug3d.blend : I agree that there is a problem with cache of your particle system. Maybe it is the result of playing animation with decimate modifier before applying it. Particles emmited from object's origin is kind of caracteristic of an unchecked "Use Modifier's stack " option. But I am able to solve it simply by erasing cache before rebake. Free Cache button does not erase it. It just remove its protection to be rewriten. You have to change a physics setting and restore it to erase cache. If you don't do it ; a rebake will just protect uncorrect cache without overwriting it. For bug4a.blend : I don't kow if it is considered as a bug in current design. Maybe user have to accept noïse as an interval of field strength centered on strength value. I mean maybe it works internally as Random values of particle system velocity. Anyways, it is not a big problem. A user can animate it to set it to 0 at start and increase it, according to the way strength is increasing.

Sergey Sharybin commented

2014-07-10 19:05:16 +02:00

Eeh, this is becoming difficult to follow for me. Do you mind reporting issues which are not related on the original crash report to a separate reports? That helps a lot keeping a track on what's the actual issues, what's remained to fix and so on. If it's all mixed into a single report we can miss whole bunch of the info.

As for the crash, please test builds which are nrewer than 49c73f2. I did some fixes to Cycles which solves crashes. I'll mark report as incomplete (like, artist action required ;) for until this is tested. Will either close it if crash is solved or triage as normal if ccrahs will still happen.

As for other issues -- please report them separately. That'd help a bunch :)

Eeh, this is becoming difficult to follow for me. Do you mind reporting issues which are not related on the original crash report to a separate reports? That helps a lot keeping a track on what's the actual issues, what's remained to fix and so on. If it's all mixed into a single report we can miss whole bunch of the info. As for the crash, please test builds which are nrewer than 49c73f2. I did some fixes to Cycles which solves crashes. I'll mark report as incomplete (like, artist action required ;) for until this is tested. Will either close it if crash is solved or triage as normal if ccrahs will still happen. As for other issues -- please report them separately. That'd help a bunch :)

Kai Kostack commented

2014-07-11 19:28:07 +02:00

A quick own build shows no crashes anymore, will check others when they arrive on graphicall.

As for the original issue, I thought the crashes would be related to the weird particle / force field behaviour I described, so it wasn't my intention to throw different problems into one report. I agree we should keep this one for the crashing bug, which can now hopefully be closed, and I will open up a new one with the other particle related stuff.

Anyways, thanks for the fix :)

A quick own build shows no crashes anymore, will check others when they arrive on graphicall. As for the original issue, I thought the crashes would be related to the weird particle / force field behaviour I described, so it wasn't my intention to throw different problems into one report. I agree we should keep this one for the crashing bug, which can now hopefully be closed, and I will open up a new one with the other particle related stuff. Anyways, thanks for the fix :)

Sergey Sharybin commented

2014-07-11 19:55:34 +02:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2014-07-11 19:55:34 +02:00

Sergey Sharybin self-assigned this 2014-07-11 19:55:34 +02:00

Sergey Sharybin commented

2014-07-11 19:55:34 +02:00

Awesome to hear this! Closing the report. Please let us know if you've got more issues.

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

Particles + force fields lead to crashes in some cases #40957