Fractional sums of Perlin Noise

I wanted to mess around with fractional sums of Perlin noise, so made a little openFrameworks app to better understand what is going on.

Frequency

Frequency comes up quite a bit in the following discussion, and more or less means the rate at which something goes up and down. All you really need to keep in mind is:

High frequency noise goes up and down quickly. It looks like this (where black is 0 and white is 1):

Low frequency noise goes up and down slowly.  It looks like this:

You can see low frequency noise takes a while to get from zero to one and vice versa, while high frequency noise does it much more often.

ofNoise Inputs and Outputs

In general it’s a good starting point to pass normalized coordinates to the noise function.

You can use ofNoise() to get values ranging from [0, 1], or ofSignedNoise() to get values from [-1, 1].

There are a bunch of functions for various dimensions as well.

Fractional Sums

Low frequency noise will give a nice undulating look, but often it is boring. High frequency noise is more interesting, but can be a bit too chaotic. What we want is a nice combination of both.

Using an example from Paul Bourke, we take several instances of noise at increasing frequency and combine them to get the effect we are after.

To do this there are three parameters, an octave count, alpha, and beta.

The octave count is how many layers of noise we will be adding together. This will typically range from 1 to 8.

Each layer of noise is generated at a higher frequency than the one before, which is where the name octave comes from. 

Beta controls the frequency of noise, the larger it is, the higher the frequency of the noise, i.e. the faster it goes up and down.

Adding these together works, but you might find the higher frequency noise overpowers the lower frequency noise.

This is where the third parameter, alpha, comes in, controlling how much of the noise from the current octave ends up in the final sum.

In rough code it looks like this:

double sum = 0.0;
for (int n  = 0; n < octaveCount; n++) 
            sum += 1/alpha^n * noise(n * beta * x, n * beta * y);

Lets say alpha and beta are both 2. In the call to noise(), the n * beta term will get progressively larger for each successive layer of noise. We are increasing the frequency of the generated noise.

However, with alpha as 2, we are adding successively less of each octave, as we get 1/2, 1/4, 1/8, 1/16 … reducing the magnitude of the higher frequency terms.

Taken together, we see the higher frequency noise contributes less and less to the final sum. We end up with a nice smooth but varying noise map to use for displacement or whatever we want.

Normalizing

Summing several octaves means you will typically get values greater than 1 (and less than -1 if you are using signed noise).

There’s a few ways you can normalize these, take a look at the commented out code. You might not want to map the minimum to zero as it can cause jumps when the lower bound of the summed noise changes.

The app 

An app to play with is up here

The small images show the individual octaves, and the big image is the final result.

Also I used the noise function from that app to do vertex displacement of a mesh and put a clip up here:

That’s it for now. Later on I will give an example of making seamless noise loops. I have a bunch of other stuff going on which I will write about when they are finished off, but I am really looking forward to sharing.

As always you can find me being rude and unprofessional on twitter. I love hearing from people, so tweet me pics of your rad noise stuff. 

Cheap Tricks - Interactive Dance Floor Application with Kinect and openFrameworks

I took a short break from a longer term project I am working on to make something for a New Years Eve party dance floor. I didn’t have a lot of time and it shows one of my favorite aspects of working with openFrameworks: you get a lot of stuff for free via the addons available, making it very quick to implement ideas.

You can see a little demo of the project here:


Cheap Tricks from dizzy pete.

It uses a Kinect and OpenCV to get the blobs (in this case people and my Ikea furniture) then turns them into triangles that are audio reactive, as well as adding in some visual effects with no real purpose other than to look cool.

Kinect Input

Reading from the Kinect is relatively straightforward, and more or less lifted straight from Kinect examples that come with oF. It uses the depth information in a grayscale OpenCV image and does some simple thresholding based on depth settings.

This grayscale image is passed to the stock OpenCV blob finder, then the blob information is passed to ofxTriangle to get a set of triangles representing the blob. I initially was using ofxDelaunay but found ofxTriangle just worked a little better for what I was after.

Audio

The audio reactive part is done via ofxFFT by julapy (there are a few out there so make sure you have the right one if you’re taking a look). I originally wanted to do beat detection and have the figures pulse in time with the beat, but that was a little too involved given the time constraint, so decided just to stick with the very low end.

I experimented with various numbers of FFT bins but ended up using the default buffer size of 512, bin size 256 and averaging the lowest three bins. This is the variable ‘low’ that is used throughout the code.

Ideally I would have had a proper audio device feeding in from the DJ’s mixer, but as it turned out I was using the default microphone on my MacBook for audio input, which worked much better than I expected.

Based on the current amount of low-end audio detected, each vertex of each triangle is displaced from its center by some amount. Triangle sizes vary; the torso of the detected body has larger triangles than the hand or arm, how much displacement to be applied is a function of the triangle area.

To be precise it is the square root of the triangle’s area, and can be tweaked by a parameter called jitterSize in the gui. I don’t actually displace each vertex, just two out of three. The code to do all third is there but commented out, I just liked the way it looked doing only two.

Once the vertex displacement has been calculated, the triangle is added to a mesh along with texture coordinates, which are used for coloring. But more on that in a second.

The basic triangle form

Background

By this stage the basic audio-reactive triangle people thing I was after was done, but it still looked a bit flat.

Poking around some OpenCV examples, I saw examples of motion detection that looked kinda cool.

First it takes the difference between the current frame and last frame, which gives areas where motion has been detected. This is then scaled up as a function of low-end audio and GUI parameter glowExtra, then added to a buffer image. The buffer image gets decayed over time, so things fade out as the motion fades.

This looked ok, but I wanted it to be a bit smoother so used ofxFboBlur to add in excessive amounts of Gaussian blur to the motion buffer image. I had to change its source a bit just to play a bit nicer with FBO sizes and drawing, which is why it appears in the source folder and not as an addon.

The blurred motion detection background

Color

Coloring was probably the hardest part for me, and even then it was pretty easy.

There are lots of different ways this could be done, but I settled on using a two-color gradient rendered to an FBO, using a mesh with vertex colors. Each frame, the mesh vertex colors are updated by cycling through the Hue component in HSB space, then the updated mesh is rendered to the FBO.

This FBO gets used in two places. First it is blended with the grayscale blurred motion detection background using a multiplicative blend mode, which takes care of coloring in the swishy aura type effect in the background.

Then the FBO texture reference is bound and the mesh containing our displaced triangularized blobs is drawn as a wireframe. This is where having texture coordinates for each vertex in the mesh is important, though fiddling around I noticed I don’t need tex coords if ofBackground() has been called. Who knows.

Regardless, when the wireframe is drawn, it is colored based on the bound FBO texture reference, which takes care of coloring in our triangle people.

The two layers colored and drawn together

Outro

So that is just a quick run through of how it works. I used a lot of addons, and all up it took me about 2 days. I started on the evening of the 29th and was finished by the afternoon of the 31st, just in time. Without the oF addons it would’ve taken me well over a week, possibly many weeks.

People at the party really seemed to enjoy it as well, which is always a great feeling.

I used soundflower during development (and oF 0.7.3 eep), but updated it to use oF 0.8, which is why you see ofxSoundStream in the code.

If you don’t have a Kinect it will use the device camera, but it does not work as well. You can use the far threshold setting for the OpenCV threshold in that case.

The source is up here.

Also I have put the source for Particles up here as well

You can find me on twitter here !


Particles 1 from dizzy pete.

Using ofFbo as a texture for ofMesh example

Springing from a discussion on the openFrameworks forums, I have uploaded a small example of using an FBO as a texture for a mesh with ofFbo and ofMesh. It also shows how you can use ofTranslate() and draw multiple fbos to a single screen if you are unfamiliar with such things.

Grab it here.

I also uploaded the source to the voronoi tessellation thing I made, here.

It's cold and wet in Sydney, I'm stuck inside preparing for finals, which maybe isn't such a bad place to be for now.

Voronoi Tessellation

Was messing around with these last weekend. It basically generates some random points, builds the tessellation around them, then fills each cell with the average color.



Voronoi Evolution from dizzy pete on Vimeo.


Also made some static images

OpenGL & openFrameworks Lighting example

I have been wanting to do more with lighting, but did not really feel like I had a reasonable grasp on How It Worked.

I made this app which has the basic lighting types:

• Ambient Lighting
• Directional Lighting
• Point Lighting
• Spot Lighting

It lets you set the various colours, like the diffuse colour and the specular highlights, and for the material used to colour the sphere you can also set the emissive light.

It is basic but for the basics it is fairly comprehensive, if you aren't quite sure what a diffuse or specular colour is, it will probably be useful. The only thing it doesn't have controls for is light attenuation and I commented out the alpha channel controls as they take up UI space and alpha blending is an app in itself.

There are a couple of oF lighting demo apps but they don't let you easily control the parameters. Mine uses the ofxUI addon so has external dependencies, but should make it a lot easier to see what happens when you shine a blue diffuse light with a red specular highlight on a yellow object.

A screen shot is below. I've made a couple of changes, the biggest is if you are holding down the space bar as you change a color it will change the RGB components together, so you can adjust in terms of black to white.

Source is up here: OpenGL openFrameworks Lighting Demo

These are the instructions from the top of the source:

Spot light defaults to a red light with a blue specular highlight
Point light is similar to a spot light, defaults to green light with white spec highlight
Directional light defaults to blue light with red specular light.
Ambient light defaults to weak grey.
Hold down space when changing a color to adjust black <-> white
Use the 'X Source' toggle to draw the light source
You can also adjust the material properties, shine and the various colours.
Toggles at the bottom of the control panel let you turn lights on/off, and also face culling
It uses ofEasyCam, left click + drag to move around right click + drag to zoom
This app depends on ofxUI and in turn ofXmlSettings

Interactive deJong Attractor

I have been working on this the last few weeks. It is an interactive deJong Attractor, developed using GLSL Shaders and C++ with openFrameworks.

The attractor is generated, then passed as a texture to a shader that builds a curl, then a bunch of particles float around that curl, changing color and opacity based on the attractor output.

It is also connected to a kinect, so the changes that you see on screen are coming from movement captured from the kinect.

I set it up on the dancefloor at a friends party, and included some iPhone footage of it in action at the end of the clip below.

Much of the detail gets lost when looking at the small vimeo embed, so please check out the larger HD version on vimeo here.


Attractor from dizzy pete

I think I have finally gotten deJong attractors and particle fields out of my system, on to the next thing.

Generative Sphere 2

Hey all, thought I would take my fancy new hardware for a spin and made this



For those interested, it uses 2 GLSL Shaders, one that takes the spectral curve as input and uses a ping-pong FBO to calculate the offsets, and the other to turn those offsets into displacement, colour etc.

A visual look at market randomness

I recently did some statistical testing to see if markets were random (details in the post Another cut at market randomness). It turns out they were, at least close to close returns for SPX/GSPC. My confirmation bias wasn't going to stand for that, so I thought about taking a different look.

Two things interested me. Firstly, I am looking at up vs down (i.e a higher or lower close than previous), rather than trying to predict an exact price. If markets are random then up or down have a probability of 0.5 each and are independent. A run of 5 consecutive ups or downs has a probability of 0.03125 or roughly 3%. How would that pan out looking at historical data?

Secondly, how could one visualise seemingly random data without it ending up looking like noise?

I came up with the following chart:

Each square represents one week and each line represents one year. If the close was higher than the previous week, it is blue, otherwise it is red. As the count of successive higher or lower weeks rise, the boxes get deeper in colour, up to a maximum of 5. As a side effect of date calculations and the definition of "week" some years have 53 weeks, which is why some lines are longer than others.

In total there were 138 runs of 5 weeks in the same direction out of 2208 samples, or around 6%, roughly double what we might expect.

Looking at that, I wondered what it would look like comparing weeks across years, comparing week 1 of year n with week 1 of year n + 1. That lead to the second chart:

This time we had 175 runs of length 5 out of 2208, just under 8%, again quite a bit more than the 3% we were expecting.  

That is all well and good, but these charts only represent the direction of the week to week moves, not the magnitude of the moves which is probably more important. Finally I took a look at the return over 5 periods. 

Again if it is positive the squares are blue, negative they are red. The colours are scaled as a proportion of the largest positive and negative returns for blue and red squares respectively. The very pale squares are where the returns were proportionally so close to zero they would not otherwise be visible, so I set a minimum level to ensure they displayed.

We can see that positive returns tend to follow positive returns and vice versa, at least for this 5 week look back period. This is somewhat deceptive as a negative return, though negative, may still be higher than the previous one implying a loss. 

What does all this mean? Not too much in practise, as it is another thing to know in advance if a series will have consecutive up days or down days. In this case a tradable edge is not so easily won.

However, it does reflect my understanding of how prices move a little better, in that they trend for a while then range for a while and vice versa, and things may not be as random as we might expect. My confirmation bias somewhat sated. 

The charts were done in Processing using the free weekly data from Yahoo! finance for GSPC. If you would like a chart for a given ticker, let me know.