Sign in to follow this  
thallish

Making a terrain engine (master thesis)

Recommended Posts

Hi For my master thesis, that will be on computer graphics I have chosen to concentrate on the creation of a terrain engine. Right now and through the summer I'm browsing the scene and I want to get as much input on which techs, algorithms, graphical quirks, like scenegraph, terrain generation, lighting, shaders and so forth, that a modern terrain engine should contain. Im using DirectX and C++ for implementation and the finished work is to be delivered in june 2007 so I got more than a year for the theoretical and pratical parts. I need to get as much info before I start so that I can take a good or at least better estimate on what I should strive for. I have gotten small bits and pieces of information from here and there on the web and I have also searched this site but I have not found any collected brain storm on the subject of terrain engines. So here is the deal. Anything that you think would be a part of a terrain engine. And I'm really talking about getting every little bit of information that you think could be relevant, that would be in depth discussions, keywords or links or whatever you feel like, so empty all those great minds and enhance the knowlegde of the community (and me of course ;-)) regards thallish

Share this post


Link to post
Share on other sites
Are you looking at just terrian, or things like water and vegetation as well? Anyway, for terrain you've got the following:


  • Geometry: The main algorithm's being ROAM, ROAM 2, geo mip mapping and geo clipmaps. I think these are the big ones at the moment.

  • On top of that you need culling, both out-of-view culling and occlusion culling (PVS data I think, but I haven't looked into it much - but I do have a paper on voxel column culling which looks nifty).

  • Then it comes down to lighting and materials so you'll probably want to look at self shadowing, splatting and if you want to be really cutting edge - a megatexture like approach.



That's all that comes into my head at the moment.

Share this post


Link to post
Share on other sites
I am also interested in ideas, articles and more about vegetation and water to answer that question ;-) (nothing more exciting than a shallow lake with weeds around it) I will hopefully get a lot of information and then I will sort them out after relevance and time.

Good start keep the ideas comming :-)

regards
thallish

Share this post


Link to post
Share on other sites
I think that for most applications todays the best you can do is just ignore the whole LOD-thing altogether and just brute force everything. Unless you need an "almost infinite" terrain (which of course would require LOD) I think a better way is to just create a huge terrain, split it up into reasonable chunks for view frustrum culling, and apply some decimation techniques (split triangles on chunk borders, of do the "loose bounding volume" thing where you just put each triangle in the BV in which it's centroid is, and then expand the BV to encompass the whole triangle). Google for TIN (Triangulated Irregular Mesh).

I really think LOD is more trouble than its worth for a static terrain, just find a good static mesh and brute force it. For texturing I suppose a per-chunk texture would be neat, and then have different texture LODs for each chunk, stream in high res versions of the textures covering the close-by chunks.

Share this post


Link to post
Share on other sites
Quote:
Original post by IFooBar
I would highly highly suggest the book Real-Time 3D Terrain Engines Using C++ and DirectX 9


Already got that one :)

Well i have got a lot of keywords I can work with and I will try to get indepth articles of the subjects mentioned. A google on the right subject did wonders.
But keep the opinions comming. I appreciate it ;-)

regards
thallish

Share this post


Link to post
Share on other sites
the theme of disscussion is quite vague. its like, you telling people you are building a car. and expect them to tell you how you can make great car. the thing is, what kind of car are you making? fastest car? strongest car(stronger than trailer), cheapest car, luxury car... and the list goes on.

the thing is, you are a masters student, which i assume by now you must have solid understanding of your needs. what is your domain? the domain problem? please be clear.

terrain engine is one huge ass topic. i personally love it.

Share this post


Link to post
Share on other sites
Well the question is as vague as people see it. I asked what people think would be a part of a terrain engine or to go with the car analogy, what makes a good car. I am not asking how to make it, I am asking about what bits and pieces that make up the car. This is just preliminary inquires, if I dont know that a car needs wheels, how can I find out about how to use wheels in a proper fashion. I need to get a firmer understanding on which area I want to go deeper into, and thereby establish my problem domain:-). I know that there is a lot to terrain engines, and this query is to get an idea on to what other people think of the concept "terrain engine".

OrangyTang: Thx for that link :-)

regards
thallish

EDIT: Formulation

[Edited by - thallish on May 22, 2006 6:25:19 AM]

Share this post


Link to post
Share on other sites
The usual reference for terrain engine is vterrain.org which is a great site with all types of ressources.

What I would expect from a modern terrain engine is to support the following features :
- support huge area of landscape with great level of detail
- look good with very high level of detail and react to lighting
- let my game engine interact easily with it
- don't eat all my processing power.

Each of these area have been adressed by lots of peopple and you will find lots of ressources. Here are some big area of research ;
- Terrain level of detail (ROAM, ROAM2, smooth geo-mipmap, geo-clipmap,...),
- Terrain data compression, paging, streaming (dynamic terrain generation, data streaming,...),
- Terrain texturing (splatting, multitexturing, procedural texturing, normal mapping for terrain, Quake 4's megatexture, texture compression, texture streaming,...), athmosphere shading (atmospheric scaterring, ...), shadowing (shadow map ; variance / percentage closer filtering, LiPSM / trapezoidal / cascaded / parallel splitted)
- Physics for terrain (don't know any, never worked on that).

Share this post


Link to post
Share on other sites
I don't know if its been mentioned but you don't really need LOD on todays hardware (unless you want it to run on a GF3 or something). Anyways, Carmack has a new MegaTexture idea that has like 5GB of terrain texturing and no LOD. You can customize the texture etc. There has been a decent sized discussion on it just recently on these forums and a lot of other sites. It seems awesome.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike2343
Just to help people out who want to get to the links from swsudio2002 easier (btw use HTML tags):
................
*phew* Done!

I am sorry~thank you.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike2343
I don't know if its been mentioned but you don't really need LOD on todays hardware (unless you want it to run on a GF3 or something).


Or if you want large enough scenes... Of course it's less necessary these days but I mean, unless you're doing UT 2k3 or something you'll need some kind of LOD scheme, won't you?

Share this post


Link to post
Share on other sites
Quote:
Original post by Niwak
What I would expect from a modern terrain engine is to support the following features :
- support huge area of landscape with great level of detail
- look good with very high level of detail and react to lighting
- let my game engine interact easily with it
- don't eat all my processing power.


To add a few more:
- support overhangs/caves
- no popping with lod scheme (ie. geomorphing)
- realistic static and dynamic lighting
- constant FPS (using things like occlusion culling and CLOD)
- scalable between brute force rendering and highly optimized CLOD
- arbitrary view distance (!)

Share this post


Link to post
Share on other sites
Quote:
Original post by averisk
Quote:
Original post by Mike2343
I don't know if its been mentioned but you don't really need LOD on todays hardware (unless you want it to run on a GF3 or something).


Or if you want large enough scenes... Of course it's less necessary these days but I mean, unless you're doing UT 2k3 or something you'll need some kind of LOD scheme, won't you?


Honestly why do you need it? The GPU can more then handle the verticies. You're not sending the ENTIRE terrain to the GPU, just the stuff within the rendering boundries. It will take more CPU power to remove a few verticies for what? You'd be better off spending that CPU time doing collision detection, AI, etc. People I swear get stuck on old habits and refuse to budge. If after profiling your rendering code you notice that lack of LOD is just killing your FPS (very doubtful unless you're rendering off to 40 miles distance for a UT2k3 type game) you can easily add it in later.

We did a terrain engine test about 8 months ago. I forget what the vertex counts were, nothing outlandish, but it was for a 5x5 or 8x8 mile area (forget also) and our major hurdle was the LOD system. I removed it and we got a 15% FPS jump on average. Several different LOD (based on existing techniques) were used and all took away from the brute force, no LOD method. *shrug*

Don't get me wrong, I'd still LOD textures (even terrain), models, etc. Just not the terrain geometry.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike2343
...
Honestly why do you need it?
...
averisk gave you an honest answer in the post you quoted. Many modern games and other applications don't want to be limited to such a small area as 8 square miles. Just look at something like what Ysaneya is doing and then say there's no need for terrain LOD. And if you aren't using up all of your card's vertex processing power on the terrain, you have more power to spare for using more detailed characters or other objects.

I agree that on smaller areas of terrain LOD calculations can be a bottleneck and are probably not worth it, but on larger terrains they definitely are worth it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike2343
Honestly why do you need it? The GPU can more then handle the verticies.

This argument ("You don't need LOD nowadays") aways comes up. And it's always wrong.

Say your poly budget was 1000 tris for the landscape. Now I could just brute force it and render the nearest 1000 in the view and it'd look ok. But if I actually had LOD then I could use those 1000 more efficiently and get the same visual quality but twice the draw distance. Thats going to be true no matter how high your poly budget actually is.

The real question is how complicated your LOD system needs to be. IMHO you don't need anything more complicated than geomipmapping. Nice high detail terrain, and switch to different sets of indices for farther away. Don't bother with geomorphing or anything complicated, just make sure that the transitions are far enough away so the snapping is minor.

Likewise for crack fixing schemes - keep it simple with something static like skirts. You still get LOD, but you're doing a minimal amount of CPU work and just letting the GPU do what it does best - blast through big chunks of static geometry.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Mike2343
I don't know if its been mentioned but you don't really need LOD


I get so frustrated when I hear this comment because as a general statement, it's complete bullcrap.

Depending on the quality and scale requirements of the terrain, it's very possible that you need to still use LOD. For medium-sized or coarse terrains you might not need LOD, but if a game like WoW tried to draw its entire terrain (the visible set at any given time) at its full resolution, you would definitely notice.

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
This argument ("You don't need LOD nowadays") aways comes up. And it's always wrong.
QFT.

Particularly with some of the lightweight simplistic algorithms -- geomipmapping would be my choice -- you can perform LoD very efficiently. My own terrain system performs LoD with negligible performance penalty (it's a couple tens of thousands of cycles per second), and the poly counts are cut back sharply as a result. (Exact values depend on configuration, but it's generally 10%-20% of what the brute force would render, with no visible artifacts.)

And yes, I know Carmack said it. And I say he's wrong.

Share this post


Link to post
Share on other sites
Funny, from what I read Carmack isn't using terrain LOD in his new engine. I personally know he's better then me so I assume he has a valid reason and has done the research.

I've seen what Ysaneya (very impressive btw) but having skimmed his Journal from time to time I've not actually seen him mention LOD. I'm not saying he hasn't but I've not seen it. Also, most of us aren't doing what he is doing. Most are working on limited range terrains (a 6' person can only see so far before something obstructs the view and 8x8-16x16 miles is normally more then enough for most FPS games).

I'm also talking MODERN hardware, not GF3 or older here (likely excluding GF4 too at this point).

1000 tri's for terrain? That's the face count of some LOD models ;-) But in all honesty if that's your triangle budget for terrain you're likely working with older hardware and I already said that I wasn't considering it.

Remember the OP has not stated exactly what this is going to be used for, or how far he needs to see. I was just pointing out for limited range terrain engines (under 16x16 miles or so) you can brute force it in most cases (higher density meshs of course will require it).

Edit:
You posted as I was typing mine up lol.
Quote:

And yes, I know Carmack said it. And I say he's wrong.


If you're a better programmer then him, more power to you. Like I said, in OUR case the poly count wasn't an issue compared to the CPU cycles we wanted to give up. It's also a mute point since the terrain engine is now shelved for the time being. Also, I'm not a Carmack fan (he's an awesome programmer, I just down't worship any coders period, it's a rule of mine) but I was brute forcing awhile ago and came to my own conclusion (you can believe it's wrong or right, I honestly don't care worked for us) that brute force was better for us and that the GPU could easily handle it.

Anyways, out until tomorrow I think. Take it easy.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike2343
1000 tri's for terrain? That's the face count of some LOD models ;-) But in all honesty if that's your triangle budget for terrain you're likely working with older hardware and I already said that I wasn't considering it.

I deliberately picked a stupidly low number to show a point - that no matter how big (or small) your poly budget actually is, you can always get better results by spending the polys where they matter (ie. using LOD).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this