As I understand it, the entire map is checked for dynamic water when dynamic water is enabled (http://taspring.clan-sy.com/phpbb/viewtopic.php?t=6954). Is there any way to change the rendering engine so that the calculations for dynamic water are only performed where water is actually showing?
If this were possible, I'm guessing that maps such as Supreme Battlefield where only 50% of the map is water would see ~a 50% speed increase in the dynamic water routines. In maps with smaller expanses of water, the performance increase would be even more dramatic. This would let a lot more people enable higher quality water, and sounds like it would be a useful optimization in general.
This could be further extended to only render water where it shows, thus helping everyone's performance even if they only have basic water enabled. Would this be possible/realistic/feasible? I'm really hoping that it is, as even a 10fps increase with dynamic water enabled would be enough to encourage many people to use it (I currently get around 25fps with it on, which is just low enough where I keep it off).
Dynamic water only rendered where water actually is?
Moderator: Moderators
-
2pacalypse
- Posts: 36
- Joined: 26 Apr 2006, 22:44
-
esteroth12
- Posts: 501
- Joined: 18 May 2006, 21:19
eh... if i get more than 20 fps in a typical setting (that is, i won't go below 20fps the whole game except the 10000000000000 particles after a nuke/complosion), i dont care and keep it on... your eyes only get about 16 fps anyway 
and water has to me rendered, because it gets rendered on the minimap, and if it wasn't rendered you would see the ground (which some people may prefer, but i wouldn't)
and water has to me rendered, because it gets rendered on the minimap, and if it wasn't rendered you would see the ground (which some people may prefer, but i wouldn't)
-
2pacalypse
- Posts: 36
- Joined: 26 Apr 2006, 22:44
Your eyes can see more than 16fps... that's a common misconception. Most (all?) people can tell the difference between 16fps, 30fps and 60fps, and it's especially obvious with computer renderings since some artifacts like motion blur aren't present at low framerates. Another benefit of having a high framerate is that it's less likely to drop to unacceptable levels if a nuke is dropped, a huge battle takes place, or your OS decides to start doing things in the background.esteroth12 wrote:eh... if i get more than 20 fps in a typical setting (that is, i won't go below 20fps the whole game except the 10000000000000 particles after a nuke/complosion), i dont care and keep it on... your eyes only get about 16 fps anyway
I'm not saying that water shouldn't be rendered, I'm just saying that "underground" water shouldn't be rendered. I love the water effects, but there's no point to calculating or drawing them if they're out of sight. If there was some sort of test that could be done (if water < land at this point of the map, then don't draw the water or do water calculations), then it'd probably save a good amount of processing power.esteroth12 wrote:water has to (be) rendered, because it gets rendered on the minimap, and if it wasn't rendered you would see the ground (which some people may prefer, but i wouldn't)
-
esteroth12
- Posts: 501
- Joined: 18 May 2006, 21:19
i was talking about the one where it only rendered water where the screen was looking at2pacalypse wrote:I'm not saying that water shouldn't be rendered, I'm just saying that "underground" water shouldn't be rendered. I love the water effects, but there's no point to calculating or drawing them if they're out of sight. If there was some sort of test that could be done (if water < land at this point of the map, then don't draw the water or do water calculations), then it'd probably save a good amount of processing power.esteroth12 wrote:water has to (be) rendered, because it gets rendered on the minimap, and if it wasn't rendered you would see the ground (which some people may prefer, but i wouldn't)
underground water should not be rendered, yeah
The human mind techncially only perceives 26-30 image changes a second, in regards to seeing fluorescent lights lights, that's because you still see the fligckers but they get condensed into one image.
As far as FPS go, 60 FPS seem smoother than 25 because it is essentially.
Remember in real life the so called FPS is unlimited to compare directly, and it's not like the eye take instant snapshots 30 times ina second. the eye sees all the time, but the brain "remembers" one image roughly once every 30th of a second. But this image is composed of everything that happens within that 30th of a second. hence you don't see that car that goes really fast jump from frame to fram, instead you get a sortof motion blurred image giving you smooth motion.
Of course at 30 FPS in game, that means you get 30 perfect images in a second,and even so, some of those frames will get blended together int he same fram in the mind, eventhough it doesn't quite work that way.
now at 60 FPS, the brain gets twice as much information and you don't get frame skip , the brian is able to do a sort of natular motion blur and has a lot more info to interpolate on.
As far as not calculating water under terrain, I don't think there's any implementation of detecting where water intersects with terrain to cull/remove water hidden. and such a interesct detector would probably be slower anyway
As far as FPS go, 60 FPS seem smoother than 25 because it is essentially.
Remember in real life the so called FPS is unlimited to compare directly, and it's not like the eye take instant snapshots 30 times ina second. the eye sees all the time, but the brain "remembers" one image roughly once every 30th of a second. But this image is composed of everything that happens within that 30th of a second. hence you don't see that car that goes really fast jump from frame to fram, instead you get a sortof motion blurred image giving you smooth motion.
Of course at 30 FPS in game, that means you get 30 perfect images in a second,and even so, some of those frames will get blended together int he same fram in the mind, eventhough it doesn't quite work that way.
now at 60 FPS, the brain gets twice as much information and you don't get frame skip , the brian is able to do a sort of natular motion blur and has a lot more info to interpolate on.
As far as not calculating water under terrain, I don't think there's any implementation of detecting where water intersects with terrain to cull/remove water hidden. and such a interesct detector would probably be slower anyway
About the water under the terrain thing,
There├óÔé¼Ôäós no need for working out intersections, etc. I'm not sure exactly how dynamic water works but the best method I can think of would be to divide the water into a grid of sections and hide any sections of water where the land is fully above the water.
The game would probably need to recheck this with each land deformation but there├óÔé¼Ôäós very little speed loss in this check. The same kind of system is used for terrain all the time and if done right the player can├óÔé¼Ôäót notice it.
First post, Yay...
There├óÔé¼Ôäós no need for working out intersections, etc. I'm not sure exactly how dynamic water works but the best method I can think of would be to divide the water into a grid of sections and hide any sections of water where the land is fully above the water.
The game would probably need to recheck this with each land deformation but there├óÔé¼Ôäós very little speed loss in this check. The same kind of system is used for terrain all the time and if done right the player can├óÔé¼Ôäót notice it.
First post, Yay...
Um... we know EXACTLY where the water is. It's based on a pixel value, supplied to the engine by the map. Anything below that is at Y-value 0. So... um... we could draw the water where pixel-value of the grayscale satisfies a pretty simple if loop. You'd want to buffer it out a couple of grayscale values, to leave a little water under each dry area, so that even during dynamic waves, you'd never see the water's edge.
This method would also totally get rid of the water drawing off-map, which due to Spring's practically unlimited sight distance, is one of the major reasons why dynamic water is sucking up so much FPS.
The real question is whether this search (which, um, only has to be done once, but the results must be stored and referred to each frame) is slower than not doing this search and eliminating the water-quads.
The answer to that, I think... is a resounding yes. I just wish I had enough time to spare to write that one up, because it should be very easy.
This method would also totally get rid of the water drawing off-map, which due to Spring's practically unlimited sight distance, is one of the major reasons why dynamic water is sucking up so much FPS.
The real question is whether this search (which, um, only has to be done once, but the results must be stored and referred to each frame) is slower than not doing this search and eliminating the water-quads.
The answer to that, I think... is a resounding yes. I just wish I had enough time to spare to write that one up, because it should be very easy.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
