But, for those thinking they're going to make a minecraft clone with this it's not going to work. Making games is all about drawing as little as possible and making as few draw calls as possible. Since CSS only supports planes (3d rectangles oriented in space) that means every cube is 6 draw calls and worse, if you want the browser to draw them correctly they have to be sorted. So let's say you had a 16x16x16 voxel area, that's potentially 24000 planes+ and 24000+ draw calls. That assumes worst case, all cubes with transparent bits like tree leaf blocks. For comparison many AAA games do little than 5000 draw calls per frame, possibly less.
Compare to a functional minecraft clone all of that would be condensed into a single mesh representing a 16x16x16 area. One draw call.
So yea, neat demo but you're going to quickly hit the limits past a few boxy logos
If you're looking for something that actually does do the optimizations necessary for a minecraft clone in the browser see http://voxeljs.com
Unity3D also has WebGL support, and is surprisingly quick for having a full physics and high quality rendering engine where you can build in C#. That would allow you to make a MineCraft clone that runs natively in the browser, and because it's Unity (a fully grown game dev environment) you will not have to reinvent any wheels or worry about many edge cases.
The really hard part about MineCraft isn't rendering, though; it's multiplayer.
As someone with two Unity WebGL games in production, I wouldn't recommend this route. A fairly small game (~20kloc, so not a toy by any stretch, but small nonetheless) has 26mb of JavaScript code exported This kills the browser.
Only good desktop or laptop machines can run it well. Runs like shit on average machines (lets not even mention mobile). This is after several months of dedicated optimization time to reduce resource usage and minimize build size.
Overall, you are faaaar better off writing it in JavaScript with one of the pure js engines if you are going to go this route.
Can't upvote this comment enough. I'm also currently in the process of creating a full featured WebGL game, and nothing is faster than simply using pure JavaScript there. Most people won't accept this, but when you ask them, those never actually tried creating a complex WebGL game.
These are totally fine most of the time. Typescript in particular looks like a good choice for game development.
Sometimes the language is less of a good choice. E.g. i did a small toy project in coffeescript about two years ago, and found to my horror, that if your function ended in a loop, it would return an array. Always. This isn't possible to accidentally do in the host language, so I'd say it is a bad fit (for game development, where you care about such things).
I believe that point is that JS always returns something for every object. Many users of JS just don't realize it. (I know I didn't till I started drinking the coffee flavored kool-aid)
This is probably as a result of CoffeeScript's Ruby-esque syntax and semantics. It does mean you can write some very clear and succinct code at times, but the tradeoff is that it can have unforeseen performance implications.
They don't add much overhead during runtime; most of the time there is zero overhead, or sometimes they can (theoretically, not sure if it's done in practice) produce more optimal code than a "literal translation".
It depends on the language. TypeScript is basically JavaScript with added bits. Unity compiles to JavaScript, but it does so through a crazy chain of C# -> CIL (via Mono) -> C++ (via il2cpp) -> JavaScript (via Emscripten). And then remember that your browser then converts that JavaScript to assembly. Holy convoluted toolchain, batman.
There's also the alternative of using C/C++ for portability and performance, but without a huge engine runtime you'll have to drag along.
There is no inherent size advantage of doing things in Javascript vs. cross-compiled to asm.js. For instance, three.js is 100kByte minified and compressed, that's in the same ballpark as the (admittedly simple) demos here: http://floooh.github.io/oryol/
Once you are over the static overhead for the C runtime and web-API-wrappers of roughly 30..50kByte, emscripten demos don't grow much faster than minified and compressed Javascript code.
If you write in C you are probably fine for code size. Usage of the c++ stdlib can easily cause a lot of code bloat though if you are not careful, but I don't actually know how bad this gets (it used to be quite bad for native apps).
There are other issues as well. The biggest offender being the inflexible heap size, e.g. when you launch an asm.js module, you pass in an array buffer as the heap which cannot be resized. If you need more memory than this, you are SOL.
This wouldn't be that bad, except in practice it needs to be ridiculously small if you want to run on most machines. 256MB, which not much memory for a game at all, will fail to allocate, or kill the tab on about 33% of machines (being generous. For us its probably more like 50% of machines, but we make educational games that need to run on university machines, which are uh, on the lower end).
Either way, as a result, a great deal of the optimization time I mentioned was spent getting all of our games to run with under 128MB heap.
That said it's definitely possible if you're careful (I'm not sure this is quite as true for a voxel game though, but I could be wrong). My complaint wasn't about the idea of using asm.js, it was the idea that Unity would produce a good result. It just doesn't.
Are there ready made engines suitable for this?
Unity has taken 11 years and Three.js 6 years to get to their current estabilished status, so let's keep fingers crossed that something gets started soon on the asm.js/emscripten front.
I think that's a bit of a chicken egg problem, the large game engines need to be everything to everybody, and trimming the executable size down probably wasn't a priority in the past since mostly you'll have a big upfront download anyway.
However, I remember that the first Unity HTML5/WebGL demos a few years ago were much smaller, a complete zombie FPS had a 3.5MB upfront download which is actually pretty decent.
How much of the 26mb JS is actually invoked at run-time?
I tested several real world web sites, like google search, github, google docs - only around 30% of javascript loaded into browser is actually invoked at run-time. Maybe in your case the usage ratio is much lower?
emscripten-compiled code already has a very aggressive dead-code elimination, so this wouldn't help I guess. It is most likely the cross-compiled Mono runtime plus required Unity modules which produce the code bloat on top of the actual game play code.
The emscripten dead code elimination uses static analysis which is limited only to the code totally impossible to be reached during execution even in theory. But POCL leaves only code which is actually invoked at run time (keeping all other code on server in the "load at first invocation" form). The difference may be very significant.
Google products (google docs for example) use Closure Compiler for dead code elimination, but anyway, after clicking almost every menu item in document editor, only around 45% of code was invoked.
If that 26mb web site was available online, I would be interested to measure it's code usage ratio.
BTW, the idea is not radically new. Java loads classes only when they are accessed first time.
Operating systems load native applications by mapping executable file into virtual memory. The pages are loaded into physical memory only when CPU tries to access them.
Ok yes, if there's a mechanism that dynamically loads the missing parts then it could work (actually emscripten supports dynamically loading scripts similar to DLLs). But 'naively' deleting functions from an asm.js blob would result in some 'unknown function' exception if the analysis was wrong and a removed function is still called somewhere.
Three.js is the main high level WebGL lib most people seem to be using, also for many MineCraft clones. It's not as web-hostile as Unity. Besides WebGL, it has renderers for CSS and 2D canvas too.
There are other actively developed Web-friendly WebGL frameworks, like Goo Create, PlayCanvas, BabylonJS and many more.
In most arena-shooter-type games, you don't need 32x memory for 32x players, because the per-player state is fairly constrained and known. (Often limited to how many projectiles they can keep in the air at once.)
I suspect Minecraft has a much harsher profile, since it's possible for every player to be loading a different piece of the world with minimal overlap, and world-pieces involve a lot more state that needs to be preserved/calculated/saved.
Much of the persistent world-state in Minecraft consists of blocks laid out on a 3D grid, which are probably fairly easy to optimise. Compare this to other 3D games where there are lots of entities with dynamic physics that can move to just about any world position, and I think Minecraft would be the easier of the two.
Also I'm not sure how Minecraft handles it (I assume it pretty much ignores it, or does something very naive), but in FPS games you need to take into account latency and do predictions on the client side to minimise it.
Think of two players running towards each other, and shooting at each other. By the time the player (or even the server) receives the data saying the other player has fired their gun, they've both moved to completely different positions.
(There is a good set of articles on this by a game developer, I can't find them now)
There was a bunch of Source-engine stuff Valve published, which is usually my go-to citation when arguing with players who don't understand "netcode" for a game but criticize it for not giving them perfect instantaneous communication anyway. :p
Most of that state only has to exist on the server, which in turn doesn't really have to figure out visibility and doesn't necessarily even need textures.
The world pieces are a very specific set of permutations, which could easily be loaded in to a graphics card's memory at the start of the game. All you are really tracking are which pieces are where, and by the game's nature, there aren't that many pieces or positions they can be in...
If each of those stacked divs represents the faces of all the 16x16 cubes in that plane, then you'd only need 48 draw calls in total. The hard part would be baking the cube textures in to a giant 'megatexture' the first place, but that could be prerendered if you didn't need animation. You'd actually need 96 images because each 'layer' would need 2 sides, but I don't see why it wouldn't work.
Imagine doing the other sides of the cubes. Now orthogonal layers will be intersecting. There's no correct order in which to draw intersecting polygons. You either need to split them (and then you're back to where you started), or you need Z-buffering.
You _can_ actually do this with just one quad per plane (or maybe 2 quads - one for the front face and one for the back face)... although you're right that you can't do it using CSS (yet).
A few years back, I wrote a tech-demo^W game for Ludum Dare (http://ludumdare.com/) based on using GLSL shaders to ray cast within a cube containing voxels. I then used these cubes as 3D "sprites" for the game.
Honestly I don't understand the craze of wanting to put EVERYTHING in a browser. I'm sure in many cases (for game development at least) it's easier to do it native, not to mention a tonne faster and less resource-intensive.
Heck, I'd even go so far as to venture that Java webapps run better than WebGL+JS. Perhaps I'm just biased/bitter because the open source radeon driver does nothing good by way of 3D acceleration.
It's not about the technology but about the simple distribution model.
I upload a WebGL demo to github-pages, and publish the URL.
I don't have to worry about code-signing, app-review-process, and don't need to wait days or weeks until the code is 'up'. For iOS this is the only way to get simple demos out.
Users only need to know a URL, they don't need to download or install stuff, they don't need to find the executable after installing, there are no scare-dialogs about installing unsafe executables, no virus scanner warnings, etc...
If your game is in the browser then I run it in a sandbox which I trust (if you're using native web technologies as opposed to a java 'webapp'). I don't need any storage on my local machine and when you make a change I just 'update' by refreshing my page.
And it doesn't matter if i'm running it on a phone, tv, desktop, laptop, x86, ARM, windows, linux, mac, etc...
It removes all of those from the equation, web tech will be available on most platforms i want to use, so i'm free to choose the best for what i want without worrying if a ton of my software is supported.
Except all of those have vastly different methods of interacting with your web app. A responsive website can handle the more similar methods of interaction that a desktop, laptop, and mobile devices rely on with slight tweaks to account for a fingertip vs a mouse, but trying to run a similar application on a TV will be an exercise in user frustration.
I'm not saying you get magical interaction for free, but i've written a toy web app that works fine on my tv.
The arrow buttons on the remote act as up/down/left/right and the "OK" button acts as enter. It actually ended up needing very little in the way of custom code to work, but like i said this was a pretty small toy app.
Still, if you want an example of a real "web app" that runs on all of those platforms, just look at netflix.
Though in fairness, Netflix hasn't historically bee based on native web tech; it used to be Microsoft Silverlight for web browsers (I think they've gone/are going HTML5 now), and even now it's native apps for mobile devices/smart tvs/etc.
>> Honestly I don't understand the craze of wanting to put EVERYTHING in a browser.
Web is an amazing distribution channel. The whole world is a click away from using whatever you build. Think about how technology distribution evolved in the last few years.. We used to buy Encarta/encyclopedia from a retailer. Now, with the web, you get the whole encarta (and more) with a click.
Seriously, I just wasted an hour trying to get Hetzner's KVM java web app to run on my Mac, because after having a couple of tickets closed and finally calling support directly, I was told firmly that the applet was from a third party vendor over whom they had no control, there was no other alternative, and they had no plans to support a better way to access the KVM.
I had to use Safari instead of Chrome, then CAREFULLY upgrade Java making sure Oracle didn't trick me into installing any toolbars, then find the Java control panel in the system preferences, which was just too awesome to be constrained by the limited confines of the Mac system preferences windows, so I had to read about how "The Java Control Panel opens in a separate window" because obviously it is so much more important than all other control panels, so I then pressed the "Reopen the Java Control Panel" button, which did what it promised after a half second pause, then I had to click around to the Security tab to find the Exception Site List, press the "Edit Site List..." button to bring up the "Exception Site List" dialog in all its glory and splendor, then press the "Add" button, then type an https url with a numeric ip address and port number into the field, then click a long series of "OK" buttons window close icons, then go back to the web browser, refresh the page, click through another series of threatening warning dialogs, to finally get a bottom of the barrel KVM applet.
And it was convinced I was using a German keyboard, so I couldn't find the punctuation characters I needed to type shell commands, and the Z and Y keys were switched. I had to press and shift-press every key to make a little table of substitutions, and then punch each character in carefully instead of touch typing.
One new thing I found during my Java adventure: the system Java control panel has an "Advanced" tab, and if you scroll way down to the bottom, there is a checkbox labeled "Suppress sponsor offers when installing or updating Java". It was un-checked by default of course. I suspect it's not actually hooked up, it's just a placebo, and exists to make me lower my guard next time I install a Java update. I'm not falling for it.
It really is about the ease of distribution with the web and the ease of development. Building production ready Java can be a nightmare. Not everything should be on the web but I am excited by this new library.
You could probably still do that with CSS and JS. You just have to detach your quads from the DOM when you know that they won't be visible.
Also as long as you use `backface-visibility: hidden`, then any cube faces that are turned away from the viewport get passed over after a very initial fast check.
Don't get me wrong: this is cool. It just makes me sad the performance is so night vs day on Firefox vs Chrome (Nightly and Dev branch on Linux). The former is glitchy (some planes are rendered when they should be hidden behind other geometry?) and stutters.
It's even sadder that even in Chrome the FPS is noticeably low. This isn't a gaming rig, it's just an Intel card, but it can run plenty of games (at 40+ FPS) from the past five years that are drawing far more than this demo, and reacting to far more inputs.
In principle I love the idea that we could write everything to be portable across OSs and form factors by writing for 'the browser', but still at this point, on this modern computer, the performance is noticeably worse, and ultimately lackluster.
It's the same story on mobile, and not just limited to GPU-bound applications, despite the prevalence of web tech in that space. At the end of the day all of this 'write it for the browser' just translates to using far more CPU cycles than putting in the effort for 'native'.
Simmer down comment section. So what if it's not the most perfect thing ever. This is neat. Good job by all that worked on it. I'll bet they learned a lot in the process and had fun doing it. thanks for sharing it with us.
Tridiv [1] is something cool to check out as well, really cool concept taken to a crazy complex level. It's an actual editor for making complete 3D models in the browser. I wonder if something of the complexity of the X-wing model [2] could be used with voxel css to make a flexible game engine.
Looks like this jsfiddle just doesn't do per-pixel z-sorting (which I wouldn't have expected from browser 3D effects) but in my brain that shouldn't be an issue with cubes (no polygons overlapping).
Locked up my iPhone 4 when I scrolled down to the spinning cubes (in Safari). Eventually after about 10 minutes of being completely unresponsive, it rebooted. No judgment, just reporting what happened when viewing on a phone.
This is definitely an impressive demo. I wonder if 3D will begin to be used a lot more in websites and mobile sites in the next few years.
We just celebrated our 4 millionth user with a 3D visualization of all our users. It uses canvas to draw instead of css, but I think it is one of the best ways to convey a feeling of our global userbase actually using the app. I'm curious what you think of its "3d performance":
Congratulations on 4 million users! The visualization works really well, IMO.
A couple thoughts on its implementation:
1) The dropdown list of countries is not alphabetized. Makes it difficult to find reviews from a given country, although it does make you use the map:)
2) If you click on a country that doesn't have a review, it produces a blank, instead of the country name and flag with no reviews.
Here's a cool project to efficiently and flexibly implement minecraft-like games in the browser in JavaScript/WebGL. It's built out of a bunch of NPM Node modules with browserify.
In the video at the top of the page, Max Ogden's presentation is fantastic and well worth watching! He did a survey of many other similar projects on github, and built on top of the best ideas from them all.
SketchUp[1] is built for ease of use for in mind for people who are not 3D pros but there's actually quite a lot of clever things going on under the hood[2] so it would not be a weekend project to reimplement. But yes, a web based clone would be awesome.
[1] It's now owned/developed by Trimble, Google sold it to them ~4 years ago
Voxels are the most expensive way to model a 3D shape, and browser CSS is the slowest way to render a 3D shape. These two were made for each other. The next step is to reimplement the Mars DOS demo [1] using voxels in the browser, and marvel at the slowdown compared to 1993. It's discouraging that we're supposed to cheer for progress even when it's headed backwards.
I love when you guys come into a thread about web tech and dump on it.
Web tech isn't "going backwards" any more than a flag-ship phone is "going backwards" because it's not as powerful as a high end desktop PC.
They solve different problems.
A browser based program is sandboxed, can be instantly "downloaded and installed", runs on all architectures, runs on all major platforms, runs on both desktops, laptops, phones, tvs, and anything else that you can run a browser on.
And even if it was verifiably worse in every single technical way, it could STILL be "progress" if it's easier to use than the alternative.
Zero installation at the cost of 10x worse performance is a worthwhile tradeoff for websites, but not for games or other 3D-heavy applications. That won't change as computers get faster, because native apps get faster too. Web 3D won't be widely adopted until it can close the performance gap. The OP makes that problem worse, not better. Hence my negativity.
Bullshit that web 3d won't be adopted. It already is! Google maps uses web 3d pretty heavily already, and it's a perfect example of this.
But even if i concede that point, i still don't agree. Who are you to say that this doesn't solve any problems?
Say for example a website that wants to include something so you can view a product in 3d and be able to move it around and inspect it.
That's not something i want to have to download a full desktop program for and give it access to god knows what on my machine for, but it's something i'd love to have to see a 3d render of something to get an idea for it's size/shape/other features.
OP isn't even marketing it as a library for "games or other 3D-heavy applications", he's marketing it as a really easy way to get some 3D rendering in the browser.
But, for those thinking they're going to make a minecraft clone with this it's not going to work. Making games is all about drawing as little as possible and making as few draw calls as possible. Since CSS only supports planes (3d rectangles oriented in space) that means every cube is 6 draw calls and worse, if you want the browser to draw them correctly they have to be sorted. So let's say you had a 16x16x16 voxel area, that's potentially 24000 planes+ and 24000+ draw calls. That assumes worst case, all cubes with transparent bits like tree leaf blocks. For comparison many AAA games do little than 5000 draw calls per frame, possibly less.
Compare to a functional minecraft clone all of that would be condensed into a single mesh representing a 16x16x16 area. One draw call.
So yea, neat demo but you're going to quickly hit the limits past a few boxy logos
If you're looking for something that actually does do the optimizations necessary for a minecraft clone in the browser see http://voxeljs.com