Holes in the terrain. Please help

Bug Reports
#21

I tried with 32 and 64bit full versions and with the basic version and it always worked.
Have you tried to download your own file and build it? Maybe WM has made some subtle changes to some parameters when it saved the file? (You have one layout in that file with a falloff distance that is indeed very close to the dreaded 0.250 (0.250 WM-Units… see Project Settings > General Setup))

The error looked pretty reproducible so far. When I tested the file from smoth I got the exact same artifacts in the exact same places.

I don’t think ram is a factor here. WM says it needs about 18MB of ram which should not be problematic. Also, WM would print an error message if you ran out of memory.

#22

I downloaded my file and built it. This is the result: http://img10.imageshack.us/img10/551/screenshot13.png
and the erosion build: http://img135.imageshack.us/img135/9436/screenshot14.png

The result was almost identical when I changed the falloff values to be further from 0.250

I don’t think it’s an issue of the Layout messing up, but a hardware issue, since it works just fine for you. Darn :frowning:

#23

I already took a closer look at he whole thing when I reported the bug. As far as I know it works as follows:
The origin of the bug are 1-pixel-holes created by the layout gen. You usually wont notice them because they are so small.
Since heightfields are nothing more than large arrays of numbers, that hole must be some special number like infinity or NaN (not a number). I experimented with it and found that they cannot be removed by combiners using min and max so they are probably not infinity but NaN. Every other equation or mathematic function that uses that value will return NaN too. This is the reason why the problem propagates along the flow of the erosion.

So the question is when do those invalid numbers occur? For example when dividing by zero. I think this only happens under certain circumstances. My guess is that some very small term in the layout calculation evaluates to zero due to numeric problems, rounding errors and the like.

By the way Stephen fixed a bunch of bugs lately - just so you know that he is in fact alive and working :wink:

#24

Good news everybody!
Thanks to smoths file that reliably reproduced the error, Stephen could track down the bug. The fix will be in the upcoming 2.2 release.

#25

Awesome! Here’s hoping that it will then work on my stupid computer :wink:

#26

WOO HOO I HALPED!

#27

Just a follow up, this bug should be taken care of in the 2.15 patch that’s currently available.

#28