Merging triangle faces!

WIP games, tools & toy projects Cube World Projects
#1

Hello! :slight_smile:
I need some help!
So basically, having an integer array of cube ids with the size of 16^3 and static method, which returns triangle vertices based on location given by array iterator. Feeding vbo with that data I get this mess:

http://img339.imageshack.us/img339/107/20130106211807.png

Nothing fancy but hereā€™s a problem Iā€™m struggling withā€¦
That chunk of cubes could also be rendered like this, providing that ids are the same:

http://img844.imageshack.us/img844/3886/20130106212005.png

Getting rid of cubes that are completely surrounded would be easy, but I still have a lot of verticies left that donā€™t have to be stored in memory. I need someoneā€™s help on algorithm that would ā€œmergeā€ verticies that share the same properties and kept triangle topology. (after trying it just got far too complex)

#2

Just getting rid of the faces that are hidden isnā€™t enough? Is having a tessellated cube that bad?

#3

http://dl.dropbox.com/u/99583484/3D/Sun%20Jan%2006%2019-00-03%20NZDT%202013.png

The only optimisation done here is to remove all the hidden faces. I still get >60 FPS

I donā€™t see why you need to optimise it that much. And that will just slow down the CPU when just one block is missing from the surface.

#4

Well it seems like a good way to increase performance, Iā€™ll stick to only face and frustrum culling for now.

http://img593.imageshack.us/img593/6066/20130106222009.png

#5

As someone whoā€™s spent a lot of time on a minecraft renderer, you probably just want to stick with removing internal edges and donā€™t bother with merging faces.

Itā€™s tempting when youā€™ve got a ā€˜simpleā€™ world, but as you add more and more gameplay it becomes progressively harder to manage. Itā€™s just too damn handy to do some thing per-vertex (eg. minecraft does itā€™s fake AO lighting via vertex colours), as well as making it easier to do texture atlas/layer tricks to get richer surface detail. And of course it means that you have to do more work when you change a single block in your world.

The biggest rendering drag I found was that even after frustrum culling a minecraft-style world has lots of underground caves that are still considered visible. That can mean youā€™re drawing twice or three times as many polys as you need. :frowning:

You should be able to do something about that with occlusion queries, but I never got around to trying it. Minecraft doesnā€™t IIRC, but thatā€™s probably because itā€™s awkward 16x16x128 world structure makes it a bad fit.

#6

What structure would you use as an alternative? Would it be a different AxBxC chunk or something different?

#7

I would probably have gone with 16x16x16 or 32x32x32 chunks and had some kind of sparse array in the height dimension, that would address the common complaint of the fixed build height.

Having said that it would make general streaming and caching more complicated. And the reason MC has chunks of 16x16x128 is a sound one - you canā€™t load faster than the player can fall, so it has to have the whole vertical slice loaded in case. So itā€™s only in hindsight that I think the chunk size is a bit awkward, and itā€™s not a huge problem really.