Subtract problem

[Milos Frydrych]

Hi.

· Windows 10 Pro  · Affinity Designer (last version).

I use Subtract function. All nodes is connected.

There is not correct result...

Milos

subtract.afdesign

[lepr]

Hi and welcome!

I just want to give you a workaround for this problem until it is fixed by the developers.

Do a non-destructive boolean operation (hold down alt key when applying a boolean command such as Subtract) to get a correct result in the form of a Compound object, and then you can apply the Convert To Curves command (keyboard shortcut is ctrl+enter) to the Compound if you need a destructive boolean result.

 

 

[Sean P]

Hi Milos,

Thanks for the file and for letting us know - I'll get it passed on to development.

Also thanks anon2 for the workaround - much appreciated. 

[Jonopen]

This has happened to me a few time recently. Glad I spotted this post, as I kept thinking I was doing something wrong. Thanks anon2 for the workaround - which works!

Here's another example:

boolean-add-glitch.afdesign

[gw_westdale]

To extend this issue a little.  
If one does a normal subtract operation (no modifier key) where the result is  apparently a compound path with two red nodes, the Layer menu / Release Compound is greyed out.
Not sure if the result is the 'wrong sort of compound'  -- it shows as '(Curves)' in the Layers panel -- or just a glitch that the command is not enabled.
(This would have been part of my workaround for the absence of a vector erase brush)

[lepr]

10 minutes ago, gw_westdale said:

To extend this issue a little.  
If one does a normal subtract operation (no modifier key) where the result is  apparently a compound path with two red nodes, the Layer menu / Release Compound is greyed out.
Not sure if the result is the 'wrong sort of compound'  -- it shows as '(Curves)' in the Layers panel -- or just a glitch that the command is not enabled.
(This would have been part of my workaround for the absence of a vector erase brush)

 

In Affinityspeak, a Compound is a container object (similar to a Group) that enables live/non-destructive Boolean constructs. The command Release Compound is only applicable to a Compound object.

The paths in a Curves object (known as a compound in some other apps) can be separated into multiple Curve objects by Layer > Geometry > Separate Curves.

[MmmMaarten]

After checking all nodes again and again in a graphic today I came to the exact same conclusion that subtract is sadly not working anymore. I'm pretty sure this was working before on the exact same file in an earlier version of Designer.

Just to give another example of it not working anymore see video below. All shapes are closed and there are no overlapping nodes or weird things. Everything is checked. Also all windings are the same, so subtract should just work without issues, but it does not. 

I found out though when changing the fill mode of the lowest layer to Alternate (even-odd) and subtract after that the result is okay. But I don't want that fill mode and when changing it back to Winding (Non-zero) after subtraction it destroys the result again.

@anon2 Thanks for this workaround. When applied to the vectors as below example it works! 

Hopefully this info helps the developers to fix it so we can use destructive subtract soon again in the next version (BTW Using Designer 1.8.5.703 here)

[MmmMaarten]

[edit] please read the last line of this post, which I think could be the solution to the issue

I just did some more testing and found out how to make it work without tricks in the file I'm working on.

In this file there are a few paths that work with subtract and others that don't (see previous post). So I tried reversing the paths of the 'non-subtracting' paths, and after that the subtract is working as expected.

So it looks like the issue of boolean subtract not (always) working has to do with the direction of the paths not being the same as the path to subtract from. (But ofcoarse this shouldn't be an issue and should always work, so this is more of a workaround than a solution)

Second video below (workaround 1): first paths without correction resulting in wrong subtract, then first reverse path directions of 'non-subtracting' paths before subtracting resulting in expected subtract. (btw, it would be nice if this forum would let us move videos around in a post)

Hope this helps the developers to fix the issue.

 

[edit] workaround 2: changing fill mode of all paths to alternate
I just found out that when changing ALL paths needed for the subtraction to 'Alternate (even-odd)' fill mode, subtraction works as expected, no matter the direction of the paths, but when switching to 'Winding (non-zero)' we get the subtraction issues back again.

In the video below all paths are in fill-mode 'Winding (non-zero)' first. And you see this is causing issues when subtracting. After that I change the mode to 'Alternate' and subtraction works fine. Changing it back to 'Winding' again and subtraction fails again.  So to me it seems like 'Winding (non-zero)' is throwing these issues with the boolean subtract operators.

And now I also understand why @anon2 's workaround works: convert to curves ALWAYS puts the created path/curve into 'Alternate (Even-Odd)' fill mode. And with that fill-mode there are no subtract issues. So the workaround in there is basically not the non-destructive subtract, neither the 'convert to curves', but the switch to 'Alternate' fill mode.

So my guess is that the issue would be fixed if subtract would automatically switch all selected paths to alternate mode first before subtracting.

 

 

workaround 1 (when in 'winding' mode): reversing direction of 'non-subtracting' paths before subtract:

[lepr]

 

5 hours ago, wigglepixel said:

And now I also understand why @anon2 's workaround works: convert to curves ALWAYS puts the created path/curve into 'Alternate (Even-Odd)' fill mode. And with that fill-mode there are no subtract issues. So the workaround in there is basically not the non-destructive subtract, neither the 'convert to curves', but the switch to 'Alternate' fill mode.

So my guess is that the issue would be fixed if subtract would automatically switch all selected paths to alternate mode first before subtracting.

 

Your issue is not the issue that was originally discussed in this thread. This thread was about bizarre paths being created by Boolean operations. Your issue concerns the fill mode of objects.

(By the way Convert To Curves does not always result in objects with Alternate fill mode. For example, applying the command to text will typically produce objects with Winding fill mode.)

[Sean P]

10 hours ago, wigglepixel said:

I found out though when changing the fill mode of the lowest layer to Alternate (even-odd) and subtract after that the result is okay. But I don't want that fill mode and when changing it back to Winding (Non-zero) after subtraction it destroys the result again.

The behaviour in Affinity is actually the correct behaviour of those two modes and a result of the direction of your curves travel in when they were initially created. Whilst the link below refers to the SVG fill rule it discusses the same Even-Odd/Non-Zero methods we use and you will see the results are to be expected.

https://www.sitepoint.com/understanding-svg-fill-rule-property/

You don't even have to change mode, you could just select a node from one of the 'broken' curves and use the 'Reverse Curve' option on the toolbar (also available is the ability to see the direction of the curve).

We would rather not change the direction on operation because there maybe some users who specifically want the directions they've set without them getting modified.

[MmmMaarten]

On 9/3/2020 at 9:27 AM, Sean P said:

You don't even have to change mode, you could just select a node from one of the 'broken' curves and use the 'Reverse Curve' option on the toolbar (also available is the ability to see the direction of the curve).

This is exactly what I wrote in my post. But the problem here is: why does it needs to be reversed in the first place if the shapes are created by 'convert to curves' in the first place.

On 9/3/2020 at 9:27 AM, Sean P said:

We would rather not change the direction on operation because there maybe some users who specifically want the directions they've set without them getting modified.

IMHO This whole thing wouldn't be a problem if Affinity would always convert to Alternate Fill Mode. But for some reason I don't get Affinity converts texts to Winding Fill Mode, making this an issue with boolean operators as we see above, and in other issues here on the forum.

@Sean P Is there a good reason why Affinity doesn't always convert curves to Alternate Fill Mode? As it seems like that would solve a lot of issues with the boolean operators.

[gw_westdale]

Many thanks anon2  for the tutorial ... conversion to software with different terms is always a challenge!