Dynamic water
Moderator: Moderators
Dynamic water
I did some experiments with dynamic water levels and wanted to know devs opinion on the problems/potential of such a thing. First a video of the "current state": https://youtu.be/a0gck2pCOyY
In the video you can see water flooding the map. Sorry for the resolution/quality, it got lost in translation, should select better formats next time. The idea is that water now takes into account ground height and reacts to terraforming (flows of cliffs, floods areas if they are open, etc).
In case you think this has potential (you do not know any reason why it would not work at some later point due to how code is structured/assumptions made/etc) I can continue "playing" with it and fixing/improving the code I made.
What I would do next:
- make the code "nice" so that I can share
- ships "float" and "move" on the new water level
- check if I can improve performance (might need some LOD approach, now it is too slow for large maps)
- improve the rendering (although my opengl knowledge is a bit old)
So, comments/suggestions/critics are welcomed!
In the video you can see water flooding the map. Sorry for the resolution/quality, it got lost in translation, should select better formats next time. The idea is that water now takes into account ground height and reacts to terraforming (flows of cliffs, floods areas if they are open, etc).
In case you think this has potential (you do not know any reason why it would not work at some later point due to how code is structured/assumptions made/etc) I can continue "playing" with it and fixing/improving the code I made.
What I would do next:
- make the code "nice" so that I can share
- ships "float" and "move" on the new water level
- check if I can improve performance (might need some LOD approach, now it is too slow for large maps)
- improve the rendering (although my opengl knowledge is a bit old)
So, comments/suggestions/critics are welcomed!
Re: Dynamic water
1) This looks crazy
2) There are many places in the code which rely on water being on level 0, I guess you now have a separate water level array?
3) While flowing is cool, it can be quite complex, and having it affect units (move ships etc.) can be really hard, have you tried a "communicating vessels" approach?
2) There are many places in the code which rely on water being on level 0, I guess you now have a separate water level array?
3) While flowing is cool, it can be quite complex, and having it affect units (move ships etc.) can be really hard, have you tried a "communicating vessels" approach?
Re: Dynamic water
4) literal floodfill, cute
5) assuming you change the water level globally: now the entire map requires repathing
6) assuming you change the level per square: now water rendering becomes a nightmare
7) moving ships to a new level seems like the easy part if you don't model physics too closely
either way, happy hacking and happy new year
5) assuming you change the water level globally: now the entire map requires repathing
6) assuming you change the level per square: now water rendering becomes a nightmare
7) moving ships to a new level seems like the easy part if you don't model physics too closely
either way, happy hacking and happy new year
Re: Dynamic water
Thanks for the comments. Some observations:
1) Crazy good or crazy bad ?
2) Yes, now I have an array with water level and an array with flow "speeds" (needed for the water simulation). The simulation is not "physical" it is meant more to obtain some nice/acceptable result.
3) Although it would be nice the flow to affect ships I think it is ambitious enough to make this work as it is. My plan was to only adjust the height of floatable/hover units. I do not get what you mean by "communicating vessels"
4) Flood fill with "some" waves. The model has a "wave attenuation". The closer to 1, the harder the water will stabilize. The closer to 0 the more it is like a gelo.
6) Yes, this was my plan, that's why I have in plan to improve the rendering.
7) Already did that, with very "brute force" approach (changed in 2-3 places which seemed like what I want). Now the shipyards and ships "respect" the dynamic water level, but the ships don't move.
I will continue to hack this (real life allowing) and will see how far it gets. The biggest "risk" is that it will end up more like a "tech demo" rather than something usable by most of the people due to performance (re-pathing, flow simulation). But would still be cool ...
Happy new year to you too!
1) Crazy good or crazy bad ?
2) Yes, now I have an array with water level and an array with flow "speeds" (needed for the water simulation). The simulation is not "physical" it is meant more to obtain some nice/acceptable result.
3) Although it would be nice the flow to affect ships I think it is ambitious enough to make this work as it is. My plan was to only adjust the height of floatable/hover units. I do not get what you mean by "communicating vessels"
4) Flood fill with "some" waves. The model has a "wave attenuation". The closer to 1, the harder the water will stabilize. The closer to 0 the more it is like a gelo.
6) Yes, this was my plan, that's why I have in plan to improve the rendering.
7) Already did that, with very "brute force" approach (changed in 2-3 places which seemed like what I want). Now the shipyards and ships "respect" the dynamic water level, but the ships don't move.
I will continue to hack this (real life allowing) and will see how far it gets. The biggest "risk" is that it will end up more like a "tech demo" rather than something usable by most of the people due to performance (re-pathing, flow simulation). But would still be cool ...
Happy new year to you too!
Re: Dynamic water
Very cool, but looks like it will be a lot of work to get a usable result. Could this allow for multiple water levels like mountain lakes?
-
- Posts: 823
- Joined: 21 Oct 2008, 02:54
Re: Dynamic water
Very nice. However it's a bit awkward given that there is two types of water in that demo. Here are some questions:
Is there going to be any "source" and "drain" when it comes to water usage?
Is water the only fluid you have in mind when comes to implementing this?
Is there going to be any "source" and "drain" when it comes to water usage?
Is water the only fluid you have in mind when comes to implementing this?
Re: Dynamic water
My thoughts exactly. Maybe a first step would be to allow defining multiple (static) water levels defined by areas (from Lua/mapconfig)?The Yak wrote:Very cool, but looks like it will be a lot of work to get a usable result. Could this allow for multiple water levels like mountain lakes?
Re: Dynamic water
@The Yak: it was already some work (~16 h to be more precise, and as I have a daily job this is quite "some" work ). Yes mountain lakes should be possible with this dynamic water. The map should have a "water height map".
@supermario: what do you mean 2 types of water? There is only the dynamic water. I think what you "see" as water is the map texture which is different for what is supposed to be "underwater". That is a map issue and considering an improved water rendering (for ex rendering water on the sides of the map, as now you can look "under the water") should not be a problem.
Source and drain can be "implemented" by changing the water level. How is this done (lua probably) and how it will look is a different issue.
It is called water more as a convention. The engine expects interactions with one fluid. I think if I will identify all the places where that happens it will be easier to extend to multiple fluids, but this is not my goal.
@The Yak,Gajop: the problem has multiple components:
A) water level computation (DONE although not perfect)
B) make units aware of new water level (moving for all units, shooting under/above water)
C) rendering (DONE although not perfect)
For me now the hardest problem is implementing B). The fact that I do not know exactly where to go and change the code, is not affected significantly by the fact there are 2-3 water levels (like lakes) or NxN water levels.
I will keep things "separate" in the sense there will be:
I) water computation module (which takes current water level and does updates or not)
II) water rendering module
III) update pathing (if needed)
IV) changes to moving/shooting to take into account the water level
Then if performance is not good for the generic case, I,II could be replaced by something simpler.
Good observation about Lua, I am sure it will come at one point but if manage to implement it only engine side I am sure someone making the Lua adaptations would not be a problem.
Edit: as a note I would expect that this will take a long time (months). I am planning this for couple of months and worked here and there, but progress will be slow. Will try to make a public branch on git hub, but cleaning the code is less interesting than making new features so...
@supermario: what do you mean 2 types of water? There is only the dynamic water. I think what you "see" as water is the map texture which is different for what is supposed to be "underwater". That is a map issue and considering an improved water rendering (for ex rendering water on the sides of the map, as now you can look "under the water") should not be a problem.
Source and drain can be "implemented" by changing the water level. How is this done (lua probably) and how it will look is a different issue.
It is called water more as a convention. The engine expects interactions with one fluid. I think if I will identify all the places where that happens it will be easier to extend to multiple fluids, but this is not my goal.
@The Yak,Gajop: the problem has multiple components:
A) water level computation (DONE although not perfect)
B) make units aware of new water level (moving for all units, shooting under/above water)
C) rendering (DONE although not perfect)
For me now the hardest problem is implementing B). The fact that I do not know exactly where to go and change the code, is not affected significantly by the fact there are 2-3 water levels (like lakes) or NxN water levels.
I will keep things "separate" in the sense there will be:
I) water computation module (which takes current water level and does updates or not)
II) water rendering module
III) update pathing (if needed)
IV) changes to moving/shooting to take into account the water level
Then if performance is not good for the generic case, I,II could be replaced by something simpler.
Good observation about Lua, I am sure it will come at one point but if manage to implement it only engine side I am sure someone making the Lua adaptations would not be a problem.
Edit: as a note I would expect that this will take a long time (months). I am planning this for couple of months and worked here and there, but progress will be slow. Will try to make a public branch on git hub, but cleaning the code is less interesting than making new features so...
- PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
Re: Dynamic water
That raised me concerns with performance. That appears to be something that is exceedingly heavy on computation and also which has game impact, thus something not just graphical that you can opt-out on a not-uber computer.
That raises me concerns, also, with technical implementation. I can imagine a ton of hard-work to introduce it and uncomfortable levels of new bugs creeping up with the new changes.
Having said that, it looks really cool.
That raises me concerns, also, with technical implementation. I can imagine a ton of hard-work to introduce it and uncomfortable levels of new bugs creeping up with the new changes.
Having said that, it looks really cool.
Re: Dynamic water
To quote you:PauloMorfeo wrote:That raises me concerns, also, with technical implementation. I can imagine a ton of hard-work to introduce it and uncomfortable levels of new bugs creeping up with the new changes.
We need new features if we want Spring to spread :)PauloMorfeo wrote:If Spring had remained exclusively a remake of oTA it would have ended up more polished and less fragmented but it would have died out by now.
- PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
Re: Dynamic water
And adding to that I can tell you that I fully agree. I thought of exactly the same as you wrote and even had some text along those lines but ended up not posting. I didn't find the proper words to express myself because it is a sensitive situation.gajop wrote:...
To quote you:
...
We need new features if we want Spring to spread :)
Stagnating will kill Spring eventually (no appealing new challenges for the software developers, no appealing available features for content-creators). But making changes carries the risk of ruining developers' commitment* (who could be doing something else more useful) and the potential bugs / broken-backward-compatibilities might end up causing more harm than good.
I expressed myself with:
Because I really meant that. It raises me concerns. I don't necessarily think it is a bad idea. I don't know well enough the inner-working of that water thing to predict well the performance impact nor the engine structure to predict well the complications.PauloMorfeo wrote:raises me concerns
* If I remember correctly, after the SY clan abandoned the project and left it with other people, 2 (or more?) of the software developers started preparing a re-write of the engine. That fully consumed them and those 2 developers ended up disappearing - either because of being worn down chewing more than they could handle; because of the frustration/embarrassment/humiliation of going back to the community (or even themselves) to say "I was wrong, I want to give this up"; or whatever.
I don't want to see developers ending up bogged in something that consumes them to the point that they disappear, I don't want content creators constantly struggling with a buggy and ever-breaking engine. .. And I also don't want to see Spring stagnate too. Tricky one, isn't it?
Re: Dynamic water
First, I am not a spring developer (yet), so can't do something else more useful. Becoming one is rather hard if you just need to fix bugs (not interesting enough). If you work on something catchy you get to know the code and how it works and maybe later get involved in more useful stuff.PauloMorfeo wrote:But making changes carries the risk of ruining developers' commitment* (who could be doing something else more useful) and the potential bugs / broken-backward-compatibilities might end up causing more harm than good.
Performance is currently bad (I said it, and I repeat it in case people would get to enthusiast), but will not optimize until I believe it can be "integrated".PauloMorfeo wrote:I don't know well enough the inner-working of that water thing to predict well the performance impact nor the engine structure to predict well the complications.
So, this is why I will not push/want/imagine this will be merged for the foreseeable future. It is a "tech demo". Will not even share it until I am satisfied with it. This way "normal" developers don't need to be consumed, but it is a development of spring. If it ends up very good, would be glad to see merged/used in games.PauloMorfeo wrote: I don't want to see developers ending up bogged in something that consumes them to the point that they disappear, I don't want content creators constantly struggling with a buggy and ever-breaking engine. .. And I also don't want to see Spring stagnate too. Tricky one, isn't it?
Also, hopefully it can show other people that cool things can be done with spring with a little effort.
Re: Dynamic water
push your changes to github / create a pull request to get better feedback than heremalric wrote:Performance is currently bad (I said it, and I repeat it in case people would get to enthusiast), but will not optimize until I believe it can be "integrated".
i'm not sure if "dynamic water" can be implement full-featured with no performance impact: this makes me think about plugins for the synced code of spring which can be enabled or disabled by the game / gameoptions.
Re: Dynamic water
For now I need to work more on it. Will do a push when it is closer to be ready. For me the feedback that I already got was what I was looking for.
Yes, the option approach should work as the functionality can wrapped around some simple functions (ex: GetWaterHeight which returns 0 for default case or some value in case dynamic water is used)
Yes, the option approach should work as the functionality can wrapped around some simple functions (ex: GetWaterHeight which returns 0 for default case or some value in case dynamic water is used)