I cannot figure out what I could possibly be doing wrong. I cannot create a new mesh decimator without incurring this error during runtime.

Unhandled exception at 0x5f4ccac8 (msvcr100d.dll) in WorldCraft.exe: 0xC0000005: Access violation writing location 0x00000000.

It breaks in the middle of the constructor call to MeshDecimator
Below is the code I wrote to create a surface mesh and then decimate it.
It does make it inside of the if statement. Previous to this point I use the example code in order to fill a volume with cubes.



I've spent many hours on this already and I am out of ideas. Any help would be greatly appreciated.

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

You need to allocate the mesh before passing it to the mesh decimator

Wow I guess I should have expected it needed to be allocated.

Now I have a new problem. It is stuck in some kind of infinite loop while performing the DecMesh->execute() line.

Any ideas on why it can't finish this line?

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

Are you running in Debug build? I find when decimating a mesh from a 64^3 region in Release it takes like 0.3 seconds and in Debug it takes like... 30 seconds. My computer is pretty slow but still the difference is incredible.

You were right it was just delayed. However it took about 8 minutes to decimate a mesh pulled from a 128^3 voxel. I know it is only my laptop and not my more powerful desktop, but that delay still seems ridiculous.

Is there any way to improve this delay? This makes debugging pretty unwieldy.

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

Unfortunately I haven't found any way around it. I just test everything mesh related in release and skip decimation when debugging my own code...

Maybe David will have some ideas.

How do you test without decimation? The frame rate drop was intense. Granted my laptop is slow, but it lost over 50FPS from decimated mesh to non-decimated mesh.

I suppose that is a testament to the power of the MeshDecimator class.

I'm going to try this code on my Desktop when I get the chance. Maybe the speeds will be survivable. It has more power.

However I'm planning on using alot more voxels than 128^3. Granted I will be paging them, but there will still be many being displayed.

That brings up another question. If decimation is slow how do you deal with the changes in voxel data? If explosions ripped through the landscape, how do you keep the game going when decimation is so time intensive?

Anyways, If you have any tips or knowledge about keeping the frame rate up I would be grateful. Thanks for your help so far.

_________________
--Real Programmers use a magnetized needle and a steady hand.
--xkcd--

Sorry can't be too much more help since I am still working on that myself.

How many threads are you running by the way? At the moment I have 3:

1) Normal priority thread that extracts meshes / materials and converts the full resolution meshes to ogre manual object and add to scene
2) Low priority thread that decimates the meshes, converts to ogre then swaps out the full resolution mesh for the decimated one
3) lowest priority thread for garbage cleanup

I can't give you any performance info atm since my code isn't in a compilable state presently and I have changed a bunch of stuff.

As for keeping up with changes, I have a chunk manager the user interacts with for changing volume data. That chunk manager has a listener which alerts the mesh manager to changes, and the threads will process the changes automatically in the background.

I don't know if that is the best approach but its what I am going with at the moment. Hopefully once I get it up and running again it will work out OK...

Yes, the MeshDecimator is fairly slow. I'm sure there's some scope for optimisation, the collapseChangesFaceNormals() might be one place to start. And PolyVox is in general a lot slower in debug mode than release mode - I'm not sure if this is a bigger difference compared to other applications, if it is then it might be due to the amount of memory accesses which are performed.

It should be noted though that release and debug builds are not mutually excusive. Actually CMake generates a ReleaseWithDebugInfo configuration which runs at the speed of a release build but provides debug info (your position in the code) when it crashes. The point is that settings such as debug info, using asserts, performing optimisations are individually settable. Release and debug builds are the two extremes, but you can also compromise in the middle. That said, I've found that a release build of Thermite doesn't work with a debug build of PolyVox, so there are limitations here which I haven't looked into.

I would say that a mesh of 128^3 seems fairly large, but of course this depends on your application. I suspect that 8 lots of 64^3 meshes would decimate more quickly (and could be done on different threads). You could still have 128^3 as your page size, but split it up into meshes. You have to trade this off against the batch count though.

Oh, an as definite integral says, you can make the terain still dynamic by using a high res version to start with and then decimating in the background before switching over. If you have a few hundred low res meshes around then a couple of temporary high res ones shouldn't matter.

@DefiniteIntegral - Leaving aside the decimation time, how do you find the visual appearance and rendering performance of the decimated mesh? Is it giving a real benefit? How big a volume have you managed to get, and with what settings?

David, I'll let you know one I finish re-writing my scene management code.