Idea to optimize rendering of far of terrain.
Members - Reputation: 1099
Posted 13 November 2012 - 07:07 AM
For my current project http://www.gamedev.net/blog/blog-807/cat-252-strife I was thinking of more ways to ceaply render massive amounts of far of terrain (7 km in all directions from the player). Currently I use a LOD aproach where the the resolution of the heightmap reduces with range and at the same time I draw bigger blocks of terrain in one draw call. (for example the terrain the player stands on would be a 128x128 vertice mesh that stretches over 128x128 meters ingame but a a 1024x1024 meter block thats 5 km away would be rendered using a 16x16 vertice mesh. So together with some frustum culling my solution gives acceptable results.
But now ive thought of another. That might allow me to go easier on the LOD (if I LOD too severly mountains in the distance might become a little spiky, not too bad but not ideal either).
What I i was thinking was to build up a skybox over a period of X frames. (lets say 120 for arguments sake). this skybox would contain all far of terrain and as soon as its done it will display it and imediatly start to build a new one.
Il elaborate. I want to render the far off terrain to a skybox texture over a perion of 120 frames (in other words it will render a little bit every frame) and when its done it will set that texture as the current skybox and start again in the background on a new one. seeing as the player in the game wont ever be moving very fast the changes in the distant terrain should not be noticeble over a 2 second timeframe. This method will thus allow you to do fairly detailed terrain rendering for far of terrain without it having a significant performance cost. Or so i think . Of course you cant do frustum culling on the far of terrain if you do this since the player can easly turn 180 degrees in 2 seconds but i even so i think it will work.
with far of terrain in my case i mean terrain futher away than 1.5 km. so in the case of my current project 1.5km - 7 km.
Is this technique used in games allready? is it feasable? what am i missing here.
Thnx in Advance!
Moderators - Reputation: 45763
Posted 13 November 2012 - 07:21 AM
It's often used for reflection cube-maps, etc, where different objects may only receive new reflection textures every few frames.
I'm currently developing a texture-space lighting system where I slowly render the scene's lighting over the course of about 3000 frames -- so that I get super cheap lighting shaders (light-mapped), but also the ability to have "dynamic" lighting ("dynamic" as in, it can change once every 2 minutes).
Crossbones+ - Reputation: 12311
Posted 13 November 2012 - 07:59 AM
Members - Reputation: 1099
Posted 13 November 2012 - 08:14 AM
Edited by Wilhelm van Huyssteen, 13 November 2012 - 08:16 AM.
Members - Reputation: 1561
Posted 13 November 2012 - 09:56 AM
hmm seeing as the payer might decide to run towards and even over a mountain for that matter i cant really write a system that will ensure the seam is always hidden. Although seeing as im only switching over from real to fake at 1.5km its hopefully not noticeable. Il just try and find out.
This is an interesting topic I have also been thinking about, but not yet started to evaluate.
I am worried about the seams. It is enough to have one single pixel wide seam to destroy the effect. Or maybe it is possible to have some technique, like using a border to fill up possible seams.
Members - Reputation: 228
Posted 13 November 2012 - 03:22 PM
What I can say is that the effect is certainly noticable in Guild Wars, however increasing the distance at which you perform the technique could remedy that - this is a six year old game after all. An advantage of your idea is that if you're willing to sacrifice fidelity you can dramatically lower the resolution of these impostor textures to improve the speed at which theyre generated.