How should I load a level?

Started by
8 comments, last by Gage64 14 years ago
I'm trying to come up with a simple level format for my game and need a little help designing it. I've created an octree to split up a polysoup and finding the faces that is visible on screen. But I'm leaning towards to use object based level instead of polysoup. So each wall, floor, chair and other stuff are separate objects. All these static objects are then put into the octree and sorted instead of splitting into faces. Is it better to use the object approach, or should I stick with the polysoup? I was also thinking about keeping one instance of each object and then in the map simple link to the object with a position and id. Can I increase performance using the instances? What's the benefits and drawbacks using each approach?
Advertisement
Ok, maybe I'm asking the wrong questions.

How is a level loaded in your engine? Does anyone know how any free or commercial engine does it?
I don't know that the question really has an answer. There are many different ways level data can be represented, both at the file level and in-game, and what will work best will most likely depend on many different factors (target platform, graphics API, scene complexity, polygon count, collision detection requirements, environment type, etc.).

Here's one thing to keep in mind though. Modern graphics APIs (such as OpenGL and Direct3D) will generally benefit from batching, so it would probably be best to avoid a scheme where, say, every section of wall and floor has its own transform and has to be rendered with a separate draw call.

Then again, if the environment is very simple, abstract, and/or densely occluded, it might not really matter (which again shows that there really isn't a 'one size fits all' answer to the question).
If you wish your level files to be human readable (if not editable), you have to organize things into objects, at least. Of course this will probably give you more work, converting if back to a polysoup, or adapting your octree to objects.
My question would be: how do you generate those polysoups currently ?
Thanks for the answers. :D

Ok, so it's not worth having one instance of each object in a level. It is faster to render the objects if all their vertices have the transformation already applied when loading the level.

The levels are object based so to speak when I create them in a 3D modeler. So they are read into the game as a polysoup simply by reading all faces and put them into one big buffer. Then this buffer is split into nodes in the octree.
Objects that you want to interact with at least (pull a lever, move a chair, swing open a door) will be much easier to work with if they're stored as separate objects. You certainly don't want to waste time trying to figure out which vertices in your soup correspond to a door that you wish to animate.
Yes you are right. I was thinking using a different list for all the dynamic objects.
If you go for a binary level format (my personal preference since you can store stuff pretty much in the exact format your game will use it), you may take a look at the way Quake 3 did BSP files for inspiration, you basically have lumps of the different type of objects in your level, and a header with the offset to each of the start of said lumps.
Thanks alot. I'll check out the BSP format. I also prefer binary format since it's much easier to handle.
You might also find this useful. (shameless plug, I know.)

This topic is closed to new replies.

Advertisement