• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
c_olin

Marching cubes, Octree, and LOD seams

21 posts in this topic

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

Share this post


Link to post
Share on other sites
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).
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
Welcome to my (least) favourite topic!
Quote:
Original post by PolyVox
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.
I 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.

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

Share this post


Link to post
Share on other sites
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 PolyVox
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.
I 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.


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

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Eric Lengyel
Here's a version with low-resolution images -- it's 4.87 MB: http://www.terathon.com/lengyel/Lengyel-VoxelTerrain-Low.pdf
Thanks for that.
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]
0

Share this post


Link to post
Share on other sites

Why not use the mathematical description of the landscape directly and solve it? Your graphical detail would go up a 1000-fold and you could even make it dynamic. Polygons are so oldschool... ;-)

Edited by spinningcube
Restored post contents from history.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by spinningcube
Why not use the mathematical description (force field) of the landscape directly and raytrace or ray-march it? Your graphical detail would go up a 1000-fold and you could even make it dynamic.

Polygons are so oldschool... ;-)
Have you ever tried this yourself?

My (admittedly naive) implementation is lucky to break 5 fps for un-shaded terrain, on an high-end gaming machine, because of the cost of evaluating the noise functions many times per ray.
0

Share this post


Link to post
Share on other sites
Quote:Original post by swiftcoder
Quote:Original post by spinningcube Why not use the mathematical description (force field) of the landscape directly and raytrace or ray-march it? Your graphical detail would go up a 1000-fold and you could even make it dynamic. Polygons are so oldschool... ;-)
Have you ever tried this yourself? My (admittedly naive) implementation is lucky to break 5 fps for un-shaded terrain, on an high-end gaming machine, because of the cost of evaluating the noise functions many times per ray.

Yup I have. You need good data structures, clever optimizations, parallelization and many simplifications. I do have a good computer i7 Intel and some pretty fast memory. It could run faster on a GPU but I never bothered. And if looking at that polygonal model of his I say he could get away with only rendering the landscape in a 320*200 window or similar and scale all the buffers (colors, z etc...) to match the rest of the scene.

Edited by jbadams
Restored post contents from history.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by spinningcube
Quote:
Original post by swiftcoder
Quote:
Original post by spinningcube
Why not use the mathematical description (force field) of the landscape directly and raytrace or ray-march it? Your graphical detail would go up a 1000-fold and you could even make it dynamic.

Polygons are so oldschool... ;-)
Have you ever tried this yourself?

My (admittedly naive) implementation is lucky to break 5 fps for un-shaded terrain, on an high-end gaming machine, because of the cost of evaluating the noise functions many times per ray.


Yup I have. You need good data structures, clever optimizations, parallelization and many simplifications. I do have a good computer i7 Intel and some pretty fast memory. It could run faster on a GPU but I never bothered.

And if looking at that polygonal model of his I say he could get away with only rendering the landscape in a 320*200 window or similar and scale all the buffers (colors, z etc...) to match the rest of the scene.


I would love to have a clean solution like ray-tracing but I don't think it is possible for what I'm attempting to achieve. And also the screenshot I showed above has the detail set low in order to make the cracks more obvious... Here is a screenshot with higher detail (still haven't gotten around to fixing the cracks):

0

Share this post


Link to post
Share on other sites

I still think you can use a ray-marching approach but limit yourself to a low resolution, then scale this resolution up to fit the rest of your scene (like the tree or players etc...), then texture and shade it on the gpu with a deferred shading pass. The result will be much nicer and you can realistically run it with a much lower resolution. There will be trickery in up-scaling the image to fit the higher resolution forward rendered stuff (basically an upsampling problem) but you can also use it to do early culling for example. 

Edited by spinningcube
Restored post contents from history.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by spinningcube
I still think you can use a ray-marching approach but limit yourself to a low resolution, then scale this resolution up to fit the rest of your scene (like the tree or players etc...), then texture and shade it on the gpu with a deferred shading pass. The result will be much nicer and you can realistically run it with a much lower resolution. There will be trickery in up-scaling the image to fit the higher resolution forward rendered stuff (basically an upsampling problem) but you can also use it to do early culling for example. I would go with ray marching as it's the simplest one and distance calculations boil down to dist square tests. But ok who would like to have a completely dynamic terrain anyway ;-)


Are there any examples that you know of that use real-time ray-marching on a large scale persistent terrain isosurface? I Googled for it a bit and haven't found anything to convince me that what you are proposing is a better solution than my current one. Implementations I have seen have simple texturing, noticeable aliasing (not as bad as popping), and do not show how the terrain looks with polygon models in the scene. And what about terrain self-shadowing and polygon models casting shadows on the terrain?

Thanks for the reply.

Edit: I just realized that it is funny that you call polygons old-school. I remember the early Novalogic games (Camanche, Delta-force) that used volume ray-casting for terrain. :p
0

Share this post


Link to post
Share on other sites

The terrain you are looking at is a cube and already encoded in a very good structure. As for texturing, lighting etc... That is easier to do in a deferred pass as you can extract normals and uvs and any other parameters from the emitters directly. Terrain self shadowing would be easy as you can shoot out an extra ray into the light direction and check for intersections. Mixing it with other geometry is as easy as you just populate the z buffer from your image, with a texture uploaded on the GPU. Now why there are not more examples? I think there are not more examples because people have not tried it enough that's all.

Edited by spinningcube
Restored post contents from history.
0

Share this post


Link to post
Share on other sites
What about physics? I will need to have localized areas where objects can interact with the terrain. Wouldn't those areas have to be polygonized for the physics system?
0

Share this post


Link to post
Share on other sites
Quote:Original post by c_olin What about physics? I will need to have localized areas where objects can interact with the terrain. Wouldn't those areas have to be polygonized for the physics system?

Nope, no need as you can as well there shoot rays for contacts with the surface or just do distance tests. But hey, if you want just finish it with polys for now and then as a fun experiment check how it would be with raymarching. No hurt in that, right?

Edited by jbadams
Restored post contents from history.
0

Share this post


Link to post
Share on other sites
Thank you for this! I generated my own lookup tables (for use with your paper), but I think yours will be a lot better (I still miss the lookup tables for transition cells, so...).
0

Share this post


Link to post
Share on other sites
[quote name='Eric Lengyel' timestamp='1297204637' post='4771574']
The look-up tables that I said I would release are now available here:

[url="http://www.terathon.com/voxels/"]http://www.terathon.com/voxels/[/url]
[/quote]

Thank you very much! I will be sure cite your work.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0