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.

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.)

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

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.