It is currently Sun Dec 15, 2019 9:24 pm


All times are UTC




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Decimation Optimization
PostPosted: Thu Jun 16, 2011 3:44 pm 
User avatar

Joined: Tue Feb 22, 2011 8:04 am
Posts: 101
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--


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Decimation Optimization
PostPosted: Thu Jun 16, 2011 9:11 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Decimation Optimization
PostPosted: Fri Jun 17, 2011 6:57 am 
User avatar

Joined: Wed Jan 26, 2011 3:20 pm
Posts: 203
Location: Germany
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...


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Decimation Optimization
PostPosted: Fri Jun 17, 2011 2:45 pm 
User avatar

Joined: Tue Feb 22, 2011 8:04 am
Posts: 101
Quote:
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.


Thats exciting. Volume resampling could be very useful.

Quote:
or the decimated mesh replaces the extracted mesh a few frames later...


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--


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Decimation Optimization
PostPosted: Fri Jun 17, 2011 4:55 pm 
User avatar

Joined: Wed Jan 26, 2011 3:20 pm
Posts: 203
Location: Germany
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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Decimation Optimization
PostPosted: Fri Jun 17, 2011 10:20 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
GM_Riscvul wrote:
I am worried about two things. One if a user edits one chunk of terrain constantly, will this backup the thread with requests?


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.

GM_Riscvul wrote:
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?


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

GM_Riscvul wrote:
It must be possible since the demos move so fluidly.


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.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Decimation Optimization
PostPosted: Mon Jun 20, 2011 9:36 pm 
User avatar

Joined: Tue Feb 22, 2011 8:04 am
Posts: 101
Quote:
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--


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC


Who is online

Users browsing this forum: Bing [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created StylerBB.net