I think we are at cross purposes - it's really quite easy and I think your probably doing it already. All milliams means is that you can create a volume of size 256^3 and clear it all to zeros. Then you load your 180x220x200 volume into memory and copy it into the PolyVox volume one voxel at a time. Voxel (0,0,0) from your volume goes into the same position (0,0,0) in the PolyVox volume, and voxel (179, 219, 199) goes into position (179, 219, 199) in the PolyVox volume.

After you have finished, some of the voxels in the PolyVox are unchanged, for example voxel (230,230,230) will still be set to zero. These unchanged ones are you 'padding'. The point is, although the PolyVox volume is too big, it doesn't matter if you don't use it all (except it could waste emory of course).

By the way, I use '^' to mean 'to the power of'. So in my notation 256^3 means 256x256x256. I notice you were using it slightly sifferently so I just wanted to be clear

As for your email, well I have some idea what the problem is. It seems you are trying to create a single vertex buffer for the whole volume?



Instead, you should have one vertex buffer for each region. When the program starts you can call extractReferenceSurface() once for each region and store the result in the vertex buffer object for that region. Later, when a region changes, you only have to call extractReferenceSurface() for the region that changed and you only have to update that region's vertex buffer.

Yeah .. It is possible ... I was thinking about raw file before....but it's easy to do as you suggested.
So far I could not get 256 ^ 3 working fast... seems very slow because of glvertex call.


Yeah.. it is wrong ... thanks for noting it.


Yeah.. I did not think about having one for each region.

I am not sure how I could be able to update it.. one thing I failed to note is that the code I sent you is Vertex array ... If I am it can not be used for in the case of surface modification.
I think I will have to study more on how I could update VBO.
Anyway thanks again for your ideas...

The way I would do it is to create an array of vertex buffer objects (or possibly of pointers to vertex buffer objects) with one array element for each region. When a region changes, you should be able to call extractReferenceSurface() to get the new data and then overwrite the data in the vertex buffer object with the new data.

At the moment I am trying to get a release of Thermite out to demonstrate the latest changes. This should be done at the weekend and then I will shift my focus back to PolyVox. My priorities for PolyVox are the large volumes and non-cubic volumes, but I think I will also try and work on the OpenGL example as it is far too basic at the moment. It will be a couple of weeks away but hopefully that will help you.

I am going through the materials of VBo, sure I can implement it. Thanks for your ideas.


Thanks for your attention. Here I would also like to remind about averaging normal .. could this done into PolyVox or out side of it (in an application)?
If this could be done outside of PolyVox then I could try on my own!

You could do it yourself (you have access to the volume data, so technically you can do anything). You also have access to the computeNormal() function in GradientEstimators.h. In theory you could call this a few times for adjacent voxels and average the results. In practice it might be more complex though.

I'm going to rework the normal stuff anyway. Currently each normal is stored as 12 bytes (a 4-byte float for each component). I think I should be able to store them in just 2 or 4 bytes with a bit of thought.

I just want to recall one question I asked already. So far I have used the the model with densities 50, 100, 255.
and I had a logic like when I load PolyVox volume data:

for each voxel :

if(density > 0)
{
volIter.setVoxel(1);
}
else
{
volIter.setVoxel(0);
}

Then your MC logic code shown below is used to find surface.



But , currently I have a model file with many different density values. Problem is that I could not use your logic above in this case.

According to your earlier explanation:


This is the case still for the new model. why the logic above doesn't work here for the new model?
When I analyzed the new model , I found that Iso level for the new model should be 650.

Then I checked the original code in the website :
http://local.wasp.uwa.edu.au/~pbourke/g ... olygonise/

I found that the original code as :

if (grid.val[0] < isolevel) cubeindex |= 1;
if (grid.val[1] < isolevel) cubeindex |= 2;
if (grid.val[2] < isolevel) cubeindex |= 4;
if (grid.val[3] < isolevel) cubeindex |= 8;
if (grid.val[4] < isolevel) cubeindex |= 16;
if (grid.val[5] < isolevel) cubeindex |= 32;
if (grid.val[6] < isolevel) cubeindex |= 64;
if (grid.val[7] < isolevel) cubeindex |= 128;

This code segment helps to map the vertices under the isosurface to the intersecting edges. I tried to analyze it by comparing your code but I am missing a point here!

The above code means that If I know an Iso level , then I can find the surface.

How I could modify your logic so that I could set a different Iso level for different models?
Or at least let me know how I can alter the method I can get the surface for the new model.
Note that I have to load this new model because this new model is a lot smoother than that I used before.

Firstly (from your email) I'm glad you got the VBO stuff working. Is it faster to render than before? I still intend to improve the PolyVox OpenGL example so after that you might see other ways you can improve your code.

Secondly, remember I mentioned the approach of 'averaging' the normals? Well it turns out I already implemented that - I'd just forgotten where it was I just haven't really exposed it to the end user so I will do that very soon.

For you latest question, you are saying you have a volumes where the values range from 0 to some large value (say, 1000) and you want to create a PolyVox volume which has the isovalue at 650? Can't you just do something like this when you copy your volume into the PolyVox one:



Or did I misunsderstand your question?

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. But they are both slower and smoother than the previous approaches. Update from Subversion to get the latest code and try them.

I'm now back working on PolyVox properly and expect to change a lot of things. Many of the changes I make will break your code (e.g. I will be changing functions names, etc). Be sure to always keep a backup of your last working code before updating!

By the way, are you using the LinearVolume class? I'm thinking to remove this (and a couple of other things) to simplify the code.

Thanks first for suggesting this idea. Yes it is faster than before (I am getting 310 Hz) , it is noticeable when loading 256 ^ 3 and modifying the volume. Tough I ran into a strange issue : after some modification , it gets a little slow. I think problem is with the way I implemented the idea : array of bools to keep track, I got to solve it.
Update : I think one reason for getting slow is that :
when I keep modifying the model ,the number of VBOs to be modified increases because my modification rate is higher the graphic loop rate.
Even though I used array of bools is used. It will be updated in high rate than in graphic loop.
As the number of VBO increases, it gets slow since I used 'glBufferSubData', this will make a lock in GPU while updating the new bufer.
http://www.gamedev.net/community/forums ... _id=227306


Oh really ....it will help me to smooth model more. I am waiting to see the interesting results. I got it working now!


Sure ... please let me know what classes or files you change so that I can figure out if it affects my system. I try to use your library as an interface which means if any function that I access in Polyvox doesn't change its signature , then there will be of less issue.

Oh God.... how come I missed it ... believe me I tried many possible ways..and I also had 'endians' problem.


Is this what you meant by 'averaging normal'?

Please let me know the changes ! that would help me a lot.


No, actually I am using the function calls as in the OpenGL example.

I have one more thing to ask :
Do you think it is possible to render color for the surface vertex generated by PolyVox if assign color to the orginal voxels in the PolyVox volume ?
I have seen the example video that has colors in it.

Ok, 310Hz sounds a lot better 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. But actually PolyVox has some memory leaks here so I will make some improvements myself.



Don't worry - the only reason it's obvious to me is because I designed the library



Yep, and that's now probably as smooth as I can get the normals. If you need more smoothness you will have to use larger volumes or try the PN-triangles mentioned before.



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(...).

At the moment are you just extracting a single isosurface? An important point is that even if you have multiple isosurfaces in a region then PolyVox will still generate a single IndexedSurfacePatch for that region. If you want to know which isosurface a vertex came from you can look at it's SurfaceVertex->getMaterial() method. This will be a number from 1-255.

If you want multiple isosurfaces, then investigate whether a single VBO can have multiple colours in it. Ask me if you get stuck here as I do have some ideas.

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.