It is currently Tue Feb 18, 2020 1:12 am


All times are UTC




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 12:08 am 

Joined: Sat Sep 18, 2010 9:45 pm
Posts: 189
Okay here it is.

http://pastebin.com/ufr54Pbf

What I thought were bugs with the extractor were really wrong assumptions in my terrain generation and paging system. (I needed to use WIDTH-1; I had this going before, but I changed for some reason; I'm not really "done" with the paging system yet so...).

You may need to modify this code a little bit to fit your needs. Right now it assumes uint8_t, although my initial implementation assumed MaterialDensityPair instead.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 3:35 pm 

Joined: Thu Nov 11, 2010 9:03 pm
Posts: 8
Thanks you!

I will try it and report back on how it is working.

EDIT: By the way, it is the ogre include necessary? I skimmed through the code and it seems that it is'nt.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 4:08 pm 

Joined: Wed Nov 10, 2010 7:15 pm
Posts: 43
does it only merge surfaces with the same material ID? it seems to me this would be the only way to do it, but I'm clearly no expert.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 4:50 pm 

Joined: Sat Sep 18, 2010 9:45 pm
Posts: 189
Metanoia wrote:
Thanks you!

I will try it and report back on how it is working.

EDIT: By the way, it is the ogre include necessary? I skimmed through the code and it seems that it is'nt.


@Metanoia

Yeah Ogre.h is not needed. As for correctness of this code, it *works* for me with the terrain I'm generating, but please be aware that the span is from zero to depth. So if you have two Volume objects tiled you may have holes in your "terrain." The way I'm doing it now doesn't have holes but I'm not sure it's correct or not. If you only use a single volume this should be fine.

@Paycheck

Yeah it only merges those with the same material AND only per slice. It's possible to extend this into 2D though.

Also, another possibility is to complety merge the sides of a "cube" and have each position on the cube index a material texture in the GPU which contain the material for a "virtual" face. However, you can't just write out a a height map like thing for a side, since this mapping is not one-to-one (I think). It may be possible to do it using some sort of structure... not sure.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 5:15 pm 

Joined: Wed Nov 10, 2010 7:15 pm
Posts: 43
what do you mean when you say slice? Anyways, I'm not really sure of how huge of a performance boost this would give except on ocean/plains but still a good idea to take advantage of it


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 9:11 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Great work! Do you have any screenshots of how much difference it makes to the resulting mesh? It would be interesting to see how the images look in wireframe mode. Even without screenshots, can you tell us how much memory is being saved or what the vertex count is like?

Also, how is the performance compared to the standard version?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 10:04 pm 

Joined: Sat Sep 18, 2010 9:45 pm
Posts: 189
David Williams wrote:
Great work! Do you have any screenshots of how much difference it makes to the resulting mesh? It would be interesting to see how the images look in wireframe mode. Even without screenshots, can you tell us how much memory is being saved or what the vertex count is like?

Also, how is the performance compared to the standard version?


Here are some screen shots.

http://imgur.com/a/xIwGP/rle_cubic

As you can see it depends on how noisy it is. For my case it works right now because of the terrain I'm generating. Of course I need to do more testing when I finish the terrain generation system. Personally I think it's worth the hours I spend implementing this and it wasn't much at all.

As for any real comparisons of actual relevance I don't have any. I'm not really "done" with it I guess. I reimplemented this so it no longer works with the regular cubic extractor so I can't just exchange this one with that one and do some tests. And memory...can't say. Tris... I don't have tris working anymore because of Ogre compositors... yes I will try to get # of tris tonight. Will let you know.

So it's probably better to wait until I do more testing before you go out and use this in your system. With that said, for me, it seems faster. There would be no way I can render what I'm rendering now with the old system (again....this is without any testing against an older version).


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 10:10 pm 

Joined: Sat Sep 18, 2010 9:45 pm
Posts: 189
Well assuming that a face contains 32 by 32 (1024) faces before merging, with this method of merging, the compression is a factor of 32. THis is the best case scenario.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 10:31 pm 

Joined: Sat Sep 18, 2010 9:45 pm
Posts: 189
Okay NVM I will test it real quick. I can just use the regular CubicExtractor. (I thought I need to change another class but I don't because that class takes a SurfaceMesh<PositionMaterial> which has nothing to do with the VoxelType of the surface extractor.)


Top
Offline Profile  
Reply with quote  
 Post subject: Re: a cubic surface extractor with RLE
PostPosted: Tue Nov 16, 2010 11:37 pm 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Sorry, I shouldn't rush you, I was just curious :-) From the screenshots it looks like you get a vertex/triangle reduction of about a factor of 5-10 which is certainly a significant memory saving. It looks like doing the merging in two dimensions would give significantly better results on the flats ground but not on the hills. And in theory I guess you can get an improvement factor of 1024. As mentioned in the other thread, this will definitely help with physics and memory, and probably with rendering too.


Top
Offline Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 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