But really, it's more of a 'well most of the time it's 2π' so maybe it makes sense to use the constant that represents that number, and since we're talking about small details, '2.0*PI' is also longer than 'TAU' to type.
Yes, there's always people doing things differently, with different targets, and amazing results. I don't think it matters when it comes to the 'for real' factor of the practice though.
I could say that I've been doing daily animations for the past 1580 days, and that's definitely real in my book. Your call.
2. If you were following my talk at GitHub universe yesterday where I was livecoding (archive will be up "soon"), the rebuilds are fast enough I don't really care (simple stuff are <3s for me, even my latest dailies where I have heaps of extra stuff are averaging <6s rebuild time). The compiler (via lsp) catches most bugs beforehand, so I would say it is not very much an issue at this point. Using a cargo cache will make things far easier as well.
3. Exactly why I started using nannou (coming from using processing via scala)!
As for the "why nannou?", and sorry for being nerdy, but nannou is the only framework I know of that does color right: you are working "naturally" in LinSrgb with float16 precision per channel (if that does not speak to you, just look for gamma correction and go down the rabbit hole). The blending of color is exceptional if you're into that sort of things (I am: see for example in HQ https://superrare.co/artwork-v2/road-to-nowhere-12621 )
Nannou is also focused towards the future: there's been a couple of major backend rewrites from opengl to vulkan then webgpu (without any issues for the end-user if you were using the core nannou api functions): you get to play with the latest toys and finally you get access to your whole GPU. No need to stay in a OpenGL-centric state based workflow (that does not make any sense since years)! I've been able to run crazy compute shaders passes while making my own render pipelines _on top of what nannou does_. It's crazy powerful.
Also I have to say the team behind nannou has been wonderful in dealing with my requests over the last two years, and they always provided help when I needed (to be honest, I chose nannou because the team was in Australia, and as I am in Japan, it made communication easy). Huge thanks to them. Have a look at the github issues to see how nice the team is.
And with cargo, I'm confident (not very confident, mind you, but optimistically confident) that I'll be able to get the thing building again in a few years.
So if your interest peaked a bit, please try it, if you have any questions, join the matrix chat and ask away!
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.
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.
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.
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!
But really, it's more of a 'well most of the time it's 2π' so maybe it makes sense to use the constant that represents that number, and since we're talking about small details, '2.0*PI' is also longer than 'TAU' to type.