Thank you for your reply. I will try to apply light model... I learned about it for some other work.... as I am novice in this area... I didn't exactly know what could be the reason ....anyway please guide me how I can access the normal ...

Hi,

I tried to implement light model for the Polyvox opengl example and I also able to find how to get the normal.
In display method I wrote the following code: (for each surface vertex)
glNormal3f(vertex.getNormal().getX(),vertex.getNormal().getY(),vertex.getNormal().getZ());

Is this correct?

You could see the outputs below:



Why it is not smooth surface? Do I miss anything here?

I also try to change: const uint16 g_uRegionSideLength = 16;

But no effect is seen. Do you think this will give me more smooth surface?

/Gajananan

The surface is not smooth because it is being extracted from binary voxel data where each voxel is either on or off. Your data really is a grid of points/cubes and this is the stucture which you are seeing in the output.

Creating a real smooth mesh from such data is tricky, though hopefully not impossible. It's not something I'm managed to address in PolyVox yet. One option might be to have a seperate stage which takes the blocky mesh and generates a new, smoother mesh from it. Thiscould be slow, espessially if you are trying to update the volume in real time. Another option might be to use a 'geometry shader' to smooth the mesh as it is rendered. I intend to look into this in th future.

In the mean time, you can make the mesh appear smoother by improving the normals. The function 'extractReferenceSurface' generates pretty crude normals, but PolyVox does come with some functions to generate better normals for existing meshes. You can follow your call to 'extractReferenceSurface' with a call to 'computeNormalsForVertices', something like this:



Haven't tried compiling that, but I think it should work.

Thanks for your information on creating a real smooth mesh. I know it is challenging to find a solution that support real time modification.

I have not known about 'geometry shader'.. I will have to study on it. How I can integrate with polyvox to get smooth surface. Do you think it is possible with polyvox?

I also tried a call to 'computeNormalsForVertices' and got the same results as before in sphere and tooth cases.
call should be like this: "*ispCurrent" is the correct argument.
computeNormalsForVertices(&g_volData, *ispCurrent, SOBEL);

I am worried I make any mistake here.

The geometry shader was introduced with Direct3D 10 compatible hardware, and is also accessible via OpenGL using extensions. It basically allows you to modify triangles as they are rendered. You should be able to send the graphics card the jagged mesh from PolyVox and have it automatically perform smoothing on-the-fly.

My limited research has indicated this can be done with a technique called N-Patches. Each triangle would be replaced by several smaller triangles to make the mesh smaller. This technique has been around for a while (it's possible to do it on the GPU) but the arrival of geometry shaders means it can now be done on the GPU.

There is an article about doing it on the GPU here: http://developer.amd.com/downloads/GS-N ... lation.zip

Maybe some useful resources in this thread: http://www.gamedev.net/community/forums ... _id=475177

Note that this is likely to be complicated and I don't know much about it yet... You might find it easier to implement the N-Patches algorithm on the CPU before you uload the mesh, but then of course you will have to run it each time the mesh changes which might be slow...



That should work. Try replacing SOBEL (which is the smoothest) with CENTRAL_DIFFERENCE or SIMPLE. You should see different images with each - if it looks the same then something in wrong... In that case I might be able to take a look at your code at the weekend.

Thank you for the information on geometry shader.


You can see a topic called "PN-Triangles" in the following link:
http://castano.ludicon.com/blog/2009/01/10/10-fun-things-to-do-with-tessellation/
Is this what you meant by N-Patches?


Thanks for that waring , I should be aware of it before trying that.


Unfortunately I can hardly see any change when I switch between those parameters. It will really be helpful if you can look into that code.

Regarding building smooth normal, further I would like to know if it is possible to access the information of triangle faces (which vertices form a face). According to my friend in our lab, it is possible to build smooth normal if we can have the information that we can get from an "OBJ" file. I believe you know the "OBJ" format.

In the mean time I would like to see if it is possible to do real time modification to voxel data and If I can see the changes in surface in real time.

Yep, that looks like it. They talk about it as a built in feature of DirectX11, but as I said you can implement it in DirectX10 using geometry shaders. In fact, I believe you can do it in DirectX9 but only with certain ATI graphics cards. In case you didn't notice, there was also this link: http://www.cise.ufl.edu/research/SurfLa ... /00ati.pdf



I've just been doing some terrain rendering and so I wanted smooth normals as well. I used the computeNormalsForVertices() function and it does appear there is a problem with it. Actually, I remember I was making some design changes and it looks like I didn't finish. I will fix this over the next couple of weeks, but it will probably involve other changes to PolyVox.



Your friend is correct, but it doesn't work very well in the case of PolyVox. Although it appears that you have a single mesh, remember that PolyVox has actually generated a number of meshes (one for each 'region'). It does this so that when you modify part of the volume, only the meshes corresponding to the part of the volume that was modified have to be regenerated.

Your friends approach will work for vertices in the middle of the mesh, but those on the edge are not surrouned by triangles (there are only triangles on one side). The same vertex in the adjacent mesh will have triangles on the other side. Hence two adjacent meshes can have different normals for a vertex in the same position. This means visible seams can appear between the two meshes. I hope that makes sense...

Instead, the normal at any given position is calculated directly from the volume data.



Yes, you can look at that while I sort out the normal smoothing issues. Good luck!

According to the reply in the following forum
http://www.gamedev.net/community/forums ... _id=488630

If we don't have have DirectX 10 for fancy geometry shader, we could go the OpenGL road and use GL_EXT_geometry_shader4 but we need a Gf 8 card. This is for your information.


I will look forward to your solution for smoothing since I have to ensure that I render a smooth surface and it supports real time modification.
I hope your changes will not affect the flexibilities provided by PolyVox.


If I am not mistaken, is this what you have done in PolyVox?

Regarding smoothing, can't we increase the number of cubes , I mean regions in the case of PolyVox. I hope this may reduce "blockyness".

Ok, I have a fix Actually there was a bug in SurfaceExtractors.cpp which was easily fixed. The complete file should now look as follows:



Note the addition of the two lines reading:



You can copy the above code, or just update from SVN as I have commited the fix. You should then find that adding the line:



as described previously has the desired effect. Let me know if it improves things (and post screenshots if not...).

Thanks for your fix. Though I hardly see any changes after fix. Were you able to see any changes yourself after the fix?
I am looking forward to your reply!