In the video game industry older games get remastered all the time. Hardware power improves so older games are adapted to have better graphics and sound etc. So for a nostalgic trip into history (at least for me) it was time for some Visions of Chaos movie remasters.

After recently adding the new Custom Formula Editor into Visions of Chaos I decided to go back and re-render some sample Mandelbrot movies at 4K 60fps. Most of these Mandelbrot movie scripts go back to the earliest days of Visions of Chaos even before I first released it on the Internet. The only changes made have been to add more sub frames so they render more smoothly and last longer.

Thanks to the new formula editor using OpenGL shading language and a recent NVidia GPU all the movie parts rendered overnight. Every frame was 2×2 supsampled so the equivalent of rendering an image 4 times as large and then downsampling to increase the quality. The original movie was a 46 GB XVID encoded AVI before YouTube put it through all of its internal recoding steps.

One of the features I have wanted to implement since the earliest versions of Visions of Chaos has been a formula editor and compiler so users can experiment with their own fractal formulas. This has also been requested many times from various users over the years. Now it is finally possible.

Rather than write my own formula parser and compiler I am using the OpenGL Shading Language. GLSL gvies faster results than any compiler I could code by hand and has an existing well documented syntax. The editor is a full color syntax editor with error highlighting.

As long as your graphics card GPU and drivers support OpenGL v4 and above you are good to go. Make sure that you have your video card drivers up to date. Old drivers can lead to poor performance and/or lack of support for new OpenGL features. In the past I have had outdated drivers produce corrupted display outputs and even hang the PC running GLSL shader code. Always make sure your video drivers are up to date.

For an HD image (1920×1080 resolution) a Mandelbrot fractal zoomed in at 19,000,000,000 x magnification took 36 seconds on CPU (Intel i7-4770) vs 6 seconds on GPU (GTX 750 Ti). A 4K Mandelbrot image (3840×2160 resolution) at 12,000,000,000 x magnification took 2 minutes and 3 seconds on CPU (Intel i7-6800) and 2.5 seconds on GPU (GTX 1080). The ability to quickly render 8K res images for dual monitor 4K displays in seconds is really nice. Zooming into a Mandelbrot with minimal delays for image redraws really increases the fluidity of exploration.

So far I have included the following fractal formulas with the new Visions of Chaos. All of these sample images can be clicked to open full 4K resolution images.

Buffalo Fractal Power 2

Buffalo Fractal Power 3

Buffalo Fractal Power 4

Buffalo Fractal Power 5

Burning Ship Fractal Power 2

Burning Ship Fractal Power 3

Burning Ship Fractal Power 4

Burning Ship Fractal Power 5

Celtic Buffalo Fractal Power 4 Mandelbar

Celtic Buffalo Fractal Power 5 Mandelbar

Celtic Burning Ship Fractal Power 4

Celtic Mandelbar Fractal Power 2

Celtic Mandelbrot Fractal Power 2

Celtic Heart Mandelbrot Fractal Power 2

Heart Mandelbrot Fractal Power 2

Lyapunov Fractals

Magnetic Pendulum

Mandelbar (Tricorn) Fractal Power 2

Mandelbar Fractal Power 3

Mandelbar Fractal Power 3 Diagonal

Mandelbar Fractal Power 4

Mandelbar Fractal Power 5 Horizontal

Mandelbar Fractal Power 5 Vertical

Mandelbrot Fractal Power 2

Mandelbrot Fractal Power 3

Mandelbrot Fractal Power 4

Mandelbrot Fractal Power 5

Partial Buffalo Fractal Power 3 Imaginary

Partial Buffalo Fractal Power 3 Real Celtic

Partial Buffalo Fractal Power 4 Imaginary

Partial Burning Ship Fractal Power 3 Imageinary

Partial Burning Ship Fractal Power 3 Real

Partial Burning Ship Fractal Power 4 Imageinary

Partial Burning Ship Fractal Power 4 Real

Partial Burning Ship Fractal Power 5

Partial Burning Ship Fractal Power 5 Mandelbar

Partial Celtic Buffalo Fractal Power 4 Real

Partial Celtic Buffalo Fractal Power 5

Partial Celtic Burning Ship Fractal Power 4 Imaginary

Partial Celtic Burning Ship Fractal Power 4 Real

Partial Celtic Burning Ship Fractal Power 4 Real Mandelbar

Perpendicular Buffalo Fractal Power 2

Perpendicular Burning Ship Fractal Power 2

Perpendicular Celtic Mandelbar Fractal Power 2

Perpendicular Mandelbrot Fractal Power 2

Quasi Burning Ship Fractal Power 3

Quasi Burning Ship Fractal Power 5 Hybrid

Quasi Celtic Heart Mandelbrot Fractal Power 4 Real

Quasi Celtic Heart Mandelbrot Fractal Power 4 False

Quasi Celtic Perpendicular Mandelbrot Fractal Power 4 False

Quasi Celtic Perpendicular Mandelbrot Fractal Power 4 Real

Quasi Heart Mandelbrot Fractal Power 3

Quasi Heart Mandelbrot Fractal Power 4 Real

Quasi Heart Mandelbrot Fractal Power 4 False

Quasi Heart Mandelbrot Fractal Power 5

Quasi Perpendicular Burning Ship Fractal Power 3

Quasi Perpendicular Burning Ship Fractal Power 4 Real

Quasi Perpendicular Celtic Heart Mandelbrot Fractal Power 4 Imaginary

Quasi Perpendicular Heart Mandelbrot Fractal Power 4 Imaginary

Quasi Perpendicular Mandelbrot Fractal Power 4 False

Quasi Perpendicular Mandelbrot Fractal Power 5

A lot of the above formulas came from these summaries stardust4ever created.

All of these new custom fractals are fully zoomable to the limit of double precision floating point variables (around 1,000,000,000,000 magnification in Visions of Chaos). The formula compiler is fully supported for movie scripts so you can make your own movies zooming into these new fractals.

This next sample movie is 4K resolution at 60 fps. Each pixel was supersampled as the average of 4 subpixels. This took only a few hours to render. The resulting Xvid AVI was 30 GB before uploading to YouTube.

So, if you have been waiting to program your own fractal formulas in Visions of Chaos you now can. I look forward to seeing the custom fractal formulas Visions of Chaos users create. If you do not understand the OpenGL shading language you can still have fun with all the default sample fractal formulas above without doing any coding.

DLA is a simple process to simulate in the computer and was one of my first simulations that I ever coded. For the simplest example we can consider a 2D scenario that follows the following rules;

1. Take a grid of pixels and clear all pixels to white.
2. Make the center pixel black.
3. Pick a random edge point on any of the 4 edges.
4. Create a particle at that edge point.
5. Move the particle randomly 1 pixel in any of the 8 directions (N,S,E,W,NE,NW,SE,SW). This is the “diffusion”.
6. If the particle goes off the screen kill it and go to step 4 to create a new particle.
7. If the particle moves next to the center pixel it gets stuck to it and stays there. This is the “aggregation”. A new particle is then started.
Repeat this process as long as necessary (usually until the DLA structure grows enough to touch the edge of the screen).

When I asked some of my “non-nerd” aquaintances what pattern would result from this they all said a random blob like pattern. In reality though the pattern produced is far from a blob and more of a coral like branched dendritic structure. When you think about it for a minute it does make perfect sense. Because the moving particles are all coming from outside the fixed structure they have less of a chance of randomly walking between branches and getting to the inner parts of the DLA structure.

All of the following sample images can be clicked to see them at full 4K resolution.

Here is an image created by using the steps listed above. Starting from a single centered black pixel, random moving pixels are launched from the edge of the screen and randomly move around until they either stick to the existing structure or move off the screen.

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: when they move next to a single stuck particle

The change in this next example is that neighbouring pixels are only checked in the N, S, E and W directions. This leads to horizonal and vertical shaped branching.

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W
Particles stick condition: when they move next to a single stuck particle

There are many alternate ways to tweak the rules when the DLA simulation is running.

Paul Bourke’s DLA page introduces a “stickiness” probability. For this you select a probability of a particle sticking to the existing DLA structure when it touches it.

Decreasing probability of a particle sticking leads to more clumpy or hairy structures.

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: 0.5 chance of sticking when they move next to a single stuck particle

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: 0.1 chance of sticking when they move next to a single stuck particle

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: 0.01 chance of sticking when they move next to a single stuck particle

Another method is to have a set count of hits before a particle sticks. This gives similar results to using a probability.

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has hit stuck particles 15 times

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has hit stuck particles 30 times

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has hit stuck particles 100 times

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has hit stuck particles 1000 times

Another change to experiment with is having a threshold neighbour count random particles have to have before sticking. For example in this next image all 8 neighbours were checked and only 1 hit was required to stick, but the moving particles needed to have at least 2 fixed neighbour particles before they stuck to the existing structure.

The first 50 hits only need 1 neighbour. This build a small starting structure which all the following hits stick to with 2 or more neighbours.

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has 2 or more stuck neighbours

That gives a more clumpy effect without the extra “hairyness” of just adding more hit counts before sticking.

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has 3 or more stuck neighbours

This seems a happy balance to get thick branches yet not too fuzzy ones.

Start configuration: Single centered black pixel
Random pixels launched from: rectangle surrounding existing structure
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has 3 or more stuck neighbours and has hit 3 times

The next two examples launch particles from the middle of the screen with the screen edges set as stationary particles.

Start configuration: Edges of screen set to black pixels
Random pixels launched from: middle of the screen
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has 1 or more stuck neighbours

Start configuration: Edges of screen set to black pixels
Random pixels launched from: middle of the screen
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has 3 or more stuck neighbours

These next three use a circle as the target area. Particles are launched from the center of the screen.

Start configuration: Circle of black pixels
Random pixels launched from: middle of the screen
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has 1 or more stuck neighbours

Start configuration: Circle of black pixels
Random pixels launched from: middle of the screen
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has 2 or more stuck neighbours

Start configuration: Circle of black pixels
Random pixels launched from: middle of the screen
Neighbours checked for an existing pixel: N, S, E, W, NE, NW, SE, SW
Particles stick condition: once a moving particle has 3 or more stuck neighbours

This next image is a vertical 2D DLA. Particles drop from the top of the screen and attach to existing seed particles along the bottom of the screen. Color of sticking particles uses the color of the particle they stick to.

Start configuration: Bottom of screen is fixed particles
Random pixels launched from: top of the screen
Neighbours checked for an existing pixel: S, SE, SW
Particles stick condition: once a moving particle has 1 or more stuck neighbours

Dendron Diffusion-limited Aggregation

Another DLA method is Golan Levin’s Dendron DLA. He kindly provided java source code so I could experiment with Dendron myself. Here are a few sample images.

Hopefully all of the above examples shows the wide variety of 2D DLA possible and the various methods that can produce them. This post was mainly going to be about 3D DLA, but I got carried away trying all the 2D possibilities above.

3D Diffusion-limited Aggregation

DLA can be extended into 3 dimensions. Launch the random particles from a sphere rather than a surroundiong circle. Check for a hit against the 27 possible neighbours for each 3D grid cell.

For these movies I used default software based OpenGL spheres. Nothing fancy. Slow, but still managable with some overnight renders.

In this first sample movie particles stuck once they had 6 neighbours. In the end their are approximately 4 million total spheres making up the DLA structure.

This second example needed 25 hits before a particle stuck and a particle needed 5 neighbours to be considered stuck. This results in a much more dense coral like structure.

A Quick Note About Ambient Occlusion

Ambient occlusion is when areas inside nooks and crannies are shaded darker because light would have more trouble reaching them. Normally to get accurate ambient occlusion you raytrace a hemisphere of rays from the surface point seeing how many objects the rays intersect. The more hits, the darker the shading. This is a slow process. For the previous 3D DLA movies I cheated and used a method of counting how many neighbour particles the current sphere has. The more neighbours the darker the sphere was shaded. This gives a good enough fake AO.

Programming Tip

A speedup some people do not realise is when launching random particles. Use a circle or rectangle just slightly larger than the current DLA structure. No need to start random points far from the structure.

Other Diffusion-limited Aggregation Links

For many years now the ultimate inspiration in DLA for me has been Andy Lomas.

Another change Andy uses is to launch the random walker particles in patterns that influence the structure shape as in this next image.

Future Changes

1. More particles. The above 2 movies have between 4 and 5 million particle spheres at the end of the movies. Even more particles would give more natural looking structures like the Andy Lomas examples.

2. Better rendering. Using software (non-GPU) OpenGL works but it is slow. Getting a real ray traced result supporting real ambient occlusion and global illumination would be more impressive.

3. Controlled launching of particles to create different structure shapes other than a growing sphere.

Mobile phones and tablets have had nice high DPI displays for a long time now. PC screens have started to catch up and 4K monitors are starting to come down in price and will become the standard in the future.

The good thing about higher DPI screens is that there are many more pixels on the same sized screen so text and images are shown much more clearly.

The bad thing is most applications (especially older programs) are not aware of High DPI scaling settings. If an application does not support scaling Windows just “zooms” the application window to a larger size. This leads to blurry text that most people complain about. So you either set the scaling factor to 100% which leads to tiny text or you live with blurry text.

Over the past few weeks I have been working on making Visions of Chaos high DPI aware. The end result is that it will now run happily on all scale settings and higher 4K monitors without the text being too tiny to read or blown up and blurry. The menus and all text within Visions of Chaos will scale according to your Windows settings and remain smooth and crisp to read.

High DPI in Visions of Chaos

Prior to Visions of Chaos being DPI aware Windows would just scale the output window like in a photo editor app. The following shows how the Visions of Chaos window looks at 150% scaling under Windows 10 on a 4K display.

This leads to the blurred text and the generated image (set to 480×360 pixels in size) is shown onscreen also stretched and blurred to 725 pixels wide.

Here is the same window using the latest version of Visions of Chaos that is DPI aware. The text fonts are scaled to a larger size so they remain crisp and smooth. The fractal image that has been set to 480×360 pixels is exactly 480×360 monitor pixels.

Windows is still playing catch up with higher resolution DPI support, but it will hopefully get better as 4K monitors become the standard. At least you can be confident that Visions of Chaos will continue to be usable and readable at high DPI settings.

Now I can get back to adding new features to Visions of Chaos.

ADDLED is a new and unique puzzle game for Android devices that I have been working on for the past few months. After much testing and preparation I am finally ready to release it to the public.

The aim is to find a set of numbers that add up to a total value. Initially the levels are simple with just sums using positive numbers, but later levels give larger grid sizes and negatives, multiplication and division.

As the difficulty increases there are more strategies to implement to get through levels.

The levels are quick enough to fill in a few minutes when you have some spare time.

If you think this is your sort of puzzle game, download ADDLED through the Google Play Store.

NOTE: This post is currently WRONG. I am not correctly comparing every particle to every other particle in the gravity calculations. So, consider the listed results and speeds as incorrect. I will update this post once I get a correct working model going.

OpenCL allows you to write programs that run on your video card processor chip (GPU). GPUs can have many hundreds of cores so can process many more things simultaneously than a CPU can. A good candidate for parallel processing is a gravity simulation.

Previous Results

Since I originally posted the following 3D gravity movies to YouTube…

…there were questions and some skepticism in the comments so hopefully this blog post helps clarify things.

Coding Information

It has been a while since I was working with the gravity code, but this should be enough info for those interested.

This is the OpenCL kernel code that does the calculation for every object each frame. I had to screen capture it as WordPress kept deleting lines no matter what tags I used.

The kernel uses the standard Newtonian gravitation formulas. No other fancy calculations are included. So no energy conservation, no collision detection, no objects clustering into planets, no dark matter, no dissipation, no energy conservation, no overall angular momentum constraint, no speed-of-light limit on propagation of gravity taken into account and no inertia of mass. Basically it is the simplest possible formulas that give gravity like results.

The pos, vel, acc and mass are float arrays that hold the position, velocity, acceleration and mass for all the objects. Every frame those arrays are filled and passed to OpenCL using clCreateBuffer and clSetKernelArg. Once the above kernel code processes the objects the values are read back from the GPU using clEnqueueReadBuffer and then OpenGL (GL not CL) is used to display the objects to the screen using transparent billboard quads. Display is currently done in software OpenGL which is why the OpenGL display time is slower than the OpenCL calculations time.

The mingravdist check makes the calculations ignore objects that are too close together. If you allow objects very close together to interact they end up flinging objects out of the simulation space at a very high speed. For a world size of 300 units I use a mingravdist of 1.

Latest Results

Here is a new movie I just rendered with 3,000,000 particles. The frames took 4,700 ms to render on a GeForce GTX 570. Out of that time 844 ms was the OpenCL calculations. The rest of the time was rendering and passing the data back and forth to and from the GPU.

Unfortunately YouTube’s compression ruined the movie quality a bit. Mostly due to the noisy/static like nature of the millions of particles. Not enough I frames and too many P frames. Here are a series of screenshots showing what the frames looked like before the compression.

To push it further, here is a rotating disk of 5,000,000 objects. This one took 6,950 ms per frame with 1,420 ms for OpenCL calculations.

Again, here are some uncompressed screenshots.

The GTX 570 is on the lower end of the GeForce cards these days so the simulation speeds should be faster on the newer cards.

10,000,000 objects was also possible, but until I work out better ways of display it is not worth posting as most of the detail gets lost in the cloud of billboard particles. 10,000,000 was taking 8,780 ms per frame with 2,840 ms OpenCL time.

Try It Yourself

If use Windows you can download Visions of Chaos and see the simulations run yourself. Here are a few quick steps to get you going;

1. Open Visions of Chaos
2. Select Mode->Gravity->3D Gravity to change into the 3D Gravity mode
3. The 3D Gravity Settings dialog will appear
4. Change the number of objects to 1,000,000
5. Change the Time step to 0.02
6. Change the Size of objects to 0.2
7. Check Create AVI frames if you want to create an AVI movie from the simulation
8. Click OK

Make sure you have the latest video card drivers so the OpenCL code runs as optimal as possible. For NVidia go here and for AMD go here.

Rayleigh-Taylor instability (RT) occurs when a less dense fluid is forced into a heavier fluid. If a heavier fluid is resting on a lighter fluid then gravity pulls the heavier down through the lighter fluid resulting in fingering, mushrooming and swirling patterns.

Here is an exmaple image courtesy of Wikipedia showing some steps from simulating RT.

This is a much more complex example from a supercomputer run at the Laboratory for Computational Science and Engineering, University of Minnesota. Also check out their movie gallery for more incredible fluid simulation examples.

RT patterns also emerge in supernova simulations like the following two images.

Mark J Stock uses his own fluid simulation code to create incredibly detailed RT examples like this

thunabrain has this example of using the GPU to simulate fluids showing RT

Real Life Rayleigh-Taylor Instabilities

Pouring milk into coffee leads to RT patterns. I took these with my phone so they are not as crisp as I would have liked.

Dropping ink into water also leads to RT patterns as in these photos by Alberto Seveso

Using SPH to simulate RT

I had some previous success with implementing Multiphase Smoothed-Particle Hydrodynamics so I was curious to see what sorts of RT like results the SPH code could create. I have now added the options to generate RT setups in the SPH mode of Visions of Chaos.

The following SPH RT simulations use approximately 500,000 discreet individual particles to make up the fluids. They are all full HD 1080p 1920×1080 60fps videos. It was very tedious to try various settings and wait for them to render. I spent the last few weeks tweaking code and (99.99% of that time) rendering test movies to see the changes before I was happy with the following three example movies.

The code is single threaded CPU only at this stage, so much patience was required for these movies.

For this first example the top half of the screen was filled with heavier purple particles and the lower half with lighter yellow particles. A very small random movement was added to each of the particles (just enough to stop a perfect grid of particles) and then the simulation was started. 73 hours (!!) later the calculations were completed for the 3000 frames making up the movie.

The next example took around 105 hours for the 4000 frames. This time three fluids are used. Heaviest on top, medium in the middle and lightest on the bottom.

And a final three fluid example that took 74 hours for the 3000 frames.

If you click the title text of the movies they will open in a new tab allowing them to be viewed in full screen HD resolution.