Pixophir It might be a good tutorial... but it's obviously not for a quick check… you have to dive in, figure it out and install the missing stuff… it's time consuming. Is there a difference — Win 7 or Win 11 — which one is needed? I'll try to make time in the next few days.

I certainly get it, no worries. I mean, we'd obviously need some deeper C++ understanding here that I did not mention. Nevertheless, if you like to dive in, there you go. Have fun :-)

@Tomcat

The Wicked Engine is a very cool project with lots of high tech, but still over my head 🙄

    Pixophir To the greatest regret, I can't help in the near future. It turns out that you have to register with M$ to work with Visual Studio… If you can't find a helper, I may do it later, perhaps in time, but for now I'm not morally ready… I'm extremely sorry.

    Pixophir I can do that (VS2017, 2019, or 2022), but not this week, as I'm away at a conference. But I can do it next week.

    7 days later

    Refactoring. Pls. stand by :-/

    Am currently simplifying the conversions between raster space, the space represented by the raster of the spacial data structure which are basically integers for the positions in heightmap textures, and world space, which is the usual floating point stuff one deals with in any 3d application.

    Before there was the possibility to extend a terrain in all directions, but that lead to conversion problems I could not really wrap my brain around. Si si, somos aficionados ...

    So, in future I will start any quad tree's raster at 0,0,0 and extend it out to max, which is limited to power of 2 sizes. That makes things considerably easier, also when I think of presenting everything to people who probably just want to slab in a bunch of textures and expect it to just work.

    Since I also have a new home to build, this may all take a bit longer.

    Lesson learnt: Do not say it will be done until it is done.

    4 days later

    The last overworking got me one step forward. That's from the rim of the canyon where I stood :-)

    Never mind the flat shading. Shown is one terrain tile made from a 16bit heightmap 4096*4096 pixels, but it works well up to a tile size of the maximum the graphics card can digest. My test data is SRTM (Shuttle Radar Topographic Mission) data, shown is a part of the Himalaya, distance between two posts is about 90m. Purposefully exaggerated to better show the boxes that cover the terrain for view frustum selection.

    The white lines are bounding box of the whole tile, the light blue ones are all the boxes of each node of the spatial data structure, the coloured ones are the per frame selected lod levels as seen from camera position.

    Sending two 0s away gives us:

    with the bounding boxes of the lod levels.

    A close-up of a valley gives an impression of what the terrain lod is planned for (no planetary curvature yet, or any sophisticated shading, that's future music for now):

    11 days later

    So, the base algorithm is finally working.

    https://github.com/BaronVerde/cdlod

    Tagging @Haystack , whenever you like.

    A 4k heightmap texture comes with it. Ask me if you want a 16k texture, or search SRTM 90m data download, select the region you want, choose ARC ASCII as format, and see my other rep srtm-converter for how to generate .png tiles from the SRTM ASCII data. Also, try noise textures you may have somewhere. Eventually tweak the HEIGHT_FACTOR in settings.h.

    Loading of a large heightmaps takes a few seconds, though that's going to change. Please mark the b* and krams directories under src as exclude from compile or you get multiple definition errors. These are just backups from working states.

    It is only a single heightmap texture for now, and only flat vertex shading. No cosmetics. If you use an own heightmap, make sure it is 16bit-grayscale png of power-of-2, edit RASTER_MIN and MAX values in src/applications/cdlod/settings.h, and add a .bb text-file next to the heightmap texture. Look into src/renderer/renderer.cpp and change the filename there. Don't add .png. Attention, though there is a vector defined there, only one texture is loaded.

    Next steps:
    Comb the code. There are quite a few implicit conversions I must get rid off. - done -
    Texture compression. - scrubbed, using half floats and uint16_t -
    Parametrize and correctly calculate raster-to-world sizes and distances. My poor brain ...
    Abstract texture types and bit depths and quite generally heightmap sources.
    Build a data structure for heightmaps, and load/unload them asynchronously.
    Render relative to eye. That means an own terrain camera.

    Then: try to get it into the Godot scene tree.

    Then proper texturing, rendering, evtl. cascaded shadow maps that fit the lod levels and ranges, collisions, placing of game objects.

    Need a beer.

      Effect of a resolution multiplier that equally divides the space between two heightmap posts and thus "fakes" a higher resolution than there actually is. It is just a linear interpolation. Considerably improves visual experience (look at the detail in the distance), raises number of triangles rendered, and adversely affects performance :-/

      4*resolution multiplier, 11 million triangles per frame, frame rate drop from around 5000/s to 1000/s compared to the other screenshots which are from the same heightmap.

        Pixophir Considerably improves visual experience ... and adversely affects performance :-/

        Look, sometimes it's worth it, ok? 😉

        1ms vs 0.2ms is not a big deal.

        Certainly. Specifically comes in handy when using procedurally generated maps from noise or fractals. And there are other methods to control the density in a distance. Otoh, proper shading isn't yet done, nor shadows. So, it will not stay that comfortable.

        But of course, having a higher resolution heightmap right from the start would be best. The resolution in the example is also not exactly game-friendly, it is around 90m between posts. A small thorpe or village would just be a speck from that perspective.

        Have also experimented with different methods to calculate the normals, which is done on the fly in the vertex shader so I don't have to do normal maps for the terrain. Will offer several methods further down, to control better the "crispyness" of the image.

        Huge work. Unfortunately, all the landscape generators do not take into account the principle of the formation of rivers. Rivers are not just irregularities filled with water. Until hydrodynamics in terrain formation is implemented, even the best generators will only be able to automatically create a lunar landscape. Or require a lot of manual revision.

        Thanks :-) Yeah, my stuff it just a renderer for heightmap images that stem from elsewhere. I will do an interface that people can use to adapt their own heightmaps.

        But there is quite some work on modelling of drainage systems. Look at this, for instance:
        https://hal.archives-ouvertes.fr/hal-01339224/document

        Update:
        OpenGL built-in texture compression for heightmap (RGTC) is scrubbed. Too lossy.

          They have an implementation, they write.

          And there's more work out there. I believe Outerra has made something similar. And I have read papers in which they try to mimic plate tectonics. Don't have the time to gather the information again.

          Bit I'd say the algorithm in the above paper could be implemented right away.

            Pixophir They have an implementation, they write.

            It is all very academic. Until the implementation in game engines, apparently, very far away.

            Bit I'd say the algorithm in the above paper could be implemented right away.

            I definitely can't pull off such a job. 🙁

            Pixophir I don't see a makefile, or CMakeLists.txt, or similar to describe the source dependencies. Do I need to make one?