I''m not %100 certain that what I''m about to say will make much sense, but what the hell...
If I remember correctly, the guys that made Drakan (Fabulous Game by the way) used multiple height maps layered over each other to make their levels. You''d have one height map representing the floor, walls, bumps in the ground, etc... and another representing the ceiling. You could even make more floors and ceilings to create different floors and cliffs and varying heights. Crypts and dungeons and such were built up from seperate objects (You had different kinds of brick walls, stone floors and such).
All of this comes from messing around in the editor, so I''m not certain that this is how they did it. Sounds like something that may be fun to experiment with though.
As for the engine I''m working on. The geometry is created in a 3D Modelling program (E.g.: 3D Studio Max) and imported into the engine, where it is then run through an octree. At least that''s the way its going to work once I finish up a few other things and get started on it. I plan on being able to store the resulting Octree in a file so that it doesn''t have to be regenerated every run, as well as implementing some sort of LOD on each node. I suspect some sort of occulsion culling will be useful to in order to get rid of the caves and mines while stomping around outdoors.
Making True Terrain
Author
Well, for this game I want to have really massive outdoor levels so I want to be able to implement some LOD... so that basically rules out loading a bsp or a 3ds level
Multiple heightmaps sounds feasible, but maybe I'll just not include caves or overhangs and just concentrate on fixing the texturing problem with really steep cliffs
I'll build a program to generate the texture coordinates based on the area that the triangle covers, instead of just the area as viewed from above... In effect fixing the texturing problem
and generate a texture based on slope, height, etc. (I know there's some papers out there on that)
Suggestions? Comments?
[edited by - nexius on November 10, 2002 9:43:45 PM]
Multiple heightmaps sounds feasible, but maybe I'll just not include caves or overhangs and just concentrate on fixing the texturing problem with really steep cliffs
I'll build a program to generate the texture coordinates based on the area that the triangle covers, instead of just the area as viewed from above... In effect fixing the texturing problem
and generate a texture based on slope, height, etc. (I know there's some papers out there on that)
Suggestions? Comments?
[edited by - nexius on November 10, 2002 9:43:45 PM]
The huge-scale terrain engine I''m designing (as a very background project, school''s gotta come first) is based on a big quadtree-sorted list of bezier patches, with some limitations for performance. But the limitations can be disabled on a per-patch basis, and thus overhangs, cool terrain features, and much more is possible.
I''d considered once adding a CSG element, subtractive shapes, that I would use to punch holes in the terrain, so that buildings could have basements without manually adding and manipulating the terrain patches to "fit" the building.
I think I considered that because I wanted to be able to blow the buildings up, in-game, unscripted, and simply remove the subtractive "base" of the building when I remove the building.
Whatever the case, bezier patches are an incredibly memory-efficient way to store massive and detailed maps, and very easy to implement LOD for. Just a thought.
I''d considered once adding a CSG element, subtractive shapes, that I would use to punch holes in the terrain, so that buildings could have basements without manually adding and manipulating the terrain patches to "fit" the building.
I think I considered that because I wanted to be able to blow the buildings up, in-game, unscripted, and simply remove the subtractive "base" of the building when I remove the building.
Whatever the case, bezier patches are an incredibly memory-efficient way to store massive and detailed maps, and very easy to implement LOD for. Just a thought.
Author
cool!
I have a few questions though.
1. Is there any advantage in using a quadtree with this particular method as opposed to an octree?
2. Wouldn''t the fact that the edges around these patches must always exist on the same plane make it look kind of cheesy?
3. Could you maybe use a heightmap to position the vertices making up each patch to solve this problem?
4. Since it''s a mathematical function, would this make collision detection any easier?
I have a few questions though.
1. Is there any advantage in using a quadtree with this particular method as opposed to an octree?
2. Wouldn''t the fact that the edges around these patches must always exist on the same plane make it look kind of cheesy?
3. Could you maybe use a heightmap to position the vertices making up each patch to solve this problem?
4. Since it''s a mathematical function, would this make collision detection any easier?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
