2
$\begingroup$

I have a simple cube with some rotation and location animation.

All 8 corners have particle system on a vertex as child on these vertices.

With Number 100 everything is fine.

enter image description here

If i increase the number to 5000 ...suddenly on the left side just "in space" 4 particles are generated where there shouldn't be particles.

What did i do wrong?

enter image description here

blend file to check:

i have to admit i try on 3.0 alpha....yes, it might be buggy but honestly: for me it is pretty stable and doesn't crash more than older versions...(just my personal experience)

same problem on 2.92 even worse on 2.83.1....maybe mac only problem...i dunno

Improve this question
$\endgroup$
8
  • $\begingroup$ there are some bugs like this as long as you haven't baked, have you? $\endgroup$
    – moonboots
    Commented Aug 3, 2021 at 11:13
  • $\begingroup$ no, i will try at once $\endgroup$
    – Chris
    Commented Aug 3, 2021 at 11:14
  • $\begingroup$ i baked, same result....äh...no, even worse 😱 $\endgroup$
    – Chris
    Commented Aug 3, 2021 at 11:15
  • $\begingroup$ oh ok, I hope someone will know then... $\endgroup$
    – moonboots
    Commented Aug 3, 2021 at 11:16
  • $\begingroup$ i just wonder...until now i never had such problems. Emitter was pretty reliable ... ;) $\endgroup$
    – Chris
    Commented Aug 3, 2021 at 11:17

2 Answers 2

Reset to default
5
+50
$\begingroup$

It would appear to be a bug and it would appear to be related to the parenting of the emitting vertices to the corners of your mesh - with the location of the particle taking on the un-transformed location but obeying the rotation (this can be seen from the pattern of the particles after the rotation has stopped but the location is still being keyframed).

You should cut it down to a minimal example (eg, 1 vertex instead of 8) so that the situation can be easily replicated by the developers (it's better if the situation can be replicated from a default cube new Blend file rather than relying on them opening your Blend - this way it rules out anything specific in your file), listing the exact steps taken to setup the example (eg, "From the default cube, create another mesh (eg, a cube) and, in edit mode,'Merge' the vertices to a point so that it consists of a single vertex and move that vertex to the vertex of the cube. Parent the vertex to the cube and keyframe the location and rotation of the cube so as to move it over 100 frames by 5 units away from the world origin while randomly rotating. Add a particle system to the single vertex object with default settings set to emit from 'Vertices' and set to 5000 particles. Run the animation and a small fraction of the particles are being emitted at seeming random locations instead of the vertex." (assuming something like that can replicate the problem). Include screenshots and include your .blend.

The bug can be raised within Blender by selecting the "Help/Report a bug" option in the menus.

For info, I've replicated this on a Windows 10 system with Blender 2.91.2 by simply Appending all objects from your file into a default startup blend file.

As mentioned, it appears to be related to the parenting of the vertex to the animated cube with the particles not always picking up the 'final' position (possible race condition).

Improve this answer
$\endgroup$
7
  • $\begingroup$ ok, thank you for reproducing and taking your time! i will try that! $\endgroup$
    – Chris
    Commented Aug 6, 2021 at 19:16
  • $\begingroup$ No worries - glad I could help. You might have some luck with Bake Animation of the vertex objects so that they are no longer reliant on being parented. If you do raise it as a bug then you could also post here so that there is a link back to it for others having the same problem. $\endgroup$
    – Rich Sedman
    Commented Aug 6, 2021 at 20:21
  • 1
    $\begingroup$ bug report: developer.blender.org/T90494 $\endgroup$
    – Chris
    Commented Aug 7, 2021 at 7:54
  • $\begingroup$ Just one question for clarification: is it necessary to have single vertices parented to the cube? If I just put a particle system on the cube and set Source > Emit From > Vertices and increase the particle number to 40.000 as you also would have with 8 vertices set to 5.000 each, than the particles emit only from the corners without errors. $\endgroup$
    – Gordon Brinkmann
    Commented Aug 12, 2021 at 12:06
  • $\begingroup$ @GordonBrinkmann - unfortunately it does need to be done this way if there is a requirement to emit particles evenly from all of the particles. The 'Random' option obviously emits from the vertices irregularly while the 'non-Randon' option emits from each particle in turn - ie, all the particles from the first vertex over its share of the frames, then all the particles from the next vertex over its share of the frames, etc. eg, 1,1,1,1,1,1,1,1,2,2,2,2,2,2,2,2,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,...etc. $\endgroup$
    – Rich Sedman
    Commented Aug 12, 2021 at 12:37
1
$\begingroup$

I was testing a lot and in the end I got it working as expected with the following settings:

  1. Under Integration > Subframes I'd set a value of 10 at first which made it better, then I raised it to 20. Now there were only two or three randomly appearing particles left.

  2. Then I activated Size Deflect in the Deflection options. After that everything worked correctly.

particle integration

Improve this answer
$\endgroup$
4
  • $\begingroup$ @Chris seems like setting Blender to compute a little more precise already helps. $\endgroup$
    – Gordon Brinkmann
    Commented Aug 13, 2021 at 6:48
  • $\begingroup$ +1 yep, in my 3.0alpha version on mac it already worked after setting subframes to 20 (without size deflect) $\endgroup$
    – Chris
    Commented Aug 13, 2021 at 10:15
  • $\begingroup$ I suspect that increasing Subframes is effectively doing the same as reducing the number of particles - ie, fewer particles per (sub)frame. This is probably reducing the amount of work and so reducing the chance of triggering the bug. Not sure why Size Deflect would have an effect - unless it acts to spread the workload out and so reduce the chance of the conflict causing the problem. $\endgroup$
    – Rich Sedman
    Commented Aug 13, 2021 at 12:43
  • $\begingroup$ @RichSedman I simply guess that not the workload by itself is the problem, but the precision in calculating. Having to take Size Deflect in account might lead to more precise calculations - which could result in correct animations. Just an idea, though. Of course fewer particles per subframe might be the cause for reducing the workload, but usually particles get spawned exactly on frames. The way I understood the subframe setting was that especially when particles are moving fast, there are more positions calculated between frames so that the movement is more precise, hence less weird results. $\endgroup$
    – Gordon Brinkmann
    Commented Aug 17, 2021 at 14:12

Not the answer you're looking for? Browse other questions tagged .