Help optimizing voxel terrain

Hello everyone! I like to program java a lot and always been fascinated by voxel games, which inspired me to make my own. I used to use LibGDX for 3d programming but for this I decided to use JMonkeyEngine3. I didn’t really know much about voxel engines in jMe3 so I researched on the forums to make a test.

The only problem is that compared to other voxel engines it is really laggy (even with a single chunk loaded). So far it does not render the faces of a voxel that is not visible, which reduced the amount of triangles greatly.

(Sorry if the code or this question is bad, i’m new to jMonkeyEngine3 and it’s community)
Does anyone know if I can optimize this and how?

you just make 0 optimizations. For exemple, you create a geometry per side, even if you use the geometrybatchnode later, it’s still huge. But this is only for the creation.
Things i didn’t see are:

  1. how you create material ? I quickly checked your code and i don’t see where it is. But remember that the batching can only merge similar material, so if you create a new material per tile you just have 0 merging.
  2. Do you remove un-visible faces ? For exemple, face-to-face faces will never be visible and should be removed.
  3. do you use a texture-atlas ? if no, you can optimize squares of similare cubes and “play” with textures coordinates to obtain the same effect with less quads.
  4. you shouldn’t create a lot of geometries and merge them after, you should instead create the final geometry directly.
  5. there is already some good voxel library out there. If you want to create your own just to reinvent the wheel and train yourself, why not. But if you plan to create a real voxel game, then you should jump directly to an existing library as you’ll likely have a better implementation and you’ll not have to maintain it yourself and you’ll be able to go to the next step directly (the game). This “logic” leads you there (you didn’t create your own 3D render engine, did you ?).
@bubuche said: you just make 0 optimizations. For exemple, you create a geometry per side, even if you use the geometrybatchnode later, it's still huge. But this is only for the creation. Things i didn't see are: 1) how you create material ? I quickly checked your code and i don't see where it is. But remember that the batching can only merge similar material, so if you create a new material per tile you just have 0 merging. 2) Do you remove un-visible faces ? For exemple, face-to-face faces will never be visible and should be removed. 3) do you use a texture-atlas ? if no, you can optimize squares of similare cubes and "play" with textures coordinates to obtain the same effect with less quads. 4) you shouldn't create a lot of geometries and merge them after, you should instead create the final geometry directly. 5) there is already some good voxel library out there. If you want to create your own just to reinvent the wheel and train yourself, why not. But if you plan to create a real voxel game, then you should jump directly to an existing library as you'll likely have a better implementation and you'll not have to maintain it yourself and you'll be able to go to the next step directly (the game). This "logic" leads you there (you didn't create your own 3D render engine, did you ?).
  1. I use my own class to save materials for a block type so each block uses the same material.
  2. For un-visible faces I do detatchFromParent();

I’ll try 3 and 4 and if it doesn’t work i’ll try 5.

How many objects do the stats show your scene has? That will show you if the batching is doing anything for you.

Rendering as wireframe can also show you if you are removing all hidden faces properly.

I keep visiting threads which say ‘voxel’, hoping that somebody will be implementing stuff like http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html - but it always turns out that by ‘voxel’ people mean ‘minecraft clone’…

2 Likes
@abies said: I keep visiting threads which say 'voxel', hoping that somebody will be implementing stuff like http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html - but it always turns out that by 'voxel' people mean 'minecraft clone'...

I agree, but both terrains are generated in the same way aren’t they…
Also, incase you haven’t seen this on "the toucher"s blog http://mtheorygame.com/2012/04/02/3-part-adventure/

@javagame said: I agree, but both terrains are generated in the same way aren't they..

…not even close.

Actually, I was doing something along these lines myself. You can take a look at my Github project if you want some help:

[NO LONGER EXISTS]

My terrain is only color-based - i didn’t integrate textures, but it shouldn’t be too hard if you want to work on something like mine.

EDIT: thought I should explain some more. Occlusion culling is working perfectly, and the chunks only recalculate the geometry whenever something in a chunk is changed.

The problem with this is that I haven’t yet figured out a way to include dynamically-changing voxels with this system, like a rainbow-colored one, that changes color constantly.

The work-around currently is to have the chunk update its mesh every single frame by changing something every frame, but that costs a LOT of performance and is BAD. 4 chunks drop my computer (fairly new, pretty awesome) to 46 fps, whereas without the workaround, I can have around 128 chunks at 60 fps.

My engine doesn’t like textures too much, as each chunk has its own material, so if you made textures, you’d be limited to only one texture per chunk. This leads to minecraft-like texture pages, with the grid of textures. I suppose if you created a system like the new one in minecraft, where a folder of textures are packed into a single file and parameters are generated from it, then you could have as many textures as you wanted.

@pspeed said: ...not even close.

EDIT: Voxel terrain is just non heightmapped isn’t it? both kinds are generated on the GPU and store data for under the terrain as well as the surface… I was under the impression the cube kind of voxel terrain was made using just the start of this http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html

How wrong am i?

Edit: I know what I mean…

@javagame said: EDIT: Voxel terrain is just non heightmapped isn't it? both kinds are generated on the GPU and store data for under the terrain as well as the surface.. I was under the impression the cube kind of voxel terrain was made using just the start of this http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html

How wrong am i?

Edit: I know what I mean…

Block worlds are not generated on the GPU. They are generated on the CPU… typically by looking at the surrounding cells to see if a side is visible or not.

Isosurfaces like in that link are WAY different.

@abies said: I keep visiting threads which say 'voxel', hoping that somebody will be implementing stuff like http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html - but it always turns out that by 'voxel' people mean 'minecraft clone'...

If you haven’t seen the demo by thetoucher you really should, it blew my mind :slight_smile:

http://hub.jmonkeyengine.org/forum/topic/terrain-side-project-video-updated-with-3-adventure-videos/

You could probably pick up some pointers from here:
http://hub.jmonkeyengine.org/forum/topic/cubes-a-block-world-framework/

Also just search for things like voxel, minecraft and blockworld on this forum and you’ll have plenty of reading material.