Sign in to follow this  
Valor Knight

My Terrain Engine [demo posted]

Recommended Posts

I have a few comments about my terrain engine so far that I hope will give me ideas on how to make it faster and better. I have some images, but can't give a demo just yet (Im on 21.6kbps, imagine the time to upload) 2 Passes, once for texture splatting, once for wireframe mesh - this was before lod was in and the second pass doubled all triangle and patch values The water is just there to cover the empty space - it is by no means anything I want. Currently 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 6800 My 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 feel there is much more I can do to increase performance, and it comes to my second question, Terrain Stitching. Currently I am doing this: (lods 0, 1, 2, 4 shown - this was a screen shot when I was creating the stitching code, that is not how it lods in the scene lod 4 is never near 0-2) Image hosting by Photobucket It produces good results, I guess, but the code to do it is very unwieldy: link to code. Is there a better way that is faster and frankly not as confusing as what I have got? Finally, 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. Image hosting by Photobucket 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. Sorry 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 Thanks. EDIT: I just got rid of everything I could and zipped it. The demo is here I didnt get to change my culling or lod updating methods yet, but this gives a rough estimation of what I am doing. press w and it will addon a wireframe pass. This requires shader 3.0. *hopefully there was no problem with the upload* [Edited by - Valor Knight on March 17, 2006 10:43:14 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Valor Knight
Currently 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 6800

My 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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by JoeyBlow2
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.



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 this post


Link to post
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 kovacsp
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.

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

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 kovacsp
If 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 paic
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)

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 Leitao
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 ?

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 JoeyBlow2
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



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




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

Share this post


Link to post
Share on other sites
Quote:
Original post by Ivo Leitao
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...

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 this post


Link to post
Share on other sites
Quote:
Original post by Valor Knight
Quote:
Original post by Ivo Leitao
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...

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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by kapru
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??


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 this post


Link to post
Share on other sites
Quote:
Original post by kapru
any 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 this post


Link to post
Share on other sites
Quote:
Original post by Ivo Leitao
Quote:
Original post by Valor Knight
Quote:
Original post by Ivo Leitao
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...

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by matches81
With 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 this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this