Advertisement Jump to content
Sign in to follow this  

Rendering vertices for my Terrain

This topic is 4744 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

Hey All. Im trying to do a 2d terrain which will be viewable from plan view. So I started it and all was looking good. Ive got my vertices in position. And here is how my 2D terrain vertices are positioned(its only 4x4): - - - - - - - - - - - - - - - - - - - - - - - - - Now i know i could use a Triangle Strip 4 times to render my terrain but i was hoping for a better approuch, as i wouldnt call a bunch of DrawPrimitive functions for a 3d terrain. Any ideas.

Share this post

Link to post
Share on other sites
Actually, a triangle strip is a loss on hardware with a transformed vertex cache.

With a triangle strip, the best you can get is asymptotically close to one triangle per transformed vertex. With a triangle list (not strip), sorted for the vertex cache, you can get about 1.5 triangles per transformed vertex on a reular mesh like this.

Thus, the list will outperform the strip.

Note that you don't need one index list per terrain block, only one index list per terrain block size -- all, say, 32x32 terrain blocks will use the same index list (unless you do LOD through border decimation, in which case you'll need 15 lists total, for the different LOD combinations).

Share this post

Link to post
Share on other sites
I read the first link and not sure whether i understand it. Please correct me if im wrong.

Say these are my vertices for the terrain terrain:

01 02 03 04 05
06 07 08 09 10
11 12 13 14 15
16 17 18 19 20
21 22 23 24 25

In my vertex buffer would i do the following:


then a call to DrawPrimitive as follows:

DrawPrimitive(D3DPT_TRIANGLESTRIP,0,however many pollygons);

Share this post

Link to post
Share on other sites
The post is actually more correct than the article.

The order, as modified by the post, would be:

06,01,07,02,08,03,09,04,10,05, 05,11, 11,06,12,07 ... and so on

I confirmed this by writting a quick program using that order using an index buffer.

[Edited by - skillfreak on January 21, 2006 10:43:31 PM]

Share this post

Link to post
Share on other sites
Someone came up with a trick called "Priming the vertex cache" which can help get larger terrain tiles while keeping more data cached.

Now lets say we're doing a 16x16 tile. The vertices (hex numbering) are like so:

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF

Typically the indices would be (in list form)
00,01,10, 10,01,11, 01,02,11, 11,02,12, 02,03,12, 12,03,13, etc...

Note that by the time we start the second row of triangles, we've looked at 32 vertices (16 on top and 16 on bottom), and the 10,11,12,etc, vertices which we need to begin the next row are long since out of the cache.

Instead, we begin with a bunch of degenerates
00,01,01, 02,03,03, 04,05,05, 06,07,07,...,0E,0F,0F

Now row 0 is in the cache, in order, with nothing drawn. Now draw row after row as normal, and the vertices removed from the cache FIFO will always be ones you'll never be needing again.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!