Although this is mainly directed towards pspeed, anyone who can shed some light is more than welcome to do so.
I was taking a look at your pre-alpha release and I got to say its simply impressive what you accomplished already, and as such I of course would like to ask you some questions about it.
I am trying to make a Sandbox/MMO crossbreed, and I am struggling with the most basic things for the moment. Terrain generation and collision detection. I am using a voxel based approach, with which I generate my terrain mesh, and then generate a MeshCollisionShape on it. This is not so bad, and gives me very reasonable timings on startup. But whenever I have to alter the voxel (adding or removing a cube) everything lags a lot. Now that it is highly “optimized” it takes about 1 second to either add or remove a cube from the mesh. I remember reading one post on the forums where you said you used voxels as well, and on your pre-alpha it simply runs very very fast, so the question is: “How did you do that?”
Please note that I am not asking for you code nor anything like, I am just trying to understand how you do it, to see where I am doing it wrong. Most likely it is in the mesh update process, so if you feel like pointing out any common problems i could be facing in that department, i would be very thankful.
Congratulations on Mythruna, it looks awesome so far.
Thanks for the kind words.
I’m not sure what advice to offer. I generate the world in 32x32x32 “leafs” and on my machine this takes 20 milliseconds or so per leaf when nothing else is going on. It’s pretty fast.
I do the building on a separate thread and then add/replace the geometry one leaf per frame to avoid hitches in the frame rate.
I don’t generate any collision shapes, though. Voxel terrain is so trivial to do collision detection on that the collision meshes are a waste of space and time. Especially when everything is a cube.
Thank you for the fast reply.
My working unit is a bit larger than the 32x32x32, this should account for some of my delay. The fact that you do not use collision mesh means a lot, for me, since 70% of my update time is regenerating the collision mesh, so taking it out should save me about 600ms. Although I will have to make the collision detection by hand, but will take a look into that.
Two pieces of curiosity about your “leafs”. When a player updates one of them, do you make something very clever to update the underlying mesh, or do you simply throw it off and recreate the mesh based on the updated values from the Voxel? And how do you handle the rendering of the leafs themselves, you will probably have many of them loaded at the same time, and will likely use some technique that enables batch rendering on the GPU, like texture atlas.
And the answers so far already set me on a new direction to go, hopefully things will go better this way.
Actually even with collision this can work quite well,
a friend of mine tried something similar that you, and ended with chunks of around 32x32x32 as well. Then he eleminated every invisible block ( underground) to reduce the amount of indiivual meshes that needs to be combined with the GeometryBatch thingy. (take a look at the utils package). Out of that he genretaed the collision mesh then. Worked fluently without even the use of threading. So the player on mesh problemw as not even there.
So should be possible with some thinking how to efficiently store that data and regenerate it for rendering/collsion detection.
Hey Phoenix,
Thanks for your input. I am working with 32x32x32 voxels, and will probably stick with them as well. When I tried a cube of 32x32x32, it was really fast to do all the operations, but when the same space was filled with a perlin noise function the performance drops a lot. Generating a solid cube that big produces a very low amount of faces, while a random surface generally have a lot of them which makes the process as whole very troublesome. Although I can try to improve on my mesh update/generation algorithms, I think I am very limited on what I can do with the CollisionMesh. Unless I am missing something very obvious I did not find a way to update the CollisionMesh, so I have to regenerate it whenever I change my base mesh.
Mythruna also regenerates all data each time a mesh is changed, while it ofc produces more garbage its not really a performance killer…
Thanks for the clarification Normen. I was trying to wisely update my mesh, but it is really inefficient with a high count of faces to draw. I will focus on enhancing my generation time, to make it as fast as possible. That should allow me to have a good time to react to user clicks as well.
After that is handled, I will investigate the options between using a CollisionMesh or handling player collision/movement by hand.
You might also be interested in this “Voxel framework for jME” that was posted recently. Also just searching “voxel” on this page (try the Google one) should also get you some worthwhile threads.
Yes, I am using his framework as a basis, although it got many improvements over the last few days. Lets just say i am a user since “commit 6”. Looks very solid so far as its getting many improvements really fast.
I did make a search previously regarding voxels and such, but since my results were so much worse than Mythruna’s I thought it could help me by doing some inquire, which already helped me a lot.
Just as a general feedback to all of you.
I got it working, I am using “Voxel framework for jME” which erlend referred previously, and its all awesome so far. I settled for a chunk size of 16x16x16. This size I can handle very easily, including regenerating the CollisionMesh every time that a block is added or removed from the chunk. I am using a basic Perlin noise generator for now (included in the voxel framework) but will set up some customization later.
Now, its time to tackle the texturing of the terrain, probably using an Atlas, although I would like to have a variable number of textures in there, and an Atlas limits my recommend texture size to 2048x2048. But that’s what I will investigate now.
Thanks to everybody who gave suggestions, all input I receive from this community is very enlightening and I can definitely say this is going to be an awesome experience for myself.