-
-
Notifications
You must be signed in to change notification settings - Fork 49
Add arcVertex() function to create circles arc using vertices. #310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Created by: clankill3r I think something like this could be nice. I used to make arcs by setting a insane strokeWeight, and then draw with a smaller strokeWeight and different radius on top (and using strokeCap square), it can give the same result, but it's a bit hacky I think. I do however think that the rotation parameter should be removed. arcVertex(cx, cy, r1, startAngle, stopAngle, 1);
vertex(...);
arcVertex(cx, cy, r2, stopAngle, startAngle, -1); Then you already kind of decide the rotation, e.g. does Also I think creating an ArrayList is overkill, since the default size is 10 and it's a structure mean for growing. So I recommend to just use Also I think angleSpan = abs(a2 - a1) % TWO_PI; Last but not least, every vertex function in processing allows for a z value as well. And I guess so should arcVertex to keep processing a friendly to use thing. |
Created by: jb4xx Thank you @clankill3r for your interest and thank you for the feedbacks. Regarding your first point, it is important to keep the rotation parameters. Take the following example: In both cases, the vertices are added following the blue arrows and in both cases, the start angle is PI and the stop angle is 0 and you can't draw it reverse and set the start angle to 0 and the end angle to PI because the start vertex is the yellow one. I do agree that the ArrayList is overkill and a fixed size array would definitely work. I think the worst case scenario would be 5 vertices if you draw an almost closed circle: the start vertex, the end vertex and 3 control points in the middle. Regarding the angleSpan, I'm don't think your formula would work since the 2 functions gives different results depending on the rotation. Here's the 2 functions (for a1 = 0), the orange being used for CW rotation and the green one for CCW rotation: But it can indeed be simplified as followed: With this, we can completely get rid of the if statement. Finally for the z value, that's a good idea but it needs way more work. Adding a z value for the center of rotation is easy but orienting the rotation in 3D space is a bit more tricky. |
Created by: clankill3r Ok good point. I think something inspired by the first image would be good for the documentation page. Also for the CW and CCW, I think it would be good that in PConstant the following would be added: int CW = 0;
int CCW = 1; arcVertex(cx, cy, r1, startAngle, stopAngle, CW);
arcVertex(cx, cy, r1, startAngle, stopAngle, CCW); Another thought, this is the only vertex function where end point is not defined by a x and y coordinate. PVector v;
// Draw the shape
beginShape();
vertex(cx + r1 * cos(startAngle), cy + r1 * sin(startAngle));
v = arcVertex(cx, cy, r1, startAngle, stopAngle, 1);
ellipse(v.x, v.y, 20, 20);
vertex(cx + r2 * cos(stopAngle), cy + r2 * sin(stopAngle));
v = arcVertex(cx, cy, r2, stopAngle, startAngle, -1);
ellipse(v.x, v.y, 20, 20);
vertex(cx + r1 * cos(startAngle), cy + r1 * sin(startAngle));
endShape(); About the z coordinate, this one is tough. I can imagine that you just pass the z value threw the parameters, and that that i just the z value being used everywhere. That is better then having no z value at all. But this is also limiting in the possibilities. (It is probably all I ever need). I have been thinking about the most likely use case I would ever have with needing a z value that has a different value for the end point then the z value at the starting point. And I guess for me that would be drawing a spiral.
float startAngle = QUARTER_PI;
float stopAngle = 3 * QUARTER_PI;
float startZ = 0;
float endZ = 15; That gives us an
Now the Now lets say we want to draw 2 types of springs. A) This spring has always the same height, but the amount of revolutions can change. #1 With option 1, drawing A is easy and B is more work. Let's take a closer look at the things that require more work: float corrected_endZ = startZ + angleSpan(startAngle, stopAngle) / TWO_PI * abs(endZ - startZ);
arcVertex(cx, cy, r1, startAngle, stopAngle, 1, startZ, corrected_endZ); float wanted_height = 15;
float t = angleSpan(startAngle, stopAngle);
float corrected_endZ = startZ + (TWO_PI / t) * abs(endZ - startZ); I think it is a bit hard to follow but please put some thought in following what I try to explain here. So it's tough for me to decide what would be best. I think it might be good to implement both for a testing phase. And start making different things using both methods and see which one is most friendly in most of the use cases. |
Created by: jb4xx Hi again, +1 to add PConstant for CW and CCW, that would be more intuitive to use. I also think it might be a good idea to return the end vertex. Regarding the 3rd dimension I'm less convinced for 2 reasons:
The idea behind that function being to approximate arcs (as in part of a circle) using bezier curves, I think it needs to stay just that. So to port it to 3D, the only thing to change is the orientation of the plane on which the arc is drawn meaning that at the end, all points end up on the same plane. Now the issue with that is that there is no easy way to provide the relevant information:
For those reasons I don't think the port to 3D would be a good idea. |
Created by: clankill3r Yeah I have to agree with you that 3D would not be a good idea. Ok then the only thing what comes to mind what remains at this point is arcPoint and arcTangent? |
Created by: jb4xx Do you mean a function |
Created by: scudly Postscript has separate operators "arc" and "arcn" to add CCW and CW arcs to the current path. Cairo, similarly, has cairo_arc() and cairo_arc_negative() functions (see https://www.cairographics.org/manual/cairo-Paths.html#cairo-arc ). But I like your idea of CW and CCW flag constants better. |
Created by: clankill3r
yes, just to have it inline with the rest of the processing functionality: https://processing.org/reference/bezierPoint_.html And about the CW and CCW, yeah since processing has already things like LEFT, RIGHT, TOP, BOTTOM a parameter seems more inline then having 2 functions. (also in certain cases, having a parameter makes things way easier then having 2 functions cause it can avoid the need of requiring if statements). |
Created by: jb4xx In that case I can see 2 options. The easy way. Since it is a close approximation of a circle, it is quite easy to compute points and tangents based on the circle that is being approximated. The less easy way. If we consider the previous method to not be precise enough, then we need to use the bezier points to get the real values. I don't think it will be that much more complicated. Another thing to consider is what would the user expect. The drawing is an approximation but the user wanted to draw a real arc so maybe he is more interested by the values given by taking the circle rather that the one given by the bezier points. And maybe the delta is so tiny that this discussion is not even needed and whatever the method it would be ok... |
Created by: clankill3r I was thinking of the easy way. |
Hi @SushantBansal-tech. Thanks for your interest working on this issue! I know this has been marked as "good first issue" and "help wanted" but I'd actually like to get some clarity on a similar conversation happening over in the p5.js repo before we move forward with this one. |
@SableRaf okay sir |
@SableRaf Can we discussed about the idea how to add arcVertex() in processing just like p5.js have done?? |
@SableRaf Sir here is the Approach to add arcvertex() in processing ,If it is good I can start working on it . There are two Approaches to implement please review it : Proposal for Implementing arcVertex() in Processing JavaObjective 1.Purpose: Allow users to draw arcs using bezierVertex() approximations directly within beginShape() and endShape(). 2.Parameters: float cx, cy: Center coordinates of the arc. Steps for Implementation
Method Description: arcVertex() will calculate intermediate control points using bezier curve approximations of arcs. 2. Modify Key Classes Define the arcVertex() method for core rendering. Extend arcVertex() logic to handle rendering arcs in the Java2D renderer. Add support for rendering arcs through OpenGL. Update the PShape class to manage arcs as part of shapes. 3. Implementation Plan Use a bezier-based approximation for arcs, similar to the SVG elliptical arc method.
Rendering Logic: Use vertex() for the first point of the arc. Ensure arcVertex() works seamlessly within these methods. Example:
|
Here is the second Approach: How to Implement Define global parameters for arc geometry (such as radius, rotation, type, and direction). arcVertex(x, y): Specify the endpoint of the arc. Steps for Implementation
width, height: Dimensions of the ellipse.
2. Implement arcVertex()
x, y: Endpoint of the arc. Backend Logic Add instance variables in PGraphics to store the arc parameters:
2.Calculate Arc Geometry: Use the start point (last vertex in the shape) and the endpoint (x, y) to calculate the arc's geometry.
3.Integrate with beginShape() and endShape(): Ensure arcVertex() works as part of the shape-drawing workflow. Example Sketch:
|
Created by: jb4xx
I feel like processing could use a function that easily generate arc circles to construct PShapes.
My proposal would be to use a bezier approximation of a circle and use the already existing bezierVertex() function to create an arc.
The argument list of the function could be similar to the one use for the arc() function to keep the same logic.
Here is what the function could look like:
And here is a possible use case:
The text was updated successfully, but these errors were encountered: