Circle technique points where size is relative to land area

[LukeParky]

Hi all, loving harp.gl but I've run into something that appears possibly inconsistent in the documentation and I'd like some advice.

Using SquaresTechnique for points, the size attribute represents size in the geo reference frame, whereas for CirclesTechnique the size attribute represents size in pixels.
In the source code PointTechniqueParams states size is in pixels so SquaresTechnique appears to be inconsistent.

I want to render a circle with the size in the geo reference frame, so having the behaviour of SquaresTechnique but rendering a circle instead of a square. Is there a way to do this using the established square or circle techniques or will I need to do some calculations to convert pixel size to geo size?

[nzjony]

@LukeParky, yes you have found an inconsistency / bug.

The SquaresTechniqe uses the THREE.PointsMaterial, which internally sets: https://github.com/mrdoob/three.js/blob/434b33e5d6811d82082172ed8a18d787818d930a/src/materials/PointsMaterial.js#L32 which controls the points size, see: https://github.com/mrdoob/three.js/blob/434b33e5d6811d82082172ed8a18d787818d930a/src/renderers/shaders/ShaderLib/points_vert.glsl.js#L25

However we have a custom material for points, see the vertex shader:

harp.gl/@here/harp-materials/lib/CirclePointsMaterial.ts

Line 28 in 7a6da80

gl_PointSize = size;

So, basically for squares, the size is computed with some attenuation but not for circles.

According to the documentation, the size of the squares / circles should be in pixels. So, from an API point of view, the square should not reduce its size based on the distance to the camera. It should stay a fixed size in screen space.

However, we can make this configurable. For example, the lines can be configured to have either a width in meters or in pixels. And it should be easy to do this for the squares / circles. Unfortunately, we are very busy with internal tasks, so I don't see this being implemented soon.

You could open a PR if you want to implement it yourself. Otherwise, you could hack the CirclePointsMaterial.ts and include gl_PointSize *= ( scale / - mvPosition.z );

[LukeParky]

I have added a commit to my fork that has attempted to solve this issue but I ran into the following issues that will need further work if you wish to have this pulled into the main repo:

1. To scale the meters correctly I had to use trial and error to find the right scale factor, this is only an approximation.
2. When zooming in very close the original SquaresTechnique and the updated CirclesTechnique shapes shrink instead of staying the same size in metres.
3. The px size never matched the number of pixels rendered on my screen, but is now different.
4. To maintain backwards compatibility the default size for circles will need to stay as metres and I am not sure how to do this in a clean way and since I don't require backwards compatibility I haven't tried a messy way.

None of these need urgent fixes for me so I will probably not be touching this for a while.
Should we create an issue/draft PR for my changes so that another developer may be able to pick up from where I left off?

[nzjony]

@LukeParky , I forked your fork and added a commit to directly compare the square / circle techniques, see: nzjony@dcf9d24

Regarding your points:

1. Yes, it seems the scale has to be changed / tweaked, maybe you can find what scale is used in three.js...?
2. Yes, this is weird, not sure what is going on here....
3. Yes, you have this scale which changes things. Perhaps the scale is created based on some PPI and your monitor is different?
4. Don't you mean pixels? At least currently the API says the size is in pixels. Or maybe I missed something.

I wish I had more time to investigate but I can't :(. As you like, a draft PR is good and yes, maybe another developer can take off.... at least if someone else asks for this in the future, we can point them to where you got to.

[LukeParky]

@nzjony thanks for that commit and the pointers.

Regarding the discussion points:

1. I will investigate this for a while but I may not have time to look deep enough to find it.
2. Perhaps this could be another issue even if it is a low priority one.
3. Not sure what's happening there but it happens on my 1080p monitor and my ultrawide.
4. Sorry I made a mistake. The original default size is measured in pixels, but it is now metres on my fork, so it will not be backwards compatible.

I will create a draft PR and do some more investigation

[LukeParky]

I have created the draft PR #2271. Should I also create an issue to go along with this?

[nzjony]

@LukeParky , yes, please create an issue.