Dynasty wrote:
Why are positions for PositionMaterial stored in Vector3DFloat and not in Vector3DInteger?
Actually the positions are not integers (they are 'integers +/- 0.5') but I agree an integer could be used and the 0.5 offset applied separately. It's partly just because PositionMaterialNormal uses floats (the the Marching Cubes meshes are not integers) and partly because on the GPU using floats for positions is more widely supported (I think?).
Dynasty wrote:
Why are the materials floats?
This makes a bit less sense, but again it's because older versions of OpenGL/Direct3D only support passing floats as vertex data. Actually I'm not even sure if that is true :-S But the idea was that you can just do a memcpy() from the data generated by PolyVox into your APIs vertex buffer.
Anyway, I agree it's a bit odd, and on our experimental branch we've actually started templatising the PositionMaterial class on the material type, so that the vertices can get the same material information that was in the voxel. You can see it here:
https://bitbucket.org/volumesoffun/poly ... sion#cl-39But I think it will be a while before this change gets merged back into the main branch.
Dynasty wrote:
I assume that the materials property works best for voxels that are textured, which is not what I am trying to achieve.
Basically yes, it was designed to pass a material identifier in which case a single numerical value (even in a float) is sufficient.
Dynasty wrote:
The voxel type that I need would probably have a position, and color (they are solid colored voxels). Is there a built in type for this sort of thing?
I would question why the voxel type needs to contain a position? The position is kind of implicit, in the same way that if you have a 2D bitmap then you don't store a position for each pixel, you just store a list of colours. So if you call myVolume->getVoxelAt(x, y, z) you never need to check the position of the resulting voxel because you know you just retrieved it from (x, y, z).
Dynasty wrote:
I can't think of any sane way to represent a color in a single floating point value.
I'm not sure it's sane but I do do it. CPU side I have the colour as a 16 bit integer (4-bits for R, G, B, and A) which I cast directly to a float:
Code:
Colour colour = vecVertices[i].getMaterial();
uint16_t colourAsUint = (colour.getRed() << 12) | (colour.getGreen() << 8) | (colour.getBlue() << 4) | (colour.getAlpha());
*ptr = static_cast<float>(colourAsUint); ptr++;
Edit: Just to be clear, Colour is my own type and is not part of PolyVox. For me a Colour is returned by getMaterial() because this is using the new templatised version of PositionMaterial as mentioned above.
Then GPU side I convert this float back to RGBA values:
Code:
vec4 floatToRGBA(float inputVal)
{
//Store the input in each component
vec4 inputVec = vec4(inputVal, inputVal, inputVal, inputVal);
//Convert each component to a value in the range 0-15
vec4 result = floor(inputVec / vec4(4096.0, 256.0, 16.0, 1.0));
vec4 shiftedResult = vec4(0.0, result.rgb) * 16.0;
result -= shiftedResult;
//Convert to range 0-1
result /= 15.0;
//return the result
return result;
}
I would have to describe it as a temporary solution though... and it may not work if you want more precision per colour channel. I think a better solution will come once we have the VertexTypes properly templatised on Material type.
Dynasty wrote:
Also most voxel tutorials that I've read suggest that you store data in chunks. However, polyvox recommends that you keep everything in a giant volume. Does this mean that the chunks should be split by the code that creates the meshes? Or something else?
The SimpleVolume and LargeVolume internally store data as chunks (they call them blocks) for memory management purposes, so you don't need to worry about this. For mesh extraction and rendering purposes you do need to manually control the size of the meshes and you can do this by passing a Region as a parameter to the surface extractors. There is no need for the blocks which are used internal memory management to match up with the Regions which are used for mesh management, though most voxel tutorials do tend to lump these two concepts together.
Dynasty wrote:
Edit2: I've implemented a custom class that holds custom value colors, block health, and position. Anyway, the mesh only seems to contain position data and no information about colors. When the mesh is converted to an Irrlicht mesh, it needs to get the color information associated with the block. There doesn't seem to be a good way that I can think of to retrieve this information, since the only data you can get is the position of the vertices and not those of the block. All of the data is stuck in the SimpleVolume.
I think I've covered this with my talk on positions and colours above... but let me know if you need more clarification.