Vincent

codeberg.orgvincentOpen-source digital art and image editing software project, built with Godot

Welcome to the Vincent Devlog! Here, I'll be sharing my design thought process and showcasing various updates on my way to (maybe) finally finishing one of my many personal projects. Feel free to join me on my journey! codeberg.org/sharkaccino/...

codeberg.orgvincentOpen-source digital art and image editing software project, built with Godot

ok the migration was surprisingly painless! still gotta fix a handful of things, but still. assuming nothing else goes wrong, the vincent project will now live at codeberg.org/sharkaccino/.... i'll update the link on my profile soon

Vincent@vincentproject.bsky.social

god i am so sick of github, man. i think im gonna finally move everything over to codeberg

everything is fine, nothing to see here

ok seriously am i just unbelievably stupid or is there really no better way of testing these things. this legitimately took like 3 hours

god i am so sick of github, man. i think im gonna finally move everything over to codeberg

kicking myself bc last time i had this project open i had like 40 billion changes and i dont remember what any of them were. why didnt i commit anything. what was i thinking 😭

btw random thing, but i was thinking it might be fun to do some kind of dev livestream! would anyone be interested in that?

hi i'm not dead ✨ (yet) trying to ease myself back into the saddle once again by starting with a small but important optimization tool: canvas visibility! #godot #godotengine #dev

this is still a WIP, but the goal is to generate a Rect2 that encompasses the entire visible portion of the canvas within the editor viewport, relative to said canvas, with rotation included.

there's a lot of annoying math involved here, and i kiiiiinda cheated by using godot's global_position property on a hidden control that keeps the size and position of the viewport while being a child of the canvas node. but it should work!

3 Sept

hey folks :) sorry for the total radio silence for the past month, i had to take a lil mental break. there's a LOT of moving parts in this project and it gets pretty overwhelming for me as a solo dev.

3 Sept

but! i've recently had some ideas on how to approach a few problems i was facing the last time i was working here, and i'm hoping i can return soon :) i'll explain more on that later cus it's like 1 AM here and im posting this from my phone in bed lmao

just realized the video doesn't actually show off the new chunk creation thing lol here's a quick demonstration that just fills the entire chunk with a white bg when drawn in

Vincent@vincentproject.bsky.social

been quietly doing a bit of technical work the past few days Vincent will no longer create and render canvas chunks that are already known to be completely invisible. instead, they're created on the fly as needed.

View full thread

increasing the chunk size can help with this, but that itself comes at the cost of longer delays when baking a brush stroke, depending on how many chunks were affected.

there's a *lot* of moving parts that determine how well this app runs now and it's getting a little scary LOL

the main goal here was preliminary work towards layer support, as creating tons of empty chunk textures for every single layer would be *incredibly* wasteful for VRAM.

there are some significant performance implications with this, however. assuming you're drawing on a blank canvas, huge brush sizes (1000px or more) will inevitably require more chunks to be generated all at once, which can lead to massive lag spikes.

funny thing i just realized to use hex color codes, i just take the current text and pipe it directly into Godot's Color.from_string() method. while this does accept hex codes, i didn't realize it also accepts *named* colors. so doing something like this is considered completely valid input LOL

this was *not* intentional, but honestly that's a pretty damn cool feature to have. and hell, it's not breaking anything, so why not keep it ✨

docs.godotengine.orgColorA color represented in RGBA format. Description: A color represented in RGBA format by a red ( r), green ( g), blue ( b), and alpha ( a) component. Each component is a 32-bit floating-point value, ...

here's the full list of named colors if anyone's curious: docs.godotengine.org/en/stable/cl...

i decided to rearrange a bunch of things in this panel. kinda realized it felt really cramped, especially if you were using the minimum sidebar width. also dont need to switch modes to tweak the alpha channel anymore 🙌

Vincent@vincentproject.bsky.social

*very* work-in-progress sneak peek at the colors panel :)

27 July

man. as unfinished as this is, it's so satisfying seeing just how far Vincent has come. there's still a lot to do, but i'm incredibly proud of what i have already. :)

27 July

the actual update here is that the paintbrush and pencil tools now use the global primary color as defined by the new colors panel. that's basically it, though.

27 July

unfortunately, i probably wont have anything more interesting for today cus i got a lot of IRL responsibilities to take care of. sorry :(

26 July

jackie's slow descent into misery perfectly documented by screen recordings

26 July

color sliders are working!! #dev #godot #godotengine

Vincent@vincentproject.bsky.social

*very* work-in-progress sneak peek at the colors panel :)

26 July

this was absolute hell to set up btw LOL, especially the HSL sliders. god i'm glad that's done with

ohhh here's a fun thing i don't think i've shown off publicly yet this is some "concept art" of Vincent i made years ago when i was first dreaming up this project!

despite being like 2+ years old, i'm still largely following this blueprint to this day :) many of these ideas have already been implemented too!

*very* work-in-progress sneak peek at the colors panel :)

sooo today i learned a few things: 1. SplitContainers finally have support for more than 2 child nodes 2. this was added in #Godot 4.6 3. there were *ZERO* mentions of this in the release notes. i'm suddenly incredibly glad that i put off the work for tool panels for as long as i did.

alright last update for tonight i threw together some really basic pencil and eraser tools :) #dev #godot #godotengine

i've just been informed that Vincent actually handles massive canvases and brush sizes better than clip studio paint LMAO??? HOW DID I PULL THAT OFF

splitting the canvas into chunks might just be the best thing i've done for this project by far. the performance difference is absolutely *staggering* #dev #godot #godotengine

worth noting the paintbrush tool does lag pretty severely with huge brush sizes (2000px or more), but that's such an extreme edge case that i don't think it's worth pursuing at this point.

*almost* got paintbrush back to working order again. main issue remaining is that it only works in one chunk per movement update, which results in these visible gaps.

there's still a slight delay when ending a brushstroke... but now, instead of it being caused by GPU data transfers, it's actually caused by chunk compilation for the project thumbnail. i think i might be able to do something with create_local_rendering_device(), but we'll see

some extra technical tidbits on canvas chunks for those interested: i'm currently using a chunk size of 256x256, which can be adjusted with relative ease :) i figured the optimal chunk size may vary between different hardware configurations, so i'll be adding it as an advanced option later.

Vincent@vincentproject.bsky.social

currently working on a canvas chunks system to provide significantly better drawing performance. i'm like 90% of the way there, i just need to get the paintbrush tool to correctly interpolate mouse inputs *between* chunks. otherwise you get these wild lines going absolutely everywhere lmao

View full thread

this is another stress test i set up, assigning random colors to every individual pixel while actively drawing within a given chunk. (minor flashing colors warning)

both of these tests were done while i was weighing the idea of moving to CPU-only drawing to improve compatibility. i eventually decided it would've required too many compromises.

Vincent@vincentproject.bsky.social

here's a screenshot from a stress test i set up the other day, with each chunk given it's own random color. with a chunk size of 256 at the max canvas size of 16384x16384, that gives us 4096 chunks.

View full thread

hell, simply being able to create a new image at 16k size was literally impossible, even on my beefy hardware. making a single texture that large would make the whole app segfault pretty much instantly.

now it's easily hitting 8k and barely breaking a sweat :) which means i've finally reached my internal goal!!! all i really gotta do is fix up the paintbrush tool to work with chunks, and then i can finally, FINALLY move on to something else.

the amount of glitch art i get out of working on this project is crazy, man

on a more serious note, if you can look past the glitchy paintbrush, you can probably see how much of an improvement this change already makes. being able to draw with virtually zero hangups at any canvas size over 3000x3000 was pretty much entirely unheard of until now.