Have anyone tried using an 0-5 number for normals which could be used as an index for an array containing regular vectors in the vertex shader?
That could also be used as an index for a texture atlas if you want different textures on the sides. They could be passed to the shader as bytes instead of float vectors (92% bandwidth reduction) or byte vectors (66% bandwidth reduction). This could be useful for embedded devices since they usually have limited bandwidth and memory.

I may do some benchmarking regarding this...

I haven't tried this but in principle it should work, and it shouldn't be difficult to implement. However, personally I'm using the CubicSurfaceExtractor (i.e. without normals) and then generating the normals in the pixel shader as shown here. This saves even more space, and also allows for improved vertex sharing between quads.

That said, I haven't measured the performance so I don't know how it compares. Any insights are welcome

I've added yet another cubic extractor which gives out indices instead.

I also noticed a couple of things that should be done with the cubic extractors. They should be passed a callback so you can choose what to do with the data without it going into the weird Mesh class. The range checks in getVoxelAt has to go and extracting the edge cases seem trivial. getVoxelAt also seem to be called multiple times with the same parameters.

I see that getVoxelAt in Block uses asserts, these are currently still there in release mode right?

Also do you know of a better algorithm for this? (with less than 6 branches per voxel)

That's fine, but I don't think we want to add this to PolyVox. The CubicSurfaceExtractorWithNormals is really just a simple testing class to help people get started with PolyVox, and to make the examples easier (no need to use shaders). But for real work you should use the standard CubicSurfaceExtractor (i.e. without normals) and generate the normals in the fragment shader. You can then have a lot less data in your mesh because vertices can be shared between faces which face in different directions.



Possibly, if there is demand. Though our plan is really to try and stablise PolyVox from now on, and what you suggest would be a pretty big change affecting existing code. Plus I'm not convinced callbacks are a better approach than the SurfaceMesh class.

But anyway, wthin a week we will have moved to Git and then it will be possible for people to try these things in ther own repositories.


The CubicSurfaceExtractor should handle the edge cases properly. The CubicSurfaceExtractorWithNormals may not, but that's because it just for testing and to keep the code simple.


Again, only for the CubicSurfaceExtractorWithNormals. This is because three different faces of a cube may all want to share a vertex but have differnt normals. Hence the vertex gets duplicated three times. The CubicSurfaceExtractor does not have this problem.



No, they should only be present in debug mode.


Well, I've thought about other algorithms but none that I've been convinced are better. The branches may or may not be a bottleneck - it's equally possible that memory access is the bottleneck. Only profiling would tell for sure. But it's pretty fast regardless so I haven't worried about it much. When I work again on this surface extractor I'll be more inclined to focus on the triangle count than the speed.

I guess this will require some benchmarks!

Since I'm pretty new to this, what's the most efficient methods without and with normals or indices:
- for a single texture on all sides?
- for different textures on all sides?
- for a single texture on all sides with per-pixel lighting?
- for different textures on all sides with per-pixel lighting?
This is probably quite useful to have for reference too.


This callback doesn't have to be explicit, it could just be another template parameter which defaults to the SurfaceMesh class so it wouldn't break anything. Another thing to add is a filter since it's likely you don't want all the voxels (say transparent or non-cubic objects). This filter might also control if normals should be added or not. That may get a bit complex (especially if you add mesh decimation into the mix) if the cubic surface extractors are more meant as examples or simple utilities.


Excellent


What I mean was for the code to use a version of Volume::getVoxelAt which doesn't do range checks, the majority of the voxels will always be valid. Some basic profiling showed that around half of the time was spent in getVoxelAt, with profiled guided optimization this overhead seemed to disappear.


What I was getting at was that the result should be stored in a variable and reused, for readability and performance's sake.

I don't really have any figures to hand about this. My current project isn't actually using textures anyway (just coloured cubes). So you'll just have to experiment



I have thought a bit about transparency but havn't really worked it through yet as I haven't needed it myself. I think I would make it another property of the VoxelType like material and density. Also need to think how it would work with the Marching Cubes surface extractor though.



The CubicSurfaceExtractor should really be implemented using the VolumeSampler which would then avoid all the calls to GetVoxelAt. I haven't done this yet, but it shouldn't be difficult.



This is already done, search the CubicSurfaceExtractor for 'm_previousSliceVertices' and 'm_currentSliceVertices'.