Create Universes

The Cave - fugue @ Syntax 2011

2011-11-18T17:51:00.000+11:00

This demo uses an engine similar to wtf-atabimp, with a few new features, such as high speed OpenGL rendered voxels and a clean up of the mp3 playing code. All voxel operations (such as "adding" and "carving out" voxels) are done in constant time, with the "housekeeping" of the voxel render list occuring at render time.

This demo is built on a framework that allows the entire demo to be driven by lua. The lua files are included, and can be modified freely. There is also a console available from the demo itself, providing a "live coding" environment which permits complete modification of the demo while it is running. There is an unmarked pane splitter at the bottom of the window which can be moved to reveal the console. The console now maintains a persistent session, so the command history is maintained between runs.

Thanks to cTrix for his wizardry in creating this awesome music for the demo!

WikiReader Forth Simulator - update

2011-10-24T16:51:00.010+11:00

Now features:

Stack window refreshes after every command
WikiReader style boot menu
New sample programs
Added SP@ word
WikiReader consistent implementation of PICK
Found and fixed a memory corrupting crash bug in Ficl Forth associated with the LOCALS| word. WikiReader Forth doesn't support LOCALS| so this is moot.
Includes a scroller sample which doesn't use LOCALS| or PICK

Nokia E71 live coding - update

2011-10-24T15:08:00.007+11:00

This update features:

Single application instead of 2 separate applications
Full use of E71 keyboard - all characters accessible using bottom left meta key, no need to use Nokia special character dialog
Tested on the Nokia C5
Trace window with go to error capability
Console with history and persistent session
Saving and loading console sessions
Integrated editor with go to line and search functions
Editor and Console use fixed width font
Several sample programs included with installation

Lua based live coding tools for the Nokia E71

2011-06-18T18:35:00.003+10:00

Installing

Using Nokia PC Suite, install the following .sis files:

qt.sis
LiveCode.sis
TextEd.sis
spectrum.sis

They can be installed in any order.

After installing, its handy to map the hardware buttons mapped so they start LiveCode, TextEd and spectrum to save you from having to traverse the menu every time you want to make a change to your lua code or see the effect of your change.

Running the tools

LiveCode and TextEd together provides a basic and fun live coding environment for Nokia mobile phones. When you run LiveCode, it loads a file called livecode.lua in the Root directory of the phone memory to retrieve the newest definitions of the update and render functions. Running the TextEd program after this will open livecode.lua for editing in a basic text editor, where any lua code may be written and update and render can be redefined. After making your changes and saving, you can return to the running instance of LiveCode, and reload your definitions of update and render by hitting any key on your phone.

I've included a small set of samples to get you started. Place them in the Root directory of the phone memory, rename one of them to livecode.lua then start the LiveCode program to try it out! If you read the samples, you'll see the only callback currently defined is drawLine, which takes 4 numbers to specify the endpoints of the line to be drawn. This function can only be called inside render.

Audio coding with spectrum and lua

I have also provided a version of the spectrum demo with a slight modification - this version allows the waveform to be specified from lua. The spectrum program reloads the file spectrum.lua whenever the mode settings are changed to obtain the newest definition of the calcsample function, which it uses to compute the waveform. If you open TextEd after opening spectrum, TextEd will allow you to edit the spectrum.lua file. Starting the LiveCode program will tell TextEd to go back to editing livecode.lua the next time it starts.

The original version of the spectrum demo comes from the Qt SDK, available from qt.nokia.com

wtf-atabimp - fugue @ Flashback 2011

2011-06-18T07:43:00.006+10:00

This demo is built on a framework that allows the entire demo to be driven by lua. The lua files are included, and can be modified freely. There is also a console available from the demo itself, providing a "live coding" environment which permits complete modification of the demo while it is running. There is an unmarked pane splitter at the bottom of the window which can be moved to reveal the console.

This is my first demo, and I wrote it this way to permit the protoyping of different effects easily. In this demo, there are only 3 effects:

A 3D braitenberg vehicle simulation, where 200 randomly placed objects self organize into a group of 3D curves
An animated heightmap
A randomly generated group of polylines with a bunch of triangular guys moving along them.

Synthbench - Flashback update

2011-06-17T18:01:00.007+10:00

I presented this version at Flashback 2011. It features:

Generator and controller elements that use lua specified waveforms
A continuously running tracker where instruments can be assigned to the tracks using "music" effect elements
Completely scriptable operation. From the lua console it is possible to construct the table, and manipulate all its controls including the data in the tracker or the waveforms in the lua generators and controllers over time.
Update callbacks which are called at 20Hz, and also after each note played by the tracker
The delay effect now mixes the input with a delayed version of itself
There are also 3 filter effects - band pass, high pass and low pass filters

I'm in the process of uploading some videos demonstrating the new features. They will appear in this youtube channel.

There are some example scripts which demonstrate how to use the scripting features. You can also refer to the readme file for further documentation.

WikiReader Forth Simulator

2011-03-19T18:56:00.019+11:00

I bought a WikiReader recently, which apart from being a 4GB text only offline version of Wikipedia, comes with a fun feature where it can run any Forth programs which are placed on its internal mini SD card. I wrote this program so I could test my small Forth programs without having to swap the mini SD card in and out repeatedly. The current version can run most of the test programs exactly as they appear on the SD card very faithfully. This app uses a Forth interpreter provided by the open source embeddable Forth implementation FICL (http://ficl.sourceforge.net/), and it works by providing device specific words as callbacks to a simulated WikiReader. It implements enough now to be useful, including the framebuffer functions, GDI functions (including text rendering using the device's font) and input functions, so I'm releasing it.

Usage:

See simlib.4th for the list of device specific words supported by this simulator, as well as simtest.4th for some simple examples. The other Forth programs included are the ones which come with the device and which I've tested on this simulator. Please refer to them for more reference material when writing your own programs.

The console supports multi-line commands. To enter a multi-line command, press ctrl-enter for a new line. The console also keeps a history of all commands entered. To navigate the history, press ctrl-up or ctrl-down. Pressing up or down without ctrl will move the cursor around the console.

To simulate moving your finger over the screen during the execution of your Forth command or program, move your mouse over the screen while holding down the left mouse button. To simulate hardware key presses, the hardware keys are mapped as follows:

Search	Q
History	W
Random	E

A note about the calculator progam, calc.4th:

The calculator program is not completely identical to the original version on the retail device, because the version on the device has a bug. I found the bug while writing this simulator, and submitted a bug report. Here is a link to the bug report. To see the bug for yourself, on your device, try the following calculation: -75 + 5 =. The result it gives is gibberish, and when trying it on the simulator with the original calc.4th, a stack underflow occurs. Fortunately, I believe I have fixed the bug, and have included the fixed version of calc.4th in the simulator. You can transfer this fixed version to your device as well.

Here are the downloads for the fixed calculator:

calc.4th
calc.patch (so you can see what I changed more clearly)

Screenshots:

Synthbench - A Reactable Simulator - Update 4

2011-02-04T19:24:00.004+11:00

This is still a limited early release. This update features sine and square wave generator and controller nodes, as well as 2 effect nodes - a band pass filter, and a delay effect. The output node now accepts multiple audio sources.

I've modified the look so it is closer to the style of the Reactable. Square nodes are generators, circular nodes are controllers, and square nodes with rounded corners are effects. I'm still using text to label the nodes though - the labels are "sin" for sine wave, "sqr" for square wave, "del" for delay and "bpf" for band pass filter. I also haven't bothered with rotating the nodes just yet.

Synthbench usage video

2010-12-23T14:56:00.019+11:00

Synthbench - A Reactable Simulator - Update 3

2010-12-16T23:24:00.002+11:00

This is a bug fix release for the Synthbench_2010_12_16 version. The output node no longer auto connects when dragged. Prior to this fix, when the output node was dragged, it instantly tried connecting to itself, resulting in bizarre behaviour. Also, the output node is now labeled appropriately.

Synthbench - A Reactable Simulator - Update 2

2010-12-16T16:13:00.004+11:00

This is a bug fix release for the Synthbench_2010_12_14 version. The program should no longer hang regardless of the node network you try to create.

Whenever there is a cycle in the network, Synthbench no longer hangs - the nodes in the cycle merely stop updating.

Synthbench - A Reactable Simulator - Update 1

2010-12-14T16:16:00.004+11:00

This program is inspired by the Reactable, and it attempts to simulate it. This is a very limited early version - the project is an excercise in audio programming.

Differences between this version (2010_12_14) and the previous version (2010_12_03):

Its possible to add new nodes to the table by dragging them from the palette
The nodes auto-connect and disconnect as you drag them. Controller nodes connect to generators and other controllers, while generators only connect to the output node. Also, a node won't auto connect with a node further away from the output node than it is, encouraging radial node layouts. I may change this rule.
The nodes are labelled - generators are labelled "g", controllers are labelled "c".
The controller nodes modify a parameter away from the base setting, which means that manipulating the sliders will have an effect even if a controller node is connected.

Controls:

Move a node by dragging it with the left mouse button
Pan the view by dragging an empty spot with the left mouse button
Zoom the view by dragging an empty spot up and down with the right mouse button

Limitations and known bugs:

The output node doesn't do any mixing - it accepts only one input from a generator node
In fact, all the nodes accept only one input at the moment, which means the only thing you can make at the moment is a chain.
The only parameter a controller will modify is the period
The program might hang if you make a complex structure it can't support - only make a chain for now.

Despite these limitations, you can still achieve some interesting effects.

Coming up in the next version(s):

Low/high/band pass filters nodes and other effect nodes
Sequencer nodes
Controller nodes affecting more parameters
Improving the look - possibly switching to 3D so effects can be added
Make more use of the Lua console

Synthbench - A Reactable simulator

2010-12-03T01:40:00.002+11:00

This program is inspired by the Reactable, and it attempts to simulate it. This is a very limited early version - the project is more of a proof of concept which provides an excercise in audio programming. You can still have some fun with it though. The table layout consists of a sinewave generator, with a sinewave controller controlling it. Selecting the sinewave controller (the node on the left) allows you to modify its parameters using the sliders at the top of the window.

The Lua scripting pane is a functional Lua repl that allows you to enter multi-line Lua expressions and programs, although isn't tied to anything in the simulator yet.

A better, actually useful version is coming soon.

Syntax Party 2010

2010-11-20T19:19:00.003+11:00

I attended Syntax Party 2010 this year. I've always admired the demoscene from afar, so when I heard there was going to be an event in Melbourne, I had to go and see it. I ended up having the time of my life! The venue was filled with like-minded, friendly, enthusiastic programmers and artists all eager to show their creations, and to query in detail about the creations of others. People from all over Australia arrived to code and party all weekend, and the atmosphere was relaxed and fun. Even though I didn't have a production prepared specifically for the event, I was encouraged to enter some of the programs I had been showing people during the event. They were Mechabach and Ball Game, and they were both well received. I've made some great new friends, including an ANSI artist named Ozzy who created a logo for my new handle, "fugue":

I look forward to next year's Syntax Party event in Sydney!

Mechabach

2010-08-19T15:16:00.002+10:00

This program demonstrates a simple procedural composition technique for automatically generating contrapuntal compositions. Sounds completely crazy? Try it.

When you run it, it generates a file called "test.mid", and proceeds to open it with the default midi playing program you have installed. I suggest using MAMPlayer, because of its visualisation of the midi file as it plays it.

What is it doing?

It generates several independent tracks, one note at a time. Notes inside beats 1 and 3 are always notes in the tonic chord, and notes inside beats 2 and 4 are always notes in the dominant 7th chord. Since it always works in C major, the tonic notes are C, E and G, and the dominant notes are G, B, D and F. Also the note that is chosen is either the nearest or 2nd nearest higher or lower note to the previous note that is part of the chord it is assigned to. The choice about whether the note is higher or lower, or is the nearest or 2nd nearest is a random choice. For example, if the previous note is C, and the next note falls inside the 2nd beat of the bar, then it may either choose the D or F above the C, or the B or G below the C. As for the rhythm, there are 3 rhythms, each 1 bar long. These are 4 crotchets, 8 quavers, or a hopping rhythm of 4 repeats of a dotted quaver and a semi-quaver. Every bar, it chooses randomly from these 3 rhythms.

Will it ever end?

Assorted bits and pieces

2010-08-11T15:42:00.005+10:00

DominoSolver

This is a small program which generates a Dominosa problem to solve, then uses my implementation of Knuth's Algorithm X to solve it. The controls are:

Press 'r' to generate a new puzzle
Press 'p' to pause the solution search
Press 's' to single step the solution search
Press 'c' to continue the solution search

Eternity2

This started out as a utility to help explore the huge Eternity2 puzzle, but as usually happens with me, I became sidetracked by pretty objects. The puzzle solving aspect is a minor part of this tool - the major focus of it is in procedurally generating the designs of the tiles, and from a programming point of view getting practice using the OpenGL stencil buffer by using it to produce different designs, and learning how to render to many textures.

To edit a design, pan over to the single tile view (its near the bottom right of the board), and press the spacebar. (To pan, drag with the right mouse button.) Labels will appear underneath some of the sliders, indicating they may be changed to alter the design. This is the area in question:

If you pan to the left, you'll see this design repeated on a grid, to give you an indication of how it looks when tesselated. You can continue editing here as well of course.

If you like, you can still "play" Eternity 2, and attempt to solve the puzzle - when you click on an empty part of the board (the large greyish area), candidate pieces are revealed on the top right, which you can click to place the tile. Tiles highlighted green have already been placed, and will be moved if you click them. I was going to investigate some simple auto placement strategies, but I got bored and moved on before I did this.

Included is a file called e2dataset.txt. This is not the official Eternity 2 tile set - it is a randomly generated tile set which includes border and corner pieces.

PegSolitaire

A simple implementation of Peg Solitaire. Right click to move a peg. There is some inactive AI code in the project.

RenderToTexturePlay

A simple render to texture experiment. Not interactive, but the texture is animated, so it may have instructive value.

FreewaySim

A simple simulation to play with some of the dynamics of traffic and overtaking behaviours.

Some of the parameters are in the Freeway constructor if you want to play around.

EmptyWorld

Its an empty world. Its a simple 3D environment complete with scene picking and an intuitive camera behaviour which you can use to render whatever thing you're working with in a 3D space instead of the usual console window.

AudioTest - a precursor to a Reactable simulator

2010-08-09T15:57:00.004+10:00

This application is a platform for some basic audio experiments and tests. It features:

A Lua REPL which permits the generation and modification of a waveform

Mouse modifiable waveform

Regeneration of waveform from Lua expression during the sliding of the sliders

The effects of modifications to the waveform are heard instantly, because it is being streamed as it is modified

It is my first foray into audio programming. It is a precursor for a "Reactable" simulator, similar to PsychoSynth.

Things to try

When the program starts, a sample expression appears, along with the resulting waveform, and the audio of the waveform should be heard.

Slide the first slider to alter the pitch of the waveform.

Slide the second slider, and notice the waveform and audio change according to the expression in the expression text box.

In the expression text box, enter a Lua expression that sets the variable "result". Variables you can refer to in the expression are:

x which is the time variable in the waveform, allowing you make "result" a function of time

p2, which is the setting of the second slider (The first slider controls the pitch). To see the value of p2, run print(p2) in the provided Lua REPL.

For example, the expression:

result = 0.2 * math.sin(x * ((2.0 * math.pi) / p2))

produces a sine wave whose frequency is modifiable with the second slider.

There are some more example expressions in audiooutput.cpp.

Building AudioTest from source

To build AudioTest from source, you will need:

Visual Studio 2008 (I use Express Edition)

Qt for Windows VS 2008 (I'm using Qt 4.6.3)

QtLuaImagine

2010-08-07T21:55:00.008+10:00

This project demonstrates the use of scripting languages in a Qt project to enable a 3D "live coding" environment. The scripting languages supported are Lua and Scheme (through s7 Scheme). For a version which uses Common Lisp (through ECL), see QtImagine and QtCSG.

The system calls the functions "update" and "render" in both languages to update and render the frame respectively. These functions can be redefined at runtime at the REPL.

When QtLuaImagine first starts, press "Enter" or click the "Execute" button to load an example Lua source file containing example definitions of update() and render(). Then, load the source file into your favourite text editor, make some changes, then load your freshly edited source file from the REPL by issuing the appropriate load command (dofile("filename.lua") for Lua, or (load "filename.scm") for Scheme) to see the effect of your change instantly. Of course, you can also enter expressions and definitions at the REPL itself. The REPL features a command history.

To build QtLuaImagine from source, you will need:

Visual Studio 2008 (I use Express Edition)

Qt for Windows VS 2008 (I'm using Qt 4.6.3)

The Visual Studio .vcproj file is generated from the Qt .pro file, and it uses relative paths in the "Additional Include Directories" and "Additional Dependencies" settings to find Qt headers and libs. Because of this, you will most likely need to regenerate the .vcproj before you load the .sln and start compiling. To do this, open a console, run vsvars32.bat (to set up Visual Studio environment variables), add the Qt bin directory to your path, then issue the command "qmake -tp vc". This will generate a new .vcproj for your setup, and you will then be ready to load the .sln and start compiling.

I have included a default .user file only for your convenience, because it contains an "Environment" setting so that Qt is added to the PATH environment variable when you run or debug. It assumes Qt is in C:\Qt\4.6.3\bin, so change this if it isn't.

A note on compiling for linux: Unlike the earlier Qt projects, this project does not have a separate static library. It is completely described by the .pro file, so compiling this on linux should be as simple as running qmake then make. Even the s7 and lua sources are included, so all that is needed to compile this on your end is Qt.

To see what other functions have been exposed to the REPL, and to see how to add your own, see luainterface.cpp/.h, and schemeinterface.cpp/.h for Lua and Scheme respectively.

I hope this code provides a running start for programmers getting into live coding for the first time.

QtCSG - Constructive Solid Geometry scripted from ECL

2009-09-08T14:58:00.018+10:00

This project is the same as the earlier project, QtImagine except this also features an implementation of "Constructive Solid Geometry" operations that can be performed on 3D models such as difference, union and intersection. The algorithm for performing these operations comes from the UnBBoolean (http://unbboolean.sourceforge.net/) Java CSG implementation.

See the files csg-test.lisp, csg-test2.lisp and csg-test3.lisp for examples on how to use these features. To run them, note that they need to be loaded in order - first csg-test.lisp, then csg-test2.lisp, then finally csg-test3.lisp, since they reference objects that were created by earlier scripts.

Similarly, see init.lisp and live-render.lisp for a live rendering example script.

QtImagine - a skeleton project for live coding using ECL

2009-09-01T17:27:00.021+10:00

QtImagine has been updated!

In the process of releasing QtLuaImagine, I cleaned up the code for QtImagine. All lisp code is now run through a (handler-bind) block so that error messages can be captured. What this means is that error messages are displayed in the main window, so no more need to flip between the console and the main window when an error occurs. Also, grey streams have been used to redirect trace output to the main window as well.

This project demonstrates the use of ECL in a Qt project to enable a 3D "live coding" environment.

The system calls the lisp functions (update) and (render) to update and render the frame respectively. These functions can be redefined at runtime at the REPL.

When QtImagine first starts, click the "Execute" button to load an example lisp source file containing example definitions of (update) and (render) which will produce a simple animation. Then, load the source file into your favourite text editor, make some changes, then load your freshly edited source file from the REPL by issuing the load command (load "live-render.lisp") to see the effect of your change instantly. Of course, you can also enter expressions and definitions at the REPL itself. The REPL features a command history.

Scripting simulations with ECL

2009-08-20T08:18:00.013+10:00

I've been adding to the program mentioned in a previous post. The circuit simulator and origami crease pattern editor are drivable from the lisp repl, and the verlet physics based paper simulator has been implemented and is manipulated from the repl.

Also, the repl itself features command history.

Here is the list of functions currently available from the repl:

ORIGAMI CREASE EDITOR

origami-start
Initialises origami crease editor with a plain sheet of paper consisting of 1 four sided facet.

origami-end
Clears the origami crease editor.

origami-creasecoords
Takes 4 parameters (x1 y1 x2 y2) representing the 2 endpoints of a crease line.

origami-crease
Takes 2 vertex ids (nodeA nodeB) and uses them as the 2 endpoints of a crease line.

origami-creasepp
Takes 2 vertex ids (nodeA nodeB) and forms the crease from "folding" one vertex on the other. The crease line is the perpendicular bisector.

origami-creasell
Takes 4 vertex ids (l1v1 l1v2 l2v1 l2v2) to describe the endpoints of 2 lines, and forms the crease from "folding" one line onto the other.

origami-fold
Takes 3 vertex ids (nodeF nodeA nodeB) and attempts to fold nodeF around the (nodeA nodeB) line by finding its mirror on the other side. It does the same with connected vertices as necessary.

origami-makeverletpaper
Makes a verlet physics representation of the current crease pattern, so it can be manipulated in the verlet physics environment.

VERLET PHYSICS

verlet-lock
Takes 1 vertex id, and fixes that node in space.

verlet-free
Takes 1 vertex id, and frees that node if it was fixed.

verlet-freeall
Removes all position constraints

verlet-rotate
Takes 4 parameters (nodeF nodeA nodeB angle) and rotates nodeF around the axis defined by nodeA and nodeB using the angle parameter. As the system resolves this attempt to do this rotation, you'll see whether the system currently permits or rejects such a motion.

verlet-numnodes
Returns the number of nodes.

verlet-numstruts
Returns the number of struts.

verlet-show
Not implemented - will show the given node id.

verlet-hide
Not implemented - will hide the given node id.

verlet-showall
Not implemented - will show all node ids.

verlet-hideall
Not implemented - will hide all node ids.

verlet-addfstrut
Not implemented - will add a folding strut, which is the same as the crease struts, but is marked as a folding strut, because it can be removed when a given fold is completed.

verlet-addsstrut
Not implemented - will add a structural strut manually. For facets containing more than 3 edges, structural struts are necessary to keep those facets flat. For the crane model, all facets are triangular, so this isn't necessary yet.

verlet-removefstruts
Not implemented - will remove all folding struts.

verlet-removesstruts
Not implemented - will remove all structural struts.

verlet-autoaddsstruts
Not implemented - will automatically add structural struts where needed for facets containing more than 3 edges.

verlet-satisfy
Not implemented - will allow the user to manually invoke the verlet constraint resolver, rather than having it run all the time.

CIRCUIT SIMULATOR

circuit-AddNode
Takes 2 parameters (x y) and adds a new node at that location.

circuit-AddResistor
Takes 3 parameters (nodeA nodeB resistance) and creates a resistor connecting nodeA and nodeB using the resistance parameter.

circuit-AddVoltage
Takes 3 parameters (nodeA nodeB voltage) and creates a voltage source connecting nodeA and nodeB using the voltage parameter.

circuit-AddCurrent
Takes 3 parameters (nodeA nodeB voltage) and creates a current source connecting nodeA and nodeB using the current parameter.

circuit-SetTweenA
Takes 3 parameters (component x y) and adds a tween vertex on one side of the component. For circuit rendering purposes.

circuit-SetTweenB
Takes 3 parameters (component x y) and adds a tween vertex on one side of the component. For circuit rendering purposes.

circuit-DoLoops
Automatically finds the loops in the circuit. It is necessary to call this once modifications to the circuit are complete for the circuit to be simulated correctly.

circuit-Clear
Clears the current circuit.

circuit-ShowCurrent
Turns on the animated rendering of the current.

circuit-ShowComponents
Turns on rendering of the components.

circuit-ShowNodes
Turns on rendering of the nodes.

circuit-ShowLoops
Turns on rendering of the loops.

circuit-HideCurrent
Turns off the animated rendering of the current.

circuit-HideComponents
Turns off rendering of the components.

circuit-HideNodes
Turns off rendering of the nodes.

circuit-HideLoops
Turns off rendering of the loops.

circuit-Rewire
Takes 3 parameters (componentID nodeFrom nodeTo) and disconnects the component from nodeFrom and connects it to nodeTo.

circuit-DeleteComponent
Takes a componentID as a parameter and deletes it.

circuit-DeleteNode
Takes a nodeID as a parameters and deletes it if there is nothing connected to it.

LIVE RENDERING

ogl-renderon
Turn on live rendering

ogl-renderoff
Turn off live rendering

ogl-drawline
Takes 6 parameters (x1 y1 z1 x2 y2 z2) that describe a 3D line, and renders it. This can only be called from within the paper-render function. Redefine the paper-render function at will at runtime.

OLD TEST FUNCTIONS

myadd
Takes 2 parameters and adds them

myaddlist
Takes a list and adds the numbers in the list.

Screenshots:

Press "Execute" when the program starts to load the script which computes the crane crease pattern:

Having a look at the crease pattern in the pattern editor:

Verlet physics paper manipulation and live rendering: Calling verlet-rotate from the repl to rotate the 4 corner vertices at once, 0.1 degrees at a time (the rotation continues due to momentum), then calling ogl-renderon to turn on live rendering, and modifying the paper-render function live by loading live-render.lisp (the function simul-rotate has been defined for convenience to do the simultaneous rotation):

Circuit simulator: Switching to the circuit simulator and loading a circuit (block-circuit.lisp):

Loading the scripts "block-circuit2.lisp" and "block-circuit3.lisp" to modify the circuit:

Embedding a Lisp interpreter into a Qt app

2009-06-26T11:52:00.017+10:00

I've been working on a few things these past few months. This includes:

A crease pattern generator that can calculate the crease pattern a piece of paper will have based on the sequence of folds applied to it. Conceptualising the paper as a mesh of facets, and determining the operations that can be performed on facets such as splitting was the key to implementing this.
A circuit simulator that uses an iterative process to solve the circuit. Since Verlet physics is very successful at applying physical constraints (such as ensuring a point mass is fixed in space, or ensuring two point masses are always a fixed distance apart) using little more than repeatedly pushing objects according to the pressure that each constraint is applying, I thought I would try the same idea with electric circuits and the pressures of KVL and KCL.

When I managed to embed a Lisp interpreter into my app using ECL, I decided this is a suitable thing to tell other people about.

The advantages of scripting using Lisp in this way are numerous and exciting:

Its an excellent way to ease into the beauty of Lisp without abandoning my other work.
Initially, I can create Lisp bindings that manipulate the interface of the simulation such as adding components to the circuit, or applying specific folds. Doing this, I get loading/saving functionality for free, because my circuit/origami folds/other simulation configuration are defined in a lisp script. Also, I can manipulate my simulation “live” in the lisp repl while the simulation is running.
Gradually, I can transfer more and more of the simulation implementation to lisp. Doing so, I can enjoy a real “live coding” environment. I have fluxus to thank for the inspiration.
Lisp is a magnificent programming language. Having a Lisp repl in my app means I get a beautiful customisable programming language allowing me to describe a DSL without having to write a single line of parsing code.

The possibilities having a Lisp running in your app are breathtaking. In the past, the only thing that kept me from writing my own language to control my simulations was the mind numbing drudgery of writing parsers. Now, I get all the advantages of a custom language completely for free!

The “Lisp” tab is initially active. It features the Lisp REPL. The only C++ function it is hooked to is myadd – not very exciting from the user's point of view, but VERY exciting for me, since it shows that I can have lisp control the whole show!

Non lisp stuff (will be lispified later):

In the “Crease Pattern” tab, press “Push button” repeatedly to see the effect of applying a fold sequence.
In the “Circuit” tab, right click a component to select it, and drag the slider to change its parameter (voltage for voltage sources, current for current sources, resistance for resistors.). In between frames, the algorithm runs 100 passes to solve the circuit. You'll notice that the visualisation is inspired by Paul Falstad's circuit simulator – I just wanted to add more interactivity!

Constructive Solid Geometry program

2008-09-02T14:18:00.016+10:00

There is also an implementation using a Qt front end and scriptable with ECL. For more information visit the QtCSG page.

This program demonstrates an algorithm for performing CSG (Constructive Solid Geometry) operations, and it is based on the Java CSG implementation called UnBBoolean (http://unbboolean.sourceforge.net/)

I found this excellent CSG implementation written in Java many months ago. Since it is very readable, and elucidates the concepts very clearly, I thought it may be worth translating this implementation into C++, so that this library can be used in C++ projects.

After months of procrastination and occasional work, the translation is completed. This is thanks to the excellently designed, crystal clear architecture of the original Java code, and the helpful comments.

Dealing with a large chunk of another programmer's source code is a very interesting excercise. There is an algorithm in the java code which implements the face cutting, but it runs all at once. If you want to figure out the reason for a particular problem, or simply want to peer into the inner workings of the algorithm, the standard line debugger is the wrong tool for the task. I found a simple and very useful technique for peering into code that runs all at once. I built a diagnostic object which allows me to take snapshots of the various geometric calculations it is performing, in order to "play it back" later, once the algorithm has finished. This was immensely helpful, and I will use this technique again. It is especially useful for reviewing algorithms that do things with geometry in 3D space.

Controls for the program

The controls are subtly different from my other programs, to allow finer control of navigation through the 3D space.

Moving the camera with the mouse:

Left mouse + mouse move ROTATES the camera.
Holding space + holding left mouse ROTATES the camera so it points to the selected location.
Holding space + holding left mouse + mouse move ORBITS the camera around the selected location.
Holding right mouse + mouse move PANS the camera along the camera plane, anchored on the selected point.
Mouse wheel MOVES the camera forward and back, based on the distance to the selected location. This means that before using the mouse wheel, make sure the mouse is hovering over the object you are interested in, because the distance of the step is a proportion of the distance between the camera and the object the mouse is hovering over.

Controlling diagnostic tool playback:

'd' toggles rendering of the diagnostic information.
Left arrow key steps the diagnostic playback backward one step.
Right arrow key steps the diagnostic playback forward one step.
Up arrow key steps the diagnostic playback forward continuously. (~20 steps per second, 1 per frame)
Down arrow key steps the diagnostic playback backward continuously. (~20 steps per second, 1 per frame)

A note on the diagnostic tool rendering:

Naturally it is up to the programmer what is being investigated, and I found myself frequently changing what the diagnostic tool should focus on. As you try to filter the volumes of data the diagnostic tool generates, I felt I had many options with how to proceed to learn more. I could either find some fancy ways to filter the data for the information I was interested in, leaving the snapshot taking as it was, or I could look at another aspect of the algorithm by modifying what I was choosing to record from the algorithm, and how I was going to present it.

There are 4 "episodes" in the diagnostic tool playback in this program.
1) Reveal the sequence of cuts made to the faces of the cone
2) Reveal each facet indivudually and all the facets that have come before, to enable me to visually ensure that there are no duplicates, and to inspect weird constructions of the algorithm
3) and 4), same as 1) and 2), except for the cube.

Screenshots:

All 3 models: difference, intersection and union:

Bird's eye view of the difference model:

External of the intersection model:

The interior of the union model:

One of the diagnostic frames:

Lights Out puzzle experiment

2008-05-14T10:14:00.012+10:00

I wrote this program to see the effect of applying a simple rule for solving the light toggling puzzle.

The idea is, because the toggle pattern is a cross shape, you can toggle one cell in a row at a time by pressing the one below it. Working your way down, you can clear each row separately this way. (According to the rules of the light puzzle, "pressing" a cell means toggling the cells that make up the cross centered on that cell individually.)

Naturally, the interesting thing happens when you reach the bottom. Sometimes it will work itself out, sometimes it won't. When it doesn't, it can produce interesting patterns as you keep applying this algorithm. When the puzzle isn't solved, this program reapplies this technique, but in the other direction.

Press 'r' to generate a new puzzle. (It regenerates a new puzzle by "pressing" 1000 cells at random)
Press 'p' to pause the algorithm.
Press 'c' to continue the algorithm. Pressing it again will modify the speed at which the algorithm runs - whole row per frame, or single cell per frame.

Click to press the indicated cell (will toggle a cross shape at that position). You can do this during a solve as well. You can set up your own puzzle this way, and see how the algorithm handles it.

Screenshots:

Simple tennis program

2008-05-14T10:03:00.010+10:00

This program is the beginnings of a tennis simulation featuring some basic tennis mechanics.

This program demonstrates a means of making the ball land anywhere with an arbitrary apex height, and a means of determining which part of the trajectory can be reached by the player.
In this way, the program demonstrates a framework for staging all sorts of different scenarios and tennis playing strategies in the tennis universe.

Description of AI behaviour:

AI runs directly toward the ball to intercept it
AI runs to the center of its half of the court after hitting the ball and before its opponent does
AI decides on where it would like the ball to land by choosing a random spot in opponent's half of the court
AI may control the height of the apex of the ball's parabolic trajectory

The parabola the AI desires is precomputed, and an appropriate initial velocity vector is computed for the ball so that the ball follows the desired trajectory under the influence of a physics model which only includes gravity.

The physics ball is rendered as a white sphere, the "scripted" constant x-velocity ball is rendered as a yellow sphere.
I render both to ensure that they match up precisely.

The precomputed parabola is rendered as well. The green portion is the portion that can be reached by the player, the red portion is the portion that cannot be intercepted in time.

In this version, I've made the camera follow the player, so there is no interactivity.

Esc will close the program.

Screenshots:

MagicVines clone uploaded

2008-02-13T15:32:00.016+11:00

This is my simplified clone of the PopCap game, MagicVines.

While playing this game (the PopCap version), I was wondering whether strategic decisions about which group of 3 to clear really mattered, and whether a robot which will take the effort out of finding groups of 3 would change the game into a strategic one.

So, I made this program initially to reveal how solvable randomly generated boards would be. In this way, it becomes a little clearer whether the game is sensitive to strategic choices, or whether the game was only about how rapidly the player can recognise groups of 3.

If there is any strategy, it seems to be to try to clear the bottom cells first, because they are replenished less often than cells at the top.

Screenshots:

There are 2 executables in this zip file:
- MagicVines.exe
- MagicVines_Robot.exe

Usage instructions for MagicVines.exe:

Click a cell to flip it from horizontal - vertical, and vice versa.
The board clears consecutive groups of 3 or more matching cells in the same column or row continuously in the background. If the board is still eliminating, your group may not get eliminated right away - it will eventually as the board resolves itself. Try to get cascading eliminations!

Press 'r' at any time to reset the board for a new game.

Usage instructions for MagicVines_Robot.exe:

Clicking a cell will direct the focus of the robot player, so that it clears groups around the clicked cell first, before any other cell.

Press 'r' at any time to reset the board for a new game.

15 Puzzle solver

2008-01-27T02:55:00.018+11:00

This program depicts a method for solving the 15 puzzle.

I wrote this to see if the explicit method I was using to solve this puzzle could be encoded, and whether there were puzzle instances my method would not work on.

A ran a separate testbed app that did thousands of runs to determine the success rate of various methods for solving this puzzle. For each run, a random instance of the puzzle was produced by making over 100 random moves. In this way, it is clear that the instance of the puzzle would be solvable.

An earlier method I used worked ~80% of the time for 100,000 runs. The method I present here was successful for all 100,000 runs, and then millions of runs after that.

When you step through the algorithm, you'll be able to clearly see the method for solving the puzzle.

Description of the method:

1) Move 1 into position
2) Move 2 into position
3) Get 4 out of the way
4) Move 3 to the top right
5) Move 4 below the 3
6) Slot in 3 and 4 in consecutive moves

Top row is done. Top row tiles are never touched again.

7) Move 5 into position (never touching the top row)
8) Move 6 into position
9) Move 8 out of the way
10) Move 7 to the top right
11) Move 8 below the 7
12) Slot 7 and 8 in consecutive moves

Top 2 rows are done. Top 2 rows are never touched again.

13) Move 10 out the way
14) Move 9 into position
15) Move 10 next to the 9
16) Slide 9 and 10 in consecutive moves so they are out of the way
17) Move 11 next to 10
18) Move 12 next to 11
19) Move 9,10,11,12 in 4 consecutive moves so that they are in a solid block to the left
20) Rotate the remaining tiles (13,14,15) until the 13 touches the 12
21) Rotate all 8 tiles until they are all in position

And now the puzzle should be solved.

Here are the controls:

'c' runs the algorithm continuously until the puzzle is solved
'p' pauses the continuous run
's' Moves one tile (steps the algorithm until it moves a tile)
'r' Generates a new puzzle
'q' or Esc closes the program

Notes on the implementation:

This program is another demonstration of the value of moving an algorithm into an updatable object that can be queried. By this I mean that instead of implementing your algorithm in a function, you implement it as a state machine, with the various states corresponding to different stages of the algorithm. Local variables of the function become member variables of this object, and any recursive function calls are handled by using a stack. In this way, it is possible to observe the operation of the algorithm, and perhaps do other things in the meantime.

From the caller, its the difference between doing this:

RunAlgorithm(data);

and this:

Algorithm a;
a.Reset(data);
while(!a.Finished())
{
a.Update();
}

You can see where the second approach would have many advantages.

Screenshots:

Picture Logic solver

2008-01-25T14:53:00.011+11:00

This program solves picture logic puzzles, and demonstrates the algorithm for a single solving pass on an individual row or column in detail.

PictureLogic.exe generates a random image, and solves it by repeatedly applying the solving passes alternately on all columns and rows.

PictureLogic_RowColAlgorithm.exe demonstrates the algorithm for applying a single solving pass to a row or column.

Controls for both PictureLogic.exe and PictureLogic_RowColAlgorithm.exe are:

'c': Commences or resumes continuous updating of the solving algorithm
'p': Pauses the continuous run.
's': Update the solver one step.
'r': Generate a new puzzle instance.
'q' or Esc: Closes the program.

For the algorithm demonstration program, there is some basic logic guiding the generation of the puzzle instances, but it can still generate unsolvable instances. However, the algorithm will detect these.

Screen layout for PictureLogic.exe:

The only thing displayed is the picture logic puzzle. This consists of the grid and block sizes, as you would see in any puzzle book.

Screen layout For PictureLogic_RowColAlgorithm.exe:

The puzzle instance is displayed in the 1D grid at the bottom: Solid rectangles indicate a cell that must be filled, hollow rectangles indicate a cell that must remain empty. Above this 1D grid are the block sizes.

Just above the puzzle instance is a 1D grid is where the results of the solving pass will appear at the end of the run.

The algorithm will enumerate every possible placement of the blocks in this 1D space during the course of the algorithm, and you can see the results of its work in the middle of the window.

At the top of the window are grids describing the "invariant" cells - the cells that stay the same for all possible placements of the blocks. These are then referred to to generate the result of the solving pass.

I hope these programs are interesting for you, and perhaps teach you about this puzzle and one way of solving it, and perhaps show the benfit of encapsulating an algorithm into an object so that you may query it and control its execution from the outside.

Screenshots:

Domino placement game

2008-01-23T09:38:00.010+11:00

This is an implementation of the domino placement puzzle. In this version, you are able to explore the puzzle in a new way - the program plays the puzzle with you!

When you place a domino, the AI propagates the constraints of your new placement, allowing you to see the logical effects of your placement. You can very quickly see whether you'd get to a dead end or a solution with a particular placement, and there are unlimited levels of undo.

You can have your puzzle loaded from a file, or watch as the placer generates a new puzzle for you.

Screen layout:
The left grid shows the puzzle.
The right grid is the solving area.
The middle column shows all unplaced dominos.

Controls:

Clicking once between 2 cells is sufficient to describe a domino placement.

Left mouse in between 2 cells in the right grid will place a domino there.
Right mouse in between 2 cells will reveal all the other places that same domino could be placed.

Mouse wheel when the mouse is over the center column to scroll the available dominos awaiting placement.
Right click on one of these available dominos to see where it could be placed.

Press 'u' to undo your last placement (there are unlimited undo levels).
Press 'l' to load the next level in the level file. (It loads from board_in_dominosa.txt).
Press 'r' to reset the solution board and begin the puzzle again.
Press 'n' to generate a new puzzle.

The puzzles in board_in_dominosa.txt are in the format that dominosa.exe uses when you save a puzzle. Dominosa.exe comes from Simon Tatham's Portable Puzzle Collection, available from http://www.chiark.greenend.org.uk/~sgtatham/puzzles/

Enjoy!

Screenshots:

Ball game simulation

2007-11-20T15:53:00.010+11:00

Left mouse button + drag will orbit the camera around the cursor.
Right mouse button + drag will pan the camera anchored around the cursor.
Mouse wheel will move the camera forward or back.

Esc will close the program.

I built this because it uses a basic AI team architecture I've wanted to try out in a simple ball game simulation. The AI architecture describes the concept of a team assigning roles to players, which in turn are implemented in terms of a basic reportoire of actions. The architecture is described in some more detail in the readme file.

Verlet Origami

2007-11-02T14:50:00.015+11:00

Please note: There is a more advanced version of this program available here.

The program I am uploading here is called VerletOrigami.

I'm using a basic verlet physics engine to simulate a ball and strut model of a pre-creased, rigid piece of paper.

The paper has been pre-creased for a paper plane, and the simulation will "fold" the paper into a paper airplane in front of your eyes, demonstrating the viability of using verlet physics to simulate a piece of paper.

Screenshots: