Ben
-
Posts
2,001 -
Joined
-
Last visited
Posts posted by Ben
-
-
54 minutes ago, prophet said:
Nice tool.
Is there much call for the "Semi-Circular" spiral? I get that it's a recreation of the workaround people have been using, but with a true Linear spiral, I can't see a use case for it. The double-back option is nice. Could that be added to other spirals as well?
Yes, because it is the only curved spiral that finishes in the centre of the shape - all other curved spirals have a non-centred end. The plotted one achieves this (currently) at the expense of it using straight lines to link the procedurally placed points.
-
-
48 minutes ago, ronnyb said:
@Ash wonderful news! Quick question: is there any chance to have a TRUE PHI-ratio spiral tool option (in contradistinction to the Fibonacci option which is an integer approximation) ?
By TRUE spiral, i mean a spiral that is CONTINUOUSLY changing its rate of expansion/contraction, not just at periodic intervals like 90 degrees etc, but continuously along every point on the spiral… 🌀
Thanks for all you do!
Yes - the construction for a Phi spiral would be fundamentally different to Fibonacci. The Fibonacci we build from the centre following the sequence. A Phi spiral would be a constant scaling from the outside. I'll have a think.
Actually - try using the Decaying spiral, set "Decay per segment" and use 100-(100/phi) for the Decay value. I could probably add this as a preset.
We do have a continuous spiral - it's the plotted one. Each point is correctly placed. Currently it's line segments only (though you can increase that to add accuracy). If I can figure out the maths for correct(ish) curve segments I'll add it.
-
Adobe does not publish the internal workings of their text engine. Without this proprietary knowledge it is almost impossible for us to export editable text to PSD.
-
19 hours ago, Mithferion said:
Some of the results on the video seem a bit random to me. I like the idea overall, but when shapes overlap... not so much.
Best regards!
Having played with the Live Paint feature in AI, it does seem to get very confused very quickly. It's sort of OK until you change the geometry a lot, then it doesn't really know where you intended the fill to be.
The feature also regroups your layers - so will change any ordering you might have had. Fine, unless your ordering was exposed by occluded fills and strokes.
So, our approach doesn't mess with your original layer ordering (apart from if you insert fill layers in-between). Also, we create post-editable fill objects - so when you are done, you can treat them like any other layer. -
16 hours ago, jmwellborn said:
In the notes for Designer 2 Beta 1736 it states: "When your bucket is loaded with a colour/fill you can now just click on any object to fill it even if it is not selected. In this case this will just fill the whole object - if you want the fill tool to take into account intersecting shapes and curves they all need to be pre-selected as before." Unless I don't understand, it looks as though clicking on the portion one wishes to fill with the loaded vector flood fill tool makes the selection on the layers panel. Very nice, if this is the expected result. Video attached.
This is a (welcome) side-effect in some ways. The new objects you created to do the internal fills are like any other curve object. So, the 'click to select and fill' method works on them in exactly the same way. When you click it will find the top most filled object at the mouse position - in this case it happens to be an area fill you made previously.
-
12 hours ago, bt1138 said:
It's pretty amazing that there are people in the world who can figure stuff like this out. Thanks, @Ben
It's what I do.
-
-
21 hours ago, ,,, said:
You certainly could be right about results differing because of the difference between font versions on Windows versus macOS, rather than differences in the Affinity code on each platform.
There is no "Divide (Compound)" command. I guess you are talking about alt/opt-clicking the Divide button in the toolbar, similar to alt/opt-clicking the Add/Subtract/Intersect/Xor buttons to create a Compound.
Alt/opt-clicking Divide does not produce a Compound. The alt/opt key is a modifier for Divide when one or more unfilled curves are in the collection of operands. The key is used when you want the fragments of unfilled curves to be kept, otherwise they are discarded.
When filled text is an operand in a Boolean operation, the text is first wrongly converted to unfilled curves instead of filled curves (a persistent bug for several years now), and then the Boolean operation proceeds. Hence, the difference you were getting by doing a simple Divide with filled text versus an alt/opt-Divide with filled text. You were effectively dividing with unfilled curves when dividing with filled text.
Yes- different platforms are likely to have subtly different fonts. They may have the same name, but might be produced differently. As I stated before - the specific error with failure to perform the bool op is down to edge case calculations as a result of possibly only one or two curves in the font glyphs. This will be rectified in 2.1.
- Sam LaGargouille, debraspicher and lepr
-
1
-
2
-
-
3 hours ago, Designer1 said:
@BenYou have only partially fixed the problem in version 2.04. Cutting the letter S with the knife does not work.
That will be because I haven't actually released a fix yet. I said I was working on it - not that it had gone live.
- SrPx and debraspicher
-
2
-
16 hours ago, SrPx said:
Does this mean that "copy as SVG" preference and "paste special- as SVG" produces inaccurate geometry? I'd be worried for other workflows, not just this... I mean, supposedly, nothing should ruin the geometry, inside the software...
No - I'm referring to anything that modifies the geometry, such as using the contour tool to create curves that are slightly different.
-
The workarounds are going to ruin your geometry. Anyone is free to apply this as a temporary measure, but it's less than ideal. We wouldn't look to incorporating this as a solution in our code.
-
Thanks for the file.
The issue is exactly what I suspected. We are seeing some precision issues with very specific types of curves. Unfortunately, fonts seem to exhibit these forms of curves more than anything else - curves that are almost symmetrical, but less than a complete 1/4 circle arc.
In a nutshell - there is a calculation we do that uses some complicated maths for polynomial root finding - these curves produce numbers that get very large in the calculation and exceed the limits of what a 64-bit computer can handle without loosing vital precision. Creating these test cases was difficult - they just happen by an unfortunate combination of input geometry, and hard to predict. But, the method we are using produces much more overall accurate results than other software might do (we give you a zoom to over 1,000,000%, and we try to ensure that anything you do looks precise even past that zoom level).
I am working on a solution to this issue that balances the needs of precision and speed.
- debraspicher, NotMyFault, davemac2015 and 1 other
-
3
-
1
-
@Designer1 Can you upload your actual file. It is likely that there is a maths precision issue affecting that specific character glyph. I can only know for sure by debugging it.
Can you also convert your text to curves before uploading.Thanks.
-
That's some top grade work, Sir!
Why you going to leave us? It's seeing quality like this that makes me remember why I toil away blood, sweat and tears working on the vector tools.
Hell - if it'll keep you around, I'll get to work cloning Buster Crabbe, so that we can make you lead artist on a new Flash Gordon movie serial.
-
If you have a file that demonstrates the crash, please submit it so that we can see what is causing the problem.
-
14 minutes ago, PixelPest said:
I don´t get where the issue is - as with N.P.M. the Point Transform Tool is all it needs imho:
And this is the correct answer!
-
This will be because all angles are represented internally as radians. We then convert them to degrees using a*180/pi. That leads to a small amount of error in floating point precision. The error is small enough not to matter in real terms.
In this example - the angle is not about the circle, but the arc start/end when presenting a pie shape.
As Walt also says - we use cubic bezier quadrant approximations for a circle/ellipse - so there is an element of error in the outline compared to a mathematically true circle.
-
@Pšenda This is not the issue. We have all the checks possible to allow saving files to any storage medium (in fact, more than most software). The issue lies in the way that USB attached storage buffers data to later be written to physical storage. We will have finished writing the file with no error messages coming back from the Operating System. The *actual* write to the physical hardware happens at a later time that is out of our control - there is additional management of the hardware performed by device drivers, etc. This is one of the reason why you MUST dismount external drives BEFORE disconnecting them.
We rarely (if ever) see these kind of corruptions happening on local storage, and that is why we advise people to work on local storage (which is also faster). Attached storage is good for duplicated backups, and we recommend that also.
If a file fails to write during our saving process, we have checks and mitigation for that - as well as disconnected network shares, changes in access/permissions, out of space, etc. What we have no control over is what happens to the file after the saving process completes.
-
If the start of the file has been overwritten with zeros, then it will be missing vital data and can't be fixed.
-
-
Is there an error code?
-
We don't snap between geometry, only bounds of an object. The exception is for points when using the Node tool, or positioning the corner of an object bounding box.
You can use the Node tool, and snap a guide to the nodes and handles of the currently selected curve objects. I think you only need to select the object, not the individual handles for that to work. (off the top of my head I can't recall if I added this for 1.8 or if it's already in 1.7).
I could add snapping of guides (conceptually any infinite line) to curves in an object, BUT that snap could potentially have many potential targets. To now, people have been happy with snapping to bounds.
Spiral Tool
in [ARCHIVE] 2.4, 2.3, 2.2 & 2.1 Features and Improvements
Posted
He came up with that example, because that's what I gave him in way of an explanation.
When using the cusped version, the spiral is formed from straight lines. The partial turn in this case is a percentage of the distance along these straight lines for a single 'turn'. To express this as an angle about a notional centre is less meaningful when the geometry is not an arc. Using an angle would result in non-linear interpolation of the straight line segments.
Note, a 'turn' is a complete lap around, not a segment or arc. Since arc angles (or more accurately, the circle divisor angle) can be arbitrary, a turn is determined as being independent of the arc angle for simplicity. So - you can specify a spiral of 2 turns (a notional rotation of 720 degrees) but then set the arc angle to whatever value gives you the visual result you want.