David Williams wrote:
The other aspect is that there's more to PolyVox than the surface extractors - for example how should the raycasting respond to transparent voxels? Or the ambient occlusion generator? Simply flagging voxels as solid or transparent might be more useful here.
You already created the callback-raycast (which btw I'm using quite successfully, it's really great, thanks!)
and that should be sufficient for anyone raycasting through transparent stuff... maybe some default ones could be implemented, but I don't believe this to be a problem.
Quote:
PolyVox wouldn't dictate what data should be stored per voxel - just what data a voxel should be able to provide. For example, a voxel already has both getMaterial() and getDensity() methods, but if only a material is being stored (e.g. Material8) then the density is simply computed based on the material (material 0 has a low density, any other material has a high density). So I agree with you, and the 'material register'would be an implementation detail of the voxel type.
so basically the voxel class would just get another function like renderBorder(VoxelType other) which would return whether a border should be rendered, and isSolidBorder(VoxelType other) which would return whether the extractor should render here AND not render anything inside