PDA

View Full Version : Why terrains?



Mike The Spike
02-14-2000, 12:01 AM
So many people are talking about terrain rendering,but why is it so popular? I never wanted to play a game that was set in a randomly generated mountany landscape,I mean,what's the big deal? Wouldn't you rather be disembowling a Quake III character inside a big metalic tech complex instead of chasing chickens in Hickstown USA?

Mike The Spike

dmy
02-14-2000, 01:35 AM
i love mountain and country walking, so i personally love landscapes.
find them in games reminds me of wide open spaces, where you can walk, drive or just stay and look.
i also like skiing in places with snow-covered trees... landscapes like the ones found in heavy gear 2 are so well made that the simple wandering around is delightful.

imagine an adventure game where you have to discover things on a very large environments, maybe with a sleepy hollow movie like feeling... fog at your feet, strange sounds... have you ever walk in a wood by evening or night, alone, with just the braze of a sigarette to light your path... ?

well... that's not so much a technical issue...

are you talking about the technical differences between an indoor and an outdoor engine ?

Mike The Spike
02-14-2000, 04:32 AM
Stop it you make me wanna jump out the window right into the woods with a backpack and a walking stick http://www.opengl.org/discussion_boards/ubb/biggrin.gif
Yeah I do mean "What's the big deal with outdoor and indoor?", since if you ask me, a 3D model of the landscape with the 3D model of a shack ontop and a good clipping (i.e. hit testing) algorithm should do the trick, I mean, the program shouldn't make a fuzz about where the player is at, aslong as he doesn't sinkthrough the floor...


Mike The Spike

PS. Tip: Joing the boy scouts! It'l do you good http://www.opengl.org/discussion_boards/ubb/tongue.gif

MikeC
02-14-2000, 04:59 AM
It's a _very_ different kettle of fish.

Indoor engines are designed for very high levels of occlusion - i.e. most of the environment isn't visible at any given time, because it's hidden by walls etc. Visibility determination - BSPs or portals - play a major part in these engines. They also tend to use a lot more textures, which require careful management. Geometry level-of-detail isn't massively important, because geometry is typically only visible when it's very close.

For an outdoor engine, you don't have convenient walls restricting what you can see, so you have to draw a lot more of the world every frame. Progressive geometry LOD becomes VERY important; you have to draw lots and lots of distant stuff, so you draw it at a lower level of detail. Conversely, outdoor scenes generally use less textures.

So yes, it is a big deal; outdoor engines, and transitioning seamlessly between indoor and outdoor, are non-trivial problems. The "just load a model and throw it at the API" approach you're used to with D3D-RM isn't going to provide acceptable performance for big data sets; immediate-mode APIs give you the power and flexibility to do it, but you have to put a lot more thought into it.

Mike The Spike
02-14-2000, 12:39 PM
I respect you're oppinion Mike, and I feel like you are right about some things. Yes it would be crap to draw poly's that aren't even seen, yet you can determine what is to bee seen and what not using geometry. I agree that BSP style approaches don't make for a good outside world renderer, yet there are ways to know what to draw and what not in any case. The simple idea of "draw it from back to front" would work very good to hide stuff that doesn't need to be drawn, yet it still will be and that's probaly what makes it hard on IM and OpenGL developers. If you're going to use some kind of "blocking" method to draw you're world using pre-build geometric blocks, like in Quake, then yes it wouldn't be great for rendering Terain and outdoor scenes, yet when you leave the indoor site, you could simply draw the outdoor mountany hilled landscape asswell, since you're the coder that can put a polygon anywhere inside 3D space, no matter where it is located and what drawing system is used.


Mike The Spike

PS. In short, make an exception by rendering you're outdoor sites in a way that is different then the way you draw the inside.

MikeC
02-15-2000, 03:33 AM
MtS - what are you talking about? You say you can't see what the big deal is with indoor vs outdoor engines, then say that you "just" have to render the outdoor scenes in a different way! Well, silly old us, why didn't we think of that?

If a whole different rendering engine isn't a "big deal", in the context of an OpenGL discussion forum, what is?

I'm trying not to be sarcastic here, but I don't think it's working...

paolom
02-15-2000, 04:53 AM
I agree with MikeC.
I would recall to you, MikeTheSpike, that OpenGL is not restricted to games, and we all examine and discuss the possibilities related to writing good code, in general.
Secondly, writing a game is more of a skillful and brainful process, not just applying stereotypes. The Quake style engine simply is not suited to be applyied to other games, nor it is intended to be, at all!
If you take seriusly game programming for PCs, you'll find that in most situations you can't just take the best algorithms and glue them together: it never worked.
There are so many things to take into account, that you'll find yourself always doing compromises for performance/graphics/playability. The difficulty is when you begin cutting out calculations and code, and strain to obtain equivalent results.
I personally would consider to be offended if someone would say off that my research and work is useless. Why are we discussing here: to improve or to lose our time in disputes?
Game programming is more than coding: it's an art. Be seriuos about that.

[This message has been edited by paolom (edited 02-15-2000).]

Mike The Spike
02-15-2000, 11:05 AM
Look guys,let me give you an example,if you write an application that is to render indoor scenes,you probaly have some sort of "floor" where the camera hovers above,right? What I mean is tesselate the floor of an indoor room,raise the polygons to match a landscape,remove all opposing wall and the roof in the room,and you're set!
This technique can be done by *any* 6DOF indoor 3D engine,using *any* 3D API. even with the BUILD (tm) engine from the game Duke Nukem (tm),you can do such a thing. So to quote paolom,"Game programming is more than coding: it's an art".
Yet I don't understand what you guys mean with switching engines? I'm saying not to switch engines,and use you're current one.And who said I'm forcing yall to give up you're research? Render whatever you want however you want,If you got the time,than that's ok,but I personaly don't,so I use these techniques to render outside locations,that's all.


Mike The Spike

MikeC
02-15-2000, 11:50 AM
Maybe we're talking about different things here. If you mean "outdoor" environments like the odd ones in Quake2 or HalfLife then yes, obviously they're using the same engine. But those levels are very heavily and very obviously restricted to work within the limitations of that engine.

I think that when the rest of us on this thread talk about "outdoor environments", we're not talking about big rooms with sky-coloured ceilings. We're talking about flight-sim style environments where you can see for fifty kilometers in any direction, where you can travel hundreds of km in any direction without stopping to load new level data every couple of minutes, where you can see a thousand square km every frame AND SWITCH TO SEEING A COMPLETELY DIFFERENT thousand square km in a fraction of a second just by turning your head.

Try doing that with a Quake-type engine, and it'll drop dead on frame one. It's a fundamentally different problem, and it needs a fundamentally different kind of solution.

Mike The Spike
02-15-2000, 02:06 PM
Look in the Advanced section for a reply on a thread about terrains, I have posted the source code to what I think is a terrain generator. With that snippet of source, you should be able to generate a 3D terrain out of a single digital image, so you could scan in a picture of the map of the US and fly around it in 3D http://www.opengl.org/discussion_boards/ubb/smile.gif
lol!
I have never coded anything like that before,
and the code is realy short, yet realy fast,could produce photorealistic results, and allows easy customatisations.(And there's even a bug in it! The "detail" variable doesn't work properly). Anyway tell me if this is the right way a 2D terrain should be rendered into 3D,cos I don't know http://www.opengl.org/discussion_boards/ubb/smile.gif


Mike The Spike

PS. Looking 5 miles into the horizon should require drawing every polygon for the next five miles, right?

[This message has been edited by Mike The Spike (edited 02-15-2000).]

malkia
02-15-2000, 02:18 PM
So where is the key for the tent?

Yeah, i like terrains, cause, don't know - Scorch sets my mania - I was trying to do Scorch 3D, but now forget about it. It was all about mother of all games - the Scorch game.

Now I'm trying to forget this, And I'm just making some stuff for fun.

See it: http://EasternAnalog.hypermart.net

a 4DOF craps, you can't look from upside, there is no sky, there are no trees, no tourists, no good water, and uses pure 2D techniques.

And don't forget that TJC's MARS.EXE was the firsT! I'm still wondering this 5kb (or less) creature.

malkia/eastern.analog
malkia@mindless.com http://EasternAnalog.hypermart.net

(Disabling Smiles in this Post)

malkia
02-15-2000, 02:19 PM
So where is the key for the tent?

Yeah, i like terrains, cause, don't know - Scorch sets my mania - I was trying to do Scorch 3D, but now forget about it. It was all about mother of all games - the Scorch game.

Now I'm trying to forget this, And I'm just making some stuff for fun.

See it: http://EasternAnalog.hypermart.net

a 4DOF craps, you can't look from upside, there is no sky, there are no trees, no tourists, no good water, and uses pure 2D techniques.

And don't forget that TJC's MARS.EXE was the firsT! I'm still wondering this 5kb (or less) creature.

malkia/eastern.analog
malkia@mindless.com http://EasternAnalog.hypermart.net

(Disabling Smiles in this Post)

MikeC
02-16-2000, 03:16 AM
MtS - yes, I saw the code you posted. To be honest, you're missing the point. Generating vertices from a heightfield map is trivial. You don't seem to understand the kind of scales involved in high-quality terrain rendering.

Suppose your viewpoint is a human character wandering around on foot. For the terrain to look good close-up, you need a fine-grained polygon resolution, maybe a vertex every meter. But suppose you wander up to the top of a high mountain on a clear day, where you can see for 25 kilometers in every direction.

What are you going to do? Generate the entire 50km x 50km visible landscape at 1-meter resolution? Right, that's 5 billion triangles. With vertices, normals, texcoords... call it 40 gigabytes of data per frame even with perfect tristripping. Hope you've got a fast system.

Obviously, I'm describing the extreme case here. You can probably get away with a lower resolution than 1 meter. You can probably get away with fogging at a closer distance than 25 km. You can certainly cull a lot of geometry that's outside the view frustrum. I'm trying to get the message across that you CAN'T just bung out a 256x256 heightfield and expect to get good results. You're off by a couple of orders of magnitude.

Take a look at Matt Fairclough's Terragen (http://www.planetside.co.uk/terragen) to see what I mean by high-quality landscape rendering. Our mission, should we choose to accept it, is to get close to this kind of quality in realtime. Don't hold your breath.