dave’s blog of art and programming

user generated content

And some more – must get on with some proper work today…

Still distracted, tried using the new (voxels->blobby) command to use the marching cubes algo in fluxus to mesh the feedback into a solid shape. The code is posted below.

(clear)

; make some voxels
(define vx (build-voxels 50 50 50))

; do the feedback
(for ((i (in-range 0 40)))
     (with-primitive vx ; not sure what's happening here
      (voxels-sphere-influence (vector 0 0 0) (vector 1 1 1) 0.2)
      (voxels-calc-gradient) ; <- probably repeated application of this...
      (voxels-point-light (vector 0 0 0) (vmul (vector 1 1 1) 0.5)))) ; <- and then this does the trick

; make a blobby from the resulting voxels
(define bb (voxels->blobby vx))
(destroy vx) ; dont need the voxels anymore

; convert to polygons
(define pb (with-state
    (scale 5)
    (blobby->poly bb)))

(destroy bb) ; don't need the blobby any more

; calculate normals and make shiny
(with-primitive pb
    (recalc-normals 1)
    (shinyness 50)
    (specular (vector 1 1 1)))

; slap on some lights
(light-diffuse 0 (vector 0.1 0.1 0.1))
(light-specular 0 (vector 0 0 0))
(let ((l (make-light 'point 'free)))
    (light-diffuse l (vector 1 1 1))
    (light-position l (vector 0 30 10))
    (light-specular l (vector 1 1 1)))

(let ((l (make-light 'point 'free)))
    (light-diffuse l (vector 0 0 0.6))
    (light-position l (vector 0 -50 50))
    (light-specular l (vector 0 1 1)))

(clear-colour 0.5)

Trying to write some documentation for the voxels primitive in fluxus, I was completely sidetracked by this accidental discovery:

A particle filter is a technique used in computer vision to estimate the state of a system, given noisy data from fallible sensors. The underlying idea is called a hidden markov model, and looks something like this:

The assumption is that any state of the system is dependant on it’s previous state (and thus all previous states) and this state is something we can never know directly, only via observations. There are two very different sources of inaccuracy or noise. One originates in the state change process – as it’s assumed we can never have a complete model of this (a good bet in the case of human actions for example). The other source of noise is in the observation process itself, which comes from the way the sensors work. This is more predictable, and filters of this type are built to allow you to account for this.

Particle filters maintain a multitude of hypotheses of the hidden state of the system at the same time. They attempt to model state changes in some basic way, for instance the velocity of a moving object. They also model the observation process, for example a distance/angle reading of an object in x,y space. Each time a new observation arrives, the system grades each particle’s simulated observation against the incoming one and weights them accordingly.

This is a frame from some particle filter code I’ve written which is tracking an object as described above. The line is pointing to the current estimation which is based on readings from a radar like sensor. I’ve told the system that the heading sensor is less reliable than the distance sensor, and so the particles are spread out in a vague crescent shape accordingly. This shape is called the probability distribution function (or pdf) and it’s a strength of particle systems to model complex pdfs such as this effectively.

If I ran one of these new fangled ‘new media arts’ courses (or whatever they are called now) I’d force students to restrict themselves to only using graphviz for several months. These are some accidents which happened trying to visualise haplotype networks for some biology visualisation work I’m doing:

Alex Mclean has some more impressive graphviz drawings here. I’m actually having to abandon graphviz as it wont cope with different length edges very well. I expect this will come back to bite me.

I’ve rewritten the experimental scheme voxel code into experimental C++ fluxus code, using hardware rendering for the sprite ’splat’ accumulation, which makes it realtime for 30×30x30 grids (27000 voxels).

The last two are a bunch of concentric spheres with the top left corner carved away by a box.

Part of the fun of this is figuring out a scene description language for volumetric data, currently you can create solid spheres or cubes, spherical influences from points, add/subtract them from each other, threshold and light them. Here’s a test with a million voxels, which surprisingly still leaves fluxus interactive, if not actually workable for realtime animations:

And a short movie of spheres carving each other up as they move around:

One day, when we have flying cars and people live on the moon, there will be no more triangles in computer graphics, only voxels. I somehow ended up spending the whole day today playing with the stalin scheme compiler and writing a small voxel renderer. These fuzzy blobs are the results:

Just found this movie from a few months back – some accidental plant weapons:

Last night I combined whisky and a zx spectrum emulator for some nostalgia infused livecoding. As with many such indulgences, some regrets the morning after.