3 minutes ago, Fulcrum.013 said:

(require to scale objects to convert ellipsoide to sphere, perform sphere test with scaled objects, and then scale results back)

This is something i've always wondered about. It's not possible to calculate the closest distance to an ellipse from a point analytically so it needs some iterations. But if you scale both point and ellipsoid so ellipsoid becomes a circle, find closest point and unscale back, then the closest point is not really the closest one, leading to bad behavior especially if the ellipse is very flat.

So i guess iterations are necessary, turning ellipsoid into a more expensive primitive?

10 minutes ago, Fulcrum.013 said:

so usualy it used into real-world robotics only (at least i never seen a game-intendent physic engines that support ellipsoids).

I don't think it's that uncommon. Newton a least supports non uniform scale for any body, including spheres or capsules.

35 minutes ago, JoeJ said:

But if you scale both point and ellipsoid

Closest point evaluation and detecting fact of collision obviuosly is a  different tasks.

1 hour ago, JoeJ said:

So i guess iterations are necessary, turning ellipsoid into a more expensive primitive?

Realy it  is  two kind of costs for collision detection - cost to determine fact of warrantied absent of collision and cost to compute actual interpenetration of collided object and other collidion properties. Obviuosly first kind of cost is much more importent becouse performed much much often then second. So in case collider have a cheap detection of fact of collision and better fill factor that lead to much rare perfirming  of complexive test its totally cheaper.  

34 minutes ago, Fulcrum.013 said:

Obviuosly first kind of cost is much more importent becouse performed much much often then second.

I know and am quite experienced with broadphase, but the fact engines support ellipsoid made me think i might miss something about an efficient closest point method. (I use ellipsoids at character skin vertices for cloth, and the approximation i do causes jitter under stress.)

2 hours ago, JoeJ said:

It's not possible to calculate the closest distance to an ellipse from a point analytically so it needs some iterations.

But most of tests dont lead to it task. For example to find distance from ellipsoide to plane it reauire to just build tangent plane that is parallel to tested,so scaling works for it.  Also curved shapes usually used with algos that predict collisions time instead to detect and eleminate interpenetrations, so it lead to finding of points that closest in given direction that is much easy task.

2 hours ago, JoeJ said:

So i guess iterations are necessary, turning ellipsoid into a more expensive primitive?

Really polyhedras tests iterative for common case too. Worst case complexity is O(n+m+n*m) axis test where n and m is number of faces of tested polyhedras. Testing of each axis require to project all vertices of both bodies to it, so it require a polynominal quantity of dot productions in total. So curved shapes in total much cheaper and precise than its polyhedral approximation for cases where we can find a implicit form of shape equation. But it much more tricky to implement, especially for shapes like torus and so on that can not be cuted to convexive parts. 

1 hour ago, JoeJ said:

I don't think it's that uncommon. Newton a least supports non uniform scale for any body, including spheres or capsules.

When I first tried this years a ago I used an article describing ellipse collision. When I implemented it, It worked but at oblique angles my ellipse would quickly get caught in geometry.  I switched to a stack of 3 spheres (you can see it in the picture I posted in the comment section of my blog) but I had the same exact problem. It baffled me for several days. Then I discovered the problem wasn't with the ellipse at all but the fact that I was using double precision, was far from the origin, and at the time visual C++ (against the standard ) defaulted to single precision calculations even if you specified double in your code ?. When I changed to double precision everything worked perfectly. I ended up keeping the spheres though because my world was a sphere and so I couldn't just scale things in one axis.  However from what I understand a lot of games do just that. 

The other issue I have heard about with the ellipse is depending on the exact ellipse, sometimes they have an issue with characters going up stairs because the of the angle if incidence.  However as far as I know there is no iteration needed or anything like that.

16 minutes ago, Fulcrum.013 said:

so it lead to finding of points that closest in given direction that is much easy task.

Yeah, i think this should be the solution. I'll try this out when i get back to this...

13 minutes ago, Gnollrunner said:

When I changed to double precision everything worked perfectly.

... this reminds me, when working on my own physics engine decades ago, i was using double precision too just to get rid of jitter.

I really was fanatic about this - i did not knew about conserving momentum, so having no jtter was my way to 'proof' the math to be right, haha

25 minutes ago, JoeJ said:

and the approximation i do causes jitter under stress

Jitter can be caused by violation of energy conservation low only. Its mean that body dont spend a energy on collisions (that is inposible in case restitution factor less than 1 at all) or interpenetration elimination algo bring a additional energy to systems. Without it additional energy any jitting decrease a magnitude so stop very shortly. Obviuosly it issue come from source other than shape of colliders.

24 minutes ago, JoeJ said:

... this reminds me, when working on my own physics engine decades ago, i was using double precision too just to get rid of jitter.

In my case I was simply too far from the origin.  You're precision gets eaten up fast when you are far away from it. Usually I put (0,0,0) at the center of the world for convenience, so any place on the surface you are far. The other way is to use some local coordinate system for collision, but since I'm building in double it's just easier to do everything in double and you can avoid all the conversion and unexpected rounding errors.  The only exception is with the graphics where everything is in float so you have to do something.

4 hours ago, Fulcrum.013 said:

require to scale objects to convert ellipsoide to sphere, perform sphere test with scaled objects, and then scale results back)

This is clearly wrong! Angles are not preserved under non-uniform scaling. The  closest point to a circle is not necessarily the closest point to an ellipse after re-scaling back!. See example below.