My problem is that I should load 256 ^ 3 voxel into memory for collision detection. Then I reduced it to some amount by not loading the voxel with 0 density. In addition to that I have to use polyvox for rendering the model plus one another model rendered using terrain.


Thanks for your concern. I will look forward to it.



Yeah it is true that I can not expect you fix everything.. I started to work on it and I have found some resources. If I get more smoother surface > I will share the idea with you.
I also need to think about real time modification ... that is more important than smoothing further.

Further I tried to do real time modification of data > surface.

My problem is when I tried to call "extractReferenceSurface" for the regions modified ( may vary), graphics loop gets slow down terribly.

What I think of doing is to have
- Main thread
- Graphic Thread
- Worker Thread

Worker Thread can take the modified data information from Main thread and construct the surfaces for the modified regions and pass the vertex and normal information for the modified region to graphic loop.

But I lack idea in multi-threading in C++ . Do you know how I could do this?
Could you guide me how I can speed up the process so that I could see the real time modification to the surface?

Hmmm... I see. Is it not possible to use the PolyVox volume for collision detection as well? You have access to the individual voxels, but maybe you need more than that?

But actually I suspect the size of the meshes is as much of a problem as the volume. A quick check of the SurfaceVertex class indcates that it is 28 bytes, which is a lot when there are millions of them. I will try to improve on this.

Also, you should realise that the way I use OpenGL in the PolyVox demo is the most simple way, but not the most efficient. The meshes are being stored in main memory, and all the vertices are sent to the graphics card every frame via the calls to glVertex3f(...).

It would be much better to transfer the meshes into graphics memory. Then you wouldn't have to transfer them every frame, and you should also be able to free up the main memory you were using. I'm not sure how you do this in OpenGL, but I think you should look into 'Vertex Buffer Ojects'.

As for your problems with the modification, I don't think you should use threading yet as this will likely make things more complicated. The Thermite castle demo updates a 256^3 volume in real time with no problems, so your application should be able to do the same. There was no example of how do do the modification, so it's quite likely you not doing it in quite the right way. Can you describe the approach you are using?

One thing to remeber is that PolyVox breaks the volume down into regions, and you can generate the region for each mesh seperatly. When a single voxel changes you only need to update the mesh for that region. You can keep track of which regions changed, or you might find there is a class called VolumeChangeTracker which will help you or at least give ideas...

Also, as the OpenGL demo doesn't demonstrate modification, you might find it useful to look in the Thermite source code.

That is a nice idea..I have to access individual voxel (X,Y,Z position and density value). Nothing much.


I will be glad to see the improvement in Polyvox memory usage since it will help me in my task. I will look forward to it.


I actually I am using the same technique :all the vertices are sent to the graphics card every frame via the calls to glVertex3f


I did not know this before , I will look into this as well. Thanks for your guidance.


I was able to try that idea. Modification is possible but ... damn slow


From this , I can really understand that I am not doing in the right way.. which I could possibly able to do.
In the Main loop.. I will be modifying the voxels (make density 0) , I keep track of these voxel (position info) in 'vector' in the main loop.The I transfer the vector (vector - thread safe). In the graphic loop, I access the vector and loop through it and check which voxels are modified then based on the position I can find which regions as modified. Then run Polyvox::extractReferenceSurface for each region.
Main problem is there may be multiple voxels in the same region. Currently I could not avoid calling extractReferenceSurface multiple times for each region.
Here I have a question:
If I use the PolyVox volume, then in the main loop I can simply use setVoxel() to make changes in PolyVox volume, Is it possible to set which regions are modified using VolumeChangeTracker?
since you wrote :


I just noticed that you had a method 'void markRegionChanged(uint16 firstX, uint16 firstY, uint16 firstZ, uint16 lastX, uint16 lastY, uint16 lastZ);'
in VolumeChangeTracker.h But it is commented out. no implementation found.

Latest update : I have tried to use polyvox volume... but problem is still :
"calling extractReferenceSurface multiple times for each region." This cause very slow graphic loop. but memory consumption is lowered hugely.

I think if i can avoid it .. then graphic loop will improve... I can further improve it with Vertex Buffer Objects.



I will look into it.

I have seen how volume modification is done in my case, but it is now slow.. it is really encouraging the way you answer my questions and provide enough information to look for and fixing problems in Polyvox. I am really thankful to you. I will really acknowledge your support in my final outcome and spread the message how Polyvox is useful.

That will be ok for a small number of triangles (maybe from volumes of 128^3) but if you get much larger you will find it becomes very slow. Even if you you are not modifying the data, using this approach it will be sending all the triangles to the graphics card every frame.



I'm pretty sure this is you main performance problem, but fortunately it is fairly simple to address. Consider you have a volume of 256^3, which is broken into regions of 32^3. In this case the number of regions is 8^3. You can create a simple array of bools to keep track of whether a region is up to date. Something like:



After you run extractReferenceSurface() on a particular region you can also set the value to 'true' in that array. After you modify a voxel you set the flag for it's corresponding region to false (and maybe it is already false, if you have already modified a voxel in that region but not regenerated the mesh yet). Does that make sense?



The VolumeChangeTracker is based on a similar principle to above. But instead of storing bools, it stores a integer representing the timestamp of the last time a region was modified. I also store a timestamp in meshes in Thermite, and I compare these each frame to see what needs updating. It's a little messy though as I never really decided exactly how it should work. So you might want to just use a simple array like I showed above.



I'm happy to help Your one of the first users of the library so it is good to get feedback and see how well it meets people's needs!

Excellent idea ...... it works superbly even for 256 ^ 3.....I can not believe myself...I am almost done with it. this was only possible because of your help and continuous guidance

I will talk about this with my adviser and get back to you.

Apart from getting a good shape of 256 ^ 3 model ( that is my problem...)


I really wonder how people have missed a tool that does wonders ! as you say I am one of the first users .

P.S Currently I would say ... only thing still I consider as a limitation is that it supports the data in the power of 2...

Well it should be possible to smooth the normals even further by taking the average normals of several neighbouring voxels. But I'm worried that if it gets too smooth you might start to lose surface detail. At the moment you are on a 256^3 model - are you intending to go higher? I don't think the loss of details wouldn't be such a problem at higher resolutions.

That is a limitation, but I think it will stay for the time being. You see, having the regions and volumes be powers of two makes certain maths operations faster. For example, I guess you have already seen that you can calculate the region which a voxel is in by dividing the voxel position by the region width? Well because the numbers are integers, and the divisor is a power of two, you can actiually replace this by a faster bitshift. So instead of:

You can say:

Would it not be possible to simply pad out the volume to make it equal to a power of two?

_________________
Matt Williams
Linux/CMake guy

Yep, that is quite possible. At the moment it's probably a little wasteful of memory, but once I implement data compression for the volumes it will be a pretty small overhead. A large contiguous range of zero's should compress down very well indeed.

let say I have a data of 180 ^ 220 ^ 200 size I am not sure how we can pad out the volume to make it equal to a power of two in a raw file? I will try to find a way!
I want to first have a the complete shape of the model. Then think about memory..


I would like to try and see how it behaves if I smooth... I have tried to render 128 ^ 3 for now..that works fine.. I will get 256 ^ 3 working first.

I could go for 512 ^ 3 since PolyVox support faster rendering and I am using Polyvox volume for CD as well and I have data 668 ^ 668 ^ 469 given that I have an idea of padding up.