Return of the Weird Symmetrical Dots
Lodugh opened this issue · 33 comments
Thanks for reporting this.
Would you be able to Pastebin your fml-client-latest.log file and post the link here?
Also, if you happen to know the coordinates from those two screenshots, that would be incredibly helpful as well.
Yep :(
If we can get a seed & coords though, we might be able to squash this one once and for all. 🪲
Uh okay, its a known bug. I saw it the first time in the latest snapshot.. I already deleted the world where I made the screenshots but I just found another one with these formations. The log is too big for pastebin.. but mods that should affect world generation are: Biomes o' Plenty, Thaumcraft, Buildcraft, Climatecontrol(all of them the latest versions)
The log is too big for pastebin.
Okay, here is my fml-client-latest.log: https://gist.github.com/Lodugh/1402a4034380b4a59a86a4b5bb558c44
That's strange - there's no world seed in that log file. When the world loads, RTG should log the world seed, but it's not in there.
@Lodugh Can you post the world seed as well please? Nevermind, saw it in the screenshot! 😉
That's strange - there's no world seed in that log file. When the world loads, RTG should log the world seed
Yes, my thoughts exactly.
Right here at this spot in the log: https://gist.github.com/Lodugh/1402a4034380b4a59a86a4b5bb558c44#file-gistfile1-txt-L5755
should have: [20:09:36] [Server thread/INFO] [FML/]: [RTG-INFO] World Seed: <seed>
Is RTG even the worldtype? Is this maybe a bug in something else?
I use DefaultWorldGenerator and I configured it that way that the default world type is RTG. Furthermore I am very sure that it is RTG because there is no coral or kelp :(. Maybe a problem with Climate Control or the latest snapshot. Just noticed it in my latest worlds..
I can't reproduce this bug with RTG 0.8.0 snapshot-5, BOP 2.1.0.1889, and BiomeTweaker loaded with RTG's tweaks for BOP.
It does happen with just RTG though, I just generated a map and here it is, I can get the seed/coords if any other dev wants them:
Bother, I forgot - what are the biomes, and what's your biome layout system and (if CC) configs? Doesn't look vanilla - is that EB?
It's straight from the dev env (the dev branch), so there's EB "installed" (probably should've mentioned that).
Should I generate a new map to find it with just RTG or is that fine?
Found this while testing for #664, so the same setup:
RTG-1.7.10-0.8.0-snapshot-5
BiomesOPlenty-1.7.10-2.1.0.1889-universal
BiomeTweaker-1.7.10-2.0.182
Default configs
Seed: -5709895089551681541
x = 393, z = -255
x = 3330, z = -2057
Testing for #658 I found this. You need to zoom in and scroll around this image. DOTS. EVERYWHERE.
RTG-1.7.10-0.8.0-snapshot-5 by itself
Seed: -2599301795896205058
you spawn inside of these Mesa biomes.
Im fairly certain this i biome specific, and i have often seen it around mesas. Couldnt it be something like zeno said of dividing by an integer?
That's what I think, and I was going to go into the relevant terrain file, make sure everything's a float before any math ops happen, and see if it fixes it.
The values returned by generateNoise are normal (in the areas where dots are produced), which means that the problem probably lies in ChunkProviderRTG, in provideChuck, as generateTerrain and (both in ChunkProviderRTG) return the "correct" (smoothed out) values as well.getNewNoise
Edit: Take this with a grain of salt, it's possible I messed something up when debugging.
did you change TerrainBase.hills(), Velo? That's come up with errors for me before, and I see it's still got int/float code.
Yup, I did. Changed non-float constants to be floats as well.
Like I said, the values generated from there are smooth as they should be (I can provide examples from debugging), the problem is introduced later in the generation process.
Edit: See edit above.
I did try that (TerrainVanillaMesa), without success. I changed all terrain code in TerrainBase to always cast to float x's and y's when needed but nothing.
I really don't think it's biome specific. In the pic above it happens in Wastelands, Savvanna and with Savanna it continues into Riparian Zone. (from EB I assume).
This is not biome-specific, I've seen it happen anywhere.
Either I'm terribly lucky (unlucky?) and I found a real bad patch of it in the Mesa Biome map from my previous post, or it's just worse in some biomes than others. If it is worse in some biomes, then it is most certainly worse in Mesa biomes.
I understand how it could be caused by math functions on ints, but is there a possibilty it could be something like the noise-floor poking through?
Looking at ChunkProviderRTG, I'm now suspecting the smoothing routines in getNewNoise, which have a complicated scheme for putting several different matrices with different spacing into one matrix, because the spacings are exactly those between the dots: 8, 4, 2, and 1 (no dots). This is the fearsome heart of the legacy smoothing routines, so wish me luck.
If I never return, tell my family I lov- oh wait, they never read this; never mind.
In trying how to understand how the hell smoothing works, I found out a possible optimization of the mix4 function that gets called ~550.000 times with a chunk radius of 12 on a new world (and thousands of times when exploring new chunks).
If my math is correct, with the optimization we do 442 million less divisions, in the above scenario.
So that's good!
Um, yes, that's a lot. But hold off because our fixes will probably collide. So, it is ChunkProviderRTG, and the problem is the averaging. Basically it's filling out a matrix from sparse data. It starts with
X0X0X
00000
X0X0X
And then does an average of the four corners for the 0's with four X neighbors for
X0X0X
0X0X0
X0X0X
And then averages the four X's around each remaining 0 to fill them in. The problem is that the 0's done in the second round should probably be an average just of the two adjacent Xs but they end up being an average of six neighboring X's. So basically every other block is a very different neighborhood. I just changed that for the top level and the "top level" of dots (the ones every eight blocks) went away! So I probably just need to do the same at two more levels - which are coded differently. Wouldn't want it to be easy!
BTW, in addition to a zillion divisions, the routine is also allocating about 700 float[256] arrays for EACH chunk. The most astonishing part is that even with all that the CPU spends most of its time decorating! That's some rabbit hole!
OK - I seem to have opened a HUGE can of worms. I did fix the random dots but ended up with a 1 block high chunk wall-y kind of thing. This seems to have been caused by a savanna plateau in the distance trying to put up a high plateau (not yet sure though), and even at the edge of smoothing the effect wasn't negligible. The "random dots" is basically the smoothing routine scattering that chunk wall around.
So I tried to crank up the effect of distance on smoothing, which I could do since I now mostly understand what's going on and - it didn't fix the problem. BUT - actually, for the most part it looked pretty good! The "blah zone" you often see at biome transitions is basically gone and "biome effects" can go quite close to the edge. It might cause some trouble at mountain boundaries, because I've been using the smooth transitions for sloping approaches to mountains.
So right as we're approaching release for RTG I find we can completely change our smoothing system, and may well want to.
but perhaps this is like one of those Lovecraftian stories where the protagonist goes into a dangerous jungle and emerges with insane ideas to create great and wonderful things. But the potential is so enormous! Cthulhu Fhtagn! wait did I really say that...
Before
After
Fixed in 19fd9d6