Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

lwjgl - Minecraft - Rendering 100k blocks @ 60fps

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 voodoodrul   Members   -  Reputation: 130


Posted 19 June 2012 - 01:57 PM

I know this has been done to death. Everyone and their brother wants to make a Minecraft clone and ask all the basic questions..

What I have here is a proof-of-concept renderer in lwjgl with primitive collision detection. I use vertex arrays to represent the blocks, each Block is rendered using static vertex arrays on the Block class, but no instance of Block is actually created. I compile display lists for each WorldChunk, I use frustum culling to decide which chunks to push to render, I use hidden surface removal to cut down on polys. Yet I can't get the performance I am looking for.

Check it out. https://voodoodrul.dyndns.org/CYDI-latest.jar - You will get a cert warning because I have to run over SSL and my cert is self-signed - you can ignore it. The JAR should just run - requires Windows and 64-bit Java

If you go into wireframe and disable display lists and press H - you will toggle hidden surface removal so you can see that it is working. It doesn't seem to offer much benefit, but it does work.

What do you guys think? I knew nothing about OpenGL 2 weeks ago - this is where I am so far.

G disables gravity, up arrow increases movement speed, down arrow decreases

Edited by voodoodrul, 04 July 2012 - 09:08 AM.


#2 Lunatix   Members   -  Reputation: 143


Posted 21 June 2012 - 10:39 AM

I've wirtten an own (voxel) terrain renderer, so i can say, the first thing what differs from your renderer is, that minecraft's blocks 3 times bigger than yours.
The secound thing is - for such big geometrical structures - use vertex buffer objects and calculate your geometry only once per change. Also play with the sizes - 32x128x32 is a good size. And be shure, that you only hold chunks in a viewrange + precache range in memory.

(If you are interrested in pics, click here https://www.facebook.com/pages/Luna-Game-Worx/286480244750104 ;)
You like voxels? Then you may like... http://gameworx.org/?p=36

#3 Wren   Members   -  Reputation: 111


Posted 28 June 2012 - 06:05 PM

Hi there,
like a lot of people here, I've also written a video renderer ;) runs at 60 fps with about 60 million blocks in view, most the time is spent on terrain generation.
I've got a single vertex buffer with positions and normals, which is shared by all chunks - each chunk has only an index buffer to bind when it's drawn. The chunk position is passed in as a uniform into the vertex shader to offset the positions.
The biggest performance boost you'll find is effective cross-chunk culling. Although I'm rendering millions of blocks, I'm never rendering more than a few hundred thousand faces. Each chunk only updates its buffer (and its neighbours') when its contents is changed.
Chunk size is also important. Too large, and you won't be able to use your generation time efficiently; too small and you might as well be drawing individual blocks. My chunks are 32^3, or about 30k blocks each, and they stack infinitely in all directions, so you can go as far up or down as you like.
It also helps to use any idle time you have to do generation. I haven't done this in my code, but when a chunk is requested but there isn't time to generate it you can push it to an idle queue, which you can generate when you next have spare time.
Hope that helps :) you can find my code on Github, just search for Bloxelcraft or Wren6991 if you'd like a look. It is in C++ though.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.