2D Drawing ---need help??

[ali_5680]

hey...
need help in 2D drawing ...I want to add drawing ablity for elliptical curves, arcs and ellipses...most of the tutorials i have seen just draw static curves..

I want the drawings to be based on points specified by the user but I having a little trouble in drawing circular arcs using three points(like in AutoCAD)...

any help will be appreciated
thanks

[JVene]

A collection of solutions are to be found at:

http://www.topcoder.com/tc?module=Static&d1=tutorials&d2=geometry2#circle

Basically, if you know the points are not colinear, the perpendicular drawn through the center of each chord on either side of the middle of the 3 points will intersect at the center of the circle you're looking for.

[ali_5680]

Hey,
Thanks for suggesting a great site do you know any good tutorials on elliptical arcs?
thanks

[JVene]

None come to mind, but I usually resort to Bezier curves.

[ali_5680]

Hey Jvene,

I am having trouble drawing arcs (with 3 point) using the 3-point circle algo you suggested ...I cannot figure out how to determine the angle from which the arc will be drawn as in circle it is easy you have three points calculate center/radius and draw from 0 to 360

thanks

[JVene]

Sorry, must be some static on the line :)

Can't quite make out what you mean.

Drawing a circular arc?

The arc is on a circle that includes 3 given points?

The angles you want are those involving the three points, as in, perhaps, the arc should be drawn from one point (left most perhaps), through the next and end at the third?

Something else I didn't quite divine?

[ali_5680]

Hey,
thanks for the reply actually I want to draw a rubberband(mouse based) circular arc using three points(like in autoCad)...I tried to use 3-point circle algorithm from topcoder site you suggested but cannot figure out the angles...

I hope I am clear this time..my last post reflects confusion in my head

[JVene]

I've used AutoCAD, but it has been a while, so I'll tap out a stream of thought on the subject from an old memory.

The first point is clicked, and as the mouse moves there's hardly any information upon which to base a curve, so we must wait for the second point.

When the second point is clicked, and the mouse subsequently moves, the current position of the mouse, at any one moment as it is relocated, provides a temporary third point upon which to base an assumption, so we could draw a 'rubber band' style arc, following the motion of the mouse prior to the third point's placement.

This suggests that the arc's description requires that we keep in mind the order in which the user supplied the 3 points. Whether or not we're still animating the rubber band of the arc, or the user has selected that final third point, hardly matters with respect to the algorithm we use to define that arc. The only difference is noting that the third point is temporary or not, and that's a UI issue, not an algorithmic issue.

So, given 3 points, and an order in which they're 'dropped', we start with the circle itself. From the circle algorithm we have a center point, a radius, and we can assume, given the caveat of inexactness of floats and doubles, that the 3 points are on the circle. The first of the 3 points in the series will provide us an angle relative to the function used to draw an arc. I'm not sure how you want to draw the arcs, bezier approximations, the GDI Arc command - that's another issue.

Assuming you need the angles (GDI Arc command doesn't need it), there is a minor complication due to the fact that coordinates on the display have a direction for the Y axis that's reversed from common math practices, and this circle in which the arc resides will be in positive coordinates, but these are matters solved by either a simple vector of the center, or a reverse of the Y coordinate from standard math - as in, height - Y.

Thinking in terms of 'standard' graphs, where increasing, positive Y moves upwards, may help a little, because it aligns with any math references you're using that aren't intended specifically for Windows coding. It's your option.

Now you need to think about what angles you want? You have the angle formed by two lines from the center to each of the arc's endpoints, but that's only informational. It doesn't describe where the arc begins, but does describe how long the arc is (given trig).

If what you want is the angle OF the line to the starting point, and then the angle OF the line to the ending point, those two angles are relative to some standardized polar coordinate. That means you must choose where 'zero' degrees is defined on a circle. You may elect, for example, that 'noon' is zero, or, somewhat typical also, 3 o'clock. Each of the two angles of interest are, therefore, the angle between a line from the center to one of these arc points, and the line drawn from the center to 'zero' degrees. These are found from trig, and you'll want to vector the circle (and the arc points) such that the circle's center is at the origin.

Looking at the GDI Arc command, what's required is a bounding rectangle and two points. The bounding rectangle is defined by using the center of the circle and the radius. You create the leftmost point by center_x - radius, and the rightmost point by center_x + radius. Similarly, you create the topmost point by center_y - radius (noting the direction of a Windows coordinate system), and the bottom most point by center_y + radius.

Then, all you need to complete the call to arc are the first and third points dropped by the user.

A couple of other issues came to mind.

I don't recall if the circle algorithm I linked includes a test for 3 co-linear points, but that's going to affect UI such that you'll provide some 'feedback' that the arc isn't an arc.

Even if the 3 points aren't co-linear, they can describe an arc on a circle of such dimensions that accuracy is difficult. Your points are given from UI as integers, but your calculations ought to be in doubles, I would think. Even then, you'll want to consider double checking, if it's important, that the arc you've created from all this actually 'settles' upon the 3 points. The middle of the 3 might be expendable, especially when the data ends up in the extremes.

Also, if you're zooming and panning, as AutoCAD does, you have to contend with a 'display pipeline' or, the reverse of it, a UI pipeline. That is, to take into account the current zoom and pan when a mouse click declares a point, and all of that within the caveats of other potential UI notions like 'snapping' points, etc, wrapped up in the fact that your arc is in some 'world coordinate' system - at which point the Arc command is only useful from a GDI/drawing standpoint. Internally, your description of the arc (that is, the data your going to store) would be 3 points, a center and radius, or something logically related to the concept of the arc like that.

All of this begs the question, what's your drawing surface? Is this vector information it's own world coordinate system? Are you measuring in the metric system? Is the surface a bitmap image?

[ali_5680]

sorry I should have mentioned that I am using C# and openGL.
thanks for the detailed reply

[JVene]

I must remind myself that not everyone uses C++ :D

[ali_5680]

Well in my case the problem is lack of experince in graphics programming and secondly I am trying to follow fast interactive-drawing functionality provided by autoCAD..anyways I will see what can be done about arc drawing..
another question for you :)
how to draw polygons(rubberband) by inscribing them in circle..i have done something about the quads but others are bothering me..
any suggestions
thanks

[JVene]

I'm guessing, and a lot depends on the implementation of OpenGL and the graphics card here, but AutoCAD's performance may be hard to beat or even match with OpenGL. On such a primitive the difference might be negligible or even recognizable.

I'm puzzling over your last concept a little. A polygon of more than 3 points would either have to be constructed to match the constraints of a circle (forcing the points to lie on the circle), or you'd have to choose 3 points such that the circle contains all of the others. There are interesting algorithms for that; they're slow, but you can probably get that fast enough to satisfy.

However, if what you're making is something like the N-gon of 3DS Max (I don't recall, but it's likely AutoCAD has something similar), your task is fairly simple.

An N-gon of this notion is simply a set of N points defined as polar coordinates (or, simply, points generated around a center point according to a radius using simple trig rotation), where the angle between each of the N points is 360/N degrees. This naturally makes equilateral triangles, squares, and similarly, N-gons with equal sides.

[ali_5680]

Hey,
the approach you suugested works fine, thanks. I have also added the rotation of the polygon with the mouse, calculating angle at the point where the mosue pointer lies on the circle and drawing the polygon from that angle. but the problem is that polygon does not rotate fully in a circle. it only rotates half

any suggestions
thanks

[JVene]

Good to hear things are working out.

As to rotation, you may find that the range of the angle argument is in radians from -PI to +PI - experiment a little on the range to supply (though I think most of the functions should 'wrap').