I did some profiling in MLE and I noticed how easily the terrain size (using the smooth surface extractor) can affect the fps +-20 even.

For my game I want to have large area of terrain, let's say 1k x 64/128 x 1k and I'd love to push it to 4k width/depth at a point. The problem is that with all the post processing and effects in MLE it seems that I can have plenty of objects but polyvox terrain alone can drop the fps even when 500-1000 dynamic physics active models don't seem to change it (as) much.

What strategies can I employ to allow showing large areas made with PolyVox? How can I defeat this FPS hit?

I did try using the mesh decimilator but it ruined triplanar texturing because of its affect on normals so I didn't actually profile it yet.

There's no easy answer to this, it's really a case of profiling to identify where the bottleneck is. For example, are you bound by the GPU or the CPU? If the physics objects are not affecting your framerate then I guess you are more likely to be GPU bound.

You'll then need to narrow it down further - it is the vertex processing, fragment procesing, or batch count which is the issue (or somehting else)? Only then can you decide where to optimise...

You should probably find out whether the decimation is beneficial - if so you can then worry about the triplanar texturing and performance concerns.

I must say, I haven't done much investigation here myself. I can't say what the expected performance would be, or whether 4k*4k is realisic. I guess it seems a little large as I haven't gone past 1k*1k.

Decimation (threshold = 0.99999f) of the terrain brought the fps back to 60 and generated very acceptable normals and not many artifacts, of course with added complexity, so is reduced FPS.

Do note that with a threshold of 0.99f actually encountered artifacts by just adding some voxel spheres (note that raised "line" coming out from the hill):


So I decided to increase the threshold, the results are very satisfying but weren't tested against complex scenes or complex terrain yet. I will need to continue investigating but it does make me believe the problem is indeed in the number of triangles, not draw calls and not pixel shaders.

Also this allowed me to put 6 point lights with shadow maps active fps was about 48 with all other effects on (cascaded shadow mapping was rendering, though not visible, depth of field, hdr, and all the rest of them). This is pretty satisfying I believe (the artifacts in the light are due to not enough tessellation of the terrain at that spot, there is a fix for it, need to look it up, it is related to the shadowing technique: "Dual paraboloid shadow mapping").
http://pokit.etf.ba/get/5993e89037f977c ... 6e8dff.jpg

It does take it quite sometime to edit with the MeshDecimator at works which means I may move it to a different thread and replace the mesh when ready, or create the normal mesh and then decimate it after some time had passes since last edit.

Still much to experiment with, especially more complex scenes... I am slowing just digging caves tunnels and adding a bit of geometry here and there, seems fine, rendering a bit more from afar, FPS still about 52, funny to see it's actually higher FPS than when I was close to the 6 point lights (all still rendering at the distance in this photo with shadows):

Ok, I decided to implement some quick perlin noise height map to the volume to test complexity:



Still room for improvement, but is a bit better I guess.

Terrain Patch Size: 64x64x64
Num Terrain Patches: 5x1x5

Edit:
I just noticed I forgot to remove the default shadowing point light there which is used for testing when first added the effect. Removing it increased fps to average of about 50 or 51. Cascaded Shadow Mapping still working, so a point light with shadow active causes the terrain the render again seem to be able to drop fps by 2-4 fps or so depending on complexity.

Then again, my GPU is Radeon HD 4870x2. Not sure how well it will be on lower cards.

I remember someone from C4 explained how to write LoD for voxels here sometime before to fix cracks when sampling at lower resolutions.

I was wondering if one could ask a function to at least extract a volume at lower resolution (and also increased scaling) where and int would specify how many voxels to skip, would it be viable at all? So if 0 no difference, if 1 then instead of sampling a voxel and his neighbors the extractor would skip one voxel neighbor to get a lower resolution, without caring for rocks between LoD, for now. Also it should scale the size of the triangles to fit.

Will it be simple to do? (Haven't looked at the marching cubes algorithm much or the source code in polyvox)

Have anyone experimented with LoD or general lower resolution mesh extraction? I know I could create another volume half the size but I want to avoid duplicate data.

I think LOD will be very beneficial to a lot of PolyVox users as I seen calls for it before, but since fixing the cracks may take time, at least a lower sampling option should be enough for some for now and those can plan on upgrading once the cracks are fixed. I know my game isn't going to be ready in half a year time probably.

Another option instead of skipping would be to interpolate the values in the voxels maybe.

Actually the SurfaceExtractor used to have an option to skip voxels in the way you describe, but eventually I abandoned it because it made the code very complex and I didn't really need it. I decided that that it would make more sense to create a smaller volume and just run the algorithm on that.

However, PolyVox doesn't currently provide any automated support for this. You will have to take manual responsibility for maintaining the smaller volume. It may not need to exist at all times though - you could probably have a second volume just big enough for one region, and then copy your data to it each time you want to extract a surface.

Be aware that using a subsampling approach will have problems of it's own compared to the MeshDecimator. In particular, you may have a terrain which is solid rock with a one voxel layer of grass on top. Using subsampling you could quite easily miss the grass voxel, so you'll find you have to make you grass several voxels deep in order to guarentee it appears in all LOD levels.

How hard will it be to bring the functionality back to the surface extractor? It's just that it will mean a lot more RAM usage if I am planning for a volume at the size of 1k or 4k. Not just that, but also editing the terrain and re-copying the volume downsampling it over and over again seems like much worse idea than having the functionality inside the surface extractor itself.

I don't think it the RAM usage is as bad as you think. In principle you only need to keep a copy of the data for the region you are currently extracting. I think your regions are 64x64x64 voxels? That means the subsampled version is 32x32x32 voxels, which is only 32k of memory.

You do have to copy the data into the other volume before you run the extractor. This means reading every voxel in the original volume (which you have to do anyway to run marching cubes) and writing 1/8th as many voxels into the new volume. I would expect the process of downsampling a region to be faster then running marching cubes on a region, and then when you do actually run marching cubes it will be running eight times as fast.

I do agree it would be nice to have some automated support for this in PolyVox, but first the idea needs testing. As I said, it will have some problems with voxels/materials being missed. If it does work out then we think what code can be added to PolyVox to simplify the process.

Sounds good

You might be interested to know that Eric Lengyel released his look-up tables for fixing holes in LoD:
Algorithm: http://www.terathon.com/voxels/
Tables: http://www.terathon.com/voxels/Transvoxel.cpp

Yeah, there was some discussion about that before:

http://www.thermite3d.org/phpBB3/viewtopic.php?f=2&t=142
http://www.thermite3d.org/phpBB3/viewtopic.php?t=139

It should be possible to implement this inside PolyVox. However, i'd see whether you need it forst... personally I'd be hopeful that any mismatch between terrain LODs could be hidden by rendering a region twice (once for each LOD) if it lies on the transition between LOD levels. I think you can combine both LODs into a single batch, so hopefully there's not much overhead.