Progress update on my 3D Sacred Geometry Engine

Fully focused

For the past two months I’ve been blessed to focus fully on my 3D Sacred Geometry engine, called PsiTriangle Engine. This engine is going to be the basis for our upcoming 3D Sacred Geometry Creation program, called Geometrify: Creator.

Beginning of the year I was working at Vizor (, for a while, but that lasted only for 2 months as it was not really something I truly loved doing.

But I got to learn ThreeJS (a javascript 3D framework) there and also how to build a 3D engine more, so this gave me good insight on how to continue with my own engine.

Getting closer to the metal

I’ve been now focusing on improving my engine since then, getting more performance out of the GPU and calculating as little as possible on the CPU.

The CPU -> GPU bottleneck is a real issue when working with dynamic geometry, optimally keep everything in the GPU memory and not transfer it from the main RAM to the GPU, as it’s a big bottleneck for performance.

Learning the tricks of GPU programming and getting to really feel the power of the GPU has been a marathon run, but I’m finally approaching the performance I’ve been looking for.

Doing complex things is easy, but just narrowing down to the simple essentials, the least amount of calculations needed, is difficult.

Putting my engineering skills to their use

I’m an automation engineer, and working with 3D equations and math is really an area where I’m starting to see use for that education. The education basis has given me the insight that I can understand and dissect any problem, if I just keep drawing and calculating on paper long enough.

Just draw it out

Just draw it out

I’m pretty happy now that I got that education, as without it I wouldn’t have probably have the system in place to work like this (*thx math teacher, Pirkka Peltola)

Fast line drawing

In the last weeks, I’ve been completely re-writing my line drawing algorithm to utilize the GPU as much as possible.

Previously I had ported an algorithm by Nicolas P. Rougier from Python code to C++ (based on his paper here:

But this case was just too generalistic and did too many calculations, and took a long time to upload the vertexes from the CPU to the GPU, which really killed performance.

So I decided to just rewrite from the ground up. Good tool to prototype graphics drawing is, so I first implemented the algorithm with Processing, then when it worked and I understood the process, started porting it to GLSL shader code.

Tesselating Circular Polylines

Tesselating Circular Polylines with Processing

Getting to know the Geometry Shader

There exists geometry shaders on modern GPUs. With these, one can calculate vertexes completely on the GPU, utilizing the massive parallelism of modern GPUs.

I started my line drawing re-implementation using only the geometry shader. Here you can see results for that:

Here all the lines, segments and origo points for the circles are all calculated on the GPU, nothing is done on the CPU except the origo point sent to the shader.

This is pretty great, but there are limitations. First, the geometry shader has to re-draw all the shapes, calculate all the sines and cosines for each line segment, all the time, everytime, on each frame. This is slow.

Second, the geometry shader can only output a limited amount of vertexes. With my GPU, that limit is 256 vertexes of vector4 components. So it’s not really much, can’t do deep recursion with that.

Bringing in the Transform Buffers

There also exists a thing called ‘Transform Feedback Buffer‘, which basically means you Transform (calculate geometry) and put the results in a Feedback Buffer (store), which you then use to actually draw (read buffer).

These buffers are then only updated when changes occur, and not on beginning of each frame like with purely geometry shaders.

This got me already much better performance:

Much better, but I was still calculating stuff recursively, storing each circular formation as a separate copy of my base class.

This worked well with http://GeoKone.NET, as with software rendering all the data stays in the main memory. But with GPU rendering, we really want to minimize the amount of things calculated.

Drawing as little as possible

At this point, I decided that I know what I want to do achieve, and to get there, I really need all the perfomance I need, to make it as smooth as possible.

To do that, the current model of doing things recursively, ie. where a class instance stores num_points class instances and visits each of them to draw their data, continuing down the path recursively with a parent child model, really didn’t work anymore with the GPU.

With GPUs, what seems to work best is doing things in a linear buffer. We want to have all data in a continuous pattern, so you can just loop through it when calculating and drawing, with minimum amount of branching and changing buffers when doing that.

Basically we just want to blast the data to the shaders, so they can work on it as parallel as possible, because that’s the strength of the GPUs.

I’m still seeking the best way to do this, but with this model I could finally reach dynamic geometry in 3D space with similar performance as with GeoKone.NET. This is my latest update, showcasing dynamic manipulation of 2D plane sacred geometry in 3D space, that will be the basis for Geometrify: Creator.

Getting there  :)

I’m developing this engine on laptop GPUs, my faster Macbook Pro having a Nvidia GT750M 2GB card, and my home computer having an ancient Nvidia GT330M/512MB.

So I really also have to figure out how to make this fast in order to develop, which is a good thing :) But I can’t wait to test this out on modern beasts of GPUs, which are easily 30x faster than the one on my older laptop.

Anyway, development continues, if you are interested in more updates, follow me on Twitter:, I’ll be updating there more frequently.

Now peace out, and bom! ^_^

Notes from the path of creating a 3D geometry engine

Hello, Sakari here, aka inDigiNeous. For the past 2 years I have been building my own 3D engine, from the ground up, using C++11 and modern OpenGL.

In this post I am going through the motivation to build my own 3D engine, technical details about the process and what is driving me to do this work. Work that is ultimately leading to the development of next version of GeoKone (“GeoKone 3D”) and later also to

The desire to see how things work

First some background on why I decided to create my own 3D engine, how I got here and why I ultimately didn’t just use a ready made solution like Unity or Unreal Engine, or any of the other more lightweight engines out there.

My personal goal has always been to understand things deeply, and to see behind things, how they operate on their core levels. I get satisfaction from understanding things thoroughly. I like to take apart stuff, build, re-build and see how the pieces fit together in different ways. This is where I get my kicks from.

To understand, to learn, to see what makes things tick.

My graphics background

When I started developing http://GeoKone.NET, I had some experience in programming graphics, but nothing on a really deep level. I first learned graphics programming back in the 90s in the MS-DOS days, doing some simple Turbo Pascal, assembler and C -based demo effects, but I never released anything or never did anything really cool.

I tinkered during the years with 2D -graphics programming, mostly on the Javascript side of things, so I had some experience with that. But nothing on a really deep level.

During the development of GeoKone I noticed that  many of the visions I wanted to implement, I just couldn’t do with Javascript and the 2D canvas, because of performance reasons and just the limitations of the platform.

Back in 2011 when I started working on GeoKone, and during the couple of years following that, there was no viable option to do hardware graphics processing in the browser, WebGL wasn’t really a viable option, and in a way it still even isn’t, although it is gaining popularity, stability and support now, but it is still limited to new powerful machines to get smooth frame rates and nice support.

So I stuck with Javascript and 2D canvas programming for a while there, and it worked perfectly fine for what GeoKone is .. but I knew I needed more close-to-the-metal programming in order to get the visions out of my head that I wanted to see.

Enter Virtual Reality

In December 2013 when the Oculus Rift DK1 became available to purchase for any developer, I could hear my intuition proclaiming loudly “Order!” “Do it!”.

I still remembered in the early 2000s when my intuition told me, as a engineering student,  “purchase Apple stock” .. and I didn’t, so this time I decided to listen ;)

I ordered the first development kit, and the moment I first tested it, I knew that this is  the environment where Geokone 3D has to be made.

The Oculus Rift DK1 :: Hello Androids

Hello Androids :: Wearing the Oculus DK1

I  decided to dedicate my time then to start learning C++ and OpenGL more and to get something showing with the DK1.

I had already prototyped core parts of GeoKone with C++, Java and even Objective-C, just to test out what would fit best for the case, so I had some code already to work on, but not much.

Development of libgeokone, very early stages, C++ & OpenGL

Development of libgeokone, very early stages, C++ & OpenGL

Back then there was no integrated support in Unity or Unreal Engine like now, so the only way to see something in stereo 3D, was to implement  it using Oculus’s own C/C++ SDK.

Learning 3D basics

And I had no real experience in doing 3D programming, no understanding of how the math and the principles behind it worked. But I just decided, screw this, I’m gonna learn this while I go, and so I began.

Implementing and understanding basic 3D math and translations, projections and such took a while to understand, and matrix operations also still a bit difficult, but the more I program this stuff and really just teach it to myself, the more I start to see this geometry everywhere, how things are built, and understand the math and physics of space and light also while learning it, which is really interesting to notice.

Using a grid to verify 3D functionalities

Using a grid to verify 3D functionalities

Had one experience of walking outside after really grasping the 3D fundamentals and getting code working, I walked outside and could see their vector versions projected on top of the physical objects for a while there, like green matrixes of the physical objects, my mind mapping them out with the rules I just programmed for them. Woah! As Keanu Reeves would say.

Programming the Oculus Rift

It took me 4 months of work to get anything even showing properly with the DK1, mainly due to learning the basics of 3D programming, vectors, matrixes, projections, the whole third dimension and the complexity that comes with it. Luckily, for vector math I could use the great GLM library, which is really nice for working with OpenGL.

I had done simple 3D programming before this, but nothing that I could substantially understand, and this time I wanted to understand each thing I was doing, in order to really grasp what is going on here.

In these months of learning modern C++, OpenGL, GLSL, browsing the Oculus Forums to understand the SDK and just taking in all of this new information, I got to the state where I would get stereo rendering working properly finally, and man, it felt good at that point :)

One of the first stereo rendered scenes I did

One of the first stereo rendered scenes I did

Finally in beginning of May 2014 I had most of my geometry core from GeoKone ported to C++, with very simple GLSL shaders. This meant I could now draw recursive geometry in 3D space, with support for stereo rendering.

This would produce this kind of images:

Early stereo images

Early stereo images

One of the very first scenes for verifying stereo rendering I did

One of the very first scenes for verifying stereo rendering I did

Another stereo image

Another stereo image

Developing the first Demo

I also got the DK1 rendering properly, so I now had this kind of images produced by my program, animated in 60 fps, zooming through the geometry:

Geokone geometry engine rendered in stereo with C++ & OpenGL

Geokone geometry engine rendered in stereo with C++ & OpenGL

I continued from there to develop this demo, tested it with different music, and finally added music from my good friend Miika Kuisma. This lead to the development of the first demo of Geometrify, which we demoed together with Tommi Ullgren, Samuel Aarnio and many others helping us, ultimately us showcasing this potential of sacred geometry in VR at over 20 events and offering probably over a 1000 people their first VR experience ..

But that is a story for another blog post :)

From demo to engine

The first demo I did was just only a technical demo, made in a way that really didn’t support building flexible software around it, so I had to spend a lot of time figuring out how to get a proper framework of C++11 & OpenGL, built in a way that allowed configuration of a 3D world designed to render recursive geometry in a 3D space.

C++11 and OpenGL was chosen in order to support cross platform from the get go. No other language really offers bindings to all the libraries on all major three platforms, Mac Os X, Windows & Linux, and also mobile devices, and with the rock solid performance that this kind of experience would require to be really solid and feel smooth as silk.

Modern C++ practices

Modern C++ practices

I spent lot of time in just learning OpenGL and C++11 best practices. C++11 is a very nice language, but to understand how to use it, you have to wade through maybe 15-20 years of legacy practices in order to find how things are done currently, and how to apply modern techniques.

Implementing beautiful line rendering

One of the key aspects of rendering recursive geometry, is how to get beautiful lines rendered. Turns out this is not as simple as just using a ready made library, as there really doesn’t exist such a thing.

I waded through different methods, read through many papers and found out people have implemented something already, like the VASE -renderer. Ultimately I decided to implement the line rendering method researched and implemented by Nicolas P. Rougier with python, described in his paper here:

Getting this to work I now had lines like this renderer in OpenGL:

Antialiased Polygon Lines

First version of the antialiased polygon lines I implenented

Showing how these lines are tesselated from triangles

Showing how these lines are tesselated from triangles

More recent example of the linerendering

A More recent example of the line rendering method.

Need for a scripting language

One of the really annoying things about C++ is the need to compile the source code all the time even if you just change one number. Trying to implement program logic with this limitation was getting really on my nerves, as usually it took at least 2 – 3 seconds to compile the classes I was working on, and when doing this hundreds of times really takes a toll in the iteration times.

I reached the same conclusion that many others before me have done, and saw that I need to add scripting language support for my engine to really get anywhere in a reasonable time and not loose my mind while doing it.

I prototyped different approaches, first considering using QT5 with it’s built in Google V8 javascript engine, but came to the conclusion that I don’t need such a beast of software just do add scripting.

I also looked at several other scripting options, but really the only other one that can be taken seriously is Lua, so I bit the bullet, learned yet another new language and bound my C++ engine to the Lua -side with the assistance of the great lua-intf interface.

Controlling scenes with Lua

Controlling scenes with Lua

To be able to write programs that have the iteration speed of javascript, combined with the raw power of C++11 and Modern OpenGL, felt super good. Unlimited power!! ;)

Base work almost done

So finally I’ve reached a state of development in my engine, now named PSITriangle Engine™, where I can run program logic in scripts in Lua, and keep the parts requiring performance on the C++ side.

It’s been a long way to this state, to implement a very specific use-case 3D Geometry Engine, using modern C++11 and modern OpenGL + GLSL techniques, all the while learning how to do this while developing the actual engine.

The feeling of getting here, controlling all the pixels on the screen, using the power of math and geometry, and skills I had accumulated over the years to produce this virtual space, felt like pure creation coming into life.

I’m glad I didn’t know how much work implementing a 3D engine properly is, because I might have not chosen that path if I had known :D

Finally  I can just quickly script and prototype ideas quickly. This brings development speeds up significantly and helps test and development massively easier from now.

From now on my plan is to finish this base of the engine and actually start implementing the program logic for what is going to become “GeoKone 3D” as the project name for now! :)

GeoKone.NET Interactive Geometry Projection Installation @ Kosmos Festival 2015

For the last three weeks, I had been working on creating an interactive GeoKone.NET powered geometry installation for Kosmos 2015 Festival. The idea was to create an interactive installation that people could control themselves and synchronize the visuals to the music playing on the Spacetime Stage at the festival.

Designign the controller interface

Designing the controller interface

Google Chrome browser has webmidi -support builtin, so connecting a Korg Kaosspad R3 controller to my laptop and reading midi -signals was pretty easy. Just had to figure out how to have some kind of intelligent and intuitive controls.

The idea was also not to break the geometry or the visuals, because with GeoKone you can pretty easily crash the browser, because exponential growth in processing and memory when increasing the recursion depth or number of points in the scene.

So I had to design some kind of limitations too, so that people could not mess up the beautiful scenes. And really to create new scenes with the controller was too difficult, so I created a bunch of nice scenes people could browse and select one to modify and work from there.

I’m pretty happy how the installation turned out! Here are a couple of videos from the event (Thanks to Suvi Suvereeni for filming and sharing):


People really seemed to enjoy this, as I observed people staying on the controller for long periods of time, some even as long as 30 minutes. Visitors also got the hang of synchronizing the visuals to the music, which was nice to see! :) Here is a quote from a user:

That was awesome! I hope I will get to try that again some time, one of the best moments of this summer for sure!

So! This means that in the future, GeoKone will have MIDI -support! You can plugin any controller and control the scenes with your favorite hardware .. how about that :) Can’t wait to implement this properly.

Also, big thanks to Miika Kuisma and Samuel Aarnio for helping me on site, and for everybody who collaborated on the stage and made this possible.

Until then, now work continues again on Geometrify, which about I will update more info later.

GeoKone.NET Gets Animation Support :: 0.93.30 Released

New version of http://GeoKone.NET is online! Now comes with Animation! ^_^
If you want to see straight away some examples live in GeoKone, load these files into GeoKone via “Scene/Load Local File”:

Hit the Animate button with these and they will start to animate, and you can modify the contents realtime of course.

Animation & Tracing!

Animation & Tracing!

Release Notes

  • Animation support! Support for rotating and scaling the formations based on adjustable parameters. Very cool :) Supports tracing also. No support for exporting animated scenes as images yet, though.
  • Use keyboard commands ‘0’ (Zero) to toggle animation, ‘9’ to toggle rotation, ‘8’ to toggle scaling.
  • Changed checkbox appearance to switches
  • Keyboard command ‘Del/Backspace’ now used to delete formations
  • Page Up/Page Down now select active formation also
  • Print Screen shows Export Image dialog
  • Tighten the UI layout a bit
  • Fixed the Randomizer and added better color presets

Realtime Animation

Animation support! Glad to announce that GeoKone.NET now supports animating the formations in real time. Each formation can be Rotated & Scaled in real time, with parameters for controlling the scaling and rotation. You can use keyboard command ‘0’ to toggle the animation, and commands ‘8’ for toggling Scaling and ‘9’ for Rotation.

Using the Tracing Feature

Using the Tracing Feature

With animation you can also trace the movement, leave trails of the moving formations, while animating, which can lead you to some very pretty images! No support for saving these traced images yet (except of course taking a screen shot).

Creating Vortexes

Creating Vortexes. Change the Line Color while Tracing :)

Also due to couple of users telling me about this, the keyboard command for Delete has been moved to ‘Backspace/Del’. Thanks for the feedback! Hopefully having Undo some day too :D

Very Interesting Shapes can now be found!

Very Interesting Shapes can now be found!

Got my Oculus Rift DevKit last week .. let’s see where this goes with GeoKone in the future ;)

Start Creating Geometry!

Now go to http://www.GeoKone.NET and starting playing around with the Animation! Try out different scale frequencies, rotation speeds (also negative!) and see what kind of worlds you can find!

GeoKone.NET Updated :: Much Faster, More Responsive, New Features

New version of http://GeoKone.NET is online! This version is a big one, completely rewritten, not anymore using the Processing.JS library, but instead only Javascript/Canvas techniques, which means it’s much faster and more responsive overall. Took a while to convert the existing Processing.js java -like parsed code to pure Javascript, but definitely worth it. Procesing.js is good for simple visualizations and prototyping stuff, but for production and achieving better performance it’s a no go.

GeoKone.NET 0.99 In Action

GeoKone.NET 0.99 In Action

Release Notes

  • Completely rewritten everything using only javascript+canvas drawing operations. Much faster, lighter and loads faster!
  • Update Dojo (used for the HTML UI) from 1.6 to 1.9.
  • Only active formations are re-drawn when modifying formations. This is a big drawing optimization and allows you to create much more complex scenes without having to re-draw all the formations all the time. Achieved with using multiple canvas elements on the page, and sorting formations based on their z-index, so that the active formations are always in the middle canvas, while the background and foreground stay unmodified. This means huge improvements in usage and drawing speeds, especially with more complex scenes :)
  • Now uses HTML5 Blob for saving images in browsers that support this. Much faster and better method for exporting PNG images, doesn’t seem to crash the browser anymore. The browsers that do not support this (Safari 5 notably) will fall back to base64 URI encoded saving.
  • Read and Save local files. You can now drag and drop local scene files to GeoKone and they will load using the HTML5 FileReader interface. Fallback for importing JSON still exist for browsers that do not support FileReader (Safari 5 again)
  • Better formation container, shows transition effects when you add formations or remove them, and feedback for when joggling polyforms with j/k.
  • Compressed all the javascript source files into one file, optimizing the loading time
  • Small tweaks and bug fixes all around. So much changes and refactoring the code.

As always, for full details, see the ChangeLog.

Approaching The Vision

This is a big release, as it the .NET version is getting so much closer to actually reaching the 1.0 version that I have in my plans and visions. My plan is to complete the .NET version and then leverage the drawing engine/loading engine of the .NET version for other Web -related sites / visualizations also, and this is why I have chosen to continue on developing the HTML5 -version instead of moving to native code.

I am pretty confident that I will be able to get the performance and features out of Javascript/Canvas/HTML5 that is required to complete this task. I would also like to see people sharing their creations with others and remixing content.

One big thing I want to add is also more features, like Spiral -formations based on the e^ or log/lin functions, hopefully adding more variability in the formations you can make.

Figuring out a way to continue working on GeoKone.NET

I also have plans for GeoKone Pro, like exporting Vector Images or other features targeted at artists and those who want to use their work in other media, like printing or image manipulation. This will mean some kind of subscription service, but I assure the standard version of GeoKone.NET will be always free, only the Pro features will have the subscription fee.

I am a lone developer, working alone on GeoKone.NET. Luckily though I have support on the marketing and idea side from Jennifer @ Stralim Technologies (check her site out if you are in Colorado and looking for a great web designer!), but mostly I am figuring this thing out by myself and trying to see what I am actually creating and how I could continue on working this without having to sacrifice too much of my own work and also getting energy back in exchange to continue developing this forwards.

I am setting up a donation feature also for the upcoming releases, so this will also hopefully generate some funds to run the servers and enable people continue enjoying GeoKone.NET :) I am really paying currently for the servers myself also, and even though I would like to make this thing completely free, I have to figure out a way to fully continue developing GeoKone without having to work too much on other projects.

Try it out! In Your Browser!

Now go to http://GeoKone.NET and start Expressing Geometry!

GeoKone.NET 0.98.03 Released

New Version 0.98.03 Beta is Online

GeoKone.NET 0.98.03 Beta has Been Released today.

This is a maintenance release, containing couple of bug fixes and new larger default scene size if the browser window is big enough. Also, the Scene Dimensions now has pre-sets for 4:3, 16:9 and 16:10 sets. Enjoy :) For more details, see ChangeLog.

Circuitry Of Gods :: Created with GeoKone.NET

Circuitry Of Gods :: Created with GeoKone.NET


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: