NASA Liquid Galaxy via Plug In

[Stuart Engelhardt]

Our latest incarnation for a few projects with Engineering and Facility Operations Directorates at NASA's Johnson Space Center.  Using the JavaScript Plug In, we have 10 viewports across 5 displays and computers.

Top Left: Close Up of NASA Johnson Space Center - back half of the campus - a general 3 screen Liquid Galaxy with flight controls set to the middle.

Bottom Left: Orbital View of continental United States with weather input overlays blended together over the Gulf of Mexico + Caribbean.

Top Right: Close Up of NASA JSC main campus (front) with our SiteView server feeding KML streams of incident data from security and facility operations personnel.

Bottom Right: NASA JSC "Mall" - core campus with buildings viewed in Energy Efficiency modes for facility operations real-time efficiency assessments.

Not that all this stuff would normally go together, just a variety of things we wanted to test splitting windows, transferring control from one master to another, multiple groups defined, dynamically changing a slave to a master and vice versa, and incorporating lots of supplemental data into the Google Earth environment.

Also - not seen, but because these are all on Windows, we are able to "pilot" the master with a wireless Xbox controller.  We've tried Space Navigator, Leap Motion, and Xbox, and while we have preferred the Space Navigator in the past, the wireless flexibility of the Xbox controller is quickly winning over for convenience - plus it separates out rotational and translational controls more similarly to the robotics controllers we train on for space station activities.

[Stuart Engelhardt]

I meant to mention, special thanks to Matthew Hall, our lead developer on our custom Liquid Galaxy apps / implementations at JSC.

[Andrew Leahy]

Hi Stuart, fantastic looking 'situational awareness' setup.

For those different sets of Earth "views" (4 in that picture) what are you using to sync and offset the camera within each set? eg. is it Earth API/webSockets or are you mucking about with viewsync or something entirely different?

Cheers,  Andrew | eResearch | UWS

--
You received this message because you are subscribed to the Google Groups "liquid-galaxy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to liquid-galax...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Matthew Hall]

I'm using Earth API and websockets. At the time, the websocket server was just a simple relay, but I've been adding to it in order to do things like dynamic master, remembering what data layers the user turned on, filtering messages, animation sync, and possibly the view translation since C# is faster than Javascript. Each view then loads up with a instance ID. Any updates it sends always have his ID and any update with a different ID is ignored. There's been downsides to moving to the plugin, like losing the space navigator, inability to fly into models, and occasionally the buildings from GE servers look melted and distorted. The space navigator we could have built an app to pull device status and forward through the websockets, but using Chrome's Gamepad API with an Xbox 360 controller was easier. The interior portion can also be worked around by using something like Unity3D which is better anyway since Google Earth does not like high poly models. Slows down a lot. The upsides of moving to plugin? You gain so much flexibility and synchronizing data across machines is so much easier when you can ignore KML and NetworkLinks.

[Andrew Leahy]

Hi Matthew, nice work.

Is the camera offset being calculated in the client JavaScript or in the C at the moment?

I have JS view offset code I can share.

We're also playing with gamepad api for Earth. Using an Xbox and racing car wheel controller! Also thinking of wrapping the spacenav with web sockets. BTW mac osx supports spacenav with gamepad api. But our rigs are windows mainly.

As soon as Earth stops being a plugin and becomes a first class web citizen should be able to do neat 3d canvas overlays on top of Earth.

Stuart, do you still have university student projects? Maybe we could collaborate?

Andrew

On Sep 25, 2013 1:45 AM, "Matthew Hall" <mdh...@gmail.com> wrote:

I'm using Earth API and websockets. At the time, the websocket server was just a simple relay, but I've been adding to it in order to do things like dynamic master, remembering what data layers the user turned on, filtering messages, animation sync, and possibly the view translation since C# is faster than Javascript. Each view then loads up with a instance ID. Any updates it sends always have his ID and any update with a different ID is ignored. There's been downsides to moving to the plugin, like losing the space navigator, inability to fly into models, and occasionally the buildings from GE servers look melted and distorted. The space navigator we could have built an app to pull device status and forward through the websockets, but using Chrome's Gamepad API with an Xbox 360 controller was easier. The interior portion can also be worked around by using something like Unity3D which is better anyway since Google Earth does not like high poly models. Slows down a lot. The upsides of moving to plugin? You gain so much flexibility and synchronizing data across machines is so much easier when you can ignore KML and NetworkLinks.

[Matthew Hall]

When I started, I did the offsets in Javascript. Was easier to debug, change, and see changes instantly without recompiles. Just refresh the browser. I ported the code into the C# part just to see if it would be better, though I am not certain since the C# will have to do N calculations where N is number of clients whereas the N clients only need to do 1 calculation. I may later try a distributed web socket system where each machine has a server running that receives on a multicast/broadcast between each other then uses websockets to communicate with the browser.

On Monday, September 23, 2013 12:10:25 PM UTC-5, Stuart Engelhardt wrote: