Chaotic Attractors
Chaotic Attractors are a subset of attractors which exhibit the properties of fractals. I'll be honest, I'm not 100% sure what that means, but I know enough to make pretty pictures of them. Each one is defined by a function that operates on a vector and returns the velocity that that point is moving, which is enough to calculate its next position in the simulation. We repeatedly apply the equation to a point and project it to the screen, producing an animation. We'll be focusing exclusively on 3D attractors, although there's no reason it wouldn't work for 2D attractors also.
I experimented a lot with getting this program to run on the GPU as well as the CPU, although using the GPU turned out not to have a performance benefit. Nonetheless, I've left a decent amount of commentary about the GPU version below. We'll define a number of default iterative equations and pass pointers to them to a master function which calls the iterative function a certain number of times between frames on a large set of points. Then we'll use a simple method for rendering the points by just drawing them to an output image.
The Implementation
The implementation is fairly simple. We call the iterative function on all of the points and write the result back to the array. We then project all of the points to the screen and paint the corresponding pixel white. I ran some tests with sending two arrays of points to the iterator, so that the output of the iterative function would not need to be written to a temporary location before being copied into the points array. It doesn't increase the memory overhead on the GPU (either way, the host only pulls one of them from the GPU each frame) but it still slowed the program down on both the CPU and GPU by around 15%.
Neat! And it rendered so fast on the CPU as to invalidate all the work I put into the GPU version. It took maybe one second to render. And, no matter how you slice it, the overhead of transferring all those points to the GPU and back each frame, not to mention the image itself, is simply far too slow to warrant parallelization. I was able to pull a 9% speedup (26.6 seconds down to 24.1) when rendering 24576 points which performed 100 steps per frame, and rendered 256 frames at 2048x2048 resolution, but that was about it. Really, the step size is the determining factor in whether the GPU or CPU is faster. This is because the overhead associated with transferring data between the host and device scales with the number of points and with the number of pixels in the output, and the ability to parallelize the program comes with increasing the ratio of work done on the GPU to work done dealing with the overhead of using the GPU. The GPU version ended up being cut from the program because I could no longer justify it. On the plus side, it simplified the code a lot.
Before I produce the next render, I'd like to add depth information to these points. I remember this being an issue the last time I tried rendering videos like this. There are a couple of options here, but the one I'd like to try first is coloring the points according to their distance from a center point (the center point will need to be different for different attractors. This should make the renders look better in general as well.
There's one more thing I'd like to implement. I'd like to create a class so that we can initialize the points without having to access the class's internals. It'll basically just be a list of spheres within which points will be randomly generated. Now, the code to produce that video with my chaotic attractor library looks like this:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include "chaos.hpp"
int main() {
int width = 512*4;
int height = 512*4;
int frames = 600;
int num_points = 2048*16;
// Setup the initializer
initializer in(1);
in.add_sphere(vecd3(0, 0, 0), 0.2);
// Create the scene descriptor
iterator_descriptor id(&LORENZ, width, height, num_points, history_len, in);
id.set_color(vecd3(0, 0, 32), 16);
// Set the step size and number of steps per frame
id.step_size = 0.0003;
id.iters_per_frame = 100;
clock_t start = clock();
// Render the frames
for (int f = 0; f < frames; f++) {
printf("Rendering frame %d\n", f);
// Change the camera position and rotation based on the frame.
float theta = (float) f / frames * 2 * 3.14159;
quaternion rotation(vecd3(0, 0, 1), theta);
id.set_camera(rotation.apply(vecd3(-48, -8, 32)), rotation);
// Get the next frame.
id.next_frame();
// Save the image to a file. Make sure to create
char hdr[64];
int hdr_len = sprintf(hdr, "P6 %d %d 255 ", width, height);
char fn[64];
sprintf(fn, "frames/%03d.ppm", f);
FILE* fout = fopen(fn, "wb");
fwrite(hdr, 1, hdr_len, fout);
fwrite(id.img, 1, width*height*3, fout);
fclose(fout);
}
clock_t end = clock();
printf("Completed in %.4f\n", (float) (end - start) / CLOCKS_PER_SEC);
printf("Goodbye!\n");
return 0;
}
Now that we have that, all that's left to do is find some more chaotic attractors to look at and render them out. The parameters will have to be adjusted for each, so I'll include them below each video. Each one will be rendered out at 2048x2048 and scaled down to 1024x1024. I recommend watching them in fullscreen, because they're very dark relative to my website.