Jaanga oSome Globe ~ Full 3D + 18 zoom levels ~ Cookbook Demo Code

For a lot of the time since the Urdacha debacle in April, I have been working with 3D globe models of the earth for the FGx project. These have for the most part been based on the Three.js globe in Chrome Experiments.

This globe has a kind of usefulness in terms of simple DataViz. I think it can be thought of as the 3D equivalent of the pie chart. Great for beginners.

But for almost any other use, the globe code is quite limited.

So I began to think of the globe I would like to have.

The features should include:

• Ability to access all sorts of open source and publicly available data from, say, Open Street Map, MapQuest and Google Maps
• All runs in your browser in a just a few hundred lines of code
• Fully 3D with easy to add and remove 3D assets at runtime
• Eighteen levels of zoom like OSM and Google Maps
• Basic 3D topology for the entire globe
• Full 3D camera controls
• User interface overlay built with a standard library such as jQuery

I'm sure there's more, but in a nutshell I want a simplified Google Map and a Google Earth that I can create and edit using tools made for dummies.

So far I think it's all doable. The link below will take you to Jaanga oSome Globe r2 on GitHub which supports 18 levels of zoom. I am working on r3 and the work on 3D topology is underway.

Link
http://jaanga.github.io/cookbook/osome-globe/r2

Three.js and jQuery: Never the Twain Need Meet

The phrase "never the twain shall meet" was used by Rudyard Kipling, in his Barrack-room ballads, 1892:

"Oh, East is East, and West is West, and never the twain shall meet."

I use this as my lesson-learned from playing with Three.js and jQuery. In this post I will suggest keeping the two different libraries in quite separate places and writing in two styles.

And, actually, I am quite wrong. Jerome Etienne at learningthreejs.com is doing an amazing job of building a combined dialect which he has named tQuery. And for proof, just look at the hugely complex structures that Steve Wittens is building using tQuery.

But now let us consider the wrong way.

Three.js says it is 'a lightweight 3D library with a very low level of complexity — in other words, for dummies.'

jQuery says it 'makes things like HTML document traversal and manipulation, event handling, animation, and Ajax much simpler'.

Guess what? What is easy 4 1 is not necessarily easy 4 2 let alone 4 U.

The two libraries appear to come from two different planets.

• Three.js is JavaScript kindergarten coding. If you can do IF's and FORs you can do THREE.JS
• jQuery is a JavaScript takeout menu. If you can order two from Column A and three from Column 4 and you are good to go on jQuery.

Which library is from Mars and which one is from Venus? Who knows?

Anyway, the thing is that both are libraries are extremely popular in their niches. And it is highly likely that people (like me for example) want to combine the user experience of jQuery with the 3D of Three.js.

The question is: can one easily combine the two styles?

The normal thing is to say, I am writing a program. My program should have a style and to make life easier for the maintainer, my program should have a consistent style throughout.

So then which style should you follow? Mr Doob's or John Ressig's?

Each giant is so huge that this midget can't seem to stand on both their shoulders at the same time.

And yet we need to write apps that are 3D and have calendars, that are animated but can show text in an accordion. What can small people do?

So here is another quote, this time from Saint Augustine:

Cum Romanum venio, ieiuno Sabbato; cum hic sum, non ieiuno: sic etiam tu, ad quam forte ecclesiam veneris, eius morem serva, si cuiquam non vis esse scandalum nec quemquam tibi.

Basically this Latin translates as: "When in Rome do as the Romans do."

The links to the cookbook samples will allow you to be completely schizophrenic while maintaining total sanity throughout while playing with both libraries together

Here are some guidelines.

We like Google, Bling, Alpha. The more words we show in straight HTML the more they will like us.

JavaScript and torus knots are not really SEO-able.

So keep let's keep two separate files. The HTML and jQuery goes in the main HTML file. The Three.js goes into its own file called in by an IFRAME into the main page. In the main file, you write in jQuery style. In the iframe, you write in Three.js style.

So the final page is built from two completely different files. And both pages - if well-written - should display all by themselves.

But 'Wait, wait!" you say. "The jQuery and the Three.js need to communicate."

Here is the secret sauce.

Both libraries will accept communication from the other if you wash your hands that communication is sanitized.

When Three.js needs something from upstairs, it just prefixes the jQuery variable name with 'parent.$.'

When jQuery need something from downstairs it prefixes the Three.js variable name in this sort of manner:

$("#ifr")[0].contentWindow.scene.children[0].material.wireframeLinewidth.toFixed(1)

The magic word is '.contentWindow.'

Both of these 'handshakes' work with getting and setting in the alternative environment.

So what are you waiting for?

Welcome to my happy, easy jQThreery schizophrenia!

Link:
http://jaanga.github.io/cookbook/j3qUE/r1/

FGx Globe r3 ~ FlightGear Planes Now In the Sky

One of my several projects over the last few weeks has been the development of a flight simulator visualizer.  You may well ask what is a 'flight simulator visualizer'?

FlightGear is a popular FOSS flight simulator program. Players like to share their in-the-air status online. A JSON feed for this data is available from FGX's Crossfeed. Their current visualizer for this flight simulator data looks like this. I thought is might be fun to wrap the data around a globe.

I have just started rev 3 of my FGx Globe. Here's is what I just wrote about the new rev:

This revision begins to feel as if its getting somewhere. The code is simpler, shorter and does more than before. In particular there is much better separation between the user interface and the 3D world. The user interface is now built using jQuery UI while the 3D all resides in a separate file embedded in an iframe. 

The user interface now provides a table that displays all the flights currently underway. For each flight there is a clickable button that opens a separate window. Multiple windows may be opened - each of which displays the current position and navigation data for a single plane. You may select from a variety of map data sources. The user interface is theme-able with all the standard 20+ jQuery UI themes available at the click of a button. All significant settings are savable as 'permalinks'. 

On the 3D side, the data-handling procedures have been re-written in a much more simple and more straightforward fashion. Also, there first steps have been taken introduce more realistic planes. 

There is still much unfinished work in this build. In particular the only way to remove terminated flights id to reload the window and the only way to completely delete a window is to reset the permalink. And there are several issues with the drop-down lists. Please note that all building and testing has been on Google Chrome. Other browsers will have issues. Other issues are listed in the TBD panel of the main menu.

So the new thing here is that I am using jQuery. I have gone over to the dark side. I have drunk the Kool-Aid.   I say this because, for the most part I code in a very simple and spare style.

The Three.js site says this about the code:

The aim of the project is to create a lightweight 3D library with a very low level of complexity — in other words, for dummies. 

Well, I have tried to match that style. In some ways this is because I resemble the categorization and in other ways because the style is simple and pure. But perhaps the most telling reason is because I am not a programmer.  I actually don't try to write code or build a program. I am a designer. What I am trying to design is a brain visualization thingy or a stock market snooper or whatever.

I could do this using pencil and paper or clay or some such traditional media. But I just happen to like to use JavaScript as my design media.

I plan to write more about coding while being a designer, but suffice it to say that much of my work sticks to "for", "if" and "=" along with parentheses, commas and semi-colons.

So the move into adding jQuery to my repertoire is a big one for me.  I think I will most likely become schizophrenic: Writing in Three.js style on some days and jQuery style on other days.

But not to worry, on both types of days my brain will very likely be placed squarely in the middle of the Three.js target market.