viewportSpeedFactor multiplier become too small by large zoomlevel

[Kanahiro]

https://github.com/kamzek/deck.gl-particle/blob/7b8a656169cd77f269271ef3d8718ecf327438f0/src/particle-layer.js#L179

This code works well in ordinary zoomlevels, but larger zoomlevel means viewportSpeedFactor exponentially become zero.
Because of this, particles don't move beautifully in such small scale...

I tried some values and found good multiplier 1.7 intead of 2. This value makes move of particles better in small scale. The best number may be different in cases.
So, in my opinion, the multiplier should be user-editable value as one of options - zoomFactor, what do you think?

[zakjan]

Hi, the power base of 2 follows the tiling power base. I believe the root cause is not in viewportSpeedFactor, but in particle coordinates stored as fp32. They need to be stored as fp64 instead to enable particle movement in higher zoom levels. It's planned to improve this.

[saintsjd]

hi @zakjan is there a workaround that you know of? Can you detail a bit more the work that would be needed to enable higher zoom levels?

[zakjan]

There is fp64 support in deck.gl, I need to explore it more in detail. https://deck.gl/docs/developer-guide/64-bits

An alternative approach is to store particles in a coordinate space independent on zoom level. However, one of my goals for this library is to support user interaction with the viewport (zoom, pan). Storing particles in viewport coordinates assumes that the viewport is static, therefore any interaction forces that the particle state has to be reset. I'd like to avoid such resetting if possible.

[saintsjd]

This is interesting:

Note: This extension is the equivalent of the fp64 prop from older deck.gl versions. As of v6.3, the fp64 mode was deprecated in favor of the new default 32-bit projection mode that is comparable in precision but considerably more performant.

https://deck.gl/docs/api-reference/extensions/fp64-extension

I need to look into new default 32-bit projection mode more.

[saintsjd]

and here

With the improved precision 32 bit projection mode in deck.gl 6.1, the use of fp64 is no longer required to achieve sub-centimeter precision. The new 32 bit projection mode has much better performance. This makes the fp64 mode more of a niche technology that demonstrates how to use 64 bit calculations should you need to use them in your own applications.

https://deck.gl/docs/developer-guide/64-bits

[zakjan]

Yeah, these points exactly. Could you let me know more about your usecase for larger zoom levels? I might be able to prioritize it.

[saintsjd]

I notice that as you zoom in on map.html the docs, at about zoom level 15.5, the wind vectors shift their direction. Expected behavior is that wind vectors continue in same direction as user zooms. I am on Chrome 98.0.4758.109 (Official Build) (arm64)

Here is an example. Note, I added onViewStateChange to the map.html to log out the zoom level to the console (on the right side of the screenshots).

      const deckgl = new deck.Deck({
        onViewStateChange: ({viewState}) => {
          console.log(viewState.zoom)
        },       
        parent: document.getElementById('deck'),

Zoom in and note the direction of wind vectors:

Passing greater than 15.5 zoom level over the same area, results in vectors shifting direction. Wind vectors move to the north instead of toward the north east:

Perhaps this is related to precision as the user zooms. I have not been able to confirm.

Interesting to note that when I replace wind_data.png with an image that I created, I can zoom to level 18 before the vectors change directions.

[maxwell-oroark]

Interesting to note that when I replace wind_data.png with an image that I created, I can zoom to level 18 before the vectors change directions.

@zakjan does it make sense to you, knowing what you do about the plugin, that the issue of precision could be mitigated by using an image with a greater resolution? wondering if our image we created might get us around this issue. we can share that image with you as well if that would be helpful in debugging. I'm on @saintsjd team btw.

[maxwell-oroark]

de-activating the layer at zoom levels < 17, assuming it is accurate, would work for our purposes.

[zakjan]

@maxwell-oroark Yes please, it would be a great help if you can share the image for investigation. Either here or over e-mail. I'm not sure how the resolution itself could fix the issue, possibly there is more to that.

[saintsjd]

I'll share via email. Sending it your way