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
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
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
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
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
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 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
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.
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
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.
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 Irregular sized Scenes with the Selector
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: https://github.com/inDigiNeous/GeoKone/tree/master-optimization.
New version of GeoKone.NET is now Live! Read more for Release Notes.
GeoKone Can Now Create Transparent Formations
I don’t normally announce .0x versions, but this release deserves one, as it brings a new polyform parameter that allows completely new visions to be created: Opacity. It is now possible to set the opacity for all the polyforms, allowing see-through formations. This is exciting, as GeoKone now can create even gradient forms and much more smoother and interesting colors from interaction of different colors on top of each other.
Radiating See Through Formations
Opacity can be set for each individual Polyform, 0 is totally clear and 255 fully opaque. All previous scenes will have their opacities set to 255. Unfortunately transparent drawing is slower than opaque forms, so with complex scenes it can get pretty slow if there is high amount of transparency. More motivation to start working on that native version :)
The keyboard shortcuts ‘f’ and ‘v’ can be used to increase/decrease opacity!
Opacity Setting Brings Totally New Looks
In order to hopefully prevent crashing with Safari and Chrome, High Resolution images are now only exported as 2x the scene size. I hope this is enough for most people, maybe I will bring back arbitary high resolution image exporting in upcoming versions, but for now browsers can’t just handle so much data within a javascript/processing image export context, so this might be something that will only appear in the native version also.
Seems like Safari and Chrome still crash a lot when the scene is complex, this is probably something to do with the URL getting so long that these browsers can’t handle it. Firefox seems to be (at least on Mac Os X) the only browser that can handle large amounts of URL data images without crashing.
Undo has also been disabled for now, as it didn’t work reliably enough and only slowed down performance.
Replicating Triangles In Space
See the full ChangeLog and updated TODO for a Roadmap of What’s Coming Up with upcoming versions of GeoKone.
That’s it! Go to http://GeoKone.NET to Create Geometry! Be sure to like GeoKone Facebook Page too if you Like GeoKone :)
New Version of http://GeoKone.NET is Live!
GeoKone is now Much Snappier! Optimized the code so that after idle time the screen is no longer updated constantly, only when the parameters of the polyforms change. This makes the UI much snappier to use and makes GeoKone much more responsive, and uses far less CPU, resulting in the browser not getting all unresponsive during usage.
EDIT: Ok, update.. I tested this on my other machine (Mac Mini 2.0GHz, 2GB RAM) and it ran GeoKone slow like molasses with Chrome. With Safari it was usable, but not nearly as fast as on my main laptop. Oh how fun it is to program the HTML5 canvas! :I Back to the drawing board .. I will anyway have to figure out the core version of what will be GeoKone.NET 1.0, skim down everything else, make these features working and then focus on the desktop C++/OpenGL version, I feel I’ve had it with this web programming and all it’s little gimmicks that it requires to get it working smoothly.
Made With GeoKone
Thumbnail feature was removed for this release, as I’m trying to figure out what are the most essential features for the web version to have, and the thumbnail was eating down performance. Maybe I will enable it back in the WebGL version.
Otherwise, work continues on the OpenGL/C++ version of libgeokone, a library for rendering GeoKone scenes with native performance and OpenGL for smooth animation and display of GeoKone scenes. When the libgeokone part is finished I will integrate the OpenGL drawing code into WebGL version, bringing _much_ faster drawing and hopefully even animation of the GeoKone Scenes.
Also thinking about moving the GeoKone hosted on Amazon so I could finally enable the server functionality again, but that will have to wait until next version.
GeoKone.NET has been Updated To Version 0.96.03 Beta.
GeoKone is an Interactive Sacred Geometry Generator that runs in your browser. With GeoKone you can Generate, Copy, Modify different Recursive Geometrical Formations that are based on Natural Constants like the Golden Ratio. All parameters of the geometry are assignable by the user. You can save your creations either as PNG Images or Export as JSON/Text Parameter Data, suitable to be Imported into GeoKone and edited later. GeoKone uses Processing.JS.
Visit http://GeoKone.NET to check it out Live In Your Browser! Visit also the GeoKone Gallery to see Unique Art made possible by GeoKone.
This update brings Improved Usability, More Stability and New Features:
Undo: Last 3 Steps Are Undoable.
Copy Formation along vertex points of currently selected Formation:
Exporting & Importing Scenes as JSON/Text
GeoKone 0.96 Screenshot!
Improved Usability
More Stylished Looks
Shortcut Buttons
Keyboard Shortcut Map
Keyboard Shortcuts!
Note: Login, Saving & Loading Scenes to the server is still disabled, as the combination of Python+Django+mod_wsgi+Apache seems to be a bit challenging setup to push live. I am seriously considering rewriting the whole server side with Node.JS, but this will take some time. Hopefully I will get the current server implementation working in the upcoming days.
And as with previous releases, GeoKone is still in Beta, so everything doesn’t always work as expected.
Also, I decided to postpone the Chakana HyperController feature into an OpenGL version of GeoKone, as it’s usability is not yet up to the standards I want and Javascript/HTML5 performance is still an issue, not really possible to run 30 FPS without OpenGL.
Happy Geometry Forming with GeoKone!
Visit http://GeoKone.NET Now! :)
Hello guys & girls, I put together a very short video of me showing one main feature of the new user interface in GeoKone, The HyperChakana controller, that is designed for easy usage with touch screens, check out a quick preview here:
I decided to test out if by simply recording my screen (as I don’t have any video capture software yet) with my camera, and turned out I liked the end result, so I put together this little piece. Working hard on the new version, 15 days to go, going for a public 11.11.11 release :) That’s going to be one powerful day anyway.
Thanks for all the people who have showed interest and became testers, I will put the new version hopefully soon into betatesting, still have to complete a couple of critical features for it to be more usable. But it’s already much faster and easier to use than the current beta version.
During this project I have really realized that usability is hard to get right, it sounds easy on a theoretical level, you tap here, this happens, you hover here, this highlights etc .. but actually implementing the logic is much more harder than it sounds, because there are a lot of things to take into account when trying to translate these rules into binary logic, especially if we want to write understandable, expandable code that takes into accounts different situations and concurrencies that are happening all the time.
Today I was optimizing the drawing to enable more complex scenes to be edited with usable speed, something that I had been waiting for a while to do. I have noticed that anything complex that I want to understand, I have to draw it down and see how it works, like today I drew this:
Optimizing Drawing
Basically, for everything that needs to happen on the screen, I have some kind of drawings/plans done. I have noticed this is the optimal way for me to implement these things, or the only way actually. I need to visualize what happens in order to understand it. Writing it down many times just doesn’t cut it, as it’s so much harder to conceptualize blocks of text instead of looking at a picture.
Maybe I will post some of those images later, just for fun. My design goals are to keep it simple and take the human into account when designing user interfaces. I have noticed that it’s a step-by-step recursive task, there are no easy roads to implementing perfect interfaces, as the rules change depending on the context. There is no one wonder interface that works everywhere (or is there .. that would be another story for another time ;)).
Here are a couple of screenshots also from different stages of development, just to see how it has come along:
First version of the chakana controller, only four directions.
NanNanNan! The program is clearly messing with my head, yelling at me, looking at me .. This is the HyperChakana controller, 4 x 3 operations, 12 total operations.
Optimizing the drawing, implementing a simple backbuffer system.
Suprise visitor, Buddha on a lake. This image came when I started testing the thumbnail view .. good sign :)
Testing out the new doublebuffer code, much more smooth experience in editing complex formations.
That’s it for now. Hope you enjoy this stuff once it’s released, I’ve been very excited in putting this project together :)
I’ve been working on a Sacred Geometry / Mandala Generator for a while now. The core functionality is implemented with Processing.JS + HTML 5 Canvas, with user interface implemented as HTML elements. Here are some images I’ve generated so far with it (click for full resolution):
Here’s a screenshot from the current version:
Mandala Generator Screenshot
These all have been created within a browser page. I still have to tweak the user interface a bit, add a couple of features and fix some bugs to release it online and let others play around with it :)
When I started using Processing.js, the first thing I did I included all my classes and sources into one big .pjs file. Doing this works fine for smaller projects, but when the project grows and you start introducing multiple classes, it all gets pretty un-manageable pretty soon.
Good thing it’s really easy to split the sources into multiple files, all you need to do is include them in your HTML file in your canvas element with the tag data-processing-sources like this:
<canvas id=”geometry” data-processing-sources=”ClassFile1.pjs ClassFile2.pjs main.pjs” width=”800″ height=”800″ />
With the current version of Processing, it will automatically detect all canvases which have the data-processing-sources defined and run setup() and draw() functions automatically.
