The planetary scale components are actually faster and using less memory (RAM+VRAM) than a static terrain ^^
In fact it requires 3 times less VRAM than using a static heightmap based terrain that comes at 2048x2048 and 4 times less on RAM, basically almost none for data, as only partial data is synced back.
On JS side it also has a minimal footprint not larger than having a average glb asset in memory. For drawcalls as mentioned this also is only 1 draw call per layer, 1 entire terrain, 1 entire ocean (also LOD) etc. As i mentioned the goal and architecture of the engine is to be part of games, not being the center piece like a world map system like google maps that can consume all budget.
It also needed to be as efficient to handle world map views that handles separate tiles than those being used in 3D like this, where you can pan around and zoom into areas you’re not actually in 3D. I also use this map for in-game editing the world (probes) in realtime.
And yes, you should not approach such a project in a utopic dreamer way without knowing the tech, a rough solution to all you see without red lights, on the web especially we are more limited and while (with a lot abstraction work) you can open and add a lot detail you need to stay in a reasonable scope, especially if you don’t have decades of experience in developing such / graphics etc your dreams might be crushed very fast only demotivating you. This is harsh these days especially with kids being blinded by graphics and games they get presented that appear like “the default” and “ez” to them while they never made something beyond altering examples or coding at all.
The term sounds a bit harsh, i just don’t know a softer atm, but what i mean was the way it has been transported to public to non-tech people, while the loudest critique, regarding there always being just a hand full assets being instanced everywhere, was ignored, which was the main issue regarding memory consumption. I wouldn’t have made the project if i wasn’t enthusiastic myself, but you should align your ideas and dreams to what is technically reasonably possible, as it’s limited to the hardware users have. I also been running against walls here and there i had to stop and build a ramp first to get across, but these kind of limitations need to be considered a lot, Tesseract is supposed to be a part of projects and that with a small footprint as possible.
There are many attempts that start well with teasers about how great the idea is and then unfortunately hit insurmountable obstacles along the way and cool down.
I didn’t knew for sure either if this would work out when i started, and you always need to be prepared to change approaches, improve/reconsider things, not being bigoted on one way, accept if something wasn’t good enough, tear it down and do better.
But that’s getting a bit philosophical ^^