Wernesgruner
New Member
I've been thinking a lot about some ways to solve the problems cause by adding a bit of realism to the water in a voxel based game. Here are some the concept and ideas that I came with. Please keep in mind that I will be working on this thread as I try to implement some of these features. So stay tuned as I will add some technical details and talk of the issues that I am encountering here.
World generation :
First of all, we could use a "sea-level" delilimit and set all blocks under this limit to be water. We could use a no-water flag to make sure that mountain valleys, canyon, caves, etc are not submerged when the chunk is being generated. I do not know how terasology’s world generator work, but that was the strategy that I adopted in Minecraft and it worked quite well! Of course Minecraft generator’s has triggers which help create a specific type of terrain with preset parameters, but I’m pretty sure this would be a good way to solve the problem of water world since no infinite water blocks could be generated above x level.
Thus all the water above the sea level *must* be "finite" or only generated in small amounts and it would also be paired with some form of water object/entity or meta-object/entity system.
Generators and sinks :
Infinite water generator. Aka ocean blocks
These block could perpetually generate water by making sure that their surrounding blocks are always at their maximum water level. Those should not be naturally (or artificially?) placed over the sea-level and they could be differentiated from finite water by being salty and/or polluted so as to make finite water more precious.
Moist system
Generators
Certain block could have a "moist" generator determinant and could be used to create glaciers and aquifers. They would create a small amount of water that would be fed to the closest water object.
The moist generator could also be joined to the water object and thus save us the need for constant scanning.
Sinks
All blocks could have an absorption level and above that level, the water could start passing down to surrounding blocks until they reached a sink.
It would basically be some kind of aquifer system. All the water passed to the aquifer from a “dry” block should be sinked. I imagine that water passed from the top should be sinked unless passed from an aquifer block. Anyways this system would require some testing from on my side for further clarification.
Water physics :
Limits paused by the infinite world
Processing power limit
Well let’s admit, water is yet but a feature and it shouldn’t be the feature that requires the most processing power. This is why we cannot have true water physics and thus why I will later introduce the water objects.
That means we need to find a way to simulate:
For small amount of water we could use a water system similar to DF. We use a x level water state system to simulate pressure. Water blocks will have a number assigned ranging x level and always try to average its surrounding blocks. Once it reaches the average level, it stops updating unless disturbed by some event.
Flooding event will most obviously require some way to make it easier on computers when larger events occur.
We could either use Finite Liquid’s solution; slowing down the calculation process or find a better way to manage flooding. For instance we could scan the floodable area and quickly calculate the results instead of letting the water propagate by averaging its water level.
Dynamic water
For a small amount of water released upon the world, you can refer to the static finite water suggestion and the moist sinks.
For all form of permanent or semi-permanent streams please refer to water systems.
Chunks loading/unloading
For performance reasons, it is simply not acceptable to rely on Minecraft’s current strategy: chuck loaders and/or partial loading.
Fortunately, I honestly think that with the proper information, we can extrapolate all the necessary information to make a viable finite water system for dynamic water. I won’t say this is going to be easy, but I already have some design ideas for a pressure system that extrapolates the maximum output from the pressure and the intake/reserve which could be accessed and saved by any chunk which contain a portion of a given water system.
This would allow us to have streams that find its source 30 chunks away, yet we would still be able to determine how much output it can give until the stream have to “end” at the intake, it would also be possible to determine when the water reserve of the hydrographic system deplete and the chunks which contain the reserve would then simply have to be updated when loaded to match the updated data saved by chunk that were loaded more recently.
Workarounds
We could have a regular averaging system for static water, and convert it to a water object once tapped. I imagine we could do the same for streams as well. The first blocks of a stream could be generators and the last one could be sinks and when the stream is not tapped. So yea, we only need realistic water when the player tries to interact with it.
Water system (meta) objects
System objects
A really cool water mechanic will have to work like a real hydrographic system. So why no treat systems as objects? For such system to work, every chunk will need to have information of the system. And this could be done by having a reference to a given system in each block susceptible of being part of an hydrographic system.
This mechanic doesn’t require to “know” the hydrographic system.
We simply need to have some basic information about its:
· Water intake
· Pressure for pressurized systems (piping)
· Reserves
· Its identity
So basically a water block becomes part of a system when it is in contact with blocks that are part of a system, that way we don't need to scan for x condition to establish a system object. It will propagate on the fly.
Water entity objects
There will obviously be some objects that require specific information. Streams will have paths, rivers will have sources, etc…
[To be continued]
Anyways, I will expand and edit this when I have more technical ideas and when I have explored the sources a little more.
I’d love some feedback and it would be great to have some ideas from you guys.
World generation :
First of all, we could use a "sea-level" delilimit and set all blocks under this limit to be water. We could use a no-water flag to make sure that mountain valleys, canyon, caves, etc are not submerged when the chunk is being generated. I do not know how terasology’s world generator work, but that was the strategy that I adopted in Minecraft and it worked quite well! Of course Minecraft generator’s has triggers which help create a specific type of terrain with preset parameters, but I’m pretty sure this would be a good way to solve the problem of water world since no infinite water blocks could be generated above x level.
Thus all the water above the sea level *must* be "finite" or only generated in small amounts and it would also be paired with some form of water object/entity or meta-object/entity system.
Generators and sinks :
Infinite water generator. Aka ocean blocks
These block could perpetually generate water by making sure that their surrounding blocks are always at their maximum water level. Those should not be naturally (or artificially?) placed over the sea-level and they could be differentiated from finite water by being salty and/or polluted so as to make finite water more precious.
Moist system
Generators
Certain block could have a "moist" generator determinant and could be used to create glaciers and aquifers. They would create a small amount of water that would be fed to the closest water object.
The moist generator could also be joined to the water object and thus save us the need for constant scanning.
Sinks
All blocks could have an absorption level and above that level, the water could start passing down to surrounding blocks until they reached a sink.
It would basically be some kind of aquifer system. All the water passed to the aquifer from a “dry” block should be sinked. I imagine that water passed from the top should be sinked unless passed from an aquifer block. Anyways this system would require some testing from on my side for further clarification.
Water physics :
Limits paused by the infinite world
Processing power limit
Well let’s admit, water is yet but a feature and it shouldn’t be the feature that requires the most processing power. This is why we cannot have true water physics and thus why I will later introduce the water objects.
That means we need to find a way to simulate:
- Streams
- Ponds and lakes
- Flooding/Draining
- Hydrographic system in general
For small amount of water we could use a water system similar to DF. We use a x level water state system to simulate pressure. Water blocks will have a number assigned ranging x level and always try to average its surrounding blocks. Once it reaches the average level, it stops updating unless disturbed by some event.
Flooding event will most obviously require some way to make it easier on computers when larger events occur.
We could either use Finite Liquid’s solution; slowing down the calculation process or find a better way to manage flooding. For instance we could scan the floodable area and quickly calculate the results instead of letting the water propagate by averaging its water level.
Dynamic water
For a small amount of water released upon the world, you can refer to the static finite water suggestion and the moist sinks.
For all form of permanent or semi-permanent streams please refer to water systems.
Chunks loading/unloading
For performance reasons, it is simply not acceptable to rely on Minecraft’s current strategy: chuck loaders and/or partial loading.
Fortunately, I honestly think that with the proper information, we can extrapolate all the necessary information to make a viable finite water system for dynamic water. I won’t say this is going to be easy, but I already have some design ideas for a pressure system that extrapolates the maximum output from the pressure and the intake/reserve which could be accessed and saved by any chunk which contain a portion of a given water system.
This would allow us to have streams that find its source 30 chunks away, yet we would still be able to determine how much output it can give until the stream have to “end” at the intake, it would also be possible to determine when the water reserve of the hydrographic system deplete and the chunks which contain the reserve would then simply have to be updated when loaded to match the updated data saved by chunk that were loaded more recently.
Workarounds
We could have a regular averaging system for static water, and convert it to a water object once tapped. I imagine we could do the same for streams as well. The first blocks of a stream could be generators and the last one could be sinks and when the stream is not tapped. So yea, we only need realistic water when the player tries to interact with it.
Water system (meta) objects
System objects
A really cool water mechanic will have to work like a real hydrographic system. So why no treat systems as objects? For such system to work, every chunk will need to have information of the system. And this could be done by having a reference to a given system in each block susceptible of being part of an hydrographic system.
This mechanic doesn’t require to “know” the hydrographic system.
We simply need to have some basic information about its:
· Water intake
· Pressure for pressurized systems (piping)
· Reserves
· Its identity
So basically a water block becomes part of a system when it is in contact with blocks that are part of a system, that way we don't need to scan for x condition to establish a system object. It will propagate on the fly.
Water entity objects
There will obviously be some objects that require specific information. Streams will have paths, rivers will have sources, etc…
[To be continued]
Anyways, I will expand and edit this when I have more technical ideas and when I have explored the sources a little more.
I’d love some feedback and it would be great to have some ideas from you guys.
