Loading is pretty quick and if there were better coherent maps from NASA then I would use them, because the system is far more powerful than what can be experienced here with the map material available to me. I even upscaled the NASA Mars Maps 106k to 131k and filtered it a little in the hope of getting a little more detail. 1000k would be just as possible without significantly more computing effort.
The scale is true to the original. I did this with three.js webgpu. I started working on the project about 2 years ago with webgl2. However, since the last six months I have brought everything to webgpu and used the opportunity to give the whole project a complete overhaul. The three.js webgpu node system has clear advantages over webgl.
As I said, there is still a lot to do, but with the current status, Mars can already be experienced.
Unfortunately, the atmosphere is quite computationally intensive so the app is better used on a PC.
To fly faster, hold down the space key and use WASD and the arrow keys to steer
This is an amazing depiction of Mars! You can see the details all the way from space to ground level. There is a mid-range height where the colors are a bit fuzzy (maybe a special filter would help?), but if you push all the way down, you can see an extreme level of detail at low level. I could almost swear I saw the Mars Rover.
I’m interested to check this out but you might to offer a lower-graphics option or improve the shader. Opening the page on my 2021 M1 Macbook Pro freezes Chrome and then the page loses the graphics context.
I really liked it. When I got close enough to Mars I could start doing a fly-by, and it worked very well. I thought I was gonna end up finding one of those Rover’s that Nasa sent there several years ago… lol Nice job!!
Thanks olavodias, yes I had to think about the Mars rovers too. There are currently 528,471 maps in the app, which together make up 18.6 GB. Perhaps an even more detailed Mars can be created from the HIRISE maps, because the app is much more powerful. But I have to do some research first.
Not sure if this might help you with Apples but, unrelated to Chrome, the Safari browser is complaining about unknown variable SharedArrayBuffer. As a wild guess, accepting the terms in order to start the app might probably be related to enabling this shared buffer (or it might just be tracking cookies since Safari suggested that it blocked 2 sites from tracking - EDIT: this appears to be coming from the forum website itself).
Ah, that’s something. The sharedArrayBuffers are indeed a tricky matter. These are very efficient tools for handling masses of data. Unfortunately, the Specter meltdown a few years ago meant that the sharedArrayBuffers were blocked by browsers by default if the servers did not use cross origin isolation. But I did that because otherwise the app wouldn’t run at all.
I first got exactly these error messages when I hadn’t yet activated cross origin isolation. This means the workers are blocked by the system because of the sharedArrayBuffers. Do Macs need additional CORS settings on the server? I’ll have to research that. I use Ubuntu on my desktop, Android on my tablet, and Windows on my laptop where the app runs in Chrome and Edge.
I just tested this for the first time with the Windows laptop. An HP Elitebook 850 G8. It is not a laptop with particularly high graphics performance.
I wrote the shaders all in wgsl. I think TSL is great, but if I need a lot of formulas I prefer WGSL because it allows mathematical symbols to be used, which makes it much more pleasant. I think three.js cannot translate WGSL into GL because there is no GL analogue for some things.
Unfortunately, the problem for Mac users are the sharedArrayBuffers and at the moment I don’t know how I could solve that
Some more info on SharedArrayBuffers usage in different browsers is available here, just to give you some idea at least.
Foot note number 3 should be applicable to Safari, not really sure why Chrome is having difficulties and whether SharedArrayBuffers are causing errors in it (or it might just be the high details as mentioned previously).
I tried to open this on an older macbook pro. First i saw some kind of a ring. Then the whole screen flashed red, then i saw the ring again and my browser froze
The license agreement is interesting, i think this is the only website where i had to agree to a license before seeing it. I hope i didn’t agree to give up all my possesions
This may be a problem in Safari but I’m running in Chrome (WebGPU isn’t supported in Safari, yet). I get the same issue as @dubois - the page displays the atmosphere ring and then crashes, so there must be something else going on.
I installed the license agreement primarily to prevent companies from using it without my consent. Unfortunately, I have had very negative experiences in the industry.
The ring you see at the beginning is part of the atmosphere. But if nothing happens, it’s because the sharedArrayBuffers are blocked.
@gkjohnson I wasn’t aware that Safari doesn’t support WebGPU. Unfortunately I don’t have a Mac. Is it possible that Chrome on the Mac prevents the use of sharedArrayBuffers in its flags?
Can you please look in your chrome when you enter chrome://flags in the browser and see what the following labels look like?
Experimental JavaScript shared memory features
Vulkan
Unsafe WebGPU Support
It could be that Chrome on the Mac does not yet support WebGPU to the same level as on other systems. If there are “Experimental JavaScript shared memory features” in chrome on the mac and are inactive then the sharedArrayBuffers are blocked. If you find these three parameters in the chrome://flags on the Mac and they are inactive, then that means that Chrome on the Mac with WebGPU is not yet as ready as on other systems. If these three parameters are inactive on the Mac then I am very curious to see whether it will work when you activate them. You don’t have to leave it active, just for testing.
The ring you see at the beginning is part of the atmosphere. But if nothing happens, it’s because the sharedArrayBuffers are blocked.
If it was just an invalid variable (eg SharedArrayBuffers was not available) then the page would just throw an error and log it in the console. But right now after starting the app the entire browser will freeze for quite awhile before crashing the page. When I tried it before all other graphics contexts in open tabs were also lost. There’s definitely something a bit more complicated going on here.
Is it possible that Chrome on the Mac prevents the use of sharedArrayBuffers in its flags?
SharedArrayBuffers are available in Chrome unless a script is loaded from a separate origin with the wrong headers set, afaik - I’m using them in my own projects, as well. They’re also available in the console when typing out SharedArrayBuffers.
Here’s what I see before the whole browser freezes:
