Skip to main content
GameDev.net gamedev.net
🔒 Locked

terrain spliting

Started by cyber-ghost Nov 20, 2003 at 5:30 PM 7 replies 550+ views
Original Post
cyber-ghost
cyber-ghost
HI i have been reading this tutor on terrains and the programer talks of creating one large terrain say 32*32 and then breaking it up into chuncks say 4*4 vertices then useing indices for speed the problem is i dont understand how he dose this if i use the vertices in this way when i pull the vertices from terrain then the vertex values would be off because vertices was originally one large mesh and the indices cant produce a square grid help me understand this please.
i know you all
edotorpedo
edotorpedo
quote:

help me understand this please



Strange... I was thinking the same thing. Two words: grammar, spelling, interpunction. Give us a clear overview of the problem and ask specific questions.

Edo

[edited by - edotorpedo on November 20, 2003 6:41:07 PM]
Edo
cyber-ghost
cyber-ghost
quote:
Original post by edotorpedo
quote:

help me understand this please



Strange... I was thinking the same thing. Two words: grammar, spelling, interpunction. Give us a clear overview of the problem and ask specific questions.

Edo

[edited by - edotorpedo on November 20, 2003 6:41:07 PM]


If you have a terrain made of 32*32 vertices,and for culling you wanted to devide it into blocks of 4*4.In a tutorial i have been reading, the programer takes the 4*4 vertices from the original mesh of 32*32,Then starting from vertex 0 - 3, and moveing to the next 4 below it so you can get the 4*4 Grid.This cant be write can it.


i know you all
edotorpedo
edotorpedo
Better, but where are you from?

If I understand correctly you want to do frustum culling (you only said culling so I assume frustum) on terrain, so you need to divide it into patches of 4x4 from an original 32x32.

Your question is how you can create the indices for a triangle strip (or quadstrip?), so you can store it in 1 index buffer for rendering.

Let me simplify it by taking an 8x8 mesh and showing how you can create indices for a 4x4 patch. You should be able to do the same thing for 32x32. I assume your vertices are organized in the following way:


0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39
40 41.........


The index buffer for 4x4 patches should now be:
0,8,1,9,2,10,3,11,11(!!!),19,10,18,9,17,8,16,16(!!!),24,17 etc

Note that you duplicate vertice no. 11 to continue the triangle strip for the following row. If you do not do this a triangle will be drawn for vertice 3,11,19, and you don't want that.

Basically you create a 'dummy' triangle (which essentially is a line which will not be drawn) to move on to the next row.

I hope this was your problem (note the number of assumptions I made), if not let me know,

Edo

[edited by - edotorpedo on November 21, 2003 6:28:37 AM]

[edited by - edotorpedo on November 21, 2003 6:33:00 AM]
Edo
Trienco
Trienco
while we''re at it: notice how you can use the very same index buffer for all 4x4 chunks, simply by using a different offset into the vertex array (effectivly adding x to all indices).

imagine it with your vertex pointer set to &vertex[4] (or add 4 to all indices).
f@dzhttp://festini.device-zero.de
Fidelio66
Fidelio66
Breaking up 32x32 into 4x4''s isn''t a real-world example. it''s probably for tutorials only.
Imagine 1 unit is 1 meter, and you have a 2048x2048 heightmap. You split this into 256 128x128 heightmap data files. Your terrain editor should be able to work on them, either on one 128x128 or several together.

Your renderer can then load in and draw the square you are on and the 8 surrounding it. To avoid drawing a 129x129 in one big buffer you can then split that up into 17x17 patches, and use a technique like geomipmapping where you draw a detailed one for the ones close, and 9x9, 5x5 or 3x3 for the ones further away.

Be careful about the data format and vertex format. Typically the heightmaps are eg. 128x128 but the vertex buffer would be 129x129. Or else there''s one strip missing between each tile.
cyber-ghost
cyber-ghost
quote:
Original post by edotorpedo
Better, but where are you from?

If I understand correctly you want to do frustum culling (you only said culling so I assume frustum) on terrain, so you need to divide it into patches of 4x4 from an original 32x32.

Your question is how you can create the indices for a triangle strip (or quadstrip?), so you can store it in 1 index buffer for rendering.

Let me simplify it by taking an 8x8 mesh and showing how you can create indices for a 4x4 patch. You should be able to do the same thing for 32x32. I assume your vertices are organized in the following way:


0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
32 33 34 35 36 37 38 39
40 41.........


The index buffer for 4x4 patches should now be:
0,8,1,9,2,10,3,11,11(!!!),19,10,18,9,17,8,16,16(!!!),24,17 etc

Note that you duplicate vertice no. 11 to continue the triangle strip for the following row. If you do not do this a triangle will be drawn for vertice 3,11,19, and you don''t want that.

Basically you create a ''dummy'' triangle (which essentially is a line which will not be drawn) to move on to the next row.

I hope this was your problem (note the number of assumptions I made), if not let me know,

Edo

[edited by - edotorpedo on November 21, 2003 6:28:37 AM]

[edited by - edotorpedo on November 21, 2003 6:33:00 AM]




Brazil!


You are correct.I have a tried the method of just creating seperate blocks with ther own vb and index buffers,then just translate them into the correct position,But applying the height values for bordering vertices suck.So if i can just index correctly into a large terrain that allready has the height values from one vb then i can avoid that nightmare.I have a problem finding the correct pattern of indexing into the mesh in my for loop, useing quads and trianglelist,and my vertices are defined as displayed.









i know you all
mrbastard
mrbastard
I was just passing through and read Trienco''s comment.

Nice one! Simple and obvious now you''ve mentioned it, but I''d never spotted it before! Great little simple optimisation.

I''ll probably implement it in my terrain engnie this weekend. Should save a little bit on AGP bandwidth or later vid mem when I''ve got VBO working. As my LOD is a simple geomipmap approach at the moment it should be applicable there too.

Thanks Trienco.
[size="1"]
cyber-ghost
cyber-ghost
HI again i finaly got the code to run correctly, thanks for the post. now all i have to do is test it in my demo.
i know you all

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.