Sign in to follow this  
67rtyus

[DX9] Strange holes in the terrain! Help needed...

Recommended Posts

Hi,

I am again blocked by a weird problem. I am rendering a huge terrain by using Direct3D 9. I posted a topic about an another problem here a while ago, which still exists; [url="http://www.gamedev.net/topic/605333-dx9-strange-flickering-problem-please-help/"]http://www.gamedev.n...em-please-help/[/url] . This is the same project and I did not change anything meaningful; I am still struggling to solve that "flickering" problem and now another weirdness appeared out of nowhere.

The problem is simple, when I move on the terrain strange single pixel sized "holes" appear in my terrain, which are not rendered correctly and which assume the background color, the color which I clear the framebuffer with. It is like the rasterizer somehow "skips" those pixels. Here are two screenshots displaying the problem. I added the green circles to emphasize the "holes":

[url="http://imageshack.us/f/193/holes1bmp.png/"]http://imageshack.us.../holes1bmp.png/[/url]

[url="http://imageshack.us/f/17/holes2bmp.png/"]http://imageshack.us.../holes2bmp.png/[/url]

This happens both with the old and new drivers of my graphics card, unlike my old flickering problem. ( a NVidia GeForce 8600 GS) The holes appearing to be flickering, too, I mean it is like they are drawn correctly in a frame and they aren't being drawn at all in the next frame; such that some of those pixels appear like "pulsing". Interestingly ,when I try to debug my program with PIX utility, they get drawn correctly, PIX doesn't seem to be capturing those pixels. I used very simple vertex and pixel shaders, which do only basic coordinate transformation and solid coloring, in order to test my current shaders, but the holes appeared again. Additionally, I tried to render the terrain with the fixed function pipeline; they were again there.

But I discovered something interesting, I thought that some of the triangles on my terrain could be erroneously eliminated by the backface culling mechanism which leads to such uncolored-empty pixels on the screen. When I turn the backface culling off, the holes disappear. But I couldn't think of any way in which the backface culling works incorrectly. I am trying to re-code my project step by step since weeks and I don't think that I have done something wrong to cause that problem. I am really confused and annoyed, again... I desperately need new ideas and thoughts which could aid me to find the source of this thing.

Edit: I forgot maybe the most important thing; these holes appear in the fullscreen mode. When I run the program in the windowed mode, they do not appear!



Thanks in advance...

Share this post


Link to post
Share on other sites
Is the terrain a single mesh? or is it using a type of LOD system? if so, those holes are likely areas were the terrain is not covering properly. What do those areas look like close up?
Another possible problem is depth precision. are you using a 16 bit depth buffer? If so, go with a 32 bit depth buffer (the memory usage is minimal now adays).

Share this post


Link to post
Share on other sites
[quote]Is the terrain a single mesh? or is it using a type of LOD system? if so, those holes are likely areas were the terrain is not covering properly. What do those areas look like close up?[/quote]

I use QuadTree to partition the terrain and there are 256 leaf nodes in the tree quadtree which have their vertex buffers assigned seperately. So, the terrain is not a single mesh. When I render a node, I call the SetStreamSource function to set the vertex buffer of the current node. I am actually using the GeoMipmapping LOD system but the holes appear again when I turn the LOD off, completely. Strangely, their numbers increase when I turn off LOD and use the full resolution meshes. (By the way, the terrain is a regular mesh system, no fancy triangle tesellations exist.)

[quote]Another possible problem is depth precision. are you using a 16 bit depth buffer? If so, go with a 32 bit depth buffer (the memory usage is minimal now adays).[/quote]

I am using the D3DFMT_D24S8 format, 24-bit for the depth buffer, 8-bit for the stencil. My card doesn't seem to support 32-bit depth buffer. But I don't think the depth precision is the problem, because I tried to clear the depth buffer with values much greater than 1.0 such that if those pixels appear because of the depths of the valid pixels get erroneously greater values than 1.0, I would detect such a case. Unfortunately, it wasn't the case, the holes appeared again.

Share this post


Link to post
Share on other sites
Well, the problem is likely an issue with your lod system creating seams. This happened to me also when I was creating an lod system for my terrain as well. You have to mess with the placement of the patches to ensure that they are either: overlapping by at least one unit; or, ensure that the vertices of the bordering patches are exactly the same. Also, 256 is a bit of a high number for how many grids there are in a terrain system, you can check out my little post on terrain [url="http://nolimitsdesigns.com/tag/terrain-rendering/"]terrain rendering --the simple way[/url]. Be sure to zoom in on the picture showing the grids and how they overlap by one unit, which means no fancy bordering patches are needed, or any special index buffers. Just simple patches -- and very few of them too!

Share this post


Link to post
Share on other sites
I don't think it is the LOD seams causing the problem; I got the screenshots in my first post when my LOD algorithm was completely off. By that, I mean, I did not ever called it in my code to begin with, not just turned off. The terrain consists of 1025x1025 vertices, the QuadTree has 4 steps of divisions such that every leaf node has 65x65 vertices. The vertices at the node edges are exactly the same, I don't use any edge patches because every node has exactly same mesh resolution. Besides, the holes appear inside of the nodes too, not necessarily at the node borders or seams.

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