Graphite: Open-source raster and vector 2D graphics editor(graphite.rs)
graphite.rs
Graphite: Open-source raster and vector 2D graphics editor
https://graphite.rs/
66 comments
Whenever I read emotional adjectives like “delightful” (or worse, “beautiful”), I can’t take a project description seriously. Show me why I should be delighted, don’t tell me that I will. Because you don’t know me, and you should let me judge on my own. Such marketing language reads more like wishful thinking than anything persuasive.
"made with love in x" makes me want to curl into a tiny ball
Hi, Graphite creator and website author here. I 100% agree with you since I am very bothered by marketing copy that's painfully obviously written by a nontechnical marketing team, and I want to avoid that here.
But... I guess it's hard being on the other end when actually writing copy so I've failed to design text which can be highly terse and also descriptive of complex concepts without turning into paragraph-long explainers. I know what Graphite is in my head, but conveying that to newcomers is really challenging! But clearly I need to try again.
Is there any chance you'd be willing to reach out to me, ideally on Discord but email also works, and let me use you to test my copy to a fresh pair of eyes? Basically as a B.S. detector :) I'm currently working on a new revamp to the website with many new pages, so having a fresh perspective and some ideas how to make things more direct (but not necessarily overly technical, since it should be digestible to artists also) and less marketing-ey, I'd find that highly valuable.
But... I guess it's hard being on the other end when actually writing copy so I've failed to design text which can be highly terse and also descriptive of complex concepts without turning into paragraph-long explainers. I know what Graphite is in my head, but conveying that to newcomers is really challenging! But clearly I need to try again.
Is there any chance you'd be willing to reach out to me, ideally on Discord but email also works, and let me use you to test my copy to a fresh pair of eyes? Basically as a B.S. detector :) I'm currently working on a new revamp to the website with many new pages, so having a fresh perspective and some ideas how to make things more direct (but not necessarily overly technical, since it should be digestible to artists also) and less marketing-ey, I'd find that highly valuable.
To their credit, this may be the only Rust project that does not say "blazing fast" on the home page.
Not a single mention of memory safety either.
This. I want to see screenshots and demo videos. At least they don’t have the explainer videos with the tall characters dancing around with quotes about innovation and synergy, or the talking head interviews with C-level execs talking about ROI.
But they haven't mentioned blazingly fast on their website... not sure if the actual downloadable binary is even written in Rust.
This was my exact thought. I was very on board until I read this and got ick'd out.
Kudos for NOT creating another open-source copy of a commercial application, but for offering a fresh take on 2D graphics.
Many times, I've wished that Photoshop would have nodes instead of layers, as it would make some things much simpler. Or that Illustrator and Photoshop would be combined into a single app.
I'm really impressed. Node-based compositing is not a feature that Adobe can easily add to Photoshop, as that would change the core workflow.
Many times, I've wished that Photoshop would have nodes instead of layers, as it would make some things much simpler. Or that Illustrator and Photoshop would be combined into a single app.
I'm really impressed. Node-based compositing is not a feature that Adobe can easily add to Photoshop, as that would change the core workflow.
> Or that Illustrator and Photoshop would be combined into a single app
This is why I have been using Affinity. Very well done integration of vector and image capabilities. However, their development has slowed significantly in recent years despite having a great product.
I hope that Graphite can be something new and become the blender of 2D image editing. There is nothing really out there right now that has the professional features of paid applications.
This is why I have been using Affinity. Very well done integration of vector and image capabilities. However, their development has slowed significantly in recent years despite having a great product.
I hope that Graphite can be something new and become the blender of 2D image editing. There is nothing really out there right now that has the professional features of paid applications.
> their development has slowed significantly in recent years despite having a great product.
Did they comment on why this happened?
Did they comment on why this happened?
They have not, although I expect it is simply a matter of expanding their products over the years, technical debt and they probably have not generated enough revenue to grow the team.
They are now working on the most important feature in my opinion for the life of Affinity products. They are finally adding built in scripting support that will also enable development of 3rd part extensions. Hopefully this will bring new life and excitement to Affinity.
They are now working on the most important feature in my opinion for the life of Affinity products. They are finally adding built in scripting support that will also enable development of 3rd part extensions. Hopefully this will bring new life and excitement to Affinity.
Affinity is mismanaged and their developers have posted very publicly about being miserable there. The applications are buggy on a good day, unusable on bad days.
The premise sounded nice when I first started using them but I cannot in good conscience recommend either of them to anyone at this point.
The premise sounded nice when I first started using them but I cannot in good conscience recommend either of them to anyone at this point.
> their developers have posted very publicly about being miserable there.
Just curious, do you have a reference?
I've complained on the forums for years about the bugs and Affinity never responds. As I've been using it for years, I figured out how to work around many bugs, but it is a field of landmines for sure.
It is indeed disappointing as it offers the best workflow for the kind of work I do.
Just curious, do you have a reference?
I've complained on the forums for years about the bugs and Affinity never responds. As I've been using it for years, I figured out how to work around many bugs, but it is a field of landmines for sure.
It is indeed disappointing as it offers the best workflow for the kind of work I do.
Their Glassdoor and some Twitter accounts I followed, it's been years though.
Plus if you've ever interacted on their forums their mods are really pushy and dismissive.
Plus if you've ever interacted on their forums their mods are really pushy and dismissive.
> forums their mods are really pushy and dismissive
Yes I agree. I argued with them at length about having a real process for handling bugs that is transparent. They have no method of evaluating the need or priority of anything as they rely only on their forum.
Basically somewhat the gist is that some time ago Affinity decided due to a lot of negative complaints they simply will be less transparent about everything so that nobody could complain. The result of course was obvious, all complaints became about the lack of transparency. Which also resulted in many content creators dropping Affinity because they felt the product didn't have a future as no more communication from the company. So there went their free advertising as well. Terrible management decisions for sure.
Yes I agree. I argued with them at length about having a real process for handling bugs that is transparent. They have no method of evaluating the need or priority of anything as they rely only on their forum.
Basically somewhat the gist is that some time ago Affinity decided due to a lot of negative complaints they simply will be less transparent about everything so that nobody could complain. The result of course was obvious, all complaints became about the lack of transparency. Which also resulted in many content creators dropping Affinity because they felt the product didn't have a future as no more communication from the company. So there went their free advertising as well. Terrible management decisions for sure.
Can you give a source for that? I thought they are doing fine.
They are doing fine for the casual user and you can't beat the price.
However, as I started using it more professionally a few years ago, there are some real problems with long standing bugs in some areas.
My biggest complain at the moment is Art Boards. I use them for almost all my work. Allows me to work much faster when working on a suite of related projects.
However, they are the most broken of all features. Probably half of all the Affinity photo live effects are broken in art boards. Also, not sure which is worse, Affinity or the users. I've opened so many bugs on art boards, to have users push back and say it is not a bug and then Affinity ignores it. They say it is not a bug because most don't use art boards as they never grasp the use case.
However, as I started using it more professionally a few years ago, there are some real problems with long standing bugs in some areas.
My biggest complain at the moment is Art Boards. I use them for almost all my work. Allows me to work much faster when working on a suite of related projects.
However, they are the most broken of all features. Probably half of all the Affinity photo live effects are broken in art boards. Also, not sure which is worse, Affinity or the users. I've opened so many bugs on art boards, to have users push back and say it is not a bug and then Affinity ignores it. They say it is not a bug because most don't use art boards as they never grasp the use case.
This is also my experience. The forums were dismal, everything is "That's not a bug". Sorry, but exporting images from designer that are incredibly blurry for no reason is a bug. Please try explaining resolution to me again, I swear I still didn't understand it after the first few game engines I've made.
Photo also degrades images by blurring them. You see it when you’re building a composition and merging layers as you go; the underlying image gets blurrier and blurrier. Photo simply can’t be trusted not to ruin your work.
This has come up repeatedly in the forums as new users discover it. And yep, the apologists cried and thrashed, issuing one ridiculous excuse after another. Even someone from Affinity.
I wish someone there would teach me about layer blending. I still don’t get it after building high-end compositing software for film.
This has come up repeatedly in the forums as new users discover it. And yep, the apologists cried and thrashed, issuing one ridiculous excuse after another. Even someone from Affinity.
I wish someone there would teach me about layer blending. I still don’t get it after building high-end compositing software for film.
Adobe used to have an app called Fireworks that was great for non-artists. They got it when they bought Macromedia. Too bad they killed it. I hope Graphite will replace it.
Adobe killed almost everything they bought from Macromedia.
Fireworks was the closest thing to figma we got before figma. It was the very best webdev design tool before adobe bought and murdered it.
I remember being excited that Photoshop was going to start to work more like fireworks when they bought it. What a naive dummy I was.
I remember being excited that Photoshop was going to start to work more like fireworks when they bought it. What a naive dummy I was.
I remember it. Fireworks was intended for UI design (like Figma or XD). It had both vector and raster tools, but they were quite basic.
Graphite looks like it could become the jack-of-all-trades app, since its foundation looks very flexible (i.e. the node graph). But, it is in its early development phase and adding necessary features is going to take many years.
Graphite looks like it could become the jack-of-all-trades app, since its foundation looks very flexible (i.e. the node graph). But, it is in its early development phase and adding necessary features is going to take many years.
Related:
Graphite – open-source raster and vector 2D graphics editor written in Rust - https://news.ycombinator.com/item?id=30675530 - March 2022 (18 comments)
Graphite – open-source raster and vector 2D graphics editor written in Rust - https://news.ycombinator.com/item?id=30675530 - March 2022 (18 comments)
I wish it didn't run in a web browser. I know that makes it easy to get working for everyone, but I have never once been able to use a browser-dependent app for anything that wasn't trivial -- and I have tried.
Indeed but by using Rust the project isn't painting itself into a corner. I seriously doubt the promised native versions will be simply shoved into Electron. Making it available on the web makes it easy to try which will help build the project.
Indeed. Not a fan of 'cloud'-based software or apps, because I know where it leads. Ultimate control over my usage by that corporation, and denial of future access through subscription models. Has happened before, and will happen again as everyone lets them get away with it.
This is not exclusive to web apps though (especially open source ones)? I don't see how what you said doesn't apply to the Adobe suite which is native.
It is not a question about the app being cloud based or local, it's more a question about the openness of the file format. With a standardized file format you can always change to another software.
Onshape is professional 3D mechanical CAD in a browser. It’s not at all trivial. Figma is professional graphic/interaction design that’s definitely not trivial. Onshape was acquired by PTC (makers of Creo) and Figma is being acquired by Adobe.
The web browser gives us an extremely frictionless development and deployment process. Our CI generates a fully deploy at a unique link for every commit which lets us open and test PRs with a single click. It deploys updates to users without needing to make them go through an updater. In these relatively early stages of our development process, the importance of the velocity that gives us cannot be understated. Plus, the ability for users to try it out in one second is quite helpful.
I've designed the whole architecture specifically to avoid the web UI "feeling like a web app" with the subtle latency of interacting with the site. I wrote all-custom UI components using the minimal amount of HTML and CSS to achieve the requirements instead of depending on an external component framework which always loves nesting dozens of `div`s inside each other to achieve what should be doable in one or two. And our highly-lightweight JS which calls into Rust (Wasm) lets it keep the slow logic out of slow JS. And we are using Svelte to move most of the frontend DOM management logic from runtime to compile time. This architecture really helps us keep performance levels as close as possible to feeling native despite using the web for its GUI rendering; and I believe it has succeeded at feeling responsive by comparison to most other web apps you use (even Slack, for example, which shouldn't be nearly as complex).
Web lets us build fast, deploy the latest version to users fast, leverage prevalent developer experience with HTML/CSS for creating GUIs, and avoid getting stuck in a box with Rust's currently-immature GUI ecosystem. That's the tradeoff we had to make early on, and it was a good decision. But we will eventually move towards a fully native version...
In the short term, we plan to use [Tauri](https://tauri.app/) which is sort of a hybrid between Electron and a native application. It uses the OS's webview to shrink the shipped binary to only a few megabytes and reuse shared memory resources with other webviews at runtime. It also runs all our Rust code natively instead of through WebAssembly so all the business logic in Graphite runs natively and only the thin UI layer becomes dependent on web tech for the GUI display.
In the long term, we plan to rewrite the entire GUI in [Xilem](https://github.com/linebender/xilem) which is the up-and-coming Rust GUI that I believe will finally get everything right, including performance (which is something many desktop GUI frameworks are actually bad it, and sometimes even worse than web). We'll still deploy a web version but at that point, it will become native-first.
Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.
I've designed the whole architecture specifically to avoid the web UI "feeling like a web app" with the subtle latency of interacting with the site. I wrote all-custom UI components using the minimal amount of HTML and CSS to achieve the requirements instead of depending on an external component framework which always loves nesting dozens of `div`s inside each other to achieve what should be doable in one or two. And our highly-lightweight JS which calls into Rust (Wasm) lets it keep the slow logic out of slow JS. And we are using Svelte to move most of the frontend DOM management logic from runtime to compile time. This architecture really helps us keep performance levels as close as possible to feeling native despite using the web for its GUI rendering; and I believe it has succeeded at feeling responsive by comparison to most other web apps you use (even Slack, for example, which shouldn't be nearly as complex).
Web lets us build fast, deploy the latest version to users fast, leverage prevalent developer experience with HTML/CSS for creating GUIs, and avoid getting stuck in a box with Rust's currently-immature GUI ecosystem. That's the tradeoff we had to make early on, and it was a good decision. But we will eventually move towards a fully native version...
In the short term, we plan to use [Tauri](https://tauri.app/) which is sort of a hybrid between Electron and a native application. It uses the OS's webview to shrink the shipped binary to only a few megabytes and reuse shared memory resources with other webviews at runtime. It also runs all our Rust code natively instead of through WebAssembly so all the business logic in Graphite runs natively and only the thin UI layer becomes dependent on web tech for the GUI display.
In the long term, we plan to rewrite the entire GUI in [Xilem](https://github.com/linebender/xilem) which is the up-and-coming Rust GUI that I believe will finally get everything right, including performance (which is something many desktop GUI frameworks are actually bad it, and sometimes even worse than web). We'll still deploy a web version but at that point, it will become native-first.
Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.
I was unaware that this was still in an early stage of development and am glad to hear of plans to move forward on a native app.
> Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.
Yes.
To expound on my original complaint about web apps in general, my main problems with them are:
* responsiveness -- specifically latency when using the gui, as well as the long staggering pauses when I don't know if I am waiting for the server to respond or if there is an app hiccup or if the thing is frozen (the random long unresponsive breaks is what made me unable to use Roboflow, for instance)
* file management -- having to do everything in the browser is frustrating because of the way the browser is separate from the OS and makes everything an 'app'. Having to import files to some server to work on them is annoying when they are right here in my system. I also like to manage the files in a specific way and have access to program and preference files and know where everything is stored (if it crashes I can find the temp files, for instance). Sandboxing the app from the OS is the opposite of how I want a desktop application to behave
* portability / offline use -- I don't want to login to use an application. I don't want my files on a cloud and I want to be able to use the application forever, even if the original company is defunct
I hope this sheds light on where I am coming from. It seems you thought of at least a few of these issues and are mitigating them.
> Hopefully that roadmap and explanation of the architectural decisions clears up any worries about the short and long term state of our GUI.
Yes.
To expound on my original complaint about web apps in general, my main problems with them are:
* responsiveness -- specifically latency when using the gui, as well as the long staggering pauses when I don't know if I am waiting for the server to respond or if there is an app hiccup or if the thing is frozen (the random long unresponsive breaks is what made me unable to use Roboflow, for instance)
* file management -- having to do everything in the browser is frustrating because of the way the browser is separate from the OS and makes everything an 'app'. Having to import files to some server to work on them is annoying when they are right here in my system. I also like to manage the files in a specific way and have access to program and preference files and know where everything is stored (if it crashes I can find the temp files, for instance). Sandboxing the app from the OS is the opposite of how I want a desktop application to behave
* portability / offline use -- I don't want to login to use an application. I don't want my files on a cloud and I want to be able to use the application forever, even if the original company is defunct
I hope this sheds light on where I am coming from. It seems you thought of at least a few of these issues and are mitigating them.
".... usable instantly through a web browser or an upcoming native client on Windows, Mac, and Linux."
Impressive project, although not what I thought of when I saw the name [1][2].
[1] https://graphite.readthedocs.io/en/latest/faq.html
[2] https://graphite.readthedocs.io/en/latest/who-is-using.html
[1] https://graphite.readthedocs.io/en/latest/faq.html
[2] https://graphite.readthedocs.io/en/latest/who-is-using.html
It’s also now a Code Review platform (https://graphite.dev/) but your example was my first thought as well.
Also a font shaping engine: https://scripts.sil.org/cms/scripts/page.php?site_id=project...
Also a crystalline form of the element carbon.
https://en.wikipedia.org/wiki/Graphite
…wait …am i doing this right?
https://en.wikipedia.org/wiki/Graphite
…wait …am i doing this right?
This name is well established as a trending and graphing open source project:
https://graphiteapp.org/
https://graphiteapp.org/
[deleted]
So this appears to be a successor to Flash?
Yesterday I discovered flash was used to produce Rob Zombie's Dead Girl Superstar (2001) music video: https://youtube.com/watch?v=WpHViVML_4o
I remember watching it on his flash-heavy website during that era, but it never occurred to me that it was anything more than just a recording converted to a flash video.
Yesterday I discovered flash was used to produce Rob Zombie's Dead Girl Superstar (2001) music video: https://youtube.com/watch?v=WpHViVML_4o
I remember watching it on his flash-heavy website during that era, but it never occurred to me that it was anything more than just a recording converted to a flash video.
It's more like they are trying to bring the nose-based workflow to 2D art.
It's already very common in 3D and VFX.
It's already very common in 3D and VFX.
More like somewhere between Photoshop and Illustrator
Fireworks. There was another product from Macromedia that was not Flash, the Macromedia Fireworks. Never thought it would go into oblivion so fast, given I always felt it's of a far superior paradigm than any of the Adobe products in many use cases. After Adobe bought Macromedia, they killed it with all the other Macromedia products in favor of their own.
I miss Fireworks each time i need to make something fast.
Looks like Affinity?
Also a more modern take on Inkscape.
Not quite. Inkscape does solely vector editing and I'd seriously argue Inkscape lacks anything "modern", specially with its latest release.
I really wanted to like Inkscape, though I found it very frustrating to use, the UI was clunky and felt really unpolished.
Affinity Designer on the other hand is really nice to use, and didn't do a bunch of weird stuff exporting SVG files.
Affinity Designer on the other hand is really nice to use, and didn't do a bunch of weird stuff exporting SVG files.
I have really enjoyed the Affinity apps. Really the only competitor left to Adobe.
Unfortunately they have only a fraction of the resources of adobe and their development has slowed significantly over the years.
Their product is just too cheap. It might as well be free. They charged something like less than $50 for a one time purchase and only required a paid upgrade recently after like 7 or 8 years.
Unfortunately they have only a fraction of the resources of adobe and their development has slowed significantly over the years.
Their product is just too cheap. It might as well be free. They charged something like less than $50 for a one time purchase and only required a paid upgrade recently after like 7 or 8 years.
For the longest time, the Mac version of Inkscape was effectively unusable due to a horrible UI port. I don't use Mac, but IIRC they did announce that it was revamped not that long ago.
I wonder if that hurt its adoption since a lot of graphic designers use Mac, so their first impression of Inkscape would've been very poor?
I wonder if that hurt its adoption since a lot of graphic designers use Mac, so their first impression of Inkscape would've been very poor?
Well, this looks quite interesting. I've never used a node-based editor before and I've been using Photoshop since the 90s, and haven't used much else so I don't know what I'm missing.
I took a look at the demo and at first glance, it looks like the current version is just a basic image editor. I don't see any options to add noise, blur, filters, etc.
Also, curious to know about the graphite fileformat. When editing an image, are the set of transformations, etc. suitable for version control?
I took a look at the demo and at first glance, it looks like the current version is just a basic image editor. I don't see any options to add noise, blur, filters, etc.
Also, curious to know about the graphite fileformat. When editing an image, are the set of transformations, etc. suitable for version control?
We're in the process of refactoring a whole lot of code from the pre-node graph MVP implementation to the node graph version, while mainly aiming to avoid losing functionality in the process and not prioritizing new functionality quite as much yet. You can import or draw an image, though, and then right click in the node graph and search for certain effects and filters (similar to Photoshop's adjustment layers) and insert them in the chain of nodes. But to become actually useful, we need a bigger and more thought-out family of nodes combined with tools which automatically insert and update the nodes for you through the means of using the tools and doing lasso/marquee-style selections. Those are all a few months away on the roadmap, but it should be a lot more powerful and novel by then.
The file format will have its own built-in version control in the future, but I believe we are planning to use an ASCII representation so it could also theoretically be version controlled externally. The current `.graphite` files are entirely a temporary format. Once we finish the aforementioned refactor, we will design and implement a proper file format that ensures backwards compatibility (something the current files don't manage at all), it will be called `.gdd` (Graphite design document).
The file format will have its own built-in version control in the future, but I believe we are planning to use an ASCII representation so it could also theoretically be version controlled externally. The current `.graphite` files are entirely a temporary format. Once we finish the aforementioned refactor, we will design and implement a proper file format that ensures backwards compatibility (something the current files don't manage at all), it will be called `.gdd` (Graphite design document).
I've been looking for a node based image editor for a while. It seems like something that would serve the scientific community by allowing people to program complex processes and handle images procedurally. If you aren't familiar, I would suggest you check out ImageJ/FIJI and perhaps consider integrating some of the analytic functionality into Graphite I definitely expect there's a market for it — I don't know anybody that likes using ImageJ.
I have been looking for something exactly like this. I've been using blender's composite mode, but that's so buggy in regards to transparency in the preview
Are there any vector graphics editors that support CAD-style constraints? That’s a holy grail I’ve been searching for but haven’t been able to find.
Not so much constraints per-se, but from a CAD drafting perspective I use Illustrator with Astute's SubScribe [1] plugin (used to be free) and Hot Door's CADTools [2] (one-time cost ~$300). The former is lightweight (e.g. tangency/perpendicular, orient tools) which is pretty nice (especially if you have extend path options from VectorScribe, a separate plugin of theirs). The latter is very robust and probably has some features most people wouldn't need, but lets you get pretty technical with designs.
There's a new UI tool called Dora [3] that has a simple yet novel constraint system that you might like. Tool is still early alpha but growing quickly.
That being said, Graphite's node-based system makes it a viable foundation to build this on! I've helped contribute to the project and Keavon (the creator) definitely has some thoughts on constraint nodes (e.g. for snapping, but also for restraint/relationships).
[1]: https://astutegraphics.com/plugins/subscribe [2]: https://www.hotdoor.com/cadtools/ [3]: https://www.dora.run/
There's a new UI tool called Dora [3] that has a simple yet novel constraint system that you might like. Tool is still early alpha but growing quickly.
That being said, Graphite's node-based system makes it a viable foundation to build this on! I've helped contribute to the project and Keavon (the creator) definitely has some thoughts on constraint nodes (e.g. for snapping, but also for restraint/relationships).
[1]: https://astutegraphics.com/plugins/subscribe [2]: https://www.hotdoor.com/cadtools/ [3]: https://www.dora.run/
Yes, that is very much the plan! I'm glad you asked because it's good to know people are needing that functionality in the real world. It'll probably start out with simple constraints but ideally turn to the constraint stack system like that in Fusion 360 and other CAD software over time. (I need to actually learn Fusion 360 so I have firsthand experience with that, though, plus then I could finally stop just lazily using Blender for all my 3D printing models.)
Not exactly CAD style constraints but close - https://cuttle.xyz/
I'm working on a 2d vector editor that'll have that. It's basically a normal editor but where all properties can be expressions that refer to data or other objects. My first target use is for data visualization. What use cases are you interested in?
Not op but civil engineering (roadway design) is a common use case
Cool! I’ve been using Inkscape for floor plans and landscaping lately. And before that designing a custom split keyboard body. And random things to cut out on my Cricut.
I don’t need a full CAD constraint solver. Just simple constraints would go a really long way (make X the same width as Y; make A spaced N units from B; etc.). Basically just a glorified spreadsheet where object properties can be accessed and read from cells and objects can have other properties assigned from the cells. Though it doesn’t have to be represented as an actual spreadsheet, of course.
I don’t need a full CAD constraint solver. Just simple constraints would go a really long way (make X the same width as Y; make A spaced N units from B; etc.). Basically just a glorified spreadsheet where object properties can be accessed and read from cells and objects can have other properties assigned from the cells. Though it doesn’t have to be represented as an actual spreadsheet, of course.
Does it have plug-in support? Can the plug-ins be written in a different language from Rust, maybe python or ruby?
Plug-ins will (at least for the foreseeable future) take the form of writing custom nodes in Rust. That code will automatically compile to CPU and GPU (unless it requires an allocator or other things not possible on a GPU architecture). In the future that will extend to custom viewport tools, custom panels, etc. either through a traditional plug-in API or maybe even through defining all that in the node graph itself, since the graph is basically its own programming language.
We will probably also need to have bindings into a Python API since Python is so popular among technical artists. Precisely how that will be done is yet to be determined, since we have a lot to do before reaching that point.
We will probably also need to have bindings into a Python API since Python is so popular among technical artists. Precisely how that will be done is yet to be determined, since we have a lot to do before reaching that point.
[deleted]
If you're a dev on an open source project, please hear my plea and stop trying to sell it like you're a hot startup.
Take inspiration from websites from projects such as OBS Studio, Handbrake or VLC (or Blender, but that is a very high bar). Those websites have none of the marketing lingo and all of the to-the-face info presented with easily digestible bullet points and pictures.
(to be clear, I don't have issue with the rest of the website, which is definitely not the case for a lot other projects I've seen)