JET_Affinity

There are plenty of programs I have no use for. So I don't use them. And I don't waste my own time repeatedly asking their makers "WHEN is such-and-such going to occur?!"
JET

It's called applying pressure.
It's called the silly belief that if you merely scream the loudest and most repetitively ask "When? When? When?" and make ridiculous claims that the program is absolutely useless without your pet feature, then you will somehow win out over every other person who employs the very same tactic about their pet feature.
JET

There are plenty of programs I have no use for. So I don't use them. And I don't waste my own time repeatedly asking their makers "WHEN is such-and-such going to occur?!"
JET

There are plenty of programs I have no use for. So I don't use them. And I don't waste my own time repeatedly asking their makers "WHEN is such-and-such going to occur?!"
JET

Hi robinp,
I understand your request and frustration for not having this available yet but these same arguments apply to every other market/area where a couple tools would be of help and considered essential for the app in that area. Affinity apps/features are not being developed/prioritised based on/or to "arbitrarily" fill the need/gaps of different markets (or to mimic behaviours or features of other apps) - they are primarily being developed as whole (consistent) project on their own right - based on our own vision/following our current plans. We keep improving/expanding them (as time permits) based on user feedback but in way it does make sense in this context and when it's applicable/feasible for the dev teams. Nobody is denying there's a few features lacking and that a few years have passed by now but that time was used to offer a host of new features/improvements to the apps, expanded to other platforms and complete the suite as intended - it wasn't wasted in meaningless/flashy things - while i understand some may not be relevant for you - specially if you work frequently with technical drawing -, it doesn't mean they aren't for other users. It's not easy to fulfil the expectations of everyone in particular when users have different needs/requirements. We did and continue doing our best to address these concerns (even if not as quick as users eventually desire/want) but we have to do it according to our resources and time and without "hijacking" our own vision for the suite.

Ah yes, those NDAs are from the Plus range beta testing period, they aren't applicable any longer. The beta tests for the Affinity range of products are done completely differently now.
 

There isn't much of an update to give unfortunately. We've just shipped version 1.7 and now we're working out what should come next.
Despite what some of the posts in this thread have suggested, we do listen, and we do implement features and changes as suggested by our users. Designer was first released 5 years ago, and since then people have been receiving free features and bug fixes, many of which had been requested and debated on this forum ahead of time. We think that's pretty fair.

Convincing 2D converging perspective is not that simple. If it were, we wouldn't need any special features for it. We can already just draw arbitrary horizon lines and perspective rays like we do on paper.
Nor do I assume it's that simple to implement in software. Have you tried the Perspective Grid feature in Adobe Illustrator (which it copied from FreeHand)? Many users no doubt think it must be rigorous just because it's in software. But it's easy to catch it committing the common error in which foreground grid "squares" become less foreshortened vertically than horizontally and therefore look like elongated rectangles instead of squares (not at all how the eye would see it).
Here's the thing: The kind of casual "vanishing point" perspective typically taught in basic art classes is actually not very rigorous. Students get exposed to so-called "one-point", "two-point", and "three-point" perspective and are led to assume that three-point perspective is some kind of end-all of ultimate realism just because the subjects we draw reside in 3D space. It's not. A view of 3D objects in 3D space can have an infinite number of "vanishing points." (Think of tossing your toddler's collection of building blocks upward into the air and taking a photo.)
Yet just watch a few of the many amateur YouTube videos on the subject and listen to how many times you hear the demonstrators use phrases like "There you have it; a perfect perspective of [this or that]!" Also note that they typically just place their vanishing points at any random locations relative to each other, without any kind of actual geometric basis.
Rigorous converging perspective must be based on the geometry of optics; of conic vision. Grid squares don't merely shrink toward the distance, they change in shape. (I wonder how many graphic designers and even illustrators understand that if you take a photo with a "normal lens," crop it down to a distant part of the subject, and then enlarge it, the resulting image looks like it was taken with a more "telephoto" lens.)
There are more formalized methods of constructing converging perspective. For example, before computers architects used a more elaborate construction method which did a better job of constraining things to realistic proportions. Technical illustrators had special equipment like Klok Perspective Boards and Tables and their graduated ruler scales.
That's not to say that the willy-nilly kind of informal converging perspective is "illegitimate" as an illustrative style. It's not. Grossly exaggerated perspective is commonly used just to add overstated drama in everything from Marvel's super hero comic books to the Marketing Department's rendition of the corporate trade show booth.
My point is that "vanishing point perspective" is a broad subject encompassing methods and purposes that range from rigorous to whimsical. So a "good" software implementation of it is an ill-defined target.
Axonometric drawing, by comparison, is not like that at all. There's nothing ambiguous or arbitrary about it. It is either geometrically correct or it is not, in fact, axonometric.
Again, the Lazy Nezumi Pro approach to interactive drawing aids causes me to re-think the need for program-native features for converging perspective. For example, one of the demo video clips on the LNP site demonstrates its Fisheye perspective variant. How often have you ever seen that kind of 2D perspective convincingly executed by the traditional "vanishing point" methods? That novel implementation alone represents a lot of potential.
In my previous post, I mentioned that the applicability of LNP to vector-based drawing is largely dependent upon the number and quality of Bezier path drawing tools that are used by dragging along the onscreen guides. It may be more advantageous for Affinity development to simply focus on optimized Bezier path tools that are of superior quality in terms of functional economy and editing elegance; i.e., the number and placement of nodes and handles automatically generated when the tool is dragged.
JET

Convincing 2D converging perspective is not that simple. If it were, we wouldn't need any special features for it. We can already just draw arbitrary horizon lines and perspective rays like we do on paper.
Nor do I assume it's that simple to implement in software. Have you tried the Perspective Grid feature in Adobe Illustrator (which it copied from FreeHand)? Many users no doubt think it must be rigorous just because it's in software. But it's easy to catch it committing the common error in which foreground grid "squares" become less foreshortened vertically than horizontally and therefore look like elongated rectangles instead of squares (not at all how the eye would see it).
Here's the thing: The kind of casual "vanishing point" perspective typically taught in basic art classes is actually not very rigorous. Students get exposed to so-called "one-point", "two-point", and "three-point" perspective and are led to assume that three-point perspective is some kind of end-all of ultimate realism just because the subjects we draw reside in 3D space. It's not. A view of 3D objects in 3D space can have an infinite number of "vanishing points." (Think of tossing your toddler's collection of building blocks upward into the air and taking a photo.)
Yet just watch a few of the many amateur YouTube videos on the subject and listen to how many times you hear the demonstrators use phrases like "There you have it; a perfect perspective of [this or that]!" Also note that they typically just place their vanishing points at any random locations relative to each other, without any kind of actual geometric basis.
Rigorous converging perspective must be based on the geometry of optics; of conic vision. Grid squares don't merely shrink toward the distance, they change in shape. (I wonder how many graphic designers and even illustrators understand that if you take a photo with a "normal lens," crop it down to a distant part of the subject, and then enlarge it, the resulting image looks like it was taken with a more "telephoto" lens.)
There are more formalized methods of constructing converging perspective. For example, before computers architects used a more elaborate construction method which did a better job of constraining things to realistic proportions. Technical illustrators had special equipment like Klok Perspective Boards and Tables and their graduated ruler scales.
That's not to say that the willy-nilly kind of informal converging perspective is "illegitimate" as an illustrative style. It's not. Grossly exaggerated perspective is commonly used just to add overstated drama in everything from Marvel's super hero comic books to the Marketing Department's rendition of the corporate trade show booth.
My point is that "vanishing point perspective" is a broad subject encompassing methods and purposes that range from rigorous to whimsical. So a "good" software implementation of it is an ill-defined target.
Axonometric drawing, by comparison, is not like that at all. There's nothing ambiguous or arbitrary about it. It is either geometrically correct or it is not, in fact, axonometric.
Again, the Lazy Nezumi Pro approach to interactive drawing aids causes me to re-think the need for program-native features for converging perspective. For example, one of the demo video clips on the LNP site demonstrates its Fisheye perspective variant. How often have you ever seen that kind of 2D perspective convincingly executed by the traditional "vanishing point" methods? That novel implementation alone represents a lot of potential.
In my previous post, I mentioned that the applicability of LNP to vector-based drawing is largely dependent upon the number and quality of Bezier path drawing tools that are used by dragging along the onscreen guides. It may be more advantageous for Affinity development to simply focus on optimized Bezier path tools that are of superior quality in terms of functional economy and editing elegance; i.e., the number and placement of nodes and handles automatically generated when the tool is dragged.
JET

Meanwhile, as Frozen mentioned, to those who haven't yet, it really is worth looking at Lazy Nezumi Pro.
LPN's claim-to-fame is that it is not an "add-on" for any particular graphics program.  It sort of gives your computer some drawing smarts, instead of just a particular graphics program. The drawing or painting program you're using doesn't even know it's there. You just launch it and then click the application window that you want to work within. It works by affecting cursor movement at the system level, "smoothing" your pointing device movements to constrain to the on-screen guides that it effectively "overlays" within that window. It's the closest thing I've seen to software actually emulating the use of physical drawing aids like rotatable rulers and ellipse templates. The way it works gives it these huge advantages:
Although it has a quite sophisticated collection of setup options, it's worth the learning curve because you learn it once and it works the same way regardless of what drawing or painting program you're using at the moment.
  Although originally presented as a drawing aid for raster-based drawing, it's not just for raster imaging. It's just as applicable in windows of vector-drawing applications; it just depends on your having selected an appropriate drawing tool. Yeah, it works with path drawing tools you think of as "freehand" (pencil, brush, etc.), but it's just as useful for a line tool (or Affinity's Pen Tool in Line Mode). It's basically appropriate for any tool you drag along the desired direction because that's what it does; it affects the smoothness or straightness of your drag inputs.
  Its perspective features include configurations for constructing both converging perspective and parallel perspective.
  Contrary to common misconception, it is not just for using a stylus (which I very seldom use). On desktops or laptops, it doesn't know or care what you are using for a pointing device. (I can't speak to the matter of finger gestures on cell phones because I quit finger painting before kindergarten. So LNP is not something that competes with Affinity, it just serves as a drawing enhancement for it or whatever graphics program(s) you are using. I think you can download it as a demo to try it out in whatever program(s) you have in mind.
JET

Meanwhile, as Frozen mentioned, to those who haven't yet, it really is worth looking at Lazy Nezumi Pro.
LPN's claim-to-fame is that it is not an "add-on" for any particular graphics program.  It sort of gives your computer some drawing smarts, instead of just a particular graphics program. The drawing or painting program you're using doesn't even know it's there. You just launch it and then click the application window that you want to work within. It works by affecting cursor movement at the system level, "smoothing" your pointing device movements to constrain to the on-screen guides that it effectively "overlays" within that window. It's the closest thing I've seen to software actually emulating the use of physical drawing aids like rotatable rulers and ellipse templates. The way it works gives it these huge advantages:
Although it has a quite sophisticated collection of setup options, it's worth the learning curve because you learn it once and it works the same way regardless of what drawing or painting program you're using at the moment.
  Although originally presented as a drawing aid for raster-based drawing, it's not just for raster imaging. It's just as applicable in windows of vector-drawing applications; it just depends on your having selected an appropriate drawing tool. Yeah, it works with path drawing tools you think of as "freehand" (pencil, brush, etc.), but it's just as useful for a line tool (or Affinity's Pen Tool in Line Mode). It's basically appropriate for any tool you drag along the desired direction because that's what it does; it affects the smoothness or straightness of your drag inputs.
  Its perspective features include configurations for constructing both converging perspective and parallel perspective.
  Contrary to common misconception, it is not just for using a stylus (which I very seldom use). On desktops or laptops, it doesn't know or care what you are using for a pointing device. (I can't speak to the matter of finger gestures on cell phones because I quit finger painting before kindergarten. So LNP is not something that competes with Affinity, it just serves as a drawing enhancement for it or whatever graphics program(s) you are using. I think you can download it as a demo to try it out in whatever program(s) you have in mind.
JET

The kind of "vanishing point" converging perspective va2m is describing is entirely based on 2D construction. And it's nothing new. Macromedia FreeHand implemented a grid system for it way before it was copy-catted into Adobe Illustrator (after Adobe's acquisition of Macromedia).
But I'd suspect it would be cleaner (both from the programming perspective and for the user interface) to implement it separately from the parallel perspective grids feature still under development in Affinity.
JET

I suspect most everyone (including the developers) recognizes the need for a well-implemented (frankly, that rules out Illustrator's) offset path function. But Affinity presently has some well known frequently discussed (including the developers) problems with results of its outline stroke command, which I'd assume is closely related. So my guess would be that there is a kind of shared foundational fix that has to be addressed before piling on related features and commands.
JET

I suspect most everyone (including the developers) recognizes the need for a well-implemented (frankly, that rules out Illustrator's) offset path function. But Affinity presently has some well known frequently discussed (including the developers) problems with results of its outline stroke command, which I'd assume is closely related. So my guess would be that there is a kind of shared foundational fix that has to be addressed before piling on related features and commands.
JET

Mithferion,
That quote sounds to me more like it's all about third-party commercial plug-ins, not about an end-user scripting implementation.
I don't get excited about plug-ins. I learned early-on in the 80s to avoid dependency upon third-party plug-ins marketed toward users like the plague (as opposed to those aimed at things like production; pagination tools, drivers for NC devices, etc).
Illustrator is the case-in-point. AI users spend a lot of money and time on third-party plug-ins just to add "missing" functionality, like dimension tools, or halftone effects, or better path manipulations. Such plug-ins are typically disproportionately expensive; often costing half-again the cost of the host program, or more. They chronically (and understandably) fall out of sync with the current version of the host program, sometimes lagging behind version changes by months. That is likely to worsen as most of the old-world software vendors have moved toward annual version changes (providing less and less in the way of substantive improvement per version) in attempts to smooth revenue flow.
User plug-ins are seldom as smoothly integrated as would be native features. CADTools, for example, much as many like it, practically constitutes a whole other interface when its active. That's not functional elegance.
To the user, third-party plug-ins are additional licenses and version updates to maintain. Their creators are usually comparatively small firms, which come and go.
Moreover, third-party feature add-ons from all these varied sources are written to interface with the host program, but are effectively oblivious to each other. So adding a collection of plug-ins to a drawing program's interface tends toward grab-bag clutter and sometimes even redundancy. For example, suppose instead of waiting for Affinity to gain its arrowheads feature, we bought a popular plug-in called Pointers4Affinity from a company called StartupA. Instead of waiting for Affinity to gain a dimensioning feature, we buy a plug-in called Rulers4Affinity from a company called StartupB. What's the likelihood of being able to use our arrowheads in conjunction with our dimensions?
That's why Illustrator's 3D Effect resides in its own modal dialog. It's just a plug-in based on a very limited functional subset of the defunct Adobe Dimensions application. Apart from its ability to import a Symbol from the current document's Symbols library as mapping art, it is essentially separate from the rest of the program. Each instance of it on the page is conceptually a "separate document" of that plug-in. It can, for example, turn a circle into a torus (by revolving the circle) OR it can turn a circle into a cylinder (by extruding the circle). But it can't make that torus orbit that cylinder within the same model space.
In short, I consider it potentially self-defeating folly for creatives (freelance illustrator and designers) to allow themselves to become habituated to (i.e., make their businesses mission-critically dependent upon) such add-ons. To my mind, the "plug-in architecture" concept, loudly marketed to end-users as the "next big thing" in the 90s, has been largely a failure.
A well-done scripting implementation is another thing entirely. It empowers the user to autonomously automate his repetitive routines far more powerfully than with just a macro feature (like Adobe's Actions) that merely records a sequence of (some of) the commands available in the standard UI. But moreover, as the user gets his feet wet, he finds he can essentially create his own vertical-need "features" that do exactly what he needs, by using variables, calculations, and conditional logic while accessing the actual objects, methods, and properties of the elements that lay beneath the standard user interface.
Scripting is not for everyone, because it assumes at least beginner level understanding of the language used. But those languages are openly, widely, and freely used standards accessible to any interested user. JavaScript, Python, VBA, AppleScript, etc. By "well-implemented" I mean:
A thorough, well-organized, and reliably updated documentation of the program-specific object model (not of the scripting language itself; that's up to the user to obtain elsewhere). Inclusion in that object model access to at least the basic objects for UI alerts, modal windows, and non-modal palettes, so that the scripter can cleanly present the necessary script-specific user options when the script is run. Clear, simple, and practical examples of using each object. Adobe has done a pretty good job of this; arguably too good by including not just Javascript, but also platform-specific languages (VBA and AppleScript), each of which requires its own documentation. Instead of platform-specific scripting languages, I'd frankly rather see a native program-specific scripting model like in FileMaker Pro. That has a full user-interface, excellent documentation, and being native, empowers the same script to work on any platform on which FileMaker runs, including FileMaker Server.
Inkscape, on the other hand, now sort of "favors" Python, but its documentation (being dependent upon volunteers) is weak and scattered. "Examples" in its case pretty much involves dissecting existing "Extensions" that are bundled with the program. That's not an easy path for scripting newcomers.
Also, bear this in mind regarding the best language to support: Adobe apps are scriptable in Javascript, not Python. Many users, like me, have cut their graphics scripting teeth on Javascript. It would be a relatively short transition for us to Javascript for Affinity. That consideration is compounded by the potential importance of embedding scripts in PDFs. Acrobat is still unavoidable in my workflow, and you can do wonderful things with Javascripted PDFs.
So if I had my heart's desire, Affinity would focus on developing an excellent (as described above) single-language (Javascript) solution to empower its users. That's cross-platform, open-source, full-featured, and has a long-established ubiquity in other environments, including the web.
I would think Affinity has this huge potential advantage: Adobe has to provide and maintain separate and different scripting implementations for each of its products, because they were developed (or acquired) separately. As I understand it, having been developed concurrently from the ground up, the three Affinity apps have the same underlying object model and code base. So I welcome correction if I'm wrong, but I suspect one thorough implementation and set of documentation could enable the Affinity scripting user to learn a single object model for the whole suite. Trust me, that would be a much less intimidating learning curve than gaining proficiency in scripting Illustrator, Photoshop, and InDesign.
JET

It's a reasonable request, but the trouble with promising features, is that when they don't appear for whatever reason, people get annoyed - this post is an example of that. So for now, we have nothing to say about future features.
I would also like to re-iterate that we released Designer 5 years ago, and our customers have been receiving free feature and bug fix releases over this period. We think that's pretty reasonable.

No, we just didn't want to start having a cross-over of functionality. We added Artboards to Designer after we had discussed pages, as that makes more sense for the majority of our customers.
If you don't want to buy the software, then please don't buy it. Use whatever software works for you.

Designer has the ability to navigate through pages in an afpub file, but that's about it. If you want to work with page layout, then we suggest using Publisher. Designer is a vector design and illustration app, so pages aren't part of its remit.

Mithferion,
That quote sounds to me more like it's all about third-party commercial plug-ins, not about an end-user scripting implementation.
I don't get excited about plug-ins. I learned early-on in the 80s to avoid dependency upon third-party plug-ins marketed toward users like the plague (as opposed to those aimed at things like production; pagination tools, drivers for NC devices, etc).
Illustrator is the case-in-point. AI users spend a lot of money and time on third-party plug-ins just to add "missing" functionality, like dimension tools, or halftone effects, or better path manipulations. Such plug-ins are typically disproportionately expensive; often costing half-again the cost of the host program, or more. They chronically (and understandably) fall out of sync with the current version of the host program, sometimes lagging behind version changes by months. That is likely to worsen as most of the old-world software vendors have moved toward annual version changes (providing less and less in the way of substantive improvement per version) in attempts to smooth revenue flow.
User plug-ins are seldom as smoothly integrated as would be native features. CADTools, for example, much as many like it, practically constitutes a whole other interface when its active. That's not functional elegance.
To the user, third-party plug-ins are additional licenses and version updates to maintain. Their creators are usually comparatively small firms, which come and go.
Moreover, third-party feature add-ons from all these varied sources are written to interface with the host program, but are effectively oblivious to each other. So adding a collection of plug-ins to a drawing program's interface tends toward grab-bag clutter and sometimes even redundancy. For example, suppose instead of waiting for Affinity to gain its arrowheads feature, we bought a popular plug-in called Pointers4Affinity from a company called StartupA. Instead of waiting for Affinity to gain a dimensioning feature, we buy a plug-in called Rulers4Affinity from a company called StartupB. What's the likelihood of being able to use our arrowheads in conjunction with our dimensions?
That's why Illustrator's 3D Effect resides in its own modal dialog. It's just a plug-in based on a very limited functional subset of the defunct Adobe Dimensions application. Apart from its ability to import a Symbol from the current document's Symbols library as mapping art, it is essentially separate from the rest of the program. Each instance of it on the page is conceptually a "separate document" of that plug-in. It can, for example, turn a circle into a torus (by revolving the circle) OR it can turn a circle into a cylinder (by extruding the circle). But it can't make that torus orbit that cylinder within the same model space.
In short, I consider it potentially self-defeating folly for creatives (freelance illustrator and designers) to allow themselves to become habituated to (i.e., make their businesses mission-critically dependent upon) such add-ons. To my mind, the "plug-in architecture" concept, loudly marketed to end-users as the "next big thing" in the 90s, has been largely a failure.
A well-done scripting implementation is another thing entirely. It empowers the user to autonomously automate his repetitive routines far more powerfully than with just a macro feature (like Adobe's Actions) that merely records a sequence of (some of) the commands available in the standard UI. But moreover, as the user gets his feet wet, he finds he can essentially create his own vertical-need "features" that do exactly what he needs, by using variables, calculations, and conditional logic while accessing the actual objects, methods, and properties of the elements that lay beneath the standard user interface.
Scripting is not for everyone, because it assumes at least beginner level understanding of the language used. But those languages are openly, widely, and freely used standards accessible to any interested user. JavaScript, Python, VBA, AppleScript, etc. By "well-implemented" I mean:
A thorough, well-organized, and reliably updated documentation of the program-specific object model (not of the scripting language itself; that's up to the user to obtain elsewhere). Inclusion in that object model access to at least the basic objects for UI alerts, modal windows, and non-modal palettes, so that the scripter can cleanly present the necessary script-specific user options when the script is run. Clear, simple, and practical examples of using each object. Adobe has done a pretty good job of this; arguably too good by including not just Javascript, but also platform-specific languages (VBA and AppleScript), each of which requires its own documentation. Instead of platform-specific scripting languages, I'd frankly rather see a native program-specific scripting model like in FileMaker Pro. That has a full user-interface, excellent documentation, and being native, empowers the same script to work on any platform on which FileMaker runs, including FileMaker Server.
Inkscape, on the other hand, now sort of "favors" Python, but its documentation (being dependent upon volunteers) is weak and scattered. "Examples" in its case pretty much involves dissecting existing "Extensions" that are bundled with the program. That's not an easy path for scripting newcomers.
Also, bear this in mind regarding the best language to support: Adobe apps are scriptable in Javascript, not Python. Many users, like me, have cut their graphics scripting teeth on Javascript. It would be a relatively short transition for us to Javascript for Affinity. That consideration is compounded by the potential importance of embedding scripts in PDFs. Acrobat is still unavoidable in my workflow, and you can do wonderful things with Javascripted PDFs.
So if I had my heart's desire, Affinity would focus on developing an excellent (as described above) single-language (Javascript) solution to empower its users. That's cross-platform, open-source, full-featured, and has a long-established ubiquity in other environments, including the web.
I would think Affinity has this huge potential advantage: Adobe has to provide and maintain separate and different scripting implementations for each of its products, because they were developed (or acquired) separately. As I understand it, having been developed concurrently from the ground up, the three Affinity apps have the same underlying object model and code base. So I welcome correction if I'm wrong, but I suspect one thorough implementation and set of documentation could enable the Affinity scripting user to learn a single object model for the whole suite. Trust me, that would be a much less intimidating learning curve than gaining proficiency in scripting Illustrator, Photoshop, and InDesign.
JET

I do remember what they look like, as I need to identify them along the Windows system tray when I want to switch to a different one.
But I'm happy with the current set of Affinity icons, and I don't care what Serif does with them. Except that the beta programs really need to have their icons distinguished in some way again, like they used to be

Another detail worth mentioning along these lines is a keyboard modifier that would control whether or not preexisting extended handles are respected when joining. Back when Illustrator couldn't join more than two paths at once (not that long ago), I hacked out a couple of Javascripts for that:

JET
 

At any price, it's a matter of principle, and something I simply will not do. Subscription licensing is a means by which to entrap customers, and it effectively holds your own working files "hostage."
My wife and I have been married for 40 years (a little longer than I've been paying for the majority of the mainstream drawing programs). But I don't marry software vendors, wise guy.
JET

Practically everyone couches their pet feature desire in terms of the "most fundamental, basic, must-have deal-breaker preventing my being able to do anything with Affinity," and "the one and only thing preventing my ceasing paying Adobe's extortion fees."
And I still say that emulating Illustrator is the last thing I want to see. I don't want "me, too"; I want better. No matter how long it takes.
The video of using an envelope distortion in Illustrator  to apply a dimple texture to a bullet is a case-in-point, because its result is actually wrong, and not even marginally convincing.
The view of the bullet is obviously orthographic: a "side view." Therefore, drawn correctly (or at least convincingly), the circular centerlines of all of the rows of dimple dots would appear not as curves, but as straight lines; not just in the cylindrical portion of the bullet, but in its dome as well. (Think of latitude lines on a globe when viewed the globe is oriented such that its equator is viewed "edge on.")
In all of the rows, the dimples (and the spacing between them) would increasingly narrow in width as they progress toward either side. But in the warp result, they are of uniform width and are even wider than they are tall. In the dome portion, each dimple ellipse would also increasingly rotate depending on its elevation toward the top of the dome.
I'm not insulting Poptoogi's drawing here; I'm just making my point about feature requests. The video used to exemplify the "critical need" is an example of the classic "golf ball" projection problem:

Even Illustrator's 3D Effect feature cannot correctly map that texture to the half-sphere portion of the bullet, because 3D Effect's mapping onto a sphere always "pinches" the mapped artwork at the poles. But it gets worse: Even Illustrator's explicitly-named "fisheye" envelope also fails for this kind of commonly-needed distortion, resulting in a "squarish" distortion.
That's not because automation of such a distortion is impossible in a 2D program; I've automated it myself by use of simple 2D geometry in an AI JavaScript:

(This is not an envelope distortion, but an entirely different approach toward achieving more exactly and correctly what has been posited as an example of why envelope distortion is so "fundamentally" needed.)
I dare say if the functionality of that JavaScript were enhanced a little bit and implemented with a nice interface in a mainstream drawing program, it could end up being called the most "fundamental, basic, must-have deal-breaker preventing my being able to do anything with [any other program]."
That's all I'm saying: Set your goal higher than Illustrator. And be willing to wait for it. Because if you're not, we'll just end up with "me, too" functionality.
New-from-the-ground-up Affinity is the kind of opportunity that doesn't come along very often. Let's not squander it by demanding the mediocrity of Adobe Illustrator.
JET

Practically everyone couches their pet feature desire in terms of the "most fundamental, basic, must-have deal-breaker preventing my being able to do anything with Affinity," and "the one and only thing preventing my ceasing paying Adobe's extortion fees."
And I still say that emulating Illustrator is the last thing I want to see. I don't want "me, too"; I want better. No matter how long it takes.
The video of using an envelope distortion in Illustrator  to apply a dimple texture to a bullet is a case-in-point, because its result is actually wrong, and not even marginally convincing.
The view of the bullet is obviously orthographic: a "side view." Therefore, drawn correctly (or at least convincingly), the circular centerlines of all of the rows of dimple dots would appear not as curves, but as straight lines; not just in the cylindrical portion of the bullet, but in its dome as well. (Think of latitude lines on a globe when viewed the globe is oriented such that its equator is viewed "edge on.")
In all of the rows, the dimples (and the spacing between them) would increasingly narrow in width as they progress toward either side. But in the warp result, they are of uniform width and are even wider than they are tall. In the dome portion, each dimple ellipse would also increasingly rotate depending on its elevation toward the top of the dome.
I'm not insulting Poptoogi's drawing here; I'm just making my point about feature requests. The video used to exemplify the "critical need" is an example of the classic "golf ball" projection problem:

Even Illustrator's 3D Effect feature cannot correctly map that texture to the half-sphere portion of the bullet, because 3D Effect's mapping onto a sphere always "pinches" the mapped artwork at the poles. But it gets worse: Even Illustrator's explicitly-named "fisheye" envelope also fails for this kind of commonly-needed distortion, resulting in a "squarish" distortion.
That's not because automation of such a distortion is impossible in a 2D program; I've automated it myself by use of simple 2D geometry in an AI JavaScript:

(This is not an envelope distortion, but an entirely different approach toward achieving more exactly and correctly what has been posited as an example of why envelope distortion is so "fundamentally" needed.)
I dare say if the functionality of that JavaScript were enhanced a little bit and implemented with a nice interface in a mainstream drawing program, it could end up being called the most "fundamental, basic, must-have deal-breaker preventing my being able to do anything with [any other program]."
That's all I'm saying: Set your goal higher than Illustrator. And be willing to wait for it. Because if you're not, we'll just end up with "me, too" functionality.
New-from-the-ground-up Affinity is the kind of opportunity that doesn't come along very often. Let's not squander it by demanding the mediocrity of Adobe Illustrator.
JET

Practically everyone couches their pet feature desire in terms of the "most fundamental, basic, must-have deal-breaker preventing my being able to do anything with Affinity," and "the one and only thing preventing my ceasing paying Adobe's extortion fees."
And I still say that emulating Illustrator is the last thing I want to see. I don't want "me, too"; I want better. No matter how long it takes.
The video of using an envelope distortion in Illustrator  to apply a dimple texture to a bullet is a case-in-point, because its result is actually wrong, and not even marginally convincing.
The view of the bullet is obviously orthographic: a "side view." Therefore, drawn correctly (or at least convincingly), the circular centerlines of all of the rows of dimple dots would appear not as curves, but as straight lines; not just in the cylindrical portion of the bullet, but in its dome as well. (Think of latitude lines on a globe when viewed the globe is oriented such that its equator is viewed "edge on.")
In all of the rows, the dimples (and the spacing between them) would increasingly narrow in width as they progress toward either side. But in the warp result, they are of uniform width and are even wider than they are tall. In the dome portion, each dimple ellipse would also increasingly rotate depending on its elevation toward the top of the dome.
I'm not insulting Poptoogi's drawing here; I'm just making my point about feature requests. The video used to exemplify the "critical need" is an example of the classic "golf ball" projection problem:

Even Illustrator's 3D Effect feature cannot correctly map that texture to the half-sphere portion of the bullet, because 3D Effect's mapping onto a sphere always "pinches" the mapped artwork at the poles. But it gets worse: Even Illustrator's explicitly-named "fisheye" envelope also fails for this kind of commonly-needed distortion, resulting in a "squarish" distortion.
That's not because automation of such a distortion is impossible in a 2D program; I've automated it myself by use of simple 2D geometry in an AI JavaScript:

(This is not an envelope distortion, but an entirely different approach toward achieving more exactly and correctly what has been posited as an example of why envelope distortion is so "fundamentally" needed.)
I dare say if the functionality of that JavaScript were enhanced a little bit and implemented with a nice interface in a mainstream drawing program, it could end up being called the most "fundamental, basic, must-have deal-breaker preventing my being able to do anything with [any other program]."
That's all I'm saying: Set your goal higher than Illustrator. And be willing to wait for it. Because if you're not, we'll just end up with "me, too" functionality.
New-from-the-ground-up Affinity is the kind of opportunity that doesn't come along very often. Let's not squander it by demanding the mediocrity of Adobe Illustrator.
JET