Nannou: Creative Coding Toolkit for Rust(nannou.cc)
nannou.cc
Nannou: Creative Coding Toolkit for Rust
https://nannou.cc/
31 comments
Thanks for the kind words bjz, it means a lot coming from yourself!
I know you're busy with language design these days (and I would never stop you, I think what you are doing is some of the most important work there is right now!), but if you ever get the itch for some creative coding it'd be an honour to see you give nannou a shot and get your thoughts on what's missing, could be improved, etc :)
I know you're busy with language design these days (and I would never stop you, I think what you are doing is some of the most important work there is right now!), but if you ever get the itch for some creative coding it'd be an honour to see you give nannou a shot and get your thoughts on what's missing, could be improved, etc :)
An Instagram user I follow has a bunch of Nannou demos (unsure if this is also the project's author):
https://www.instagram.com/mactuitui/
Nannou has a pretty long initial setup and build time (about 15 minutes on macOS for me) compared with Processing and similar, but it's worth exploring for the scope and goals it has: https://guide.nannou.cc/why_nannou.html#goals.
https://www.instagram.com/mactuitui/
Nannou has a pretty long initial setup and build time (about 15 minutes on macOS for me) compared with Processing and similar, but it's worth exploring for the scope and goals it has: https://guide.nannou.cc/why_nannou.html#goals.
Thanks for the link! I'm not directly involved in the project (yet), but the team has been so nice to me over the last six months I've been using nannou daily that when they wanted to feature my dailies on the site, of course I said yes!
This is really inspiring. If I wanted to try to create something like this, what would you recommend as a good starting point, is there an existing sample that you based all of these off? Do you release the source code for your art anywhere or just the final product?
I've been doing this since ages, so these's a lot of intuition going on, and I've a quite significant list of sketches at this point, so I personally start with a lot of convenient tools already.
To learn about the different techniques and mostly to get to know the basics I cannot recommend enough the amazing Daniel Shiffman ( https://twitter.com/shiffman/ ) and his awesome "The Coding Train" video series on youtube: https://www.youtube.com/user/shiffman
I usually do not release the code for my dailies, but I'm getting a few of them ready to include as examples for nannou, there's a PR with one example already up. I'm also always open to talk about the "how" I did something and to give you a pseudo-code version of what I'm using.
To learn about the different techniques and mostly to get to know the basics I cannot recommend enough the amazing Daniel Shiffman ( https://twitter.com/shiffman/ ) and his awesome "The Coding Train" video series on youtube: https://www.youtube.com/user/shiffman
I usually do not release the code for my dailies, but I'm getting a few of them ready to include as examples for nannou, there's a PR with one example already up. I'm also always open to talk about the "how" I did something and to give you a pseudo-code version of what I'm using.
Excellent. I found the PR and was able to run it, I think that will make a good starting point for experimentation.
I'm a game developer so pretty experienced with rendering but not so much with Rust, Vulcan, etc and haven't done a lot of this 2D "demoscene" sort of stuff, so I don't know all the neat tricks there., and it is not immediately obvious what kind of techniques you use to get the cool results that you are getting.
I had a look through some of the existing examples in nannou (under the generative_design folder) but found the existing ones to be extremely uninteresting. Your PR is a great non-trivial example with inspiring results.
Your instragram feed makes these all seem like beautiful mysterious artwork. It love it if there was a "making of" blog which described your thought process going from one to the next, as I imagine you aren't rewriting them each from scratch but making small tweaks on an existing idea each time.
I checked out the Coding Train, there is such a wide range of content there, was there a particular episode that inspired a lot of these designs?
I'm a game developer so pretty experienced with rendering but not so much with Rust, Vulcan, etc and haven't done a lot of this 2D "demoscene" sort of stuff, so I don't know all the neat tricks there., and it is not immediately obvious what kind of techniques you use to get the cool results that you are getting.
I had a look through some of the existing examples in nannou (under the generative_design folder) but found the existing ones to be extremely uninteresting. Your PR is a great non-trivial example with inspiring results.
Your instragram feed makes these all seem like beautiful mysterious artwork. It love it if there was a "making of" blog which described your thought process going from one to the next, as I imagine you aren't rewriting them each from scratch but making small tweaks on an existing idea each time.
I checked out the Coding Train, there is such a wide range of content there, was there a particular episode that inspired a lot of these designs?
I wrote a bit about the process here: https://medium.com/@mactuitui
As for the coding train, there's a few examples where I actually got directly inspired: the fluid simulation was a great one as I was always afraid that this might be too much work; this showed me I could actually do it in a day (but be vary that that his particular implementation has a few bugs).
If I look at one recent example, maybe raycasting is interesting. How would I make that look nice? Maybe I'll start by having a simple scene with a few regular walls but a circle of point sources that would rotate in a loop. Maybe I'll find a way to make the walls move in an interesting fashion. Or have the rays propagate through time and have a contest of flashing lights.
But what Daniel is good at is explaining some of the techniques used behind this type of work, it is not about the "how to make it look cool".
Now that I think of it, there's one thing that might be fun to do is to work though Casey Reas's Process series (linked here: http://reas.com/text ). It's a set of "elements" that have predefined behavior (but described as text) and a set of "rules" to represent how those elements interact. There's a lot of freeway since it's text; you might find something interesting by yourself here.
The point is that there is no right or wrong way to do things here, it's mostly a matter of "does it look good". That requires to think about all the points that make art look good, so you'll have to think about contrast, balance, composition and everything. But having something to show is half the battle/
The particular example in the PR is indeed based on the previous days before, there is a lot of overlap in the techniques used and it can be pretty opaque to understand but at its core it's a system that generates a tree by making elements grow/branch out according to some "energy" that is coming from the root (iirc). The other half of the issue is how to make this process look good.
As for the coding train, there's a few examples where I actually got directly inspired: the fluid simulation was a great one as I was always afraid that this might be too much work; this showed me I could actually do it in a day (but be vary that that his particular implementation has a few bugs).
If I look at one recent example, maybe raycasting is interesting. How would I make that look nice? Maybe I'll start by having a simple scene with a few regular walls but a circle of point sources that would rotate in a loop. Maybe I'll find a way to make the walls move in an interesting fashion. Or have the rays propagate through time and have a contest of flashing lights.
But what Daniel is good at is explaining some of the techniques used behind this type of work, it is not about the "how to make it look cool".
Now that I think of it, there's one thing that might be fun to do is to work though Casey Reas's Process series (linked here: http://reas.com/text ). It's a set of "elements" that have predefined behavior (but described as text) and a set of "rules" to represent how those elements interact. There's a lot of freeway since it's text; you might find something interesting by yourself here.
The point is that there is no right or wrong way to do things here, it's mostly a matter of "does it look good". That requires to think about all the points that make art look good, so you'll have to think about contrast, balance, composition and everything. But having something to show is half the battle/
The particular example in the PR is indeed based on the previous days before, there is a lot of overlap in the techniques used and it can be pretty opaque to understand but at its core it's a system that generates a tree by making elements grow/branch out according to some "energy" that is coming from the root (iirc). The other half of the issue is how to make this process look good.
This looks really cool! Is it a coincidence that this has the same name as the Aphex Twin song?
nah, it's named after the song (according to the docs - https://guide.nannou.cc/why_nannou.html)
Very cool, especially considering UI is still somewhat underserved in Rust.
Learning rust while doing the raytracer challenge. this Looks amazing! does it work with wasm?
It has moved to Vulkan, so unlikely...
Hey kvark, I really appreciate all the work you're putting into the Rust graphics ecosystem!
Just fyi, we are closely watching both wgpu-rs and rendy and will continue to do so over the next couple of months. Vulkano has been a mission to use to say the least, maintainership is dwindling (most of the recent PRs are from us), and the Rust graphics landscape has changed quite a bit since we made the decision to use it almost a year ago. Both wgpu and rendy seem like strong contenders for the future of nannou's graphics, but we probably won't go down that road for a couple more nannou releases at least while we focus on some other areas.
We're particularly interested in rendy's render graph [1] approach to a higher-level, near-zero-cost API. Are there plans for something similar in wgpu?
Also, I realise that wgpu is web-first, but I'd be curious to get your thoughts on its potential for use in native applications for installations and projection mapping - e.g. will it be possible to spawn multiple swapchains for multiple windows? Or will it be purely focused on a single window web experience?
Anyway, we'll do another post soon about our thoughts on the future of graphics in nannou, just wanted to let you know you're on our minds :)
[1]: https://github.com/amethyst/rendy#rendergraph
Just fyi, we are closely watching both wgpu-rs and rendy and will continue to do so over the next couple of months. Vulkano has been a mission to use to say the least, maintainership is dwindling (most of the recent PRs are from us), and the Rust graphics landscape has changed quite a bit since we made the decision to use it almost a year ago. Both wgpu and rendy seem like strong contenders for the future of nannou's graphics, but we probably won't go down that road for a couple more nannou releases at least while we focus on some other areas.
We're particularly interested in rendy's render graph [1] approach to a higher-level, near-zero-cost API. Are there plans for something similar in wgpu?
Also, I realise that wgpu is web-first, but I'd be curious to get your thoughts on its potential for use in native applications for installations and projection mapping - e.g. will it be possible to spawn multiple swapchains for multiple windows? Or will it be purely focused on a single window web experience?
Anyway, we'll do another post soon about our thoughts on the future of graphics in nannou, just wanted to let you know you're on our minds :)
[1]: https://github.com/amethyst/rendy#rendergraph
Wow, thanks for such a detail response!
Delaying with decision to adopt Rendy or wgpu-rs is reasonable: both are still maturing, and are in the early adopter phase.
> We're particularly interested in rendy's render graph [1] approach to a higher-level, near-zero-cost API. Are there plans for something similar in wgpu?
No, this would not ever be in wgpu (or feasible on top of WebGPU in general), since it's providing safety at lower level, and there is no way to get near-zero-cost there.
Saying that, I'm not sure what the bottlenecks of your use-case are. Do you plan on submitting a lot of different work on GPU, i.e. heavily use command recording on CPU (as opposed to relying on GPU instances), to the point of being sensitive to CPU performance? My expectation from a creative coding framework would be that zero-cost is not the foremost priority.
> will it be possible to spawn multiple swapchains for multiple windows? Or will it be purely focused on a single window web experience?
Yes, I think this is already possible in wgpu-rs, although nobody tested multi-windows yet. In general, we put heavy focus on native usage.
Looking forward to your post!
Delaying with decision to adopt Rendy or wgpu-rs is reasonable: both are still maturing, and are in the early adopter phase.
> We're particularly interested in rendy's render graph [1] approach to a higher-level, near-zero-cost API. Are there plans for something similar in wgpu?
No, this would not ever be in wgpu (or feasible on top of WebGPU in general), since it's providing safety at lower level, and there is no way to get near-zero-cost there.
Saying that, I'm not sure what the bottlenecks of your use-case are. Do you plan on submitting a lot of different work on GPU, i.e. heavily use command recording on CPU (as opposed to relying on GPU instances), to the point of being sensitive to CPU performance? My expectation from a creative coding framework would be that zero-cost is not the foremost priority.
> will it be possible to spawn multiple swapchains for multiple windows? Or will it be purely focused on a single window web experience?
Yes, I think this is already possible in wgpu-rs, although nobody tested multi-windows yet. In general, we put heavy focus on native usage.
Looking forward to your post!
What a coincidence, I've been using Clojure with Quil recently and bumping up on the limits of what it can do easily, so I've been thinking about my options.
I was going to settle in tonight and take a look at using Common Lisp and OpenGL directly, but I'm interested in Cinder or openFrameworks but would rather play around in something other than C++.
I'll add nannou to my list but does anyone have any other recommendations?
I was going to settle in tonight and take a look at using Common Lisp and OpenGL directly, but I'm interested in Cinder or openFrameworks but would rather play around in something other than C++.
I'll add nannou to my list but does anyone have any other recommendations?
Speaking of creative coding, does Rust have an official GUI package yet?
To my knowledge there is no clear dominant package but things are improving quickly : https://areweguiyet.com/
Is it likely that Rust will have support for hot reloading? I love the language, but having a fast iteration cycle is essential for this type of work.
Depending on what you mean, it does: https://github.com/phaazon/warmy
It would be nice to see some examples with code. The showcases section is empty.
At least there are a bunch of example: https://docs.rs/crate/nannou/0.9.0/source/examples/
It would be nice if they had included images/gifs.
I just finished making some short gifs that show some of the compiled examples. Thanks again for the suggestion. https://github.com/nannou-org/nannou/tree/master/examples
That's a great idea. We will start to put together a table or pictures that shows the resulting window of each compiled example. Hopefully have this up in the next few days. Thanks for the suggestion!
The author talks about some of their projects, with videos, here: https://www.reddit.com/r/rust/comments/byyu30/vulkan_lasers_...
Thanks!
https://nannou.cc/posts/nannou_v0.9
Being a big Processing fan, and a bit of an artist too, this kind of creative framework is something I have been hoping was available way back when I started playing around with Rust in late 2012. Thanks goes to the Nannou team for all their hard work over the years in making this possible!