Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

[Resolved]: Material woes
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=15&t=297		 Page 1 of 2
Author:  thomasfn [ Tue Dec 06, 2011 10:37 pm ]
Post subject:  [Resolved]: Material woes
Is there any situation where the generated mesh from PolyVox would contain materials not found in the volume?

I'm populating a volume, and all my voxels only ever have material IDs 0, 1 or 2. Yet somehow some of the vertices generated by polyvox are coming out as material ID 3. It seems to be occuring in areas where there is a transition between 2 materials.

Here's a screenshot. Grass 1, Rock is 2, sand is 3. 0 is "error" material for things that shouldn't be drawn. I'm only populating my volume with grass and rock (1s and 2s), I have checked this and I know for 100% sure this is the case. Yet as you can see, Polyvox is producing ID 3. In the background you see some random patches of sand also, they should be rock. I've double checked everything, the 3s make it into the system as soon as I execute the surfaceextractor.

Image

Any thoughts?
Author:  ker [ Wed Dec 07, 2011 9:26 am ]
Post subject:  Re: Material woes
how are you getting your indices from the SurfaceMesh? could there be any float casting issues?
Author:  David Williams [ Wed Dec 07, 2011 9:37 am ]
Post subject:  Re: Material woes
Actually I think this is indeed a bug in PolyVox. In the old days PolyVox only supported material volumes (no density), and zero was considered to be empty space while any other material id was solid. Therefore, when generating a surface between two voxels it was guarenteed that one of the voxels would be zero.

I needed to assign the material which was not zero to the vertices, and rather than using if-else statements I could just OR the value of the two voxels (knowing that one of them was zero). However, I don't think this logic makes sense anymore since we have the densities but it has been left in. A logical OR of '1' and '2' would give your value of '3'.

I'll move this to the bugs forum and get it fixed. Of course it could still be something else (like rounding errors... it's a bit ugly that PolyVox uses floats for the materials) but I'll start wth the logical OR.
Author:  ker [ Wed Dec 07, 2011 11:47 am ]
Post subject:  Re: Material woes
David Williams wrote:
I'll move this to the bugs forum and get it fixed. Of course it could still be something else (like rounding errors... it's a bit ugly that PolyVox uses floats for the materials) but I'll start wth the logical OR.


I've always wondered, why are the material indices floats to begin with?
Author:  David Williams [ Wed Dec 07, 2011 3:38 pm ]
Post subject:  Re: Material woes
ker wrote:
I've always wondered, why are the material indices floats to begin with?


I'm not exactly sure which GPUs support integer types but I don't think it's all of them. I'm sure that DirectX10+ hardware will support them for indexing texture arrays, etc, but I don't know about older hardware. Whereas I do know that floats work everywhere.

However, PolyVox could (and probably should) still output integer materials and leave it up to the user to cast them to floats if necessary for their particular target hardware. The reason it doesn't do this at the moment is that it is currently possible to do a direct memcpy() of the index/vertex buffers which is theorectically faster than iterating over each vertex and copying/casting them one at a time.

In practice, many people are not doing a memcpy() anyway as they are using things like Ogre::ManualObject. Also, for some applications you want to split the mesh or duplicate triangles so in this case you are iteratng over the data anyway. I think in the future the data type will get changed to int rather than float.
Author:  thomasfn [ Wed Dec 07, 2011 4:03 pm ]
Post subject:  Re: Material woes
I iterate over my vertices (several times since I smooth the mesh and other stuff), so I don't use memcpy. I have a seperate VBO (using OpenGL) for positions and normals so I kinda have to.

Thanks for looking into it. I did notice some OR operations going on when I looked over the source code briefly but didn't really understand what was going on.

I know you're a busy man, and I don't mean to be rude, but I'm on a deadline - what kind of timeframe are we looking at?
Author:  David Williams [ Thu Dec 08, 2011 8:31 am ]
Post subject:  Re: Material woes
I think you can fix this quite easily yourself. If you look in SurfaceExtractor.inl you need to replace the three lines similar to this:

Code:
const uint32_t uMaterial = v000.getMaterial() | v100.getMaterial();


with lines similar to this:

Code:
const uint32_t uMaterial = std::max(v000.getMaterial(), v100.getMaterial());


In Git master it's lines 445, 468, and 491, but the lines number might be different in the last snapshot. Looking at Git master should let you recognise the code though.

Note that the three instances are slightly different (v100 vs v010 vs v001) so don't just do a copy and paste. Let me know how that works out and I'll commit it if it's ok.
Author:  thomasfn [ Thu Dec 08, 2011 12:35 pm ]
Post subject:  Re: Material woes
Cheers, I'll have a go at that later and let you know how it turns out.
Author:  thomasfn [ Thu Dec 08, 2011 10:34 pm ]
Post subject:  Re: Material woes
Success! Your fix seems to have fixed the problem.

Image
Author:  Virror [ Fri Dec 09, 2011 1:04 pm ]
Post subject:  Re: Material woes
What technique do you use for the texturing? Looks very nice : D
Page 1 of 2 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/