PanthenEye

Yearly bump.

Yea, I did that. That's why 0,0 is right where rulers meet, but it does not import into Spine at 0,0.

It's very basic. Transfers single PNG images in correct (EDIT: Actually, it's not correct order, perhaps something with Slice order?) layer order but doesn't retain the Layer blending mode such as Multiply. There's also no way of correctly positioning the art. I want rulers to define the origin: But no such functionality exists and art is offset in Spine since it's placed using the bottom left corner of the document: I can, of course, move the art in Spine in place, but this introduces issues when updating art later via JSON import. And PhotoshopToSpine script can set a custom ruler origin before export. For animation purposes, I need 1-2px alpha whitespace at a minimum, which the PhotoshopToSpine script adds to each individual image exported. In Designer I have to do this by hand manually with export slices. Too much manual work for complex projects, which can easily exceed several dozen slices for a single character. It just doesn't scale. And finally, the built in Spine exporter doesn't support any of the Spine specific features such as defining Skins, defining bones, placing multiple images under the same Spine slot, auto converting images to mesh, exporting into subfolders which spine will export as separate texture atlas, etc. All of this is very Spine specific, so it's not really Affinity's job to cover this. But API should be robust enough to handle all this and it should do so without manually defining export slices. Or if slicing can't be worked around, at least it should be able to automatically define slices per rules defined, such as auto slice only visible groups and add X px alpha white space to each slice.

I just want this to be possible in Designer: https://github.com/EsotericSoftware/spine-scripts/tree/master/photoshop Creating new tools is all swell and good, but I just need a basic export pipeline for Spine 2D animation software, which is the industry standard for 2D animation in video games. The linked script saves literally hours of work and is the single biggest reason I'm still subbed to Adobe. Hopefully, the API will cover things like merging layers, parsing layer names then do operation X if the name contains some string, change exported layer name, add alpha padding to each exported image, trim alpha whitespace, set and read designer document ruler origin, read layer mode, scale layers before exporting and write relevant data to a JSON file, which Spine can then import and rebuild the exact layer order, layer position, layer mode and everything else that's relevant. This should be possible without manually defining export slices, ain't nobody got time for that.

Yearly bumb a bit early this year.

As far as I can tell stroke with control options have not improved from v1. Please add stroke width tool. Some examples:

+1

Looks like the newly released Affinity Designer 2 hasn't improved anything in this regard. Unfortunate.

Yearly bump.

Yearly bump.

Yearly bumb.

Add Stroke Width Control tool to the list. Like an ex-user of the forums once said, using the pressure graph is like driving a car with a calculator.

Yearly bumb, it's been 3 years with no advancements in line width control. Still can't use AD.

I'd like to see that happen too. Since all their revenue only comes from attracting new users, that's where all their development efforts are focused. And hence why long standing, fundamental issues are never addressed - fixing them won't generate new sales so they're forever in the backlog. A change of business model is probably needed like you described, otherwise I can't see AD ever becoming a true professional tool. I bet the refocus on Publisher and slow AD updates is because AD has probably reached a certain degree of market saturation and is not generating the sales it used to. So they create a new product and invest most resources in that until it also ends up in the same situation at which point it'll enter maintenance mode and they'll develop a new product. Is this really better than Adobe? Not for me at least.

I believe the situation we're in is largely caused by Affinity's business model everyone likes to praise. Since the software is a one time purchase for a rather cheap price (when compared to similar commercial software), their revenue is largely dependent on gaining new customers indefinitely. To do that they periodically release new versions that introduce a bunch of big, marketable features at the cost of the ever crumbling and deficient foundation of the software. Once the new features are introduced, they might get some bug fixes later but rarely are they fundamentally improved even if they are effectively unusable in a professional setting. The team then focuses on the next set of big, marketable features or new products to sustain the company. And with every new product their resources grow thinner and thinner. I absolutely hate Adobe's subscription but this is no alternative, never has been and it seems it never will be either. Or devs just like to work on something new and don't care about basic vector features like per node stroke width control. EDIT: Just tried VectorStyler mentioned in this thread. In 30 seconds I found stroke width tool so it's already superior to Affinity Designer in my eyes. This basic tool has been requested in multiple threads here as far 6/7 years ago. Affinity have made 0 improvements in all that time to stroke width control. Pressure graph is as janky as it has always been, creates ugly results and in no way it's even comparable to manual per node stroke width control.

6 years later, stroke width control hasn't improved a single bit.

This has been asked for since 2014. Six years later we still have the tiny, imprecise and often fiddly pressure graph. Previous requests: 1. 2. 3.

I do own CSP but as you've already mentioned, only the line-art is vector based. All the coloring layers are still raster. There are some unorthodox ways of working around that but I don't like the workflow for that. I'd prefer a fully non-destructive vector based workflow. Affinity Designer is really close, I especially like how the clipping masks are so effortless but line width tools are too basic for my use cases. I'll check back next year.

Bumperino. Still looking forward to improvement in this area.

Did I say this was a 3D grid? What I expect from a feature like this is some measure of precision - actual metrics I can use to determine the parameters of the project to get the result I need. Currently, that's simply not possible without considerable extra effort. I have to eyeball it as well as hack around it to get something usable out of it. The workflow generally is really great if it worked as advertised, but the tool's design is imprecise and flawed for anything that is not an illustration. The isometric grid does not match the pixel grid. So if both pixel and grid snapping is enabled I get unexpected, random results all over the place when trying to move shapes with precision. So I can only have one or the other enabled at a time. This should not be the case. If only grid snapping is enabled, after moving the shapes perfectly in place according to the grid there are still subpixel gaps between these shapes which are hard to spot in the editor and only show up at certain zoom levels (such as 900%) but are glaringly obvious once the asset is exported. I counter this by placing a single flat shape as a background gap filler. It's not hard but this should not be necessary. Because the isometric grid does not align with the pixel grid if I export an asset aligned with the isometric grid, it doesn't properly strip all white space giving me an unusable, imprecise asset. I have to disable grid snapping, enable pixel snapping. Add guides and move the asset to fit the pixel grid, so it can properly export the asset with all white space stripped via Export Persona. The workaround is usable but now the asset is not aligned with the grid anymore. None of this should be necessary. The grid size parameter does not relate to the asset in question in any reasonable manner. A 2:1 isometric projection with a grid size parameter of 143.1px was the closest fit I could eyeball for a 256x256px asset which is a common asset size but it's still off. Why can't it simply ask for the height or the width of a single cell so I can actually set up the grid with precision? I can't create the correct grid size I need from the get-go so I have to resort to using the transform panel to resize the asset to the precise dimensions I need which again misaligns the asset from the grid. Great tool for digital only illustration but it sorely lacks precision for anything video game or print related.

I still don't get the grid spacing parameter. Why it's in pixels. Why does 143px grid fit a 256x256px tile?

Ok, so I finally got something usable out of it. A proper 256x256px tile. The solution was to ditch the isometric grid completely, enable back everything related to pixel snapping. Scale up the object to the final dimensions I need via Transform panel. Then add guides for pixel-perfect precision (because the export was still 1px longer for some random reason even though the object was precisely 256x256px). After doing all that it sorta works. So the workflow now is: Create a 2:1 isometric grid. Grid size doesn't matter much since it doesn't reflect the final image size in any way. So do what looks comfortable. Disable pixel snapping, enable grid snapping Create the asset on the isometric grid (note that grid only snapping leaves subpixel gaps between separate planes which are glaringly obvious once the asset is exported. So the background shape needs to be flat and uniform and cover the whole tile to fill these gaps) Disable grid snapping and the grid itself, turn back on pixel snapping Add guides for pixel perfect export Scale your object via Transform window to the tile size you need Export Hope you don't have to do any major asset edits because the grid does not fit the asset anymore

Scratch that, it's all for nothing when it exports this abomination. I can't fathom the point of an isometric grid that doesn't align with the pixel grid. For anything precise this tool is unusable. The general workflow is so nice, I just wish it would be useful for things that require more precision than an illustration. The marketing of this feature said it's useful for games too yet clearly it's not.

I've now spent hours trying to get this thing working. It's so close yet so far. A 1px outline on the brown planes plugs that damn gap between them. But it creates issues with brown corners sticking on top of the green plane. So now the green plane needs a 2px outline to compensate which ruins the regular size of the image and makes it unusable. I can only assume the export persona's final result has a significant difference from what the editor shows me since I can't see any of these issues in the editor. At least not to the extent I'm seeing it in the final export. The outline workaround does not really work: Now I'm experimenting with larger uniform shapes that take the whole space of the tile which kinda works for brown planes. There are still some subpixels between the green and brown planes but they are way less noticeable. Maybe in game, it wouldn't matter. So I guess that's what I'll stick with for now. I still can't get the right size I need for the tile in the editor but that doesn't matter as much as long as the aspect ratio is correct. I can always run a Photoshop script or something to resize all tiles to the exact size I need. And with some trial and error, I could probably get ADs grid to the right size I need via importing the correctly sized tile in the editor first, then adjusting the grid to fit it. All of these "workflows" are really backward though. I wish it just worked out of the box and wouldn't require me hacking this thing for hours to get something usable out of it.

So that subpixel gap does appear at certain zoom levels. But there's nothing I can do about it. No matter how many times I re-snap the planes to the grid, the gap is still there.