I had a thesis proposal draft due this week, followed by the last calm week where I could do the heftier fixes before needing to focus on getting my demos to work for members’ week.
I am realizing that the per-line buffer data is another way to put interesting info into the shader in a way I haven’t before.
For a long time, the only parameters getting into the GPU were through uniforms and shader code, which had to apply to the entire image.
I could also send data through colors written to a texture going into the shader (but I’m usually disappointed because of anti-aliasing from the Nannou drawer into the GPU. I have something off there. I’ve worked around it in the past by scaling up the draw texture and then sampling it.)
So I had been using shaders by drawing a giant pair of triangles over the entire screen. This summer, I started a few sketches that built my shapes out of triangles. My understanding is that this is typical 3D computer graphics, but I’ve been learning computer graphics as I go, and I just finally needed the triangles to get smoother gradients.
Anyways, having the GPU triangles associated directly with the objects means I can finally send in properties about a particular shape into my shader in a better way than through the pixel colors. Like I could do the “position of an object in the grid-pattern”, which I use a lot in CPU-land.
So for this project, I’m back to my two giant triangles, but they get in all of the lines. And the lines can also have data passed in with them!
(And… as I’m writing this, I’m wondering if I could have done this if I had just made a bunch of triangles? I think I already tried that.. But I guess I’ll have to try that again someday.)
I wanted to demo the active learning robin from this summer, but after some changes, the robin was taking nearly 5 seconds to render.
I’m not totally sure how much this mattered, but the SVG was also an MB. I had some old code where Catmull-Rom was manually adding points, and I switched that to adding a Bezier curve, so that should both look smoother and take fewer pixels.
An ongoing slow part of my code is computing the thickness of feathers from a live-coded function. I did another optimization pass on that.
The first part was to approximate the line by recursively splitting the line, and stopping early if the computed thickness is close to the midpoint of its neighbors. It didn’t really cut down the time without degrading the quality, but at least it gave me an easy dial to turn to make much quicker versions.
The other part of the computation is the main evaluation. I use the same thing for UnitCells (like when I have a grid of objects), but for some reason the “Lazy” ones (where I can per-sketch custom variables, for example, the position along a feather) still run a lot slower. I had a quick win by switching some more things from clones to reference counting. I tracked down another source of slowness to when I cloned the contexts, and I added extra information to it. I found out EvalExpr has a trait, so I could implement my own struct that holds an Arc to the parent context as well as a vector of the new variables being added.
Something I’ve been looking forward to was my Vision in Art and Neuroscience class going on a field trip to Mass MoCA! We got a view of fall foliage in northwestern Massachusetts and spent time in the largest Ganzfeld (a space with uniform lighting), James Turrell’s Perfectly Clear. It was a treat to see multiple of Turrell’s pieces in one place. I have to mention the skyspace we had at the Claremont Colleges, so I get some undergrad nostalgia when I see other work.
I also got to see the three floors of Sol LeWitt in “Sol LeWitt: A Wall Drawing Retrospective.” I liked the ink washes used in the earlier work, and seeing so many pieces.