petersvp wrote:
What is your data source? MArching cunes expects array of floats, that is, in its original implementation, then it generates isosurface based on threshold value.
What I create is a PolyVox::RawVolume<BYTE>, BYTE = unsigned char.
The problem I have with anything larger is, again, the masses. 300x300x300xbyte is already 26MB.
If we used floats, that would be 100MB. And double that, because during creation we need our own C array as well as the PolyVox volume. So float would mean 200MB. And all of that creates a mesh with hundred thousands of vertices, all consisting of 3xfloat. So for a very short amount of time, one cell creation would cost, let's estimate... 300MB.
Now triple that as we have three background threads active at once, creating all the terrain cells at game start. That would be ~1GB of memory at runtime. Likely more because I certainly forgot something.
Not really application breakingly much, and it is only during that phase, but still.
And the good thing with char or any other integer is that we can use it to encode other information as well.
But I would be willing to try out floats (or even doubles), if that has a chance of allowing us to create smaller cells. With smaller cells, the temporarily larger memory consumption of floats would be acceptable.
Indeed, having only 256 different values could be enough to explain those artifacts. But still, why would that inaccurary appear in 50x50 cells, but not in the large 300x300 cells? The data is exactly the same for one 300x300 cell as for thirty six 50x50 cells.
petersvp wrote:
Polyvox has its LowPassFilter, are you running that?
I am not explicitly using it, no. I thought that might possibly be done automatically at some point during the mesh extraction.
Is there a sample where the filter is used?
petersvp wrote:
Are you downsampling your source data and if yes, how?
No, I am not downsampling. We also use ANL for noise creation, and every voxel gets its own value.
At least every x/z voxel, as we use ANL (for now) for heightmap creation. The "height" at the x/z coordinate of the voxel (converted to noise range mapping) is looked up and then the whole x/z column is filled downwards with 255 (max BYTE) - while smoothing the top 10 or so voxels, so it does not go straight from 0 to 255 in values.
Though there is a case in which ANL is not used (instead, a pre-existing image is used). But that is used only in a few placed and would not explain all cells being so.. terracy... when they consist of hundreds of 50x50 cells instead of just a few 300x300 cells.
Again, the amount of voxels per kilometer/meter never changes (I just tried that out in some pictures in the gallery). The only thing actually changing is the size of the cells.
If the cells are 3x3km large, they contain 300x300x300 voxels. If the cells are 500x500m large, they contain 50x300x50 voxels.
petersvp wrote:
And about deadlines, however, everybody hates them...
Yeah, the ugly reality