Metaball particle sources jumping around #71163

New Issue

Lime_Flavored_Dragon · 2019-10-28T17:13:30+01:00

2019-10-28 17:13:30 +01:00

System Information
Operating system: Windows-10-10.0.18362 64 Bits
Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.86

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f5449
I tried reproducing the bug the 2.81 beta and 2.82 alpha builds on Oct 28, 2019. The bug was observed there as well.
Worked: N/A (I only recently started working with metaballs)

Short description of error
When running a particle simulation with multiple metaball object particles, the original objects appear to jump around and scale based on the particle scaling settings. However, when transforming the originals, the file seems to use the correct position for the transformation. Sometimes, but not always, Blender will crash. The exact behavior is extremely inconsistent. I have attached a video demonstrating one possible result of the bug. The video has force fields but they are not necessary to reproduce the bug. I have removed them in the .blend file.

Exact steps for others to reproduce the error
In the attached .blend file, I have two objects with particle systems using metaballs. Simply scrub through the animation frames and the source objects will jump around.

glitchyfire.blend
glitchyfire.mp4

**System Information** Operating system: Windows-10-10.0.18362 64 Bits Graphics card: GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.86 **Blender Version** Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-29 14:47, hash: f6cb5f5449 I tried reproducing the bug the 2.81 beta and 2.82 alpha builds on Oct 28, 2019. The bug was observed there as well. Worked: N/A (I only recently started working with metaballs) **Short description of error** When running a particle simulation with multiple metaball object particles, the original objects appear to jump around and scale based on the particle scaling settings. However, when transforming the originals, the file seems to use the correct position for the transformation. Sometimes, but not always, Blender will crash. The exact behavior is extremely inconsistent. I have attached a video demonstrating one possible result of the bug. The video has force fields but they are not necessary to reproduce the bug. I have removed them in the .blend file. **Exact steps for others to reproduce the error** In the attached .blend file, I have two objects with particle systems using metaballs. Simply scrub through the animation frames and the source objects will jump around. [glitchyfire.blend](https://archive.blender.org/developer/F7865835/glitchyfire.blend) [glitchyfire.mp4](https://archive.blender.org/developer/F7865833/glitchyfire.mp4)

Lime_Flavored_Dragon commented

2019-10-28 17:13:30 +01:00

Added subscriber: @Lime_Flavored_Dragon

Garry R. Osgood commented

2019-10-28 19:50:11 +01:00

Added subscriber: @grosgood

Garry R. Osgood commented

2019-10-28 19:50:11 +01:00

Sometimes, but not always, Blender will crash

Similar to #69578 in many ways. Not convinced yet, but interested to see if I can produce trace backs for both bug reports.

>Sometimes, but not always, Blender will crash Similar to #69578 in many ways. Not convinced yet, but interested to see if I can produce trace backs for both bug reports.

Garry R. Osgood commented

2019-10-29 12:17:43 +01:00

Here, I consistently find that AddressSanitizer reports a use of heap memory after it has been freed. Specifically, one thread uses a region of heap that another thread has freed. Details in address_sanitizer_T71163.txt
address_sanitizer_T71163.txt
The failure point is consistently at particle.c:1282 within psys_interpolate_face()

1278 v1 = mvert[mface->v1].co;
1279 v2 = mvert[mface->v2].co;
1280 v3 = mvert[mface->v3].co;
1281
1282--> normal_short_to_float_v3(n1, mvert[mface->v1].no);
1283 normal_short_to_float_v3(n2, mvert[mface->v2].no);
1284 normal_short_to_float_v3(n3, mvert[mface->v3].no);

To arrive at this point, I modify @Lime_Flavored_Dragon procedure just a little bit. Instead of scrubbing through the time line, I just run the animation in the viewport. AddressSanitizer never reports this heap-use-after-free issue until the cache has been fully built and the animation is running off of cached data. The time of failure is variable, suggesting a race condition where the Good Guys (almost) always win. When they lose, it is always at this point.

OK - Maybe related to #69578 in that multiple simultaneous metaball-based particle systems have heap issues. There is smoke here, but haven't confirmed the location of the fire (the broad issue of thread race is not specific enough). Nor am I assured that it is the same fire as in #69578.

Here, I consistently find that AddressSanitizer reports a use of heap memory after it has been freed. Specifically, one thread uses a region of heap that another thread has freed. Details in **address_sanitizer_T71163.txt** [address_sanitizer_T71163.txt](https://archive.blender.org/developer/F7869138/address_sanitizer_T71163.txt) The failure point is consistently at [particle.c:1282](https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/particle.c$1282) within psys_interpolate_face() 1278 v1 = mvert[mface->v1].co; 1279 v2 = mvert[mface->v2].co; 1280 v3 = mvert[mface->v3].co; 1281 1282--> normal_short_to_float_v3(n1, mvert[mface->v1].no); 1283 normal_short_to_float_v3(n2, mvert[mface->v2].no); 1284 normal_short_to_float_v3(n3, mvert[mface->v3].no); ``` ``` To arrive at this point, I modify @Lime_Flavored_Dragon procedure just a little bit. Instead of scrubbing through the time line, I just run the animation in the viewport. AddressSanitizer never reports this heap-use-after-free issue until the cache has been fully built and the animation is running off of cached data. The time of failure is variable, suggesting a race condition where the Good Guys (almost) always win. When they lose, it is always at this point. OK - Maybe related to #69578 in that multiple simultaneous metaball-based particle systems have heap issues. There is smoke here, but haven't confirmed the location of the fire (the broad issue of thread race is not specific enough). Nor am I assured that it is the same fire as in #69578.

Germano Cavalcante commented

2019-10-30 14:47:46 +01:00

Added subscriber: @mano-wii

Sergey Sharybin was assigned by Germano Cavalcante

2019-10-30 14:47:46 +01:00

Germano Cavalcante commented

2019-10-30 14:47:46 +01:00

This involves depsgraph (which works multithreaded).
Within BKE_mball_polygonize we have the init_meta which peforms a loop with the BKE_scene_base_iter_next function.
The problem is that BKE_scene_base_iter_next "temporarily" copies the matrix of the dupli object and this does not work well with multithreading.

This involves depsgraph (which works multithreaded). Within `BKE_mball_polygonize` we have the `init_meta` which peforms a loop with the `BKE_scene_base_iter_next` function. The problem is that `BKE_scene_base_iter_next` "temporarily" copies the matrix of the dupli object and this does not work well with multithreading.

Sergey Sharybin commented

2019-10-30 15:17:16 +01:00

For until #62311 is addressed such configuration can not work reliable.

Sergey Sharybin commented

2019-10-30 15:17:26 +01:00

Closed as duplicate of #62311

Sergey Sharybin closed this issue

2019-10-30 15:17:26 +01:00

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

Metaball particle sources jumping around #71163