softbody self collision fails with more than one thread #53701

New Issue

Jens Ole Wund(bjornmose) · 2018-01-05T23:07:56+01:00

2018-01-05 23:07:56 +01:00

System Information
Operating system and graphics card
linux ubuntu on a ryzen 7
GeForce GTX 1080 TI

Blender Version
From code review I would guess somewhere in 2.5

Short description of error
Soft body self collision fails on parallel execution

Exact steps for others to reproduce the error
SoftTreadingVeryBig.blend
Based on a (as simple as possible) attached .blend file with minimum amount of steps
Have a mesh with more than 100 vertices ( yes it is the correct plural of vertex though spell checker complains )
Set up a scene to force the mesh to collide with itself
Have a machine with more than one core
In render settings (don't ask why it is there) give more than one thread.
Find: Not all 'collision balls' are in scope.

See : https://www.youtube.com/watch?v=S9lpsPNCIDg

Analysis:
Running parts of the the mesh sliced in threads must not assume other members ( vertices (said that once) ) of the mesh to be touched properly.

Fix:
See:
https://www.youtube.com/watch?v=pnlQ1yumOjc

https://pastebin.com/EruQPRAR

says:

in 
_softbody_calc_forces_slice_in_a_thread(
the second loop 
for (c=sb->totpoint, obp= sb->bpoint; c>0; c--, obp++) {
should run over all 'other body points'
-           for (c=sb->totpoint, obp= sb->bpoint; c>=ifirst+bb; c--, obp++) {
+                        /* we are threading here .. so .. needs to go all the way because we do not know which Other Body Points were touched */



and does not alter 'obp' at all.
so removing 
-                       /* exploit force(a, b) == -force(b, a) part2/2 */
-                       sub_v3_v3v3(dvel, velcenter, obp->vec);
-                       mul_v3_fl(dvel, _final_mass(ob, bp));
-
-                       madd_v3_v3fl(obp->force, dvel, sb->balldamp);
-                       madd_v3_v3fl(obp->force, def, -f * (1.0f - sb->balldamp));
+                       /* exploit force(a, b) == -force(b, a) nopes is not working when mesh is divided in threads ..
+                                                   well .. not now .. may be someone thinks this over .. benefit would be 1/2

wish I could have fixed myself .. seems like I am too old to use GIT

**System Information** Operating system and graphics card linux ubuntu on a ryzen 7 GeForce GTX 1080 TI **Blender Version** From code review I would guess somewhere in 2.5 **Short description of error** Soft body self collision fails on parallel execution **Exact steps for others to reproduce the error** [SoftTreadingVeryBig.blend](https://archive.blender.org/developer/F1711583/SoftTreadingVeryBig.blend) Based on a (as simple as possible) attached .blend file with minimum amount of steps Have a mesh with more than 100 vertices ( yes it is the correct plural of vertex though spell checker complains ) Set up a scene to force the mesh to collide with itself Have a machine with more than one core In render settings (don't ask why it is there) give more than one thread. Find: Not all 'collision balls' are in scope. See : https://www.youtube.com/watch?v=S9lpsPNCIDg Analysis: Running parts of the the mesh sliced in threads must not assume other members ( vertices (said that once) ) of the mesh to be touched properly. Fix: See: https://www.youtube.com/watch?v=pnlQ1yumOjc https://pastebin.com/EruQPRAR says: ``` in _softbody_calc_forces_slice_in_a_thread( the second loop for (c=sb->totpoint, obp= sb->bpoint; c>0; c--, obp++) { should run over all 'other body points' - for (c=sb->totpoint, obp= sb->bpoint; c>=ifirst+bb; c--, obp++) { + /* we are threading here .. so .. needs to go all the way because we do not know which Other Body Points were touched */ and does not alter 'obp' at all. so removing - /* exploit force(a, b) == -force(b, a) part2/2 */ - sub_v3_v3v3(dvel, velcenter, obp->vec); - mul_v3_fl(dvel, _final_mass(ob, bp)); - - madd_v3_v3fl(obp->force, dvel, sb->balldamp); - madd_v3_v3fl(obp->force, def, -f * (1.0f - sb->balldamp)); + /* exploit force(a, b) == -force(b, a) nopes is not working when mesh is divided in threads .. + well .. not now .. may be someone thinks this over .. benefit would be 1/2 ``` wish I could have fixed myself .. seems like I am too old to use GIT

Jens Ole Wund(bjornmose) commented

2018-01-05 23:07:56 +01:00

Added subscriber: @bjornmose

Vuk Gardašević commented

2018-01-06 08:14:48 +01:00

Added subscriber: @VukGardasevic

Vuk Gardašević commented

2018-01-06 08:14:48 +01:00

Attaching the code from the paste bin here for future reference. P586

Attaching the code from the paste bin here for future reference. [P586](https://archive.blender.org/developer/P586.txt)

Philipp Oeser commented

2018-01-09 19:10:19 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2018-01-09 19:10:19 +01:00

Here is one that applies on current master P588
can confirm this is looking better with the patch (it comes with a 15% performance penalty though - 185sec vs. 160sec in my test, but I guess that is expected?)

@bjornmose : have you looked here reg. git/commit access?

Here is one that applies on current master [P588](https://archive.blender.org/developer/P588.txt) can confirm this is looking better with the patch (it comes with a 15% performance penalty though - 185sec vs. 160sec in my test, but I guess that is expected?) @bjornmose : have you looked [here ](https://wiki.blender.org/index.php/Dev:Doc/Tools/Git) reg. git/commit access?

blender-admin commented

2018-01-10 01:51:04 +01:00

This issue was referenced by 9aada45e52

This issue was referenced by 9aada45e52e88d272c38dc2e47cbc9a6d3d35698

Jens Ole Wund(bjornmose) commented

2018-01-10 01:56:09 +01:00

Changed status from 'Open' to: 'Resolved'

Jens Ole Wund(bjornmose) closed this issue

2018-01-10 01:56:09 +01:00

Jens Ole Wund(bjornmose) self-assigned this 2018-01-10 02:17:34 +01:00

Jens Ole Wund(bjornmose) commented

2018-01-10 02:17:34 +01:00