Show HN: Graphite, a Blender-inspired 2D procedural design Rust app
graphite.rsFor the past three years I've been building what I hope will be the next Blender, tackling the lack of any good 2D design or image editing tools outside the Adobe monopoly. This was our first year participating in Google Summer of Code and this Q3 update includes the big payoff from that, covering the most progress we've made so far as a project. If you're a Rust dev, consider getting involved as we apply for the next GSoC in the new year— you could be our intern next summer :)
Q3 progress report: https://graphite.rs/blog/graphite-progress-report-q3-2024/
This is amazing. I love Inskcapke but I think this tool is too good.
It makes me very excited to see tools that are built as web apps because more gravity on web means more capabilities for the web platform which is more open and accessible.
Rust is great - amazing. I presume it is compiled to Web Assembly.
I'm just wondering how and why these three passionate gifted individuals didn't go Round A, Round B Investor funding, post valuation SAFE, Press briefing route?
Been thinking a lot about it lately when I see tons of AI wrappers, open weight fine tuned packaged models and everything in between.
Probably passion can't be priced? Happiness is not valuation?
You won't get funding for a vector editor.
Re: open weight models Most of the innovation happens within companies who use OSS to either appeal to developers or to destroy potential competitors (think Meta spending a fraction of its ad revenue just to ruin the market for OpenAI / Microsoft) Some individuals get grants from VCs who want to make a name in AI for themselves for the cost of peanuts (eg. a16z sponsors some models)
At the same time, for wealthy tech people with skills and a well paid job (think 300-500) raising capital is not always an attractive proposition. You'll likely have a lower salary when doing your own startup and if it turns out your open model can't make enough money you'll just have a bunch of worthless equity and 1-2 years of high stress / pressure.
Figma comes to mind. But yes, your rest of the analysis follows on the dot and makes perfect sense.
This looks neat. I’ve been using Illustrator for twenty five years and have been wishing for a node-oriented replacement of the Appearance stack a lot lately. I will have to check it out when you have binaries, I hate web apps.
Is Electron really so different in your experience than a PWA?
Personally, I always try to use a PWA when the app is otherwise offered via Electron.
If it’s going to depend on a browser engine, it may as well be the one I already have open and update regularly.
I’d prefer it to be one that the developers have specifically targeted and developed/tested against, especially if there’s any GPU involvement.
(Looking at the videos: global color swatches please, it’s super powerful to be able to change everything drawn in a color - fills, strokes, effects, etc - with a few clicks.)
I'm eager for that feature too! The node graph engine recently got the ability to represent that concept, so now I just need to find the time to design and build the UI for it. I utilize that feature a lot in other software so it'll be really helpful to have in Graphite as well.
Related. Others?
[Open source Rust graphics editor] Graphite progress report (Q2 2024) - https://news.ycombinator.com/item?id=41138691 - Aug 2024 (3 comments)
Graphite 2D graphics editor built in Rust: Looking back on 2023 and what's next - https://news.ycombinator.com/item?id=38855850 - Jan 2024 (2 comments)
Graphite: 2D Raster and Vector Editor - https://news.ycombinator.com/item?id=38169500 - Nov 2023 (4 comments)
Graphite: Open-source raster and vector 2D graphics editor - https://news.ycombinator.com/item?id=36901406 - July 2023 (64 comments)
Graphite – open-source raster and vector 2D graphics editor written in Rust - https://news.ycombinator.com/item?id=30675530 - March 2022 (18 comments)
I had to re-read your intro paragraph a few times to understand what this is supposed to be.
I read it as a replacement for Blender, but upon testing it I was confused as everything was 2D and looks like Photoshop.
But no, you meant the next Photoshop, while referencing Blender as a popular open source version of closed-source 3D modeling/rendering software? Is that right?
Upon rereading that paragraph, I suppose I didn't write that as clearly as I'd meant to. Blender is darn near perfect and there'd be no reason to replace it. So yes, as you figured out, I'm referring to becoming a second Blender but this time in the 2D realm: a generalist tool that uses actual innovation to catch up and then surpass its commercial competitors.
Graphite is to Photoshop as Blender is to 3DS Max?
Roughly speaking, that's the plan, with next year's roadmap focused on raster (image and raw photo) editing. Currently, Illustrator would be the more appropriate comparison instead of Photoshop, because vector editing is the primary feature set we've built so far.
Reminds me more Affinity Designer than Photoshop. Since it is also for vectors. In Adobe land you need two apps for this. (Well actually three - omnipresent Creative-Cloud eating the resources in background.)
but its not really photoshop either because its targeting vector based graphics, whereas Photoshop is mainly raster-based.
I'm not up on Adobe (I use InkScape which is sort of the default open-source / free alternative) but I guess Adobe Illustrator is the closest analogue here.
Author says raster focus next year, intention to support both and frankly it sounds like great idea.
Congrats on releasing such a complex tool, that's a big achievement.
Someday, I'd like to try my hand at making my own vector graphics tool that contains a constraint solver. I am just an amateur when it comes to graphic design, but I often find Inkscape incredibly difficult to use. Certain shapes take bizarre combinations of commands to create and once a design is finished it can be hard to make adjustments. I find it much easier to make 2D designs as a fusion 360 sketches because constraining a bunch of lines and curves then playing with measurements is significantly more intuitive and interactive. Also maybe a tool like this already exists and I'm just not aware of it.
Definitely! And in fact, that is on our [roadmap](https://graphite.rs/features/#:~:text=CAD%2Dlike%20constrain...). Maybe you could get involved instead of making something separate.
I'm really looking forward to that. It's something I tried to tackle but unfortunately had to give up on.
Awesome! If I ever find the time, I will definitely look into contributing.
Wow this looks fantastic! Good open-source tools for design are so necessary [1].
You should probably add Graphite to this list [2]. I'll definitely try Graphite and follow its progress.
Good luck!
--
1: https://www.youtube.com/watch?v=lthVYUB8JLs
2: https://github.com/KenneyNL/Adobe-Alternatives
Thanks! I'll open it up to the community to suggest Graphite's inclusion in lists like that one but I'll abstain from doing that myself. I should mention that, at the present moment, the only category we'd appropriately fit under is the Illustrator alternatives. Next year we will be building towards raster editing as our next core competency, but vector editing is the only one we've focused on so far.
Really looking forward to having something with decent vector AND raster capabilites. That niche is currently unfilled unless one wants to run an old version of Fireworks in a VM...
I keep reading occasional people talk about Fireworks with a wistful bygone "what could have been" for raster + vector. That's older than my era (although I was old enough to grow up making Flash animations and games) so I never got to know Fireworks, but I do hope to finally build a worthy solution after all this time. The neat part is that, in Graphite, raster content (brushes, patterns, noise, filters, effects, Mandelbrot Set fractals, etc.) is procedurally generated on-the-fly at the current viewing resolution, just like vector content. So they both interact harmoniously in a way no other editor has been able to manage.
Adding to the above, in a way this can also be self hosted and is a candidate for the awesome selfhosted list [1].
1. https://github.com/awesome-selfhosted/awesome-selfhosted
It looks like that list tends more towards home-server self-hosted SaaS kinds of software rather than desktop apps. With our upcoming desktop app, and the fact that you can install it right now as a PWA, there's really no benefit from self-hosting. Your data is already client-side, so there's nothing for the server to do besides act as a CDN and send some tiny static assets. Unless people are going somewhere without internet, there's really no point in self-hosting the static files instead of using our CDN. Since we don't even have a server backend (except for a proxy to the Google Fonts API which we need to keep our API key private).
I (mis?)understood one of the features for 1.0 "Cloud document storage" as some sort of custom storage server, webdav or other remote filesystem support.
If there's no plan for that or if its limited to usual suspects like GDrive, Dropbox etc., then I guess there's not much benefit to selfhosting.
That's all far-future stuff that will let us continue to grow towards our larger ambitions further down the roadmap with a revenue stream that isn't purely dependent upon donations, which isn't sustainable on its own. It will always be a purely separate value-add that's not shoved down the throat of users— a subset of users will find that helpful and pay for the storage and most users won't care and won't be bothered about it. But we don't have any of that yet, and won't for a while.
This is almost exactly the tool I have wanted for a long while.
The one thing is when something is drawn in the interactive UI, rather than becoming a single node which cannot be decomposed/worked with via sub-elements, it should become (or there should be an option for) "ungrouping" it to an equivalent set of nodes/values --- if this capability is present, I couldn't figure it out, and I'd be glad to know of it.
This is incredible. Thank you for this.
The Adobe suite is a bunch of bugs stuck together for the benefit of no one in particular, at this point. Hopefully with time and donations this can disrupt the market as Blender did in 3D.
What a fantastic UX. You guys can really be very proud. Between this and Zed there are already two apps that can replace everyday apps for me.
I wish I could do this kind of Rust code in my day job.
The appeal of Blender for me is not just the open-sourceness, but also the fact that everything in it is programmable. Any action you can do via UI, you can do by calling some Python method.
Why create a new project instead of advancing InkScape though?
Graphite is built to be a programmatic data processing pipeline that takes the form of a render engine and WYSIWYG editor. You'll be able to write custom code for every part of the system.
And because it's time for a fresh start. Sometimes you can't turn around a heavy ship, and that ship doesn't want to be turned around. It's easy to write a sentence like that, but once you actually think about it, how does an outsider with a good idea and a capability to execute on it somehow approach an existing project and decide to "take it over"? That would be neither viable nor would it yield a desirable outcome. We're building something fundamentally different from Inkscape that just so happens to eclipse it.
Absolutely - as with so many large open source projects, the maintainers and community are (rightfully) going to be sceptical of any newcomers.
This leaves only three options:
1. start contributing to the project slowly, try to get into their ranks, participate in conversation, and hope that you share the same vision
2. fork it and learn the codebase by yourself
3. write your own
Out of those, given the obviously conscious choice to go with Rust, and the ambitious goals, the third option is the only one that makes sense.
Exactly! The only thing harder than making something so ambitious would be doing it in a huge legacy codebase with an existing leadership team fighting against someone vying to rock the boat. Being new is an opportunity, not a flaw. It means there's a lot of work to do, but that's tractable with the right organization structure that I think we've successfully managed to build— and it's something other projects really struggle with, so starting fresh in that respect also avoids problems from cultural elements that could very well be the blame for the inadequacies of those existing projects.
So easy, so nice. Beautiful work, really amazing. Congratulations and thank you.
This is the kind of stuff I love to see at the top of HN, that application looks absolutely professional.
When searching for "scripting" on the pages, I don't see any scripting support. Are there plans to integrate it?
Also some kind of API?
Thanks!
No support for custom scripts yet. But the whole concept is that we're basically building a WYSIWYG editor on top of a node-based compositor on top of a visual programming language (so that's three products in one, lots of work ahead for us!). The result is that the whole thing is a programmatic data pipeline and you'll be able to write custom scripts in both node and code form, then compose them into reusable pieces and pipelines. But since we're building three products in one, we have only been able to focus on the parts that matter most to get things working. Your request hasn't yet been one of those, but worry not, that's very much a core feature.
Wow! That's something really useful and awesome. Shame on Adobe while having so much resources not pushing more to build a diverse eco system of creative apps like Graphite
Love it! I've never liked how 2D graphics currently involves so many separate programs and forces you into a feed forward pipeline workflow.
I opened a medium complex SVG and the app became unresponsive beyond useable. After scaling it down by manually entering the scale values I could not find the SVG any more (the Align... buttons in the top bar are always grayed out/not implemented yet, it seems).
Every update (even moving the canvas around takes 1-2 secs on my laptop.
TLDR; looks like this is redrawing everything every time which makes it useable only for very simple projects atm, unless I miss sth. I.e. needs caching of vectors as bitmaps/textures of some sort.
Also doesn't seem to support OpenEXRs yet? They won't show in the file browser.
Screenshots look great and I love the node editor's mapping to the layer stack.
But as always with Graphite it's still unclear to me how many of the screenshots show actual functinality and how many are mockups or the functionality behind some UI elements is simply not implemented yet.
Wow, cool! I think I remember a post years ago about this project. IIRC you did a thesis in something to do with simulating brush strokes? Anyway, congrats on releasing this, super impressive to have worked on this for so long and come out with something that looks so good. (And it's awesome that you're looking into using Vello too.)
You remember correctly! Here's that thesis code <https://github.com/Keavon/Brush-Nodes>. You can ignore the readme since it doesn't talk about brushes and open the GitHub Pages site (or, I can just link it here: <https://keavon.github.io/Brush-Nodes/>). Then press Ctrl+1, Ctrl+2, Ctrl+3, or Ctrl+4 and reload the page after each. Be patient as it takes a couple seconds to load the page once a demo is chosen. That'll load the four brush demos:
- Ctrl+1: dotted stamp roller - Ctrl+2: bristle brush - Ctrl+3: diluted ink - Ctrl+4: ragged solid ink brush
This concept will be reimplemented in Graphite eventually. Maybe as a GSoC project.
The actual thesis write-up is here <https://digitalcommons.calpoly.edu/theses/2653/> in case you're really interested for some reason.
Oh cool! I've had a very unfinished unpublished SVG editor from a couple years ago with blender-ish controls that I started cleaning up a couple days ago; guess I don't need to anymore.
Here are some things in mine that I've found useful but don't see here (/ might have missed) and could be food for thought (presumably some of these are just NYI but noting them regardless): [edit: a couple of these things are already noted at https://github.com/GraphiteEditor/Graphite/issues/1870]
- shift+G/R/S for setting handle mode (bent, colinear, and colinear+equidistant respectively) works out quite intuitively; mode can be displayed as a different icon on the point (square for bent, rectangle aligned to angle for colinear, and circle for equidistant is what I use; circle is somewhat questionable but my handles have arrow tips)
- while holding just a handle, set the rotation/scale anchor point to its point
- allow both rotate and scale at the same time (maybe never useful but I still did it. ¯\_(ツ)_/¯)
- while rotating/scaling, some shortcut for setting the anchor point (esp. snapped to an element representing the rotational center of a symmetric design)
- middle-mouse-dragging while holding an element should ignore the delta mouse movement during the movement
- I draw visual indicators of the current r/g/s accumulated action (g: a line from the starting mouse position in the canvas to where it'd be dragged to; s: line from the anchor point through the current and original mouse position with different colors (i.e. the ratio of the color lengths is the ratio of scaling); r: lines from the anchor to original & current mouse position, with an arc in between (very busy-looking, don't quite like it))
- some actions - cut a path into two (a thing I don't have but have wanted is drag-selecting to cut into three), snapping to existing points if near enough; and another to join paths if two end-points are selected; and select all linked to current selection
Thanks, those are really useful! Would you mind copy and pasting those into a comment in https://github.com/GraphiteEditor/Graphite/issues/1870 to help us keep track of those suggestions? I'd like to revisit them again.
This is really cool but I have an RTX 4080 and it's really struggling to open and subsequently manipulate the example art.
Maybe just because it's in the browser?
That'd be because it's all CPU-based at the moment . So your 4080 is taking a vacation while your CPU hits the gym. That's obviously not ideal, but you'll have to trust me that it is due to long-term architectural planning reasons and not a blatant disregard for sensible development practices. Our node graph engine is really advanced—it's actually a scripting language built upon Rust and its type system—which will have some very sizable benefits once it's done being built. But right now, it means vital things like GPU compute have been blocked by a towering pile of other engineering work. But we've nearly completed those prerequisites and should be able to unlock GPU compute in the early parts of next year (this is also blocked on Firefox and Safari shipping WebGPU support, required to use compute shaders in the browser— and on us having the time to support Windows, Mac, and Linux builds via [Tauri](https://tauri.app/)).
In short, please be patient :) The app's architecture is designed with performance that'll make your CPU and GPU scream, but it's a big job building all of it. Especially for raster imagery, that's where a CPU-bottlenecked render pipeline is especially affected. But next year is the year we move on from vector graphics to raster once the GPU is utilized in the render pipeline.
Thanks for taking a look!
When you start supporting GPUs, what APIs do you plan to use (cuda, vulkan, dx, etc.)? It would be quite unfortunate to use a non-vendor-neutral API (for both OS and GPU vendor). I would probably use wgpu or vulkan for this.
Everything will be using compute shaders for the foreseeable future. [WGPU](https://wgpu.rs/) abstracts that to work with WebGPU on browsers, DirectX/Vulkan on Windows, Metal on Mac, and Vulkan on Linux and Android. There may be opportunities to explore vendor-specific options like CUDA in the far future to leverage a further increase in performance, but compute shaders are portable and nearly as good.
yep,
this almost killed my machine , I wasn't to sure if it was my PC or firefox
Looks good! I'm not too much into graphics these days, but when I was I would've loved that.
What UI crate are you using for the GUI?
Right now, it's a custom HTML/CSS/TypeScript component system using Svelte built to minimize bloat. But since Graphite is a data-driven graphics app and render engine, we are planning to gradually rewrite our UI components as Graphite documents— allowing us to design the editor's UI within its own editor UI. Once that happens, we can probably drop the web dependencies— although we've taken pains to ensure our current web dependencies are very lightweight and performant. All the slow parts of Graphite are due to backend engineering shortcuts we've taken to enable forward progress, and those are stopgaps that are actively being worked on to be rebuilt into proper, high-performance systems.
Have you considered using Iced? It can be hard to figure out at first but it's blazing fast, cross-platform and can compile to WASM. It's also _beautifully_ designed.
Importantly, it's both "just Rust" and "very Rust". You can stay on the yellow brick road and kinda just get the app out there with incredible multi-threaded CPU + GPU rendering performance from the outset... or dig deeper and go into advanced stuff. Per the docs, it "leverages Rust to its full extent: ownership, borrowing, lifetimes, futures, streams, first-class functions"... it's just up to you how much of that you want to use
The documentation is admittedly WIP but if you need help, the Discord server is very helpful. I'm there virtually 24/7 and happy to answer any questions
The repo is at https://github.com/iced-rs/iced -- check out the readme for two complex apps recently built. It's fully themeable so you can make apps look exactly as you want them to (which is a downside for those looking for more native widgets)
It was a top contender when I was picking a GUI solution but it didn't meet the cut. Remember that this was 3.5 years ago. The decision to go with HTML/CSS was undoubtedly the right one and it'll continue to treat us well for the foreseeable future. But we are beginning to rewrite certain areas, like the node graph, in our own render stack because this streamlines the code best. And other widgets like histograms, color scopes, etc. will continue to be built with our own renderer. And then at some point, it will start making sense to begin gradually replacing other parts of our UI with the regular widgets like buttons and checkboxes with that system. Doing so will help us simplify things and make them more user-customizable, so plugin authors can affect the UI, etc.
I sincerely doubt you will be able to match the performance of native widgets with immediate-mode render libraries.
Love the design.
this is cool.great job.
this looks really promising. I'm missing the old days of PSP to dr up some image for meme fun etc. This looks like it'd do the job.
(The submitted URL was https://graphite.rs/blog/graphite-progress-report-q3-2024/ but I converted the post to a Show HN per https://news.ycombinator.com/newsguidelines.html and added the progress report link to the bottom of your text. I hope this helps!)
Thanks for keeping things tidy! I'm more used to the Reddit side of the internet so I appreciate the help keeping to the norms here on HN.
Why not extend blender, then it becomes so much more powerfull. ea 3d print, animate, render, use for vfx in videos