Intersects still creates hundreds of extra and unwanted/unneeded nodes

[MmmMaarten]

I was hoping the new algorhythm for outline stroke fixed the creation of too many extra nodes after using boolean functions. Unfortunately the issue is still there unsolved. This makes the intersect boolean impossible at the moment when using with complex shapes and curves. That's a shame, because it's a very important feature for working with vector graphics to rely on and I use it a lot for all kind of work. If we need to remove literaraly hundreds of extra and unneeded and recurve the thing with the nodes that are left, than this feature is pretty unusable and doesn't help.

For exporting graphics to svg for use on the web it's very important files are as small as possible. Having hundreds of redundant nodes is not what we want and makes our webgraphics unnecesary slow. Also we than don't have the controlpoints to animate shapes in the svg as suddenly there are more controlpoints than created during the design-stage.

Next to this we want to edit the curves of the shapes after boolean operations. And that's impossible with hundreds of nodes. So don't want to be rude and I love Designer, but on this point our well designed and optimized shapes lose all cleanness we work so hard on when using a boolean operation 'cause then there's a lot of unwanted and unneeded 'rubbish' in there making our shapes losing their original editablility.

Just did some tests and the result seems to be there in the latest stable version (1.7.3.481), beta 1.8.0.526 and still in the latest beta (1.8.0.532).

Added the (stripped) file I used in the video. Hopefully this can be fixed some day soon! Thanks in advance,

testfile.afdesign

[narrationsd]

@wigglepixel, I had a look, being curious, and because I saw nothing like this on intersecting reasonably irregular figures.

What I found with your example file is that if I displace by only one pixel (or whatever an arrow-key delivers) to the left, for example of the smaller piece, the problem goes away, and i get a normal-looking few points to define the resulting object.

I suspect the problem is in some kind of quantization of exact position for points of the two matching(!?) curves on the right - where you see the points build-up.

If those curves are for example very close but not entirely matching, one could imagine how this could result in many points apparently being required to define their intersection. Or, which is the reason I mention quantization, some method of reading the points which invents a micropixel difference in plotting each curve. I'd guess the quantization theory, since that could account for a noisiness where resulting intersections seem back and forth instead  of in one smooth curve.

So it's a little hard to decide if it's exactly an algorithm problem, especially as anything but this micro-match, even using your complex curves, gives a nice and simple result.

For the time being, I do understand  that you want to match the shadow/darker section within the larger and lighter one, but the result I get  with the one-(pseudo?)-pixel offset seems to look quite good, so maybe that can be good enough.

And as a fix, maybe Affinity can arrange a configurable quantization for matching, which would be saved with the drawing, to allow you to do 'exact' matches later if you really need to. Or best, an auto-configuring one, which would react when 'too many' points were generated vs. the number of  points in either of the individual objects beforehand.

These are interesting figures; not yet imagining how they'd be used....

[my results are on the latest Beta]

 

[MmmMaarten]

14 hours ago, narrationsd said:

These are interesting figures; not yet imagining how they'd be used....

@narrationsd This is one of the illustrations for an upcoming blog article about the History Of Interactive Computergraphics (part 3). This one is an illustration made from a frame from the 3D computer animation of a sphere morphing to a sphere inside out (from the project: 'Sphere turned inside out' from 1976  ). Which in fact is pretty crazy. Just imagine a sphere being inside out... that's unimaginable. But still it's possible and they did it in 1976 for the first time. If you are interested; here's part 1 and here's part 2 of this series. Part 3 with follow soon with this illustration in it.

The one pixel move as as workaround you write about is interesting. Thanks for your sharing your findings. Although not the solution to this intersection problem, if it works it could be a workaround for now I guess. I solved it now by not using intersect, but manually draw the curves instead. That was a lot quicker than fixing the intersection nodes mess. But next time I keep your tip in mind.

BTW, these shapes are definitely no exception in throwing this problem with intersection/boolean operations. I have the same problem a lot of times with all kinds of shapes. Especially when making illustrations where shapes are way more complex than just rectangles and circles (although I always draw paths instead of freehand drawing to keep nodes as minimal as possible). So this is definitely no exception.

Hopefully Serif is able to solve this thing in the near future. Maybe your hints could help them. Thanks!

[narrationsd]

Maarten, that's very interesting....

Yes, I suspect Affinity can easily deal with this problem, once seeing it clearly, alongside the work-around here.  I'd modify what I said only to suggest that a desirable automatic fix mode be also one of equally available configuration choices, necessarily saved in the document  -- I think you'd still like to be able to adjust in some circumstances, as ever for getting what the human sees best.

5 hours ago, wigglepixel said:

I always draw paths instead of freehand drawing to keep nodes as minimal as possible

Yes, I had some thinking this might have occurred and been part of the problem -- if you drew _again_ for example the problem curve that produces the myriad-point intersection. Drawn or traced again with not precisely the same path as the initial shape, then there're all sorts of opportunities for micro-difference -- including once again possibly primarily in the quantization given intersection probably works with measured-apparent positions rather than the Bezier points themselves. But again, Affinity guys and gals will have to know the details.

Now, I looked at your references, and have to say that's an extremely attractive presentation. Your mini-resume gives a pretty good hint how this came about ; also reminds a bit of how it was to come in weekends or evenings when consulting with the BBC, and find persons micro-refining what would become one more excellent video interval on someone's television.

As to the procedure with the sphere, it must be an exact example of the phrase on the Wikipedia page for it: 'veridical paradox'. What looks it can't be true but is, to save someone from looking it up.

The key is that this is a purely mathematical procedure, where the sphere is allowed to intersect itself along the way.  This is not physical; and I take it as due warning to what one may understand as a danger signal in other situations, that the way so much 20th century physics is based entirely on math that just 'happens' to fit with what can be even quite carefully observed --in some cases but not others -- is no full answer. Witness controversy not lessening about 'dark matter', 'dark energy', relativity/quantum irreconcilability, and whether the universe is indeed stretching as we think after the last flip-flop about this. Small matters, and that is a multiple pun.

Ok, enough on a Sunday morning, but maybe will amuse you.

Take care,
Clive

[lacerto]

(...)

[Jowday]

19 hours ago, Lagarto said:

Here is what happens in CorelDRAW if you first draw a shape, then add a node in a segment and immediately delete it (the curvature stays exactly the same):

Here is what happens when the same thing is done in Designer (the curvature significantly changes):

This means that it is very difficult in Designer to simplify a curve even manually. E.g., I tested removing superfluous nodes manually from the intersected shapes of your example picture in CorelDRAW and could do so without changing the curvature simply by avoiding to remove too much nodes at the same time, but trying the same in Designer resulted sooner or later in gradual change of the curvature.

The ideal solution to the problem (at least for typically modest accuracy needed in graphic design) would be implementing some kind of tolerance value for boolean operations so that curvatures that very closely overlap would be considered identical (so no additional nodes would be needed to define the resulting shape), but I''m not sure if that is possible without somehow simplifying the affecting curves beforehand so perhaps it is better to do this mathematically accurately in the first place and then provide good tools for automatic, adjustable and manual simplifying.

You have to use a keyboard shortcut every time you delete a node to get the same result - I would much prefer the opposite.

• Ctrl+Alt+Backspace (Windows)
• Alt+Delete (Mac)

Removing a lot of nodes manually that way is maddening ineffective. Time consuming too. The Windows keyboard shortcut combined with mouse clicking is murder. It is like control + alt + delete + touch your toe simultaneously.

 

[lacerto]

(...)

[MEB]

Hi wigglepixel,
This is a known issue that (i believe) is still being looked for 1.8. Although quite a few issues were fixed in the current Beta, there's still some cases/situations that fail with most up to date code revision. I've logged/passed your file to the dev team for checking/testing against new builds. If you happen to have more problematic files involving boolean operations (not necessarily with complex curves as the case you posted) please upload them (you can delete all other objects from the file) for us to check/add to our log. Thanks for your report/support.