The 17th meeting of the Houston Recreational Computer Programming Group was held this past Sunday, May 11th, 2014. Once again, pretty good turnout and plenty of cool things were presented.

Stephen Cameron presented his ongoing progress on the fake fluid dynamics work that he presented previously at the April 2014 meeting. The CurlyVortex program is now working much better than it was last month. The basic idea is that the Curl of a 2D Perlin noise field is used to obtain a divergence free velocity field which can serve as a passable model of an incompressible fluid flow.

Perlin noise is a kind of pseudo-random number field in which you supply coordinates, for example (x,y), and get a noise value for those coordinates. Small changes to the coordinates result in small changes to the noise value, and larger changes to the coordinates may give larger changes in the noise value. So it's kind of a "smooth" field of random numbers. If you imagine the noise values as a height field, you can then compute the slope, or gradient in x and y at each point in a plane. If you then take the vector representing this slope and turn it 90 degrees clockwise or counterclockwise, depending on whether the slope is uphill or downhill, you get the "curl" of the noise field, which will consist of vectors tangent to coutour lines of the height field. You can then use (possibly scaling first) this curl as a non-divergent velocity field.

Given the velocity field, you can then simulate a bunch of particles in the velocity field in which each particles velocity (and thus next position) is determined by its location within the field. If a particle's color is determined by its initial position, mapping this position back to a corresponding image, you can simulate the image being distorted as if it were floating atop a swirling fluid.

The aim of this exercise is to eventually produce 3D textures that can be mapped to a sphere for gas giant planets similar to Jupiter within the game Space Nerds In Space. To that end the curly vortex program also imparts a few horizontal velocity bands some moving left, some moving right into the process.

A gallery of images from curlyvortex may be found here.

Once the 2D version of the program was working well, the transition to 3D was attempted in a C program, dubbed "gaseous-giganticus". Gaseous-giganticus is part of the Space Nerds In Space codebase.

For the 3D version of the program, the particles are constrained to the surface of a sphere rather than to the surface of a plane. There are six velocity fields maintained rather than a single field. These six velocity fields are 2D arrays of 3D vectors and correspond to the six faces of a cube. For a given particle the velocity is determined by projecting a ray from the center of the sphere through the cube inscribed in the sphere. The intersection of the ray with the cube determines the face (which of the 6 velocity fields) and the coordinates on that face (the indices into the 2D velocity field of that face).

Computing the six velocity fields is not quite as simple as in the 2D case. A 4-octave Simplex noise field is sampled with the (x,y,z) coordinates of of the sphere that correspond to each of the cells in the 6 faces of the velocity field arrays. The 3D noise gradient for each point is calculated, then projected into the surface of the sphere by normalizing the sum of the vector defining the point and the relatively much smaller noise gradient vector. This projected vector is then rotated left or right by 90 degrees within the surface of the sphere (about the axis defined by the particle's position relative to the origin of the sphere) depending on whether the noise gradient is "uphill" or "downhill". That is, whether the magnitude of the sum of the particle's normalized position vector and the noise gradient is greater than or equal to the radius of the sphere.

Particles are then dumped onto the surface of the sphere and the velocity field is applied iteratively as in the 2D simulation, but normalizing particle positions as we go to keep them constrained to the surface of the sphere (correcting for cumulative errors). Initial particle colors are provided by a few different available mappings from a rectangular input image to the surface of a sphere. Probably the one which works the best for the purpose of producing nice looking gas giant planet textures is the sinusiodal projection.

Gaseous-giganticus is multithreaded, using 6 threads for computing the 6 velocity fields and 6 threads for updating images during processing and as many threads as there are available cores for calculating particle motion.

A gallery of images from gaseous-giganticus may be found here.

Andrew Okin presented on a debugger he wrote for his mine craft launcher. When minecraft launches it often crashes, but little debug information is given. Andrews program records pertinent debug information, and he explained the various problems he encountered in setting this up.

Chris Cauley (that's me) presented on his latest css fractal, the serpinski triangle. It makes use of the CSS 3 transform property to create a triangle in side of a div. Each div then is given 3 more divs, which are laid out in such a way that the famous fractal is formed. Full details and a live demo can be seen on my blog.

Patrick Wheeler presented a short explanation of how to build a convergent replicated data type, CRDT, counter on top of Riak. CRDTs allow for multiple distributed actors to write to the same data structure without risk of losing data. These types of structures have good availability and partition tolerance while allowing for some variance in consistency across distributed nodes (more info). That said CRDTs are eventually consistent (more info). For example a CDRT that counting uniques hits to a web page severed in Houston on London might have consistent counts all data older then 200ms. 100ms old data might not yet have converged and would only partial representation of of the total uniques.