Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Reduce the polys in a voxel engine?  (Read 433 times)
0 Members and 1 Guest are viewing this topic.
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Posted 2014-06-14 09:48:06 »

Hola! Cheesy

So, I've made a small voxel engine (Think minecraft) Which currently doesn't do much - it draws lots of cubes in a random pattern (hills and such) and these cubes are shaded in accordance to which direction the sun is shining in.

The game I'm going to create with this will be an RTS style game (think dwarf fortress..... kind of) so naturally the camera will be zoomed out.

The problem is that with an aerial view camera, you render so many more blocks than you normally would if you were to, say, play minecraft. I understand the concept of chunk loading, but with the amount of chunks that would be ideal to load, I've calculated I'll end up drawing 2.5 million tris !!!

I'm also not drawing faces of cubes which are touching eachother.

I've considered maybe combining some faces (currently everything is put into the computer as quads, but I believe it splits it up into triangles for the GPU), but because of the huge number of permutations you coul dhave with different numbers of combines faces, it would be impossible to combine the faces in such a way that it would be optimal AND not slow the game down in the process.

This is a quite considerable stopper to the development of the game, and it's only gonna get worse the more things I add, currently I'm just rendering blocks :'D Could anyone help me?Smiley

P.S I have the source in a zip file but for the life of me I can't figure out how to attatch it:(
Offline Hermasetas

Senior Devvie


Medals: 6
Projects: 2
Exp: 3 years


I do gamez, yes!


« Reply #1 - Posted 2014-06-14 09:55:56 »

One technique I have heard about is to batch multiple of the same bock type together and then drawing one big quad with GL_REPEAT turned on for wrapping the textures.

For example if you have a 3x3 area of the top of grass blocks then instead of drawing 9 quads you could draw one quad that covers them all and then just have the texture repeat 9 times.

Not sure how to implement this, but it would reduce the number of quads a lot Smiley
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #2 - Posted 2014-06-14 09:58:41 »

Mmm, I was thinking of that, but it would be the implementation i'd struggle with:(
I'd have no idea on how to go about it, or, more importantly, no idea how to go about combining them in an efficient way.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Bearded Cow

Senior Devvie


Medals: 2
Projects: 1
Exp: 1 year


¬..¬


« Reply #3 - Posted 2014-06-14 10:01:20 »

Will you be rendering the ones you can't see, with that calculation?
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #4 - Posted 2014-06-14 10:03:28 »

I don't understand?

Currently, I store all the cubes in a 3 dimensional array of integers. a different integer denotes a different block. When I come to placing the vertexes in the VBO, I first check whether the spaces adjacent to them are filled with air (0). if they are, I render that side.
Online NegativeZero

JGO Knight


Medals: 47
Projects: 2


Zero but not.


« Reply #5 - Posted 2014-06-14 10:12:22 »

One technique I have heard about is to batch multiple of the same bock type together and then drawing one big quad with GL_REPEAT turned on for wrapping the textures.

For example if you have a 3x3 area of the top of grass blocks then instead of drawing 9 quads you could draw one quad that covers them all and then just have the texture repeat 9 times.

Not sure how to implement this, but it would reduce the number of quads a lot Smiley

The process Hermasetas describes here if I am not mistaken is pretty much Quadtrees, which will speed things up when you have smooth landscapes. But if you're making a minecraft-like game, your terrain is going to be quite variable and this likely won't help.

If you're not already, upgrade to use VBOs and make sure you're breaking down into triangles before you send your geometry to the GPU.

As for what you said about the top-down perspective vs. first person, I think first person would cause a lot more lag than top down. With top down, you can predict how much you will be seeing at once, whereas with first person you can potentially see infinitely from the top of a mountain (except you can't because RAM). With top down, realistically you would only be rendering 4 * 4 chunks at a time max while still being able to see any units you control. Whereas in minecraft you can see like, 10 chunks in one direction with a good enough PC (meaning 400 chunks loaded).

If you plan on adding extremely large zoom, you're gonna have to look into LoD (level of detail).

Ultimately, were I you, I'd carry on and not worry too much about optimisation right now, and just come back to the relevant code IF you get too a point where it actually becomes a problem.
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #6 - Posted 2014-06-14 10:17:15 »

I'm already using interleaved VBOs Tongue

It's not really the level of zoom, it's just that if I make the blocks too large it looks awkward for anything to be moving up and down on.

If any of you have played cubeworld, he has extremely small voxels (In comparison to minecraft. You could probably fit about 8 into 1 minecraft block) but it runs beautifully. It's this size which I need to use, to make it look less awkward when a unit moves up or down one.
Offline Danny02
« Reply #7 - Posted 2014-06-14 10:21:39 »

take a look: http://0fps.net/2012/06/30/meshing-in-a-minecraft-game/
Offline ForeseenParadox

Senior Newbie


Medals: 1
Exp: 1 year



« Reply #8 - Posted 2014-06-14 10:24:16 »

I would suggest to use an IBO(index buffer object) if you're not already. Since you have a lot of blocks, an IBO would be useful. It basically reuses vertices that are used multiple times. So for example, you could represent a cube with 8 vertices instead of something like 36(3 * 2 * 6 = 36)
Offline Bearded Cow

Senior Devvie


Medals: 2
Projects: 1
Exp: 1 year


¬..¬


« Reply #9 - Posted 2014-06-14 10:27:59 »

I don't understand?

Currently, I store all the cubes in a 3 dimensional array of integers. a different integer denotes a different block. When I come to placing the vertexes in the VBO, I first check whether the spaces adjacent to them are filled with air (0). if they are, I render that side.

But what about as you're from a top-down view the blocks underneath blocks, you should forget about those.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #10 - Posted 2014-06-14 10:30:16 »

Hey Danny that's just what I needed, thanks!

Paradox, I was going to use IBOs but on the LWJGL wiki page they weren't really all that documented. That makes a lot of sense! But, won't you have to assign 1 colour to 1 vertex? Therefore having an awkward gradient? I currently modify the colours depending on the direction of the sun, if a face shares vertices then this might not work as well?

Sorry bearded cow, maybe I didn't clarify it enough - the camera is aerial, not top down, so you can rotate it:P
Offline ipe369

Junior Devvie


Medals: 3
Exp: 3 years



« Reply #11 - Posted 2014-06-17 11:26:19 »

I know this is quite an old thread, but for anyone else looking how to optimise an engine like this, danny's method is definitely the way to go. After implementing it, I can display more than 9 times the amount of faces I could before, without any drop in frame rate:O
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (36 views)
2014-12-15 09:26:44

Mr.CodeIt (29 views)
2014-12-14 19:50:38

BurntPizza (61 views)
2014-12-09 22:41:13

BurntPizza (98 views)
2014-12-08 04:46:31

JscottyBieshaar (58 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (76 views)
2014-11-29 21:32:03

toopeicgaming1999 (137 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (37 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!