Cool, so what do you mean by 'serious gaming'? As in gaming with a serious purpose such as virtual surgery or something? You could certainly load a CT or MRI scan into the engine (I've done it) for such an application.

Anyway, very early OpenGL sample is committed. Nothing dynamic yet, it just creates a sphere in a volume (with low values in the middle and high values near the edges) and generates the surface for it. It gets displayed in pure white.

But writing this sample has made me realise there are still a few hacks in the library which I want to get rid of, so I'll probably leave the OpenGL sample for a couple of weeks now while I make some improvements.

Yes, this is the idea.


Ok, I have other things to do this afternoon, but I will try the sample asap and then try to modify it, load models, etc.

Hello,

I have tried the OpenGL example and adapted it to run in an Ogre application (it's still very dirty though ). But I have discovered that there is a problem in the destructor of BlockVolume, where some blocks are deleted twice, probably because they are shared.

Hmmm.... Yes, that's possible. But actually some work is needed on the block sharing code anyway. If a volume is changing a lot then there could be many new's and delete's going on as it attempts to share the blocks. But all blocks are exactly the same size so it makes a lot more sense to implement a memory pooling system. The same applies to other parts of the library.

Well the mesh decimation works and the mesh smoothing is getting close. After that I'll consider the library feature complete (for the time being) and will concentrate on fixing these issues. But I'm glad someone else is playing with it

I have more questions:

1. Is there a way to know the voxel value corresponding to a vertex? Is it the material atribute of a vertex? (And what is the alpha? Is it an auto-computed opacity or something?).
2. I have seen that the surface is extracted where there is a frontier between 0 and any other value. This is always done this way or is there a way to specify one or more isovalues to the method? Also, I have seen that it there is some material with a value different from 0 that reaches de border of the volume, its surface is not computed. See the two below images for example. The object is a kind of pyramid, and in the second image you can see that its "floor" is missing. I don't know if this is intended to be this way or not, but I think that the floor surface should be computed.

Yes, it is indeed stored in the material attribute. The value should be between 1 and 255, but because it is a float I add 0.1 when it is generated, and then take the floor() in the shader when I use this value to decide which texture to apply. The 0.1 is just to avoid floating point accuracy issues - it probably isn't necessary but I haven't looked into it.

The alpha value is used when I blend together two adjacent materials to give a smooth transition. But actually it shouldn't be generatred in PolyVox because it is always 1.0 (I think...). It actually gets set later when Thermite checks each triangle to determine whether all it's vertices have the same material.

I need to revisit this, and clarify exactly what gets done by PolyVox and what gets none by Thermite, because at the moment the boundary is a bit vague.



It's always done that way. I envisaged that zero represents empty space, and any other value represents a solid material. A boundary between two materials would only be visble if the camera were actually inside one of them, and as they should both be solid this should never happen. However, I accept that if one of the materials was water (so you can get inside it) or glass (so it's partly transparent) then my argument doesn't hold. Is this what your looking at, or some other scenario?



That is the intended behaviour, but I can see why you would want it changed. The marching cubes implementation doesn't look outside the volume and doesn't make any assumptions about what's out there. But presumably you would like it to assume it's zeros? In my hypothetical games I've considered that the camera will always be inside the volume, and so you'll never see the missing polygons.

I don't think I'll change the behaviour in the near future, but adding these polygons should probably be done as a seperate step anyway as it's a special case. So if you really need it you could add it by checking the voxels at the edge of the volume and adding triangles where necessary. But it's probably easier to just move your pyramid so it's fully inside the volume

btw, your project looks interesting!

I knew there was a better word than "frontier", but i didn't remember "boundary" And yes, I was thinking in transparent or non-solid materials.


Adding an 1-voxel border seems easier Thank you!

I think in the case of non-solid materials it doesn't make sense to represent them with the PolyVox approach because you wouldn't expect to be able to cut them up or destroy them in the same way. But yes, semi-transparent materials like glass are a problem at the moment. That said, it's a probably a pretty small code change to address this. It's just one line where I compare to zero and I think it's simple to extend this to compare to other values. But it's not a priority so I don't know how soon I'll look at it - If you really need it, copy the surface extraction code and have a play with it

Actually, maybe it's not so simple. Not only do you need to extract the surface but you need to be able to render in the correct order for the proper transparency effect, and this means the glass mesh might have to be separate from the other meshes. This could have a bigger effect on the design of the system... Something for the next version I think!

Now I'm taking a different approach by using 3D textures, that's why I haven't written any post lately. Anyway, I will write again if I use PolyVox again in the future.

Hi ,

I am glad to get to know about this library, I am really interested in using this library. For that I have to make sure that my requirements are satisfied.

I started to think about it because of the following quote:



My requirements:

1. should be able to load high resolution CT scan data 512* 512 * 512 to represent a volumetric static object
2. data should contain the density value
3. voxel representation should be cube : 8 vertices represent voxels , not a single point
4. should be able to identify multiple collision points while a moving object interact with static object
5. should be able to modify the density values which leads voxel removal
6. once material removed , locally construct the surface data and continue to detect collision

Could you please guide me by advsing me if this library can meet my requirements. The answers would really be appriciated.

thanking you in advance

/G