Game Algorithms

Re: Terrain LOD Again

csharp1024 — Wed, 12 Aug 2009 11:20:27 GMT

There is a new version to download that fixes this issue.

Re: Terrain LOD Again

iamvirus — Tue, 11 Aug 2009 19:51:06 GMT

This is probably already been answered, but I could not find it anywhere in the forum...

When I render the terrain, there is a gap between each chunk... how do I get rid of it?

Thnks

Re: Terrain LOD Again

DimX — Fri, 05 Sep 2008 22:58:59 GMT

Not sure if you've already discovered the problem, but it seems to be caused by mipmaps. If you set the mipmap level to 1, TextureUsage to None and skip the GenerateMipMaps call then it'll work the same way as with the loaded PNG texture.

Re: Terrain LOD Again

Qu — Fri, 15 Aug 2008 04:58:50 GMT

Hey cool! It's great you got it working...

..but...

...what the heck? I wonder why it would do that? That makes no sense.

Here's the relevant texture generation code:

    
            //Define texture  
        
            private Texture2D normalTexture;  
        
            //...  
        
            //Constructor  
        
            normalTexture = new Texture2D(g, heightMap.Width, heightMap.Height, 0, TextureUsage.AutoGenerateMipMap, SurfaceFormat.Color);  
        
            //Color array  
        
            Color[ normalData = new Color[heightMap.Width * heightMap.Height];  
        
            //...  
        
            //Generate the normal data array (this is done for every pixel)  
        
            normalData[x + y * terrainHeight] = new Color(texVector);  
        
            //...  
        
            //After normalData has been filled:  
        
            normalTexture.SetData<Color>(normalData);  
        
            normalTexture.GenerateMipMaps(TextureFilter.Anisotropic);  
        
            //Add the normal texture to the shader  
        
            TerrainShader.Parameters["NormalTexture"].SetValue(normalTexture);

Maybe someone with more XNA experience could tell us why the above would have different results on Gorky's graphics card when compared to loading the exact same texture via the content pipeline, after it had been saved using Texture2D.Save?

Re: Terrain LOD Again

gorky — Fri, 15 Aug 2008 02:57:46 GMT

I had a chance to play with your code today to try to figure out the weird shadow problem that still exists with the code.

After a few hours I have narrowed the problem down to a few lines of code. But the problem area is perplexing.

I first looked over the shader code. It seemed OK. Then I moved onto the generation of the normals, because I came to believe that was in error. But that too, was OK. I generated the same exact normal map as you do.

So I added the following bit of code to your LoadContent class right after the creation of the new quadterrain and subsequent texture save to "C:\normalData\test.png"

    
            Texture2D test = Content.Load<Texture2D>("test");  
        
            q.TerrainShader.Parameters["NormalTexture"].SetValue(test);

Viola it worked! But the question is why? What is the Content loader doing different with the texture vs. what you did to generate it? I couldn't come up with an answer, but I need to get back to my code.

Re: Terrain LOD Again

Maerius — Tue, 12 Aug 2008 10:41:54 GMT

Hi again. Please excuse me my absence for few days. I was seriously ill and I took me some time to recover.

Unfortunalety, VTF costs much [Chart]. It also requires SM3.0, which can be unacceptable for some developers. However, it's advantages are invaluable. VTF-based terrain can and even should benefit from adaptive LOD, as reducing the number of rendered vertices is crutial when using tex2Dlod(). I don't believe in techniques, which alter the buffers each frame but I do believe that grid-based paged geometry, asynchoronously streamed from memory od HDD can achieve better performace results. However, VTF-based terrain unburdens CPU dramatically, especially when using hardware instancing. Fixed vertex and index buffers give more place for dynamic texture update for streaming hugeous textures. Futhermore, you can freely alter the height map in real-time. In addition, multiple observers benefit from shared geometry and cheap CPU-cost. Having a small set of 2D terrain patches is extremely flexible. You can forget about geometry, paying attention only to managing height/ground/blend/normal maps, which eases the implementation of large-scale terrains. Screen-space error metric for LOD require height map preprocessing but it's more sophisticated than both simple distance-based approximation [Harald Vistenes, GPU Terrain Rendering, Game Programming Gems 6] and clipmap rings.

Normals can be computed in pixel shader [Chart].

Re: Terrain LOD Again

Qu — Tue, 12 Aug 2008 02:22:55 GMT

Thanks for looking into it ZMan!

I don't remember seeing a moderation notice, but that's obviously what happened. It's certainly long enough.

So: the big announcment thread is over here.

And we were only 2 posts off a 100 post thread, too. ;)

Gorky: Lets hope the graphics problem is something really simple and stupid that I'm doing wrong, so that it's easy to fix and re-release. :) My only advise is that it could be somewhere in \content\terrainShader.fx.

Re: Terrain LOD Again

The ZMan — Tue, 12 Aug 2008 01:11:46 GMT

Qu:

In other news, I posted a pretty massive "release announcment" thread to this board which went into detail about the basics of terrain LOD, how each element of my LOD works, what the various properties did, and many of the problems I had constructing it.

That was some time ago, and it still hasn't shown up, so I'm just wondering what happened? Anyone know?

You can find it here http://forums.xna.com/forums/t/15397.aspx

The forum spam checker sometimes catches very long posts as spam... you should be told when you post that its being moderated then you can always email me to approve it.

Re: Terrain LOD Again

gorky — Mon, 11 Aug 2008 23:23:29 GMT

I'm back.

I've been away for most of the last 3 weeks.

I didn't see your post (or any others for that matter.) You might try to get ZMan's attention to your lost post. It sounds like an informative and useful bit of info.

If I get the chance soon, I'll try to download and play with the code. (Hopefully the weird graphics problem has went away.)

Re: Terrain LOD Again

Qu — Mon, 11 Aug 2008 01:33:45 GMT

Thanks for the positive review Peter. :)

In other news, I posted a pretty massive "release announcment" thread to this board which went into detail about the basics of terrain LOD, how each element of my LOD works, what the various properties did, and many of the problems I had constructing it.

That was some time ago, and it still hasn't shown up, so I'm just wondering what happened? Anyone know?

Re: Terrain LOD Again

PiotrWPL — Sat, 09 Aug 2008 16:35:54 GMT

According to your suggestions I found and check VTF example with normal generation in XNA. I put it into my project. I was very intrested how it will be working.

Maybe I will share my FPS results.

Using VTF terrain my frame rate in game felt down from 33FPS(without any terrain) to 16FPS(with VTF terrain).

Using Terrain algorithm form this article my frame rate felt down from 33FPS(without any terrain) to 24FPS(with LOD Terrain).

Result - looks the same:) and LOD is faster.

Conclusion ... I will stay with LOD Algorithm. Another advantege is that it is working on ATI cards and Pixel Shader 2.0(VTF require Shader Model 3.0).

I read a lot that Ati cards has problems with VTF.

My hardware - laptop Toshiba A100-847 with Nvidia 7600GS 256MG SM3.0 terrain hightmap size 512x512

I know that this first algorithm haven't got any optimisation but this method is still slower than this LOD example. Probably a lot depends here from graphics card and my card is slow with VTF.

I just want to share this results maybe it will help someone with decision what to choose between this 2 options;)

Peter

Re: Terrain LOD Again

PiotrWPL — Wed, 06 Aug 2008 17:54:05 GMT

Right now I'm making submarine game - XNA Submarine project on gamedev.pl website. So camera position range is very wide ....

Chase camera height range will be

Y > (terrain height at position(x,y) + 1)

and Y < (water level ( usually half size of maximum height of the terrain ) + some margin to see top of sub).

Distance from object will be maybe 5 lengths of the sub ...
Free Camera is free .... :) I thought about a box for camera and actors twice smaller than map in the centre of level. You can get out from it with camera and you can't move outside this box with your submarine- you will see message that you are trying to leave your battlefield:)

I hope that it explain everything:). Usually water level will be at 1/2 to 3/4 of height of the terrain. I think than we will be not flying with free camera higher than maximum terrain height. I think that I can limit camera max height to 4/5 height of the terrain.

Cheers Piotr

Re: Terrain LOD Again

Maerius — Wed, 06 Aug 2008 17:29:22 GMT

Ok, and what about the maximum height the observer can fly? Is your scene just a race track or some bigger part of the world, paged just like in Morrowind?

Re: Terrain LOD Again

PiotrWPL — Wed, 06 Aug 2008 17:03:56 GMT

Shader Model. 2.0 ... (It can be 3.0)
Camera - chase camera fallowing car / plane / ship is most important to me. And camera rotating around it's target. I thought about give additional ability to use free camera but it is not necessary.

Thank you for help

Piotr (pw_ch@o2.pl)

Re: Terrain LOD Again

Maerius — Wed, 06 Aug 2008 16:17:04 GMT

GeoClipmaps require texture preprocessing, which practically has to be done in C++, as it is not easy to convert a 1 GB image. I manage to write a megamap file builder using WIC (Windows Imaging Component) and DirectX (for RGBA->DXT1 conversion). boost::gil is simply too slow for debugging which is an additional circumstance. I can provide my solutions if anyone is interested.

Hoppe's geoclipmaps pays very little attention to error metrics, which is ok. This technique can be still simplified by neglacing the "double data" in heightmaps and adding the skirts to the terrain patches. You can successfully implement hugeous ground/heightmaps without clipmaps and you don't need hugeous textures to render clipmaps.

It's crucial to define the observer and it's behaviour, because it's usually faster to render a single geometry (in both XNA and DirectX), preferably in a single render call. QuakeWars uses a one big TIN (Triangular Irregular Network), but neither Supreme Commander nor Black & White 2 (AFAIK). Even the XNA sample renders a single 513x513 regular terrain patch (already elevated in Y components).

Please, define your shader model and camera behaviour precisely. Do you want to have your view Warcraft3-like, Far Cry or something like TA:Spring?