Volumes Of Fun
http://www.volumesoffun.com/phpBB3/

a cubic surface extractor with RLE
http://www.volumesoffun.com/phpBB3/viewtopic.php?f=2&t=90		 Page 1 of 3
Author:  beyzend [ Tue Nov 16, 2010 12:08 am ]
Post subject:  a cubic surface extractor with RLE
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.
Author:  Metanoia [ Tue Nov 16, 2010 3:35 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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.
Author:  paycheck [ Tue Nov 16, 2010 4:08 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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.
Author:  beyzend [ Tue Nov 16, 2010 4:50 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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.
Author:  paycheck [ Tue Nov 16, 2010 5:15 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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
Author:  David Williams [ Tue Nov 16, 2010 9:11 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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?
Author:  beyzend [ Tue Nov 16, 2010 10:04 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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).
Author:  beyzend [ Tue Nov 16, 2010 10:10 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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.
Author:  beyzend [ Tue Nov 16, 2010 10:31 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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.)
Author:  David Williams [ Tue Nov 16, 2010 11:37 pm ]
Post subject:  Re: a cubic surface extractor with RLE
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.
Page 1 of 3 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/