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?
I can't speak for OP, but I didn't seek funding for my company because I knew that it would eventually force me to sacrifice the things I value about it in favor of growth. I'd rather run a small company that sustainably does good, honest business than a giant one that hollows itself out for maximum growth.
Founders are just as tired of "ugh, why can't they just stop ruining good things!" as you are. Or some of us are, anyway.
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.
Raising investor money means selling your business before you're even done with it. Sometimes before you've even started it. I mean, that's what all that equity that gets cleaved off represents.
And generally, you'll get your worst terms the earlier you solicit those funds.
If you don't need those funds, it's (mostly) to your advantage to hold off on raising them until you've got your feet underneath you and a company whose future is less disputable.
On the way there, you may even decide not to sell much to investors at all, which makes a big difference if you actually care about either your product or your team. Because your outside investors will rarely care about either and will often convince you to compromise both. They're financiers, and they're there for the money. You should be sure your objectives align with theirs before you sell to them.
> 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?
Maybe they wanted to work for themselves, not for a VC?
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.
(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.
If you don't have a way to bundle up a collection of nodes and apply it to another object or bring it to another document with just a few clicks, that's super powerful too. I rely on that constantly in Illustrator. And constantly grumble at the fact that there's no way to have folders in the Graphic Styles palette where these collections of nodes live, since I can easily have a dozen styles for one character when I'm doing comics.
----
although I just played with it and judging by the state of your layers palette there's clearly a lot of stuff to do in terms of organizing the elements of the document in general - to me, documents contain one of more layers, that contain paths, compound paths, groups of paths, and/or layers, and I can choose to place new paths at the top or bottom of any layer (or inside a clipping path); Graphite just calls every path a "layer" and this becomes very unwieldy within a few seconds of drawing shapes.
I want my applications to live on my computer and be able to do things like say “this new update breaks my workflow, I am rolling back to the last good version until they get this shit fixed”. This has happened multiple times with Illustrator.
Also they say "native" apps are coming which I am assuming means "actually talks to the OS properly instead of going through a web browser", I have loathed Electron apps ever since Evernote got rewritten as a pile of webshit.
Some suggestions:
I was doing something and then suddently I got a red error message, "The document cannot be rendered in it current state", instructing me to click the Node Graph button.
1. I couldn't find that button. Perhaps show a picture of it or just embed it in the error message.
I got the same error when I was doing the tutorial (which went quite well) and was doing the steps for circular repeat of the sun rays. Pressing Ctrl-Z undid practically all the work instead of just the last wrong change (not sure what caused it).
Update: the issue with following what was shown in the tutorial is now fixed. Now the Fill and Stroke nodes apply to the vector contents of group data, which was the problem. (We made Circular Repeat produce a group of vector shapes to properly preserve styling information like gradients, which was why it broke.)
Ah yes, good find: the stroke node can only apply to vector data, but when you use the Circular Repeat node, it now produces group data (as it should have always done). The fix is to put the Stroke node first to avoid the type error. I'll see what I can do to update the tutorial with that info, and to try to make the Stroke node more robust so it could apply to all group elements.
I'm surprised that Ctrl+Z undid more than one step, I've never seen that before. If you get the chance to reproduce that and write up the steps, please file an issue since we'd like to take a look into that.
I can try to reproduce but don't want to go through all the steps every time in case things go wrong again. Is there a savepoint/export/import kind of feature?
I think a tutorial regarding basics such as how to find shortcuts, do's/dont's for new beginners might help.
You can save the document and reopen it later just like in any other program. You might not be able to reproduce the graph validity error anymore because we fixed the specific bug you encountered. The input hints bar at the bottom shows what buttons you can press in any context, but that's a good idea to mention it in upcoming tutorials because I've noticed that users tend to ignore it. Hover tooltips and the app menu also both display shortcuts, which are worth pointing out in future tutorials as well. Thanks for that suggestion.
Thanks for the feedback. What you've encountered is a type error— basically a programming language's compiler telling you that your code is invalid. It's not a bug per-se, although sometimes it is caused by our nodes not being as general as they should be. We just fixed an issue where the Stroke and Fill nodes only applied to vector data but didn't apply to group data (where the group contained one or more vector data). Those kinds of problems, when sensible, should probably get issues filed against them.
The red error message does tell you where to look:
> Check for error details in the node graph, which can be
> opened with the viewport's top right _Node Graph_ button.
So in the top right of the viewport, and it's the button labeled "Node Graph". Is it possible your window was very small and the button got scrolled out of the way by other buttons? I'm open to feedback about how you may suggest improving the text of that message. It would currently be hard to make that dialog more visual or interactive, unfortunately, but that'll be something worth building towards improving in the future with improved diagonstics all around.
I'd suggest allowing bug reports directly from the app. You can capture highly useful context with the report. You have highly technical people here eager to help your wonderful creation!
We have this for crash reports. Perhaps that's a good idea to add a menu button for reporting other bugs. Do you have suggestions as to how to make that discoverable?
1. When this red error message is displayed, I'd have loved to see a "report this bug/issue/incident" next to it. That button would have opened a dialog box for me to write in, and telling that the context would be shipped with my bug report.
To me it looked like a crash, but I do understand that programmatically it wasn't a "crash" or an unhandled exception.
2. Since this is a pre-alpha/alpha/beta version, there's nothing wrong with a green button with a picture of a bug anywhere in the interface. Just open a dialog explaining that although horrified, you'll be thrilled to learn of any bugs.
Ah yes, you made me realize we could check if the node graph isn't open and tell the user to report a bug in that situation, which must have arisen from a tool or other WYSIWYG aspect of the program causing a node graph error. But we wouldn't show it if it arose from the user just noodling around with the nodes. That's a good idea that'll be worth us implementing, thank you for the suggestion.
If I click with a drawing tool on the drawing and my drawing disappears and gets replaced with that screen, that's 100% a bug, no matter how we try to phrase that.
Yes, that should never happen. If you ever encounter that, please report a bug describing the situation in which it occurred. The Brush tool bug was fixed yesterday, so that particular one shouldn't happen anymore.
That's a recent regression, thanks for mentioning that. We'll get that fixed ASAP. I should also mention that the brush tool isn't well-supported and will be fully rewritten early next year. It currently has some quality and performance issues because it has to generate a texture on the CPU of the width and height required by the entire stroke bounding box, which quickly hits a performance wall.
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.
Those are both 3D CAD programs though, and almost all CAD software supports 2D parametric sketching. I mostly just find strange though that such a ubiquitous feature in CAD, which allows for fast creation and manipulation of 2D shapes, is missing from every vector graphics tool I've used.
Immediately looking at the screenshot and I'm impressed. No further review I can tell this is different. I've always said we need more "Blender"-like projects out there to take on Adobe. I see you potentially have plans to take on other apps as well. Following and hoping for your success.
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.
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.
Procedural node-based raster editing can become insane. Do things vectors cannot, but with infinite resolution. There are already fractal examples on the website which would murder any vector renderer.
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.
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.
Maybe I'm doing something wrong, but I find it somewhat non-intuitive that each stroke / circle / box is automatically its own layer, rather than the layers being explicit, as they are in Inkscape. That makes the layers essentially useless for me.
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.
Do you think you'll use WASM as a target for the custom scripts in code form?
Zed has an interesting WASM-based extension APIN that makes it really easy to write extensions in Rust, it might be worth checking out for this project.
Custom code will be compiled to Wasm so it's sandboxed for security purposes. First-party code that ships with Graphite, or perhaps trusted authors in the future, will be able to use non-Wasm native code on desktop. But Wasm is still a very high percentage of native speed.
Is it possible to draw a Bézier curve, then decompose it in the Node Editor to a set of numeric nodes which input into a Bézier node? I couldn't figure out how to do that (mentioned it elsethread).
You could ask that in our Discord and we can give more advanced guidance, but that isn't something we specifically have nodes for yet. We are building a spreadsheet view for working with all the data in numeric form, and once we have that plus some nodes for interacting with the spreadsheet data, your use case will become more naturally represented.
This is a usage model which I would advocate for --- the ability to record series of actions and then edit them made using WordBASIC to automate Microsoft Word far more accessible/discoverable for me.
Could you see this having a CAD-like mode? I really see a gap there in terms of open-source projects.
I see that you have constraints on your roadmap, but that's not what I mean. I am specifically referring to the 2D mode of Vectorworks, which is, special modules aside, really just a vector editor with support for hairlines and representational line styling (so lines don't have a 'real' thickness, but you set semantical pen thickness).
The main feature here is more about the path drawing workflow, which enables you to efficiently work with exact measurements. E.g. to draw a line you'd click to start, hover on the desired angle, enter number, (optionally press tab, enter exact angle,) click. A rectangle, say, would have additional parameters to access via tab.
So thinking about it, it in fact it is kind of a restraints system, but it only applies to the current drawing process and has the absolute minimum needed key presses/actions as possible, because you need to do this a lot (Sketchup works simlar, too)
I could see myself working on something like that, but didn't see anything pointing in that direction in your open tasks, so I am wondering if that would be in scope for graphite.
That's all definitely in-scope. If you'd be motivated to contribute it, there should also be nothing that's really blocking it right now if you're willing to dive into the implementation details. Please join our Discord and let's talk about it more.
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.
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.
My understanding is that InkScape is foremost an SVG editor. If SVG can't do it, then InkScape can't either. This seems quite somewhat limiting for a general-purpose graphical editor, aspiring to integrate good bitmap editing support as well later.
Though, I guess it does somehow extend the SVG format, as it provides saving as either Inkscape SVG or plain SVG.. So maybe my understanding is incorrect?
Yes, and furthermore, Inkscape doesn't even have its own file format. You save your work to SVG. So the entire program is intrinsically tied to the SVG spec, and won't ever expand beyond that. It wouldn't be a good base to try and extend into a highly generalized program meeting the Graphite vision.
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.
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.
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.
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.
This sounds like a big project—congrats on releasing it! Just curious, as a business other than a hobby, do you have enough resources to see it through?
Everything we do is bootstrapped through donations and volunteer development time. When our main other core contributor graduates in a year, we'll need the funds to hire him, so we will be pushing that donation angle more in the coming year as well as applying for grants. I personally would like to be paid eventually, but I'm well-equipped to keep at this for a while before finances become a problem in my life. I can be not paid, but can't pay others. As a project, we have longer-term business plans that let us stay sustainable and independent and not wholly dependent upon donations: a combination of asset store payment processing, cloud document storage, and render farm services for people who wish to opt into paying for those value-adds that are otherwise not part of the main product. A decade from now, I'd like to actually recoup my investment, but I don't want to sell out to investors.
Yours is the sort of project where if I had a boatload of money I'd just find it no strings attached through your project forecast. This would be such an excellent tool for artists with light pen integration.
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.
Feel free to drop by our Discord and go into more detail about this. I think we may need to discuss it for me to understand exactly what you're describing.
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.
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
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:
Krita is a painting application. Graphite is a vector editing application. There is currently no overlap between the two apps. We intend to eventually build a painting application workflow, but that isn't something we're focused on yet and we'll likely prioritize other area first because Krita is a competent tool for painting already, which digital artist should use for that workflow until we someday have the time to build something even better.
I'm so glad this is a genuine product that stands by it's own merit rather than trying to sell itself on the basis of being written in Rust. I feel too many products that use some fancy new tech in development make that aspect part of the sales pitch. It is certainly interesting for us here, but the users of the tool will only care about the technical side to the degree that the tool is stable, performant and continues to be developed.
I'm not an illustrator so I can't add much beyond that, but I'm rooting for the devs to turn it into a success!
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.
It's your app, so obviously do whatever you want, but I agree with the sibling comment that an immediate mode GUI wastes valuable CPU cycles redrawing the frame repeatedly and will invariably hurt performance
Again, since iced is "just rust", you can write whatever widgets you need, although it comes with a long list of built-in widgets (and there are many more built by the community). You can compose views with a bunch of these widgets to get to the UI you want.
There's also nothing stopping you from creating a way for users to write widgets for your iced application. The sky is the limit.
And I'm singling out iced because I'm a fan, but this should be true for pretty much all robust GUI toolkits out there.
Very cool! One comment, one question. 1) panning the node graph of the leaves demo seemed slow / laggy on my macbook pro in chrome, which gave an initial low-quality feeling - moving nodes was nice and responsive.
2) Given that this is written in Rust (compiled), is it on the roadmap to 'export' the parameterized designs into some callable library code? e.g: a game engine that calls "leaves = generate_texture("changing_leaves.graphite", percentage=0.2)"? It would be cool to keep that configurability even once you leave the editor - basically, splitting the node-graph renderer out as its own library that you can call programmatically.
1. Please see https://news.ycombinator.com/item?id=41854076
2. Yes, you got it! That's very much something we are building towards, and you hit it on the nail in describing how that will work and the utility it will provide to people across many industries from game dev to backend services.
You're in luck, this seems to _only_ support WASM in the browser for the time being.
> Graphite's code architecture is structured to deliver native performance for your graphically intensive workloads on desktop platforms and very low overhead on the web thanks to WebAssembly and WebGPU
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?
I can't speak for OP, but I didn't seek funding for my company because I knew that it would eventually force me to sacrifice the things I value about it in favor of growth. I'd rather run a small company that sustainably does good, honest business than a giant one that hollows itself out for maximum growth.
Founders are just as tired of "ugh, why can't they just stop ruining good things!" as you are. Or some of us are, anyway.
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.
You could totally get funding for a vector editor. A friend of mine got funding for a node-based video editor.
Figma comes to mind. But yes, your rest of the analysis follows on the dot and makes perfect sense.
Raising investor money means selling your business before you're even done with it. Sometimes before you've even started it. I mean, that's what all that equity that gets cleaved off represents.
And generally, you'll get your worst terms the earlier you solicit those funds.
If you don't need those funds, it's (mostly) to your advantage to hold off on raising them until you've got your feet underneath you and a company whose future is less disputable.
On the way there, you may even decide not to sell much to investors at all, which makes a big difference if you actually care about either your product or your team. Because your outside investors will rarely care about either and will often convince you to compromise both. They're financiers, and they're there for the money. You should be sure your objectives align with theirs before you sell to them.
> 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?
Maybe they wanted to work for themselves, not for a VC?
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)
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.
(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.
If you don't have a way to bundle up a collection of nodes and apply it to another object or bring it to another document with just a few clicks, that's super powerful too. I rely on that constantly in Illustrator. And constantly grumble at the fact that there's no way to have folders in the Graphic Styles palette where these collections of nodes live, since I can easily have a dozen styles for one character when I'm doing comics.
----
although I just played with it and judging by the state of your layers palette there's clearly a lot of stuff to do in terms of organizing the elements of the document in general - to me, documents contain one of more layers, that contain paths, compound paths, groups of paths, and/or layers, and I can choose to place new paths at the top or bottom of any layer (or inside a clipping path); Graphite just calls every path a "layer" and this becomes very unwieldy within a few seconds of drawing shapes.
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.
I want my applications to live on my computer and be able to do things like say “this new update breaks my workflow, I am rolling back to the last good version until they get this shit fixed”. This has happened multiple times with Illustrator.
Also they say "native" apps are coming which I am assuming means "actually talks to the OS properly instead of going through a web browser", I have loathed Electron apps ever since Evernote got rewritten as a pile of webshit.
Some suggestions: I was doing something and then suddently I got a red error message, "The document cannot be rendered in it current state", instructing me to click the Node Graph button.
1. I couldn't find that button. Perhaps show a picture of it or just embed it in the error message.
2. Make the error text selectable.
3. Let me report the bug straight from the app?
I got the same error when I was doing the tutorial (which went quite well) and was doing the steps for circular repeat of the sun rays. Pressing Ctrl-Z undid practically all the work instead of just the last wrong change (not sure what caused it).
Update: the issue with following what was shown in the tutorial is now fixed. Now the Fill and Stroke nodes apply to the vector contents of group data, which was the problem. (We made Circular Repeat produce a group of vector shapes to properly preserve styling information like gradients, which was why it broke.)
Ah yes, good find: the stroke node can only apply to vector data, but when you use the Circular Repeat node, it now produces group data (as it should have always done). The fix is to put the Stroke node first to avoid the type error. I'll see what I can do to update the tutorial with that info, and to try to make the Stroke node more robust so it could apply to all group elements.
I'm surprised that Ctrl+Z undid more than one step, I've never seen that before. If you get the chance to reproduce that and write up the steps, please file an issue since we'd like to take a look into that.
I can try to reproduce but don't want to go through all the steps every time in case things go wrong again. Is there a savepoint/export/import kind of feature?
I think a tutorial regarding basics such as how to find shortcuts, do's/dont's for new beginners might help.
You can save the document and reopen it later just like in any other program. You might not be able to reproduce the graph validity error anymore because we fixed the specific bug you encountered. The input hints bar at the bottom shows what buttons you can press in any context, but that's a good idea to mention it in upcoming tutorials because I've noticed that users tend to ignore it. Hover tooltips and the app menu also both display shortcuts, which are worth pointing out in future tutorials as well. Thanks for that suggestion.
Thanks for the feedback. What you've encountered is a type error— basically a programming language's compiler telling you that your code is invalid. It's not a bug per-se, although sometimes it is caused by our nodes not being as general as they should be. We just fixed an issue where the Stroke and Fill nodes only applied to vector data but didn't apply to group data (where the group contained one or more vector data). Those kinds of problems, when sensible, should probably get issues filed against them.
The red error message does tell you where to look:
> Check for error details in the node graph, which can be > opened with the viewport's top right _Node Graph_ button.
So in the top right of the viewport, and it's the button labeled "Node Graph". Is it possible your window was very small and the button got scrolled out of the way by other buttons? I'm open to feedback about how you may suggest improving the text of that message. It would currently be hard to make that dialog more visual or interactive, unfortunately, but that'll be something worth building towards improving in the future with improved diagonstics all around.
I'd suggest allowing bug reports directly from the app. You can capture highly useful context with the report. You have highly technical people here eager to help your wonderful creation!
We have this for crash reports. Perhaps that's a good idea to add a menu button for reporting other bugs. Do you have suggestions as to how to make that discoverable?
1. When this red error message is displayed, I'd have loved to see a "report this bug/issue/incident" next to it. That button would have opened a dialog box for me to write in, and telling that the context would be shipped with my bug report.
To me it looked like a crash, but I do understand that programmatically it wasn't a "crash" or an unhandled exception.
2. Since this is a pre-alpha/alpha/beta version, there's nothing wrong with a green button with a picture of a bug anywhere in the interface. Just open a dialog explaining that although horrified, you'll be thrilled to learn of any bugs.
Ah yes, you made me realize we could check if the node graph isn't open and tell the user to report a bug in that situation, which must have arisen from a tool or other WYSIWYG aspect of the program causing a node graph error. But we wouldn't show it if it arose from the user just noodling around with the nodes. That's a good idea that'll be worth us implementing, thank you for the suggestion.
If I click with a drawing tool on the drawing and my drawing disappears and gets replaced with that screen, that's 100% a bug, no matter how we try to phrase that.
Yes, that should never happen. If you ever encounter that, please report a bug describing the situation in which it occurred. The Brush tool bug was fixed yesterday, so that particular one shouldn't happen anymore.
I suggest putting a button in the error dialog that goes straight to the Node Graph.
Simply using the brush tool triggered this error for me.
Update: that's fixed now. It was a super recent regression which is how it didn't get caught earlier. Thanks for the report.
That's a recent regression, thanks for mentioning that. We'll get that fixed ASAP. I should also mention that the brush tool isn't well-supported and will be fully rewritten early next year. It currently has some quality and performance issues because it has to generate a texture on the CPU of the width and height required by the entire stroke bounding box, which quickly hits a performance wall.
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.
The closest thing would be Solvespace --- might want to look at Dune3D.
Those are both 3D CAD programs though, and almost all CAD software supports 2D parametric sketching. I mostly just find strange though that such a ubiquitous feature in CAD, which allows for fast creation and manipulation of 2D shapes, is missing from every vector graphics tool I've used.
Yeah, it would be interesting to see the Solvespace solver ported to Inkscape as it was to Blender as CADsketcher.
Immediately looking at the screenshot and I'm impressed. No further review I can tell this is different. I've always said we need more "Blender"-like projects out there to take on Adobe. I see you potentially have plans to take on other apps as well. Following and hoping for your success.
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.)
Good luck, you are going to need it.
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.
Procedural node-based raster editing can become insane. Do things vectors cannot, but with infinite resolution. There are already fractal examples on the website which would murder any vector renderer.
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.
I'm glad at least one person in this thread mentioned Fireworks. I found it much more intuitive than Gimp and Inkscape.
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.
Maybe I'm doing something wrong, but I find it somewhat non-intuitive that each stroke / circle / box is automatically its own layer, rather than the layers being explicit, as they are in Inkscape. That makes the layers essentially useless for me.
This looks awesome! It looks like a decent Illustrator alternative with its own identity. Even the basics are more competent than Inkscape.
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.
Do you think you'll use WASM as a target for the custom scripts in code form?
Zed has an interesting WASM-based extension APIN that makes it really easy to write extensions in Rust, it might be worth checking out for this project.
Custom code will be compiled to Wasm so it's sandboxed for security purposes. First-party code that ships with Graphite, or perhaps trusted authors in the future, will be able to use non-Wasm native code on desktop. But Wasm is still a very high percentage of native speed.
Makes sense, I think that will end up a solid approach.
Is it possible to draw a Bézier curve, then decompose it in the Node Editor to a set of numeric nodes which input into a Bézier node? I couldn't figure out how to do that (mentioned it elsethread).
You could ask that in our Discord and we can give more advanced guidance, but that isn't something we specifically have nodes for yet. We are building a spreadsheet view for working with all the data in numeric form, and once we have that plus some nodes for interacting with the spreadsheet data, your use case will become more naturally represented.
This is a usage model which I would advocate for --- the ability to record series of actions and then edit them made using WordBASIC to automate Microsoft Word far more accessible/discoverable for me.
Could you see this having a CAD-like mode? I really see a gap there in terms of open-source projects.
I see that you have constraints on your roadmap, but that's not what I mean. I am specifically referring to the 2D mode of Vectorworks, which is, special modules aside, really just a vector editor with support for hairlines and representational line styling (so lines don't have a 'real' thickness, but you set semantical pen thickness).
The main feature here is more about the path drawing workflow, which enables you to efficiently work with exact measurements. E.g. to draw a line you'd click to start, hover on the desired angle, enter number, (optionally press tab, enter exact angle,) click. A rectangle, say, would have additional parameters to access via tab.
So thinking about it, it in fact it is kind of a restraints system, but it only applies to the current drawing process and has the absolute minimum needed key presses/actions as possible, because you need to do this a lot (Sketchup works simlar, too)
I could see myself working on something like that, but didn't see anything pointing in that direction in your open tasks, so I am wondering if that would be in scope for graphite.
That's all definitely in-scope. If you'd be motivated to contribute it, there should also be nothing that's really blocking it right now if you're willing to dive into the implementation details. Please join our Discord and let's talk about it more.
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.
My understanding is that InkScape is foremost an SVG editor. If SVG can't do it, then InkScape can't either. This seems quite somewhat limiting for a general-purpose graphical editor, aspiring to integrate good bitmap editing support as well later.
Though, I guess it does somehow extend the SVG format, as it provides saving as either Inkscape SVG or plain SVG.. So maybe my understanding is incorrect?
Yes, and furthermore, Inkscape doesn't even have its own file format. You save your work to SVG. So the entire program is intrinsically tied to the SVG spec, and won't ever expand beyond that. It wouldn't be a good base to try and extend into a highly generalized program meeting the Graphite vision.
This is one of the more interesting projects I've seen for a while. Excellent landing page by the way.
Thanks! Do you mean the website home page, or the app's welcome screen?
I was referring to the link posted to HN: https://graphite.rs/
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.
Love it! I've never liked how 2D graphics currently involves so many separate programs and forces you into a feed forward pipeline workflow.
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
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.
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.
This sounds like a big project—congrats on releasing it! Just curious, as a business other than a hobby, do you have enough resources to see it through?
Everything we do is bootstrapped through donations and volunteer development time. When our main other core contributor graduates in a year, we'll need the funds to hire him, so we will be pushing that donation angle more in the coming year as well as applying for grants. I personally would like to be paid eventually, but I'm well-equipped to keep at this for a while before finances become a problem in my life. I can be not paid, but can't pay others. As a project, we have longer-term business plans that let us stay sustainable and independent and not wholly dependent upon donations: a combination of asset store payment processing, cloud document storage, and render farm services for people who wish to opt into paying for those value-adds that are otherwise not part of the main product. A decade from now, I'd like to actually recoup my investment, but I don't want to sell out to investors.
Yours is the sort of project where if I had a boatload of money I'd just find it no strings attached through your project forecast. This would be such an excellent tool for artists with light pen integration.
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.
Feel free to drop by our Discord and go into more detail about this. I think we may need to discuss it for me to understand exactly what you're describing.
See answer at:
https://news.ycombinator.com/item?id=41862107
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.
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
Please make First and Last name optional in your email signup form, there's no reason for that to be mandatory.
It's not mandatory, you can enter any name you wish.
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.
Looks good! I'm not too much into graphics these days, but when I was I would've loved that.
Is there a comparison/contrast with Krita anywhere?
Krita is a painting application. Graphite is a vector editing application. There is currently no overlap between the two apps. We intend to eventually build a painting application workflow, but that isn't something we're focused on yet and we'll likely prioritize other area first because Krita is a competent tool for painting already, which digital artist should use for that workflow until we someday have the time to build something even better.
I'm so glad this is a genuine product that stands by it's own merit rather than trying to sell itself on the basis of being written in Rust. I feel too many products that use some fancy new tech in development make that aspect part of the sales pitch. It is certainly interesting for us here, but the users of the tool will only care about the technical side to the degree that the tool is stable, performant and continues to be developed.
I'm not an illustrator so I can't add much beyond that, but I'm rooting for the devs to turn it into a success!
So easy, so nice. Beautiful work, really amazing. Congratulations and thank you.
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.
It's your app, so obviously do whatever you want, but I agree with the sibling comment that an immediate mode GUI wastes valuable CPU cycles redrawing the frame repeatedly and will invariably hurt performance
Again, since iced is "just rust", you can write whatever widgets you need, although it comes with a long list of built-in widgets (and there are many more built by the community). You can compose views with a bunch of these widgets to get to the UI you want.
There's also nothing stopping you from creating a way for users to write widgets for your iced application. The sky is the limit.
And I'm singling out iced because I'm a fan, but this should be true for pretty much all robust GUI toolkits out there.
Isn’t iced immediate mode?
I sincerely doubt you will be able to match the performance of native widgets with immediate-mode render libraries.
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.
Love the design.
Very cool! One comment, one question. 1) panning the node graph of the leaves demo seemed slow / laggy on my macbook pro in chrome, which gave an initial low-quality feeling - moving nodes was nice and responsive.
2) Given that this is written in Rust (compiled), is it on the roadmap to 'export' the parameterized designs into some callable library code? e.g: a game engine that calls "leaves = generate_texture("changing_leaves.graphite", percentage=0.2)"? It would be cool to keep that configurability even once you leave the editor - basically, splitting the node-graph renderer out as its own library that you can call programmatically.
1. Please see https://news.ycombinator.com/item?id=41854076 2. Yes, you got it! That's very much something we are building towards, and you hit it on the nail in describing how that will work and the utility it will provide to people across many industries from game dev to backend services.
Awesome! Composable tools rule.
this is cool.great job.
Similarly, there's Kons-9 for 3D procedural imaging/modelling written in Common Lisp.
Is there any dependencies that would not allow this to be compiled to WASM?
I just think sometimes when I see cool apps like this, it seems like there could be a new wave of cool web/phone apps using RUST/WASM.
Something about these Rust examples just seem snappier, sharper.
You're in luck, this seems to _only_ support WASM in the browser for the time being.
> Graphite's code architecture is structured to deliver native performance for your graphically intensive workloads on desktop platforms and very low overhead on the web thanks to WebAssembly and WebGPU
(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