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/

First-ever high-resolution images of a molecule as it breaks and reforms chemical bonds

I find these first images of molecular bonding to be very exciting.

You may find this curious, as this is meant to be a data visualization site where reality is modeled but rarely shown for itself.

Look at the image. It shows a single molecule displayed from an orthogonal point of view - and nothing is moving.

What will multiple molecules moving and interacting in 3D look like? For the foreseeable future, my guess is that such complex stuff will have to be modeled rather than photographed.

http://phys.org/news/2013-05-first-ever-high-resolution-images-molecule-reforms.html

We have work to do...

The First Image Ever of a Hydrogen Atom's Orbital Structure

Here is an image of some very small events.

http://io9.com/the-first-image-ever-of-a-hydrogen-atoms-orbital-struc-509684901

Eventually we will be able to generate algorithmically generated 3D animated depictions of such events - directly from the actual physics equations.

This in turn will enable us to consider what happens when multiple hydrogen atoms interact.

As well as visualizing what is happening at an even smaller scale.

Old 2.0: How Old becomes the New New

The San Francisco WebGL Developers Meetup held on 15 May at CBS Interactive was in many ways even more mind-boggling than our normal meetup.

The usual type of things we see at the meetup is some sort of visualization that we have all seen before. The only difference is that we last saw the thing in a mega movie such as Minority Report or on a $75 game DVD running on a computer with dual GPUs. And now we are seeing it in a browser, for free, no plugin necessary. It's so much deja view all over again that we can hardly Yogi Berra it.  It's huge and we think its normal.

Things are moving so fast and yet it feels like we are standing still. Is there a reason for this?  The present and the future are fast moving, but we actually live slowly in the present and present. Is it because we live in our own legacy?

And that was the fun fact of this WebGL meetup. Every demo was trying to speed up the past, to bring our legacy up to modern capability, to make the past go faster miles an hour.

Let me count the ways.

First up: Tony Parisi - along with Remi Arnaud and Fabrice Robinet - showed off glFT. What does glFT do? It's like a hose that sucks 3D models out of people's hard disks and gets them up into the cloud. If we are going to move from Computer Aided Design to Internet Aided Design then we have to get the last twenty years of design data online - quickly, easily and cheaply - without coders always having to rescue stuff. And Tony gave us a presentation of an open-source and probable industry-standard method for doing so - truly a free glFT.

After Tony, up came Aleksandar (Aki) Rodic who showed a 3D editor built using Three.js and connected to the cloud via Google Drive. I logged in to the online demo while Aki talked and happily added an icosahedron and scaled torus knots while he demoed. So what was the old bit here? The editor did not have much power. Apart from the amazing collaboration ability - it was more like AutoCAD 2.18 from 1983 than an editor of 2013. But that's not the point - and I will come back to Aki's demo at the end of this post.

Then came Iker Zugaza from Ludei. OMG. Now we are not just talking old. We are talking archeology. Iker showed us the Ludei game system running on old Blackberry tablets, early Kindles and even an iPad 1.  Each of these ancient devices displayed 3D graphics with webGL-like speed even if the device did not support WebGL.

More than that: you can use your wacky Android dev tool or Objection-C or whatever. Just get your stuff to run in a browser, send the blob to Ludei and they will send you back the code for just about any platform out there - living or dead. For free (well until you get enough users).

Finally there was Robin Willis from sunglass.io.  Think GitHub for designers. Use the tools you like to use. SketchUp. Inventor SolidWorks or whatever, and then easily and quickly obtain a representation that can be shared, and viewed and commented (and blamed) by the whole design team online. Your project is no longer stuck on a hard disk in some office but is available to the world.

So all of the demos gave the old legacy data and devices a kick in the pants and said "back to the future with you!" All very cool.

But the demo I keep thinking about is Aki Rodic's collaborative 3D edit demo.

And I think I am beginning to understand why.

When we think of the past we think of all that data from 3D Max, Maya, ProE, SolidWorks, Rhino and whatever. trillions of point and faces.

But the future is not about data, it's about code.  You don't send monster data down the interpipes, you send the code for building and animating monsters. Architects don't send you buildings, they send you the instructions for creating the building. Your DNA does not contain a miniature you, it only holds the the code for re-creating you.

Three.js is not a tool for building CAD models, it's a library of WebGL tools. It's the equivalent of DNA. What Aki is sending around is just the instructions on how to use the DNA. He's transferring the Internet equivalent of RNA. I think the future of 3D on the web will be based on techniques that move code as much as data. It's a fast and proven idea.

Speaking of fast and proven, hats off to Tony Parisi for yet again showing that he 'gets' what happening in 3D and 'puts' on a great event.