Hi,

I am interested in the source code you generously provided. I have built the source code and example using CMake. However, the example is based on qt which is difficult to install on my computer.

The previous posts mentioned that there was a glut based example. How could I get one?

Regards,
Jun

Hi, yes, there is a previous OpenGL example written in GLUT. Checkout revision 781 from subversion and try building that. It's written againast an older version of the PolyVox library, of course.

Once that works, you can copy the GLUT project outside the PolyVox source tree and check it still works (you might need to fix some paths at this point...). Then you can update PolyVox to the latest version.

Lastly, use the Qt example in the latest PolyVox to modify your GLUT version with the new classnames, functions, etc. You should then have a GLUT example working with the latest PolyVox.

Let me know if you have any problems...

Thanks for your information. I have just downloaded it and run the demo.

I have two further questions.
1) Have you ever tried the direct point rendering, just as
glNormal3f();
glVertex3f;
My limited experience is that, after using the bilateral filtering for the normals, the direct point rendering looks much smoother for smooth surface like the sphere region in the demo. The drawback is that the sharp edge may be not very clear. And that's why I am looking for some approaches to translate from direct point rendering to mesh rendering.

2) Is there any interface in your code to save the generated mesh in popular file format such as .obj or wrml? The current appearance of the demo is not so good. So I am considering load the generated mesh in other software such as Deep view.

BTW, your documents is clear and helpful, thanks very much.

Unfortunatly I don't have any experience with Point-Based Rendering, though I'm aware it is an active research topic. However, I have fairly recently added a mesh smoothing function to the PolyVox Library. See IndexedSurfacePatch::smooth(). Also, you can use higher quality normals to improve the appearence. Search the source for CENTRAL_DIFFERENCE, SOBEL, etc. I have been able to achieve the following results.

Unsmoothed:


Smoothed:




No, but you have acess to the triangle data so it wouldn't be difficult to add an exporter. .obj in particular is a very simple format. I wouldn't mind adding such an exporter to PolyVox though it would belong in 'Util' rather than 'Core'. I don't know when I'd get around to it though...



Great! I'm certainly intending to add a lot more in the way of documentation...

Yep, the second image is much better.

I have followed your advice to implement a GLUT based demo using the latest version(873). However, after several modifications (detailed at the bottom), there remains a LNK error 2019
---------------------
error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl PolyVox::extractReferenceSurface(class PolyVox::Volume<unsigned char> *,class PolyVox::Region,class PolyVox::IndexedSurfacePatch *)" (__imp_?extractReferenceSurface@PolyVox@@YAXPAV?$Volume@E@1@VRegion@1@PAVIndexedSurfacePatch@1@@Z)
----------------------

I tracked it and found it was caused by "extractReferenceSurface(&g_volData, Region(regLowerCorner, regUpperCorner), ispCurrent);" in main().

After comment it, there are no compile errors, but an unhandled exception arose in file xtree.

I also tried to build a simple demo using PolyVox from the beginning. Just creating a volume and extracting the surface. Resulting in the same LNK error. Of course, I have checked the link against .lib and put the .dll in the debug in both cases.

My environment is VC2005. I modified the GLUT_781 version as follows.
---------------------------------------------------------
1 Replace the .lib and .dll created by v781 with v873
2 Change the inlude path of the project
3 modify the #include... in the .h and .cpp (delete "PolyVoxCore/")
4 replace uint8 with uint8_t, uint16 with uint16_t, uint32 with uint32_t
5 replace getSideLength() with getWidth(), getHeight(), getDepth() respectively in Shapes.cpp
6 replace with g_volData.getSideLength() with g_uVolumeSideLength in main.cpp
7 replace Volume<uint8_t> g_volData(g_uVolumeSideLength) with Volume<uint8_t> g_volData(g_uVolumeSideLength, g_uVolumeSideLength, g_uVolumeSideLength) in main.cpp
8 isp.m_v3dRegionPosition with isp.m_Region.getLowerCorner() in OpenGLVertexBufferObjectSupport.cpp

Ah, right, the extractReferenceSurface() function is old code. In fact, everything in SurfaceExtractors.h, FastSurfaceExtractor.h, and DecimatedSurfaceExtractor.h will probably be removed soon. It is being replaced by a single class in SurfaceExtractor.h (note the spelling difference between SurfaceExtractor.h and SurfaceExtractors.h).

Look at the new OpenGLWidget for an example of how it should work, but it's something like:


Note that it now returns a shared pointer to the data which it creates itself, whereas previously you had to create the IndexedSurfacePatch yourself and pass in the pointer to it. So if you are storing the resulting IndexedSurfacePatches (rather than just sending then to the graphics card and then deleting them) then you will need to store these shared pointers instead.

[Edit:] I just removed the old surface extractors from SVN. So if you update, they will be gone.

Thanks. I have fixed it.

Great! Just let me know if you have any more questions.

Thanks for your help. And as your source code is easy for integration, I'm almost done with transferring the rendering in my work from point-based to mesh-based.

I have some suggestions for further improvements.
1) the invisible surface can be avoided to improve the efficiency. In the current codes, the voxels are identified with different indexes. All the boundaries between different material is constructed. However, to my point of view, only boundary between empty voxel (indexed with 0) with solid voxel should be constructed. Because other boundaries is invisible, there is no need to construct them.

2) Can the flaws (circled in the fig attached ) be removed? I suppose this is caused by the division of the subvolume. Maybe it is difficult in the algorithm view. Anyway, it does not cause not much bad effect.

Thanks again for your help.

I think I already do this - it was certainly my intention. The following code:


Compares the 8 corners of each cell to 0, and makes no distinction between other values. But if you have some reason to believe that invisible surfaces are still being generated then let me know, and I will look into it (that could be a big performance problem).



It appears the flaws come from the IndexedSurfacePatch::smooth() function, rather than the initial surface extraction (note that the flaw is missing in the first of the two pictures I posted above). It might be fixable, but it's not that high priority for me. Try changing the 'amount' parameter which is passed to that function?