[question] > Circle passing through 3 points.

[.: NICKY G. :.]

15 minutes ago, >|< said:

Look at the status bar for the modifier to "create along line". Since it is ctrl on a Mac, it'll probably be Serif's infamous RMB+LMB combination on Windows.

I tried and I succeeded, but the combination of the RMB + LMB keys in windows is hellish !!!
Very uncomfortable like what ... there is no other solution?

[lepr]

.

[.: NICKY G. :.]

4 minutes ago, >|< said:

Buy a Mac.

 

Those of Affinity could change the RMB / LMB button with ALT on windows!

[R C-R]

1 hour ago, .: NICKY G. :. said:

Those of Affinity could change the RMB / LMB button with ALT on windows!

On Macs, the Alt key is already assigned as a keyboard shortcut to ignoring snapping. I'm not sure about Windows but I think it is the same.

[v_kyr]

Well it's way too cumbersome to manually draw circles this way in AD, with a few lines of programming code one can let an algorithm do the math and drawing work here instead ...

 

Just a little programming test for drawing/generating such 3 point based circles. - Well, if AD would have a well documented programmers API, one could build and add one or two such things for that. 

[.: NICKY G. :.]

10 minutes ago, v_kyr said:

Well it's way too cumbersome to manually draw circles this way in AD, with a few lines of programming code one can let an algorithm do the math and drawing work here instead ...

 

 

Just a little programming test for drawing/generating such 3 point based circles. - Well, if AD would have a well documented programmers API, one could build and add one or two such things for that. 

WOW   WOW   WOW    WOW 

[.: NICKY G. :.]

47 minutes ago, R C-R said:

On Macs, the Alt key is already assigned as a keyboard shortcut to ignoring snapping. I'm not sure about Windows but I think it is the same.

yes also in windows the ALT key works this way (I didn't know, I have been using AD for a few days)

 

however AD still has some things missing, but it is already clearly better than AI.
Faster, more precise.

Hopefully those of the Affinity will give you a wake up call that surpassing Adobe AI is almost done.

I have always hated AI since I left freehand.
Freehand was magnificent.

[v_kyr]

BTW another 3 point based circle curvature play can be easily and interactively done/demonstrated with the Menger curvature.

Quote

In mathematics, the Menger curvature of a triple of points in n-dimensional Euclidean space Rn is the reciprocal of the radius of the circle that passes through the three points. It is named after the Austrian-American mathematician Karl Menger.

[lepr]

.

[.: NICKY G. :.]

4 hours ago, v_kyr said:

BTW another 3 point based circle curvature play can be easily and interactively done/demonstrated with the Menger curvature.

 

Forgive me if I ask you, but how can you do these things ???
This is exactly what I would like ...
Similarly, the plug-in of the astute graphics subscribe ...

How can we show these things to the AD developers?
I believe that they should think of some design function a little more particular and precise. I'm not saying it should work like a CAD, but being a vector drawing software, a lot of drawing things should be able to do ...
 

 

 

 

[.: NICKY G. :.]

11 hours ago, >|< said:

Look at the status bar for the modifier to "create along line". Since it is ctrl on a Mac, it'll probably be Serif's infamous RMB+LMB combination on Windows.

can't you change this RMB + LMB command in the keyboard command settings ???

[R C-R]

8 minutes ago, .: NICKY G. :. said:

How can we show these things to the AD developers?

I believe that they should think of some design function a little more particular and precise.

I mentioned earlier that they have already said they would like to "do more" with circles, but that almost certainly requires replacing the Affinity bezier approximation of circular (& more generally elliptical) shapes with something that can be calculated more precisely. I think that in turn would require increasing the internal precision of the app's calculations, which I believe they have said is something on the order of 8 decimal points.

From what I can tell from online calculators like this one, that would require increasing the internal precision substantially, but I don't have a clue about how much would be enough for fitting circles to 3 points & such.

To get some idea about that, I made the assumption that whatever I paste into the Transform panel will be calculated to the equivalent of ~8 decimal points regardless of the display precision preference setting, & used the center point & radius values below from the online calculator to create the "Approx. circle" ellipse in the attached 3 point Circle fit.afdesign file.

Assuming my methodology is sound (& my iMac & app are working correctly), at first it looks like a good fit. However, when I start to zoom in on a point in Outline View mode, it becomes increasingly obvious that somewhat greater internal precision would be required for a fit that would be visually accurate all the way down to the extreme zoom levels the Affinity apps are capable of.

At 6000% the misfit is already clearly visible:

 
At really extreme zoom levels like 2 million % the point & where the circle should touch it can't even be displayed on the screen at the same time.

So I think this boils down to three things:

• How much more precision is enough to satisfy most users' needs?
• Is there a better way to provide it for these shapes that does not require increasing the internal precision for all calculations?
• Whatever the method, would it reduce the responsiveness of the Affinity apps to unacceptable levels?

Any thoughts on that?

[lepr]

.

[R C-R]

57 minutes ago, >|< said:

The problem is not one of precision; the four joined cubic bezier curves, which Affinity uses for approximating circles (and ellipses in general), simply cannot describe a true circle.

But in practical terms, what can? That's what my next to last bullet point was about. One way or another, any practical implementation should at least render correctly for all zoom levels the app can support, be compatible with the native Affinity file format, not adversely affect performance, & ideally export to supported vector file formats without loss of accuracy.

[v_kyr]

5 hours ago, .: NICKY G. :. said:

Forgive me if I ask you, but how can you do these things ???
This is exactly what I would like ...
 

It's nothing rocket science, just a little bit of reusing given graphics programming routines of a prog language API and then to implement with that some well known algorithms and principles in mathematics/geometrie. 

Quote

Similarly, the plug-in of the astute graphics subscribe ...

How can we show these things to the AD developers?

Looks like that Astute Graphics company specialized itself on making and offering Plug-ins of add-on or missing vector drawing things for Adobe Illustrator, similar as a lot of others do for Photoshop instead. Adobe has and offers for long time programming APIs, scripting capabilities etc. for their major tools, something the Affinity line doesn't have or offer yet.

The AD developers? Well I believe most of the Affinity devs are probably already from the graphics domain and thus they should already know all these things very well. But in commercial development a dev has to follow more the route the management tells and dictates to implement, so to say the overall more important urgent things. Another point here is bug fixing, as far as the underlayed reused infrastructure has certain influencing bugs, it does make more sense to fix those first, before diving into implementing new features. Otherwise you run the risk that errors/bugs spread more and more over with every new feature.

[.: NICKY G. :.]

1 hour ago, v_kyr said:

It's nothing rocket science, just a little bit of reusing given graphics programming routines of a prog language API and then to implement with that some well known algorithms and principles in mathematics/geometrie. 

Looks like that Astute Graphics company specialized itself on making and offering Plug-ins of add-on or missing vector drawing things for Adobe Illustrator, similar as a lot of others do for Photoshop instead. Adobe has and offers for long time programming APIs, scripting capabilities etc. for their major tools, something the Affinity line doesn't have or offer yet.

The AD developers? Well I believe most of the Affinity devs are probably already from the graphics domain and thus they should already know all these things very well. But in commercial development a dev has to follow more the route the management tells and dictates to implement, so to say the overall more important urgent things. Another point here is bug fixing, as far as the underlayed reused infrastructure has certain influencing bugs, it does make more sense to fix those first, before diving into implementing new features. Otherwise you run the risk that errors/bugs spread more and more over with every new feature.

I hope they hurry up, I can't wait to leave Illustrator for good and, for my humble opinion, it has always sucked!

[v_kyr]

In the context of AD, I would not bet on that they are fast in implementing such features, because it is very questionable at all what, when and how will ever be added to the software.

Can't comment so much on Illustrator since I didn't used that for years (only sporadically), in the past I used more Virtuoso (FreeHand) and CorelDraw for vector related things. But at least AI looks to be nowadays the industry mainstream, seems to be feature rich and function complete in contrast to other competitors vector software. Though it's high pricing and a cloud based software rent (leasing) model are of course another theme not everybody feels fine with, so everyone has to decide for themselves here. - All in all it also depends a lot on whether a software is used professionally, so to say for making a living out of the work with that or not.

[.: NICKY G. :.]

4 minutes ago, v_kyr said:

Nel contesto di AD, non scommetterei sul fatto che sono veloci nell'implementare tali funzionalità, perché è molto discutibile su cosa, quando e come sarà mai aggiunto al software.

Non posso commentare così tanto su Illustrator dato che non l'ho usato per anni (solo sporadicamente), in passato ho usato più Virtuoso ( FreeHand ) e CorelDraw per cose relative al vettore. Ma almeno l'IA sembra essere al giorno d'oggi il mainstream del settore, sembra essere ricco di funzionalità e funzioni in contrasto con altri software di vettori concorrenti . Anche se il prezzo è elevato e un modello di noleggio (leasing) di software basato su cloud è ovviamente un altro tema che non tutti si sentono a proprio agio, quindi tutti devono decidere da soli qui. - Tutto sommato, dipende anche molto dal fatto che un software sia utilizzato in modo professionale, per così dire per guadagnarsi da vivere con quel lavoro o meno.

I also started with Freehand, then I switched to Ai due to the acquisition by the adobe ...
Currently on windows it still works freehand, but the standard was passed to the adobe.

But I never got along with Ai. Very slow, heavy, etc. With the many problems that had freehand (various bugs, color management, etc.), it was certainly easier to work. We did everything.

[lepr]

.

 

[R C-R]

6 hours ago, v_kyr said:

The AD developers? Well I believe most of the Affinity devs are probably already from the graphics domain and thus they should already know all these things very well. But in commercial development a dev has to follow more the route the management tells and dictates to implement, so to say the overall more important urgent things. Another point here is bug fixing, as far as the underlayed reused infrastructure has certain influencing bugs, it does make more sense to fix those first, before diving into implementing new features. Otherwise you run the risk that errors/bugs spread more and more over with every new feature.

In addition to all that, the Affinity developers (& management) have to consider the relative merits of making any changes that would affect the native file format shared by all the Affinity apps or the original design goals like for (almost) realtime adjustments, panning, & zooming.

[lepr]

.

[R C-R]

4 minutes ago, >|< said:

Must you cast a dark cloud over every suggested improvement to the apps?

I am not casting a dark cloud over anything, just pointing out a few of the things they have to consider that @v_kyr did not explicitly mention in the post I replied to. The OP seems to think both posts were worthy of a "Like" so I am not sure why you would consider either one particularly dark.

[lepr]

.

[R C-R]

31 minutes ago, >|< said:

Your responses to people's suggestions for improvement or new features always focus on hurdles and barriers that you perceive.

They don't "always" focus on any one thing, nor was my reply you quoted in any sense 'darker' than the one by @v_kyr I was replying to. Besides, there are always hurdles & barriers worth considering in any development process; it does not make much sense to ignore them.

[v_kyr]

1 hour ago, R C-R said:

'darker' than the one by @v_kyr 

Darker, like the dark side of the moon?

Being myself a long time software engineer I know one or two things about software development, programming in general, project management and most things which are associated and related to that field. Therefore I can judge quite some things in terms of feasibility and effort here, but I doubt that simple endusers would have a deeper idea (any clue) of some of the involved processes at all. Strictly speaking, they (end users) also do not need to know that, because they usually do not have to care about how things are internally structured and build up, or which overall involved design & development problems devs have to fight with etc. in their daily project related implementation work. - Since I'm not involved to Affinity, nor I'm on their payroll, I can express my opinion, or general experiences on some of these dev related topics here. However, it's not my job or intention here, to excuse any of their possible development deficits, that's something they have to argue and communicate on their own.