Add z axis to offset property

[peterqliu]

We should take advantage of the extra dimension that map pitching affords us, and use depth to visualize overlapping elements that would otherwise obstruct each other.

Currently, the layer stack order is dictated by the sequence it was specified in the stylesheet; when applied, the proposed z-offset would override that. This is analogous to HTML's natural stacking order overridden by z-index in CSS.

Also, label rendering order is currently tightly bound to layers' z-order, because they both key off of the stylesheet layer sequence. Adding z-offset will free us to decide which layers get rendering priority, regardless of whether they go above or below other layers.

cc @lucaswoj @kkaefer

[tmcw]

Currently, the layer stack order is dictated by the sequence it was specified in the stylesheet; when applied, the proposed z-offset would override that.

This doesn't make sense to me; altitude and draw order are different concepts.

[samanpwbb]

I love this idea.

altitude and draw order are different concepts.

That's why it'd be nice to make it possible to decouple altitude (z-order) from draw order. If I follow @peterqliu idea correctly, draw order would continue to be dictated by layer order, but then a new z-offset property would allow layers to break away from that order (sort of like z-index in html).

If we had data driven styling, would then allow for zordering based on a field (and then maybe let us close mapbox/mapbox-gl-js#1349 - of course this would be way to do it with less layers)

[peterqliu]

altitude and draw order are different concepts

@tmcw they are, but because layers are drawn bottom-up, earlier layers are covered by (hence appear "lower" in the stack) than later ones. Right now, draw order dictates the perceived altitude of different layers.

[peterqliu]

Another benefit: z-offset would enable us to "interweave" layers from different groups, instead of stacking a whole group on top of another in altitude. For example, I'd be able to group casings together and roads together, even if some casings sit atop some roads.

This makes groups more powerful, because we'd be able to associate layers by concepts, without being hamstrung by their positions in altitude.

[jfirebaugh]

I agree with @tmcw -- I would expect a z-axis in *-offset properties to modify the geometries in the scene, not draw order or depth-buffer order. It would only have a visual effect if the map is tilted.

[peterqliu]

to clarify, the z-offset would not affect draw order at all (as @samanpwbb said, that would continue to be dictated by layer order). But it would have a visual effect with or without map tilting, of being lofted above/below the rest of the map surface. In plan view (no tilt), lofted layers would cover the ones below it, regardless of draw order.

[samanpwbb]

This conversation needs some clarification, partially my fault:

Peter's initial issue is about something he's calling z-offset, which would be a pixel value that moves a particular layer on the z-axis in a way that would be apparent if the map were pitched.

For some reason, I thought he was talking about something more like z-index – which would effect only the order in which features are drawn, still flat (I should have looked at the picture).

When both Peter and I both said draw order we only meant to refer to the logic that calculates collision detection across layers. I think that's the wrong word to use for this.

---

It doesn't make sense to conflate z-index and z-offset. These are different things and if anything, would demand two different properties.

To someone who is used to using Mapbox Studio but isn't familiar with how the renderer works, it's tempting to talk about draw order and z-index as separate things. I have a sense that for those of you who understand how the renderer works, it's not so easy to separate the two things.

---

We should refocus this conversation around the original z-offset idea, which would only effect maps that were pitched.

[samanpwbb]

Would be awesome to revisit this. There are times when it would be useful to raise layers or features above other features on a map – right now I'm trying to make a map that feels like it has an annotation overlay that's raised up from the base. For these cases, there should be a z-offset property:

It makes to have these properties use the same units as extrusion-height and extrusion-min-height rather than the units used by existing x/y offset and translate properties. For that reason, we'd need a add new property instead of introducing another element in existing offset/translate arrays.

z-offset would be useful for all layer types. If applied to a layer with extrusions, z-offset would offset the entire extrusion layer (effectively moving up both min and max heights.

Two questions:

1. What would happen when the map is not pitched?
   
2. Some map designers might expect or desire the option to let raised features cast shadows. Would something like this be technically possible?

[ansis]

I agree with @tmcw -- I would expect a z-axis in *-offset properties to modify the geometries in the scene, not draw order or depth-buffer order. It would only have a visual effect if the map is tilted.

I disagree. I would expect a layer that is offset in 3D space to be drawn as if it exists in 3D space. Can anyone think of a case when you'd want a layer with a higher offset to be drawn below a layer with a lower offset?

---

Also, I'm not sure whether we should add z-offset to existing 2D render types or if we should just add more 3D render types.

Things get complicated when you consider z-offset works when it is data-driven, when it interacts with other 3D objects, what kind of transparency blending we can support for 3D things, and how it behaves with 3D terrain.

I think it might make sense to keep 2D layers completely 2D and only add 3D things to 3D layers.

[lucaswoj]

Merged into mapbox/mapbox-gl-js#3993