That seems nice but it's taking, also, all my CPU time on my windows machine. I don't get it, yesterday there was another WebGL demo on HN and it did exactly the same thing. Is that something which we have to live with in the future ? Is WebGL going to be too much CPU intensive, so much that nobody is going to be able to run that ? Or is this 'demo' asking too much of WebGL ?
The high CPU usage is expected because I spawn off four background workers that peg all your CPU. It's not intended for public consumption yet, so don't jump to conclusions.
When I have finished this it will perform better.
> Or is this 'demo' asking too much of WebGL?
The WebGL part is only half the story. It uses webworkers for the perlin noise generation and this is currently very slow in JavaScript.
This page consumed all the resources on my Late 2010 MBA pretty quickly. Not that the real minecraft runs well, but it's far more playable than this version.
Whether that's WebGL or the programming is something I don't know.
> This page consumed all the resources on my Late 2010 MBA pretty quickly. Not that the real minecraft runs well, but it's far more playable than this version.
Well. There are a couple of reasons for this. First of all: yes, it should keep 4 CPUs busy. I spawn of four background workers so it pretty much hogs everything.
That said, not only the world generation is slow right now, also the VBO generation is because I do some very conservative invalidation which causes some VBOs to be generated multiple times.
I have a lot of stuff that I can do to make this faster and my local version already performs better but I caused some bugs in the coordinate system conversion and my frustum culling. I have to iron this out first before I update the live demo.
This version (rendering wise) on my Mac does actually render faster than Minecraft at equal rendering distances.
This is how we were instructed to think about transforms, in school. I'm not sure how common it is, but I also believe that this is how XNA performs transforms. It has been two or more years since I have worked with XNA though.
If and when you write a blog post about this, I think it would me more interesting if you'd write about how you generate your vertex buffers and organize your draw calls, etc than describing the world generation algorithm.
Everyone, and their dog, have been writing Minecraft-style world rendering demos for a few years now and there are also quite a few blog posts that describe the world generation algorithm. They're always an interesting read, but I would be more interested in how you get that stuff to the GPU and how do you render it.
Also some insights about WebGL limitations would be welcome. Would your task have been easier if you could memory map your vertex buffers or use instanced draw calls? This is the kind of stuff I'd love to hear about as a graphics programmer.
Yeah, the world generation is not that interesting in my version anyways. The interesting stuff is how it uses web workers to move that into the background and how the VBOs are updated (or will be once I have finished that).
Both my cores were pegged but if you can get this to perform as good as Minecraft and turn it into a game I might buy it. Especially since us Linux users don't have as many good games to choose from.
I noticed something : when the viewpoint is lookint at a flying block wich is not that big, it's lagging the same as looking at the entire world. Is is rendering something in the background which is out of the view ? I'm not saying it's not a nice demo, actually I like the feeling very much. This perlin noise is pretty enjoyable. But I can't understand why it's that slow ;(
> I noticed something : when the viewpoint is lookint at a flying block wich is not that big, it's lagging the same as looking at the entire world. Is is rendering something in the background which is out of the view?
Yes it is. I have experimental frustum culling implemented but something with the coordinates is wrong and it starts to cull things it should not.
> But I can't understand why it's that slow ;(
Because it's work in progress and in many parts the implementation is just not finished yet. I need to fix the frustum culling, I have to improve the front to back rendering, have to switch to transferred objects for the web workers where possible, speed up the critical code paths and fix the Chrome performance bugs that come from too many VBO switches.
Doing a fast 3D engine is hard, even if most of the 3D is done for you. It's slow because it's simple, and because JavaScript is actually a fairly hard language to do some of this quickly in.
May I suggest running this in a Virtual Machine such as VirtualBox. Then you can control how many cores are pegged by how many you have assigned to the VM, and leave the rest of your machine responsive for other things.
