Hey guys!
First i would like to thank you for the great PolyVox Engine =) I really love the stuff you did here.

I am using the PolyVox Engine for an university project, where we use PolyVoxand the XBOX360 Kinect device to create a 3D painting programm for modelling purpose.
We used apes wrapper as a starting point (thx to you ape, your work really helped me to get behind the whole stuff) but now we would like to switch to our own wrap.

Our coding platform is windows, c# and the whole thing is based on microsoft xna. So I took the swig wrapper of the latest snapshot and added support of materialDensityPair for the simple volume. Everything compiles fine but when i run the whole thing I get a Heap Corruption Error when starting.
Any Idea how this happens ?
If needed I can provide the interface files used or the source code.
Feel free to contact me a floar[at]gmx.de
Thanks alot,
flo.

Unfortunatly I don't have any experience here. I don't think the new SWIG bindings have been tested in C# (only Python). My suggestion would be to cut down the application (or create a new test application) and try to identify exactly which calls are cauing the problem. E.g. Does it crash if you create a volume but don't write to it? Or don't extract a surface? Or don't render it? Or maybe just the act of including PolyVox causes the problem?

Maybe then we can narrow down what the problem is...

Hey David, the error occurs when i try to construct a "volume battery" which means there are 10x10x10 volumes with the size 50x50x50. Wen need this in the kinect projekt to keep calculation time close to realtime. (because recalculation is done every frame).
I tried to hunt the error down and startet a new small c# projekt which is just focussing on PolyVox.
When I construct this volume grid the starting time increses heavily (nearly 2 minutes) and it consumes 3GB of ram. IS there any point I am missing?
As I stated above im using 1000 volumes (type materialDensityPair26) and wich 50x50x50 each volume.

regards floAr =)

You should only create one volume - internally it is already broken down into seperate blocks for memory management. In order to keep the manipulation in real time you will want to generate seperate meshes for differnt regions, and you can do this by passing a Region parameter to the surface extractor.

Ahh ok didnt know this. But I found a way to speed things up. Please dont ask me why its faster or how i get to this point.
Im using an array to save volume blocks and another array of the same dimension to hold boolean, to indicate if the corresponding volume needs to be recalculated.
At the moment i can create 1000000 volumes with 50x50x50 in about 4 seconds. if i try to do this with one volume it throws me an out of memory exception. Last config tested was 1 volume with 500x500x500 and it takes over 3 minutes to initialise.

I will work this out over the next days and test it out a bit.

Are you sure? That's 125 Gigabytes of data, which doesn't sound right...



What to you mean by 'initialise'? You mean to create the volume? Or to load the data into it? In C++, you should be able to create the volume on a fraction of a second, and fill it with data in a few seconds. Filling it with data involves millions of calls to setVoxelAt(), and it may be that each function call is relatively expensive because of the C# to C++ overhead.

But yes, see what you can find...

You were right =) Found a mistake when setting up the region.(It was a by-value,by-reference problem -.-) but now I even have a batch of 30x30x30 volumes with side length of 50 units. A single volume of 1500 units side length took much longer to initialise.

With initalise i mean just creating the volume with the new operator. This seems to take quite sone time, maybe because of some memory management stuff between c# and c++.


EDIT:
Ok forget what I said
you where right. seems like there was an internal error in the batch wich kind of swallowed some volumes. Which created the speed boost. I will stick to your suggestion and create single volume and add some "frustun culling extraction".
If anyone wants i will provide the swig files for c# or the c#lib and/or a projekt using xna.

regards and good night...finally =)

This does seem suspicious as it only takes a fraction of a second to create the volume from C++. Maybe you could add print statements at the beginning and end of the C++ constructor, and around the new operator in C#? Maybe then you can see which be goes slow?



Sure, we'd be interested in your SWIG changes at least. Once you've got it all working as desired anyway.

What I got so far:
I use a Volume of 750x750x750 which is initialized with "new" in about 7 seconds. (If this still sounds slow i will try the Console output you mentioned).
As Voxel-type i use MAterialDensityPair62 (with 2 bytes density and therefor 6 for material). I have a question regarding this. If I use Density8 as voxeltype a density of 3 will result in a very thin line. Is this the case here to or is the resulting "tickness" scaled depending on maximal value for density?

For rendering I use a calss calles "BatchedPart" which keeps the inedx and vertex buffer, a certain region of the volume (50x50x50 atm.) and a position.
When rendering I use frustum culling to determine which part needs to be drawn.

What im working at right now is a shader which uses the 6 bit material value to assign a simple color and the manager class will get some more methods to determine when a part needs to be updated.

That sounds a lot more reasonable. It does clear the volume to all zero's so tyha's why it takes a few seconds. But did you work out why it was taking three minutes before?

Yes, it's proportional to the minumum and maximum values. The threshold is defined as halfway between the minimum and maximum values. The surface is generated where the values cross the threshold.