XNA 4.0 voxel map rendering, using noise techniques

Started by
45 comments, last by winsrp 12 years, 1 month ago
very true, but I cant seems to find how this guy can have those huge view distances, not to mentions heights and depths, with destruction. You would need to save millions of cubes in memory, not to mention a file, or something. And 3D noise functions seems way too slow to use them in combination, so those should all be 2d noise functions somehow.
Advertisement
You don't actually have to save all the cubes. Most of the information is given implicitly by the procedural generation. Now to handle the destruction you only have to store the deltas to the generated world. basically you have a sparse datastructure (octree, hashmap or similar) and only store changes in there (so destroyed and built blocks). Usually the player won't build or destroy millions of blocks. The changes he makes to the world are very sparse. So you can actually get away with storing the parameters of the generator function + the changes.
interesting... I'll try generating some land without saving box information and see what do I get from there.

but that would mean that I cannot check if the object below is land or air, without calling the function again and check for the previews block value... So I'll have to display all the blocks faces again...

Any ideas on how can I accomplish that?
Well you might want to keep some of the information explicitly around. For example if you partition the world in chunks like i said earlier. you can keep and explicit representation of the chunks surrounding the player in memory to do fast collision checking an mesh recomputation in case something gets changed. If he walks away you kick some of the old chunks out of memory and load new ones etc.
I saw that the bounding box object consumes lots of memory, almost as much as my hole box definition and the creation of a bounding box on the fly also consumes quite some cpu power, but of course is a lot less than the whole array of boxes, so I'll try to keep my chunks with their corresponding bounding boxes in order to maintain the frustum culling, and try to keep list of changes in each chunk, so I can reapply those, if the chunk gets out of memory, then I might as well save those changes to a file latter on.

I'll try to maximize memory allocation as that seems the key to large areas, and by the way japro, how do you make it so that the quads gets generated by the geometry shader? Do you have any sample code?
If all your cubes are the same size, you shouldn't need a bounding box for each cube. You can either hard code the box values, or just create/alter a box when you are actually doing your narrow phase collision.
So started from scratch for the third time, but I wan't to make the generation as good as possible before I start with something else.

I'm going to try making hardware instancing of the cubes (too many fancy words for a noob I know, I just passed the last half hour reading about it and seem awesome) to see how what comes out, I've already made my cube in blender (actually just opened blender and a cube came out, how great is that!!) and exported it to fbx.

I have also made a plane of quads to show up without saving a thing, also created a new 2d perlin function, and running the perlin against the generation now takes 0.9 seconds to generate a 256 *256 array... not bad.

I also found some holes in the memory where returning arrays in functions will leave some data left in memory. Fixing all that.
question, If I have a 16x16 block and I use perlin noise 3d to retrive only 8 values, how would I go to use trilinear interpolation to get the other blocks?

Or how can I interpret the 3d noise values to produce a form from 3d space, what would the -1 to 1? values have to mean to know how to interpolate them?
ok I managed to get nearly as much boxes as I want on screen... pic attached (2048*2048 cubes), the problem now seems to be the frame rate which drops dramatically, but the mem footprint on the system is brutal at 8.5mbs only, and the generation type (of this simple terrain its only 33 secs, which is not bad for so many blocks) !!! This is without fructum culling, I'll try adding that now, and reduce the size of the sections which now is 16*16 sections of 128*128 cubes. To something that the fructum culling can take more advantage of, probably will need increase the mem foot print due to the bounding boxes for the sections that I need to add (I'll try to create those on the fly for reference on the FPS count and see what comes out.)

[attachment=7015:lots of cubes test.png]

This is loading 2 perlin 2d functions, one for land, and another for grass painting. the water is colored based on depth of water, which looks kind of cool.

Did someone got a look on the trilinear interpolation questions? tx
I'm having a bit of a transparency issue here that I can't seems to figure out.

I set the color of the water to

new color(color.blue.r,color.blue.g, color.blue.b, ctype(color.blue.A/2, integer))

but it seems to have some artifacts, any ideas?

[attachment=7016:transparency issue.png]

This topic is closed to new replies.

Advertisement