Sneak peeks for 1.7

[TextusGames]

Handle constrains.

 

Then you are manipulating node's handle and holding shift why not constrain handle angle to 0, 45, 90 e. c. degrees(in screen space coordinate) and also the original angle (angle before click and drag of handle)? Distance to mouse cursor will still change handle length.
It seems natural because then you are using any other tools and press shift it constrains to 0, 45, 90 degrees.

 

And that seems like there is no current way to constrain (or snap)  to 0, 45, 90 degrees for nodes handles. Is there a way?

[MEB]

6 minutes ago, TextusGames said:

And that seems like there is no current way to constrain (or snap)  to 0, 45, 90 degrees for nodes handles. Is there a way?

 

Hi TextusGames,

Welcome to Affinity Forums

No, currently there's no way.

[rubs]

Ben, thanks for the great news and the videos! While you are at it, perhaps you should also consider adding more snapping options to the control points of geometric shapes. These seem to snap only to the shape itself, but not to external objects. For example, the hole radius in a donut shape does snap to 1/4, 1/2 and 3/4 of the donut radius, but there seems to be no way to snap it to an another object. Or is it?

 

Thanks again for the exciting news.

[rubs]

On 12/03/2018 at 8:07 AM, Ben said:

The naming of rotations is a case in point - you can call it XYZ, Yaw-Pitch-Roll, Azimuth-Elevation, etc, etc.  Also, the naming of axes.  Is Z up, or Y up?  And do you use a left-handed or right-handed coordinate system?

 

 

I believe the two questions relative to the axes could be left to the user to decide. Ideally we'd have configurable settings for those. Just my .02.

[Ben]

21 hours ago, MEB said:

 

Hi TextusGames,

Welcome to Affinity Forums

No, currently there's no way.

 

But there will be in 1.7.  Already done.

 

[chris.bannu]

Thank you for a wonderful product that keeps getting better and better.

[graphxlord]

Hey Love all the communication between users and developers, certainly a winning business model in my book, unlike Adobe. I read in a much older forum about a vector tracing tool that was in development back in 2014. I was unable to see anything more about it, what ever happened to that I do I actually have it and just don't know it, LOL. I just bought AD yesterday so forgive me if I am a bit behind but reading in the forums is certainly inspirational :-) Thank You! 

 

[MEB]

I graphxlord,

Welcome to Affinity Forums

You probably saw a thread requesting a tracing tool. There's quite a few ones around - it's one of the most requested features - but all we said was that it would be implemented if the dev teams were happy with the quality of its output. In any case this is NOT on the roadmap for the current 1.x cycle of the app, so in case it's implemented it will still take some time until available. Meanwhile there's several third party apps you can use to trace images which you can then import to Affinity Designer. Here's some:

- Inkscape (open source), 

- Super Vectorizer 2

- Vector Magic

[Mithferion]

9 minutes ago, MEB said:

I graphxlord,

Welcome to Affinity Forums

You probably saw a thread requesting a tracing tool. There's quite a few ones around - it's one of the most requested features - but all we said was that it would be implemented if the dev teams were happy with the quality of its output. In any case this is NOT on the roadmap for the current 1.x cycle of the app, so in case it's implemented it will still take some time until available. Meanwhile there's several third party apps you can use to trace images which you can then import to Affinity Designer. Here's some:

- Inkscape (open source), 

- Super Vectorizer 2

- Vector Magic

So, that feature is not the same as "Convert Pixel selection to Vector shape"?

Thanks in advance.

Best regards!

[Alfred]

31 minutes ago, Mithferion said:

So, that feature is not the same as "Convert Pixel selection to Vector shape"?

 

No, it's not the same at all! A tracing tool would find all the shape boundaries in a bitmap image and create closed curves to mark those boundaries. The 'Convert Pixel selection to Vector shape' feature will simply take a "marching ants" selection and create a vector shape to match.

 

[Mithferion]

Ahhh, I see. Thanks for clarifying!

[TextusGames]

Hello Again

 

After using your program for some time I can say that it is really the best one i have tried. I liked it and want to work in it.

(I am using trial version of affinity designer on windows 10 with high dpi monitor and windows scale set to 200% with largest tool handles option)

 

But one and only thing still really frustrates me - I just can't reliably manipulate handles by node tool and  it kind of ruins everething. 

Then i am trying to click on node or node's handle i have to precisely move mouse cursor inside it's visual representation overvise i misclick.

Grabbing area is just too small and in fact it is even less then its visual representation(if you try to grab square node you need to move mouse slightly inside it). That should not be this thay.

 

Then i am using move tool or crop tool i can reliably grab handles of baundry box with ease, because the  grabbing area is much more bigger ( almost 3 times larger) and therefore you can grab it even then mouse cursor is some pixels away from visual representation and it makes me happy . This is convinient and should be default behaviour  for  node tool too. (Other programs like  Moho, Illustrator, Spine use this approach).

 

I still suggest to add GrabbingScreenTolerance parameter to define grabbing area. But if you make node tool to grab nodes as easy as move tool does that will be good enough. You can also highlight node or handle in order to better distinguish which one will be grabbed.(Illustrator does this way, it is useful then multiple nodes are close to each other and then handles are close to node)

 

Look how easy it is to select by  move tool in oppose to node tool.

 

 

Here is important question.

Is this intended to be that way or this is a bug?

 

 

[Mithferion]

What about a configuration to make them bigger as desired? That way the clickable area will be more accesible.

[UPDATE] This is already possible... shame on me.

Best regards!

[Ben]

It's not a bug - it's just an inconsistency, but not necessarily an overlooked one.  The two tools in question have fundamental differences - the Move tool will only ever show the nine handles for the selection box, whereas the Node tool could end up displaying hundreds of handles.   So, the hit tolerances have largely been arrived at as a result of trying to balance this.

 

You should also take note that the Move tool has special nested handles.  The handle you were picking up at 16 pixels is used for rotation.  If you move a little closer to the centre, you'll notice that the cursor changes and it provides scaling instead.  The scaling handle size is closer to the size of the Node tool handles (so more consistent with our standard handle sizes).

 

The various tools have their own hit testing code for various components. There is the preference for Tool Handle sizes which acts as a scaling to the standard size handle for each tool, but each tool will not necessarily have the same standard size handles.  There is probably room for us to revisit how this all works, and standardise it better across all tools.  I've been working on a lot of tool changes for 1.7, and there could be room to deal with it as part of these changes.

[TextusGames]

2 hours ago, Ben said:

It's not a bug - it's just an inconsistency, but not necessarily an overlooked one.  The two tools in question have fundamental differences - the Move tool will only ever show the nine handles for the selection box, whereas the Node tool could end up displaying hundreds of handles.   So, the hit tolerances have largely been arrived at as a result of trying to balance this.

 

You should also take note that the Move tool has special nested handles.  The handle you were picking up at 16 pixels is used for rotation.  If you move a little closer to the centre, you'll notice that the cursor changes and it provides scaling instead.  The scaling handle size is closer to the size of the Node tool handles (so more consistent with our standard handle sizes).

 

The various tools have their own hit testing code for various components. There is the preference for Tool Handle sizes which acts as a scaling to the standard size handle for each tool, but each tool will not necessarily have the same standard size handles.  There is probably room for us to revisit how this all works, and standardise it better across all tools.  I've been working on a lot of tool changes for 1.7, and there could be room to deal with it as part of these changes.

 

 Thank you for answer and for amasing programm.

 

As for node tool it is not critical how much control handles it has at same time,  if several candidates are in hit radious from cursor program should just pick closest one (if they have same distane pick last created/iterated ). Node that will be picked after click could be also made highlited (outlined).

 

If tool has big picking radious

you always have an option to zoom in and pick the right one even more easely. In oppose if tool has small picking radious it is not an option, and there is no way to more conviniently pick handles.

 

Increasing tools handles vizual size only just for makeing it more pickupable can produce visiual cluttering, the situation then you have many nodes and they are too large and intersects each other.

That is why i believe the visal size of a node  and  its picking area should be adjusted separtly via two multipliers - NodeVisualSizeScale and NodePickingRadiousScale.

This will allow to have not large visual nodes and ability to easely pick them at the same time.

 

I am using largest tool handle size preference and still can't relaiably click on node,s handles, almost every fouth click is a misclick.

 

Please find a time to improve convinience of picking nodes by node tool In 1.7, becouse you already  improve base tools in that release.

 

At least give two more options for 

Tool handle size preferene:

Smallest

Small

Normal

Large

Largest

Massive

Gigantic

But please make them really big, i dont mind nodes to be large as long as it allows me to conviniently pick them.

 

I hope you will find a time, thank you in advance and best regards.

 

[EricGD]

What sort of improvements are being made for the vector crop tool? I'm hoping it would be possible to treat the cropping box like a shape, with the ability to change it's rotation, shape, curve, etc...

[Move Along People]

-

[Move Along People]

-

[Alfred]

48 minutes ago, haakoo said:

In layers-tab : Drag your shape/curve to your image until you see a small vertical blue line next to the thumbnail of your image,drop it

 

If you drag the shape to the thumbnail of the image, you should immediately see the vertical thick blue line.

 

48 minutes ago, haakoo said:

Now the image is clipped by this shape/curve and you can adjust this shape/curve however you see fit.

 

Or rather, the image is cropped to the shape. When an object is clipped by a shape, the parts of the clipping object which are outside the clipped object remain visible; when an object is cropped to a shape, the cropping object becomes completely invisible.

 

[Alfred]

4 minutes ago, haakoo said:

Why aren't there designated options for the clipping feature?

 

Good question, Hans! We can ‘Mask to Below’ to effect a crop, but there’s no equivalent for clipping. In Serif DrawPlus there is a button with a dropdown list attached, so the user can choose between ‘Crop to Top/Bottom Object’ or ‘Clip to Top/Bottom Object’.

[Move Along People]

-

[Move Along People]

-

[Alfred]

4 minutes ago, haakoo said:

In another vector program the back object is a clip to the upper objects.

 

That’s what you get with the option ‘Clip to Bottom Object’ in DrawPlus. The crucial point is that parts of the ‘clipview’ object (which I believe is the term used in CorelDraw) remain visible outside the object(s) that it clips.

 

3 minutes ago, haakoo said:

As for the buttons and/or options for clipping or cropping to bottom/top objects,

isn't this a main feature as you can make nondestructive edits to what you want?

At least in designer where vector clipping is essential it should be present

 

I think buttons might make things easier in many cases.

[Move Along People]

-

[JET_Affinity]

Ben,

I apologize again for the length. I just want to be clear and thorough at the sacrifice of brevity, for the benefit of other interested forum participants.

Quote

 …the naming of your axes…

My convention for XYZ labels of the iso axes is not entirely arbitrary. I simply label the vertical axis Y and the rightward axis X just to be generally consistent with the page rulers in 2D drawing and page assembly programs. This is also in keeping with the Cartesian orientation of the two scales attached to a drafting machine head. So that simply leaves the Z label for the leftward axis.

But various programs (both 2D and 3D) do it differently, and it's not really onerous to adapt. Regardless of the specific orientation, I much prefer a straightforward X, Y, Z labeling as opposed to ambiguous terms sometimes used ostensibly in the name of "intuition" (Left, Right, Top; Front, Side, Top, etc.), even for general illustration.

Quote

The example you've given suggests to me that there are two parts to the rotation…the presentation transform (for example, the rotations that produce the standard Isometric grid)…that appears to be a constant for your whole design…and then there is the rotation of a component in the design relative to your logical coordinate system.

Yes. A complete solution needs to provide for two general rotational tasks. More simply put: establishing the coordinate system itself and "off-axis" rotations of object edges which are not parallel to the coordinate system.

If you provide for that much, you have at least simulated the process of drawing isometrically "on the board" in pre-computer days.

Off-axis rotation, however, includes two commonly needed situations, which I differentiate as "simple" versus "compound."

What I favor (and what you have already demonstrated in your last movie file) is a third capability which can actually make drawing "isometrically" in software radically more powerful than drawing on the board: The ability to re-orient the coordinate system on-the-fly. The point of this is that the coordinate system should not have to be, as you say, "a constant for your whole design."

So the operations needed for a complete solution are  fourfold:

• Initial Setup of the Axonometric Coordinate System
• Piecewise Simple Off-Axis Rotation (within the current coordinate system)
• Piecewise Compound Off-Axis Rotation (within the current coordinate system)
• Re-Orientation of the Coordinate System for major sections of the drawing

Those four operations can be thought of as corresponding to "stages" or "levels" of supportive functionality as far as current 2D drawing software goes. (They can actually be performed in any mainstream 2D Bezier-based drawing system if the user is well-versed in the principles, but they are seldom and weakly overtly or expressly supported (if at all) in most programs:

Stage 1. Providing Axo Grids: As already in Designer 1.6. This is significantly less functional than DrawPlus. But because the feature can automatically generate correct orthographic proportion between three perpendicular planes, even this is at least far better than:

• Programs that merely provide rectangular page grids (e.g., Adobe Illustrator)
• Programs that merely provide a "faux isometric" 2:1 aspect-ratio grid (e.g., Xara Designer Pro)
• Programs that merely provide a basic isometric grid (e.g., Inkscape)

Giving this a cube interface as in your last screen recording makes it more intuitive and "friendly" for any other general illustration purposes. But if the main point of my previous post (rotating about each axis) were implemented, just a few thoughtfully selected pre-defined defaults which can be selected from a menu (or even a set of icons) would be plenty for a starting point. A selection something like:

• Iso Bird's Eye
• Iso Worm's Eye
• Dimetric Top Favoring
• Dimetric Bottom Favoring
• Dimetric Sides Favoring
• Trimetric Top Favoring
• Trimetric Bottom Favoring
• Trimetric Left Side Favoring
• Trimetric Right Side Favoring

That is would be not at all limiting because even at the beginning of a drawing, nothing would prevent the illustrator from "fine tuning" any of those orientations by incrementally rotating the proxy cube about any of its the three axes.

Stage 2. Providing Interactive Off-Axis Simple Rotation: This was demonstrated by your rotating star video clip. This moves toward the functionality of DrawPlus, which otherwise in the realm of mainstream 2D Bezier-based drawing programs (at least to my knowledge) is only provided in much more expensive Corel Technical Designer. (I assume TechDesigner's Projected Axes feature could be fairly easily added to Draw, and should have been long ago.)

At first blush, (as evidenced early-on in this thread), this "live connection" between a piece of the artwork and one of the grid-defined "planes" appears to just be all about merely putting flat artwork onto the three perpendicular planes of a box (which, unfortunately, is all that some think isometric drawing is).

While that's certainly a great and useful feature for illustration in general, its greater implication for axonometric drawing is more subtle: To an isometric illustrator, it's not just about rotation on one of the planes. It also constitutes the most basic use of an elliptical protractor; finding correctly angled and scaled rotation about the axis which is not even on that plane.

Now, in truth, just the Pie option of Affinity's Ellipse Tool alone effectively constitutes a serviceable elliptical protractor if one knows how to use it as such. And by the same token, it's also fairly trivial to effectively "project" (distort) artwork drawn "in the flat" onto any axonometric plane by means of a "manual" rotation and scale transformation. But the "live" (interactive) aspect, of course, makes such things quicker and more intuitive, and adjustable, as software should. (Suppose, for example, you need to construct a set of wheel spokes or a radiator fan in correct geometry relative to your axis setup.)

Stage 3. Providing Interactive Off-Axis Compound Rotation: This is not provided by your rotating star video clip. When drawing "on the board," that unassuming little piece of plastic called an isometric protractor was not just used for finding drawn lengths and angles rotated about a single axis. It also serves (albeit in two steps) to construct compound rotations—rotations about two axes—which, as you noted, can define any rotation in 3D space.

An isometric protractor template goes even beyond that. A good one has printed along its major diameter an odd-looking, rather esoteric scale which provides something else very commonly needed in conjunction with off-axis compound rotations:  the correct "angle" (aspect ratio) of an ellipse which is "pierced" by the off-axis line.

This (so far) is the "stage" of functionality missing in the peeks at the developing interface. Stage 2 and Stage 3 combined correspond to what you referred to as "the rotation of a component in the design relative to your logical coordinate system" and what I refer to as "compound off-axis rotation." It corresponds to the purpose of the "Unit Sphere" in the mockup I sent you and of my Flash-based tool; an interactive "spherical protractor":

Stage 4. Providing for On-The-Fly Reorientation of the Coordinate System.  This is what your last movie file demonstrates. Its interface treatment, however, is the element about which I have the greatest misgivings so far, because a more intuitve treatment of this would make available and immediately intuitive a concept widely misunderstood by begining and experienced axonometric illustrators alike: The fact that isometric, dimetric, and trimetric are not three arbitrarily "disconnected" conventions. When done right, they are in fact entirely geometrically compatible and can therefore be used to advantage even within the same drawing.

This (given the main edit I suggested in my previous post) is what would really take the solution far beyond competing attempts. But thinking of it as "a constant for your whole design" is a step backward. Completely re-orienting the whole coordinate system for every single piecewise off-axis roation (stages 2 and 3) would be tediously cumbersome. But doing it for significant contiguous portions of the whole drawing (as in my motorcycle example) would be hugely advantageous.

Quote

I don't know - what do you think?  I know how I'd want to visualise it, but that might not be the same as you?

Provision for what I've described as Stage 3 and a modification of Stage 4 would put this feature set in a class of its own, far ahead of any of the half-baked piecemeal features provided in any of the mainstream 2D drawing progams. One way to do that might be:

To Provide Stage 3 Functionality: Provide a Unit Sphere widget or tool. This would basically consists of the functional equivalent to three "Pie" ellipses (and a little bit of on-screen "cues" for interactivity and intuitiveness) which, when invoked, appears at the cursor location (if a tool), or on the page (if a widget, perhaps stored as one of the default Smart Shapes objects). In either case, it conforms to the current grids orientation (if any) when it appears. Otherwise it appears in isometric orientation.

Referring roughly (at least in principle) to my screenshot above, a handle circle would appear at the intersection of, say, the X axis and the "equator" ellipse. Its movement is constrained along the ellipses it encounters, and is followed by a "ghost" ellipse guide (the grey ellipse in my image) indicating the current "latitude," which also serves as a drag guide. Cursor readouts (two values) appear during the drag, indicating rotation about the constraining horizontal ellipse (i.e., "longitudinal" angle) and about the constraining vertical ellipse (i.e., "latitudinal" angle). Throughout the process, a radius line between the sphere's center and the cursor is displayed, along with an ellipse which is "pierced" by the radius. On mouseup, that radius becomes a normal single-segment path, and its "thrust ellipse" becomes a normal Pie Ellipse. A prompt appears in which to enter the true-measure length of the radius (and major diameter of the thrust ellipse).

To Improve Stage 4 Functionality: This would be just as explained in my previous post: Modify the interface so as to provide interactive and numeric rotation of the proxy cube about each of the three axes, instead of about just one axis and a "pitch" thumbwheel" as in your movie file.

Something I did not make clear in my previous post is that I would not expect re-orienting the overall gridset (the cube) to have to be so elaborate as to maintain object-specific "links" to the planes of the previous original cube orientation. That is, once I reached the steering stem in the motorcycle example, and decided to re-orient the axonometric coordinate system to more directly assist in construction of the front assembly, I would consider it fine if previously drawn objects were to become "flattened" regarding their "live" connection to the previous coordinate system. Again, the concept I'm trying to convey is that changing the overall coordinate system would be powerfully useful. But it should be used to facilitate drawing significant areas of the drawing, not to perform each and every piecewise rotation (which are typically many in real-world use). I'm not expecting this to act like 3D modeling, but like the long-established discipline of 2D axonometric drawing which is all about referencing the axes, for not just linear measures but rotations also; and not about freely twirling a "virtual trackball."

Something functionally equivalent to this approach would be vastly more intuitive in real-world use than having to mentally "step back" and imagine what combination of rotation about Y and overall elevation (values from two different manipulation metaphors) are needed to, for example, "Rotate the toy tank's muzzle 15 degrees about X and then rotate it and the turret 65 degrees about Y." Those are the terms in which the illustrator is thinking when drawing axonometrically. He is not thinking in terms of tilting and rotating the whole coordinate system for every piecewise off-axis rotation.

I'd like to suggest a detail modifications to the cube-based interface:

Unless it represents some other not yet explained functionality, I don't really see the value of the smaller inner cube. I would much rather see an ellipse displayed on each face of the large cube. One of the most common errors in axonometric illustration is disproportion between ellipses and axial measures. Without going into more detail here, It has to do with the issue that was commonly (and awkwardly) described as "isometric drawing" as opposed to "isometric projection." The error is just as easy to commit in software as it is on the board (if not more so).

Again, thanks for your work and attention to detail (and patience), and sorry for the length.

JET