NIMk Sprint day 1 and 2

This is my update from Amsterdam on day two of our Naked on Pluto residency. Marloes’ report on day 1 is here.

Today was all about taking the themes from yesterday and making them into concrete game mechanics we can use. We started by mapping out possible constraints imposed by multiplayer activities. We want a large amount of what you do on pluto to be coordinated with other players – and this impacts on the logic of the game world. For instance, doors can be locked – sometimes in a room full of people we only want players who are carrying a key to be able to get through the door, at other times a single player might be able to unlock a door for everyone (perhaps for a limited time).


A locking conundrum.

This sort of play requires a way for players to coordinate with each other, for example using a realtime chat system. A minor crisis involving the details of how to handle this feature was narrowly averted and we escaped to the shores of Ljsselmeer to begin considering the vertical slice, the moustache as core game feature, community service and mandatory fanny packs.

Meshed feedback

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)

Particle filters

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.

Accidental graph art

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.

Voxels in fluxus

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 30x30x30 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: