Maximum Number of Markers

[sampoder]

Hey!

I'm trying to render around 6,000 but only 50 or so markers seem to be showing up on my map, code is here: https://github.com/hackclub/site/blob/10c57825053b4d6a12ba9fb7acaa03926150b971/pages/donate2.js#L48 and the preview is deployed here: https://v3-git-redesign-donate.hackclub.dev/donate2/ and my markers are here: https://github.com/hackclub/site/blob/redesign-donate/components/donate/locations.js

I was wondering if there's a max no. of markers?

Thanks so much!

• Sam

[shuding]

Yep, there is currently a limit of 64 markers:

cobe/src/shader.frag

Line 132 in 75a46e4

for (int m = 0; m < 64; m++) {

It's tricky to work around it due to how shaders work, I'll keep this issue open for now.

[sampoder]

Ah, I see, thank you! What would happen if I was to fork the component and delete the limit, would things go crazy?

[shuding]

Yes, the globe will be extremely slow if you change it to 6,000 (like 100x slower)... I think you can somehow try to merge these markers, because even if you are displaying all of them, those that are very near will be almost overlapped so can be maybe just one marker.

[codeagencybe]

@sampoder did you try removing the limits? How was your experience?
I'm in a similar situation but not as big as yours.
I need to load a few hundreds, but I was also confused first why I didn't see the dots until I found this issue.

@shuding
Now since WEBGL has turned a lot better, does it still make sense to keep it at max 64?
I have seen a lot crazy stuff in the the threejs React groups what they can render in a browser, I would assume rendering a globe can handle it better now?

[shuding]

It's mostly not just about the tech and how performant it is, but how our code was implemented. Basically we have:

for each frame
  for each pixel (800x800)
    for each marker (64)
      if pixel on marker
        draw marker color
      else
        skip

And that loop makes things a lot slower and grows linearly.

A reimplementation of turning markers into individual vertex fragments would solve this completely but that's a lot of work unfortunately.

[codeagencybe]

@shuding aha, ok I understand it better now. I didn't peak yet under the hood, and didn't assume it would be structured like this.

Is the 64 currently used like a "safe" point to keep it performant, or you think it can be bumped a bit while still remaining acceptable in performance?
My use case is not as big as Sam, I only need to render a few hundred (~170 something).
What would be my best option to handle that case?
Or do you know of any other reliable globe solution like yours that could handle larger datasets better?

I was also searching via ThreeJS and came to this package from globe.gl:
https://globe.gl/

They have some example based on polygons, it's not like your nice package but it does show a lot datapoints for every polygon while rendering still seems to be smooth.
Example: https://globe.gl/example/hexed-polygons/

This one also looks very slick: https://globe.gl/example/airline-routes/us-international-outbound.html

But this is also quite overkill for my simple use case. If I could raise the 64 to 3X~4x that number, it would already solve my use case.

Anything I could help with to make your version into vertex fragments? Or what would you need to make this possible?

[shuding]

@codeagencybe I think you can fork (or just inline this lib) to try it and bumping the number up, 170 might be fine!

The 64 was something I picked as a safe bet but it can probably be a bit higher especially when the canvas dimensions are not huge.

[arno-fukuda]

+1

200 limit seems more appropriate (there are 193 countries).
Would be great if we could overwrite the 64 through options.