As far as I can tell, there is no pattern with the small dots.  But there does appear to be band like strips that are darker.

Here is a screenshot, much higher up, with a majority of the landscape in view:

qu - no pattern

I would be intested to see if the dark spots move around if the light position moves.  My guess is they won't.

What is strange is how the darkness has no relation to the heights.  Almost like the normal texture is being used as a shadow/light map.

 

Hmmm... based on that, I'd say like the global normal map is undergoing some sort of corruption at the SetData() stage...

 

Here's the more recent version, and I've added a few things that might help us work out why it's doing that. The light cycle now spins quite fast (once every 6 or so seconds no matter the FPS) and the global normal texture is saved to C:\normalData\test.png (you will have to create the normalData folder manually or this will throw an exception).

This is the new *.ccgame file.

And this is a copy of the normal map that should be created.

The generated global normal texture looked identical to yours as far as my eye could determine. So the problem is not there. (I thought it was too.)

But watching it in action with the faster sun gave some possible clues.  There are some areas of land that never get shrouded in darkness.  Likewise there are some area's of ground that are almost always in shadow.  But a majority of the landscape cycles into and out of darkness.   The band like strips are very obvious as the sun cycles around.  After watching certain parts of the ground closeup, I think the problem might actually be coming from your detail normal mapping.   Can you create a version, that with a button press, will skip using detail normal mapping in the shader?

 

 

I set up a version a few secs ago which allows you to turn detail mapping on and off that by pressing P, and then found out that the file hosting site I've been using is down at the moment.

No worries: Google found me another one.

Here's the link.

Turning off the detail mapping had no effect.

I'm baffled at what it might be.  Perhaps I'll play with the code when you release it.  I'm guessing that what might be working for your card in the pixel shader for normal mapping, does not work on mine.

OK guys. Riemer isn't set up yet, but I might as well share it through the free file hosting site... it's not that big a file. I'll change over once everything's set up on Riemers site.

QuadTerrain LOD class: Download.

 

Hope you like! Let me know if you've got any feedback.

Hello I was trying to move your class to DrawableGameComponent.

Sample code is possible to find here ...

www.thefuturestudio.com/xna/

It is working but I have a lot of problems to use it in my game.

In my game I can see terrain only in very small scale and when I'm far away from it.

I think that the issue is in my camera class. It is different from yours. I put into my server 2 project. Could you help me and tell me how to fix this strange problem.

When you deploy project with my cam and move forward with W key(and right mouse button) you will see how strange is it working right now. My cam is working fine for me with water ... sky and other objects

Could anyone help me with that????

Hey, I'll download the sample code you referenced and get back to you tomorrow, after I've taken them home and had a look. :)

PiotrWPL:

In my game I can see terrain only in very small scale and when I'm far away from it.

The terrain constructor has XZ and Y scale values, which you can set to match your needs, but beyond that I'll need to take a look: I haven't encountered anything like what you're mentioning during testing. I'll get back to you tomorrow.

^-^
Qu.

Hmmmm closing camera far plane distance fix this problem ...

Thank you Quasar for help and this great project!

Peter

You beat me to it. Apparently a 2500000 far clip plane is a bit too much. :)

Based on the effect that was being caused, my best guess is that (for whatever reason) the bounding frustum constructor couldn’t handle the massive far plane distance, and was ignoring it. Thus, the only Quadnodes displayed were those whose bounding box’s collided with the near clip plane.

  

By the way, that’s a really good looking height map. ;)

I found it at images.google.com:) search for "heightmap" probably the second result.

Now I have twice much more FPS with comparison to QuadTree

Thanks for your time ...

Peter

I though I could somehow helpful for you guys and share my test result I've made for my thesis.

http://lapinski.hostedwindows.pl/Gallery/Gallery.htm

If you target Shader Model 3.0 you can elevate the terrain vertices in vertex shader using VTF. It works with Forward/Deferred Lighting and shadowmap-based shadow casting including horizon visibility check for daylight system. You can make your terrain rendering extremely fast & easy for certain camera work modes. But if you want enormous textures or optimized big terrain patch meshes, C++/DirectX is required.

 ps. I would strongly suggest to avoid dynamic terrain mesh building - ROAM and similiar were good for GeForce2, but now it's simply inefficent to suffocate CPU with such a data-driven task as trimesh generation.

Hello Maerius. I'm sorry other community users that I will use my native language.

[polish]

Witam serdecznie. Mam na imię Piotr i od paru miesięcy walcze z XNA. Ostatnio z terenem:). Wiem że generowanie terenu przy pomocy GPU jest dzis popularne i zapewne bardzo szybkie. Z chęcią wypróbuje bardziej optymalny algorytm. Wszelka pomoc i przykłady będą naprawde mile widziane. Przypuszczam że przez całą społeczność XNA. Szukałem przykładów kodu geoclipmaping ale moja wiedza jest jeszcze niestety zbyt mała aby coś takiego zaprogramować a i czasu brak niestety. Czytałem o tej technice w GPU GEMS i jakiejs seri ShaderX ale nie jest to zadanie proste a ja borykam się teraz z napisaniem engine na mgr na którą mam mało czasu. Nie wiem tez czy ta metoda nie została czasem opatentowana. Za wszelkie rady ... kod ... z którego moża korzystać dowolnie również w celach komercyjnych będe wdzięczny jak i inni użytkownicy XNA. Pozdrawiam Piotr.

[english - thanks google]

 

Hi Piotr, we generally try to keep conversations in English. If you are more comfortable using yuor own languge then please provide a translation as best you can.  I guessed polish (seems like a good guess) and added Google's version above. Feel free to edit the mistakes.

OK. It was first and the last time:) when  I did it ...:)  I will try to be more confident about my English level:) Sorry for this mess:)

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?

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)

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?

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

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

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?

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.)

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.

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.

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].