Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Border point #464

Closed
donflopez opened this issue Dec 7, 2016 · 12 comments
Closed

Border point #464

donflopez opened this issue Dec 7, 2016 · 12 comments

Comments

@donflopez
Copy link
Contributor

donflopez commented Dec 7, 2016

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!

@donflopez donflopez changed the title Point border Border point Dec 7, 2016
@meetar
Copy link
Member

meetar commented Dec 12, 2016

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).

@meetar meetar closed this as completed Dec 12, 2016
@donflopez
Copy link
Contributor Author

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

Thank you!

@meetar
Copy link
Member

meetar commented Dec 12, 2016

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
Copy link
Contributor Author

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

@meetar
Copy link
Member

meetar commented Dec 12, 2016 via email

@meetar
Copy link
Member

meetar commented Dec 12, 2016

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

@meetar meetar reopened this Dec 12, 2016
@javisantana
Copy link

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
Copy link
Member

bcamper commented Dec 13, 2016

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
Copy link
Member

bcamper commented Dec 13, 2016

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
Copy link
Contributor Author

Hey!

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

  • Draw with pre-drawn textures.
    presentacion sin titulo
    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
Copy link
Member

bcamper commented Dec 15, 2016

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 :)

@bcamper
Copy link
Member

bcamper commented Apr 28, 2017

Released in v0.12.0!

@bcamper bcamper closed this as completed Apr 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants