Inlay blend mode incompatible with point and text styles

[karimnaaji]

Inlay blend mode is incompatible with our text and point styles, the reason being that the depth of text and icons is not in world space but in screen space so interleaving geometry is not possible as is. An experiment using the stencil buffer to occlude part of the icons has been done on https://github.com/tangrams/tangram-es/pull/402, this solution gives the expected result.

Referring discusssions:

• https://github.com/tangrams/tangram-es/pull/402
• https://github.com/tangrams/eraser-map/issues/74

Docs:

• https://github.com/tangrams/tangram-docs/blob/97ce6fe9f727c6b3d69052e9e9938dd2edc4852c/pages/styles.md#blend

[westnordost]

This would also be very helpful for node-features that should be part of the map and not on top of the map. For shops etc. it is understandable that they should not be occluded by buildings etc. other features maybe should. Examples for nodes that should not appear in front of a building if they are really behind it:

• trees
• barriers (gates, cycle barriers,...)
• pedestrian crossings
• (mini-)roundabouts, turning circles, turning loops

[warpedgeoid]

Are there any workarounds to this issue when dealing with hundreds of point markers that each must be displayed in a certain order based on a defined priority?

If not, I'm going to have to start the painful process of migrating to another framework for our mobile app. We've spent months perfecting our map styles against the JS version only to learn that ES supports only a fraction of the style features.

Additionally, if this limitation is mentioned in the documentation, it's far too subtle.

[matteblair]

Hello @warpedgeoid 👋

Points can be drawn in order of precedence using the priority parameter, which works the same in JS and ES. I might not totally understand your goal though, so feel free to elaborate.

[warpedgeoid]

Unfortunately, can't elaborate very much due to legal BS. However, I can tell you that the symbology in question is very complex, and defined within a document issued by an international standards body. In certain cases, point markers must appear stacked on top of one another, but the rendering order is defined in the standard for each type of marker, and any implementation doing this incorrectly would be obvious to end users.

[matteblair]

I see, that does change the problem. priority controls the visibility of icons when they collide, but doesn't change their "stacking" order. It sounds like you found a way to arrange these symbols correctly in Tangram JS - are you using the z parameter?

[nvkelso]

We do some tricks like the stacking in Walkabout with the trees layer, IIRC?

[warpedgeoid]

@matteblair We used nested layers with different order parameters. Looking back at the rendered output, I can see where some of the points are not being drawn in the proper order even in the JavaScript version. Didn't know about the z parameter, is it documented somewhere?

@nvkelso I'll take a look at Walkabout. Does this stye work equally well on JS and ES?

[tallytalwar]

@warpedgeoid It should work equivalent on both JS and ES, apart from any new features from JS, which I don't think walkabout is using right now.