Have it running but...

[jscastro76]

Hi bud,
I have it running with the satellite style

I let the adjustments of continents to the terrain layer, so it works below it.

The problems I have found with standard mapbox...

• Color... By default is dark and not taking the lights as expected. This is very weird because the lights are affecting the radar antenna.

I added another plane below to give it a bit of color... not much improvement

But the weirdest thing is that the reflection is inversed, probably because of the rotation of the water plane -0.5PI

Apart from all of this, the performance is terrible on creation, and scaling it will create a clear tile effect... beyond those things... it works

[mglonnro]

Wow! Great work!

I got stuck at the color also, and couldn't figure out how to add any (similar to the three.js example from where the water was borrowed).

[mglonnro]

One other thing I've noticed today (from a separate issue) is that whenever you zoom out to have a lot of map details, triggering a repaint every frame (forcing mapbox to redraw everything) is getting extremely slow.

[jscastro76]

One other thing I've noticed today (from a separate issue) is that whenever you zoom out to have a lot of map details, triggering a repaint every frame (forcing mapbox to redraw everything) is getting extremely slow.

What about using this instead + threebox to manage the layers??? I’d give it a try, seems quite easy to integrate and could be a great built-in addition for Threebox

[mglonnro]

One other thing I've noticed today (from a separate issue) is that whenever you zoom out to have a lot of map details, triggering a repaint every frame (forcing mapbox to redraw everything) is getting extremely slow.

What about using this instead + threebox to manage the layers??? I’d give it a try, seems quite easy to integrate and could be a great built-in addition for Threebox

Oh, that looks cool as well. Whatever floats the boat, I guess! :) Can you get it working nicely with that?

Re threebox: I just a week ago refactored my project away from threebox (the original version, not your fork) to get a better understanding of how the three.js integration actually works. I might transition back, of course, at some point. But the this.map.triggerRepaint() exists there as well? If I want a rotating 3D cube, for instance, it has to call the trigger for each frame which effectively forces mapbox to redraw all its layers as well, for each frame?

[jscastro76]

Yes, triggerRepaint still there yet, it’s inherent to the way CustomLayerInterface and update layer work in Mapbox. I had exactly the same conversation with other dev last week and I’m still looking for solutions. Anyway the performance has been improved from the original project, you can check the example number 15 on performance even with thousands of objects.

When I did my first research on the TriggerRepaint topic, I found a quite old issue in Mapbox where a guy tested all the different options, including having a fully separated context and even 2 mapbox instances, one of them empty. Here is the link

The performance was obviously better in terms of FPS/memory, but there were other collaterals that I personally wouldn't assume for threebox, like losing the depth calculation between mapbox fill-extrusions and 3D custom layer.

Sharing context	Different contexts & canvas

The second issue is the delay between the movement of both cameras. While current sharing context ensures the objects are fixed and stuck to a coords set, creating different contexts will produce a soft dragging effect where the delay between the 2 contexts render can be visually perceived when the map moves first and the 3D objects follow. It's perceivable even with ne single cube, so with thousands of objects will be definitely clearer.

There's one more test that I would do, is just to create a new context but paint in the same canvas the map is... theoretically speaking, that would solve these two issues keeping at the same time a good performance... but that's a test I haven't done yet.

[mglonnro]

When I did my first research on the topic, I found a quite old issue in Mapbox where a guy tested all the different options, including having a fully separated context and even 2 mapbox instances, one of them empty. Here is the link

The performance was obviously better in terms of FPS/memory, but there were other collaterals that I personally wouldn't assume for threebox, like losing the depth calculation between mapbox fill-extrusions and 3D custom layer.

The second issue is the delay between the movement of both cameras. While current sharing context ensures the objects are fixed and stuck to a coords set, creating different contexts will produce a soft dragging effect where the delay between the 2 contexts render can be visually perceived when the map moves first and the 3D objects follow. It's perceivable even with ne single cube, so with thousands of objects will be definitely clearer.

Oh, how cool to know that someone has traveled down that road as well! And I agree that the collaterals are problematic.

I do most of my 3D stuff on top of the water layer, but there are a lot of different objects so the unsynced movement would look bad.

Here are a few pictures from my project:

I love mapbox 2's sky! Too bad about the shadows :) The transparent water effect is done with a plane mesh that copies its color from the map water layer's color.

In Finland, the seamarks are public data, so I've grabbed that and converted it to 3D objects (drawn by a friend of mine). The picture also shows part of a color-coded (based on speed) track.

Night mode. I'm using the sun elevation to adjust the luminosity of all the map layers (as well as the three.js lights) to simulate it getting dark :)

[jscastro76]

Looks cool!! If you aren’t mixing fill-extrusions with 3D objects, definitely is better to keep the context separated.
If you are using always the same model or a reduce number of them, you should check the cache I implemented in Threebox, that will ensure a minimum consumption of memory by caching the first Object3D instances in every load method by url, that’s how I reached the current performance where thousands on objects could be created where +100 was almost impossible with the original Threebox and the memory could reach +2GB and freeze completely the browser.
you can also check how I implemented the shadows, based on suncalc for a given lnglat and datetime.

[paulsoning]

Hey, I added a huge skybox to get the color

[am2222]

@mglonnro do you have any updated version on this? I am following your foot steps and was wondering what approach did you take at the end?