That is very easy to answer… The path of clouds is not determined by the terrain. The problem is not that water moves. Proceduraly generated motion is no problem. The problem is that water moves along the terrain, i.e. its motion is determined by context. And context is what you don’t have, what you cannot have.
Erosion is easier that way, because nobody will look very closely at whether the direction of your erosion is consistent. It doesn’t even need to be, because it’s not the only geological process at work, so for a dry river bed to go uphill every once in a while is not something very notable. If your river does that… well, there’s a problem.
I’m not sure what you mean by 2D blocks. For all I can tell NMS terrain is a 3-dimensional slce out of a 4-dimensional function. But yes, a system of rivers that doesn’t take context into account is certainly possible. Not even that hard to do. But is that really desirable? Are the occasional gorgeous visuals really enough to offset the jarring feeling you get everytime you see a river flow uphills (which will be lots of times), or potentially even hanging in the air?
Again, not sure what you mean by 2D block. But yes, features strictly isolated to a small area of terrain would be possible, but again I’m not sure it’s worth the effort. You’d have pretty nasty pop-in too, because the entire area needs to be known before the ever-so-small river can actually be generated, which means that you might suddenly find yourself submerged when you were walking on dry land just a second before…
Hmmm… there migh be a misconception about voxels here. Voxels are not directly related to the 3d rendering process (the rendering process itself happens on the GPU anyways, there’s no information coming back from there). They are the information that the terrain will be rendered out of, true, but they need to go through polygonisation first. If my assumption is correct that they’re slicing a 4d function, then the voxels are the terrain. There’s no 2d representation of the terrain like there is for example in Elite Dangerous, where terrain is indeed a 2-dimensional map on which every pixel value is the height of that point. In NMS, I would think that the voxels are the output of the function.
I think I finally see what you’re getting at. This is basically what they do for volcanoes and buildings Although they don’t do that in “pre”. they’re just running a different seed and function to place them, in order to be able to query them on demand when you’re triggering a scan or something like that. The trouble with the rivers is that they are comparatively large features, even small ones, compared to these, and buildings and volcanoes can just stomp the terrain flat if they need it, that isn’t a problem. But for a river, you’d again need to know the terrain they are flowing through, so you have to generate that swath at some point before placing the river.
At least, this would be a solution that is indeed theoretically possible. The question would become, how much CPU does NMS have left to spare to generate the necessary terrain swath when you’re getting close without freezing up the simulation and without producing hte pop-ins I mentioned above. I could very well see small lakes being generated this way, all they’d need to do is dig out some terrain and fill it up with water. Although even that is already much more expensive than the flattening for buildings, because you now have to trace the circumference to find the rightt point for the local waterlevel.
But yes, in this form, it is “merely” a question of available resources, and not entirely impossible.