# Category Archives: Image manipulation

One of the problems with the original Image fader (Live page) project was that it only faded images in one direction. I made an update to allow the image fader to handle all four directions, and used it to create a wallapper for my webite.

# Update: Painter

Recently I wanted to make some pixel art for a mobile version of my website (which is very different to anything I’ve done before, and more confusing than I thought it would be.) To do that I decided to use the Painter tool (Live page) I’d written a few years ago. Unfortunately the tool no longer worked, for reasons that I’m still trying to debug. (Possible to cross-domain restrictions when using the full path, but more likely due to the limits of the GET request.) The old method used PHP to generate the image, and the HTML DOM to manage the editing, using an HTTP request when the image needed to be generated. It’s not hard to see why this is inefficient, so once the canvas became available I decided to transition from PHP to JavaScript and the canvas.

Given my previous experience with the canvas it didn’t take long to code up a new version of the painter, and the biggest challenge was extending the scope of the line paintbrush to create lines at any angles, not just vertical or horizontal. The updated look is more sleek and professional, the performance is better, and there are fewer failure modes. I’ve kept the legacy version for interest, but I have no plans on using that again. I am also considering adding two new featuers in the future: allowing the user to save their image to an online database, and allowing the user to upload an image so they can edit existing images pixel by pixel.

# Work in progress: Hexagonal civilisation game

It’s another unfinished game!

Ever since I played Sid Meier’s original Civilisation I’ve wanted to make something similar to explore the gameplay and create something fun to pass the time.

### Overview

In principle this game should be fairly easy to develop because it is turn based and each problem (except the AI) is well defined. I first tried developing a game using SVG and one of my friends suggested using hexagons, which gives it a nicer, more rounded feel. However like many other projects this one is much lower priority than the others and it’s hard to justify the large amount of time required for development, so it’s stayed in a very rudimentary state for a long time.

As usual this game uses the canvas with the normal model for user interaction that I developed when writing the Feynman diagram maker. The rest is simply a matter of keeping track of the variables needed for the game to function. The interface would be as clean and elegant possible, as I felt this was the main advantage the original game had over the rest of the series.

### Challenges

Challenge: This was one of the first games I developed using hexagons.
Solution: The choice to use hexagons leads to some non trivial problems. The most important challenge is the choice of coordinate systems and arranging it in an intuitive manner. It tooks some trial and errr but in the end I created a map that could be used for the development of the game. (Resolved)
Challenge: This game would need some (basic) artificial intelligence.
Solution: This is something I haven’t even started to think about yet! (To do)

# Work in progress: Maze game

Following on from the Platform game and Explorer game I wanted to create a tile based game. This was partly inspired by the game Kharne which I had played many times, and I became frustrated with the lack of similar games online. (It was this frustration that lead to a minro obsession with 91, and the creation of the huge 91 map poster.)

### Overview

This game builds on the experience I gained from the Platform game, Explorer game and others. The player finds themself on an island where they must pursue several adventures. All of the graphics are procedurally generated and the emphasis is placed on making each adventure unique and special, rather than “Collect 100 coins” or “Beat this boss”. Like the other similar game projects the progress has been postponed here, as other projects are considered more important.

### Challenges

Challenge: This game needed dialgoue trees and combat.
Solution: I wanted to make a game with some standaard dialogue and combat functionality for NPCs. The dialogue tree to a while to work out, mostly because there’s no clean way to do it, but I’m quite happy with the outcome. The combat was easier to manage, but it will take some iteration before it becomes optmised. (Resolved)
Challenge: I wanted to arrange object pseudorandomly on the canvas.
Solution: One of the things I wanted to do was auto-generate environemnts (for example, arrange flowers on grass randomly.) Initially I used random number to do this, but immediately found that the flowers would move around as the player moved! To get around this I used the room and position coordinates to generate pseudorandom numbers, which work much better. Some objects moved (such as bees around the beehive) so for those I added a time dependent part to the motion. (Resolved)
Challenge: I wanted to envinonment to change slowly.
Solution: I wanted to have an adventure where the life on the island slow dies, and I made an effect where the grass slowly fades from green to grey. This needs to be changed so that it only comes into play during certain missions, but I am very pleased with the result. It looks very creepy and it was quite easy to implement. I took some inspiration from for this. (Resolved)

# Work in progress: Platform game

This project is something I’ve been working for a long time and something I have wanted to develop for as long as I can remember. It’s a platform game strongly inspired by the BBC Micro game, Citadel. (I have another project dedicated to mapping Citadel.) When I was younger I would dream about playing non-existant extra levels in Citadel, and when I started recreational programming I would sometimes dream about making new levels for the game.

### Overview

The game is organised into a two dimensional array of rooms, which are subsequently split into blocks. Each block is then specified using a shape, foreground, background, obstacle, medium, and objects. The medium can be air, water, fire, solid rock etc, and the obstacle is wall, ladder etc. The foreground and background are purely cosmetic. The objects are things like coins, doors, keys etc.

Motion is controlled using the keyboard and is handled on a pixel-by-pixel basis. The function defining the motion are very loosely inspired by , although all the code and algorithms are my own. The player is modeled by a rectangle which is moved across the blocks pixel by pixel, searching for collisions. When a collision is detected movement is stopped along that axis. If movement along the other axis means there is no longer a collision then movement along the first axis resumes. This is how collisions were handled in Citadel, and was something I wanted to replicate. When the collision happens at $$45\deg$$ the ambiguity is resolved by the direction of movement of the player. (For example if the player is moving down along the $$y$$ axis and collides with a corner the player will move down instead of horizontally.) The movement was initially monitored using a “mask” of pixels surrounding the player, with a special mask view for debugging, but this has since been retired due to the huge CPU demands.

This game is in progress, so at the moment there is very limited functionality. The physics engine is pretty much complete, although it would benefit from some optimisations. The main environment types have already been developed, including air, water, solid, fire, and ladder. A few extra features have been added including trampolines and the double jump feature. The features I was working on when I paused development were interactions with objects and the inventory, and adding a “pain” feature instead of instant death (another feature of Citadel that I very much enjoyed.)

The game has an editor so that the developer can “draw” rooms onto the canvas directly instead of writing things in a text editor, as it was arranged initially. This speeds up content writing a lot, but there are almost certainly some features that need to be added to make this better, and probably a handful of bugs that need to be fixed as well.

When the player or editor goes into a room that does not exist, a new room with the name “Nothingness” is automatically added to the map. This is very important because players always find new ways to break the map. In fact this is something that was handled very well in the original Citadel, although it did lead to a serious exploit, where players could “fall off of the edge of the map” and end up elsewhere.

This game needs some more development, but already it has potential to be very interesting. As well as adding more content and assets it’s necessary to optimise the game play so that it can be played on lower end computers.

Bonus!: Before the canvas was available I tried to make a platform game using SVG. As I’ve already discussed before, using SVG with Javascript is a pain since the Javascript must be cleanly embedded within the SVG document itself. This didn’t stop me though, and I made a very bad proof of principle game where you can see some of the problems with moving platforms: SVG platformer.. This game also has a game breaking bug associated with how different browsers handled text nodes and how the standards changed.

### Challenges

Challenge: This game needed a decent physics engine.
Solution: This was my first time writing a physics engine, and being a physicist I thought it would be easy. I was wrong. I love classical physics and its inherent beauty, but writing code for a classical physics enging is hard. I started out with a ball bouncing around a square room, followed by adding gravity, then adding player controls. I built up the model step by step until I had something reasonabe and intuitive. It was a very informative experience. (Resolved, to be revisited)
Challenge: The rooms needed to have some kind of model that was both versatile and had good performance.
Solution: I built the rooms out of blocks. Each block had a shape and this allows the developer to create a detailed room for the game, as well as having pixel perfect control over the player’s movements. however this comes at the cost of performance, so some additional gains needs to made with the physics engine. The versatility of the room design is excellent and I am very happy with the amount of creative freedom the developer has in assembling the rooms. (Resolved)
Challenge: The double jump feature needed to be added.
Solution: One of the options I wanted to add was a double (and triple etc) jump to make some areas accessible only once this feature is enabled. Doing this meant keeping track of how many jumps had already been made, and from what kind of surface. This was not a trivial thing to do and it helped make the physics engine more robust. (Resolved)
Challenge: The rooms has to be stored in an array, which could be turned into a map.
Solution: Storing the rooms in an array makes it easier to access them and reduces memory usage. At the same time it means keeping track of additional coordinates which brings their own problem As the player (or game developer) moves into new rooms, new rows and columns are added to the array, meaning that indices must be updated. This caused a few bugs, but was finally resolved. The developer also has access to a map of the rooms, which is something I may add for the player as well. (Resolved)
Challenge: This game requires quite a bit of pixel art.
Solution: The style of the art in this game is heavily inspired by Citadel, but there are other parts I made myself. The pixel art used to make the blocks was made using the Painter project, which was in fact written explicitly for this game.. (Resolved)

### Screenshots

One of the projects I have wanted to develop for a long time is a browser based particle physics experiment simulator. Such a project would generate events using Monte Carlo methods and simuate their interactions with the detector. This was made partly as an educational aid, partly as a challenge to myself, and partly because at the time I was feeling some frustration with the lack of real analysis in my job. As expected for a Javascript based CPU intensive appplication, this reaches the limits of what is possible with current technology quite rapidly.

### Overview

The model for the detector is saved in an xml file which is loaded using the same methods developed in the Marble Hornets project. Particle data are currently stored in Javascript source files, but will eventually use xml as well. The particle interactions are simulated first by choosing a process (eg $$e^+e^-\to q\bar{q}$$) and then decaying the particles. Jets are formed by popping $$q-\bar{q}$$ pairs out of the vacuum while phase space allows and then arranging the resulting pairs in hadrons. Bound states are then decayed according to their Particle Data Group (PDG) branching fractions, with phase space decays used. The paths of the particles are propagated through the detector using a stepwise helix propagation. Energy depositions in the detector are estimated, according to the characteristic properties of the detector components. A list of particles is then compiled based on the particles produced and these can be used to reconstruct parent particles.

The user has access to several controls to interact with the application. They can choose how to view the detector, using Cartesian coordinates and two Euler angles (with the roll axis suppressed.) The most expensive parts of the process are the generation of the event displays and the generation of the particle table. By default these are only updated after a certain interval, to allow the user to accumulate a significant number of events without being slowed down by the graphics. To save time the detector itself is rendered once in a cutaway view, and the particle tracks are overlaid on the saved image. Eventually the user will be able to get a full event display, including the detector response to the particle with glowing detector components etc.

The user has access to collections of particles, including electrons, muons, pions, kaons, photons, and protons. From these they can construct other particles, making selections as they do so. Once they have made parent particles they can then plot kinematic variables including mass, momentum, transverse moment, and helicity angle. This should, in principle, allow students to learn how to recreate particles and how to separate signal from background effectively.

Given the large amount of information available the user has access to a number of tabs which can can be collapsed out of view. This allows the user to run the application with the expensive canvas and DOM updates, and thus collect many more events.

This is still a work in progress, with reconstruction of particle being the next main priority. Eventually the user would be able to load their favourite detector geometry and beam conditions, then perform their analysis, saving the output in xml files and possible being able to upload these to a server. This would allow users to act as “players” with “physics campaigns”, including the SPS experiments, HERA experiments, B factories, LEP experiments, and LHC experiments. This is, of course, a very ambitious goal, and one which has been ongoing for over a year at this point.

See other posts tagged with aDetector.

### Challenges

Challenge: A sophisticated model for the detector was needed.
Solution: The detector is split up by subdetector, with each subdetector having its own characteristic responses to different particles. The detector is split up in cylindrical coordinates, $$( ho,\eta,\phi)$$, with each subdetector also being split into modules. Individual modules then react the particles for reconstruction purposes. Thus with a few key parameters even a sophisticated model can be stored in a few variables that can be tuned quickly and easily. (Resolved.)
Challenge: The detector shold have a three dimensional view that the user can control.
Solution: The detector is drawn using a wireframe with transparent panels. This is a method I developed in 2009 for a now defunct PHP generated SVG based visualisation of the BaBar electromagnetic calorimeter, which I used to show the absorbed dose as a function of detector region and time. The drawing algorithm is not perfect, as panels are drawn in order from furthest from the user to closest. This is sufficient for most purposes, but occasionally panels will intersect causing strange artefacts. Eventually this should be replaced with a much more stable, robust, and fast implementation, such as in three.js. (Resolved, to be revisited.)
Challenge: Particles should be modeled realistically and physically correctly.
Solution: Particles are modelled with the most important parameters (mass, charge, decay modes etc) taken from the PDG. Their kinematic properties are modeled using special four vector classes, and decay products “inherit” from their parents in a consistent manner. Particles at the highest layer of the tree are assigned their four momenta, and then their decay products are decayed, inheriting the boost and production vertex from their parents. This is repeated recursively until all unstable particles are decayed. So far this does not take spin into account, as everything is decayed using a phase space model. Particles with large widths have their lineshape modeled using a Breit-Wigner shape. As a result, particle have realistic looking jets and four momentum is conserved. This required the development of special libraries to handle these decays and kinematic constraints. (Resolved, to be revisited.)
Challenge: Particles decay trees must be traversed consistently.
Solution: This is harder than it sounds! Every time an event is generated, particles are recursively decayed for as long as phase space allows. The particles must then be traversed and dispalyed in the table, in a consistent manner. Ensuring that all particles are listed hierarchally without missing anything out takes some care. (Resolved.)
Challenge: Particles lists had to be prepared for the user.
Solution: The user has access to a handful of “building blocks” to play with. These are taken from the (generated) list of particles per event and filtered by the particle type. Further lists can be created or filtered from these lists, and parent particles can reconstructed from combining lists. This means having to provide special classes to handle the particles and ensure that no particles are reconstructed recursively (leading to infinite loops.) Apart from using reconstructed particles instead of generated particles, this has been resolved. (Resolved, to be revisited.)
Challenge: The user needs to be able to make histograms.
Solution: I had made histgorams for other projects, including the Reflections and Box plotter projects, so this was mostly fairly easy to do. Even so, being able to create new histograms of arbitrary scales and variables on the fly meant that this histogram class had to be more robust than previous projects. (Resolved.)

# Crazy 2014

When I heard the sad news about flight MH17 I couldn’t quite understand what was happening. It seemed like the worst parts of 2014 had come together in a way that nobody could have predicted. I tried to sum up the situation in this infographic. This mini project was in fact an excuse to practice some infographic making skills, which I had not used for a long time.

### Overview

This is rendered on the canvas, as usual.

# Reflections

A “reflection” is a term in particle physics for when a decay of one particle looks like the decay of another. It’s a topic which has been studied for about fifty years, and seemed like an excellent chance to combine physics and coding.

### Overview

To make a reflection it’s necessary to take one particle that decays to two daughters, and then assign the wrong mass hypothesis to at least one of the daughters. The way this is done is by using PHP to generate an SVG image with Javascript embedded within it. The user then makes a POST request to create a new image.

The definition of the helicity angle is the angle between one of the daughter particles, and the relativistic boost into the lab frame, in the frame of the mother particle. The angle is determined by explicitly boosting into this frame and taking the dot product.

### Challenges

Challenge: This was one of the first projects where I had to map onto a coordinate system on a canvas.
Solution: This is not as easy as it sounds when axes are involved! By appropriate use of the log function and creating margins it was possible to make a two dimensional histogram, which is a model I’ve used ever since. (Resolved)
Challenge: This project needs some insight into how the underlying physics works.
Solution: It took some thought about how to make this work effectively, as it’s essentially an exercise in four vectors, which are always more subtle than I’d like. (Resolved)
Challenge: The plot needs to be updated to match the user’s input.
Solution: At the time this was written I was already used to using both PHP and SVG, which were the state of the art at the time. It’s a bit clunky to send a POST request every time the plot needs to be updated, and now we have the canvas. At some point I should update this code to use Javascript and the canvas. (Resolved, to be revisited)

### Screenshot

Here is the output for the decay $$\Lambda \to p \pi$$ ($$m(\Lambda)=1150 ~\mathrm{MeV}$$) creating a reflection for the decay $$K_S^0 \to \pi\pi$$ ($$m(K_S^0)=497~\mathrm{MeV}$$), which has been studied for decades.

# Iterated path

In 2014 the CMS experiment at CERN released their 2010 data to the public for analysis. As a quick exercise I decided to analyse the dimuon mass spectrum to show that this could be done in a reasonable amount of time.

### Overview

The input file is the 2010 Run B comma separated values file. The python script then produces mass spectra for same sign and opposite sign mass spectra and zooms in on the interesting regions.

### Challenges

Challenge: The main challenge was that this project was made as quickly as possible.
Solution: This project uses python and existing ROOT libraries for the maximal development speed. The other data format available was using CMSSW and a virtual machine. In principle using CMSSW should be straightforward, but I decided against using this because the software was already four years old and support would be minimal or non-existant, even to current CMS physicsts. (Resolved)

# 91 map

I played the game 91 and wanted to create a map of the world. What started out as a simple map to help keep track of the regions soon turned into a larger project which resulted in an A0 sized poster being produced. The creator of the game got in touch and at the time of writing the first poster has been printed and more will follow. The creator is going to publish and sell these posters online.

### Overview

The game 91 is a tile based canvas game which is written entirely in Javascript (served up by PHP via AJAX requests). The game itself has a “fog” which means that only regions in a line of sight are visible. Given the way the game is organised means that in principle it should be easy to create a map. I adapted the code to make maps of each region, and then created a patchwork of all these small maps to create a larger map.

### Challenges

Challenge: The code had to be reverse engineered to obtain all the maps.
Solution: One of the most fun parts of this project was reverse engineering how the AJAX requests were handled and how the maps were parsed. Fortunately it was relatively straightforward to do. (Resolved.)
Challenge: Small maps had to be combined with different drawing styles.
Solution: To make the large map I had to combined many smaller maps. There’s no “cheap” way to do this, so I created an object that contained the smaller maps in a larger two dimensional array where each cell has its own drawing style flag, allowing non-trivial overlap of different drawing styles. (Resolved.)
Challenge: A poster of very large dimensions needed to be created.
Solution: There’s no easy way to manage an image of the size needed to make a large poster. I have made large posters before (for example, in the Marble Hornets project) so I was prepared for many of the problems. The sides of the map had to have relative sizes of $$\sqrt{2}$$, which fortunately was relatively easy (especially when compared to the Citadel project. In the end I opted to have a large .png file at $$\sim 500 ~\mathrm{dpi}$$ giving very fine print quality. The resulting file is just under 20 MB in size, which is rather impressive given its physical size. (Resolved.)

### Sample outputs

The final version of the poster, as approved by the game’s creator, can be seen here: Poster version 2.