Have YOU written a terrain engine yet?

Started by
6 comments, last by d000hg 21 years, 8 months ago
Well, it seems everyone is doing so; those that aren''t doing some RPG or tetris I''m interested in how you approached: Visibility testing Detail reduction e.g LOD Texturing Lighting (pre-generated/realtime - shadows?) And what kind of poly counts would you have on screen - my last demo got 30K polys on screen at 30-40fps but I think that''s quite high? I plan to implement some degree of scalability for different specced systems but even so what is a sensible minimum/maximum? Read about my game, project #1 John 3:16
Advertisement
Mine was not optimzed so it will look pathetic compared to others, It was mainly a visualization of my hermite interpolation terrain generator:

Visibility testing - none, backfaceculling by DX7

For the rest somthing about the map setup:
Quadratic heightmap with with extended Quads: A quad with an additional point in the center, building 4 triangles (pointing inward)

Detail reduction e.g LOD - only partly implemented: 9 adjacent quads were merged into one, should have been recursive. To coarse

Texturing - Every vertex had a u,v coordinate of alternating 0 and 1 the centers of the quads had 0.5, 0.5,

Lighting - Realtime, partly: whenever the lighting changed (day / night cycle) I calculated new vertex lighting information, no shadows



---------------------------
I may be getting older, but I refuse to grow up


[edited by - Dreamforger on July 27, 2002 7:12:40 AM]
I may be getting older, but I refuse to grow up
I've done a fair few in my time...

most recent is in a vehicle physics sim I decided to stop working on a while ago.

vis testing:

broke the terrain (which was 256x256) into lots of 8x8 blocks. did sphere based frustum culling, and at each, had the minimum height, used that do do really simple line of sight to cull others (makes a HUGE difference)

detail reduction:

each block had level of detail variations... they were swapped to whenever far in the distance.

texturing:

(average) 1-2 passes, upto 4 textures (on my machine)
2 or more base textures, blended together (the shot below has 2) - they were only blended when they would actually make a visible difference (which added a good 20% to the frame rate)
detail map, blended only only on close blocks and faded out, (adds another pass to close blocks) - so only 5-6 blocks had the detail map drawn...
and a shadow map finally.

Lighting:
pre generated 512x512 shadow map. The light was aligned on an axis which makes it really, really fast to generate.

poly counts:
huge :-)
Things to take into account:
the vertex cache (I got 40% boost when I optimized for it)
using vertex buffers (or since I was in GL, VAR)
using unsigned shorts as indicies instead of ints. (25%)
and make sure that the data buffer (if it's a VB/VAR) is fixed.


This is a shot on my system
(geforce 1, pentium 3 533)



[edited by - RipTorn on July 27, 2002 8:19:10 AM]
Are those polygon figures before or after LOD - is that the actual number of polygons it''s drawing? If so that IS a lot - at .25M polys in scene without texturing, I got about 3fps I think on a GF2MX! Though that works out ~1M polys/s, think I wangled it to about 2M later. I''d assumed I should have 20K polys in scene for slow cards, maybe less.

What did you mean by the line of sight stuff, please?


Read about my game, project #1


John 3:16
Well, mine was Octree based view fustrum culling combined with geomipmaps. Textured by dividing into 256 blocks (16x16), and assigning a texture to each block. My terrain is defined as a continous BSpline function, so computing normal at any vertex is easy. As a result, vertex lighting has been implemented. Oh, and dont forget, the most important thing (sarcasm) Back-face culling.

[edited by - SporadicFire on July 27, 2002 2:32:16 PM]
i JUST finished mine, here it is:

it has three textures that are 'lerped' together so they blend evenly from one square to the other. the third isn't visible because its controlled by a blending map, which i havne't done yet. you can control the number of squares a texture covers before it starts repeating, or mirroring. the reason the edges are so spiky is becasue its a random map 'smoothed' by averaging the locations a lot. it can't do the edges yet. that is a 256x256 heightmap, so 131,072 polys/frame. but you won't see near that many in the game, there will be a view distance and large hills so 1/2 are backface culled off the bat, the other 7/8ths are 'distance culled'

no loding, normal lighting
working on the collision now


[edited by - billybob on July 27, 2002 4:54:09 PM]
quote:Original post by d000hg
Are those polygon figures before or after LOD - is that the actual number of polygons it''s drawing? If so that IS a lot - at .25M polys in scene without texturing, I got about 3fps I think on a GF2MX! Though that works out ~1M polys/s, think I wangled it to about 2M later. I''d assumed I should have 20K polys in scene for slow cards, maybe less.

What did you mean by the line of sight stuff, please?
John 3:16


yes. they are the actual counts for number of polygons drawn... and that shot has no lod changes since it''s above 30fps. A GF2mx will get about 20% lower tris/sec rate than my geforce 1. (in my experience at least)

the line of sight is simple.
since the terrain is broken into 8x8 chunks, I have the minimum height and maximum height of each chunk stored. This forms a really low detail version of the terrain map (32*32)
so, for each block, I project a line from the centre maximum of the block, to the view point, and see if it goes below the minimums of any other block along the way (very crude) - The performance boost is quite amazing. And it''s surprising how accurate it is.
Billybob your engine is looking pretty cool, though very odd - reminds me of something out of alien or something - that green texture looks like goo!


Read about my game, project #1


John 3:16

This topic is closed to new replies.

Advertisement