@Keith_1357@petlimpet I’m honestly impressed by the effort you put into this … It’s beyond my knowledge to understand that math behind your ideas but I thought of something right now and thought to share maybe you can figure it out.
Why not create a single raycast in the center of object a and b and make the angle random(360) … put that inside a repeat event and make it like 20 times
This way the ray will shoot randomly super fast in all directions per frame.
.
Now the idea is to make the ray not go outside the object boundaries
.
And when a ray hit another object … create an object at the end of the ray and make the shooting of rays stops and when they don’t touch again… make the ray work again.
.
This I don’t know if it’s possible but I feel like it’s a good idea if it’s possible.
I won’t use random. But you can use repeat with a variable and scan like a radar. Although, I’m still unsure if it would find the right spot.
You could scan plus and minus a certain amount based on maybe the direction of movement. (forces). You could do large steps first then smaller to lock in.
In regards of the calculation overhead you don’t need to apply any of the various methods which you found before a collision happened, right?
So you should be able to just use normal collision condition first, and only if that happens you cast your ray.
(Btw, I really like the idea of the ray along the corner, which Keith postet in the beginning. I would go with that one, but cast one from p1 to p2, and another one from p2 to p1 (basically clockwise and anti-clockwise). Then use the point in the middle of the two resulting points. This should give you pretty good precision)
Maybe a useful tidbit could be to calculate the intersection of the two object’s bounding boxes and raycast or sample points inside that for collision points.
Once two objects are colliding the bounding box intersection is rather easy to calculate with min and max. I’m not super familiar with gdevelop’s syntax but roughly it’s:
X0 = max(objA.bboxLeft, objB.bboxLeft)
Y0 = max(objA.bboxTop, objB.bboxTop)
X1 = min(objA.bboxRight, objB.bboxRight)
Y1 = min(objA.bboxBottom, objB.bboxbottom)
Where x0,y0 is the top left corner and x1,y1 is the bottom right of the intersection.
You could randomly sample points inside that intersection till you find a point to overlap both objects. That would give you a collision point but won’t give the whole collision area. Sample multiple points and average them to get a better approximation of the center the collision area.
For a full accurate collision area, and if both objects have convex collision polygons, you could clip one polygon with the other. Then to get a point from that you could just get the average from the corners of the clipped polygon.
Otherwise most engines use sat, gjk, mpr or sdf algorithms to both find if two objects collide, and the penetration depth and direction. The collision point calculation is a step beyond that to find the edge/point on either object.
However you probably can get a fairly accurate approximation with sampling collisions within the bounding box intersection.
Especially since the GD engine has necessarily determined these coordinates (X and Y) in the event of a collision between 2 objects.
A remark: let’s take the (extreme) case where it is the 2 parallel sides of a parallelepiped (square or rectangle) which touch each other, for us who are humans, the collision seems to be verified for each of the points on the sides of the 2 objects but in fact, the computer detects that there is a collision from the first point of intersection.
Hence my request that the GD developers provide us with the X and Y coordinates of the collision point for each of the 2 colliding objects.
I don’t think, that the collision detection implies the calculation of collision points. That would always need another layer of calculation. It could be added for sure, but it is not something we would want for every collision event, and it would create overhead, if not needed. It is, in fact, quite particular, that a collision returns a single point.
Take the example of a spawner, that creates object_A at random positions. If the creation of object_A collides with object_B, its position gets changed to another random position. The collision would return true, because an area overlaps, not a point. It might be a neat option to have, a seperate condition event for specific cases, but usually you don’t need it and you also cannot return a point, if an area is the actual collision result (while the result remains usually simply true/false, based on the calculus). So it is probably too specific and also quite expensive.