Fluxus and Voxels and long rendering times
Following on from previous Voxel Debut, it seemed a good idea to visualise the data using Fluxus, as a (fresh faced, enthusiastic, sort of stressed) newbie to live coding visuals. Before this stint, I had never really worked with 3D and animation, so thinking this way has been an entirely new concept to me, alongside learning Fluxus (& Scheme, in general). With a couple of Algoraves coming up this week, an incubated week of intense livecoding and voxels is entirely necessary. I have found, so far, that focusing on either is in turn helping my understanding of the other.
To represent the voxels in Fluxus, I wrote out 150x150px cropped sections of each GeoTIFF as PNGs, which could then be loaded into Fluxus as primitives, the data of which could be mapped to a voxel primitive. A brief pit stop to animate this was needed.
This was then converted to a poly primitive (via blobby, ~ofc~, much to Amber’s amusement) and saved as an OBJ file… this can be imported in the future, to save rendering times. The example below took half an hour to render – the joy of waiting! I don’t think that would suit the temporal and time sensitive nature of live coding, at all.
(string-append "voxels_ok/mk" (number->string index) ".png")))))
(define p (build-voxels 150 150 31))
(lambda (index colour)
(list-ref files (inexact->exact (floor (/ index (* 150 150)))))
(vector 0 0 (* 10 (vx(pdata-ref "c" index))))))
(define blob (with-state
(define pol (with-state
(translate (vector 0 0 0))
The saving of the OBJ file again paves the way for further voxel adventures. In terms of performance, it will be interesting to manipulate the poly primitive, even as the opacity tweaking above gives good results… and slightly humorous (to me, possibly only myself & I) to base a performance on a city I have never been to. But visually, the aesthetic of navigating a very real area as green space could end up being really quite immersive.