Skip to main content
gamedev.net
🔒 Locked

Terrain Engine...

Started by Imperio59 12 replies 4.3k views
Original Post
Imperio59
Imperio59
Hey! I'm just getting started with making a small engine to render basic terrain... For now it'll only have one texture, it'll be rendered from a heightmap wich will be taken from a greyscale bmp... Ok, this is all nifty, but i was thinking about having a 256x256 map... Ok, this gets a bit tougher here, i have to draw 32K some points, well more like twice as many trianles, so around 65535 triangles... So far so good, the plan is to render triangles like so: Here... But! 65K triangles is a lot... I already had planned i'd use some sort of optimisation technique, even though i hadn't realised the number of triangles involved... anyways. Quadtrees! I know the basic theory about quatrees, but the implementation has me wondering. If my camera is on the edge of the terrain, i still have to draw all those polygons! Then quadtrees and all those nifty techniques are wasted... Sooo... Should i put in some kind of max viewing distance in this case? If i find that i have to draw over... say 10K triangles, then what should i do? Make the max viewing distance lower? Render bigger triangles (LOD management)??? I still wanted to try and see what my FPS would be like when drawing all 65K triangles to see in the end the FPS increase :) Anyways, are there any good articles that talks about all these problems or should i just go with the flow and handle problems as they come up (i know this is usually the wrong way to go but...) ?
Imperio59 - C++ Programmer
Funkymunky
Funkymunky
Well, you could implement some sort of LOD scheme, like the ROAM algorithm, or SOAR (my personal favorite.)

If you're just gonna use a straight brute force w/ quad tree, then yeah you probably want to include a max draw distance with some fogging.
jjmontes
jjmontes
First, implement that terrain engine, then care about framerate. As beginners is the best we can do.

Anyway, you can always strech that heightmap to 128x128. That will work reasonably well in any card nowadays.

Hope it helps.

-=[ J ]=-I always forget to change the tagline.
TempusElf
TempusElf
Quote:
Original post by Imperio59
If my camera is on the edge of the terrain, i still have to draw all those polygons! Then quadtrees and all those nifty techniques are wasted...


Huh?
The only time a working quadtree would have you rendering the entire terrain is if you're viewing frustum covers the entire terrain... this is a bad idea


but maybe I don't clearly understand what you're saying

edit:

well after thinking about it... I guess it wouldn't be so bad for the frustum to cover the entire terrain because you don't want distant things to just dissappear all of a sudden... so a LOD algo would be a good idea... in any case, if this is your first implimentation, a quadtree with out LOD is at least better than rendering the entire map every frame

[Edited by - TempusElf on October 19, 2004 8:08:12 PM]
Trienco
Trienco
whats your target system? because 256x256 can be considered small to tiny for modern systems. cut it up into 32x32 pieces (16x16 if it makes you feel better) and just brute force frustum test all of them (for a small terrain that should still be faster than a tree).

about seeing every single triangle. sure, might happen, but do you REALLY want a player to stand a corner with empty space right behind him? do you really want a horz fov of 90° or more?

do it like above first, if you then find it running too slow you can still think about lod (hint: unreal tournament seems to be using the same map size and does nothing but frustum culling... seems to be fast enough, isnt it?)
f@dzhttp://festini.device-zero.de
technobot
technobot
These days, 65K polys is not that much. Here's how you should go about this:
1. Brute force the entire terrain.
2. It is quite possible you will still get high frame rates. If so, you are probably fillrate limited. To test, change the resolution of your window. If the framerate changes significantly, you're fillrate limited and the polycount is not an issue. If the framerate stays about the same, you're probably geometry limited (could also be bandwith limited, but probably not). If the latter, continue:
3. Break up your terrain into chunks (32x32 quads is a good choice), and implement frustum culling. If you really were geometry limited, this should give a noticable speedup. If so, continue:
4. Switch to vertex arrays, if you're not using them yet.
5. Switch to indexed triangle strips.
6. You should be getting good framerates by now. If you want to go even faster, and your card supports it, switch to VBOs or their DirectX equivalent (depending on the API you're using).
7. Optionally, cull the chunks by a maximum view distance, and add fog to hide the cut-off.

There is little use in implementing LOD for such a small terrain.
Michael K.
Imperio59
Imperio59
Yea... So The API i'm using is OpenGL for now...

I'm done doing the basic BASIC stuff right now :p

I have my terrain rendering at a constant 60 fps (my Geforce FX 5600 is capped at 60 fps, so that's fine). Let me say it was quite a head rush seeing my terrain rendered like that :p I first did it in wireframe, then i tried doing colors but i'm still fiddling with those so it'll look nice and allow you to really see the terrain instead of big patches of the same color...

I'm doing the mouse controls atm, i only had the keyboard controlling the camera before...

So yea, i'll probably implement some sort of view frustrum... The radius idea sounds good, i might do it straight like that using that formula :)

Once i'm done with that i plan to add texture and probably generate the terrain from some sort of heightfield, bmp or otherwise (right now i'm using rand() to generate something wich looks quite nice when you contain the rand() values to a small interval...

Anyways, do you think it's a good idea to expand from that engine? I was thinking i'd burn the project as it is for posterity and then expand on it to maybe add models, lighting, texture maps... :D
Imperio59 - C++ Programmer
technobot
technobot
Quote:
Original post by Imperio59
I have my terrain rendering at a constant 60 fps (my Geforce FX 5600 is capped at 60 fps, so that's fine).

Yes, I forgot to mention: to see what performance you're really getting, you need to turn off vsync.
Quote:
Anyways, do you think it's a good idea to expand from that engine? I was thinking i'd burn the project as it is for posterity and then expand on it to maybe add models, lighting, texture maps... :D

I don't see why not..
Michael K.
Imperio59
Imperio59
Sooo, i kinda left this topic for a while, i just tested with Vsync off and i get around 110 FPS, not too bad methinks :)

Now i gotta work on getting my camera to work, it's kind of lame at the moment :(

Anyways, don't know if i'll be able to work on this for a while since college is so demanding and all that, but i think the next step would be to indeed add LOD (probably split them into 16x16 or 32x32 and use brute force to calculate if they are within our view radius...)

There's also another option wich Star Wars galaxies uses for it's terrain, it has a certain radius where High LOD is used, and after that radius low LOD is used , the terrain renders very, VERY far away distances too! :)

Then i was thinking i'd try to add textures , and after that try to put in a model inside the engine, probably importing from a common model format such as .mdl or maybe a Gmax file directly if i can find info on the format...

Then put in animation, and maybe even physics... OOOR... the code'll get too messy and i'll be left with a small but shiny terrain engine demo ;)
Imperio59 - C++ Programmer
Trienco
Trienco
Quote:
Original post by Imperio59
There's also another option wich Star Wars galaxies uses for it's terrain, it has a certain radius where High LOD is used, and after that radius low LOD is used , the terrain renders very, VERY far away distances too! :)


thats more or less the basic concept of lod. if you use distance or screen error or whatever, usually the effect is that something far away will end up with a low lod. and after playing swg a few weeks with 512mb i would really stay away from that as a rolemodel (though chances are its just their caching thats completely screwed).

adding things later on like that is.. usually messy and you tend to just squeeze in some code here and there and suddenly realize youre running out of places to squeeze something in without breaking something ,-)

but the terrain itself should be pretty standalone anyway with just a few functions to create/load/render and return the height at some position (or allow access to the heightmap, depending on your plans).
f@dzhttp://festini.device-zero.de
WhileTrue
WhileTrue
If you're going to do LOD then definately check out Chunked LOD. I've done a lot of lod routines and Chunked LOD is the best I've used for really large terrains.


But to be honest, a 257x257 heightmap (256x256 quads) should be rendered brute force. It really isn't all that much to render and most cards can do that pretty well. Use indexed triangled strips and render them all together in one call and you should be more than ok.

The other thing is, for the game I'm doing with my university club (http://www.uvicgamedev.net), we started with a 256x256 heightmap but really, a 64x64 heightmap can be scaled to cover the same amount of area. The only cost is your hills have a little bit less roll/smoothness but still, our hills look natural. 64x64 does a good job when you scale it. I would say 128x128 would definately be more than enough.

My two cents..

--Daniel Guillamot
Imperio59
Imperio59
Yea i guess i'll try brute force for now :)
I was also wondering, and i've searched a bit on the openGL forums for this (maybe this isn't the best forum to ask but i've got a thread open here sooo):

How do i render my texture over square areas, when i'm rendering triangles? (In OpenGL)

Right now i'm using direct calls to send coordinates of all points for my triangles, but i'm wondering how i need to order my call so that the texture will end up covering the square and not just one triangle with it cut in half... I've heard of mip mapping, but i don't understand it, and Nehe's tutorials render on quads only :(
Imperio59 - C++ Programmer
Wudan
Wudan
I just figure out what a triangles S / T tex coords depending on it's X / Y values (in my implementation, Z is up), it's very simple to do:

float CoordfromVal( float val, float blocksize ){    float var = val - val/blocksize;    return var / wide;}


The val is the X, Y, or Z value you feed the function, and the blocksize is how often along said plane you want your texture to repeat.

Topic Locked

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

Sign in to reply to this topic.