David Williams wrote:
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.
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.
David Williams wrote:
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.
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.
David Williams wrote:
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.
Excellent
David Williams wrote:
Zoxc wrote:
The range checks in getVoxelAt has to go and extracting the edge cases seem trivial.
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.
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.
David Williams wrote:
Zoxc wrote:
getVoxelAt also seem to be called multiple times with the same parameters.
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.
What I was getting at was that the result should be stored in a variable and reused, for readability and performance's sake.