Reality Check - Textures Hit Hard

Am I too greedy trying to render 16384 textured vertices at a perfect frame rate?

I'm rendering a terrain, and until now, I've simply had each vertice being coloured by a RGB value. It's time to move on to bigger and badder things, so I decided to get the startings of a texture going.

I'm starting with strictly tiling each "square" of vertices. And now that I've got it working, running around on my terrain is a chore. What used to be smoother than silk on teflon would now make a lumber jack proud. That's right, it's choppy like you wouldn't believe.

I'm not doing anything fancy in the rendering that I wasn't doing before.

My initialization includes:

Code:

---

...
D3DDevice->SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_SELECTARG1);
D3DDevice->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE);
D3DDevice->SetTextureStageState(0, D3DTSS_COLORARG2, D3DTA_DIFFUSE);
...
// And as for my RenderStates:
// Culling none (CW doesn't help)
// ZEnable true
// Lighting false
// FillMode solid
// NormalizeNormals true
// Ambient 0x00FFFFFF
// AlphaBlendable false

---

And I call

Code:

---

if(FAILED(D3DXCreateTextureFromFile(D3DDevice, "C:\\Grass.bmp", &Texture)))
        return false;

D3DDevice->SetTexture(0, Texture);

---

Just once. Outside of my Rendering.

Between the BeginScene() and EndScene() methods of my D3DDevice, the only code that appears is:

Code:

---

//Render everything
D3DDevice->SetStreamSource(0, VertexBuffer, 0, sizeof(VERTEX));
D3DDevice->SetFVF(FVF);
D3DDevice->SetIndices(IndexBuffer);
D3DDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, NumVertices, 0, NumPolygons);

---

So, I'm at a loss where this performance hit can be coming from. And my only guess is that Textured vertices take more time?

If there're any thoughts, I'm glad to hear them. Thanks for reading :)

How are you setting texture coords.

Some things to check out:

• Your tex coords should be incremented by 1.0f/Width and 1.0f/Height.
• Your vertices are created at load time and not during the render.
• Make sure your FVF is in the exact order that your vertex members appear in the structure.
• Set culling to appropriate value.
• BIGGIE: Make sure texture is resolute enough to convey the image but not too resolute to cause frame issues. Tiling resolution can also cause problems. The texture should span the entire wireframe mesh, not tile over each quad. Tiling over each quad will cause major framerate hits. That would mean each quad had 1 sample of the texture applied to it.
  For a large texture (anything over 64x64) this tiling would really put a crunch on framerates.
• To compensate for this lack of detail and control use multi-texturing either through a shader or the fixed function pipeline
• Instead of calculating real time lighting, either calculate a light and shadow map for the terrain grid or use per-pixel dot3 lighting inside of shaders.
• Use of shaders does not always guarantee more FPS - on some cards it most assuredly does not

That "BIGGIE" definitely did it.

I had no idea that using various coordinates would throw it off that badly. I was using a 128x128 texture and tiling it over and over with:

Code:

---

Map[TerrainIndex].TU = (float)(XPos & 1);
Map[TerrainIndex].TV = (float)(ZPos & 1);

---

Where XPos and ZPos are integers cycling from 0 to NumCols/NumRows respectively. Pretty much just "Tiling" the texture. I was worried about the quality if how everything would look if I stretched it out.

But right now, I made one big 1024x1024 texture, and spread it across. I attached a screenshot below (The lighting isn't working completely yet, but that's for another day). That's how pixelated it looks now, and I'm wary about increasing the texture size further.

One last question about the picture below, is that "detailed" (the close up parts worry me) enough for shaders/pixel magic tricks to make up for the sever lack of detail there is now do ya think?

Thanks again, and a lot, for that tip. I'm back to silk on teflon, and that definitely would not have crossed my mind to change.

I've encountered the same problem and the solution lies in closely examining some games that do terrain.

Ones to examine are:

Battlefield 1942
Battlefield Vietnam
Microsoft Combat Flight Simulator 2
Microsoft Flight Simulator 2004
World War 2 Fighters
European Air War
IL2 Sturmovik/Aces Expansion Pack/Pacific Fighters version 4.02m or 4.02 standalone
Microsoft Train Simulator

If you have any of these games load them up and closely watch what takes place.

There are several ways to gain resolution for textures that are closer to the camera.

• Since terrain detail is directly proportional to the distance of said terrain point to camera, some type of level of detail or LOD algorithm will help a lot. Several methods exist for this as well. You can switch LOD based on distance, terrain complexity, or any number of other properties. This LOD will allow you to 'batch' triangles so that more detailed sections have smaller triangles and less detailed sections have less triangles. I suggest lookin at ROAM or Real Time Optimally Adapting Meshes algorithm, quadtrees, octrees, distance algos, etc, etc. This won't help your textures per se, but it will give you more control over how up-close terrain looks to the viewer. Detail will be concentrated where it matters most. The distant triangles make up only about 1% of the total picture and yet with a brute force algo, 85% to 90% of these buggers are displayed even though they are next to nil in detail.
  
• BIGGIE: Create a 128x128 or 64x64 'detail' texture. If you are doing bump mapping create a bump map the same size as the detail map. For triangles that are close to the camera use the distance as an alpha value. For instance if the texture detail starting distance was 100 units from the camera, alpha at this point would be ((101-100)/100) or close to .01f. Additive blend the detail texture to the existing texture using the computed value as the alpha for the detail texture. As the tri's get closer to the camera, the alpha increases and the detail texture becomes more visible. This will definitely increase the visual quality of your terrain. Use the same process to add bump mapping, light mapping, specular mapping, etc. Whether you use shaders or the fixed function pipeline is totally up to you. I would code both - FFP for older cards and shaders for newer.

Might I also suggest you alter your quad size some. It looks a bit blocky right now.
Try cell sizes of 8, 16, 32, and 64 and see what happens to the overall terrain quality.

Also turn linear filtering on. This will filter the texture linearily on u and v producing a nice bilinear filter. The up-close texels now will become a blur, but if you add detail texturing, they will look good and the far-away texels will look the same.

Bubba, I don't know how many times you've pulled through huge, but thanks again.

I've added the bilinear filtering, which makes everything so much easier to look at. Along with about a million minor changes to the engine in general, I've also added a very crude Procedural Generation and shading (both visible in the screenshots below).

As you can see (or perhaps not), but there are some problems with getting the terrain as smooth as wanted. Currently it's using a method where it just averages the heights of surrounding pixels, and that's the height. Next on the line will probably be writing better algorithms for the height smoothing and for shading (which right now takes the Y component of a Normalized Normal, and just uses that as a ratio for how much of the texel's colour will be used), and then LOD...no matter how big or bad I think I'm getting, there's always something bigger and badder just around the corner.

There are a million steps to go before I reach Perspective's level (I ran across his thread while searching...I forget what now...but boy, is that impressive, and a nice reminder of what can be accomplished).