You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would recommend not to use trilinear interpolation for terrain generation in this project, if you are able to consider such. Perlin and trilerp might be the biggest visual detractors to Minecraft's terrain generation. They are worth avoiding rather than emulating, in my opinion. I do see that you are using glm::simplex instead of glm::perlin for the 2D heightmap, which is great. But trilerp can tarnish the results of even the best noise generator or terrain formula, because it breaks the continuity of slopes and introduces a visible grid pattern. I think the community needs more counterexamples to trilerp, than they need more examples of it.
I put together a quick Minecraft mod a few days ago, to demonstrate a counter-example to the trilerp speed optimization. I haven't run performance metrics on it yet, but the approach doesn't feel any slower than Vanilla trilerp when generating or exploring worlds. The key optimization is to start with the height-based threshold, and any 2D noise that can be pre-generated per column. Then, generate the successive octaves of 3D noise only when you know that (current generated value so far) + (max range of the rest of the octaves including current octave) can possibly cause a cross between a positive and negative final value, i.e. block or no block. If it can't, stop generating noise at that block. Most blocks will get ruled out before any noise is generated, because the height-based threshold precludes noise from affecting the block state at all. Then many will get further ruled out after the first octave. The other difference compared to Vanilla MC is that 16 octaves was more than necessary. Only 4 or 5 octaves were really needed.
The example at the link demonstrates this concept as adapted to Vanilla's terrain generation formula. It would be a simpler case to apply it to a single set of summed noise octaves.
Trilerp (Vanilla MC)
No trilerp. I used a bi-spline for Vanilla biome grid interpolation because I had to interpolate it somehow, but the actual terrain is full-resolution noise.
The text was updated successfully, but these errors were encountered:
I should clarify that the second image isn't a spline per se. The biome borders (including rivers) use a spline, because I adapted this to Vanilla MC's 4x4-spaced biome generation grid. Within the biomes, it's full-resolution 3D noise.
Either way, feel free to hit me up for pointers on the code I linked, or anything about noise generation in general. Happy to help in whatever ways. I'm K.jpg on your discord.
** Suggestion Title **
Don't use trilinear interpolation for terrain generation
** Describe your suggestion **
Noticing commit c2b95e4 from yesterday.
I would recommend not to use trilinear interpolation for terrain generation in this project, if you are able to consider such. Perlin and trilerp might be the biggest visual detractors to Minecraft's terrain generation. They are worth avoiding rather than emulating, in my opinion. I do see that you are using glm::simplex instead of glm::perlin for the 2D heightmap, which is great. But trilerp can tarnish the results of even the best noise generator or terrain formula, because it breaks the continuity of slopes and introduces a visible grid pattern. I think the community needs more counterexamples to trilerp, than they need more examples of it.
I put together a quick Minecraft mod a few days ago, to demonstrate a counter-example to the trilerp speed optimization. I haven't run performance metrics on it yet, but the approach doesn't feel any slower than Vanilla trilerp when generating or exploring worlds. The key optimization is to start with the height-based threshold, and any 2D noise that can be pre-generated per column. Then, generate the successive octaves of 3D noise only when you know that (current generated value so far) + (max range of the rest of the octaves including current octave) can possibly cause a cross between a positive and negative final value, i.e. block or no block. If it can't, stop generating noise at that block. Most blocks will get ruled out before any noise is generated, because the height-based threshold precludes noise from affecting the block state at all. Then many will get further ruled out after the first octave. The other difference compared to Vanilla MC is that 16 octaves was more than necessary. Only 4 or 5 octaves were really needed.
See code example: https://github.com/KdotJPG/Simply-Improved-Terrain/blob/af61d86022d48fd32fddbe05e87aabaffdc591b8/src/main/java/jpg/k/simplyimprovedterrain/world/gen/NoiseChunkGeneratorImproved.java#L403
The example at the link demonstrates this concept as adapted to Vanilla's terrain generation formula. It would be a simpler case to apply it to a single set of summed noise octaves.
Trilerp (Vanilla MC)
No trilerp. I used a bi-spline for Vanilla biome grid interpolation because I had to interpolate it somehow, but the actual terrain is full-resolution noise.
The text was updated successfully, but these errors were encountered: