Actually pretty simple.
Best
Boolean function for intersection between circular segment and circle
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Re: Boolean function for intersection between circular segment and circle
- Attachments
-
- circleInSector.love
- demo
- (696 Bytes) Downloaded 265 times
- BrotSagtMist
- Party member
- Posts: 659
- Joined: Fri Aug 06, 2021 10:30 pm
Re: Boolean function for intersection between circular segment and circle
Is this a contest now?
Controls: Mousewheel+lctrl
Quite interesting results we have here.
Controls: Mousewheel+lctrl
Code: Select all
X,Y=love.graphics.getDimensions()
B={x=X/2,y=Y/2,r=X/100}
A={x=X/2,y=Y/2,r=X/5,s1=1,s2=2}
function Points()
A.x1=math.cos(A.s1)*A.r+A.x
A.y1=math.sin(A.s1)*A.r+A.y
A.x2=math.cos(A.s2)*A.r+A.x
A.y2=math.sin(A.s2)*A.r+A.y
A.m1=(A.y-A.y1)/(A.x-A.x1)
A.m2=(A.y-A.y2)/(A.x-A.x2)
A.b1=(A.y-A.m1*A.x)
A.b2=(A.y-A.m2*A.x)
end
Points()
A.f1=function(x) return A.m1*x+A.b1 end
A.f2=function(x) return A.m2*x+A.b2 end
function love.draw()
love.graphics.circle("fill",B.x,B.y,B.r)
--distance, upper line, lower line, == is for inverting which side of the line we are on.
if (((B.x-A.x)^2+(B.y-A.y)^2)<(A.r)^2) and (A.f1(B.x)>B.y) == (A.x>A.x1) and (A.f2(B.x)<B.y) == (A.x>A.x2) then
love.graphics.arc("fill",A.x,A.y,A.r,A.s1,A.s2)
end
love.graphics.circle("fill",A.x2,A.y2,B.r)
love.graphics.circle("fill",A.x1,A.y1,B.r)
end
function love.mousemoved(x,y)
A.x=x
A.y=y
Points()
end
function love.wheelmoved(x,y)
A.s1=A.s1+y/10
if not love.keyboard.isDown("lctrl") then A.s2=A.s2+y/10 end
Points()
end
- Attachments
-
- main.love
- (617 Bytes) Downloaded 219 times
obey
Re: Boolean function for intersection between circular segment and circle
Neither Ref's nor BrotSagtMist's approaches are correct.
First, the OP said "if a segment and another circle intersect". To me that means that the intersection is not null, i.e. the circle overlaps the sector. Ref has interpreted that the circle should be entirely contained in the sector, and BrotSagtMist has interpreted that the centre of the circle should be contained in the sector.
Second, both approaches fail. Ref's fails if the sector points right, and BrotSagtMist's fails if the total sector angle is > 180°.
Third, the OP asked for a function with 8 specific parameters.
First, the OP said "if a segment and another circle intersect". To me that means that the intersection is not null, i.e. the circle overlaps the sector. Ref has interpreted that the circle should be entirely contained in the sector, and BrotSagtMist has interpreted that the centre of the circle should be contained in the sector.
Second, both approaches fail. Ref's fails if the sector points right, and BrotSagtMist's fails if the total sector angle is > 180°.
Third, the OP asked for a function with 8 specific parameters.
Last edited by pgimeno on Sun Aug 08, 2021 6:10 pm, edited 3 times in total.
Re: Boolean function for intersection between circular segment and circle
Ouch!
Officially stomped on!
Forgot about zero angle crossing.
Revised demo attached.
No contest. Just reviewing trig. After all, who can compete with pgimeno
Thanks pgimeno for help.
Officially stomped on!
Forgot about zero angle crossing.
Revised demo attached.
No contest. Just reviewing trig. After all, who can compete with pgimeno
Thanks pgimeno for help.
- Attachments
-
- sectorContact Circle.love
- revised demo
- (934 Bytes) Downloaded 230 times
Re: Boolean function for intersection between circular segment and circle
So why does my approach look so complicated? The limit case of the intersection of a circular sector with a circle is when the circle is in contact with the sector. By imagining a ball rolling around the sector, we can see what shape does it have:
The sector is the half-transparent white area in the centre. The outer side of the ball describes a trajectory given by the yellow line, and its centre describes a trajectory given by the dashed line; the area delimited by the dashed line is called the Minkowski sum, a concept very familiar in the field of collisions. If the small curved segments are not taken into account (if the ball's centre is inside the blue areas), you may report a collision when there is none. And detecting and handling those corner cases is where most of the difficulty lies.
There's also the difficulty that when the angle is > 180°, and only then, it's not enough to check if the centre is at the correct side of both lines at the same time; the test must become whether the centre is at the correct side of either line. That's the problem in BrotSagtMist's approach. In retrospect, checking the angle directly wasn't the best idea: I could have used a cross product; the sign of the Z would have told me if the angle was >180° or not.
The problem with Ref's approach was that checking angle ranges is trickier than it seems at first sight and it's easy to make a mistake. I haven't checked his new code yet.
Edit: I actually made a mistake myself, but it's going to be very difficult to spot because the difference is minimal. It will be more noticeable if the radius of the ball and the radius of the sector are similar.
The sector is the half-transparent white area in the centre. The outer side of the ball describes a trajectory given by the yellow line, and its centre describes a trajectory given by the dashed line; the area delimited by the dashed line is called the Minkowski sum, a concept very familiar in the field of collisions. If the small curved segments are not taken into account (if the ball's centre is inside the blue areas), you may report a collision when there is none. And detecting and handling those corner cases is where most of the difficulty lies.
There's also the difficulty that when the angle is > 180°, and only then, it's not enough to check if the centre is at the correct side of both lines at the same time; the test must become whether the centre is at the correct side of either line. That's the problem in BrotSagtMist's approach. In retrospect, checking the angle directly wasn't the best idea: I could have used a cross product; the sign of the Z would have told me if the angle was >180° or not.
The problem with Ref's approach was that checking angle ranges is trickier than it seems at first sight and it's easy to make a mistake. I haven't checked his new code yet.
Edit: I actually made a mistake myself, but it's going to be very difficult to spot because the difference is minimal. It will be more noticeable if the radius of the ball and the radius of the sector are similar.
- BrotSagtMist
- Party member
- Posts: 659
- Joined: Fri Aug 06, 2021 10:30 pm
Re: Boolean function for intersection between circular segment and circle
Nice speech but meanwhile OPs head exploded.
Thing is, your interpretation of the problem does not seem to be practical in regards to making a game.
Like, would anyone notice that blue area in a fast moving shooter?
Of course i have no idea what op actually wanted, but if we assume the sector is the target area of a gun then having it reacting on _touch_ would feel awkward in a game. And neither would it matter to consider angles greater than half a circle.
Thing is, your interpretation of the problem does not seem to be practical in regards to making a game.
Like, would anyone notice that blue area in a fast moving shooter?
Of course i have no idea what op actually wanted, but if we assume the sector is the target area of a gun then having it reacting on _touch_ would feel awkward in a game. And neither would it matter to consider angles greater than half a circle.
obey
Re: Boolean function for intersection between circular segment and circle
Such is life.
Always nice to create beautiful solutions to non-problems.
Had to add a check to see if the center of the arc was inside the circle.
Always nice to create beautiful solutions to non-problems.
Had to add a check to see if the center of the arc was inside the circle.
Re: Boolean function for intersection between circular segment and circle
I assumed it is a watch area for detecting someone; I'm thinking something like a flash-light or a camera. Like, the arc represents the field of view of something and when you're detected, you're in trouble. In that case, more than half a circle is a possibility. I would be upset if I were the player and I was detected while being directly behind the watcher. And if the arc is visible, I would be upset if I was detected when the arc is clearly at a distance from me.BrotSagtMist wrote: ↑Sun Aug 08, 2021 10:34 pm Nice speech but meanwhile OPs head exploded.
Thing is, your interpretation of the problem does not seem to be practical in regards to making a game.
Like, would anyone notice that blue area in a fast moving shooter?
Of course i have no idea what op actually wanted, but if we assume the sector is the target area of a gun then having it reacting on _touch_ would feel awkward in a game. And neither would it matter to consider angles greater than half a circle.
Edit: Something along the lines of this: https://love2d.org/forums/viewtopic.php?f=14&t=79261
As for reacting on touch, that's what I interpret from the OP's wording as I said.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot], Google [Bot] and 12 guests