maxhkohl
commented
9 years ago Majeed, You are entirely correct, and really good at what you do!
This was based on the idea that slower water will absorb into a surface, while fast water will run off of it at a higher rate. Thus, I programmed the drop collision code to destroy drops that fall below a certain velocity, allowing still drops to be absorbed. In reality, this assumption would depend on the geology of the surface, but that information is not available to our code.
Engineering wise, I did this simply to save frame rate because after about 2500 drops are on the screen, rendering speed will drop below 20 fps, and this does a great job of culling out immobile drops. I am happy to turn this "feature" off, however it will impact the program's frame rate negatively. We may need to reconsider allowing drops to combine and increase in size (bug #1) in order to maintain an acceptable frame rate.
This is definitely a bug by definition, because as you said our spec is to just let water run off the surface. Our surfaces are just large enough to allow pools to drop at the end, and when that happens it runs off the surface at too slow of a rate.
Kadi0
It looks like that most of the rain does not make it to the flat ground. From a Geo point of view, in general water goes into the ground faster at a muddy ground but not so fast on a rocky mountain. When I was running the simulation, it looks like that the middle of the terrain is holding the water ==> the water sit there for a while ==> the algorithm deletes the rain drop. The normal behavior is for the program to let the water make to to the flat ground and then time the drops for disappearance. I debated this with myself a lot because, Is this an issue or an opinion ? I don't know, but what do you think ?