GeoKone.NET 0.99.05 Released :: Scene Zooming & Sharing

http://GeoKone.NET has been updated! Now with support for Scene Zooming!

Abstract Art :: GeoKone can be used to create more Abstract Art too!

DigiTotemical :: GeoKone can be used to create more Abstract Art too!

Actually there have been a couple of releases since the last blog post here, so I will post here the major changes between those:

Release Notes

  • Scene Sharing You can now share your scenes to others with the “Scene/Share Scene” functionality. Eg:
  • Maximum Workspace, The “Scene/Maximum Workspace” option will maximize workspace and set GeoKone to fullscreen (keyboard shortcuts not working with Safari in fullscreen :( )
  • Paramater Sliders, for many of the Formation Parameters, the values are now set with horizontal sliders. This makes it easier to see visually and to adjust with mouse/touch input values.
  • Scene Zooming, you can now Zoom in and out of the scene with the toolbar magnifier glass icon. This opens up a whole new world of possibilities and makes GeoKone more intuive and fun to use. Use the keyboard shortcut ‘4’ for easy access. The keys 1-4 can be used for easy access to mouse operations.
  • Changed Keyboard shortcuts: Removed Stroke Weight to free up keys, also Child Number Of Points moved to 6/7 and Fixed Number Of Childs Points to Y/U.
  • Multiple Formations Copied in correct order, a stupid bug that was there for a couple of releases, if you had multiple formations selected with Mod All and copied them, they were copied in the reverse order, resulting in incorrect arrangement. Now it works properly.

For full list of changes, see the ChangeLog.

Development Progress

Haven’t updated this site for a long time, because I’ve been busy working on what is going to be the next version of GeoKone, but something completely different .. let me just say that meditative, sound and Oculus Rift are the focus for the software I am now working on .. It will be something totally mindblowing :)

Good things are happening, I’ve been demoing a tech demo of this to a handful of people and all of them have been impressed by the results, we are now in the process of looking for a team of people to take this thing forwards. More on this as we get more concrete results, at this point I don’t want to spill too much as the software is still finding it’s shape, but I can say we are aiming for the release of Oculus Rift consumer version. Hopefully will make it!

Create Geometry! Have Fun!

Now go to http://www.GeoKone.NET and start playing around with Recursive Geometry!


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:

GeoKone 0.97.05 Out – New Line Join Mode Parameter

Hey All, just released a minor update of GeoKone.NET. This release adds support for the Line Join parameter, allowing you to create rounded, beveled or square line joins:

Rounded David Star With Shadows

Rounded Line Join David Star With Shadows

Here we can see what effect the rounded mode has, the line joins are rounded to create a more smooth look. This is actually just direct support for the Processing.js strokeJoin parameter, you can see here how the different modes affect line drawing. The shadow in the scene is created by copying all the formations, setting their color and stroke to black, offsetting the y by a nice amount and then adjusting the opacity to a smaller value, creating a shadow like effect behind the actual formation.

Also, Calculation of Stroke Weights Has Been Fixed in this release. Unfortunately, there was a bug in all version from up to 0.96 how the Stroke Weight values based on the Stroke Weight Ratio was calculated, I had typed a + instead of a * in the formula that counts what the stroke weight should be in relation to the line weight, and with the previous versions the stroke weight was just being added to the line weight, which is not what I originally intended. Now the strokeWeight is actually directly in relation to the lineweight, eg. if we have a lineWeight of 1.0, and stroke ratio of 2.0, the strokeWeight will be twice as thick as the lineWeight.

Another Variation With Rounded Lines - The Shadows Add Nice Depth Also! :)

Another Variation With Rounded Lines – The Shadows Add Nice Depth Also! :)

So this formula has now been fixed, But Unfortunately All Previous Scenes That Are Not Saved In The GeoKone Server, that use the Stroke value will show incorrect, and you will have to fix the stroke weights manually. I have fixed the values for those scenes that were saved to the GeoKone.NET server, so no worries about those.

Also, the Scene Server was down for a while, while I was looking for a new place to host the server, wasn’t really a good option to run the server at home. But now it has found a new home, and I hope to actually keep it running there so I can implement the social features I have been planning for GeoKone.NET.

Translucent Life - More Subtle Effect with Strokes, Round Lines and Opacity

Translucent Life – More Subtle Effect with Strokes, Round Lines and Opacity

Ok, now have fun with GeoKone.NET and Create Some Geometry! :)

GeoKone 0.96 Beta Released! Create Sacred Geometry Live!

GeoKone.NET has been Updated To Version 0.96.03 Beta.

What is GeoKone ?

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.

  • Keyboard shortcut: ‘v’
  • Very basic functionality for now, still need to tweak and optimize

Copy Formation along vertex points of currently selected Formation:

  • Keyboard shortcut ‘.’ (dot)
  • This allows you to copy the currently selected Polyform and place it along the outer points of the current polyform, allowing much easier copying of formations and creation of totally new formations.

Exporting & Importing Scenes as JSON/Text

  • Copy & Paste the current Scene as Textual Data. This allows you to save your scenes locally to your computer and Import later to continue editing.
  • Importing & Exporting currently works by you Copying and Pasting the scene text into/from GeoKone.
  • Expect more improvements on this in upcoming versions. In the future it will be possible to Integrate these GeoKone scenes into other programs, through a small library that will draw GeoKone scenes with OpenGL! :) This could bring a whole new world of possibilities.
GeoKone 0.96 Screenshot!

GeoKone 0.96 Screenshot!

Improved Usability

  • Copying, Joggling and moving Formations around works now better and is more accurate.
  • Performance might be a bit slower though, but I will continue optimizing the code and release more often.

More Stylished Looks

  • More polished look for the parameter page (although the new Safari has some issues drawing this, seems to affect Mac Os X Lion version only)

Shortcut Buttons

  • Shortcut buttons for most used features, currently: Randomize, Save Image, Export Scene

Keyboard Shortcut Map

  • Help/Keyboard Shortcuts:  See more easily what different keyboard buttons do!
Keyboard Shortcuts!

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! :)

HTML 5 Sacred Geometry Generator with Sample Images

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

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 :)