(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)

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.

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.

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: