   Continuous Collision Detection for translating Ellipsoid
  Comments for the article Continuous Collision Detection for translating Ellipsoid
  Very useful article but it is not for n00bs. It has a somewhat heavy vector math that is not explained in full details, its for the ones who have solid knowledge in vecmath. And I found something wrong:Quote:P will be inside triangle if,    0 ≤ s0 ≥ 1    0 ≤ s1 ≥ 1Shouldn't it be 0 ≤ s0 ≤1 and 0 ≤ s1 ≤ 1 ?!;  I'm always wondering, why collision with edges is connected with collision with triangle, IMHO it's separate stuff.For example, in following situation(ellipsoid going from the top towards shared edge of two triangles):0/\ellipsoid shouldn't collide with triangles, only with their shared edgeand collision normal should be normalised average of triangle edges normals, pointing up.Am I missing something?   ;Quote:Original post by xissburgShouldn't it be 0 ≤ s0 ≤1 and 0 ≤ s1 ≤ 1 ?!That's correct. Thanks for pointing that out.Quote:Original post by tmr_tommyzI'm always wondering, why collision with edges is connected with collision with triangle, IMHO it's separate stuff.For example, in following situation(ellipsoid going from the top towards shared edge of two triangles):0/ellipsoid shouldn't collide with triangles, only with their shared edgeand collision normal should be normalised average of triangle edges normals, pointing up.Am I missing something?You have got a very valid point there - certainly there is redundancy here. This could be dealt with by storing edge - triangle adjacency info and flag every edge once it has been queried for collision. But would the memory overhead be justified? Wonder if there is a known solution here....Btw, how would you define the normal of an edge? Note that for smooth collision response the normal cannot be discontinuous. The normal for a collision point on an edge will have to be along the reverse ellipsoid surface normal at this point.   ;Quote:Original post by chand81Quote:Original post by tmr_tommyzI'm always wondering, why collision with edges is connected with collision with triangle, IMHO it's separate stuff.For example, in following situation(ellipsoid going from the top towards shared edge of two triangles):0/ellipsoid shouldn't collide with triangles, only with their shared edgeand collision normal should be normalised average of triangle edges normals, pointing up.Am I missing something?You have got a very valid point there - certainly there is redundancy here. This could be dealt with by storing edge - triangle adjacency info and flag every edge once it has been queried for collision. But would the memory overhead be justified? Wonder if there is a known solution here....Now I have proper response using separate edges, but levels are quite small so memory overhead isn't a problem.Quote:Original post by chand81Btw, how would you define the normal of an edge? Note that for smooth collision response the normal cannot be discontinuous. The normal for a collision point on an edge will have to be along the reverse ellipsoid surface normal at this point.You're right, I totally missed this.. So, for collision points within triangle interior I can just use triangle normal for simplicity(as it's always equal to reverse ellipsoid normal?) and for edges/vertices I need to calculate reverse ellipsoid surface normal for collision point - and this should make nice smooth continuous response I guess, right?;Quote:Original post by tmr_tommyzYou're right, I totally missed this.. So, for collision points within triangle interior I can just use triangle normal for simplicity(as it's always equal to reverse ellipsoid normal?) and for edges/vertices I need to calculate reverse ellipsoid surface normal for collision point - and this should make nice smooth continuous response I guess, right?Thats correct, just like in the case of sphere collision.   ;Quote:Original post by xissburgAnd I found something wrong:Quote:P will be inside triangle if,    0 ≤ s0 ≥ 1    0 ≤ s1 ≥ 1Shouldn't it be 0 ≤ s0 ≤1 and 0 ≤ s1 ≤ 1 ?!Fixed - thanks!   ;Quote:Original post by chand81You have got a very valid point there - certainly there is redundancy here. This could be dealt with by storing edge - triangle adjacency info and flag every edge once it has been queried for collision. But would the memory overhead be justified? Wonder if there is a known solution here....As I understand it, the original Halo used a system somewhat like this for handling collision. When querying their spatial subdivision structure for primitives to test against during collision, it would return not the usual list of triangles but a list of edges, vertices and faces. This has several advantages, not the least of which is that it avoids redundant checking of the same edge/vertex multiple times, and you can also avoid checking concave edges (which can't be hit before their attached faces) for example.   ;Quote:Original post by d00fusAs I understand it, the original Halo used a system somewhat like this for handling collision. When querying their spatial subdivision structure for primitives to test against during collision, it would return not the usual list of triangles but a list of edges, vertices and faces. So the edges and vertices are tested independently?Quote:Original post by d00fusand you can also avoid checking concave edges (which can't be hit before their attached faces) for example.How is this implemented?In this implementation, the point in triangle test succeeds and exits the detector skipping the concave edge....;Quote:Original post by chand81So the edges and vertices are tested independently?The set of faces, vertices and edges is tested to find the closest impact point (if any). It's worth noting that in many cases a lot of vertices can be skipped as their associated edges already provide the necessary collision support.Quote:Original post by chand81How is this implemented?In this implementation, the point in triangle test succeeds and exits the detector skipping the concave edge....You'll find in practice that it is very difficult to make point-in-triangle checks robust for all input using floating point arithmetic. In this case you can end up in the best case checking redundant triangle edges, in the worst case missing collisions entirely (this is more a problem with raycasts - however generally you're going to want to use the same collision geometry for these). Having an explicit edge representation (perhaps using "fat edges") will often be a significant improvement as well as allowing you to skip redundant edge tests in all cases.   