8 ms·

Cool demo. 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 pos

Cool demo. 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 http://voxeljs.com

LukeSolomon 11y ago
Well then make a pull request Mr. Fancypants
- yincrash 11y ago
  No pull request can make a project that is meant to implement voxels in CSS overcome the hindrance of implementing voxels in CSS.
ccvannorman 11y ago
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.
- cbsmith 11y ago
  Given its execution model, I'm not sure I'd agree that multiplayer is terribly hard in MineCraft. What is challenging about it?
  - Terr_ 11y ago
    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.
    - talldan 11y ago
      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.
      - lucaspiller 11y ago
        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)
        Terr_ 11y ago
        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 https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin... https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
onion2k 11y ago
Theoretically you only need one draw call per plane though, right? Imagine using a stack of divs like this: https://hcgilje.files.wordpress.com/2011/01/stack.png https://hcgilje.files.wordpress.com/2011/01/stack.png 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.
- balefrost 11y ago
  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.
  - maffydub 11y ago
    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/ 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. See http://matt-williams.github.io/ld29/ http://matt-williams.github.io/ld29/ for the game and http://ludumdare.com/compo/2014/04/28/voxel-map-algorithm/ http://ludumdare.com/compo/2014/04/28/voxel-map-algorithm/ for a write-up of the technology.
zzz6519003 11y ago
good to know that XD
mistercow 11y ago
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.
roddux 11y ago
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.
- oldmanjay 11y ago
  I hope your hobbies meet the arbitrary usefulness requirements of the dismissal squad.
- sleepychu 11y ago
  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.
  - Klathmon 11y ago
    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.
    - ascagnel_ 11y ago
      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.
      - Klathmon 11y ago

LukeSolomon 11y ago

Well then make a pull request Mr. Fancypants

yincrash 11y ago
No pull request can make a project that is meant to implement voxels in CSS overcome the hindrance of implementing voxels in CSS.

ccvannorman 11y ago

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.

cbsmith 11y ago
Given its execution model, I'm not sure I'd agree that multiplayer is terribly hard in MineCraft. What is challenging about it?
- Terr_ 11y ago
  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.
  - talldan 11y ago
    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.
    - lucaspiller 11y ago
      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)
      - Terr_ 11y ago
        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 https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin... https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...

onion2k 11y ago

Theoretically you only need one draw call per plane though, right? Imagine using a stack of divs like this: https://hcgilje.files.wordpress.com/2011/01/stack.png https://hcgilje.files.wordpress.com/2011/01/stack.png 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.

balefrost 11y ago
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.
- maffydub 11y ago
  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/ 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. See http://matt-williams.github.io/ld29/ http://matt-williams.github.io/ld29/ for the game and http://ludumdare.com/compo/2014/04/28/voxel-map-algorithm/ http://ludumdare.com/compo/2014/04/28/voxel-map-algorithm/ for a write-up of the technology.

zzz6519003 11y ago

good to know that XD

mistercow 11y ago

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.

roddux 11y ago

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.

oldmanjay 11y ago
I hope your hobbies meet the arbitrary usefulness requirements of the dismissal squad.
sleepychu 11y ago
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.
- Klathmon 11y ago
  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.
  - ascagnel_ 11y ago
    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.
    - Klathmon 11y ago