Holes in generated brick terrain, unsure on how to fix it

[TheBlackParrot]

The code is in the screenshot, and here

It looks fine here, with buildTerrain(32,32,1,"brick32xCubeData");

but


Holes start appearing inbetween blocks when there's a major height difference, with buildTerrain(32,32,2,"brick32xCubeData");

How can I go about fixing this correctly, because I've spent probably 2 hours already trying to figure it out.

[Ad Bot]

[Zeblote]

Make a custom "cube" that is 64 bricks high

[Treynolds416]

Make a custom "cube" that is 64 bricks high

That's a lazy solution and you should feel bad.

OP, I'll send you some code of mine that does this, you can compare and contrast both methods to see what you're doing wrong

[Zeblote]

That's a lazy solution and you should feel bad.

OP, I'll send you some code of mine that does this, you can compare and contrast both methods to see what you're doing wrong

That's not a lazy solution at all, instead of creating a second sube below the one where the heights are too far from each other (and thus creating 4 additional faces to be rendered and 2 additional faces to be calculated as culled off) you just stretch the cubes.

Results in lower brick count and better performance.

[TheBlackParrot]

That's not a lazy solution at all, instead of creating a second sube below the one where the heights are too far from each other (and thus creating 4 additional faces to be rendered and 2 additional faces to be calculated as culled off) you just stretch the cubes.

Results in lower brick count and better performance.

Except that it will still cause holes if there's a big enough height difference

[Treynolds416]

That's not a lazy solution at all, instead of creating a second sube below the one where the heights are too far from each other (and thus creating 4 additional faces to be rendered and 2 additional faces to be calculated as culled off) you just stretch the cubes.

Results in lower brick count and better performance.

It's a lazy solution. It requires an unnecessary datablock and doesn't work in all foreseeable cases

[Zeblote]

Except that it will still cause holes if there's a big enough height difference

A difference larger than 64 bricks is very unrealistic.

It's a lazy solution. It requires an unnecessary datablock and doesn't work in all foreseeable cases

One datablock is not much. And much better than a few thousand more bricks for a large terrain.

[Treynolds416]

A difference larger than 64 bricks is very unrealistic.

Says who? That's not your code.

One datablock is not much. And much better than a few thousand more bricks for a large terrain.

If performance is that much of an issue and you're forced to use custom datablocks, you might as well just make several sizes and retain a filling process instead of just using the largest possible custom brick in every single gridspace because you're a lazy bum who doesn't take pride in your work.

[Scriode]

A difference larger than 64 bricks is very unrealistic.

Because cubes are realistic?

[$trinick]

You have to build down to the lowest surrounding point.

https://gist.github.com/Trinick/6144856#file-tbp-s-terragen-L46-L68

By the way, that was just an example, not a plug and play fix. You average out values with surrounding tiles, which I didn't incorporate into my detecting lowest surrounding brick math. If the surrounding tiles were lower than that one it would pull it down, making a gap.

[Mr. Wallet]

I recommend the crazy-high datablock method if you plan on allowing real-time terrain deformations, otherwise you will be doing a bunch of math every time you move a brick. In general it's the superior solution for speed and error-proofness (especially if you end up changing something later) as long as you can guarantee the maximum height difference between two bricks in your application. Not sure what everyone has against Zeblote...