[HN Gopher] Show HN: Graphite, a Blender-inspired 2D procedural ...
___________________________________________________________________
Show HN: Graphite, a Blender-inspired 2D procedural design Rust app
For 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/
Author : Keavon
Score : 707 points
Date : 2024-10-15 22:32 UTC (1 days ago)
(HTM) web link (graphite.rs)
(TXT) w3m dump (graphite.rs)
| dang wrote:
| (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!)
| Keavon wrote:
| 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.
| dang wrote:
| 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)
| lacoolj wrote:
| 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?
| Keavon wrote:
| 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!
| john01dav wrote:
| 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.
| Keavon wrote:
| 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.
| 123pie123 wrote:
| yep,
|
| this almost killed my machine , I wasn't to sure if it was my
| PC or firefox
| egypturnash wrote:
| 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.
| egypturnash wrote:
| (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.)
| Keavon wrote:
| 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.
| egypturnash wrote:
| 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.
| skavi wrote:
| 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.
| dumbo-octopus wrote:
| I'd prefer it to be one that the developers have specifically
| targeted and developed/tested against, especially if there's
| any GPU involvement.
| egypturnash wrote:
| 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.
| adastra22 wrote:
| What UI crate are you using for the GUI?
| Keavon wrote:
| 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.
| airstrike wrote:
| 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)
| Keavon wrote:
| 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.
| adastra22 wrote:
| I sincerely doubt you will be able to match the
| performance of native widgets with immediate-mode render
| libraries.
| airstrike wrote:
| 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.
| bangaladore wrote:
| 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?
| Keavon wrote:
| 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.
| crabmusket wrote:
| Graphite is to Photoshop as Blender is to 3DS Max?
| Keavon wrote:
| 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.
| timeon wrote:
| 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.)
| germandiago wrote:
| Good luck, you are going to need it.
| underbiding wrote:
| 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.
| mirekrusin wrote:
| Author says raster focus next year, intention to support both
| and frankly it sounds like great idea.
| aDyslecticCrow wrote:
| 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.
| mightyham wrote:
| 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.
| Keavon wrote:
| Definitely! And in fact, that is on our [roadmap](https://graph
| ite.rs/features/#:~:text=CAD%2Dlike%20constrain...). Maybe you
| could get involved instead of making something separate.
| mightyham wrote:
| Awesome! If I ever find the time, I will definitely look into
| contributing.
| kakkun wrote:
| I'm really looking forward to that. It's something I tried to
| tackle but unfortunately had to give up on.
| WillAdams wrote:
| The closest thing would be Solvespace --- might want to look at
| Dune3D.
| mightyham wrote:
| 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.
| WillAdams wrote:
| Yeah, it would be interesting to see the Solvespace solver
| ported to Inkscape as it was to Blender as CADsketcher.
| senectus1 wrote:
| 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.
| bufferoverflow wrote:
| 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?
| Keavon wrote:
| 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.
| lionkor wrote:
| 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.
| Keavon wrote:
| 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.
| _flux wrote:
| 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?
| Keavon wrote:
| 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.
| emmanueloga_ wrote:
| 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
| devsda wrote:
| 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
| Keavon wrote:
| 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).
| devsda wrote:
| 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.
| Keavon wrote:
| 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.
| Keavon wrote:
| 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.
| nicoburns wrote:
| 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...
| Keavon wrote:
| 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.
| OnionBlender wrote:
| I'm glad at least one person in this thread mentioned
| Fireworks. I found it much more intuitive than Gimp and
| Inkscape.
| nassimm wrote:
| Looks good! I'm not too much into graphics these days, but when I
| was I would've loved that.
| ChadNauseam wrote:
| 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.)
| Keavon wrote:
| 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.
| dzaima wrote:
| 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. -\\_(tsu)_/-)
|
| - 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
| Keavon wrote:
| 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.
| wg0 wrote:
| 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?
| jokethrowaway wrote:
| 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.
| wg0 wrote:
| Figma comes to mind. But yes, your rest of the analysis
| follows on the dot and makes perfect sense.
| ChadNauseam wrote:
| You could totally get funding for a vector editor. A friend
| of mine got funding for a node-based video editor.
| crabmusket wrote:
| > 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?
| rachofsunshine wrote:
| 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.
| swatcoder wrote:
| 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.
| martin_henk wrote:
| 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
| revskill wrote:
| Love the design.
| android521 wrote:
| this is cool.great job.
| qwertox wrote:
| 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?
| Keavon wrote:
| 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.
| WillAdams wrote:
| Is it possible to draw a Bezier curve, then decompose it in
| the Node Editor to a set of numeric nodes which input into a
| Bezier node? I couldn't figure out how to do that (mentioned
| it elsethread).
| Keavon wrote:
| 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.
| WillAdams wrote:
| 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.
| bschwindHN wrote:
| 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.
| Keavon wrote:
| 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.
| eternityforest wrote:
| Love it! I've never liked how 2D graphics currently involves so
| many separate programs and forces you into a feed forward
| pipeline workflow.
| lionkor wrote:
| 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.
| OhNoNotAgain_99 wrote:
| Why not extend blender, then it becomes so much more powerfull.
| ea 3d print, animate, render, use for vfx in videos
| virtualritz wrote:
| 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.
| Vox_Leone wrote:
| So easy, so nice. Beautiful work, really amazing. Congratulations
| and thank you.
| WillAdams wrote:
| 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.
| WillAdams wrote:
| See answer at:
|
| https://news.ycombinator.com/item?id=41862107
| Keavon wrote:
| 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.
| kranke155 wrote:
| 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.
| FrustratedMonky wrote:
| 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.
| hucker wrote:
| 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
| bethemoly wrote:
| 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?
| Keavon wrote:
| 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.
| TechSquidTV wrote:
| 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.
| deskr wrote:
| This is one of the more interesting projects I've seen for a
| while. Excellent landing page by the way.
| Keavon wrote:
| Thanks! Do you mean the website home page, or the app's welcome
| screen?
| aDyslecticCrow wrote:
| This looks awesome! It looks like a decent Illustrator
| alternative with its own identity. Even the basics are more
| competent than Inkscape.
| deskr wrote:
| 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?
| noisy_boy wrote:
| 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).
| Keavon wrote:
| 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.
| altilunium wrote:
| Simply using the brush tool triggered this error for me.
| Keavon wrote:
| 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.
| short_sells_poo wrote:
| 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!
| zdw wrote:
| Is there a comparison/contrast with Krita anywhere?
| Keavon wrote:
| 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.
| anthk wrote:
| Similarly, there's Kons-9 for 3D procedural imaging/modelling
| written in Common Lisp.
| cozzyd wrote:
| 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.
| handity wrote:
| Please make First and Last name optional in your email signup
| form, there's no reason for that to be mandatory.
| Keavon wrote:
| It's not mandatory, you can enter any name you wish.
| fwip wrote:
| 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.
| Keavon wrote:
| 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.
| fwip wrote:
| Awesome! Composable tools rule.
| lavela wrote:
| 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.
| Keavon wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-16 23:02 UTC)