Jump to content

wigglepixel

Members
  • Content Count

    230
  • Joined

  • Last visited

About wigglepixel

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    https://www.wigglepixel.nl

Profile Information

  • Gender
    Male
  • Location
    : Utrecht, The Netherlands

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Great work @Renzatic. Love this style! Both the vectorwork done in Designer for the labels/textures as well as the Blender scenes. Artistic and still cartoony, great mix!
  2. @Sean P thanks for the quick response. When I try it now, when opening an ai-file and cancelling the import, I see the issue again. On the files I test it now I don't see the same issue when not canceling during import, but I'm pretty shure I didn't cancel import before while having the same issue. I'll keep an eye on it as I can't replicate the same issue without cancelling the import at this moment.
  3. Windows shows some thumbnails of Designer files razor sharp and others, with exact same dimensions and dpi, and even exact same files but re-saved, blurry. Looking at the thumbnails below, the left one is the thumbnail of an exising afdesign file. The right one is the exact same file, but opened in Affinity Designer 1.8.5.703 and saved to another name. So for some reason newly saved afdesign-files get a very blurry icon while older files have perfectly sharp icons. I include the original afdesign-file as an attachment. buffer.afdesign
  4. After closing files that were opened in Designer they are still locked by Designer in Windows making it impossible to remove or rename them. Only after closing Affinity itself the files are unlocked. I'm pretty sure this wasn't an issue in previous versions of the program.
  5. Yes! Part 5 just went live. The era of Pixar, the beginning of mayor software packages, moving forward towards interactives and animations on the internet! 😎 Now that the second wave of the pandemic had arrived, we better have something interesting and full of content to read as well! Enjoy it everybody, hope you have as much fun reading as I had researching, writing and illustrating it! After this part there will be only one more part (part 6) to complete this series I've been working on since 2017 with preperation, research, organising, reading, illustrating, writing etc.! Collect them all 😉 Thanks a lot everybody for liking and (positively) commenting on previous parts! It motivates me to keep on writing quality blogs! English: The History of Interactive Computer Graphics - Part 5 Dutch: De Geschiedenis van Interactieve Computergraphics - Deel 5 @Alfred @Madame @Roger C @Wosven @GarryP @A_B_C @WatcherMagic @John Rostron @Renzatic @dutchshader @CLC @SrPx @haakoo @telemax
  6. 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. 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.
  7. This bug still isn't solved in 1.8.5. As written above Expand Stroke only works when stroke alignment is set to the center. It's not working when alignment is set to in- or outside. Could this get some attention by Affinity to fix this?
  8. [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. subtract-works-when-all-paths-are-in-alternate.m4v workaround 1 (when in 'winding' mode): reversing direction of 'non-subtracting' paths before subtract: boolean-subtract-works-when-same-direction.m4v
  9. 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) boolean-subtract-not-working-anymore.mp4
  10. As title says; see video below. Example in the video is a new document. resizing-doesn't work.mp4
  11. Very busy writing part 5 inbetween other (commercial) projects. Trying to fit the last mayor developments in the history of interactive computer graphics into the last two blog-articles now! As a small flash back in the mean time on the previous part with an item about inverse kinematics, as I just recorded new demo-videos of some interactives on touch screens: There really is no better way in experiencing the difference between Forward Kinematics and Inverse Kinematics than with an interactive on a touch screen! 😀 Stay tuned and watch this space. Part 5 will be pretty interesting too and things were more and more moving towards and centralizing on the web during that period of time! 😎 kinematics-comparison-1920x1080-24fps.mp4
  12. I agree. It's frustrating. As a professional I bought a Surface to do graphical work with a graphical pen as it is made for that, but it's just impossible to use Affinity products without a keyboard. I even needed to buy a seperate bluetooth keyboard just because when using a Surface in tablet-mode the keyboard cannot be used and Affinity can't without. Like you I have the strong feeling for a long time Affinity is not taking professionals working on Windows seriously neither, even though last 20 to longer years it's no longer only Mac that's ruling the graphical/web industry and a lot of companies use Windows for a long time now. The time that everything was only Mac for graphical work was in the 80s and 90s. We're in 2020 now.
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.