problem with collisions detection

Blitz3D Forums/Blitz3D Beginners Area/problem with collisions detection

RemiD(Posted 2015) [#1]
Hello,

I need a way to detect if a 3d shape does not intersect with another 3d shape.
The 3d shapes are low tris but, after some tests it is too slow to use meshesintersect(mesh1,mesh2) so i am doing some tests with an ellipsoid collider and low tris collidables, however, i don't understand why, but the collision is not detected if i use the collision system like this :


Please note that i need to be able to create/destroy an ellipsoid collider when i want, where i want, in order to avoid some errors where a previously created ellipsoid collider gets stuck (resetentity does not seem to work in all cases).

Any help or suggestion is appreciated.

Thanks,


RemiD(Posted 2015) [#2]
A collision seems to be detected but not always when it should be... That's strange. It may explain why i have had some problems with this collision system in the past. I guess that i will have to rely on meshesintersect or maybe code my custom shapesintersect routine...


Floyd(Posted 2015) [#3]
A mesh is a hollow shell made of triangles, not a solid body. So if one mesh is inside another, but their surfaces do not touch, MeshesIntersect will be false.

Similar considerations hold for collisions. Entities must begin separated from each other. If movement brings them into contact then there is a collision. But if they begin in an intersecting state then they have not collided. If movement separates them they may collide later.


RemiD(Posted 2015) [#4]
double post


RemiD(Posted 2015) [#5]

So if one mesh is inside another, but their surfaces do not touch, MeshesIntersect will be false.


I know but that's not the problem here, the problem is with the collision system, sometimes it detects a collision between the ellipsoid and the collidable mesh, sometimes it does not.



But if they begin in an intersecting state then they have not collided. If movement separates them they may collide later.


That's not what i have seen in others similar tests... Sometimes a collision is detected even if the ellipsoid is already intersecting/through some triangles of a mesh...
If this was true, in this case a collision would never be detected, but sometimes it is...


Anyway, i will find another way (maybe a distance calculation and then, if near enough, a meshesintersect calculation)


Floyd(Posted 2015) [#6]
I tried about twenty repetitions ( space bar ) of your code and never saw anything obviously wrong.

There were no collisions detected, but that was correct. There were no collisions.

Note that all positioning and movement is based on random numbers. This makes the experiment non-reproducible. You and I do not see the same results.


RemiD(Posted 2015) [#7]

I tried about twenty repetitions ( space bar ) of your code and never saw anything obviously wrong.
There were no collisions detected, but that was correct. There were no collisions.


Try more and you will see, sometimes a collision is detected, the sphere (which represents the ellipsoid collider) and the cube (which represents the mesh collidable) will be colored in red.

In theory, a collision should be detected the same time a meshes intersection is detected.



Note that all positioning and movement is based on random numbers. This makes the experiment non-reproducible. You and I do not see the same results.


replace seedrnd(millisecs()) by seedrnd(1000) and on the 25th iteration you will see a collision detected. (i have tried on different computers and always the same results...)

After 100 iterations, a collision is detected the 25th, the 35th, the 78th, the 91th, and each time with a new ellipsoid collider...

Can we call this a bug ?


steve_ancell(Posted 2015) [#8]
You may be experiencing tunneling, do a search for colision tunneling correction. I know it normally applies to 2D but maybe it'll also work in 3D.


steve_ancell(Posted 2015) [#9]
Here's a page to get you started. ;)

http://www.stencyl.com/help/view/continuous-collision-detection/


RemiD(Posted 2015) [#10]
Thanks for the suggestion steve, but this has nothing to do with the problem explained here.

The "tunnelling" or "collider/body goes through a collidable because it moves too fast" is another issue.


By the way, i have managed to do what i wanted with a distance calculation and if near enough, a meshesintersect calculation.

But this problem is still annoying because, in theory, it should detect a collision if a ellipsoid collider intersects with a mesh collidable...


Floyd(Posted 2015) [#11]
I get the same four collision cases 25,35,78,91.

But I would not call this a bug. In each case the ellipsoid and cube are overlapping at the start. That is not a valid configuration for the collision system. They must be separated before movement and collision detection begins.

It's easier to see that they overlap if the camera positioning is replaced with this:

PositionEntity( Camera, 0, 50, 0 )  ; above the scene
PointEntity Camera, ObstacleMesh    ; looking down
TurnEntity Camera, 0, 0, 45         ; X+ is to the right, Z+ is up
CameraZoom Camera, 15



RemiD(Posted 2015) [#12]
@Floyd>>I have edited the code example to better see what is going on.


In each case the ellipsoid and cube are overlapping at the start. That is not a valid configuration for the collision system. They must be separated before movement and collision detection begins.


In this case why sometimes a collision is detected and sometimes it is not, while the cases are similar ? (the ellispoid collider intersects with the mesh collidable)
I think there is a bug or maybe as you say the collision system is not meant to be used like this.

Anyway, for what i want to do meshesintersect is more appropriate and fast enough if combined with a distance calculation before.

(In the end i won't use the collision system for anything ! I will use my own collision system with linepicks and pickables or a distance calculation then meshesintersects...)