I've heard that some games import their levels into their games directly as meshes created in 3DS Max or some similar program. (For example, say an .X mesh or .3DS mesh). This sounds attractive, but I'm completely lost as to how you would render such a level efficiently. You can't just merrily stick your nice fat level into a single vertex buffer and blast it away to the GPU every frame. I have an idea of how to render this efficiently, but I'm still a bit shaky on acceleration methods since this is my first indoor game. So, if anyone could please give me some feedback or point out some other strategy I should look into, I'd really appreciate it! So... I figure the first thing is to spatially partition the level into chunks, so that, based on the position and orientation of the camera at time X, you can determine which chunks to render.. Since the game is in a typical FPS style, I think it would suffice to simply divide the level via 2D grid into "patches". So, at run-time or as a pre-processing step done in a homebrewed tool, the level would be quantized into these squares based on their X and Z coordinates, and then grouped together into smaller sub-meshes. In the engine, a separate index buffer will be held for each "patch" so that they can be rendered individually. These patches could be culled with a quadtree.. I *think* a quadtree should suffice; octree isn't necessary because for an FPS kind of game, the level is for the most part "flat", and your camera is centered around eye-level. The function of the quadtree if I understand correctly, is to reduce the amount of tests that need to be done to check if patches fall into the view frustum. So, this will help narrow down the things that needs to be rendered. However, things behind walls shouldn't be rendered, even if they're in the frustum. So, on top of the quadtree, some form of occlusion culling needs to be used. Exactly what, I'm not sure yet... I've heard of portals, but haven't really studied them in depth. Well, that's the plan so far :/ Please let me know what you think. Thanks very much in advance, roos

If I were you, I'd probably just test out what you've described so far, and then only add more optimizations if it renders too slowly.

One thing to keep in mind is that your level doesn't have to be one large polygon soup: it'll usually be divided into logical nodes as defined by the level builder. Each node has a position and (implicitly or explicity) a bounding-box. This makes the whole endevour less like managing a huge bucket of arbitrary polys and more like a scene-graph.

For the large meshes that need more aggresive optimization (eg. BSP), the standard solution is to run the level through a post-processor because it's too much to do at load time.

Morbo

Hmm... ok thanks for the advice.

I guess the first thing I'll do is try rendering the level w/o any optimizations, just one big mesh. The game is targeted towards higher-end machines (support ps 2.0) anyways so rendering a small level with simple geometry that has say, 5-8 K polys every frame is probably not going to put a major dent in the fps.

Eventually I'll probably have to split up the world somehow, so that collision detection can be done efficiently. Oh well, guess I'll cross that bridge when I come to it. Thanks again!

Quote:Original post by roos
Hmm... ok thanks for the advice.

I guess the first thing I'll do is try rendering the level w/o any optimizations, just one big mesh. The game is targeted towards higher-end machines (support ps 2.0) anyways so rendering a small level with simple geometry that has say, 5-8 K polys every frame is probably not going to put a major dent in the fps.

8k? you wont need anything fancy for that. my grandma could fingerpaint that in realtime.

Quote:
Eventually I'll probably have to split up the world somehow, so that collision detection can be done efficiently. Oh well, guess I'll cross that bridge when I come to it. Thanks again!

yeah. if you want some simple culling aswell as collision later on, just fo the challenge or maybe to do bigger levels later on, you wont need to wrench it in later on or need duplicate partitioning schemes. also an octree isnt much extra hassle over a quadtree, virtually none actually, and youll be able to have high structures without completely recuding the efficiency of your culling/collision.

Quote:8k? you wont need anything fancy for that. my grandma could fingerpaint that in realtime.

Lol :) Yea, I assume it shouldn't be bad. Not quite sure how it'd be when factoring in pixel shaders and shadow mapping though, but hopefully ok.

Alright, I will rework my quadtree code into an octree since you guys seem pretty sure it'll be better.