Sign in to follow this  

Terrain alpha blending fillrate problem

This topic is 4813 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm having yet more troubles with my (possibly) infamous terrain engine! This time round, I think I'm having problems with fillrate. I'm using a method very similar to splatting, but different enough that it warrants an explanation of the method here. Basically I have one mesh per texture "splat layer" for the entire terrain. The mesh is split up into chunks and the chunks are rendered by means of a quadtree. Each splat layer has its own blend texture which informs the pixel shader how much of the current layers texture needs adding to the underlying texture. Each splat is rendered in a separate pass (currently the terrain has 4 texture "splat layers"). A detail layer is rendered for each pass that blends that layers texture with itself tiled at a higher frequency. This detail layer is rendered using multitexturing (it is not a seperate pass) and ensures that the terrain texturing does not look overly tiled and uniform. Overall, this means that I'm rendering 4 passes, with 3 textures per pass (1 texture is set to 2 different registers to avoid needing to use a phase marker in the pixel shader for the detail layer). Each splat layer mesh is also optimised to use the smallest number of verts possible, because I understand that rendering the entire terrain mesh 4 times is wasteful when I can simply render the polygons that have the texture painted onto them and ignore the others in the terrain where the overlaying blendmap will have 0 alpha. Now my problem occurs with the blending, so I'm assuming it may be a fillrate issue, but have been unsuccessful in reducing the problem. I want my game to have a top down view, but when using a top down viewpoint, the frames per second drastically drops when travelling over areas of terrain using blending. My FPS may be 150 over an empty area, and as low as 70 FPS or worse when travelling over a blended area. Now, this problem is much much less noticeable when using a standard first person perspective (almost no FPS difference), as I imagine it is drawing to a smaller portion of the screen and using less fillrate? This would be all well and good if I were doing a first person perspective game, but I really would prefer a top down perspective if possible. I have tried reducing the blendmap resolution, tiling the texture at a lower frequency, spacing the vertices further apart to reduce polycount, using alpha testing to remove 0 alpha polygons as early as possible and I've actually turned off alpha blending and still notice the same problem, though it is slightly worse with alpha blending enabled. I suspect I may simply be asking too much to blend 4 layers with 3 texture needing sampling in each layer. I could drop the detail layer for a reasonable reduction of the problem (although that doesn't entirely solve it, it does help), but it would be such a shame, as the detail layer really makes it look a lot nicer! I have also noticed that the size of my terrain makes almost no difference on framerate, and a 1024*1024 terrain will render almost identically as fast as a 128*128 terrain, so I know my quadtree is working pretty efficiently, so I'm certain that it isn't a factor here. I guess I'd like to know if anyone can point out whether this is likely to be a fillrate problem or a polycount problem (I suspect fillrate), and whichever it is, if anyone could offer advice on reducing/removing the problem I'd be very appreciative! Thanks, Steve *Edit* Thinking about it, batching may also be a problem, currently I batch by chunk, so each chunk has its 4 splat layers rendered, then the next chunk, then the next chunk, etc, etc. This makes for a lot of texture switches. The alternative would be to have one set of texture switches and have a load of vertex buffer changes as each VB must be switched to 4 times (one per splat layer). I don't think this is an issue in my blending problem, but it is something else I know I should consider. Basically I guess I'm saying that I'm not sure how expensive a texture switch is compared to a VB/IB switch. [Edited by - Mephs on October 8, 2004 9:35:44 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Mephs
Basically I have one mesh per texture "splat layer" for the entire terrain.


thats where you lost me. what for? are you saying you have the mesh for the entire terrain 5(!) times?

Share this post


Link to post
Share on other sites
You're missing some useful information.

1. What 3D card are you using, 150 or 70 fps could be quite reasonable, although I guess since you're using pixel shaders it must be fairly recent

2. What desktop/window size
I thought the normal test for seeing if your are fillrate limited is to reduce it down to say 640x480 and see what happens to your performance.

BTW any chance of some screenshots, always nice to see a terrain engine ;)

Share this post


Link to post
Share on other sites
Well I'd do a test like this: try not blending. I mean try rendering the same just don't do the blending operation, see if the bottle neck is the #of polys or the blending itself.

Also if you have a nice and useful pixel-shader why not do the blending there? Why render 5 times?

Quote:
Original post by noisecrime
BTW any chance of some screenshots, always nice to see a terrain engine ;)
Add my vote to that request ;)

Share this post


Link to post
Share on other sites
"Basically I have one mesh per texture "splat layer" for the entire terrain. The mesh is split up into chunks and the chunks are rendered by means of a quadtree. Each splat layer has its own blend texture which informs the pixel shader how much of the current layers texture needs adding to the underlying texture. Each splat is rendered in a separate pass (currently the terrain has 4 texture "splat layers"). A detail layer is rendered for each pass that blends that layers texture with itself tiled at a higher frequency. This detail layer is rendered using multitexturing (it is not a seperate pass) and ensures that the terrain texturing does not look overly tiled and uniform."

!! Dont do that per pixel! Do it per vertex. Store a blend index for every texture per vertex. That way you can have up to 4 textures in one pass ( when you transmit the blendweight in the vertexcolor )

Share this post


Link to post
Share on other sites
Quote:
Original post by Dtag
!! Dont do that per pixel! Do it per vertex. Store a blend index for every texture per vertex. That way you can have up to 4 textures in one pass ( when you transmit the blendweight in the vertexcolor )


and enjoy the fancy jumps in texturing if he uses or adds some kind of lod that will skip vertices and make common geometry popping look like a subtle effect in comparison.

Share this post


Link to post
Share on other sites
Quote:

and enjoy the fancy jumps in texturing if he uses or adds some kind of lod that will skip vertices and make common geometry popping look like a subtle effect in comparison.


Unless he can output the entire terrain as a new texture based on the splatting (preprocessed). Which can then be used as a base texture in place of splatting when passed a certain distance, ideally before LOD comes into play.

?

Share this post


Link to post
Share on other sites
Thanks for all the replies!

Unfortunately I'm currently without home internet connection and have to reply from work (so no weekend replies from me!). I've worked out several things which have saved me some frames per second now, so it's not too much of an issue any more.

As for the info I've missed, I'm using a GeForce FX 5700LE on a 2.4Ghz Athlon XP with 768 megs RAM. I'm also rendering in 1024x768 windowed mode (as this is an MFC/DirectX level editor). I will post screenies at some point, but if anyone is able to host them for me it would help a great deal as I'm not able to renew my web-hosting for a couple of months.

I've tried tiling at a lower frequency, and now it looks a lot better (less of a tiled look) while also definitely working faster. Unfortunately without my code in front of me I can't remember everything else I did to help the situation, but it was a variety of quite minor changes.

Something else that as been bugging me is LOD. I was close to having a simplified implementation of chunked LOD where progressive meshes aren't used but simply each LOD has an error calculated and each LOD also doubles the size of a quad while removing half the vertices (much simpler to implement than PM's for a similar effect).

Now this was all well and good in theory, but I realised part way through that using splatting is going to mean that when I come across cracks between chunks of different LOD, I can't use a skirt to fill the gap because the skirt texture will not match the texture above (as I'm not texturing the terrain with one large texture). Assuming that I use a single texture for the skirts, this texture will show up wherever there is a crack. I figure it would look really bad if the skirt was a grass texture and was showing up hiding a crack for a chunk that has a mix of rock and sand textures for example. Anyone know any way around this?

Share this post


Link to post
Share on other sites
I'm sure there will be someone more expereinced with better suggessts, but again for the LOD/skirt issue I would have thought the last post I made should be relevant.

That is build your terrain, and then turn it into one large texture (however you want to go about it). Then reduce this to a managable size maybe 1024x1024 or a series of 512x512 sections, whetever. You can then use this texture when rendering the skirts. Hopefully the skirts happen at a distance where the lack of detail/resolution compared to the splatted areas wont be as noticable. I would also assume for distant LODs you'd use the same texture and save on doing any splatting passes.

BTW I just re-read your first post, and missed the alphatest you mentioned first time round. After I worked out what this meant it seams like a nice solution to exiting the pipeline early for polygons. I'll have to give it a go.

As to your perfromance issues, it would be nice if you can update the thread sometime as to what changes you thought made a difference. You appear much happier about the perfromance so presumably you've made some gains somewhere. It will be interesting as from your intial post it did seam like fillrate would be an issue (although the card is pretty good, and you've not got an excessive window size).

As to hosting images I can proberbly do that for you in a week or so. Sadly my current domain is down (my ISP has lost my payment twice now!) and i'm releasing an application that will suck up bandwidth for a while sometime this week. Once thats resolved though, I don't see why i couldn't host some pics fora while. PM or email me sometime if you still want to put up some images.

Share this post


Link to post
Share on other sites
Hmm, yes that sounds like a good idea that I actually meant to implement but forgot about, and had also forgotten the benefits of it as well. I shall try that, but I do wonder how I'd get the skirt texture to line up properly with the chunks above. My best guess is that I'd give the skirt texture coordinates a little either side of the divide between the chunks and that hopefully it would match reasonably well from any viewpoint. I guess it wouldn't be perfect, but it's better than a single texture that would definitely not work. I'll give it a go as I think it would save a lot of fillrate and lower the polygon count significantly, and on top of that it will allow me to implement the chunked LOD lowering the poly count even further. I'm hazarding a guess that with these changes I could push for a consistent 300+ FPS which will give me plenty enough room for rendering at a good framerate with my water renderer enabled which is one of the things I've been aiming for.

Once I've had a chance to review my code changes I'll try and post them so there's a decent list of fillrate reduction tips in the thread.

Cheers,

Steve

Share this post


Link to post
Share on other sites
"and enjoy the fancy jumps in texturing if he uses or adds some kind of lod that will skip vertices and make common geometry popping look like a subtle effect in comparison"

True. Actually I'd do it like farcry: Store the regular texture in one big texturemap ( maybe several if your terrain is so big ). Apply detailtexturing to the near geometry chunks with LOD 0 ( detailtexturing is controlled by mask textures ). That guarantees no seems, and a quite good speed. I strongly doubt that you can get a good speed with what he described above. Especially if you want additional effects ( for example detail texturing )

Share this post


Link to post
Share on other sites

This topic is 4813 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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