Thread: Holes in terrain

This is very weird and I did not encounter this last time I coded this quad-tree frustum culled terrain.

Since this is a recursive algorithm if the function works for 1 patch it should theoretically work for all patches. How in the world am I getting some patches that just do not show up? I've written the terrain data to 5 files each separating the different types of data and I cannot find the problem.

Look at this mess:

Here is an updated screenie with the new shaders.

Still holes in the terrain. Dunno why. But now I have multiple terrain types with smooth transitions between them.
This screenshot is clamped at 100 FPS so I'm not losing any frames so far with just the rendering.

So this problem is due to the frustum culling, e.g. when you have the frustum test turned off everything is rendered properly?

Is it just a random tile here and there or is there any consistency to it? Have you used this algorithm before? Granted I don't know much at all about 3d/Driect X, but I'm just wondering if perhaps there's a pattern to the missing patches.

How are you doing the texture transitions? Are you loading all of your textures into a 3d texture and interpolating the texture z value when you want to transition, or is it a multi-pass kind of thing?

So this problem is due to the frustum culling, e.g. when you have the frustum test turned off everything is rendered properly?

I turned frustum culling off and still have the same problem. There are a few areas I can think of that may be causing this issue. I'll let you know what I discover.

Man that's odd. I don't know if its a frustum culling problem because patches before and after the hole are rendered.

The texture transitions look good.

My sentiments exactly when I ran it and saw what it was doing. And thanks I think the texture transitions look very good for a single pass shader.

Is it just a random tile here and there or is there any consistency to it? Have you used this algorithm before? Granted I don't know much at all about 3d/Driect X, but I'm just wondering if perhaps there's a pattern to the missing patches.

It's not quite random and it appears as if the southeast portion of the quad tree is falling apart. However there is a serious problem with this theory. If the quadtree was broken, almost every terrain patch would reveal this since this is a recursive algo. So if it's broke for one patch it should be just as broken for the next. Also what's extremely baffling is that 4 patches in the center of the terrain are completely missing. This is a quad tree boundary so this would mean that all 4 quad tree nodes would have failed in order to produce such a render. I'm almost certain it cannot be the quad tree. It may be in the actual render code that traverses the tree and drills down to the leaf nodes.

How are you doing the texture transitions? Are you loading all of your textures into a 3d texture and interpolating the texture z value when you want to transition, or is it a multi-pass kind of thing?

Terrain texturing and lighting is done in a one pass blending shader that does diffuse and specular lighting. It's a well known technique. I'm using a blend map to blend several different textures. Each texture uses a channel of the blend map to determine how much of it's color contributes to the final pixel. A tiling coefficient is used on the texture samplers and a non tiled coefficient is used on the blend map. This technique is in several books but is explained very well in Frank Luna's recent book. I'm only using the basic technique here and it works well for now.

Once I discover the source of my 'holes' I'm going to add bump-mapping to the shader. Future plans also include billboarded grass, 3D trees/rocks/plants and whatever else I can throw at this. The eventual goal is to implement this renderer as the planet renderer for my space game project so I will also need billboards on the horizon so I can show far off planets, moon, suns, etc. Hopefully I can also implement some CLOD so I can perform seamless space to planet transitions with no loading and no pausing.

The skybox is not actually a box. Instead it is a cubic environment mapped icosphere which gives pretty good results.

To narrow down problems specific to the polygons that make up the world I've implemented a debug 'point and shoot' function which tells me which polygon I'm pointing at. I have then examined the parent algorithm (in your case the recursive rendering functionality?) at the part of the function that should be handling the polygon in question. Perhaps you can do the same?

It seems the culling is indeed the problem. I messed with the min and max vectors of the AABBs for the patches and now I have some very odd results.

Here is a screenshot from way above the mesh patches. There is a clear pattern of holes and suspiciously one entire quadrant is missing. This points to a quad tree generation problem.

EDIT:

I'm an idiot. Found the problem and it was the SW corner was not generating correctly. Probably because I was passing midwz as the start z and the end z.

Hehe. Yep. It's a pattern and an ugly one. Perfect example of how looking at the big picture can fix a simple issue.

Now it's working fine and the culling also is working quite well. I dumped the P and N optimization that every web site out there tells you to use. Why? Because it quite honestly does not work for all cases or at least I could not get it to work. So I'm testing all 8 corners of the AABB against the 6 planes of the frustum. The test I'm not performing is the 8 corners of the frustum against the 8 corners of the AABB.

I also have in mind some different culling algos in case this one does not yield good results. I've looked also at restrictive quad-tree's and triangle bin-trees for CLOD but have not attempted any of them yet.

Next question is now how do I generate these patches on the fly and generate the normals? I have code that will read in data from a file given a central offset and a range around the offset. The idea is to load in 'patches' in real time as the player moves.

I've found several articles on various techniques but not sure how to go about implementing them. Moving from a white paper to actual code is a bit of a leap especially when I hardly understand all of the white paper.

Hughes Hoppe page describes geomip-mapping which I've been wanting to try. I think paging data in would be easier since everything is still maintained in a regular grid. My idea is to pre-process the entire world and place it on disk in vertex format. The index buffers for the patches will never change so I could store it once and just use the data for every patch. The only difference between the LODs is the step size across the data. I'll deal with T junctions when I get there but I have a few ideas on how to deal with them. The biggest issue is fitting all of this into a quad-tree at run time. It's easy to pre-gen the quad-tree but it's not so easy to embed data down into the quad tree at run time.

Another issue is view distance. I'm assuming that total view distance based on height above the terrain is the projection of the altitude vector onto the horizontal view vector or look vector. This would be true out to a certain maximum distance.

Other issues that come into play are shaders. I need to do sky scattering both on the skydome or skybox and on the terrain. But the terrain also needs diffuse lighting with the blend texture map system to arrive at the final terrain. This is a lot of inputs into the shader. I simply do not know how to 'chain' shaders. Ideally one shader would take care of the diffuse and blend map and the other shader would then do the sky scattering on the result of the previous shader. Anyone know how to chain these together?

Here is a screenshot of terrain with detail levels. I'm trying to get excellent texture detail closeup and lessen it the farther away from the viewer the terrain is. This sample uses 5 textures, grass, grass_far, rock, sand, and the blend map. Closeup UV's are multiplied by 512.0f, mid UV's are 32.0f, and far UV's are 1.0f.

Here is a sample of my cloud shader and associated source.

Code:

uniform extern texture cloud_tex1;
uniform extern texture cloud_tex2;

float2 cloud_scroll1;
float2 cloud_scroll2;

float4x4 matWorldViewProj;

sampler Cloud0 = sampler_state
{
    texture = <cloud_tex1>;
};

sampler Cloud1 = sampler_state
{
    texture = <cloud_tex2>;
};


struct VS_OUT
{
    float4 Pos : POSITION;
    float2 TexUV1 : TEXCOORD0;
    float2 TexUV2 : TEXCOORD1;
};


VS_OUT VS(float4 Pos : POSITION,float2 TexUV1 : TEXCOORD0,float2 TexUV2 : TEXCOORD1)
{
    VS_OUT outData = (VS_OUT)0;

    outData.Pos = mul(Pos,matWorldViewProj);
    
    TexUV1 += cloud_scroll1;
    TexUV2 += cloud_scroll2;

    outData.TexUV1 = TexUV1;
    outData.TexUV2 = TexUV2;

    
    return outData;
}

float4 PS(VS_OUT inData) : COLOR
{
    float c0 = tex2D(Cloud0, inData.TexUV1);
    float c1 = tex2D(Cloud1, inData.TexUV2);

    float total_inverse = 1.0f / (c0 + c1);

    //c0 *= c0 * total_inverse;
    //c1 *= c1 * total_inverse;

    return (1.0f - total_inverse) * 3.0f;

}

technique Clouds
{
    pass P0
    {
        VertexShader = compile vs_3_0 VS();
        PixelShader = compile ps_3_0 PS();
    }
}

Man I love your work Bubba, it's really impressive...

I know you're working on an engine, or at least were. Do you plan to release it? Commercially or otherwise?