u/jimothy_clickit

Doing a little exploration of my work on applying the GLiM global lithography data set and the SoilGrids 250m/px data set to my planetary terrain. The technique is very simple - really I'm just using perlin to scatter the normal I use to sample (converted to lat/lon, then hashed into the lookup texture, then finally to the bindless texture tile), but after a ton of tweaking of some perlin values, I was quite shocked at how good it actually looks. My perlin experience consists all of about three or four days of actual exposure and research, so I'm at the tip of the iceberg. Consequently, there are so many issues, and it's not nearly as performant as I want it to be, but after a couple days of fiddling around, I'm happy with where it is so far.

Raymarching on a true-to-scale globe, lots of terrain streaming, very basic light direction, but really coming along. So ready to replace this height-based coloring with some actual textures soon.

The short of it is this - I have an icosahedral world that subdivides at runtime, instancing each visible node using the same triangle grid. This works great, but I'm fighting some hard-to-pin-down aliasing issues.

My initial theory was that a lack of mips was causing distant pixels to oversample for what the screen could actually display, so I fixed that, and now my texture tiles have mips.

My next thought was that I should select the mip analytically, by calculating camera distance to the pixel, and then clamping the log2(dist / "random number") example below:

float terrainLOD(vec3 worldPos) {
    float dist = length(worldPos);
    return clamp(log2(dist / 50000.0), 0.0, TERRAIN_MAX_MIP);
}

I debugged this by converting the lod / TERRAIN_MAX_MIPS to a simple greyscale value, just to sanity check, and it looks like this:

https://preview.redd.it/n5ia08libd9h1.png?width=2529&format=png&auto=webp&s=bf6de6e59a5d36103aa69e7dc1293e1d7579bdb6

Great, we've got mips and that looks about how I'd expect. The value lightens as the mip chain lengthens. Good.

Now, what's really baffling me is that the aliasing problem is not only still present, but still as pronounced as when I first started. At high altitude, it's especially wretched.

https://preview.redd.it/iji3690sbd9h1.png?width=2527&format=png&auto=webp&s=77aa601a9d9879c2550c423e712e5b0db663c87f

I briefly went down a path of thinking that this was a mesh issue, that triangles were too close together and were thus causing some degenerate/sub-pixel issues, but that didn't really hold water either, because the terrain is aliasing closer than where I'd expect a mesh problem to be concentrated - at the horizon line.

https://preview.redd.it/zm0p8ys5cd9h1.png?width=2520&format=png&auto=webp&s=65bb7838d6ecd41d29de1328be97412971567778

So...I'm sort of running out of ideas here. This is my first time really working with mips and while I can clearly see they're there. I can even force the terrain to render solely with a certain mip level, but I still see the aliasing.

Also - shadows are ray marched, and I have tried to do ray marching with a mip level other than 0. It doesn't really make a difference. I still encounter the aliasing. It does seem to go away if I get rid of the shadows altogether, which leads me to my last theory - is this just a limitation of having huge draw distance on shadows? Should I look at some kind of proper AA method for this to smooth things out a bit?

Any ideas would be appreciated. Thanks in advance.

What are some good recommendations on spare tire mounts that lay flat in the bed? I want to get a hard cover for the top of the bed (Diamondback or something similar) and if the tire is upright, then I can't put that on. I haven't actually seen much out there from some light searching, so what are folks using?

Thanks in advance!

I've been working on a real-world/real-scale global terrain engine (Vulkan, C++) for the better part of a year now, having undergone many many iterations, but always improving. This is my somewhat basic take on the notion of continuous LOD in the context of my icosahedral, subdividing world. I'm really happy with how it came out, but I will say that the algorithmic ordering of which vert moves where was quite painful to fully iron out.

I'm still playing with some morph start/end parameters, but I think the length of transition looks good and is practically unnoticeable when not looking at the mesh itself, which is what I was aiming for. Also, one of the biggest tricks was ensuring that there were no tile gaps during and after the morph, which has been a recurring pain for me as the project has matured (increasingly "solved" though these days).

Morph factor is calculated on the CPU per instance just before instances are created and sent to the GPU. I envision a more compute driven pipeline in the future, but it's still very fast and plenty workable for now.