Large Level Creation

Discussion in 'Game Development (Technical)' started by aussiedude, Nov 30, 2007.

  1. aussiedude

    aussiedude New Member

    Joined:
    Nov 14, 2007
    Messages:
    20
    Likes Received:
    0
    Hi everyone,

    I need advice on designing and creating a large 3D game map. The map is basically done and needs UV mapping and texturing. Some objects that go in the map are done too (done trees, rocks, houses, logs so far). It's a fps by the way. For the level of detail I've done in the map it doesn't seem too smart to try and load the whole map in high detail and use that for the game. It doesn't seem too smart because:
    1. I'd need a very large texture for texturing the WHOLE island. Even if I cut corners by doing manual tiling of the texture with the UV map I think I'll still need a texture at least 4096x4096.
    2. Theres over 8000 polygons on the map. All will be textured, plus some will have normal/displacement mapping... it just doesn't seem right loading a map like that when the player will be only seeing about 100 polygons of the map at any one time.
    3. I'll need to be doing object collision on the map for the objects in the game and the player... correct me if I'm wrong but doing a collision detection to a whole map which has 8000 polygons in a real-time game is bad right?

    When I look at games like half life 2 and GTA I can see that the maps have been spilt up. On half life 2 they seem to load all the sections of the level area while only displaying the sections which the player is in. In GTA the developers have their own streaming going so there's no loading screen as the player moves. This is what I need cause it be silly if the player had to see 10 loading screens to travel from one side of a small island to the other.

    OK, so here's my question:

    How do I go about modelling/uv mapping/texturing/loading&streaming a very large game map that can divided into sections and have the low detailed versions of all the sections loaded at the start of a game and the high detailed versions loaded as the player moves through it?

    Any links to info or advice or personal stories on how you personally how done this or how to approach this would be greatly appreciated.

    PS: I remember seeing a game once that was set in a jungle. For the trees up close that had really well detailed versions of all the trees. For the trees in the distance they had flat images of trees that always face you. It was really affective and looked great. I got some photos of trees to use for that exact same thing but I'm going by guess work in how to use them in the game, should the flat images of trees be billboards or what? Any links to info about this would be nice too.
     
  2. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    A quadtree will probably be easiest for your landscape. Do a google search and you'll find a lot of reference material for them.
     
  3. aussiedude

    aussiedude New Member

    Joined:
    Nov 14, 2007
    Messages:
    20
    Likes Received:
    0
    Thanks luggage. The game engine I'm using actually already has a terrain generator that does something like that, but my terrain can't really be represented by a bitmap displacement map, so I can't use it. I think I might be able to use a quadtree for streaming the game level though. Could have a system where the map is divided into four and the section the player is not in are loaded in low detail. Then do another subdivision and load the cell which the player is in high detail and the rest in in medium.

    ... actually on second thought, nah that wouldn't work. I'd have the player in a high section right next to a low detail. Maybe I should just split up my map into 4x4 squares, then just load the square where the player is in high detail and the squares nearby in medium detail and just leave the rest in low detail. Would that work? I know what needs to be done, I'm just not sure about how to do it? :confused: I don't feel like tackling this until I get idea of how to do this.
     
  4. datxcod

    Original Member

    Joined:
    Dec 16, 2005
    Messages:
    98
    Likes Received:
    0
    You mention that you are working on a FPS, and those are usually based around rooms and enclosed spaces, if that's so the you should look into portal culling.

    If you have a big city ala GTA your best choice would be an octree with occlusion culling. If you have a city modeled, you can't just load everything into the engine as a huge model. In games like gta, EVERYTHING is a mesh, lamps, buildings, benches, trees, and EVEN ground patches. You then use a level editor (or modeling app that is compliant with your engine) to place entities (to assemble your map) into a map format that will be loaded into the engine, the engine uses an acceleration algorithm (your scene manager) to construct the scene. An octree algorithm starts with a cube (3 dimensions) enclosing your scene and splits it simultaneously along the three axes, after the first iteration you'll have 8 boxes inside that first cube. The process is recursive and you usually stop after a certain number of iterations have been completed. You then use that data to do massive culling of objects and even for collision detection.

    Hope that helps.
     
  5. Bad Sector

    Original Member

    Joined:
    May 28, 2005
    Messages:
    2,742
    Likes Received:
    5
    If you don't experiment you won't find a good method :p.

    He're is a nice and easy-to-implement idea (that just popped into my mind so it'll have some rough edges, but in general i believe it's doable):

    Split your world into a 2D grid (since you're dealing mostly with a landscape/outdoor area) with each cell being around the size of the player's volume. Take the view frustum and slice it in three pieces with each slice being perpendicular to the near plane. The distance of the slice "line" from the near plane will be the boundary between the detail versions. The first slice (from high quality to medium quality) should be close to the near plane. The second slice (from medium to low) should be around the middle between the near and the far plane. Don't just divide the frustum in three equal spaces between the near and far plane, because the low quality area will take most of the view and the high quality only a small part of it.

    Now once you have the three frusta, project each one of them to the 2D grid. When looking at a projected frustum, you'll actually see a convex 2D polygon. Now, just like if you were doing convex polygon rasterization (imagine the 2D grid as your framebuffer), find the edges. All the cells between and including the edges (in each row) are visible. If you encountered them with the low quality projected frustum, then use the low quality version of the map's mesh to render that part. Similarly with the medium and high qualities.

    Using this method, you have the following benefits:
    1. You only render what's visible.
    2. You don't need to figure out how far the cell is from the player.
    3. If you use detail textures, you only need to change the GPU state twice (before and after rendering the high quality subfrustum).
    4. If you keep a list with the objects that touch the cell (note: an object can touch more than one cell) in each cell, you immediately know what's visible and what not. Also if you have different LOD versions of the object's model, you know which version to use. And these without frustum occlusion checking and camera distance calculations.
    5. By using such a grid, you can limit the collision detection routines to the cells (and objects which touch the cells, if you use the lists i mentioned in #4) to the cells around the player and ignore the rest.
    6. You don't need to precalculate anything (except when loading the level, in order to fill the object lists). When objects move around, you just remove them from the cells they don't touch any more and add then in cells they didn't touch before. If you have many dynamic lights (as opposed to, for example, having only the sun and a baked lightmap into the landscape's texture), it's fast to figure out which objects they affect: just those inside the cells around it (the area is based on the light's size).

    There are a few drawbacks:
    1. If you have indoor areas, you either need to figure out a separate algorithm or split the polygons to fit inside the cells so you can use the same code (each cell will not only include information about the landscape, but also the indoor geometry that is 'over' it). The latter method doesn't take in account indoor areas with rooms over rooms, so in this case both rooms (or actually, the same areas of both rooms) will be sent to the card. Also this case *does* require precalculation (splitting the polygons isn't a fast enough process to be done while loading the level).
    2. The area around the light it's fast to figure out only if you use the rectangular area. However, the light is circular, so extra objects will be considered for lighting. While those objects won't be lit (since they'll be outside the light's sphere), if you use per-pixel shading, the shader will be executed for the pixels that made up these objects.
     
  6. zoombapup

    Moderator Original Member

    Joined:
    Nov 25, 2004
    Messages:
    2,890
    Likes Received:
    0
    Erm. 8000 poly's for a map?

    Sod it, just render the goddam thing from a buffer. Its entirely static right?

    Brute force it.

    Seriously, 8k poly's is NOTHING on modern hardware. Just write it to the right sort of index buffers and make sure you have decent batch sizes and you should be golden.

    For coldet, if youre using something like physx, you could just split the world into reasonbly big-ish chunks and then get physx to bake them. Then simply load the collision chunks as required (store those in a quadtree if you like, but I'd try just loading everything initially).

    As for textures, thats another story. I'd suggest doing a lot of tiling and blending.

    I'll tell you a little story to illustrate:

    I was at a certain car-racing-game-company once (sorry, cant tell you who, as its NDA, but they did a rally game series for a recently deceased scottish driver) anyway, I was wondering how they'd done the streaming for thier world (I mean, you rally down the side of a mountain etc). So I asked them and the programmer I was talking to was looking quite confused, he said "huh? erm, no, we dont stream it. Its all just loaded at the start". This was on the PS2. The trick was that they'd used vertex colouring for the lighting which saved them a ton of memory compared to doing lightmapping etc. Anyway point being, sometimes the brute force method (in this case load everything) is often acceptable. Weirdly enough, their method worked out brilliantly becuase then their day/night tracks were just the same tracks with different vertex colour buffers and they could do transitions between them.
     
  7. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    On a similar note I used to work for a company who now shovel crap onto the Wii. We had to do a monster truck game based on a popular toy license using a 3rd party 3d engine and a 3rd party physics engine.

    We started out following the physics people's advice - treat the track as a heightmap. This was causing lots of grief with the artists so we tried it out using the track as a polygon soup. For the amount of polys we were using there was hardly any difference. Physics time went from 2% to 3% of the total frame time.

    So, as they say. Test, test and test again.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer