I have searched quite a bit for a solution to this issue but I haven't found anything. Has anyone successfully implemented seamless LOD with marching cubes before?
Marching cubes, Octree, and LOD seams
Author
I have implemented marching cubes for a large volumetric surface. The surface is contained in an octree which splits as you get closer to each cell, making a large (4096^3) area to explore. The problem is the seams between cells of different LOD. Here is a screenshot of the issue (there are also normal issues between cells of the same LOD, but I can fix that):
I have searched quite a bit for a solution to this issue but I haven't found anything. Has anyone successfully implemented seamless LOD with marching cubes before?
I have searched quite a bit for a solution to this issue but I haven't found anything. Has anyone successfully implemented seamless LOD with marching cubes before?
I've read a substantial amount of literature on MC, and don't believe I have ever encountered someone doing chunked LOD terrain with it.
Quick question: are you running MC on the CPU or GPU?
You might have a look at this article, which mentions "adaptive refinement," though this method is far more complex than vanilla MC: Cubical Marching Squares
You might try just running a full-quality MC and then using an adaptive mesh simplification algorithm to generate the LOD mesh for each patch. Definitely more expensive, but you'll get better-looking LOD that way and (if you tell the algorithm not to touch any vertices on the boundary of the patch) have no cracks.
And a quick note about normals - I'm assuming, based on the fact that your normals aren't all correct, that you're computing them after the mesh has been generated by summing and averaging the face normals for each vertex. If you want really good-looking normals for an implicit surface, consider calculating the normals by sampling the density field at each vertex with a slight dx, dy, and dz in both directions (i.e. compute the partial derivatives in each direction). It looks very nice (but, as I said, is costly, and probably only viable on the GPU, depending on how much loading time is acceptable).
Quick question: are you running MC on the CPU or GPU?
You might have a look at this article, which mentions "adaptive refinement," though this method is far more complex than vanilla MC: Cubical Marching Squares
You might try just running a full-quality MC and then using an adaptive mesh simplification algorithm to generate the LOD mesh for each patch. Definitely more expensive, but you'll get better-looking LOD that way and (if you tell the algorithm not to touch any vertices on the boundary of the patch) have no cracks.
And a quick note about normals - I'm assuming, based on the fact that your normals aren't all correct, that you're computing them after the mesh has been generated by summing and averaging the face normals for each vertex. If you want really good-looking normals for an implicit surface, consider calculating the normals by sampling the density field at each vertex with a slight dx, dy, and dz in both directions (i.e. compute the partial derivatives in each direction). It looks very nice (but, as I said, is costly, and probably only viable on the GPU, depending on how much loading time is acceptable).
Author
Thanks for the reply. The chunks are generated on the CPU. There is no way I could do a full-quality MC on my density field (it a perlin-noise based function over 4096^3).
I will read that article to see if I can apply it to my implementation.
For the normals, I actually just implemented the method of normal generation you mentioned. I read about it in the GPU Gems 3 article and it makes the normals look much better. It is running pretty good on the GPU (the terrain chunk generation is threaded, but there are minor hiccups).
Thanks for the info... I really hope I could find a decent solution for this.
I will read that article to see if I can apply it to my implementation.
For the normals, I actually just implemented the method of normal generation you mentioned. I read about it in the GPU Gems 3 article and it makes the normals look much better. It is running pretty good on the GPU (the terrain chunk generation is threaded, but there are minor hiccups).
Thanks for the info... I really hope I could find a decent solution for this.
Have a look at this:
http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf
I haven't looked in detail, but I believe he is introducing new MC cases which straddle the different LOD levels.
http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf
I haven't looked in detail, but I believe he is introducing new MC cases which straddle the different LOD levels.
Welcome to my (least) favourite topic!
Regardless, there are a number of advancements on marching cubes that ought to solve the problem (dual-manifold contouring, adaptive skeleton climbing, etc.). I haven't thus far had the time to implement any of them to check if they really do provide a solution...
Quote:Original post by PolyVoxI can't download the 50 MB PDF over my ghetto internet connection, but if I recall correctly, C4 does all of its voxel tessellation offline, which gives you a lot more choices in how you resolve inter-tile edge dependencies. Eric is somewhere around the forums though - perhaps he will weigh in at some point.
http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf
I haven't looked in detail, but I believe he is introducing new MC cases which straddle the different LOD levels.
Regardless, there are a number of advancements on marching cubes that ought to solve the problem (dual-manifold contouring, adaptive skeleton climbing, etc.). I haven't thus far had the time to implement any of them to check if they really do provide a solution...
Quote:Original post by c_olin
Has anyone successfully implemented seamless LOD with marching cubes before?
Quote:Original post by XeonXT
I've read a substantial amount of literature on MC, and don't believe I have ever encountered someone doing chunked LOD terrain with it.
The C4 Engine has been rendering voxel-based terrain with Marching Cubes and chunked LOD for about a year now.
Quote:Original post by swiftcoder
Welcome to my (least) favourite topic!Quote:Original post by PolyVoxI can't download the 50 MB PDF over my ghetto internet connection, but if I recall correctly, C4 does all of its voxel tessellation offline, which gives you a lot more choices in how you resolve inter-tile edge dependencies. Eric is somewhere around the forums though - perhaps he will weigh in at some point.
http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf
I haven't looked in detail, but I believe he is introducing new MC cases which straddle the different LOD levels.
Here's a version with low-resolution images -- it's 4.87 MB:
http://www.terathon.com/lengyel/Lengyel-VoxelTerrain-Low.pdf
The C4 terrain is designed for real-time interactive modification, so the triangles generated along the transition between LODs depend only on very localized data.
To implement all of this requires some look-up tables of nontrivial size. I plan to release mine in the near future.
I read in here that they just use "crack patching" to fill those gaps.
So I guess that means they put a or some pollys in the cracks to fill them. Simple as that?
So I guess that means they put a or some pollys in the cracks to fill them. Simple as that?
Quote:Original post by Lloydg
I read in here that they just use "crack patching" to fill those gaps.
So I guess that means they put a or some pollys in the cracks to fill them. Simple as that?
This paper does not define what "crack patching" means, but it's probably referring to a number of techniques that have been proposed that are either (a) not truly robust or (b) require analysis of an arbitrarily large swath of the voxel data. Not being robust means that not all cracks are filled in correctly, so you still have cracks. Analyzing arbitrarily large swaths of the voxel data is bad for two reasons: it has an unpredictable running time, and changes to the terrain in one place can affect how it looks far away from that place.
The method used in C4 is 100% robust, meaning that it will correctly fill cracks for any possible crazy voxel data you might encounter. And like Marching Cubes, the triangulations it outputs depend only on the immediately surrounding voxel data, so it has a constant per-cell running time, and local changes only have local effects. This is good for real-time terrain modification, like blowing craters in the ground.
Quote:Original post by Eric LengyelThanks for that.
Here's a version with low-resolution images -- it's 4.87 MB: http://www.terathon.com/lengyel/Lengyel-VoxelTerrain-Low.pdf
Quote:To implement all of this requires some look-up tables of nontrivial size. I plan to release mine in the near future.Let me know when you do so - I have no immediate desire to try and generate them from scratch [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
