Nannou: Creative Coding Toolkit for Rust
nannou.cc
nannou.cc
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!
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 :)
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.
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.
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?
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.
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 :)
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!
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?