WebGL Meincraft | Hacker News Reader

WebGL Meincraft

dev.pocoo.org

46 pointsllambda20 comments

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.

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 ;(

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.

Also because web workers don't work great yet.

> 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.

Hello both my cpu cores pegged at 100%.

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.

That's an awfully heavyweight approach to something that can be solved just as well using the existing CPU affinity functionality of your OS.

Was this done with 3D perlin noise?

Give us some technical details of the project please.

It's perlin simplex noise and there will be a longer blog post about how it works. It's just work in progress :-)

Hooray for floating islands! (seriously, I love that these exist in M(ine|ein)craft. It makes the world a lot more interesting)

Very CPU heavy. For those wondering, it does work, it just takes a while for anything to appear.

You should prevent propagation of up/down arrow key events in the game canvas, which (I believe) cause the browser window to scroll up/down.

Pretty sweet! Can't wait for the details

completely non responsive, did not finish rendering first scene after waiting for about 4 minutes.

Reply on news.ycombinator.com