mipmaps for pois

[tallytalwar]

• [ ] Just do it

Does it make sense for pois to have mipmap filtering?

Refer: https://github.com/tangrams/eraser-map/blob/gh-pages/eraser-map.yaml#L117

[nvkelso]

@tallytalwar What alternative should we use?

[tallytalwar]

I am not sure, but I believe we do not need any filtering for icons! Karim can add more on it though.

[karimnaaji]

Mipmapping basically optimize rendering of icons when they are scaled at a bigger/smaller ratio than their original size. So actually if we don't drastically modify the size param on any of the sprite/icons this would save us minimal memory. For eraser-map we would be ok not specifying any filtering and using the default one.

[nvkelso]

We do scale the images (in EraserMap), though?

On Sep 29, 2015, at 13:05, Karim Naaji notifications@github.com wrote:

Mipmapping basically optimize icons when they are scaled at a bigger/smaller ratio than their original size. So actually if we don't drastically modify the size param on any of the sprite/icons this would save us some memory. For eraser-map we would be ok not specifying any filtering and using the default one.

― Reply to this email directly or view it on GitHub.

[karimnaaji]

Right, just been checking the actual reductions, it would make sense to use this if the reduction is more than half of the original icon size. But personally, I would recommend to use this filtering only when the texture is applied in 3d perspective. I experienced issues when neighboring icons were blurred together during the mipmap process which can cause some annoying artifacts on borders (if we don't space them enough in the icon atlas), so the best is not to use this filtering when providing an atlas. Once we have the style-sheet working in es I'll test the different cases to see what fits best.

[nvkelso]

It’s super easy to space the assets farther apart in the sprite sheet, btw.

(They used to be farther apart, but Patricio needed them piled on top of each other for a Tangram experiment and we never spaced them back out.)

On Tue, Sep 29, 2015 at 4:36 PM, Karim Naaji notifications@github.com wrote:

Right, just been checking the actual reductions, it would make sense to use this if the reduction is more than half of the original icon size. But personally, I would recommend to use this filtering only when the texture is applied in 3d perspective. I experienced issues when neighboring icons were blurred together during the mipmap process which can cause some annoying artifacts on borders (if we don't space them enough in the icon atlas), so the best is not to use this filtering when providing an atlas. Once we have the style-sheet working in es I'll test the different cases to see what fits best.

— Reply to this email directly or view it on GitHub https://github.com/tangrams/eraser-map/issues/45#issuecomment-144220873.

[karimnaaji]

Oh ok I see. If we notice any artifacts,  with this specific filtering we'd try different spacing, for now we can let it as is.

On Tue, Sep 29, 2015 at 7:46 PM, Nathaniel V. KELSO notifications@github.com wrote:

It’s super easy to space the assets farther apart in the sprite sheet, btw. (They used to be farther apart, but Patricio needed them piled on top of each other for a Tangram experiment and we never spaced them back out.) On Tue, Sep 29, 2015 at 4:36 PM, Karim Naaji notifications@github.com wrote:

Right, just been checking the actual reductions, it would make sense to use this if the reduction is more than half of the original icon size. But personally, I would recommend to use this filtering only when the texture is applied in 3d perspective. I experienced issues when neighboring icons were blurred together during the mipmap process which can cause some annoying artifacts on borders (if we don't space them enough in the icon atlas), so the best is not to use this filtering when providing an atlas. Once we have the style-sheet working in es I'll test the different cases to see what fits best.

— Reply to this email directly or view it on GitHub https://github.com/tangrams/eraser-map/issues/45#issuecomment-144220873.

---

Reply to this email directly or view it on GitHub: https://github.com/tangrams/eraser-map/issues/45#issuecomment-144222430

[karimnaaji]

To expose more clearly what I was saying yesterday, this is what happens when you provide this filtering which generate those images (where each of them is half the size of the previous one):

Level0:

Level1:

Level2:

Level3:

So clearly, we can't use icons over level1 where information is lost, which is why scaling over half of the size in minification isn't a use case for us, and using the default filtering would be totally fine.

[nvkelso]

Cool, thanks for researching. Is the recommended fix to remove line https://github.com/tangrams/eraser-map/blob/gh-pages/eraser-map.yaml#L117?

[karimnaaji]

Yep

[karimnaaji]

To visualize how it renders in ES, by aggressively scaling down the size icons:

Default:

Mipmaps:

[bcamper]

@karimnaaji in JS, we default to linear filtering (not nearest which visually is "no" filtering) if no filtering is specified. I really think mipmap is overkill in most of these cases (likely for POIs anyway). It makes sense for bigger textures, like those world texture experiments Patricio was doing, or perhaps larger area decals? Also, in WebGL, mipmapping is not supported for non-power-of-2 textures, so in those cases it falls back to linear even if mipmap is requested (but ES supports mipmapping for non-power-of-2 I think right?).

In short, we should have support for filtering as mipmap, linear, nearest in ES, and default to linear. But for this style I think we should just switch to linear anyway (it's only mipmap because it was copy-pasted from another example).

[nvkelso]

Using linear would probably fix a bug I’ve seen where specifying sizes not clean fractions of the original has no affect.

On Fri, Oct 9, 2015 at 8:15 AM, Brett Camper notifications@github.com wrote:

@karimnaaji https://github.com/karimnaaji in JS, we default to linear filtering (not nearest which visually is "no" filtering) if no filtering is specified. I really think mipmap is overkill in most of these cases (likely for POIs anyway). It makes sense for bigger textures, like those world texture experiments Patricio was doing, or perhaps larger area decals? Also, in WebGL, mipmapping is not supported for non-power-of-2 textures, so in those cases it falls back to linear even if mipmap is requested (but ES supports mipmapping for non-power-of-2 I think right?).

In short, we should have support for filtering as mipmap, linear, nearest in ES, and default to linear. But for this style I think we should just switch to linear anyway (it's only mipmap because it was copy-pasted from another example).

— Reply to this email directly or view it on GitHub https://github.com/tangrams/eraser-map/issues/45#issuecomment-146899983.

[bcamper]

Um, strange, can you elaborate / have an example? That should not be the case.

[karimnaaji]

There's is support for NPOT on desktop, but not on Opengl ES 2.0 (at least for mipmap generation) without using extensions (or on some devices without extensions, but I've seen it working on some devices without doing anything, which depends on the driver), if we want to use mipmap for anything we would need to use power-of-2 textures. Also, there's no fallback on this right now on ES, but I'll follow up and add the behavior.

It's a different but related subject on mipmaps, and I think that @blair1618 would agree with that, since the stylesheet is getting stable on how many/what kind of pattern would be used (mainly grid/dot patterns) we must use textures with mipmap filtering for those (with a default color that we could easily modify in the shader). One of the main advantage of doing this would be a consistent dot/grid pattern on tilted view, mipmaps are really good for that, pixel shaders just screw the pattern since the covered screen size is hardly known while tilting/rotating which leads to flickering and aliasing on the pattern, but also in rendering (one texture fetch vs a full pixel pattern shader would be much better).

Current status on ES with eraser-map stylesheet:

• grid pattern on rotated/tilted view on a building

• dot pattern from far away on tilted view