More Analysis of GE Plugin

Turns out, the API is extremely expansive, letting you control most functions of the app. And while that gives you many options for how to build your own web-based mashup of GE plus, what it also theoretically does is let you embed GE into other PC apps, e.g., games.

Here’s the thing — a plugin is just a DLL. There are some clever ways it can detect where it’s running (the API key for one). But I imagine you could now write a compiled application that simply pretended to be a browser, or you could embed the built-in IE Browser widget in a .Net Forms app. Calling the Google API functions via COM would make it simple to control, not via Javascript in this case, but actual compiled C++ if you wished.

You could load your 3D objects via Collada/KML, make them move via the API, and even see them interact with each other, if you maintain game state in your own code. But beyond that, it gets a little tricky. The cute Milk Truck example has my truck disappear or flicker when I jump high enough — this is most likely due to a near clipping plane being set without considering the dynamic object so close to the viewer. Expect lots of those sorts of issues to work around, as best you can.

But the one 3D mashup people may really clamor for is famed Second Earth or Google Earth meets Second Life mashup, as previously discussed. I think it would be much easier now, at least at the basic level.

Here’s the general outline:

Wrap the new GE DLL in your own pseudo-browser as above (preferably using a compiled language like C++). Combine that with the now-open SL client code, sitting "outside" and running the show. Intercept the calls in the SL client code that create objects. Add some export code such that these calls now save the geometry, prims and avatars for the most part, as Collada. Have GE re-load those into the world (preferably asynchronously).

It would be great if there was a more direct path to get gobs of 3D user data into GE, not yet from what I saw. You’d also intercept the regular SL spatial network updates from the server for objects and avatars and turn those into positional updates in GE. Better yet if you can grab the final (post-smoothed, extrapolated) positions, since you don’t want to see the latency, do you now?

Trickier would be handling the animation of avatar face, skin and joints, since it requires real-time bones and morph support to exist in GE, which I’m sure isn’t exposed. You’d be left with loading a replacement avatar geometry file every frame, which will absolutely be slow. You’d probably settle for avatars that can only move, but not animate.

In fact, the whole thing would be too slow for my tastes, but it’d most likely work as a proof of concept, or at least a cool demo.

I give it a month or two before someone shows a working prototype. Just putting a dozen or so avatars in the world this way would be pretty simple. But don’t try a thousand or more unless you’re a glutton for punishment.

 

3 thoughts on “More Analysis of GE Plugin

  1. Pingback: Links: Cartographica interviews Avi Bar-Zeev; new Google Geo Developers Blog - GIS User News

  2. Pingback: Left: Cartographica interview Avi bar-zeev; new Google geo Developers Blog | Google Earth Blog

  3. Pingback: Links: Cartographica interviews Avi Bar-Zeev; new Google Geo Developers Blog | Ogle Earth

Leave a Reply

Your email address will not be published. Required fields are marked *