It is currently Tue Dec 10, 2019 11:30 am


All times are UTC




Post new topic Reply to topic  [ 48 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
 Post subject: Re: Transvoxel Algorithm
PostPosted: Fri Nov 16, 2012 1:47 am 

Joined: Wed Apr 27, 2011 7:10 am
Posts: 43
kalwalt wrote:
a bug in polyvox or the tva approach?


A bug in my implementation.

_________________
irc://irc.freenode.net/#polyvox


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Mon Nov 26, 2012 2:12 pm 

Joined: Mon Oct 15, 2012 4:33 pm
Posts: 52
Any news from this side?


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Tue Nov 27, 2012 9:37 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
Ok, from my point of view I think we are now ready to look at this again. It's been a crazy few months with the work on Voxeliens and the PolyVox release, but things are now under control again. So if you're still interested in working on this then we can have some more discussions about where it is going to go.

This thread has raised plenty of issues such as licensing, Boost, maintence, etc, but I think the solutions which have been proposed are basically the right ones. We'd probbaly be looking at creating some kind of addons/contrib library in which this project (and other community projects) could live and potentially be brought into the core as they mature.

An important question is whether realazthat is still developing this and is interested in taking it further. I realise projects come and go so no pressure here.

We've also made a couple of changes which were raised in this thread. In particular the Region class has some new member functions, and volumes also now have a VoxelType exposed whih simplifies the extractors by removing the need for template template parameters.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Fri Oct 11, 2013 5:12 pm 

Joined: Sun Sep 29, 2013 6:14 pm
Posts: 4
Ugh, I've been breaking my head over LOD stitching as well.
This problem is so hairy.

I wonder if the following approach would work:

The blocks that neighbour a lower LOD block will only need touch ups at on of its 6 (cubic) faces.
The article mentions 'transition cell' but you could just as well speak of 'transition face' as well.

Let's say the interface is between the hi-res +Z face with the lo-res -Z face.
Would it not be enough to only snap the vertices of the hi-res face so that they fall onto the edges that lie in the low-res face?

So in the diagram below, for the cell on the right, snap the vertices on the red edges to the large black edge.

Image


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Sat Oct 12, 2013 7:31 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
LOD is certainly a very tricky problem with Marching Cubes meshes, and I don't have any great answers. Think carefully about how much you need it because it has cost me quite some time in the past. But I can give a couple of tips which I found when working with it in Cubiquity (image here).

Firstly, I haven't done any stitching. Obviously it's the 'correct' and watertight solution but it is fairly complex. Instead I've applied a very simple hack, in that I use a different threshold value when extracting the lower LODs as compared to the upper LODs. When applied on a smooth density field this causes the lower LOD meshes to be slightly eroded and therefore slightly smaller than the higher LOD meshes. The crack still exists but it is always hidden behind the higher LOD.

This approach can of course cause visual discontinuities, but in practice I haven't seen too many problems. I haven't applied advanced lighting though and I think this might highlight the discontinuities.

Secondly, I think there is the question of how the downsampling is performed. I not sure what the TVA paper does but a common approach is just to skip ever other voxel, or perhaps average groups of eight voxels into a single one. I do not think these are mathematically sound approaches. There is a nice page here which talks about more mathematically correct approaches, and I think applying these might reduce the need for stitching of offseting. I think it will be a few months before I really try it though.

As for your actual question, do keep in mind that geometry can disappear completely in lower LODs (e.g. a long thin structure may no longer be visible). I feel this may affect your suggestion of adjusting the meshes afterwards.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Sat Oct 12, 2013 2:33 pm 

Joined: Sun Sep 29, 2013 6:14 pm
Posts: 4
David Williams wrote:
... Instead I've applied a very simple hack, in that I use a different threshold value when extracting the lower LODs as compared to the upper LODs. When applied on a smooth density field this causes the lower LOD meshes to be slightly eroded and therefore slightly smaller than the higher LOD meshes. The crack still exists but it is always hidden behind the higher LOD.


This is a great idea, and really simple to implement.
I will try this approach. Thanks for sharing.

Would you recommend always keeping full copies of the volume at low LOD in memory, and keep them in synch with the high res one?
Or do you make a low LOD volume cell on the fly for each hi res volume cell that needs rebuilding? (could cause differences at the edges of the cell if it is not part of a full size volume?)

Bram


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Sun Oct 13, 2013 7:46 am 
Developer
User avatar

Joined: Sun May 04, 2008 6:35 pm
Posts: 1827
bram wrote:
Would you recommend always keeping full copies of the volume at low LOD in memory, and keep them in synch with the high res one?
Or do you make a low LOD volume cell on the fly for each hi res volume cell that needs rebuilding?


I think somewhere in between. I wouldn't try to keep the whole volume in sync, and downsampling every cell of the fly could mean doing a lot of duplicated work between cells.

Instead, what we do in Cubiquity is that given a region we want to extract at a lower LOD, we downsample just this region from the source volume into another appropriately-sized destination volume. Then we run the extractor on the whole of this new volume. It's actually messy as you have to add a border as you are copying, and also translate and scale the resulting mesh but it basically works. I can't say it's necessarily the best approach though.. this is still kind of work-in-progress.

Be aware that the develop version of PolyVox lets you specify a wrap mode for sampling a volume, though I forget whether it is usedby the surface extractors.


Top
Offline Profile  
Reply with quote  
 Post subject: Re: Transvoxel Algorithm
PostPosted: Sun Oct 13, 2013 6:30 pm 

Joined: Sun Sep 29, 2013 6:14 pm
Posts: 4
David Williams wrote:
I think somewhere in between. I wouldn't try to keep the whole volume in sync, and downsampling every cell of the fly could mean doing a lot of duplicated work between cells.


Sorry, I got the terminology wrong.
I meant blocks (chunks) not cells.
I believe in PolyVox terms, a cell is simply the space bounded by 8 volume samples?
(As I noticed that PolyVox::Region will report a size in voxels that is one larger than the size in cells.)

Yeah, I expected the edge voxels to create trouble.
So I guess I just have to copy a little extra.


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

All times are UTC


Who is online

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