I am starting to work on a JME3 game which consists of a cube-based voxel world, a la Minecraft. I tried googling for voxel libraries in JME3, and pretty much everything I found was just people’s personal, half-baked projects but no finished, tested products with documentation and such. Maybe I just didn’t search well enough, and I missed something? If so, please let me know.
I did notice the TerraMonkey project and had a brief look at it. From what I can tell though, it is geared towards “realistic”, smooth terrain generation, and not designed for a block-based world. It also seemed like it was purely focused on the graphics end of things, and wouldn’t be of any help in the actual voxel storage and other backend stuff. Am I wrong?
If there are no voxel libraries readily available and I will need to start my own from scratch, I have two key concerns:
Raw data management: I will be loading up finite, but relatively large worlds. The world volumes will be a few dozen million voxels at minimum, but I would definitely like to have more then that even, somewhere up in the few hundred million if possible. While this isn’t a preposterous amount of data, it’s big enough that I a guessing I will need to be careful about how I handle my data, or else I will run into major efficiency issues. What sort of tutorials or resources should I be going to, to learn how to handle data in this fashion?
Rendering efficiency: While I am familiar with the basic graphics concepts, I don’t have any real experience in producing something that can render a complex scene at a reasonable framerate. For example, In the early tests I’ve been writing, I can’t create shadows on relatively simple scenes without major FPS reduction (400 - 500 FPS without shadows, to 10 FPS with). Is there comprehensive documentation somewhere on how to properly optimize a scene? Culling invisible geometry, messing with accuracy and render settings, optimal use of hierarchical nodes, etc.
If anyone has any other recommendations on materials to look at or libraries that may be of use to me, then please let me know. All advice is appreciated.
@seizure said:
If there are no voxel libraries readily available and I will need to start my own from scratch, I have two key concerns:
Raw data management: I will be loading up finite, but relatively large worlds. The world volumes will be a few dozen million voxels at minimum, but I would definitely like to have more then that even, somewhere up in the few hundred million if possible. While this isn’t a preposterous amount of data, it’s big enough that I a guessing I will need to be careful about how I handle my data, or else I will run into major efficiency issues. What sort of tutorials or resources should I be going to, to learn how to handle data in this fashion?
Rendering efficiency: While I am familiar with the basic graphics concepts, I don’t have any real experience in producing something that can render a complex scene at a reasonable framerate. For example, In the early tests I’ve been writing, I can’t create shadows on relatively simple scenes without major FPS reduction (400 - 500 FPS without shadows, to 10 FPS with). Is there comprehensive documentation somewhere on how to properly optimize a scene? Culling invisible geometry, messing with accuracy and render settings, optimal use of hierarchical nodes, etc.
Datamanagement: Consider that 100million voxels already take up 4gb of space in the very best case (storing only 32 bit per voxel).
It seems sparse octrees are used for storing large sets of voxel data. At least i read that.
Rendering: Shadowing is always a problem. Your performance is not really normal however, There must be something else going on in your example.
Culling: JME uses frustum culling. Occlusion culling is not that easy to write to actually gain some performance in common 3d environments. In a voxel world however there might be something possible
Optimisations:
Batch the geometry in small chunks.
Voxels != Cubes!!!
Use a TextureAtlas
General:
Drawcalls are very bad in jme3. So You really have to limit the amount.
Each shadow casting lightsource requires a whole rerender of the scene.
Each lightsource requires a whole rerender of the scene.
And the common footer:
Even if a voxel world looks simple, it is not under the hood. Some rumors say that they are fairly more complex than a “common” 3d scene.
I have no doubt about the complexity of a voxel world… It’s because of this complexity that I was hoping to find some pre-built libraries to aid me. And I am well aware voxels != cubes. Hence why I specified a block-based, voxel environment, implying both.
Not every single space will actually contain data (“air” blocks), and I think I can probably get the vast majority of the voxels within a world to contain just a couple bytes (non-entity voxels, such as terrain blocks, don’t need to store unique per-voxel data) but yes, it certainly is a staggering amount of data… having said that, my game is heavily inspired by one which already exists, and deals with voxel volumes in the range I am speaking of, so I am sure it is doable. Just a matter of how… I will look into sparse octrees.
@seizure said:
And I am well aware voxels != cubes.
What he meant is that when you generate a ‘block world’ mesh you aren’t generating cubes/boxes/anything of the sort. You are generating the visible quads.
Effectively, block worlds are made of quads and not blocks.
Also, I’m not sure what you searched for before but if you search the forum for “block world” then the first hit is about a library someone else has already put together.
Also, it’s worth saying in case there are any misconceptions…
Some people decide to do a block world because they think ‘simpler looking graphics’ must mean ‘easier game to make’. In fact, it is the exact opposite. Block world games are in most ways the hardest games to make because nothing standard will work. A game where you load up a scene, add some models, and do stuff is generally 1000x easier.
Without knowing your skill level, if you are anywhere near a beginner then I strongly suggest starting somewhere simpler.
@seizure said:
... aving said that, my game is heavily inspired by one which already exists, and deals with voxel volumes in the range I am speaking of, so I am sure it is doable.
Which game?
For example, Minecraft deals with the world in small chunks that are compressed… but otherwise nothing spectacular as I recall. I’m sure on google can you literally trip over articles on how that was done.
Mythruna chops up its world in 32x32x32 pieces and vertically run-length encodes them. Gzip can take it down even further if needed. I always end up loading a vertical set all at once so I’ve considered reducing the number of files but there are benefits to having entire 32x32x32 chunks as ‘empty’.
Well… that’s technically not true… so far, I have been using generic Box constructors because I’ve been lazy about converting everything into rendering individual quads… but yes, I understand what you mean, and am also aware of this… Aside from my rendering-specific queston, I meant blocks just as in… blocks. Like in MC. I wasn’t talking about geometry… At any rate!
My reason for storing it as a voxel world is for data and design purposes, certainly not graphics. I am definitely beyond “beginner”, though I am sure you hear that all the time, so I have no idea what simply saying that is worth. Either way, I am pretty dead-set on this project I have in mind. I’m not looking to make a generic hobby game for funsies.
My world is different from MC in that it is finite, and all portions of the loaded world which are “discovered” by the player are constantly polled for various calculations, so in theory, if a player uncovered the whole world, every voxel would be called on for calculations.
As daunting as this seems, I know it is possible, because I have seen it implemented. To answer your question, Dwarf Fortress is what I am referring to. The game noticeably slows down when asked to work with extremely large volumes, or when a very large number of CPU-intensive entities exist in the world, but it definitely works!
Anyways, the link you supplied to Block World seems to be precisely what I am looking for! I am guessing this is the most mature project of the sort out there at the moment then? Much thanks for the pointer. I’m not sure how I missed it either, but I’m glad I came here to ask if I had missed something!
It’s worth nothing that HUGE, contiguous portions of the voxel world will contain identical data (mostly due to how I expect to be producing stone layers), which I am sure lends its self to some serious compression, so it is possible that this helps to keep such huge volumes loaded in at once?
