BitteWenden wrote:
Looks like it's some uint8 causing the problem since it only happens once you go over 256 in the region size.
Yes, indeed, the CubicVertex is defined as follows:
Code:
/// A specialised vertex format which encodes the data from the Marching Cubes algorithm in a very
/// compact way. You will probably want to use the decodeVertex() function to turn it into a regular
/// Vertex for rendering, but advanced users can also decode it on the GPU (see PolyVox examples).
template<typename _DataType>
struct MarchingCubesVertex
{
typedef _DataType DataType;
/// Each component of the position is stored using 8.8 fixed-point encoding.
Vector3DUint16 encodedPosition;
/// The normal is encoded as a 16-bit unsigned integer using the 'oct16'
/// encoding described here: http://jcgt.org/published/0003/02/01/
uint16_t encodedNormal;
/// The interpolated voxel data from the neighbouring voxels which generated this
/// vertex (every vertex is placed between two voxels by the MArching Cubes algorithm)
DataType data;
};
The '8.8 fixed-point encoding' limits the extracted size to 256. In practice users are expected to extract regions with a side length of 16, 32, or 64 (depending on your application) and extract multiple adjacent regions per volume which are rendered as separate meshes. This keeps each extraction fast, and means that you can quickly update the mesh for parts of the volume which change.
Edit: I though you were talking about cubic voxels to start with - with Marching Cubes you have to take a bit more care to line the meshes up. You might want sides lengths of 17/33/65 so that they actually touch.
