Okay, so I have two very simple separate Path objects, one containing a straight line I created with lineTo and one containing a curve that I generated with the quadTo function. I need to get the POINT (x, y) where these two objects insect, which they only do once as well as the DISTANCE from one side of the arc of the point where they intersect.
There are lots of posts about figuring out IF they intersect, but I can't find any information on how to figure out WHERE they intersect.
EDIT! I still can't figure this out, I've been trying to fake it by measuring the distance along the yellow line that the black lines were drawn apart from each other and then making a whole new curve. It's sloppy and not working well. See the image!
If I can get to the distance from the end where the black curve intersects the yellow line, I can get a segment of the curve, and the two points on it's end, and it will work great!
Any ideas, anyone? :)
Thanks!
Related
I have a question about Android's "fingerpaint" example: https://github.com/Miserlou/Android-SDK-Samples/blob/master/ApiDemos/src/com/example/android/apis/graphics/FingerPaint.java. There's a detail I can't seem to understand.
On an "ACTION_MOVE" motion event, the view draws a new path segment to the canvas using the Path.quadTo method. This happens on line 104. If I understand correctly, the current position of the Path is (mX, mY), and (x, y) is the location the user has moved the pointer to. So quadTo(mX, mY, (x + mX)/2, (y + mY)/2) should draw a quadratic bezier from (mX, mY), halfway to (x, y), using (mX, mY) as the control point.
I'm not an expert on beziers, but since the control point is collinear with the start and end points, this looks like it should just draw a straight line, meaning that we might as well have just called Path.lineTo instead. Moreover, when I run the app and move the pointer, a line is drawn all the way to the new location, not just halfway as I would have expected from the code. Replacing (x + mX)/2 and (y + mY)/2 with x and y , or replacing quadTo with lineTo, doesn't produce a perceptible difference in behavior.
Can anyone help resolve my confusion?
I've got the exact same question. After playing around a little with parameter values, what I understood is that:
Setting the control point coordinates to be the same as those of the starting point helps drawing a smoother curve.
Moreover, when I run the app and move the pointer, a line is drawn all the way to the new location, not just halfway as I would have expected from the code
What happens is that each time a new path is drawn, the distance between start and end points is calculated in pixels. For every slight move a new path is drawn. So, in the end we have lots of small paths drawn one after the other. You're correct that the path (line, curve) seems to be drawn all the way to the end and not just halfway. However, what actually happens is that it is indeed drawn halfway; the distance between each new path is so small that we don't notice that. Let me explain this with the screenshots below. In both cases, I tried to draw from one side of the screen to the other.
This is how it looks when using the coordinates given in the sample code
And this is how it looks if we use the end point coordinates as the actual end point coordinates in quadTo()
So, when we use the actual end point coordinates, the paths are more accurate in terms of where's the end point (notice how the end point to the right is more close to end of the screen in the 2nd photo?)
On the other side, the distance between start, control and end point plays part in the smoothness of the path. In the second screenshot, I used the halfway point as the control point and this resulted in less smooth paths.
At least that's what I have understood. If anyone has a more accurate explain, please share it.
Could someone explain me how convex path is calculated? I need to draw some cubic and additionally some lines but then path is shown as non convex. However when I leave only lines or just cubic it is then convex. The problem is that I need some non regular shaped background and need Convex path for shadow outline but can't get how I could connect drawing cubic with some lines to make convex path if it is even possible
A path is convex if it has a single contour, and only ever curves in a single direction.
Convex means it keeps bending / rotating in one direction, and one direction only. You really have to make sure that all your angles and curves add up. If your curve connects to a line it has to have the same angle or be "more convex", I hope the following 2 images will clear this up.
The picture below is not convex. That's also likely your problem. The line connects to a curve, but the curve has a different angle than the line and it will change the direction where it connects. See where the line goes down but instead of continuing the downwards-motion it suddenly goes up again. Instead of keeping one direction it will change for a moment where line and curve meet.
The above Image is exaggerated for clarity, but even small errors in the connection between the line and curve will trigger an error.
The next line connects to a curve with a steeper angle. This is convex and won't be a problem. See how the whole contour keeps a single motion in one direction, depending in which direction you follow it it keeps turning left/right.
I answered because I was facing a similar issue recently and I feel your pain. I recommend pen and paper to double and triple check the math and to use a small epsilon value to account for rounding errors etc... You really have to nail the math, because if your line and curve connection is just off by very little it will throw that exception.
Sorry for my bad paint skills
How do I draw a path along some defined points in a way so that the path is nicely curved and not necessary exactly touching the defined points, except the end points where the line must be ending at the exact points? I have tried with quadTo, but that gives me jagged connections between the quadTo end/start in some situations.
To illustrate what I want I have attached this example image:
Thank you
Søren
I am drawing a path when a user drags his finger across screen. If, however, he does this too fast, I get too few points in path. Is there some way, I can increase the number of points in path after the user has drawn it?
I need this because I am comparing each point of path1 to all points on path2 to see when these two paths are intersecting.
If the user has already completed drawing a path, the best you can do is work with the points you have and guess at what goes between them. Two popular methods of guessing are to insert line segments between points, which gives a very jagged look, or you can use spline interpolation, which gives a very smooth look, but involves a more complicated calculation.
More info on spline interpolation: http://en.wikipedia.org/wiki/Spline_interpolation
Whether you use line segments or splines, you'll need to mathematically find the intersection by using the equations for the path1 segment/spline and the path2 segment/spline. You'll have two equations, two variables and so you should be able to solve the system to find the values for x and y that satisfy both equations, making that point the intersection.
http://en.wikipedia.org/wiki/Line-line_intersection
I'm a new Android developer that's developing a simple twist on the Tron game with GPS movement, but I'm having trouble implementing player's intersecting.
Right now, my player's trails are Paths that I move to co-ordinates and draw the co-ordinate difference as a line on the canvas.
The path class offers no such intersection method that I can find, so I resorted to using Regions which I've tested an intersection to work with 2 regular Rectangles, but I can't make a Region using Region.setPath for some reason. From my understanding, the path needs to be closed to form an area for it to create a Region, which isn't exactly what I need.
Is there a way to create a region off a path, and not the area the path creates? ie: If the path were a straight line of 10px thick, how do I make a region that is a line of 10px thick?
Here's a short code sample I'm doing:
Path p1path = new Path();
p1path.moveTo(startPos,startPos);
p1path.lineTo(newPos,newPos);
p1path.moveTo(newPos, newPos);
Region p1region = new Region();
p1region.setPath(p1path, new Region(0,0,480,800); // this is where the region isn't setting as I thought it would...
// do same for p2
if(p1.quickReject(p2)) // checks for intersection
Thanks :)
So I've solved this quite some time ago, but to help those who eventually stumble onto this and want some similar functionality:
This post is quite some time ago - so let me remember what happened.
Creating a Region around a path actually did work but for a very limited set of Paths. What I mean by "Creating a region around a Path" is that for a Path that goes from x1,y1 to x2,y2 create a rectangular Region that covers (for example) x1-50,y1-50 to x2+50,y2+50 where 50 is the pixel weight stroke of the Path.
If you can visualise it, it basically creates a rectangular region that covers the Path and it's 50px stroke so you can "fake" Path intersection using Regions. Wherever a Path is, a Region is and so when 2 Paths "intersect", you can check for Region intersection (which you can do but I've forgotten the method names).
This however proved to work only for a few Paths. Though I'd like to think my Math proficiency is adequate, I could not get it so that for whichever direction the Path went the Region would work. Different angles, different directions etc. caused the Region not properly drawing under the Path. My above example of using the 50 stroke width would only work for going a particular direction.
The solution my parter and I stumbled onto was creating a 2D integer array that mapped onto the screen. Wherever a Path went into a certain direction, we would fill every array cell the Path mapped onto with a specific value (1). We would do the same for the other Path, but with a different value (2). Each move you make you would check the 2D array against the Path co-ordinate to see if it has been occupied or not. There was an important mathematical formula that would extrapolate which cells were visited when you go from x1,y2 to x2,y2 that proved very helpful - I believe it was called something along Brasenheim's formula, or something.
It's not the most elegant solution, but it ended up faking Path intersection well. If anyone is interested in a better explanation, you can message me.
Good luck!