Problems with physx collison
#1
Have a problem with tylow collision shape. When binded mesh gets wrinkled/bend the collision shape does those weird spikes which breaks the chain.


Also is there a way to prevent the collision shape to get too close to or through itself? A way to leave a gap or something like that which wont break the chain.



Attached scene is just an example to clarify the issue which i have with my actual project. This seems over exaggerated, but i am occuring these situations alot and cant find a solution to prevent the chain to break.





https://drive.google.com/file/d/1tABb7ql...ePC2a/view


Attached Files
.max   Untitled.max (Size: 3.14 MB / Downloads: 57)
  Reply
#2
if I understand correctly...

...that's one of the reasons I usually avoid using PhysX Collision operator, for complex collisions (with animated colliders), but instead, I just create another (separate) event with PhysX, for all objects that are meant to be colliders.
That separate event usually looks like this:
- Birth objects (pick objects that are meant to be colliders)
- Voronoi (if objects are concave)
- Object bind (pick objects that are meant to be colliders)
- PhysX Shape
- PhysX Switch (Kinematic)

Basically voronoi act here as "resolution", and the more you increase it, the more precise it will be.
I think Tyson itself mentioned somewhere, that PhysX collision, if collision object is animated, can lead to some bugs.
That's why I just recreate the whole collision stuff as separate PhysX event with kinematic in PhysX Switch.

If it's still breaking the chain, try increasing timesteps, or increase binding (if you use them).
  Reply
#3
That solution didnt change anything, with or without physx the issue remains, looks even worse 
Compare pics in attachment

If i did it wrong, then correct me...

And no, this doesnt have to do with timestep, substeps etc.

Parts of the collider shooting out and piercing or squeezing through the chain in a couple of frames, all visible in the video i posted...
How does increasing the steps should change that?
I made the effort to rebuild and record that issue, so please watch it careful next time


Attached Files Thumbnail(s)
       
  Reply
#4
(01-11-2022, 09:38 AM)ZZpbt. Wrote: And no, this doesnt have to do with timestep, substeps etc.

Just loaded quickly the scene file you posted, changed timestep to 1/8, and the chain didn't break. 

Yeah, you're right, I should take more carful look (because you basically had already setup scene like I suggested), but I didn't had the time for careful look, but I just wanted to (quickly) help. 
In any way, I think we all sometimes expecting too much of PhysX (that is basically solver for games, and it works best only with convex shapes), and I don't think PhysX really like underlying vertex animations, and stuff like that.... unless you "help it" solve. 
That's why I almost always (for complex sims), create separate model for PhysX, and separate for render... Tymesher is also often handy for creating collision objects out of some very complex geometry.
  Reply
#5
(01-11-2022, 12:51 PM)d4rk3lf Wrote:
(01-11-2022, 09:38 AM)ZZpbt. Wrote: And no, this doesnt have to do with timestep, substeps etc.

Just loaded quickly the scene file you posted, changed timestep to 1/8, and the chain didn't break. 

Yeah, you're right, I should take more carful look (because you basically had already setup scene like I suggested), but I didn't had the time for careful look, but I just wanted to (quickly) help. 
In any way, I think we all sometimes expecting too much of PhysX (that is basically solver for games, and it works best only with convex shapes), and I don't think PhysX really like underlying vertex animations, and stuff like that.... unless you "help it" solve. 
That's why I almost always (for complex sims), create separate model for PhysX, and separate for render... Tymesher is also often handy for creating collision objects out of some very complex geometry.

Not going to increase simulation time by 8 just because it didnt break in your test (stated clearly that this is just an example scene to show the issue, doesnt even matter if the chain breaks or not).
That is no solution. The problem is clearly the fractured/voronoid collider and not physx. Posted 2 pics where you can see, that physx isnt even activated. Didnt you take a look?
I am able to simulate 3k frames animation with heavy motion and no 1/8 necessary for chains to stay together. They only break because parts of the collider doing these unnecessary spikes that pierces through chain while trying to follow binded mesh...
Btw i too use 2 different meshes.
  Reply
#6
Hi tyflow, could i get your attention on this matter, please?
  Reply
#7
The method of doing deforming mesh collisions with a Face-Fractured mesh and then binding all those pieces to the original geometry is not foolproof. Depending on your deformations, it's not always possible (*usually* not possible, in fact) to maintain a 1:1 correspondence between deforming mesh face shearing levels and squash/stretch of the bound kinematic particles...so they lose parity under stress pretty quickly.

In general, the PhysX library is not that great for really tiny, detailed rigidbody setups colliding with large, deforming meshes (like a chain on a neck, as in your case). A small chain composed of actual independently colliding links colliding with a large deforming mesh is somewhat of a worst-case scenario.

You can try a couple of things:

You can skip the kinematic setup entirely and just add the deforming mesh as a Mesh collider, and increase your PhysX substeps (not the overall sim timestep). In your scene that prevented the chain from breaking. See attached.

Another thing you can do to improve your original setup, is to simply subdivide your neck collider a lot more, so the size of the kinematic faces is a lot smaller. Smaller faces means less deformations, less deformations means better collisions. You can optimize this solution by deleting all faces on the collider mesh that won't be needed for collisions, ensuring that only those faces you anticipate will collide with the chain are present in the sim. Don't forget to enable Scale bind in the Object Bind operator too. I also found that setting the Object Bind velocity mode to verlet seemed to improve stability on the kinematic particles. See attached.

Neither solution is particularly fast to simulate, but they both satisfy the criteria of chain not breaking while undergoing collider deformation.


Attached Files
.max   chain_subdivided.max (Size: 3 MB / Downloads: 54)
.max   chain_substeps.max (Size: 3 MB / Downloads: 47)
  Reply
#8
(01-19-2022, 03:04 PM)tyFlow Wrote: The method of doing deforming mesh collisions with a Face-Fractured mesh and then binding all those pieces to the original geometry is not foolproof. Depending on your deformations, it's not always possible (*usually* not possible, in fact) to maintain a 1:1 correspondence between deforming mesh face shearing levels and squash/stretch of the bound kinematic particles...so they lose parity under stress pretty quickly.

In general, the PhysX library is not that great for really tiny, detailed rigidbody setups colliding with large, deforming meshes (like a chain on a neck, as in your case). A small chain composed of actual independently colliding links colliding with a large deforming mesh is somewhat of a worst-case scenario.

You can try a couple of things:

You can skip the kinematic setup entirely and just add the deforming mesh as a Mesh collider, and increase your PhysX substeps (not the overall sim timestep). In your scene that prevented the chain from breaking. See attached.

Another thing you can do to improve your original setup, is to simply subdivide your neck collider a lot more, so the size of the kinematic faces is a lot smaller. Smaller faces means less deformations, less deformations means better collisions. You can optimize this solution by deleting all faces on the collider mesh that won't be needed for collisions, ensuring that only those faces you anticipate will collide with the chain are present in the sim. Don't forget to enable Scale bind in the Object Bind operator too. I also found that setting the Object Bind velocity mode to verlet seemed to improve stability on the kinematic particles. See attached.

Neither solution is particularly fast to simulate, but they both satisfy the criteria of chain not breaking while undergoing collider deformation.

Ok then there is no way to prevent this behaviour... None of these are solutions (mostly already tried) to prevent the collider to do those weird spikes when binded mesh surface starts to crease/fold a little too much. So you forced to arduously "clean" mesh frame by frame.
That is the only problem which breaks the chain the whole time...

Anyway, regarding the other question:
Also is there a way to prevent the collision shape to get too close to or through itself? A way to leave a gap or something like that which wont break the chain?
  Reply
#9
(01-25-2022, 12:32 AM)ZZpbt. Wrote: Anyway, regarding the other question:
Also is there a way to prevent the collision shape to get too close to or through itself? A way to leave a gap or something like that which wont break the chain?
  Reply
#10
You mean like, a way to prevent it from self-intersecting, even if the animation on it self-intersects?
  Reply
#11
(01-31-2022, 03:13 PM)tyFlow Wrote: You mean like, a way to prevent it from self-intersecting, even if the animation on it self-intersects?

That and some kind of offset from particle to particle.
There is a way to prevent this with the cloth modifier, but again its tedious...
Is there a way to achieve this within tyflow, some combinations of operators etc.?
  Reply
#12
Preventing self intersection in an input mesh is difficult because detecting such things tends to be a history-dependent process (technically detecting intersections isnt history dependent, but finding the way to undo them is), so you're right, you'd have to resim with a cloth setup or something to solve those intersections.

Can you clarify what you mean by particle-to-particle offset?
  Reply
#13
(01-31-2022, 03:55 PM)tyFlow Wrote: Preventing self intersection in an input mesh is difficult because detecting such things tends to be a history-dependent process (technically detecting intersections isnt history dependent, but finding the way to undo them is), so you're right, you'd have to resim with a cloth setup or something to solve those intersections.

Can you clarify what you mean by particle-to-particle offset?

Willl do an example scene tomorrow
  Reply
#14
Here it is.
Just enable/disable relax and cloth modifiers and run simulation to see the effect.

Afaik cloth gives the verts an "soft" offset which is defined by thickness and repulsion properties.


Attached Files Thumbnail(s)
       

.max   Untitled.max (Size: 4.45 MB / Downloads: 49)
  Reply
#15
Hmm, well PhysX Shapes have a penetration offset setting that you can use to give each shape a little penetration buffer, but you're never going to run into a situation where colliders can fully intersect like in your second image and the simulation will remain stable.

Post-processing your mesh with relax modifiers, prior to input into the sim (like your first image) will be your best bet.
  Reply


Forum Jump: