Jump to content

[SOLVED] Defenition of intersection of two meshes during an animation


photo

Recommended Posts

Hello! We have a problem with detecting a point of intersection of two meshes when theese moved in fast animation. For example detect collision of swords. The problem is that swords exist not whole trajectory what we can see but just in particular frames. If in that frames meshes isn't intersects we can't detect collision.

post-831-0-82705400-1382443099_thumb.png

Link to comment

No expert in this area, but I don't think your mesh-based intersection detection approach will do the trick. Instead - at least as an idea - I would try to rely on available physics engine functionality for (continuous) collision detection.

 

The animated character should have some BodyRageDoll assigned and the sword should have some Capsule collision shape with enabled continous collision detection. If done correctly the physics engine should be able to calculate collision contact points automatically and exactly during animation and call your defined body collision callback function.  

Link to comment

Thank's we have tried but it doesn't works. Expanding line to capsule just increase of probability of detection but doesn't resolve the problem completely. "Continious collision detection" whether demands some adjustment or  doesn't works.

Link to comment

Well, we use VSync but tests without it also. Without VSync FPS about 200 - 220. Used to default number of iterations, but increasing to 16 does not helps.    

Link to comment

You should provide a small test scene with your animated fighting characters/swords meshes and physics setup to illustrate the problem. Otherwise it will be hard to provide you any working proposal for problem resolution. 

Link to comment

Hello,

It seems, that sword position is set directly, so changes in physics settings don't affect to accuracy of collision detection.

You can try to use triggers to check the collision or attach the sword to a player with a joint to simulate sword movements physically.

Link to comment

Thank you very much! The way using physical triggers helps to solve our problem! But we can't define a contact point in PhysicalTrigger enter_callback(Body body). Function body.getNumContacts() returs 0. 

Link to comment

Now we have another question. When VSync is turns on the problem appears again. To solve that, we increase iterations of physical setting of scene up to 32. It helps but it's ok for the performance? And what is the optimal range of that parameter in accuracy-performance ratio? Thanks in advance!

Link to comment

Hi again. We expecting from continuous collision detection that it construct trajectory between the frames to detect intersection independently to physical setting, FPS etc. There is the point in the documentation:

 

"If a sphere or a capsule participates in the contact with any other shape or surface, continuous collision detection (CCD) is performed. Unigine takes velocities of the body, radius of its shape and calculates what contacts this body will have (during the current physics tick), assuming it continues its current trajectory. So, unlike the simple collision detection, contacts are analyzed not discretely, once per physics tick, but rather found for the whole frame."

 

And there is respective checkbox in editor. But it seems not like that or we do something wrong? Unfortunately our test shows that detection occurs just in high FPS. Is it possible to solve the problem for any FPS and iterations by standart Unigine means?  

Link to comment

Hi,

Continuous collision detection is an approach, when the body that is moving is extruded along its way (between two frames), and if something gets into this volume, a collision is detected, and the body is taken back in time to correctly react to the collision.

So, physical setting should be tuned if you want to avoid returning bodies in time.

Link to comment

Ok, we understand what is CCD like you do. But in some reason we can't take expected result. Would you like to send us any example where CCD works? It is desirable that it be without physics, the main point - without masses calculations i.e. we works with animations and the physical interference just a disadvantage. Thanks :)

Link to comment

You can check shapes/sphere_05 and shapes/capsule_03 samples.

CCD is not working without physics and available only for sphere and capsule approximation shapes.

If Nodes -> Shapes -> Continuous checkbox is unchecked you need to increase physics fps to detect the collision.
But even if CCD is enabled low physics fps can cause skipping collision if body's velocity is too high.

 

Link to comment

Thanks, your examples works correctly. Nevertheless our tasks related with frame based animations. We have to apply position of the object every update (because we can't use joint to attach it, joints are too flexible for our purposes) and in this case CCD seemingly skipped. Than a question. Is there a way to apply CCD functions manually in updates or flushes? 

 

Additionally we have to set zero mass of the shape. Unless some micro collisions and vibrations occurs plus resources leaks in vain. But without mass collisions are not detects at all, even discretely. But setting the mass positive also not solve the problem just increase detection probability beyond zero.

Link to comment

Ok, thanks for answering. Then, is there another way to use CDD in animations in our case? Or advise please some another way to solve it? We can't have dependence from high FPS rate to detect collision, it will be different in users machines.

Link to comment

Thank you for your participation. We had tested the modified example and result is the same that probably you get (some hits are missing) and the same that we've get before. 

Link to comment
  • 3 months later...
  • 2 weeks later...

Hello again!

 

Long time, no see. :)

 

I came up with a new idea: instead of moving sword's collision shape just create 'sweep collision shape' and enable it on during animation (I guess the best moment for that is when the enemy is nearly get hit by the sword) and then you'll get your contact points; don't forget to disable that shape after sweep.

 

Just see this demo for better understanding about 'sweep collision shape' (no source code, sorry): http://aztez.com/blog/2014/01/06/anatomy-of-a-successful-attack/

Link to comment
×
×
  • Create New...