# My Terrain Engine [demo posted]

## Recommended Posts

##### Share on other sites
Quote:
 Original post by Valor KnightCurrently in a retail build, I am getting ~ 321 FPS at 1024x768 windowed 4x AA ~ 231 FPS at 1280x1024 fullscreen 4x AA (stupid internet connection will not allow chinging resolutions in fullscreen apps while it is active, so I have to keep it at my windows resolution) My computer: 3.2ghz, gpu: GeForce 6800My first question, are these ok framerates given that I am rendering ~25,000 triangles for the sky, and terrain, I am worried because I have no idea what rendering and doing everything else will cost in fps, and 231 fps seems low just for sky and terrain rendering.
I think the speed you achived is impressive! 231 FPS corresponds to 4.32ms per frame. If you finally want to achive, say, 30 FPS, it has a frame time of 33.3ms. From this point of view, you can see that you still have 7.7x the time you use now.

Quote:
 Original post by Valor KnightFinally, my last question (for now :p) How would I go about texture lod-ing? Here is another screen shot, and with the wireframe overlay, you can notice the distant texture shows the uv repeating very easily, while it looks rather good up close. While reading the papers on geo-clipmapping (thinking about switching - I really like the gpu taking care of it and using a static buffers, instead of dynamic ib's on the cpu), they talked about texture clipmapping, how is that done, I seem not to be able to find info on it, and that texture repeat needs to be less obvious, so with entities around it will hopefully be barely noticeable.
What about mixing the distant textures with some (possibly procedural) noise? Or you could use bigger textures everywhere, so that it will repeat less frequently.

Quote:
 Original post by Valor KnightSorry for the long post and the incessant questions, but I have been just piddling around with my code trying to optimize what I think needs to be done, and need a second opinion
If you want to optimize it more, then I recommend trying NVPerfHUD. It's the ultimate tool in my opinion [smile]
This was a great post anyway, no need to say sorry to anyone :)

kp

##### Share on other sites
For the texture problem : multitexturing. In your scene, you have only 1 texture tiled over the whole terrain. When rendering a terrain, you usually have something like 4 detail textures that you blend (to create sand areas, grass areas, etc.) and also another texture channel to modulate the result (lightmap, or a color texture)

With all that, you can introduce a lot of variation on the colors, the details, etc. and the texture tilling almost completely disappear.

Now, if you want to implement lods with textures, you will have a few issues : you use square patches. If you have a 512² texture on a lod0 patch, and a 256² texture on a lod1 patch, you almost certainly will see the gap between the patches. So you will need to create a pixel shader that would interpolate between both texture, or something equivalent. And I don't think that will be easy ^^

So to sumarize : use a few texture channels to add a lot of diversity to your terrain texturing. That's the easiest way to remove texture tilling.

##### Share on other sites
One question do you have multiple vertex buffers per section of the terrain ? Or do you store everything in a vertex buffer ? I have read somewhere (i think it was on greg snook book on realtime terrain rendering) that you could use multiple streams one for the height of the vertexes (it's really the only thing that changes) and only one vertex buffer for the postition...

It's geomipmapping right ?

##### Share on other sites
The Terrain Stitching could use some work, but otherwise good job!

Try using this approach.

Instead of terrain mesh "square" being created like:

 ------- |\    | | \   | |  \  | |   \ | |    \| -------

Try using this approach

 ------- |\   /| | \ / | |  \  | | / \ | |/   \| -------

That way when you stitch its just a matter of adding a line to the square which changes detail (I seperated the squares in my example below to give you an idea of the neighbhoring square might look like):

 ------- ------- |\   /| |\/|\/| | \ / | |/\|/\| |  \--| |--|--| | / \ | |\/|\/| |/   \| |/\|/\| ------- -------

And you can keep dividing in such a way from very corse to fine detail.

##### Share on other sites
Quote:
 Original post by JoeyBlow2The Terrain Stitching could use some work, but otherwise good job!Try using this approach.Instead of terrain mesh "square" being created like: ------- |\ | | \ | | \ | | \ | | \| -------Try using this approach ------- |\ /| | \ / | | \ | | / \ | |/ \| -------That way when you stitch its just a matter of adding a line to the square which changes detail (I seperated the squares in my example below to give you an idea of the neighbhoring square might look like): ------- ------- |\ /| |\/|\/| | \ / | |/\|/\| | \--| |--|--| | / \ | |\/|\/| |/ \| |/\|/\| ------- -------And you can keep dividing in such a way from very corse to fine detail.

I think that with this arrangement you cannot use triangle strips... This is the method described in focus in terrain rendering book and in my opinion it's not performance friendly...

##### Share on other sites
Thanks for the replies, I am going to try and get a demo of it, I just need to change the way I am looking for needed lod changes. Currently I am just checking the distance to all of the patches instead of only the ones in the frustum, so hopefully that can give me a little fps boost.

Quote:
 Original post by kovacspI think the speed you achived is impressive! 231 FPS corresponds to 4.32ms per frame. If you finally want to achive, say, 30 FPS, it has a frame time of 33.3ms. From this point of view, you can see that you still have 7.7x the time you use now.

eh.. I will make a demo and see what other people get, I just need to change a few things first.

Quote:
 Original post by kovacspWhat about mixing the distant textures with some (possibly procedural) noise? Or you could use bigger textures everywhere, so that it will repeat less frequently.

Currently I am using 512x512 textures, so I dont really want to go any higher perhaps 1024 but that is it. The noise sounds like a good idea, I will have to look into that

Quote:
 Original post by kovacspIf you want to optimize it more, then I recommend trying NVPerfHUD. It's the ultimate tool in my opinion [smile]

I will look into that, thanks

Quote:
 Original post by paicFor the texture problem : multitexturing. In your scene, you have only 1 texture tiled over the whole terrain. When rendering a terrain, you usually have something like 4 detail textures that you blend (to create sand areas, grass areas, etc.) and also another texture channel to modulate the result (lightmap, or a color texture)So to sumarize : use a few texture channels to add a lot of diversity to your terrain texturing. That's the easiest way to remove texture tilling.

I am actually doing that but I am using 1 blend texture with r,g,b,a being a different texture. Currently, it is just my blend map is the clouds plugin from the gimp so it is really close anyway. I will need to get a lighmap working and a color map, but I am afraid that I will still see the repeat in the distance.

Quote:
 Original post by Ivo LeitaoOne question do you have multiple vertex buffers per section of the terrain ? Or do you store everything in a vertex buffer ? I have read somewhere (i think it was on greg snook book on realtime terrain rendering) that you could use multiple streams one for the height of the vertexes (it's really the only thing that changes) and only one vertex buffer for the postition...It's geomipmapping right ?

I have 2 vertex buffers in this scene, I fill them till they have ~5 mb of info and then create a new vb and fill that one up. So when creating it I have a variable number of vb's. I have one index buffer per patch though. yes im doing geomipmapping.

Quote:
 Original post by JoeyBlow2The Terrain Stitching could use some work, but otherwise good job!Try using this approach.Instead of terrain mesh "square" being created like: ------- |\ | | \ | | \ | | \ | | \| -------Try using this approach ------- |\ /| | \ / | | \ | | / \ | |/ \| -------

But your adding 3 times as many triangles to the scene than before, right?

##### Share on other sites
Quote:
 Original post by Ivo LeitaoI think that with this arrangement you cannot use triangle strips... This is the method described in focus in terrain rendering book and in my opinion it's not performance friendly...

I wasnt using strips anyway. Performance wise, is a dynamic index buffer (or many) faster than a dynamic vertex buffer? I want to start geomorphing, but when using index buffers instead of strips, it will be interesting to say the least, (unless there is an easy way)

##### Share on other sites
Quote:
Original post by Valor Knight
Quote:
 Original post by Ivo LeitaoI think that with this arrangement you cannot use triangle strips... This is the method described in focus in terrain rendering book and in my opinion it's not performance friendly...

I wasnt using strips anyway. Performance wise, is a dynamic index buffer (or many) faster than a dynamic vertex buffer? I want to start geomorphing, but when using index buffers instead of strips, it will be interesting to say the least, (unless there is an easy way)

Index buffers instead of strips ? I'm sorry but i'm not understanding.. In my geomipmapping implementation i'm using triangle strips and index buffers. I'm talking about the primitive type (i.e. triangle strips, trinagle fan etc)

##### Share on other sites
so Geomipmapping is when you have 2 vertex streams one for the x and x position this one would never change and be the same for all patches. And one for the height. these would be joined together in a vertex shader??

##### Share on other sites
Quote:
 Original post by kapruso Geomipmapping is when you have 2 vertex streams one for the x and x position this one would never change and be the same for all patches. And one for the height. these would be joined together in a vertex shader??

It's one possible way of doing it i think.
I've not implemented it in that way (yet) but i think it could work. At least that's what Greg Snook does in his book (in his ROAM implementation).

##### Share on other sites
any one wanna explain exactly what it is no need to go on how it works tho

##### Share on other sites
Quote:
 Original post by kapruany one wanna explain exactly what it is no need to go on how it works tho

Check this two articles :
[Geomipmapping] - http://www.flipcode.com/articles/article_geomipmaps.pdf
[Geomorphing] - http://www.gamedev.net/reference/articles/article1936.asp

##### Share on other sites
Quote:
Original post by Ivo Leitao
Quote:
Original post by Valor Knight
Quote:
 Original post by Ivo LeitaoI think that with this arrangement you cannot use triangle strips... This is the method described in focus in terrain rendering book and in my opinion it's not performance friendly...

I wasnt using strips anyway. Performance wise, is a dynamic index buffer (or many) faster than a dynamic vertex buffer? I want to start geomorphing, but when using index buffers instead of strips, it will be interesting to say the least, (unless there is an easy way)

Index buffers instead of strips ? I'm sorry but i'm not understanding.. In my geomipmapping implementation i'm using triangle strips and index buffers. I'm talking about the primitive type (i.e. triangle strips, trinagle fan etc)

I am currently doing DrawIndexedPrimitive() - I didnt know you can do both, but what would that matter? do you do indexed for lod's and tri strip for base lod. This is why I think geomorphing will be difficult - perhaps Im doing it wrong, I dont know.

When I get off work, I will post the demo - its better than looking at 2 images and deducing problems that way

##### Share on other sites
demo posted, let me know how it fares.

##### Share on other sites
I tried it out, I get ~300fps on my 6800 GT. The geomipmapping is working nicely but the program consistently crashes after about 20 seconds.

Why the SM3 restriction? Your vertex shaders compile under 1.1, and 2.0 for your pixel shaders. A little bird once told me you should always use the lowest shader model you can.

##### Share on other sites
humm, 20 seconds crash? I have no idea what that can be, but will look into it asap. What were you doing when it happened? Unfortunatly I dont have any logging methods yet (I will make a basic one right now though).

I am using sm 3.0 for my sky coloring (I have dynamic sky coloring in a vertex and pixel shader) - I could lower it but I am probably use some methods later, if I am not already.

##### Share on other sites
Just tried out the demo. Between 390 and around 500fps on AMD Barton 3000+ and GeForce6800GT. With more than one texture (as you´re going to implement) and lighting this could look nice. Didn´t spot any artifacts or anything like that and got no crashes.

One thing though: Are you doing one Draw-call per patch you render? If so, try to combine the index buffers of the patches into one and render as many patches as you can with one Draw-call. Perhaps it aids performance. On the other hand it might be better to just keep going and implement some more stuff until it gets too slow. Then benchmark it and find the real bottlenecks.

##### Share on other sites
Quote:
 Original post by matches81With more than one texture (as you´re going to implement)

Sweet no crashes, thanks for testing it. I am using more than one texture, I am using 3 currently, the only thing is that if you look, the blend map is the clouds plugin from the gimp, so it blended all 3 together to look like 1 texture, but I can add paths and patches of grass if I edited the blend map rather easily.

I will try to put everything into one call but how would I do it? Would I create another dynamic vertex buffer and then somehow load it every frame and then render once for every vertex buffer. I have VB goals in that only fill the vb to about 5 mb and then create a new one, I read somewhere this was the most optimized way to do it, and it works fine until I hear differently.

##### Share on other sites
350-500fps. AthlonXP 2.8ghz. Geforce 6800GT.
no crashes or artifacts. very smoooth.

i like the way the tide comes in on a landlocked lake :D

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628375
• Total Posts
2982318

• 10
• 9
• 14
• 24
• 11