2 clothes on a collision object cause crash #39104

New Issue

Jun T · 2014-03-11T02:12:09+01:00

Jun T commented

2014-03-11 02:12:09 +01:00

System Information
Arch Linux (x86-64)
nVidia Geforce GTX 670

Blender Version
Broken: 2.70 25ad7b4
Worked: 2.69

Short description of error
When put 2 clothes on a single collision object, 2.70 often crash.
Even though not crashed, Simulation is absolutely different from 2.69 or when clothes are a single cloth.
And when cloth simulation is switched Off and On, It works well just for the session.

Exact steps for others to reproduce the error
Open physics_crash3.blend.
Play(Alt + a) it.
Probably crash.
Or the clothes will hop.

**System Information** Arch Linux (x86-64) nVidia Geforce GTX 670 **Blender Version** Broken: 2.70 25ad7b4 Worked: 2.69 **Short description of error** When put 2 clothes on a single collision object, 2.70 often crash. Even though not crashed, Simulation is absolutely different from 2.69 or when clothes are a single cloth. And when cloth simulation is switched Off and On, It works well just for the session. **Exact steps for others to reproduce the error** Open [physics_crash3.blend](https://archive.blender.org/developer/F80605/physics_crash3.blend). Play(Alt + a) it. Probably crash. Or the clothes will hop.

Jun T commented

2014-03-11 02:12:09 +01:00

Changed status to: 'Open'

Jun T commented

2014-03-11 02:12:09 +01:00

Added subscriber: @junt

Sergey Sharybin self-assigned this 2014-03-11 07:03:28 +01:00

Sergey Sharybin commented

2014-03-11 07:03:28 +01:00

Seems to be a threading issue. Will look into it.

Sergey Sharybin commented

2014-03-11 07:34:41 +01:00

Added subscribers: @sreich, @JoshuaLeung, @erwin, @brecht

Sergey Sharybin commented

2014-03-11 07:34:41 +01:00

Developer note:
The issue is caused by static solvers in plNearestPoints() which for sure leads to threading conflict. Simple solution would be to make solvers not static which makes simulation stable but not sure which speed impact it'll have.

@brecht, @erwin, @JoshuaLeung, @sreich could i have your feedback here?

Developer note: The issue is caused by static solvers in `plNearestPoints()` which for sure leads to threading conflict. Simple solution would be to make solvers not static which makes simulation stable but not sure which speed impact it'll have. @brecht, @erwin, @JoshuaLeung, @sreich could i have your feedback here?

Brecht Van Lommel commented

2014-03-11 11:21:07 +01:00

Added subscriber: @genscher

Brecht Van Lommel commented

2014-03-11 11:21:07 +01:00

@genscher is the cloth expert though this is more of a bullet issue.

Perhaps try it on a cloth with a lot of collision and see what happens to performance if you remove static.

Otherwise I guess you need to somehow init the solvers once per cloth evaluation thread and pass them to each call to plNearestPoints.

@genscher is the cloth expert though this is more of a bullet issue. Perhaps try it on a cloth with a lot of collision and see what happens to performance if you remove static. Otherwise I guess you need to somehow init the solvers once per cloth evaluation thread and pass them to each call to plNearestPoints.

Sergey Sharybin commented

2014-03-12 09:47:31 +01:00

Did some tests with the file cloth_test.blend.bz2

Seems to be no noticeable affect on the speed. So think we're quite safe to go with static variables removed for 2.70 release.

Did some tests with the file [cloth_test.blend.bz2](https://archive.blender.org/developer/F80768/cloth_test.blend.bz2) Seems to be no noticeable affect on the speed. So think we're quite safe to go with static variables removed for 2.70 release.

blender-admin commented

2014-03-12 09:48:47 +01:00

This issue was referenced by blender/blender-addons-contrib@de86b7097f

This issue was referenced by blender/blender-addons-contrib@de86b7097fecf2a8b71d93a5edf20a38f4b4587c

blender-admin commented

2014-03-12 09:48:47 +01:00

This issue was referenced by de86b7097f

This issue was referenced by de86b7097fecf2a8b71d93a5edf20a38f4b4587c

Sergey Sharybin commented

2014-03-12 09:50:15 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue