GL terrain engine

Started by
4 comments, last by TheLabRat 23 years, 6 months ago
I''m making a simple terrain engine in opengl for a new game. The terrain won''t need to be really delta-force huge, but will have quite a reasonable poly count - should I depth sort and implement hidden triangle removal, or will GL''s depth buffer be sufficient and just send in the whole terrain to be drawn. If its is recommended to remove them -what would be an effective way of testing a polygons distance to the moving camera. Thanks Chris
Advertisement
The simplest way I can think of would be to create a 3d array, and sectorise the polygons with a X/Z grid.

If you use a 3d array [50][50][100], where each cell represents 50 feet, that''s a 2500 feet square area, and each cell [x][z] can hold 100 polygons.

Find the centre of the polygon (in X & Z) and store it''s ID in the corresponding array[X][Z][next poly]. Of course you will need another array (2d) that stores the polycount for each grid cell.

Obviously, this is a very limited system, but it''s damn simple to implement, and you can surely afford the 1mb of memory it needs, if your terrain fits into this kind of scale.

We can make it much, much more efficient - and flexible by doing away with the 3d array, and reducing it to a 2d array of pointers. Each pointer directs us to an area of memory that holds the precise information for the cell - so if it has 2 polygons or 500, no memory is wasted and there is no upper limit to the poly count-per-cell.

In fact, I''d like to here what some of the ''veterans'' think of this idea - I can''t be the first to think of it (although I first worked on it in 1995, for a software renderer) and it must have a proper name. Sorry for my complete ignorance when it comes to terminology, but I just feel that when you''ve designed and implemented your own methods like this (however simple they are) it is always satisfying to see them working, knowing they are the product of your own head!

It''s all working brilliantly for me now!!

Cheers

Matt



Check out my project at:www.btinternet.com/~Matthew.Bennett
1/ use some sort of cullingtest coupled with LOD (quadtree, ROAM) for your terrain
2/ (poygonspos - cameraspos).length() , this does involve a sqrt but theres heaps of examples of a fast sqrt on the net
You probably don''t need too much accuracy for your tri distance test, so use the L1 normal to get the depth. Its a lot faster than pythagoras because doesn''t involve sqrts and multiplies.

It works like this:

    L1=(max( max(abs(cam.x-pos.x), abs(cam.y-pos.y)), abs(cam.z-pos.z);    


All it does is take the furthest distance of a point down a particular axis and calls that the distance. The result if you use it for depth culling is an axis-aligned cube around the view within which the player can see. If you used pythag it would be a sphere.

http://www.geocities.com/ben32768

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

Thanks for the help - I''ll give it a go, by the way, what does L1 mean - pardon my ignorance?
Level 1 - I think... I would point you to the page where I found it, but I can''t remember where that is.

http://www.geocities.com/ben32768

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

This topic is closed to new replies.

Advertisement