Support polygon blurring

[kkaefer]

For outdoors hillshades. Ideally this is a blur property that takes a pixel value.

[kkaefer]

#140 is a prerequisite for this.

[incanus]

I have added this to the WWDC milestone. Let's get all the relevant Outdoors-labeled issues there for easier tracking if the goal of #171 getting Outdoors working is part of the WWDC launch.

[kkaefer]

Cross-referencing mapbox/mapbox-gl-js#236

[kkaefer]

There are still a lot of things that need to be done; I created separate tickets for these:

• Support prerender: true for other layer types #246: Support prerender: true for other layer types
• Prerender at the beginning of a frame #247: Prerender at the beginning of a frame
• Manage prerender textures more efficiently #248: Manage prerender textures more efficiently
• Properly store/restore OpenGL state #249: Properly store/restore OpenGL state

[incanus]

Do we need the blur properties to be transitionable?

[edenh]

@incanus not necessary for transitioning between WWDC styles, but nice to have otherwise.

[incanus]

Ok. #252 (non-WWDC).

[incanus]

@gundersen blur side-by-side for context (click for full):

[gundersen]

wow. This is so close. @nickidlugash @edenh - thoughts on matching the darkness of the hill shades?

[edenh]

The issue currently is that blurring is applied uniformly at all zoom levels. Supporting zoom-aware functions for blurring (#253) should get this near perfect.

[incanus]

I'll take a crack at that shortly then @edenh.

[kkaefer]

@edenh The blurring is already somewhat zoom-aware: It appears more blurred the further you zoom in, and appears less blurred the more you zoom in. As explained in #253 (comment), this isn't an easy thing to fix for now (we can revisit this later on). It looks like this is only a slight visual deviation from Mapnik's look, but please reopen a ticket if it's not and this is more urgent.

[edenh]

@kkaefer here are a few comparisons. The blur is currently too aggressive and actually ends up degrading the quality a bit. If we can't hit functions, could we at least set a min zoom for the blur property (~14-15)?

Original

With blur

Without blur

For these low zoom levels, I prefer the crispness without blur. Another example:

With blur

Without blur

[nickidlugash]

For reference, the carto outdoor style starts hillshade polygon blurring at z14:

at z14 --> image-filters: agg-stack-blur(2,2);
at z15–16 --> image-filters: agg-stack-blur(8,8);
at z17–18 --> image-filters: agg-stack-blur(16,16);
at z19 and above --> image-filters: agg-stack-blur(32,32);

[kkaefer]

The way blurring works is by rendering everything to a texture, then blurring the texture, then upscaling the texture to fit the tile. Currently, the texture is 256x256 pixels, which when upscaled looks very blurry. You have these options to control the blurring:

• prerender-size: The texture size (default 256).
• prerender-buffer: The buffer in percent around the tile that we should render too. This should be identical to the amount the data in the vector tile exceeds the vector tile's bounding box. (default 1/32 = 0.03125)
• prerender-blur: Number of blurring rounds performed.

With a prerender-size of 512, the hillshades look like this:

Previously:

[edenh]

Ok. Setting the buffer size to 1024 generally helps if we cannot contain the blur to specific zoom levels, but I think 512 after z14 would be much better.

[kkaefer]

@edenh What we can do is have function properties that are fixed to integer zoom levels, e.g. they wouldn't smoothly interpolate between zoom levels as you zoom in and out, but we could use stops to define values for integer zoom levels. Does that sound useful?

[edenh]

Yes, that would be fine. We would probably want to minimize the amount of 'jumps' in blur to one or two at ~ z14 and 17 in that case.

Would this just look like a stops function on the prerender-size property?

[nickidlugash]

I think this could work, since the complexity of hillshade polygons and density of contour lines change at integer zoom levels anyway.

[edenh]

@kkaefer any chance you can hit stops for polygon blurring today?

[kkaefer]

@edenh I will implement this tomorrow (Sun) morning.

[edenh]

@kkaefer great. It will also be useful for some of the overlay work.

[mikemorris]

Curious if any techniques from http://www.sunsetlakesoftware.com/2013/10/21/optimizing-gaussian-blurs-mobile-gpu would be applicable here to increase performance?

[kkaefer]

We're already doing that:

I used OpenGL's native support for linear interpolation to downsample the source image by 4X in width and height, blurred that downsampled image, then linearly upsampled via OpenGL afterward