NikiTo said:
It is something they teach students in the second month in any programming school.

It is something really basic in computing. It is mentioned everywhere.

I won't try to cure your anxiety about floating point precision limitations because i know that's hopeless ; )

But it clearly is not the problem here, and proposals to use ‘someone else's library’ just because of your assumptions is not very helpful.

Notice he uses a ball with a radius, not a point. In practice this rules out all precision issues you gave as examples in this thread.

All of these approaches mentioned here were made in order to address floating precision problems. If there were no floating precision problems, directly computing the intersection would suffice.

I painted a nice doodle explaining how floating point math produces the jitter over the edge. Step by step. But i am deleting it now.

If i say Cyanide is toxic, Joej would drink a gallon of Cyanide only to prove i am wrong.

Good luck with your projects! Time runs fast…

NikiTo said:

…

If i say Cyanide is toxic, Joej would drink a gallon of Cyanide only to prove i am wrong.

Good luck with your projects! Time runs fast…

Haha, mirrors my experience.

He seems to think it's OK to have unreasonable levels of naïveté because that's somehow preferable to “having prejudice” .

… not only it's not OK:

Well, not sure if it's necessary to drag private discussions into the public, but to address ‘proof and naivety’ i remember my failure to explain to both of you:

1. Raytraced shadows have no peter panning
2. TAA can be equivalent to supersampling

… but even after implementing both of them just to proof those things, you guys can't overcome your personal opinions / prejudges, fail to look at it just from a technical prespective, fail to learn and admit your assumptions might be wrong.
And most importantly: Fail to accept different people have different convictions and opinions, and might be unwilling to adopt yours just for the sake of peace about whatever unrelated topic.

And worst: Making those personal things public (by hijacking other peoples threads), attacking and accusing me - that's not only childish as usual, it also is unfair and only shows how hard it is for you to maintain social relationship, which i'm sorry about but can't help it.

Maybe we can just one time behave like grown up people and forget about this? Thanks.

JoeJ said:
Well, not sure if it's necessary to drag private discussions into the public,

No need to do that.

JoeJ said:
Raytraced shadows have no peter panning

Yeah, no need to bring that either, because it is a little bit off topic.

But, Joej, i have to repeat what you said to me in many public discusiions here - (perephrasing)"I can not allow you to misinform other people in this forum"

JoeJ said:
Notice he uses a ball with a radius, not a point. In practice this rules out all precision issues you gave as examples in this thread.

This is a LIE! And it could be damaging to people who use forums to learn.

In this case -

FP math could tell you that the circle/sphere touches the line/surface. But it is not touching in real life.

Depending of the level of precison you use, the same algorithm could tell you that the intersection point of the circle/sphere and line/surface is "randomly around" the expected -

This could work if you are close only to a single line/surface.

But if your circle/sphere is close to various linesSegments/planes at once, it could happen that the same algorithm, once detects the closest intersection to be with lineSegment/plane A, and other time it detects that the closest intersection is with lineSegment/plane B. And this could create jittering.
(When i say "close" i don't mean close to the center of the circle/sphere, but close to its circular/spherical surface, or in other words - the difference between the distance of the center to the line/surface and the radius is small enough as to keep computing a possible collision)

Even after applying the techniques you mentioned, FP problems still exist, and still attempt to give problems. But now the program is working good enough. FP is still imprecise, but the program works good enough.

If somebody needs too much time to learn how to sort out FP problems or can not accept the truth because of ego, and if the main goal of that somebody is not to learn, but to produce a working app in reasonable time, then that somebody should try to use the code of other people.

Using the code of other people is a core part of modern programming practices.

And, not use the code of other people just because their reputation or nice avatar photo but using it because it works. After the code of other people is tested inside the one's own app and it works good enough, that code could be used.

_WeirdCat_ said:

I rather loose year of life to understand evertyhing and make it work rather than use someone elses code ?

It is your right to do with your own time whatever you want. You are a free person. I did it myself for 2D. Was planning to do it for 3D too, but abandoned it there. It improved my understanding about FP and this helps me in other projects now. Although i think i would never need 2D collison in mi life.

It is up to everyone to decide if he prefers to improve productivity or to learn more about the matter.

A small example how messy is FP -

The dot(for sake of example i will use a dot) is the player and the red arrow is his direction of movement -

We cancel out the impossible part of the path and replace it -

We compute the new position of the player -

oops, fauty FP computation gave you a new position that is behind the wall -

Only a frame happened so far. The player keeps holding the same direction keys, so the direction is the same. And now, the player will not detect the colision(or could detect it because FP is random around) -

Then you could try a trick. Every time after the new position of the player is computed, you could project it on the wall in order to fix the error -

oops, faulty FP projected it on the wrong side of the wall again -

Then you add a bias to the projection. A small bias that the player would never notice.

You can see it is still incorrect. It is neither on the wall, neither on the projection line. It is completely wrong. But at least now, it is wrong on the correct side of the wall. At least the player will not pass through the walls now.

(orange arrow is offsetted in order to be easier to visualise)

It is just an example. If you are going to do it yourself it is you who needs to push his own head with it. Others and I, we can give you tips from time to time and examples. I will never code it for you, because I am lazy, and you don't want the code of other people anyways. So play with it. Take pencil and paper and emulate it step by step. And for every emulation, paint the result “randomly around” the expected. Close to the expected but randomly offseted in all directions. Then it will become easier to understand. All the needed formulas to project, intersect shapes, measure distances etc are all abundand on the internet.

How you compute the new slided position of the player is a different story. You might want to just trick it to look nice to the player or you might want physics simulation for friction. I am not touching that part.

NikiTo said:
A small example how messy is FP - The dot(for sake of example i will use a dot) is the player and the red arrow is his direction of movement -

If you would not have written this post, i would have done for you. Because you just confirmed my assumptions why you had issues to implement 2d collision detection.

It is not because of precision, it is because of an ill posed problem, and it is your failure to have missed that. Your conclusion, precision prevents things from working was wrong.

So i will try to fix this for you. Because, yeah, i always know everything better, i know. But i'm old. And i can't help i have implemented simple 3d collision detection successfully while you failed on the 2d case. I can't help i know it better than you do.

So listen…

Your example is a point colliding with a line in 2d. But this can never work, because if the point is exactly at the line, there is no way to tell where did it came from? Even with infinite precision, it would not work as intended.

To make it work, you need a definition of solid and empty space. E.g. A Polygon, or having a tangent for the line that identifies which side is solid, or having a BSP tree, whatever.
Then you can just make sure the point keeps outside solid space, and do corrections if necessary.
Ask yourself: If stuff has no area, no volume, so no mass either - how should it collide with other such non existing stuff properly at all?

Think about it. And think how using a ball instead a point already removes the problems you mention, and how exactness is not necessary to be infinite.
But using a ball also introduces more complexity because face, edge and vertex collisions cause different collision response.

NikiTo said:
But if your circle/sphere is close to various linesSegments/planes at once, it could happen that the same algorithm, once detects the closest intersection to be with lineSegment/plane A, and other time it detects that the closest intersection is with lineSegment/plane B. And this could create jittering.

If you have multiple contact and you resolve contact A than B, A bay be violated again so we gent jitter. But again it is our own fault, not caused by precision.

To resolve this properly, e.g. ball intersecting 2 walls at a corner, we can displace wall planes by ball radius, calculate their line of intersection and put the ball at this line to resolve both collisions at once.
Same works for 3 planes where intersection becomes a point.
With more than 3 we could calculate Minkovski sum (which i have no experience with), and put the ball center to the closest point on the new surface.

NikiTo said:
Yeah, no need to bring that either, because it is a little bit off topic.

Agree, sorry for that. Got triggered because multiple people start to attack me out of nowhere on the wrong place.

Please notice that i did not say you would not be helpful, or your assumptions about FP precision would be pointless BS. I did not address any of your posts with my response at all, i only added what i think is the real reason for the problems.

It was you who interpreted all those things in my simple saying:

It seems you have jitter because instead doing that, you alternate both adjacent lines (or faces in 3D). It's clearly a mistake but no floating point precision issue.

… which is in no way rude or personally addressed to you, and it's not even sarcastic. Read it once more.
But still, again you got triggered, and the old paranoia comes back telling you everybody is against you, everybody wants to proof you wrong, it is something personal… and you make the thread explode again… But as said, your mind fools you, and you do not get the real intent.
I admit, i did indeed think things like: ‘Why does he reply on 3D collisions if he even did not get the 2D case working? How does he think he could be helpful?’. But i did not say that. Now i do, but it is a consequence of your own actions. You cause exact those things that you do not want to happen, entirely on your own. So there is a reaction, yes, but you are wrong about the cause. The cause is you, not me, or all the others.

If only you would realize… i think you could just control yourself, follow logic and reasoning instead intuition - i think you could make things much more easy for you.