Where Conference 2012

Looks like I'll be at the Where 2012 Conference this year.  If any of my users are going, drop me a line.

MapBox Tiles - The paging version

MBTiles databases are deceptively simple.  They're just a database with a little metadata, right?

Yes, and that's what makes them tricky.  From an implementation perspective, here are some of the problems:

• They can be sparse.  Just because there's a level 7 tile at (40,41) doesn't mean there's one at (20,18).
• They can be empty up top.  A user might neglect to include levels 0-5 because they don't need them.
• They don't cover the whole earth.  Usually.

There are good reasons for all of those, mostly having to do with 2D map display.  In 3D this gets interesting.  

To do this right I have to map a 2D quad tree onto a sphere for proper data paging.  You have to either hack it or work in screen space.  I'm doing the latter and it means projecting representative pixels to the screen and deciding how important their associated tiles are.  It's a nice general solution and should work well for other data types too.

The point to all of this is that MapBox Tile paging support is underway.  That will open up a host of other interesting areas too.

github has won the internet and I'm a joiner

I've got a whole bunch of stuff coming up and rather than announce it all at once, I'll dribble it out bit by bit.  Let's start with github.

Don't Make This Harder Than it Has to Be

Hey, google code.  It's not you, it's me.  Honestly, I just think github will make me more popular.  There. I said it.

Yes, yes.  I know you do git now and I appreciate that.  Really, I do.  But let's face it, we both know you don't really want to.  And you've really let your social features go.  I mean, that's just sad.

So I'm going to leave my old repository there for a while if you don't mind?  Yeah, I know that's a bit rude... but it's more convenient for me.

WhirlyGlobe 2.0

The next major version will go up on github.  In fact, it is already.  You just can't see it.  Trust me, you don't want it yet.  I'm messing with the namespaces and generally causing havoc.  Why put up with that until you have to?

I'm also contemplating a smaller 1.3 release to round out the Mapbox Tiles functionality.  That'll stay on google code.

Live Globe

I'm pleased to announce the release of Live Globe 1.0 on the app store.  This app really pushes WhirlyGlobe to its limits in some interesting ways.

Live Globe is actually the original WhirlyGlobe app and the publisher, Hyperwords, is my first WhirlyGlobe client.  There's some interesting history there, but first a video.

History

In early 2011 I was contemplating writing a toolkit.  I was thinking of doing either a 3D interactive globe or a 2D interactive map, but I needed a client.  I've learned that I don't get anything done without deadlines or outside observers.  Quantum effects may be at play.

So there I was trolling the job boards, looking for someone who needed one or the other.  Hyperwords turned up first with a list of requirements for a 3D globe.  I sorted those into toolkit vs. app piles, made an initial schedule and off we went.

The WhirlyGlobe toolkit is all mine, distributed under an open source license.  So most of that development was just me doing my thing.  As soon as the toolkit was working, we negotiated for development of Live Globe specific features.  I'm a consultant, that's what I do.

After another interlude, I ended up writing the non-globe features as well.  And here we are.

Features

If you're at all interested in this stuff, you should just go buy the thing and check it out.  No whining about the $3.99 price tag.  Nice things cost a little bit of money.

There are a few unique things in Live Globe.

• The imagery data set is tweaked a bit and higher resolution than normal.
• Two data sets are provided for different hardware.
• Some of the vector data is new and a good bit of the rest is modified.
• The interaction model is a bit smoother and better integrated.
• Overall, the app more gracefully handles memory usage.

Those first three are the most interesting.  A lot of app developers don't want to deal with manipulating the data sets.  For good reason too, it's a weird set of skills and it can be time consuming and expensive.

The rest of the development was details, details, details.

Full Disclosure

I'm not an independent app developer.  I only do apps for other people.  I'm not a partner in Live Globe or any other app.  I'm just a consultant with a toolkit.

Live Globe is cool and I wish Hyperwords the best, but I don't have a stake in its financial success.

So Buy it Already

Hyperwords has a long list of features planned for future versions.  But someone has to, you know, buy the thing.  This was the app I used to develop WhirlyGlobe and it was invaluable to me for that.  If you're using WhirlyGlobe or even think it's cool, you should go buy this app.

MapBox Tiles Support & Other Things

Right now WhirlyGlobe supports a single resolution of imagery for the globe.  You chop it up, feed it to the system and it uses that.  I've always planned on supporting image pyramids.

There are lots of ways to represent an image pyramid.  The one I settled on, for various reasons, is MBTiles.  It's pretty simple and they've got a decent iOS presence.


MapBox Tiles - First Pass

I'm implemented a first pass at MBTiles support.  Here's a pretty picture.

MBTiles layer - Geography Class data set

Lots of things missing here, but let's talk about what's working.  I've added a new data layer called WhirlyGlobeMBTileLayer.  It works in much the same way as the Spherical Earth Layer.  You give it  the name of an MBTiles file and it'll do the rest.

MBTiles are stored in a Spherical Mercator coordinate system (designed to annoy professional cartographers).  That's fine for our purposes, but it does mean we have to do a little reprojection.  The layer handles that part by generating the triangle grid in the local system and projecting out.  As a result the images get warped without having to do anything else.  It's good enough for display.

Just to make that point, here's another pretty picture showing how a vector layer lines up with the underlying image.  It matches perfectly.  A little too perfectly actually, which means we're using exactly the same data set.  Natural Earth 10m admin 0 represent!

MBTiles Layer + 10m vector countries

Okay, so it's completely working, right?  Not so much.  This was just the first pass.  Let's take a look at...

Missing Features

In the above examples we've loaded the 4th level of detail.  It's basically a quad tree so that's means an image set of 16 by 16 tiles.  That looks good here, but if we go closer, it won't.  Go up another few levels and that's too much memory.

The solution is dynamic tile paging.  Load in what's near you, or really what takes up the most screen space.  Load out what isn't important.  It gets messy.

That's the biggest missing feature: dynamic tile paging.  There are some minor features too.  

• Tile edging.  When textures and chopped images don't get along, you see seams.  I need to figure out why, in this particular case.
• Sparse MBTiles.  It's possible to make an MBTiles archive with missing pieces.  Useful, but annoying to implement.
• MBTile selection layers.  The standard supports these grids for doing lookups.  I use vector data for that, but someone might need these instead.
• PVRTC support.  JPGs and PNGs are a huge waste for the graphics card.  We really need PVRTC images.

Development Plans

I've checked the first pass in to the trunk.  Feel free to kick it around.  If all you want to do is load in a single level of detail, that might be enough.

I don't think this will be truly useful until the dynamic paging is working.  Right now I'm pursuing it at open source speed.  It'll get done eventually in conjunction with an app that the Development Seed guys are working on.

If you need this functionality sooner and have money, let's talk.  This could move up to client speed.  If you don't have money and still need it, I'd be interested in hearing about that as well.

Oh, and here's another pretty picture.

Geography Class + Lofted Polys

WhirlyGlobe 1.2 - Release Announcement

I'm pleased to announce WhirlyGlobe 1.2.  This release has been several months in coming and represents a big step for some of the more interactive functionality in WhirlyGlobe.

I put together a little a short video of the changes.  Check it out below in all its twitchy camera glory.  I'll cover the changes in more detail here.

Marker Layer

In WhirlyGlobe 1.0 we had text labels.  They work great, but sometimes people just want to stick a textured polygon down on the terrain and call it a day.  Or maybe they want to throw down several hundred of them with a sequence of textures.  Either way, we can do it now.

With Markers, you specify a geographic location per marker and one or more textures to use.  If you give it a sequence of textures and a period, it'll switch between them.  We make that all fast on the back end.


Particle System Layer

This feature was just plain fun.  You give WhirlyGlobe a location for the emitter, or 150 of them, a bunch of parameters for the particles and off you go.  The emitters generate new particles in the rendering thread and it all looks smooth and pretty.

For now we're doing simple fountains.  We could change that easily enough.  I'm talking to you, potential clients.


Lofted Polygon Layer

We had lofted polygons in the WhirlyGraph app, but not as a regular feature in the toolkit. These are transparent shapes that sit on top of the terrain, letting you see what's underneath.  They look cool and they're harder to implement than you might think.

Special thanks go to the Clipper library.  I've written that code before and I'm just as happy not to have done so this time.  Plus, theirs is better.



Fading In & Out

It's a minor feature, but I'm already overusing it.  If you specify a fade time on the description dictionary for your object, WhirlyGlobe will fade it in and fade it back out when you delete the object.  Even a fast fade, like half a second, looks good.

Fading out was much harder than fading in, but we did it.  All for you.


Selection Layer


We already had support for geographic selection.  That is, finding the region that contains a given point in latitude/longitude.  Several of my clients needed something better: screen space selection.

Labels are the most obvious problem:  How big is a label in geographic coordinates?  What if I want to select the nearest label instead of whatever falls beneath the tap?  Annoying questions when you're working in lat/lon.

With the selection layer, you just hand over the extents of your object and give it a unique ID.  When you need to run a query, just ask the selection layer to do the work for you.  Much easier.

The label and marker layers in 1.2 use the selection layer if you turn it on.



Caching

Now we're in to the low level features.  Caching lets computationally expensive layers save their work.  The vector and label layers can make use of it, but it's really the Loft Layer that needs it.

What you do is specify a cache name for a given object (or set of objects).  Then, when you ask the layer to add it, it can check the cache first.  If the cache is present, we read from it.  If not, then we do the computation and save to the cache.


Texture Atlas Builder

Keeping the texture count down in OpenGL is pretty key.  If you look at the guts of any modern game you'll see they've merged a whole lot of their textures together into big atlases.  We need to do that too, but our content is more dynamic.

The solution is a texture atlas builder.  Hand your images over to the builder and you'll get a smaller set of bigger textures and a mapping from one group to the other.  You can use these sub textures as regular texture IDs and the layers will do the right thing.

Obviously, this should work with caching, but doesn't yet.


Generators


I'm a big fan of static geometry for rendering. I don't like doing any calculation or data manipulation I can't avoid.  However, some features need real time data manipulation on (or near) the rendering thread.

Generators let us do that without losing too much control.  They're render-side objects that construct the optimized drawables we need in the rendering thread.

In WhirlyGlobe 1.2 we've got a generator for particle systems and one for markers.  For particle systems the generator creates new particles and updates the positions of existing ones.  The marker generator handles switching texture display for multi-texture markers.

I've been pleased with how fast the render side generators are.  I see more animation in WhirlyGlobe's future.


WhirlyGlobeTester

WhirlyGlobe is all about the interaction, so things are constantly getting added and deleted.  We needed a better way to test all that.

The WhirlyGlobeTester app contains code for most of the WhirlyGlobe features.  It also helps test interaction with view controllers and serves as example code.  Look here for best practices.

You can find WhirlyGlobeTester in the source tree or the starter pack.

Where to Get It

You can grab the source tree from the google code page.  The 1.2 release is tagged.

If you just want the framework, check out the downloads page.  There's also a starter pack which contains all the test apps and 3rd party libraries you need to compile.

WhirlyGlobe 1.2 - Imminent

I'm just about to release WhirlyGlobe 1.2. This week is pretty likely, early next week at the latest.

Delay, Delay, Delay

I was hoping to wrap this up in November; now it's January. I blame my "clients" with their requests for "work" they're "paying" me for. Bastards. They're still out there, but I've cleared myself a little time to wrap this sucker up.

I've got developers using preliminary versions of 1.2 already. It looks pretty good. In fact, I'd go so far as to call it snazzy.

Looking Past 1.2

I have a 1.3 released planned with one or two big features. I'll talk more about that after 1.2 is out.

WhirlyGlobe 1.3 is likely to have most of the features I consider essential for a 3D interactive globe toolkit. Anything beyond that I'll probably let clients drive.