3
\$\begingroup\$

I originally built the start of my game world with a fully minecraft style structure: chunks, only visible faces rendered, noise, etc. Too blocky. I implement marching cubes. Looks great, horrible to work with:

The problem is when you try to add or remove blocks to the marching cubes as... exactly as they are supposed to... everything gets smoothed. It becomes difficult to raycast on a neighbor and if you do all the blocks around him get changed. Obviously.

I see a lot of marching cubes/metaball looking games that implement area based organic molding. You don't place "blocks" you shape an area or deshape it like Landmark mining etc.

On the otherhand Blockscape and Landmark seem to be a blend of the two? The land starts out marching but you can cut clear square chunks out of it and place square cubes onto it.

How can you make straight corners with marching cubes? Or is it a combination of two entirely different systems?

(UPDATE): There is probably more than one answer to this, does anyone have any experience trying to do this though? I can think of a couple of possible approaches:

  1. Separate player built objects into a separate mesh/object per chunk keeping terrain as terrain. Run smoothing (marching cubes or others) algorithms and normal calculations only on terrain. Would probably need some sort of a half-transparent cube highlighter showing what the cursor is currently selecting. I can see a number of benefits to this system, though feel as if there are some downsides I'm just not thinking of immediately that would crop up if I started coding it...?

  2. Define a "smooth" bool per cube, only assigned at initial calculation of the mesh on any surfaces (floor/ceiling/etc). Any built/added/removed blocks are not re-labelled as "smooth" when generating the mesh use different math for smooth cubes than for blocky cubes. This is what I'm currently working with and it works, but it's still only about a third as smooth as a full marching cube approach would be. Basically I'm average each vertices y value with its surrounding four cubes height(noise) values while never letting it go beneath 0 or above 1 (to stay within the cube). I also had to re-write the raycast click detection to use the surface normals.

  3. Re-code the marching cubes algorithms to work only on the cells I want them to/do what I want them to. This seems like the most difficult but possibly most visually rewarding approach.

or ??

\$\endgroup\$
0

1 Answer 1

3
\$\begingroup\$

I would suggest using Dual Contouring instead of Marching Cubes, for the following reasons:

  • It supports both smooth and sharp features
  • It works well with level-of-detail methods
  • It requires no lengthy lookup tables

The one big caveat is that it is not as simple to parallelize for the GPU, if you are interested in that.

PS: You may get stuck trying to figure out the QEF solver - all it is is an algorithm that finds the point with the lowest sum-of-squared-distance-to-planes. I found a particle-based approach with a fixed number of iterations, which can be unrolled in a GPU kernel/shader, worked quite well.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ This link leads to a LinkedIn-profile now.. \$\endgroup\$
    – Sti
    May 6, 2020 at 20:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .