I am redesigning my program to utilize threads to speed up some aspects of the program. While I was working on this I remembered the troubles I have been having with decimation.

I haven't had a chance to test the new snapshot yet. It is possible improvements were made on the surface extractor and mesh decimator since I last used them. I know improvements were made on the cubicSurfaceExtractor. However I do not wish to use Cubic extraction.

In debug mode, mesh decimation is horrendously slow. Beyond a joke. I realize this is related to the debug mode and apparently it runs the decimator about 100 times slower than it actually runs. Even if this is true and the decimator runs 100 times faster than debug mode, it still seems too slow to use in a real time application where FPS matters.

However, not using Mesh Decimation results in very dramatic drop in FPS. Sometimes greater than a 40 FPS drop for me. This is not acceptable either.

I am wondering how others have optimized this process and how they use the Mesh Decimator. Perhaps there has been an update since the last snapshot and it is faster. Perhaps I just need to test it on a better machine.

Anyways, I would be grateful for any advice on how to use Mesh Decimation in an optimized manner.

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

At the moment I would have to say that PolyVox does not have a good solution for the decimation of smooth meshes. As you say it is very slow. It can probably be optimised (especially now the cubic meshes have a seperate solution) but overall I intend to instead focus on a different solution based around resampling the volume rather than decimating the mesh. I would suggest you read this thread for more information about my thoughts here.

I recently updated the todo list and both the RawVolume and the VolumeResampler are steps towards this. I would say that it is currently the most requested feature, so it is probably where I will work next, but I can't give a timescale.

well... for now (and even with better extraction/decimation) you should probably think about using threads. that way the meshes simply appear a few frames later instead of making your game slow down...
or the decimated mesh replaces the extracted mesh a few frames later...

Thats exciting. Volume resampling could be very useful.



That is my current plan. I will have one or two threads dedicated to mesh activities. Such as having one thread extract meshes, while the other handles decimation requests.

I am worried about two things. One if a user edits one chunk of terrain constantly, will this backup the thread with requests?

Two will there be a huge slowdown anytime a user wants to edit terrain because the mesh becomes high res as soon as he/she edits it?

I don't really have any specific questions yet (I'm still reading that post about volume resampling). I am just interested in any design experience someone might have in streamlining the mesh creation process. I want the application to run smoothly. It must be possible since the demos move so fluidly.

Thanks for the help.

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

well you'll need to implement a proper queue... one that will not push a new chunk if the chunk is already in the queue somewhere... that way you won't clog your thread for extraction

about the slowdown... I do not believe so, as decimation doesn't remove that many triangles if you have a natural terrain. (and it's only the one chunk which is undecimated). I'm not using decimation at all in my game.

As ker sys, this is really up to your implementation. Maybe you want to wait 10 seconds since the last edit before you start the decimation.



Not really, because you only need to switch to high resolutin for the part which is being edited. For example, if your terain is made up of 500 decimatd regions, and the user starts editing, you only need switch a few of those regions to high resolution (unless they are performing some action which afects the whole volume).



The demos don't use any kind of decimation. If you find that your application runs significantly slower than the demos then you might have other problems besides triangle count.

Really? I'm concerned about my code now. I've been testing one chunk, and I lose almost 20 frames between decimated and non-decimated. It could be related to debug mode, or my laptop, but still if the application does not use decimation... Perhaps I am using the example code incorrectly and making too many triangles...

What size are the chunks in the demo and how many are being rendered? My test size is 64x64x64 or 16 meters cubed.

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