Best Display Mode for Landscape?

What would you consider to be the best display mode for a large landscape engine, of approximately 256x256 polygons (65536)? My landscape is a simple flat mesh with differing .y coordinates. I want to be able to ‘tile’ textures (maybe each tile would be 10x10-50x50 polygons), and eventually blend textures.
My landscape is going to be viewed similar to Black And White, i.e. isometric engine with very close and distant zooms.

  1. 1 Big Vertex Array. How can I tile textures using a VAR? Will OpenGL frustrum cull polygons for me? Would it be possible to pass ONLY the y coords and generate the x and z coords in the VAR algorithm to minimise bus usage/card memory?

  2. Display lists. Seperate display lists for each ‘tile’, can also frustrum cull each display list.

  3. Seperate VARS for each ‘tile’? Then HSR each VAR against frustrum.

  4. Other?

I’m currently using 1 VAR, but having trouble working out how I can tile the textures, and how to perform HSR.

[This message has been edited by alexjascott (edited 04-30-2001).]

[This message has been edited by alexjascott (edited 04-30-2001).]


65K pollys isn’t much in a landscape, my smallest landscape is 1025x1025. But I try to target 8-10K polys onscreen per frame.

Don’t let OpenGL do the culling for you - you’re still wasting time sending the data to the card, and you can cull larger chunks out at a time than OpenGL can.

Given your description, I think an array of 16x16 tiles (of 16x16 each), or 8x8 (of 32x32 each) would be good. Pick the patch size which will give you the most texturing flexability.

As for the structure of the patches… Fastest would be a single tri-strip stored in a display list (tri-strips can be bent around backwards to build odd-shaped strips like a square). This doesn’t allow for CLOD or dynamic deformation though, but it’s dead fast. You can store both texture and multitexture coords this way.

Frustum cull each tile by using it’s center point.

This doesn’t change the number of triangles you’ll have to render if you zoom out though. You’ll still need some LOD in there.


How is it that you can strip a 16x16 grid with one strip without using slivers (ie: polygons that aren’t really there and are very small)?

And if you’re going to use VAR (with tiles), I would suggest making your tiles either 8x8 or 4x4. The overhead for fustrum culling might be large, but it makes good use of the 10-element post-T&L vertex cache.

Sorry Korval,

Your’ll have to explain what you mean a little better!

As for the tiling, i was probably aiming for a 16x16 polygon tile, with 16x16 tile landscape. Perhaps that wont look nice enough, so maybe I’ll have to split it more.

However, as I understand VAR they are best when you only have 1 big VAR. But HOW do you apply multiple textures (with tiling) to a VAR?

I was asking BryanNC about this comment: “(tri-strips can be bent around backwards to build odd-shaped strips like a square)” and how that works.

All you have to do is break your VAR memory up into tile-length segments (programmatically, not by declaring multiple blocks of memory). Fill these blocks as needed by your engine.


Sorry if I was cryptic, I was suggesting using degenerate triangles, as you pointed out.

Not sure how 8x8 tiles would make better use of the vertex cache. 4x4 may: 5 one way, 5 back. But 8x8 would be just as poor as 32x32 in terms of vertex cache misses, no?


You won’t need to bother with VAR unless you want dynamic updates to the mesh. If your terrain is static, just use VA + display lists, it’ll be faster. VAR is an NV extention (?) which will not be available on all cards.

As for multitexturing with VAR, I believe you can setup the step sizes to include texture coordinates, color, vertex, etc… all in the same VAR run. I’ve not tried multitexturing (or even texturing, for that matter) with VAR yet, so please correct me if I’m wrong here.