Geokone Tutorial Video :: Creating Sacred Geometry Live

I did an quick’n’sleek tutorial video on how to create beautiful Geometry with  GeoKone.NET., check out the video here:

In this video I go through the basics, while creating art and explaining what I am doing.

Just watching somebody create geometry can also be quite relaxing, especially with great music by Miika Kuisma in this video.

Video :: Export frame-by-frame movie from GeoKone Tutorial

I had some inspiration to do a long requested tutorial on how to export movies out of GeoKone, so I decided to make it as the new version 0.99.62 has the ability to export frame-by-frame by using the combination of “PrintScreen/ctrl+p, ‘ (quote), Enter” keyboard shortcuts.

Here is the tutorial video, featuring background music by my friend Luminescent:

With this technique you can also export GIF -animations! Here is an example:

This image showcases the Hue Rotation feature in the new release

This image showcases the Hue Rotation feature in the new release

Enjoy this new feature and have fun, go to http://GeoKone.NET and start playing around with these new features!

Children using GeoKone and Transparent Film Paper to create Beautiful Art

Was so happy to see this that I had to share this link here also. Amy Zschaber from, an art teacher teaching in Georgia, shared one of her classes she had taught on the subject of Islamic Art & Architecture (which is heavily based on natural, sacred geometries).

Specifically, she introduced the children to GeoKone, and each student made some designs they liked, then they printed it out and colored by hand on transparent film paper used in old projectors.

The results are beautiful! Sharing couple of images here that the children made:

photo 4 (2)

photo 4 (1)

photo 3

photo 2 (3)

photo 2 (4)

This saved my day (or night to be exact). One of my goals in life is to share this knowledge with children, and to open up the creativity in kids, so this really warms up my heart and motivates me to continue working on this subject.

Check out her post here for more images and the way she taught this to her students:
Big thanks for Amy for posting this online!

GeoKone.NET updated with PDF Support

http://GeoKone.NET has been updated! Now with support for Downloading PDF versions of your scene!

GeoKone.NET Blasting Geometry :: Now With PDF Export Support!

GeoKone.NET Blasting Geometry :: Now With PDF Export Support!

Actually it has been over a month already from the release, been pretty hectic with getting up to speed, will write about that more in a separate post later.

Release Notes

  • PDF Downloading, download Scalable Vector Graphics versions of your scenes, in PDF format. Requires for you to register an user, scene to be saved on our server and purchased PDF downloads. You can purchase PDF downloads with Paypal currently, considering adding Bitcoin support in the upcoming releases.
  • Nudge Sliders, New UI elements for adjusting poly parameters with mouse, nudge sliders. These enable much more precise control of parameter values with the mouse too. Slide left and right to add or decrease to current value increasingly.
  • Hide User Interface, The option ‘Scene/Hide User Interface’ will hide all the user interface elements from the screen. Combine this with fullscreen to get fullscreen canvas for now.
  • User Interface Improvements, Show current active formation and number of formations on the scene, added Golden Ratio scene size presets and now the currently modified parameter value is shown in the bottom right corner.

For full list of changes, see the ChangeLog.

PDF Exporting

This is one of the most requested features since the beginning of GeoKone, and finally it is here. Now you can export your scenes to Adobe Illustrator, Sketch or other vector based programs and continue editing your scene there. This means you can now easily make print quality versions of your scenes, for example for t-shirts, art and other physical objects you might want to decorate with GeoKone art.

The previous version of the downloaded PDF will always be stored on the server, so you can re-download already exported scenes without having to purchase more. This is a paid feature, because running the servers cost money and for now I have paid it from my own pockets. All PDF purchases and donations help support keeping GeoKone running! ^_^

Here are a couple of examples of PDF files exported with GeoKone (click on image to open PDF version)

GeoKone PDF Example 1

GeoKone PDF Example 1


GeoKone PDF Example 2

GeoKone PDF Example 2

GeoKone PDF Example 3

GeoKone PDF Example 3


Create Geometry! Be Creative!

Now go to http://www.GeoKone.NET, register yourself an account, Create A Scene, Save It and check out the ‘Scene/Download PDF’ option :)

GeoKone.NET 0.98.20 Released :: Improved Scene Loader with Thumbnails

New version of http://GeoKone.NET is online!

Improved Scene Loader

Improved Scene Loader

Release Notes

  • New improved scene loader. Now shows thumbnail previews of your scenes. Much easier to use. Loads more scenes on demand as you scroll down the list.
  • Server side rendering of scenes via converting the project to Java+Processing and generating thumbnails of your scenes everytime you save a scene. This will enable more features in the upcoming releases, like seeing what scenes other people are creating.
  • All mouse operations now require you to to drag, holding the mouse button down while moving. This is to prevent accidental modifications of the scene and to more comply with how other software works.
  • Remove Google stats tracking, didn’t really use this so much and it just slows down the initial load time
  • Some small tweaks and optimizations in the UI & help

Scene Loader Notes

The new Scene Loader will generate a thumbnail image of your scene everytime you save it. This has some limitations currently, as the codebase that generates the thumbnail is running on Java+Processing, instead of Javascript+Processing.JS, so the images are not rendered correctly on all cases. Especially really small scenes and scenes that utilize the bug (or feature) of setting childNumPointsFixed or childNumPointsRatio to a fraction (1.5 example) will not render correctly on the server side.

Also some really complex scenes with very high recursion depths unfortunately will usually result in a out of memory error on the java side of things, so these might not work either.

I’m pretty happy that this works anyway on this level, so I can now start working on implementing sharing of scenes with others and then seeing what people are creating with GeoKone.NET :)

Start Creating Geometry!

Now go to http://www.GeoKone.NET, sign up for an account and start saving your scenes on the server!

Development Issues & Early Design Drafts with GeoKone.NET

I felt like writing about the design process and some implementation details that I have been going through since I started working on GeoKone.NET. I will talk about performance issues, early designs that I worked for GeoKone, show some screenshots of different versions along the development process and finally look at what is up and coming with the next version of GeoKone.NET.

I was originally thinking about waiting for 1.0 version until to write about some of this stuff, but I feel it’s maybe better to split it into couple of parts and just to show you what kind of things I am facing when developing GeoKone.NET

Performance & Design Issues

One of the issues that I have been struggling constantly with GeoKone  is performance.

Processing.js + Javascript + HTML5 techniques have not been developing at the pace I would have wished for. When I started implementing GeoKone about 1.5 years ago, I thought that WebGL would already be widely supported or that browsers would have found an unifying way of handling canvas element + input + large amounts of classes, but I guess I was overly optimistic on this.

The first version of GeoKone used a simple model: Processing.js running in noLoop() mode and the canvas was only redrawn when user changed the input. This worked pretty well, as GeoKone was still really simple.

Early Beta Version of GeoKone

Early Beta Version of GeoKone

But this noLoop() model was too simple for taking into account ways to present visual feedback for the user when interacting with the PolyForms (the formations on the screen, based on number of points around a circle). I needed a way to run logic & drawing even when the user was not doing anything, so I could present cool animations and transition effects in the program that would run for a while after the user stopped doing anything, or before stuff happened on the screen.

So I designed to take the game engine approach, where a collection of state machines are running at 30 FPS, rendering all polyforms on each frame. This model was used before versions 0.96, and it proved to be too slow to be really used without hardware acceleration.

This design was very responsive and allowed to make some nice transition effects and other realtime animations when joggling polyforms for example, but would almost immediately raise the CPU usage to 100% or even over on multiple cores, depending on the browser.

I also designed and implemented this cool Hyper Chakana Controller for modifying and interacting with objects on the screen. Here you can see a early design image that I had in mind for GeoKone running in fullscreen:

Early Design Of Fullscreen GeoKone, with the 12 -operation Hyper Chakana Controller

Early Design Of Fullscreen GeoKone, with the 12 -operation Hyper Chakana Controller

The Hyper Chakana Controller is the Compass Looking controller, with 4 actions in each direction, allowing Context Specific Actions to be mapped to each one of these directions, so that if you select a PolyForm, the Chakana would be able to Rotate, Scale, Move etc the polyform based on the Natural Directions the user is touching.

Developing The Chakana Controller, Running at 30 FPS

Developing The Chakana Controller, Running at 30 FPS

The name and design for this was based on the South American Sacred Geometry Cube, The Chakana, which you can see a 2D -version here:

Chakana - It Is Said that all South American Culture, Art, Design is based on the ratios of this design

Chakana – It Is Said that all South American Culture, Art & Design is based on the ratios of this image

I even went so far as to implement this HyperChakana controller, as you can see in this early preview video I made:

But after testing this model for a while, I realized that I cannot run this 30 FPS all the time, as making the CPU fan scream was not an option, so I had to figure out something else.

I looked into WebGL, but since back then it was still experimental (and still is, Safari does not officialy even support it yet, you have to toggle it via the developer options) I decided to stick with Processing.js + basic 2D canvas.

GeoKone eating 98% of CPU

GeoKone eating 98% of CPU

I also decided get rid of the Chakana Controller for now, although I put a lot of work into designing and implementing it. Hopefully I will be able to use this design in upcoming, native versions of GeoKone.NET, as I believe this could be a very natural way to interact with objects on the screen, especially with touch screens.

So I had to find a middle road, not running the logic & drawing at 30 FPS, but still having to be able to animate transitions between polyforms. So I decided to run logic for 50 milliseconds after the user has stopped interacting, and after this call noLoop() to stop Processing.js from calling the main draw() method. This way I could still animate stuff and run logic, and the it wouldn’t take as much CPU as before.

This model worked pretty well, and is the one that is still in use with the current live version (0.97). But it proved to create unnecessary logic for handling the stopping and starting of the loop() and noLoop() methods, creating some pretty ugly state handling code that is just unnecessary.

For the next version of GeoKone.NET 0.98, I have cleaned up the code and got rid of this difficult method of determining when to run the loop and when no to, and just tell Processing.JS not to run the loop at all in the beginning, and to call redraw() manually whenever the user interacts with the polyforms. This seems to be the only acceptable model in which GeoKone is responsive, and does not hog the CPU.

Premature Optimization

Also I had foolishly pre-optimized the code, using precalculated sine and cosine tables for the polyforms, inside the PolyForm class. These were not really even used as any time any parameter of the polyform was changed, the class was re-created completely. So even when the user moved the polyform around, it was re-created, thus re-creating the sine and cosine tables also, and preventing from re-using them. Doh. For the next version I have removed all this kind of “optimizations” and just draw and calculate everything on the fly.

Premature optimization truly creates a lot of problems, as the logic of the program changes during development process so much that the optimizations are not even affecting the program in anyway, but they are making it more difficult to adapt to changes in the architecture.

I actually profiled my code and found out that this creating of these sin/cos tables was causing major slowdown, as I used the new keyword everytime the PolyForm was re-created to create the tables. For debugging I use Firefox and the excellent Firebug extension, and I could see the more I removed any use of new in loops, the more faster the initialization & drawing got. This is kind of obvious, as creating classes in performance critical loops of course takes time to allocate new objects, instead of just changing parameters of existing objects on the fly.

It’s really easy to start optimizing early, and run into problems afterwards. This also bit me in the ass when trying to optimize the drawing so that all the in-active polyforms, that is, those polyforms which are not currently being edited, are being drawn into a separate backbuffer and the active polyforms are drawn to a front buffer, and these are then combined to make up what the user sees on the screen.

Debugging Back Buffer Optimization - Backbuffer on left, frontbuffer on right

Debugging Back Buffer Optimization – Backbuffer on left, frontbuffer on right

This enabled me to draw more complex scenes than before, as I could copy very complex formations into the background buffer, and just move the stuff in front buffer around.

But this created problems with the z-ordering of polyforms, as whenever I would choose polyforms to be modified in the front buffer, these would rise on top of the polyforms in the backbuffer, even though logically they were behind the ones in backbuffer.

This was caused because the backbuffer was drawn in the back, and the frontbuffer always on top of the backbuffer, ignoring completely the z-ordering of the polyforms and changing the way the scene looked when editing and when you disabling Mod All.

I have enabled this Back Buffer/Front Buffer optimization for now at least three times, and yet again I have to disable it as it causes problem with the drawing logic. Better just to stick with implementing the functionality first, and then worry about optimization :) It’s kinda difficult also to let go of these optimizations, as I know that I could be drawing much more faster scenes even with current versions, but there would be some minor drawing bugs which I find unacceptable. Maybe I will find a good way to do it after the program logic is finished.

Next Version

Here are a couple screenshots of the next version in action, I’m not going to write anything more now as I’m really close to releasing this and I have to write those in the release notes anyway :) Major new improvement is the Layer Style Polyform Selector, which you can see on the left side of the screenshots. Also, you can now move the PolyForms up and down in their z-ordering, which makes it more easier to edit your scenes.

Testing the PolyForm Selector

Testing the PolyForm Selector

Testing Irregular sized Scenes with the Selector

Testing Irregular sized Scenes with the Selector

It is easy now to move polyforms higher and lower in the order which they are drawn

It is easy now to move polyforms higher and lower in the order which they are drawn

That’s it for now! Continuing finishing the last tweaks on the next version, and if you want to try it out yourself early, you can check it out at the master-optimization branch from GitHub: