RBD sim ignores mesh (cloth) deformation #91183

New Issue

michael campbell · 2021-09-04T19:36:28+02:00

michael campbell commented

2021-09-04 19:36:28 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.92

Blender Version
Broken: version: 3.0.0 Alpha, branch: master, commit date: 2021-09-03 21:49, hash: 716682365c
Worked: BLENDER 2.79b

Open below file and press play. RBD sim ignores mesh deformation and reacts to its undeformed state instead. The setting of 'deforming' shown below is ignored in versions after 2.79b:

rbd sim ignores mesh deformation .blend

Here's another file, this time using an alembic as the deforming object. It still acts as though the mesh is not deforming...which is strange considering it's an imported deforming object.

rbd sim ignores mesh deformation on imported USD as well .blend

All works as expected in 2.79b

279b physics .blend

2021-09-04 19-46-49.mp4

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.92 **Blender Version** Broken: version: 3.0.0 Alpha, branch: master, commit date: 2021-09-03 21:49, hash: `716682365c` Worked: BLENDER 2.79b Open below file and press play. RBD sim ignores mesh deformation and reacts to its undeformed state instead. The setting of 'deforming' shown below is ignored in versions after 2.79b: ![image.png](https://archive.blender.org/developer/F10377107/image.png) [rbd sim ignores mesh deformation .blend](https://archive.blender.org/developer/F10376990/rbd_sim_ignores_mesh_deformation_.blend) Here's another file, this time using an alembic as the deforming object. It still acts as though the mesh is not deforming...which is strange considering it's an imported deforming object. [rbd sim ignores mesh deformation on imported USD as well .blend](https://archive.blender.org/developer/F10377008/rbd_sim_ignores_mesh_deformation_on_imported_USD_as_well_.blend) All works as expected in 2.79b [279b physics .blend](https://archive.blender.org/developer/F10377074/279b_physics_.blend) [2021-09-04 19-46-49.mp4](https://archive.blender.org/developer/F10377075/2021-09-04_19-46-49.mp4)

michael campbell commented

2021-09-04 19:36:28 +02:00

Added subscriber: @3di

blender-admin commented

2021-09-04 19:36:28 +02:00

#94036 was marked as duplicate of this issue

Everton Schneider commented

2021-09-05 17:12:35 +02:00

Added subscriber: @EvertonSchneider

Everton Schneider commented

2021-09-05 17:12:35 +02:00

Hi! I can confirm it. The cloth modifier is not being considered on RBD "convex hull" shape and "deform" source and not even using "final" source which describes as considering "all modifiers". Tried "mesh" shape also but same result on every source mode...

Everton Schneider commented

2021-09-05 17:18:15 +02:00

But, I noticed that the "simple deform" modifier gets detected using the "mesh" shape and "deform" as source and also checking the "Deforming" checkbox right below (which I think is very annoying having to check a deforming checkbox even using deforming source... it's redundant) Check the file to see it working:

RBD_MeshDef.blend

But, I noticed that the "simple deform" modifier gets detected using the "mesh" shape and "deform" as source and also checking the "Deforming" checkbox right below (which I think is very annoying having to check a deforming checkbox even using deforming source... it's redundant) Check the file to see it working: [RBD_MeshDef.blend](https://archive.blender.org/developer/F10379537/RBD_MeshDef.blend)

Hans Goudey commented

2021-09-05 18:09:51 +02:00

Added subscriber: @HooglyBoogly

Philipp Oeser commented

2021-09-06 11:26:49 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-09-06 11:26:49 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2021-09-06 11:26:49 +02:00

Can confirm, problem of the 2.8 depsgraph it seems (was also not working in 2.79 with the --enable-new-depsgraph option)

Can confirm, problem of the 2.8 depsgraph it seems (was also not working in 2.79 with the `--enable-new-depsgraph` option)

Philipp Oeser commented

2021-09-06 11:53:11 +02:00

Added subscriber: @ZedDB

Philipp Oeser commented

2021-09-06 11:53:11 +02:00

@ZedDB: interested?

Philipp Oeser changed title from ~~RBD sim ignores mesh deformation~~ to RBD sim ignores mesh (cloth) deformation

2021-09-06 11:53:42 +02:00

michael campbell commented

2021-09-07 17:41:37 +02:00

As this stops the entire physics system working, and because it's been an issue for a few years, could this be considered a higher priority than normal? I don't think it's ever going to get addressed otherwise.

Philipp Oeser self-assigned this 2021-09-08 12:12:24 +02:00

Philipp Oeser commented

2021-09-08 12:12:24 +02:00

OK, I have a fix for this [ but still have to verify it is the right thing to do :) ]

michael campbell commented

2021-09-08 15:19:03 +02:00

In #91183#1217519, @lichtwerk wrote:
OK, I have a fix for this [ but still have to verify it is the right thing to do :) ]

Whoaa, that's impressive. I'd be amazed if there aren't a few hundred related bugs that you'll be fixing in one swoop! Any chance of sharing the diff? I was just about to mess about moving everything to 2.79 as alembic, and then shrinkwrapping for collisions. Staying in 3.0 alpha would be great.

> In #91183#1217519, @lichtwerk wrote: > OK, I have a fix for this [ but still have to verify it is the right thing to do :) ] Whoaa, that's impressive. I'd be amazed if there aren't a few hundred related bugs that you'll be fixing in one swoop! Any chance of sharing the diff? I was just about to mess about moving everything to 2.79 as alembic, and then shrinkwrapping for collisions. Staying in 3.0 alpha would be great.

Philipp Oeser commented

2021-09-08 16:23:54 +02:00

I am still investigating (getting deeper and deeper here -- this involves depsgraph issues where some stuff isnt available when needed -- will try to explain in detail when I put a final patch up).

So the very short answer would be: start blender with -t 1 (one thread) and remember to have it on MESH and Deforming ON :) -- things should be fine then

Then if you have multiple threads, this is the bandaid for now:
P2375: T91183_bandaid



diff --git a/intern/rigidbody/RBI_api.h b/intern/rigidbody/RBI_api.h
index f13f321a2c6..2470803a6ae 100644
--- a/intern/rigidbody/RBI_api.h
+++ b/intern/rigidbody/RBI_api.h
@@ -258,7 +258,7 @@ void RB_shape_delete(rbCollisionShape *shape);
 float RB_shape_get_margin(rbCollisionShape *shape);
 void RB_shape_set_margin(rbCollisionShape *shape, float value);
 
-void RB_shape_trimesh_update(rbCollisionShape *shape,
+bool RB_shape_trimesh_update(rbCollisionShape *shape,
                              float *vertices,
                              int num_verts,
                              int vert_stride,
diff --git a/intern/rigidbody/rb_bullet_api.cpp b/intern/rigidbody/rb_bullet_api.cpp
index daa377a7b55..d36ca02f381 100644
--- a/intern/rigidbody/rb_bullet_api.cpp
+++ b/intern/rigidbody/rb_bullet_api.cpp
@@ -814,7 +814,7 @@ rbCollisionShape *RB_shape_new_trimesh(rbMeshData *mesh)
   return shape;
 }
 
-void RB_shape_trimesh_update(rbCollisionShape *shape,
+bool RB_shape_trimesh_update(rbCollisionShape *shape,
                              float *vertices,
                              int num_verts,
                              int vert_stride,
@@ -822,7 +822,7 @@ void RB_shape_trimesh_update(rbCollisionShape *shape,
                              float max[3])
 {
   if (shape->mesh == NULL || num_verts != shape->mesh->num_vertices) {
-    return;
+    return false;
   }
 
   for (int i = 0; i < num_verts; i++) {
@@ -841,6 +841,8 @@ void RB_shape_trimesh_update(rbCollisionShape *shape,
     btGImpactMeshShape *mesh_shape = (btGImpactMeshShape *)shape->cshape;
     mesh_shape->updateBound();
   }
+
+  return true;
 }
 
 rbCollisionShape *RB_shape_new_gimpact_mesh(rbMeshData *mesh)
diff --git a/source/blender/blenkernel/intern/rigidbody.c b/source/blender/blenkernel/intern/rigidbody.c
index 328c54fc21b..b46729c40ef 100644
--- a/source/blender/blenkernel/intern/rigidbody.c
+++ b/source/blender/blenkernel/intern/rigidbody.c
@@ -1680,12 +1680,15 @@ static void rigidbody_update_sim_ob(
       int totvert = mesh->totvert;
       BoundBox *bb = BKE_object_boundbox_get(ob);
 
-      RB_shape_trimesh_update(rbo->shared->physics_shape,
-                              (float *)mvert,
-                              totvert,
-                              sizeof(MVert),
-                              bb->vec[0],
-                              bb->vec[6]);
+      if (!RB_shape_trimesh_update(rbo->shared->physics_shape,
+                                   (float *)mvert,
+                                   totvert,
+                                   sizeof(MVert),
+                                   bb->vec[0],
+                                   bb->vec[6])) {
+        rigidbody_validate_sim_shape(rbw, ob, true);
+        RB_body_set_collision_shape(rbo->shared->physics_object, rbo->shared->physics_shape);
+      }
     }
   }

Like I said, this will all change once the threading issue is out of the way (the baindaid just builds a new collision shape for the case it fails), stay tuned...
Would like to hear if -t 1 is also a workaround for your cases.

I am still investigating (getting deeper and deeper here -- this involves depsgraph issues where some stuff isnt available when needed -- will try to explain in detail when I put a final patch up). So the very short answer would be: start blender with `-t 1` (one thread) and remember to have it on `MESH` and `Deforming` ON :) -- things should be fine then Then if you have multiple threads, this is the bandaid for now: [P2375: T91183_bandaid](https://archive.blender.org/developer/P2375.txt) ``` diff --git a/intern/rigidbody/RBI_api.h b/intern/rigidbody/RBI_api.h index f13f321a2c6..2470803a6ae 100644 --- a/intern/rigidbody/RBI_api.h +++ b/intern/rigidbody/RBI_api.h @@ -258,7 +258,7 @@ void RB_shape_delete(rbCollisionShape *shape); float RB_shape_get_margin(rbCollisionShape *shape); void RB_shape_set_margin(rbCollisionShape *shape, float value); -void RB_shape_trimesh_update(rbCollisionShape *shape, +bool RB_shape_trimesh_update(rbCollisionShape *shape, float *vertices, int num_verts, int vert_stride, diff --git a/intern/rigidbody/rb_bullet_api.cpp b/intern/rigidbody/rb_bullet_api.cpp index daa377a7b55..d36ca02f381 100644 --- a/intern/rigidbody/rb_bullet_api.cpp +++ b/intern/rigidbody/rb_bullet_api.cpp @@ -814,7 +814,7 @@ rbCollisionShape *RB_shape_new_trimesh(rbMeshData *mesh) return shape; } -void RB_shape_trimesh_update(rbCollisionShape *shape, +bool RB_shape_trimesh_update(rbCollisionShape *shape, float *vertices, int num_verts, int vert_stride, @@ -822,7 +822,7 @@ void RB_shape_trimesh_update(rbCollisionShape *shape, float max[3]) { if (shape->mesh == NULL || num_verts != shape->mesh->num_vertices) { - return; + return false; } for (int i = 0; i < num_verts; i++) { @@ -841,6 +841,8 @@ void RB_shape_trimesh_update(rbCollisionShape *shape, btGImpactMeshShape *mesh_shape = (btGImpactMeshShape *)shape->cshape; mesh_shape->updateBound(); } + + return true; } rbCollisionShape *RB_shape_new_gimpact_mesh(rbMeshData *mesh) diff --git a/source/blender/blenkernel/intern/rigidbody.c b/source/blender/blenkernel/intern/rigidbody.c index 328c54fc21b..b46729c40ef 100644 --- a/source/blender/blenkernel/intern/rigidbody.c +++ b/source/blender/blenkernel/intern/rigidbody.c @@ -1680,12 +1680,15 @@ static void rigidbody_update_sim_ob( int totvert = mesh->totvert; BoundBox *bb = BKE_object_boundbox_get(ob); - RB_shape_trimesh_update(rbo->shared->physics_shape, - (float *)mvert, - totvert, - sizeof(MVert), - bb->vec[0], - bb->vec[6]); + if (!RB_shape_trimesh_update(rbo->shared->physics_shape, + (float *)mvert, + totvert, + sizeof(MVert), + bb->vec[0], + bb->vec[6])) { + rigidbody_validate_sim_shape(rbw, ob, true); + RB_body_set_collision_shape(rbo->shared->physics_object, rbo->shared->physics_shape); + } } } ``` Like I said, this will all change once the threading issue is out of the way (the baindaid just builds a new collision shape for the case it fails), stay tuned... Would like to hear if `-t 1` is also a workaround for your cases.

michael campbell commented

2021-09-08 16:34:45 +02:00

awesome, thanks!

Philipp Oeser commented

2021-09-08 16:44:00 +02:00

-t 1 working for you (without patch)?

`-t 1` working for you (without patch)?

michael campbell commented

2021-09-08 17:14:29 +02:00

Just having a drop of lunch, will let you know as soon as I get back.

michael campbell commented

2021-09-08 17:24:02 +02:00

Just tested with the -t 1 workaround in 2.93, and I find that collisions don't work at all. Opening the same file again without the -t 1, and collisions work again.

michael campbell commented

2021-09-08 17:28:57 +02:00

hmm, I think that has something to do with the caching, because if I try it several times by playing and then rewinding, eventually it works with non deforming objects, but deforming objects don't get recognised at all.

michael campbell commented

2021-09-08 17:42:47 +02:00

3.0 the t -1 fix works, but caching during playback stops working after a variable number of frames. using the bake button works.

ah, just realised why that was because frame dropping was turned on. So yeah, that's a great workaround for now thanks!

3.0 the t -1 fix works, but caching during playback stops working after a variable number of frames. using the bake button works. ah, just realised why that was because frame dropping was turned on. So yeah, that's a great workaround for now thanks!

michael campbell commented

2021-09-08 18:50:52 +02:00

Sorry @lichtwerk , it's all over the place, I thought it was just a case of frame dropping being turned on that was causing the collisions to intermittently not work, but I've baked several times now and sometimes it works and others times it doesn't. There doesn't seem to be any logic to it, it's just random. I'll head over to 2.79b for now as I have to get this project done.......if I can get armature weights to carry over (which seems impossible at the moment).

Philipp Oeser commented

2021-09-08 19:42:34 +02:00

does the patch work better?

michael campbell commented

2021-09-08 20:21:42 +02:00

I don't have time to download everything and build at the moment (running behind on this project). If you have a windows build available, drop me the link and I'll quickly try it out .

michael campbell commented

2021-09-09 17:50:56 +02:00

Hi @lichtwerk Just tried the patch. It's very hit and miss. Sometimes it works, other times it doesn't. When it does work, it only works for part of the specified frame range defined in the simulation start and end frames. Other times blender hard crashes when trying to remove the rigid body physics from multiple objects.

I suspect a lot of the problems are cache related. Clearing the bakes doesn't delete the cache, you have to change a setting on one of the simulated object's RBD properties.

It's SUPER broken.

Hi @lichtwerk Just tried the patch. It's very hit and miss. Sometimes it works, other times it doesn't. When it does work, it only works for part of the specified frame range defined in the simulation start and end frames. Other times blender hard crashes when trying to remove the rigid body physics from multiple objects. I suspect a lot of the problems are cache related. Clearing the bakes doesn't delete the cache, you have to change a setting on one of the simulated object's RBD properties. It's SUPER broken.

michael campbell commented

2021-09-09 17:59:01 +02:00

Just tried baking from the scene tab's bake button...it's baking around 10 x slower than 2.79b (even though 2.79b had approx 100x more cubes in the tower being knocked over..plus constraints between each object!). It got to 50% and then crashed blender.

I think you may have your work cut out for you :) I'll keep my fingers crossed for you though. You'll go down as a legend if you can bring working physics back to Blender after it being missing for 2 years.

Just tried baking from the scene tab's bake button...it's baking around 10 x slower than 2.79b (even though 2.79b had approx 100x more cubes in the tower being knocked over..plus constraints between each object!). It got to 50% and then crashed blender. I think you may have your work cut out for you :) I'll keep my fingers crossed for you though. You'll go down as a legend if you can bring working physics back to Blender after it being missing for 2 years.

Philipp Oeser commented

2021-09-10 08:35:20 +02:00

Thx @3di for spending the time trying it out (even on a tight deadline)!

And sorry this bandaid wasnt working (it being slower was kind of expected since it has to rebuild the entire shape instead of just updating some positions).
Couldnt reproduce crashes so far [but have an idea why that might be the case and will check on that as well].
And yes, there are issues all around this area, will still try some more and sum up my findings (but might have to get other devs onboard as well if this turn into a timesink for me...)
All the best on the current project!

Thx @3di for spending the time trying it out (even on a tight deadline)! And sorry this bandaid wasnt working (it being slower was kind of expected since it has to rebuild the entire shape instead of just updating some positions). Couldnt reproduce crashes so far [but have an idea why that might be the case and will check on that as well]. And yes, there are issues all around this area, will still try some more and sum up my findings (but might have to get other devs onboard as well if this turn into a timesink for me...) All the best on the current project!

michael campbell commented

2021-09-11 15:06:52 +02:00

thx @lichtwerk , still tearfully battling the blender physics system :( Desperately trying to avoid renewing my Houdini licence after dedicating the last 2 years to building a business around teaching Blender.

michael campbell commented

2021-09-11 15:24:07 +02:00

Perhaps you guys could get in touch with your friends at Nvidia to see if they'll amend the licence of their flex system which is already practically GNU. Perhaps they'd be happy to make it fully GNU so you guys can have a fully unified phyiscs system. You can try the demo here:

https://github.com/NVIDIAGameWorks/FleX

Works on Nvidia and Amd GPU's.

Perhaps you guys could get in touch with your friends at Nvidia to see if they'll amend the licence of their flex system which is already practically GNU. Perhaps they'd be happy to make it fully GNU so you guys can have a fully unified phyiscs system. You can try the demo here: https://github.com/NVIDIAGameWorks/FleX Works on Nvidia and Amd GPU's.

Philipp Oeser removed their assignment 2021-09-13 12:46:27 +02:00

Philipp Oeser commented

2021-09-13 12:46:27 +02:00

Added subscribers: @JacquesLucke, @Sergey, @dr.sybren

Philipp Oeser commented

2021-09-13 12:46:27 +02:00

As a triager, I am afraid I will have to step down and let the #nodes_physics module take over (as much as I'd like to get down to it it just eats too much time that is needed to fight other reports :/)

I can only raise awareness to @Sergey or @dr.sybren or @JacquesLucke perhaps, and yes since I have done that I would also think this deserves High prio.

As a triager, I am afraid I will have to step down and let the #nodes_physics module take over (as much as I'd like to get down to it it just eats too much time that is needed to fight other reports :/) I can only raise awareness to @Sergey or @dr.sybren or @JacquesLucke perhaps, and yes since I have done that I would also think this deserves High prio.

michael campbell commented

2021-09-13 14:58:20 +02:00

👍

michael campbell commented

2021-09-18 17:40:35 +02:00

Is anyone looking at this?

Sergey Sharybin commented

2021-09-20 09:24:17 +02:00

To my knowledge nobody is working on this issue due to being busy in other projects.

This is not likely to have an easy fix, as the rigid body was violating some fundamental designs to make certain things appear to work. If we consider this a high priority issue we need to make sure there is a dedicated time from a developers allocated to look into solving those fundamental issues with the rigid body system design.

To my knowledge nobody is working on this issue due to being busy in other projects. This is not likely to have an easy fix, as the rigid body was violating some fundamental designs to make certain things appear to work. If we consider this a high priority issue we need to make sure there is a dedicated time from a developers allocated to look into solving those fundamental issues with the rigid body system design.

Philipp Oeser commented

2021-09-20 09:52:47 +02:00

Added subscriber: @dfelinto

Philipp Oeser commented

2021-09-20 09:52:47 +02:00

@Sergey: feel free to change priority back (or maybe @dfelinto might also have an opinion?)

We can also declare (some parts of) RB physics (or interaction between different simulation systems in general) EOL and make sure simulation integration in geometry nodes tackles this properly (or clearly states that this is not supported).
I just set the High priority because in its current form, it is a completely broken feature.

@Sergey: feel free to change priority back (or maybe @dfelinto might also have an opinion?) We can also declare (some parts of) RB physics (or interaction between different simulation systems in general) EOL and make sure simulation integration in geometry nodes tackles this properly (or clearly states that this is not supported). I just set the High priority because in its current form, it is a completely broken feature.

Sebastian Parborg commented

2021-09-20 10:28:06 +02:00

We need to do a deep clean/refactor of our rigidbody code to properly fix some other crashing issues that are there because of some very bad design choices in the current code that can't be fixed.
So as Sergey pointed out, I don't either think this will be a high priority issue because of the amount of planning and time this need to be fixed properly.

In general, none of our current physics sims interacts with each other in a good way.
Sometimes it might work, but that is mostly because of luck. This is because all is not most systems are not aware of each other in any way.
Hell even multiple cloth sims have trouble interacting with each other already.

To make that better we need to do even more rewrites and cleanups.

We need to do a deep clean/refactor of our rigidbody code to properly fix some other crashing issues that are there because of some very bad design choices in the current code that can't be fixed. So as Sergey pointed out, I don't either think this will be a high priority issue because of the amount of planning and time this need to be fixed properly. In general, none of our current physics sims interacts with each other in a good way. Sometimes it might work, but that is mostly because of luck. This is because all is not most systems are not aware of each other in any way. Hell even multiple cloth sims have trouble interacting with each other already. To make that better we need to do even more rewrites and cleanups.

michael campbell commented

2021-09-20 15:31:20 +02:00

I did notice that everything works as expected if the collision mesh is set to anything other than mesh or convex hull. It does start having a schizoid embolism though, which can only be cleared by checking and unchecking the animated checkbox of the rigid body settings:

hmm, maybe I could cover the cube with particles, set the object they're instancing as animated rbd with sphere collisions, and then the particles would act as the collision rather than the meshes geometry.....

2021-09-20 14-27-26.mp4

I did notice that everything works as expected if the collision mesh is set to anything other than mesh or convex hull. It does start having a schizoid embolism though, which can only be cleared by checking and unchecking the animated checkbox of the rigid body settings: hmm, maybe I could cover the cube with particles, set the object they're instancing as animated rbd with sphere collisions, and then the particles would act as the collision rather than the meshes geometry..... [2021-09-20 14-27-26.mp4](https://archive.blender.org/developer/F10514265/2021-09-20_14-27-26.mp4)

michael campbell commented

2021-09-20 16:16:39 +02:00

yep, super messy workaround. It seems the bug isn't the physics system though, more to do with the depsgraph?

2021-09-20 15-12-42.mp4

yep, super messy workaround. It seems the bug isn't the physics system though, more to do with the depsgraph? [2021-09-20 15-12-42.mp4](https://archive.blender.org/developer/F10515132/2021-09-20_15-12-42.mp4)

Bastien Montagne commented

2021-09-20 16:54:44 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2021-09-20 16:54:44 +02:00

This is certainly not high priority, as already said by others RB needs serious re-design... This is not even a bug actually, but rather a known issue.

michael campbell commented

2021-09-20 17:06:41 +02:00

For anyone arriving here with one of the other issues caused by this bug; for non-deforming rbd driven geometry which should act as a mesh shaped cloth collision . Duplicate object being driven by rbd, remove rbd from duplicate, parent to original, and then give duplicate a collision modifier (remove collisions modifier from parent/original):

2021-09-20 16-03-40.mp4

For anyone arriving here with one of the other issues caused by this bug; for non-deforming rbd driven geometry which should act as a mesh shaped cloth collision . Duplicate object being driven by rbd, remove rbd from duplicate, parent to original, and then give duplicate a collision modifier (remove collisions modifier from parent/original): [2021-09-20 16-03-40.mp4](https://archive.blender.org/developer/F10515355/2021-09-20_16-03-40.mp4)

Bastien Montagne added this to the Core project 2023-02-09 15:42:54 +01:00

Bastien Montagne removed this from the Core project 2023-02-09 18:20:37 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

RBD sim ignores mesh (cloth) deformation #91183