Border point

[donflopez]

Hi guys,

I have not seen a way to set a border for a point (with colour and width), Is there anyway to set it up? If not, is it planned?

Thank you!

[meetar]

Hi @donflopez – we don't plan to add support for a border parameter on a point style – however you may be able to make a custom style with a shader which places a border around your point, and in some cases you may be able to simply draw one larger point behind another (although you'll have to turn off collisions for that).

[donflopez]

Hi @meetar! Yep, I've seen those possibilities but, could the border be dynamic based on a feature of the data?

Thank you!

[meetar]

We don't have any built-in functionality which matches that description, but if you use the double-point trick then you could set the color of the background point with a function, and the effect would be to color the border based on feature properties.

[donflopez]

If we make a PR with this feature, would you consider to add it to tangram?

[meetar]

We've actually been considering changing the points style behavior in Tangram-JS, to match the Tangram-ES behavior in ways which would allow borders to be easier to implement! Currently the default circular point shape is drawn with a custom shader, and it may be better to switch to using pre-drawn textures instead. So of course feel free to experiment, but this specific behavior is currently subject to change, and without knowing more about how you plan to modify it I can't be sure that our goals will line up.

[meetar]

Changing this to a feature request, for tracking: would like a way to add borders to points.

[javisantana]

the problem with pre-draw textures if that it's hard to deal with situations where you need dynamic border width (based on a attribute for example). That's a pretty typical thing in data visualization (our use case)

[bcamper]

Sorry, to clarify, we mean we may switch to textures that Tangram draws on the fly, according to the styling rules in the scene file. Terminology in this case, "pre-drawn" = "CPU-side / before the shader", vs. the current method which is drawn entirely within the shader :)

[bcamper]

Though even then your by-attribute example is a good one where this might break down. That suggests a method of having one (or a limited number) of SDF-style point textures that are dynamically re-styled in the shader may be the best option. cc @blair1618

[donflopez]

Hey!

We've been thinking about the way to draw points, here are our insights:

• Draw with pre-drawn textures.
  
  We can afford pre-drawn textures by-attribute, making an on demand texture drawer... That is, if you have a border-width changing by conditions when you are gonna draw the points ask to the texture factory for a texture, if there is a texture with those conditions, it returns it immediately if not... it creates the texture on the fly and then return it.

We can also check all the conditions and pre-draw all the possibilities.

But this is a complex task with bad worse cases.

• Draw with gl.POINTS primitive.

Using the points primitive, we can draw points on the fly and use the technique commented before of drawing two points to paint the border dynamically by attribute or directly in the shader, as we are doing here but with gl.POINTS not gl.TRIANGLE.

What do you think?

Thank you all!

[bcamper]

Hi @donflopez -- thanks, your general direction is good, here are my thoughts:

• After more consideration, I don't think drawing different point style combinations CPU-side with textures makes sense, for a couple reasons:
  • The potential number of combinations (as you also mentioned) will be inefficient and unsupportable in extreme cases.
  • We need to keep in mind that any feature added to Tangram JS must also be supported in Tangram ES, our native C++ codebase, and the divergence in CPU-side drawing options there (e.g. we have Canvas in JS) adds complexity (granted it's not very difficult to directly draw point textures).
• Drawing points in the shader is going to be more flexible, and more compatible with Tangram's existing geometry build and render pipeline. I would keep going with the branch you linked, with these comments:
  • We are going to want to use quads (gl.TRIANGLES), because: Tangram is already using them for sprites and label text (which much of this code is shared for), and the entire area of gl.POINTS will get clipped out when the point itself (the center of the sprite) moves out of the viewport (this makes gl.POINTS suitable for cases like particle systems, but not for cases like this where there are fewer overall elements and you want to ensure they are drawn).
  • Terminology thing: we will probably end up going with the term outline rather than border, for consistency with our existing lines styles.
  • This should go down the untextured point path, so the rest of the shader continues to work for other cases.
  • Currently, each points-based style must be configured to render either with a texture or without a texture (e.g. you can't mix textured and non-textured features drawn with the same style). This is something I'd like to relax in the future, but should be outside the scope of the initial PR / feature addition. The benefit is that you can use this restriction to only add vertex attributes for outlines when they are needed (saving memory usage for other features), for example in an else clause here. Here's a similar example from the lines style.
  • We will likely upgrade the shader drawing portion to use a Signed Distance Field texture for better antialiasing (example for the Refill style here old: Texture dots refill-style#33). But I'd prefer to keep that out of an initial PR and continue to implement using the existing code, as you have (just extended for an outline).
  • Please follow the Tangram code style, for example variables (non-methods) are with_underscores (I probably wouldn't choose this if starting the project now as it's less common, but it's the style we already have).
  • Otherwise, it looks like you are following the existing patterns! Which are not always so obvious :)