Terrain data storage

Hello,

I was wondering if someone could push me in the right direction. Not sure if this is in the right area either but i didnt see something for general questions.



i have been playing around with jME3 over the summer with what would become a dwarf fortress minecraft blend. This is really just a project to learn and keep up at least a shred of my programming skills (little as i am sure they are anyways).



anyways to the question: what sort of data structure or way of storing data is most efficient for storing or organizing the terrain data? ive been having problems finding posts as i am not sure what the keywords to search for them would be.



summary: planning on having a server - client setup ( as even if this is only ever used by me the networking is a topic i want to learn and play around with) so the server would obviously have the entire world stored someway. I have looked at “voxel” on the web but the definition leads me to believe this would be inefficient for large worlds (from what i understand the cubes dont carry placement data, position in the array/data struct does = large open areas waste ton of space)



I feel like this server might not be best run as a simple app like some of the tutorials have shown or even if it does that i will need to write my own classes for the terrain data. I dont know enough yet about jME3 to know if that is true.



should I be looking to write these classes myself or does jME3 have an efficient way of handling this? and in either way what are the keywords (jME3 classes) I should be searching with/looking at?



figure ive left tons of holes that will need answering so let me know what i need to clarify.



i understand the “box” worlds are hard ( and actually decided because of that i would jump strait to 3d instead of 2d to learn more) and have messed around with creating custom meshes of variable “box” sizes and can even remove / add the individual “boxes” that make up the single geometry. I have now turned my attention to the headless part and will come back to that later…

So far the best compression I’ve gotten is to store the world in parts (tiles, chunks, whatever) and run length encode them vertically… you can GZIP them, too. Most of the data tends to be vertically coherent so run length encoding reduces the size quite a bit on its own and largely empty tiles will be near 0 depending on how you encode them and how you’ve chunked your world.



Note: it wasn’t clear from your last paragraph… or at least I could have read it two ways… so just in case, box worlds are not made up of boxes. The data are cells in an array and the geometry is batched “quads” where solid meets air.

1 Like

Thanks pspeed, ive been reading a lot of your stuff lately.



Yea i wasnt sure how to phrase it shortly. I had created something that reads 3x3x3 (actually i have it variable and played around with 5x5x5) matrix and creates a custom mesh based the data (say 1 for soild and 0 for not) that only has a texture/triangles based where visible. these had links to the 3x3x3 ones next to them so they could check those faces too… figure this was a way to do it. I was trying to remove the vertical limits by making chunks that are 3d. the plan would be to eventually expand these to bigger dimensions. then i was thinking about storing the whole world as these floating chunks (or a few of them) creating a kind of hybrid ( arrays of the “base” blocks that are stored with location data ). Thought this might be easier to then work through as the mechanics would consider everything open and then only places with chunks would be solid. This thought came to me with caves in the reverse. solid ground with only data representing the cave.



I started creating something that i could use to tree down. chunks of chunks of chunks… etc till getting to a base sized block but then you would have to move all the way up and down some branches to access the data next to it…



is there anything in jME3 that i should use to store this data? or should i just create my own class for storing the world?

I’d use your own class.



For Mythruna, my “chunk” size (which I call leaves because I was originally going to be a hierarchy, too but now I only have nodes and leaves)… anyway, my leaf size is determined more as a tradeoff between geometry generation and optimal geometry size. JME will like fewer bigger geometries but the mesh generator will prefer to generate smaller ones.



Mythruna leafs are 32x32x32 and a node is 32x32x5 leafs… so 1024x1024x160. The vertical limit is more a function of originally how quickly I could shuffle the local player view around. At 128 clip, 9x5 new leafs need to be shuffled into the local area every time you cross a leaf boundary. I later fixed any slowdown related to this and now my only technical limit is that I do a lot of 2D map related stuff that prefers bytes for height because they are smaller. So I will probably always have a 256 meter height limit… which is fine for an RPG. There are tricks I could use to get around it but it’s of extremely low priority.

1 Like

Thank you very much. This is exactly what I wanted to know. Didn’t want to spend a ton of time only to find someone else had created something for exactly what i wanted to do.



Started looking at your Mythruna. Has it been only you the whole time? How long has that been going? Pretty impressive. Also glad to hear you and your wife are doing well. (or at least from the update a few months ago that i just read)

Thanks.



Yep, just me. I’ve been working in it for about a year and a half.

Well inspiring to say the least. One last question: How many hours a week would you say you put into it? cant imagine you would make enough off donations to support you and your family for full time development.

@ditchbuster said:
Well inspiring to say the least. One last question: How many hours a week would you say you put into it? cant imagine you would make enough off donations to support you and your family for full time development.


No, not by a long shot.

I try to put in about 20 hours a week. Sometimes I can put in a lot more... sometimes a lot less. Just depends on life and day job, etc.