I'm having an issue with drawing Arcs with AggPas, and I can't quite put my finger on it... What's happening is that small arc segments are just not being drawn... they are not super tiny segments, they should end up being at least 100 pixels long, but they have a pretty big radius, but the radius itself is not the issue because I can draw larger arc segments with even larger radii and they have no issues. It seems to be some combination of parameters. Basically I am scaling my drawing with a multiplier and when I cross a certain point, these arcs disappear from the drawing. But I notice this only happens with the Arc() function, not ArcTo() but I'm using both at the same time.. I'm using MoveTo(), LineTo, and ArcTo() to draw a highlighted path, and at the same time Line() and Arc() to draw a centerline so what happens is that as I zoom out, decreasing the scale, the highlighted path is there, but the centerline disappears for these arc segments. I've reduced this down to trying to just draw the arc in question and I still have the same issue, so I know it doesn't have anything to do with any other functions.

It would not be easy to just use ArcTo() for the centerline as well, because it would break the path I am building, and if I try to draw the path so far, then use ArcTo for the centerline, then start another path, I end up with a quite noticeable overlap in my highlighting where the overlap is highlighted twice... so it would be nice if I could figure out what's going on with ArcTo()

Here is some test data for one of the arcs that just will not draw with AggPas: Here is how I am implementing the arc command:

agg^.arc(Drawinfo.gi*pixelscale+Draw_X_offset,Drawinfo.gj*pixelscale+Draw_Y_offset,Drawinfo.r*pixelscale,Drawinfo.r*pixelscale,Drawinfo.ea,Drawinfo.sa);
If Pixelscale drops below a certain point, the arc will not draw.   I ran several tests, then tried it with just hard coded values as follows:
agg^.arc(-600470.258096880350,168254.083748858280,624074.001867781300,624074.001867781300,6.011216001395,6.010880670454);    //Draws Arc
agg^.arc(-540359.532287192330,151479.575373972450,561666.601681003190,561666.601681003190,6.011216001395,6.010880670454);    //Draws Arc
agg^.arc(-486259.879058473110,136382.517836575210,505499.941512902880,505499.941512902880,6.011216001395,6.010880670454);    //Does Not Draw Arc
Any Pixel scales smaller than this result in no arc being drawn.

Now I can draw the same arc with the following code:

total_arc_angle:=Drawinfo.ea-Drawinfo.sa;
If Total_Arc_angle<0 then
   Total_Arc_Angle:=Total_Arc_Angle+(2*Pi);
agg^.resetpath;
agg^.moveto(Drawinfo.px*pixelscale+Draw_X_offset,Drawinfo.py*pixelscale+Draw_Y_offset);
If Total_arc_angle > Pi then
    agg^.arcto(Drawinfo.r*pixelscale,Drawinfo.r*pixelscale,Total_Arc_Angle,True,True,Drawinfo.gx*pixelscale+Draw_X_offset,Drawinfo.gy*pixelscale+Draw_Y_offset)
Else
    agg^.arcto(Drawinfo.r*pixelscale,Drawinfo.r*pixelscale,Total_Arc_Angle,False,True,Drawinfo.gx*pixelscale+Draw_X_offset,Drawinfo.gy*pixelscale+Draw_Y_offset);
agg^.drawPath(StrokeOnly);
With this I also performed the same 3 tests as above with the following:
agg^.moveto(609.165546484752,409.256438718313);
agg^.arcto(624074.001867781300,624074.001867781300,0.000335330941,False,True,665.125058651162,609.784932227478);   // Draws Arc
agg^.moveto(611.948991836276,419.230794846482);
agg^.arcto(561666.601681003190,561666.601681003190,0.000335330941,False,True,662.312552786046,599.706439004730);   //Draws Arc
agg^.moveto(614.454092652649,428.207715361834);
agg^.arcto(505499.941512902880,505499.941512902880,0.000335330941,False,True,659.781297507441,590.635795104257);   //Draws Arc

With MoveTo and ArcTo, I can draw the arc any size, even reducing the pixel scale down so far that the entire drawing is 1 pixel

Does anyone know what's going on with this? It seems like the kind of thing where some internal calculation does not have enough precision, or something is overflowing.. but it's strange that ArcTo always works to draw the same exact arc.

James

James Richters wrote

agg^.arc(Drawinfo.gi*pixelscale+Draw_X_offset,Drawinfo.gj*pixelscale+Draw_Y_offset,Drawinfo.r*pixelscale,Drawinfo.r*pixelscale,Drawinfo.ea,Drawinfo.sa); If Pixelscale drops below a certain point, the arc will not draw. I ran several tests, then tried it with just hard coded values as follows: agg^.arc(-600470.258096880350,168254.083748858280,624074.001867781300,624074.001867781300,6.011216001395,6.010880670454);

From the above, it seems you implemented your own Arc() procedure. Is that correct?

From the agg_2D.pas unit (the non GUI Toolkit dependent version), the Arc() implementation is as follows:

procedure Agg2D.arc(cx ,cy ,rx ,ry ,start ,sweep : double );
var
  ar: {bezier_}agg_arc.arc;
begin
   m_path.remove_all;
   ar.Construct(cx ,cy ,rx ,ry ,start ,sweep ,false );
   m_path.add_path(@ar ,0 ,false );
   drawPath(StrokeOnly );
end;

So I couldn't really test with your ARC example, but I could with your ArcTo() example. The latter indeed works. I also made each of the 3 arc segments in a different color - Red, Green and Blue to see exactly which is which.

Could you post the code for your Arc() implementation - seeing that your parameter list is totally different to mine.

ps:
Unfortunately there are a couple of AggPas implementations floating around. The original version in not being maintained at all and should not be used any more, as it contains a few bugs and lacks 64-bit CPU support. My AggPas copy which lives in the fpGUI Toolkit code repository is well used and maintained. Could you try using my version of AggPas and see how that goes for you.

If there is a bug in ARC, I would like to resolve it.

You can get a copy of my AggPas from the fpGUI repository as shown here:

https://github.com/graemeg/fpGUI/tree/develop/src/corelib/render/software

Regards,
Graeme

From the above, it seems you implemented your own Arc() procedure. Is that correct?

No, it's the Agg2D Arc Function:
http://www.crossgl.com/aggpas/documentation/#Arc

Could you try using my version of AggPas and see how that goes for you.

Yes I am using your version already

If there is a bug in ARC, I would like to resolve it.

I can supply a complete sample program if it would help. I would like to resolve this as well, I'm very happy with AggPas for my application.

I think maybe email wrapping distorted my arc command so they didn't look right Here is the command I am sending broken down with comments:

agg^.arc(
(Drawinfo.gi*pixelscale+Draw_X_offset), {Cx}
(Drawinfo.gj*pixelscale+Draw_Y_offset), {Cy}
(Drawinfo.r*pixelscale), {Rx}
(Drawinfo.r*pixelscale), (Ry)
(Drawinfo.ea), {Start Angle}
(Drawinfo.sa) {Sweep Angle}
);

Test Version with hard coded numbers:

agg^.arc(
-600470.258096880350, {Cx}
168254.083748858280, {Cy}
624074.001867781300, {Rx}
624074.001867781300, {Ry}
6.011216001395, {Start}
6.010880670454 {Sweep}
);

Thanks for the help with this

James

Also I just do all my math in radians so I don’t' need to convert deg2rad() as in the examples. There is little point in converting everything to degrees just to convert it back to radians again.

James

I can supply a complete sample program if it would help

See Sample Program Attached

James

James Richters wrote

> I can supply a complete sample program if it would help See Sample Program Attached

Thank you, that should really help a lot is solving the issue. I'll take a look later tonight or tomorrow morning.

Regards,
Graeme

Ah indeed. Now it makes more sense. As I mentioned, I'll take a look later tonight.

Regards,
Graeme

Hi James,

Please get a fpGUI repository update so you have the latest AggPas from there. I found a bug in Agg_2D's Arc() implementation, and it didn't match the documentation's sample output. Yet the Agg2D's Arc() worked correctly.

Here is the commit log.

===============================
commit 3dfce61fd9a3abba7d8a3825b8fa677bb75907e0 (HEAD -> develop, sourceforge/develop, github/develop)
Author: Graeme Geldenhuys
Date: Wed Aug 30 19:43:19 2017 +0100

AggPas: agg_2D's Arc() implementation had parameters in the wrong order.

If you compared the Agg2D vs the Agg_2D Arc() behaviour you would see they
give different results. After this commit they generate the same [correct] output.

src/corelib/render/software/agg_2D.pas | 2 +-
src/corelib/render/software/agg_arc.pas | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
===============================

Further I looked into the implementation details of Arc() and ArcTo(). They use totally different arc implementations. ArcTo() is based on a bezier arc, whereas Arc() doesn't.

Regards,
Graeme

Please get a fpGUI repository update so you have the latest AggPas from there. I found a bug in Agg_2D's Arc() implementation, and it didn't match the documentation's sample output. Yet the Agg2D's Arc() worked correctly.

I have updated from your fpGUI repository just now and it is including commit: AggPas: agg_2D's Arc() implementation had parameters in the wrong order.

With that change I needed to change what I called the start and sweep (end) angles.. but it's still leaving out the 3rd arc. I have attached the modified sample program for your evaluation.

I realize Arcto() and Arc() work differently, but the Arc I am trying to display is a valid Arc segment with either method.

Thank you for your help with this

James