sorcerykid wrote: In simplest terms, it would not be a scalable client-server architecture.
Hello Sorcerykid, thanks for your criticism, very good.
I understand what you mean. I had thought about that.
I agree that what we do NOT want is that the server has to recompute a lot of things whenever one player moves a tiny bit or changes their orientation a tiny bit.
Allow me to expand a bit on the idea I had in mind. I think with this idea it would be possible to get most of the desired behaviour (that the server sends to the client only the data the player should be able to see) with relatively little overhead for the server, in the sense that the server doesn't have to recompute things constantly for every little move that every player makes, but only has to recompute some things incidentally, namely when a player digs or places a node at a crucial location.
My idea is based on the topology of the terrain, namely the air spaces that are connected. The complete 3D map of the whole minetest world can be thought of as consisting of two things: (1) the air, and (2) the solid nodes. Where "air" is everything a player's avatar can move through (including water) and "solid" is everything that a player can not move through.
Consider the "air" part of the map. Most of the air in the map would be the air above the surface, which would (typically) be one big connected volume of air. Below ground, there are isolated caves that do not connect to the aboveground air. These are air spaces that are topologically distinct from the aboveground air space and not connected to it. Then there are caves that are connected to the surface, so the air in these caves is topologically the same as that of the aboveground air space. Then there is the air inside houses with steel doors and with no openings that allow access inside. The air inside such a house is also an isolated distinct pocket of air.
For my idea to work, it would probably be necessary to make another step on top of the above picture, namely to also divide up the air spaces in connected cave systems (and in big connected houses) into multiple air volumes, as folllows. Consider a long connected cave consisting of two big rooms A and B, with between them a narrow bottleneck. In this situation the big rooms A and B would become distinct air spaces, with the border between them located at the bottleneck spot. I think finding these distict air spaces divided by narrow bottlenecks can probably be done by running an erosion operation (
https://en.wikipedia.org/wiki/Erosion_(morphology)) on the air spaces in the map, and then finding the connected air spaces in the erosion result.
The result of this would be that the air in the map is divided into distinct regions, so that these distinct regions are either not connected to each other, or are connected only by a narrow bottleneck. Each of these distinct regions of air in the map gets its own unique integer label number. This label number is written into all of the air nodes belonging to that region of air. (I.e. the air node labels are stored directly in the map nodes.) Finding the air regions and labeling each air node in the map is done by the server when the map is generated (and when new map blocks are generated).
The crucial property of this air node labelling is that the air regions and the label numbers are the same for all players, and are independent of the location and orientation of the players. The air node labeling is stored in the map on the server (the same map that is used by all players). The map stores no special information about visibility specific to any one player or any one player's current location/orientation.
As long as players do not build or mine, this air region information in the map on the server remains unchanged.
For each player (client), the server knows the position of that player in the map, and the server sends to that client only the map blocks containing the air volume that the player is currently in, censored so that all the solid nodes that are not immediately adjacent to that air volume are replaced by the node value "invisible". (Note that this does not depend on the direction the player is looking in, i.e. in this respect my idea is probably different from the specifics of Iisu's idea.) Therefore, as long as the player remains inside the same air volume, the data that the server sends to the player remains the same. (For very large air volumes of course, the set of map blocks sent to the client needs to be only a subset of that air volume, namely only the map blocks near the player, same as is doubtlessly done in the current software.) Each client is sent only this "censored" data, i.e. data from which the things are removed that should be invisible to that player. Note that the "censoring" means that nodes are made invisible only in the COPIES of the map blocks that are sent to that client. The map as stored on the server is not specific to one client, contains all data, and is never "censored" so that parts are made invisible.
As a result, the client will only be able to see the solid nodes that are adjacent to the air volume he is currently located in. He will not see solid nodes that are deeper inside the rock. And more to the point, he will not see anything of the air volumes that he is not currently located in.
The reason why I suspect it would be necessary to divide large connected cave-like systems into multiple distinct air spaces at the bottlenecks is that it would be probably undesired for example that a player on the surface can see every last corner of large complex connected cave system that is connected to the surface. And similar when a player is below ground in a large complex cave system, I think he shouldn't be able to see the parts of the cave that are far away and located for him beyond one or more bottlenecks.
When a player mines a node in such a way that a bottleneck is widened so far that two previously distinct air volumes become merged, then the server has to re-label the smaller of the two merged air volumes. When a player places a node so that a new bottleneck is created so that a previously connected air volume gets split up into two (or more) distinct air volumes, then the server has to re-label the air nodes in the old air volume. Note that both of these re-labeling operations are local operations, confined to a limited part of the map.
This is only a rough idea. What to do with long straight 2x1 tunnels is still to be solved. (Maybe use a modified erosion operation that mainly erodes corners, and leaves long straight stretches of air nodes relatively intact.)
Please criticize if I am overlooking things.
On top of this making-invisible of distant air spaces, it would still be necessary that the server also checks that players do not move through walls. That should (I think) be simple. Whenever a player attempts to move into another node, the client should request permission to move there from the server. The server already keeps track of the location of each player. When a client requests to move into another node, have the server check whether that move is legal. If the move is illegal, then disconnect the client.