Sign in to follow this  

Rendering a level

This topic is 4743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
I agree with Kelly -- the main motivation for how you group and store your world geometry has to do with performance bottlenecks. If you want to do hierarchical visibility testing, you will probably want to precompute a KD-tree or BSP. You can also merge static objects together which might have been saved separately because of texture boundaries, or convert from triangle lists to strips for smaller data sizes.

Start with the most obvious, simple-to-implement method (list of renderable objects) and then profile to find out what you need to change.

-Tom

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:

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.


What are you talking about? Levels were like that back in the original DOOM days. Every modern FPS is fully 3D and the camera is completely free. I would say that a system based in Octrees&Portals with some kind of LOD would be great for start. Traditional BSPs are kind outdated.

Share this post


Link to post
Share on other sites
I'm with Eelco - I'd just use an octree instead of a quadtree. Sure, you might be thinking your levels will be small... but you might start adding things here and there, doing some fancy shaders... and then suddenly the framerate can skyrocket. Plus, you'll be rendering models as well - that's something to think about too ;)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4743 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this