The aim of “VirtualWorld3d” is simple – to make it easy for users in interact in a 3d environment on the web. We want to make it easy for people to create their own 3d worlds using a simple block based interface (think “Lego” / “Minecraft”). We want the worlds to be accessible from anywhere with just a web-browser. Sharing worlds will be as simple as sharing a web address.
“VirtualWorld3d” is very much a hobby project but with big-ambitions, this is not our main job (maybe one-day) and we invest our own time and money to make it happen.
- Page Load times – The page load times were a limiting factor, on slower desktops and mobiles we were finding page load times in excess of 10 seconds. This was not good enough, we want the worlds to open as quickly as any other web page.
Whilst looking for solutions to these problems we became aware of the incredible cross-browser developments in the area of WebAssembly. It rapidly became apparent that if this technology lived up to the “hype” then it could be the answer to all of our problems.
The “WebAssembly” version of “VirtualWorld3d” was born.
An early preview of the WebAssembly version of ‘VirtualWorld3d” can be found at VirtualWorld3d
The New Architecture
Improvements in Page Load Time
The new architecture gave us a double “win” in the area of page load times:
- The move away from external libraries (e.g. Three.js) meant that we could focus on only the functionality that we needed and so the size of the libraries got much smaller. Which meant quicker download and compilation times – WIN 1.
This means that in our latest version we can get a world up and running in a couple of seconds, even on slow devices.
A significant amount of profiling was performed on our application and it was found that three aspects in particular were contributing to our performance issues:
- Lighting (Ambient Occlusion) – “VirtualWorld3d” uses an ambient occlusion style lighting algorithm, that is why things get darker when you are indoors or when there are a lot of objects around. This also needs a significant number of calculations, especially when changing the map (we seemed to get around a 6 times improvement in performance when we move to WebAssembly).
- Triangle Culling – The block style nature of “VirtualWorld3d” means that the whole thing revolves around triangle culling, if you place two bocks together then you can get rid of the triangles for the sides facing each other which cannot possibly visible. Without this algorithm, the number of triangle would be far too high to be workable by the graphics hardware. This again involves a significant number of calculations, particularly when editing the map. Again we saw a roughly 6 times improvement in this when we moved to WebAssembly.
Using these improvements we have been able to relatively easily achieve 30 frames per second event on modest hardware and without needing a complex “WebWorker” setup. We are really looking forward to the Threads API for WebAssembly becoming available cross-browser.