infinte view distance simulated with skybox

[MisterE]

I wonder what people's thoughts are on the practicality of simulating infinite view distance with the skybox. assuming you have a heightmap of the whole map (like assuming you are using mg_rivers), could one build a 3d scene programratically using the heightmap, and then set the skybox to a render of that? I assume that it would require making or using a simple 3d engine to render the scene from the heightmap, but that is something that was solved with early flight simulators, so studying how they did it should make that feasible. the 360 terrain view can be generated outside minetest using a separate (custom?) engine, and then we send the resulting skybox to the player every minute or so using minetest 5.5's dynamic media api, with ephemeral media set to true. the api allows sending media to one player only.

I'm sure there are problems with this idea the question is, what are they, and how much work would go into solving them. Please only respond with considered answers, not: 'give up, it aint happening'. worst case, this is just a thought experiment, please treat it as such.

[v-rob]

To quote myself:

Part of the problem with [infinite simulated viewing range] is that it only previews generated terrain. If your map has a gigantic city or a huge crater from TNT blasts or a sprawling town, it would only show what the map originally looked like. For small-scale buildings and suchlike, this isn't a problem, but largely modified maps aren't represented well.

Don't get me wrong, I'd like a huge viewing range, but this does seem to be a problem to any implementation that only looks at the original terrain.

Instead, if your computer/server can handle emerging lots of mapblocks from disk fast enough, I think a better implementation would be to render far away parts of the map in lower detail.

[Gael de Sailly]

It's interesting and probably the first time it is proposed.
It seems a bit hacky but I think it could work and probably not need any change in the engine.
It could work for core mapgens too, for which terrain height is easily predictable if you can generate perlin noises with the appropriate seeds.

Don't get me wrong, I'd like a huge viewing range, but this does seem to be a problem to any implementation that only looks at the original terrain.

The heightmap could be generated at first and then be auto-updated whenever something is modified on the map, using callbacks like MTSatellite does.

Determining the colors for the landscapes will also not be easy, especially for places that have not yet been generated, and a simplified approach will be needed but could be based on the biomes.
About the rendering, I think we may be disappointed by the speed at which the skybox will become misaligned with the closer landscape when the player is moving. We can not consider the distance to be near-infinite, and the skybox rendering has to start at something like 200-300 nodes (it's difficult to get Minetest render farther in all directions). At this distance, a move of the camera by 5 nodes is absolutely not negligible and the skybox will appear flagrantly misaligned, unless the refresh delay is very low. However, it will look good when the player is not moving.

[MisterE]

you might be able to get some decent update times. After all, you are doing a very simple render in fairly low detail of a terrain mesh, something that weak computers can handle with ease, I think. (old games did it). then you just have to send the image to the client, which could be an issue in multiplayer with high latency, but would work without any latency in singleplayer, and probably be acceptable in MP with low lag.

[Linuxdirk]

Ages ago we had this ("farmesh") but it was removed in 0.4 because the implementation was bad an became incompatible with new rendering. I wonder if something like this would even be possible nowadays.

But I think "cheating" larger render distances isn't the way to go. Nodes far away should be rendered and displayed (with lower LOD the further away of course). During testing the best I was able to achieve was around 280 nodes which is good in Minetest but ridiculously small compared to other voxel-based games.

[c56]

Instead, if your computer/server can handle emerging lots of mapblocks from disk fast enough, I think a better implementation would be to render far away parts of the map in lower detail.

i think you would just need to approximate it

[Blockhead]

I know it's not the same bit anyone interested in this may also be interested in larger view distance as of 5.7. My experience with that is that unless the server storage and CPU can keep up, it takes a long time to load the terrain in. Others have mentioned you would probably use LOD meshes. The tricky part is keeping the mesh/skybox up to date.

[proller]

https://www.youtube.com/watch?v=4Tgc7W-UD7E

[hex]

Regarding OP's question: I did this years ago, it worked but clients currently do not free old skybox textures and just leak them, so the client would eventually run out of RAM and crash.

1670240757009.jpg (197.19 KiB) Viewed 167 times

1670240755028.jpg (497.95 KiB) Viewed 167 times

zxc.jpg (150.77 KiB) Viewed 167 times

I had an emulator of mgv7 set up, using noiseparams queried from the config. The terrain was rendered using simple raymarching, only height was sampled. 3D noises were approximated with a binary search.

One challenge when doing this is that the engine combines map and world seeds using 64-bit math and then truncates them to 32, so you have to use FFI's "unsigned long long" or a bignum library to get noise identical with the mapgen's. This was a rather obscure thing to figure out.

The raymarching wasn't very expensive because it was actually 2D (in polar coordinates), it could be timesliced, and because stationary clients do not need new skybox frames. If the texture collection bug were fixed, then a low-res [png layer over a proper skybox could actually work. Outsourcing the rendering to a C library or even a server-side OpenGL context would make this very cheap.

[Blockhead]

https://www.youtube.com/watch?v=4Tgc7W-UD7E

Farmesh ideas are pretty cool, though not quite the idea in this thread. It's probably about time we had a new farmesh thread. I'm kind of guessing here but I think that the farmesh = 4 indicates 4 levels of detail that are applied base on distance? :

1. Normal terrain, up-close
2. Stone approximation in 4^3 nodes as cubes
3. Stone approximation in 8^3 nodes as cubes.
4. Stone approximation with vertices only.

That last I think I have seen before, probably from you, in another video.

Edit/P.S.: Oh, also, as the video had no sound, I put this on in the background while I watched

Regarding OP's question: I did this years ago, it worked but clients currently do not free old skybox textures and just leak them, so the client would eventually run out of RAM and crash.

The raymarching wasn't very expensive because it was actually 2D (in polar coordinates), it could be timesliced, and because stationary clients do not need new skybox frames. If the texture collection bug were fixed, then a low-res [png layer over a proper skybox could actually work. Outsourcing the rendering to a C library or even a server-side OpenGL context would make this very cheap.

Very cool. Hopefully it's not too hard to fix that memory leak at least, before thinking about putting the skybox renders in a fork and possibly (not holding my breath) mainline.