Porting a particle(ish) simulation

Hi, I’d like to port the following Processing sketch to OpenFrameworks, and improve it while I’m at it:
http://www.youtube.com/watch?v=7pl-H0HpyxU

The simulation works as follows: I have “loops” (since “string” is already used for something else in programming languages) of points, through which colours flow as a visual representation of information. At intersections the colours interact and change. Porting the simulation is pretty straightforward actually - it’s the graphics part that has me stumped.

What I’ve done so far in Processing is use the pixel array with updatePixels() for direct pixel manipulation. Every point in the simulation is a pixel on the screen. Basically, I have an array of points (named “fibres”, to stay within the theme) that have an x, a y and a c component[sup]*[/sup]. Every frame any point within the screen (the simulation space can be bigger than the viewing space) is put in the pixel array, which then gets updated.

So far, to do this in OpenFrameworks, I make a texture the size of the screen. Then I update the texture every frame by copying an array of chars[sup]**[/sup] representing the pixels to it. It works, but it isn’t exactly fast… Also, since I’m essentially drawing lines (one dimension), updating an entire texture (two dimensions) that is mostly empty is a huge waste of resources.

Is there a way for me to do this more efficiently? I’ve looked at ofLine, ofPath, and similar options, but the problem as I see it is that every strand many, many points, and every point can theoretically have a different colour. One option is calling ofLine for each point, but that is very slow on my little netbook.

I thought maybe I can try having a one-dimensional texture for the colours, and apply it to a line, or use shaders to manipulate the shape? I don’t know enough about OpenGL to know what is and isn’t possible, and my question appears to be just outside the scope of the regular things covered by tutorials (at least the ones I’ve found so far).

Any suggestions?

[sup]*[/sup] Since the only information being updated every frame are the colours at the intersections, and the position of colours relative to the (x,y) position, the program is optimised by using an offset to avoid a read/write for every point in a loop. Big speedup, but not important to my current problem.

[sup]**[/sup] Actually, I use a union of a 4 unsigned chars/1 unsigned int, so I can use 0xFFFFFFFF to represent a white RGBA pixel, or 0xFF0000FF to represent a red pixel, etc. No idea if that has any influence on performance.

Ok, I’ve found this tutorial:
http://www.arcsynthesis.org/gltut/index.html

I’ll work my way through it and see if I can figure out my problem on my own. If I do, I’ll share my solution here. Might be of interest to someone else in the long run :slight_smile: