3D surface reconstruction for volumetric voxel data

Gajananan · **Joined:** Sun Feb 01, 2009 3:18 pm **Posts:** 34

Quote:

Ok, I have added two new gradient estimation methods. They are CENTRAL_DIFFERENCE_SMOOTHED and SOBEL_SMOOTHED. To be honest they look about the same, but CENTRAL_DIFFERENCE_SMOOTHED is faster so I would recommend that one.

I got the improvement in the smoothness. Just to confirm all I have to is to call like below rite?
computeNormalsForVertices(&g_volData, *ispCurrent,CENTRAL_DIFFERENCE_SMOOTHED);

Quote:

When you modify the volume, are you deleteing the old VBO and creating a new one or just replacing the data in the existing one? And are you deleting the old meshes?Otherwise your memory will fill up

After reading this :
http://www.gamedev.net/community/forums ... _id=227306

I did use the option 2 : glBufferSubData
One important point : glBufferSubData requires a kind of lock on the buffer, and this could have to wait until the GPU is done with the buffer.This may cause delay.

I think , I am replacing all the data for a VBO correspond to changed region. I am not sure if I am deleting the old meshes! How I could do that.
I think problem I mentioned is that Graphic loop goes down after some time during modification of volume, Could the problem exist because of memory?

Quote:

If you need more smoothness you will have to use larger volumes

Larger mean more densed volume (high resolution) so that sharp edges won't appear?

Quote:

The way in which you render the data is mostly down to OpenGL rather than PolyVox. I don't know how you change the color of a VBO but in the old days it was glColor3f(...).

I have not dealt with colors yet.
What I meant by " render color for the surface vertex generated by PolyVox if assign color to the orginal voxels in the PolyVox volume"
is that when Polyvox generate surface vertex , Can't it handle(assign) color as well?
May be I am wrong here in computer graphics theory?

Quote:

At the moment are you just extracting a single isosurface?

I am not sure since I am not clear of single isosurface vs multiple isosurfaces. I could say is that I use the same function call as in your example, which mean extracting a single isosurface?

Quote:

If you want multiple isosurfaces, then investigate whether a single VBO can have multiple colours in it.

We can have array of color for vertex (like array of normals) then bind this array as :
glBufferSubData(GL_ARRAY_BUFFER,0,noOfvertices * 3 * sizeof(GLfloat),vertices);
glBufferSubData(GL_ARRAY_BUFFER,0,noOfvertices * 3 * sizeof(GLfloat),colors);
Can't we do that?
This is why I asked you if polyvox can assign color for vertex

Quote:

Also, if you want to have nice textures/materials it will help if you are familiar with shaders so you could spend some time looking into these. GLSL is the language you would need.

Thanks for that information.
Basically what I wanted to do is to have different colors for different density areas. is this correct to say that this only possible if we extract multiple isosurfaces?

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Gajananan wrote:

I got the improvement in the smoothness. Just to confirm all I have to is to call like below rite?
computeNormalsForVertices(&g_volData, *ispCurrent,CENTRAL_DIFFERENCE_SMOOTHED);

Yep, that looks correct.

Gajananan wrote:

Larger mean more densed volume (high resolution) so that sharp edges won't appear?

Yes, I mean higher resolution. When polyvox supports larger volumes of course!

Gajananan wrote:

...when Polyvox generate surface vertex , Can't it handle(assign) color as well? May be I am wrong here in computer graphics theory?

Well it could, but that would not be very flaxible since I don't want to force people to use particular colours. In fact, people might rather use textures, or some kind of procedurally generated material. The material ID lets you identify a surface and then you can decide how to colour it. It's a bit more work for your application but it is worth it...

Gajananan wrote:

I am not sure since I am not clear of single isosurface vs multiple isosurfaces. I could say is that I use the same function call as in your example, which mean extracting a single isosurface?

I guess what I mean is 'how many different voxel values do you have?'. You are dealing with a tooth dataset, right? Let's imagine you set the enamel to be PolyVox value '1', the center of the tooth to be value '2', and the surrounding air to be material '0'. When you get the mesh back from PolyVox, you will want to know which vertices come from the enamel and which ones come from the center (you might want to know this so you can give them different colours). This information is what you get from the material ID.

Gajananan wrote:

We can have array of color for vertex (like array of normals) then bind this array as :
glBufferSubData(GL_ARRAY_BUFFER,0,noOfvertices * 3 * sizeof(GLfloat),vertices);
glBufferSubData(GL_ARRAY_BUFFER,0,noOfvertices * 3 * sizeof(GLfloat),colors);
Can't we do that?

I will have to look into OpenGL as I improve the example, but that looks promising. The catch is that you have to build your own color array, as mentioned above.

Gajananan wrote:

Thanks for that information.
Basically what I wanted to do is to have different colors for different density areas. is this correct to say that this only possible if we extract multiple isosurfaces?

That is certainly the easiest way of doing it.

Also, I have now started making some changes to PolyVox which will need you to update you code. For example, I'm trying to simplyfiy it so you don't have to use the 'BlockVolumeIterator' as much as I think this is confusing. I might also rename some classes - BolckVolume to Volume, IndexedSurfacePatch to SurfacePatch, etc.

Gajananan · **Joined:** Sun Feb 01, 2009 3:18 pm **Posts:** 34

Quote:

When you get the mesh back from PolyVox, you will want to know which vertices come from the enamel and which ones come from the center (you might want to know this so you can give them different colours). This information is what you get from the material ID.

I am not sure about 'material ID' . is this generated by PolyVox?

Quote:

Also, I have now started making some changes to PolyVox which will need you to update you code. For example, I'm trying to simplyfiy it so you don't have to use the 'BlockVolumeIterator' as much as I think this is confusing. I might also rename some classes - BolckVolume to Volume, IndexedSurfacePatch to SurfacePatch, etc.

I will try to see how I could modify my code to call your new functions.

I have one more question. This is related to coordinates of the vertex generated. My problem is that I need to move (render) model in the positive z direction (towards screen as now it is rendered away from the screen). I could not do that because I am using BlockVolume<uint8> g_volData for collision also.
If I am correct . the regions start from (0,0,0) rite ? How I could move whole model in +z direction with out having problem in collision?
I am sorry If haven't used the correct graphical terms! I think you got my idea!

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Gajananan wrote:

I am not sure about 'material ID' . is this generated by PolyVox?

Yes, and you can obtain it using the getMaterial() funtion of the SurfaceVertex class (it's currently a flat but should probably be an int). I have now updated the my own OpenGL example to include Vertex Buffer Objects, lighting, and multiple colours so you should have a look at that to see what I do. It still needs some tidying, but it's something like this:

Code:

GLfloat red = 1.0f;
GLfloat green = 0.0f;
GLfloat blue = 0.0f;

uint8 material = vertex.getMaterial() + 0.5;

switch(material)
{
case 1:
   red = 1.0;
   green = 0.0;
   blue = 0.0;
   break;
case 2:
   red = 0.0;
   green = 1.0;
   blue = 0.0;
   break;
case 3:
   red = 0.0;
   green = 0.0;
   blue = 1.0;
   break;
case 4:
   red = 1.0;
   green = 1.0;
   blue = 0.0;
   break;
case 5:
   red = 1.0;
   green = 0.0;
   blue = 1.0;
   break;
}

Gajananan wrote:

I have one more question. This is related to coordinates of the vertex generated. My problem is that I need to move (render) model in the positive z direction (towards screen as now it is rendered away from the screen). I could not do that because I am using BlockVolume<uint8> g_volData for collision also.
If I am correct . the regions start from (0,0,0) rite ? How I could move whole model in +z direction with out having problem in collision?
I am sorry If haven't used the correct graphical terms! I think you got my idea!

Do you actually need to move the volume, or would it be sufficient to move the camera?

If you actually want to move the volume then should should not do this often - probably just when a region is generated. You can simply add some value to the vertex positions which PolyVox returns.

If you just need to move the camera you should look into the OpenGL functions glRotatef(), glTranslate3f(), glScale3f().

Gajananan · **Joined:** Sun Feb 01, 2009 3:18 pm **Posts:** 34

Thanks for your updates on Opengl example.. that looks promising ..especially colors.. I thinks I could do that same thing. I will get back to you later once I do that!.

Quote:

Do you actually need to move the volume, or would it be sufficient to move the camera?
If you actually want to move the volume then should should not do this often - probably just when a region is generated. You can simply add some value to the vertex positions which PolyVox returns.
If you just need to move the camera you should look into the OpenGL functions glRotatef(), glTranslate3f(), glScale3f().

I have to move the volume once(when a region is generated) in the viewing volume. The I should be able to rotate using the camera.
Problem here is that when I move the volume by simply adding some value to the vertex positions which PolyVox returns, then collision detection breaks as I use the original PolyVox volume for collision detection not the vertices!.
Actually when I create Polyvox volume .. it starts from (0,0,0) to (256,256,256).

Do you have any idea how I move the volume itself?

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Gajananan wrote:

I have to move the volume once(when a region is generated) in the viewing volume. The I should be able to rotate using the camera.
Problem here is that when I move the volume by simply adding some value to the vertex positions which PolyVox returns, then collision detection breaks as I use the original PolyVox volume for collision detection not the vertices!.
Actually when I create Polyvox volume .. it starts from (0,0,0) to (256,256,256).

Do you have any idea how I move the volume itself?

I have updated the example so it shows how to rotate (click a mouse button and drag). I am creating the volume so that it goes from (0,0,0) to (128,128,128). I am then using OpenGL transformations to position it correctly. I use code like this:

Code:

glMatrixMode   ( GL_MODELVIEW );  // Select The Model View Matrix
glLoadIdentity();   // Reset The Current Modelview Matrix
   
//Moves the camera back so we can see the volume
glTranslatef(0.0f, 0.0f, -100.0f);   

//Rotate the volume by the required amount
glRotatef(g_xRotation, 1.0f, 0.0f, 0.0f);
glRotatef(g_yRotation, 0.0f, 1.0f, 0.0f);

//Centre the volume on the origin
glTranslatef(-g_uVolumeSideLength/2,-g_uVolumeSideLength/2,-g_uVolumeSideLength/2);

If you have problems building it, you can get a prebuilt version here: http://www.david-williams.info/linked_f ... 032008.zip

Transformations in 3D graphics can be pretty confusing - but hopefully that helps :-)

Gajananan · **Joined:** Sun Feb 01, 2009 3:18 pm **Posts:** 34

Quote:

//Centre the volume on the origin
glTranslatef(-g_uVolumeSideLength/2,-g_uVolumeSideLength/2,-g_uVolumeSideLength/2);

Using the above code works in my case too.. I could center the volume.
However after the transformation of the volume I get the transformed matrix
using glGetFloatv(GL_MODELVIEW_MATRIX, camera_state);

This is for collision detection. When I use the inverted matrix of the camera_stat matrix for collision . How ever this does not seem working.

However I have also
glRotatef(rotatex, 1.0f, 0.0f, 0.0f);
glRotatef(rotatey, 0.0f, 1.0f, 0.0f);
glRotatef(rotatez, 0.0f, 0.0f, 1.0f);

With the rotations above only before introducing the translation , everything worked fine!
Do you get what I am trying to do and see anything wrong?

Quote:

Transformations in 3D graphics can be pretty confusing - but hopefully that helps :-)

Very true.. I have been doing this for sometime,.. I am yet to master this!:)

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Can you clarify what kind of collision detection you are doing? Are you trying to detect when the camera hits the volume (to stop it flying through)? Or are you trying to click on certain voxels? Or do you have other object in the scene which you are colliding with the volume?

Gajananan · **Joined:** Sun Feb 01, 2009 3:18 pm **Posts:** 34

Quote:

Can you clarify what kind of collision detection you are doing?

I know the moving objects vertex position (in world space). Then I check against voxel (Polyvox volume element)
If volume is not moved then it is mapped in world space as moving object
In the case of Polyvox volume's position change, I have to find the matrix :I get the transformed matrix using
glGetFloatv(GL_MODELVIEW_MATRIX, camera_state);

get the inverted matrix of it , multiply the moving objects vertex position with the inverted matrix . This will convert the the moving objects vertex position from world space to volume object space.

Quote:

Are you trying to detect when the camera hits the volume (to stop it flying through)?

Not the camera .. another moving object.

Quote:

Or are you trying to click on certain voxels? Or do you have other object in the scene which you are colliding with the volume?

Yes . another moving object that collide with the volume.

I am sorry If I am not correct in graphic theories.! Please correct me if you find me wrong!

Gajananan · **Joined:** Sun Feb 01, 2009 3:18 pm **Posts:** 34

Oh ye! .. I found the solution ..... there was a bug in my code!.... sorry for the stupid questions!

3D surface reconstruction for volumetric voxel data

Who is online