Ogre Forums

hello,

I have extensive modeling experience (with multiple applications from real-time specific to art and animation) and I'm starting to design levels for a game.

I'm wondering the best way to start as quick as possible. I have no problem constructing (modeling, textures, lighting, etc) with whatever software, but I want this to go smoothly and work for the programmers.

Any suggestions on getting started?

Thanks,
Ryan

First, I'd talk to your programmers and find out what their requirements are.

xavier,

Perhaps I should elaborate a little. I'm 85% content creator, 15% programmer. My friend is 99% programmer, and not very familiar with content creation. We're starting to design a game (using Ogre) and starting small. I'm researching ways to best create levels for the game to maintain visual quality and simplify programming.

I'm taking the role of creating content for use in a game we'll be constructing. Starting with levels, and hopefully expanding to animated characters. Thus far I've only made props. We have no code to date.

I'll be using 3DMax, Blender, Lightwave, Carrara, Milkshape, and/or Wings3d. Photoshop & Gimp for images.

We know we have a lot to learn, and I'm exploring the forums in all the depth I can stand. But I'm hoping someone can suggest a method and/or format to help us get started with something other than basic boxed rooms.

Many thanks,
ryan

As far as i know, blender exporter is the most functional exporter as in today. Anyways, blender can import a lot of formats, so you dont have to worry much about witch 3d application to use.

Now, someone with some experience in importing animation could tell you more...

You both have to start with an idea of what your levels will do, contain, support, etc. Are you going to have one or more character spawn points? Will those be editable by modders or end users? Will you have weapons pickup points? Warp points? Will you have trick walls or doors that require proximity triggers? How big a level or map will you need, how many simultaneous characters or players? Those are just a few of the questions you need to ask yourselves, and the answers will often provide the answers to the questions you have about what you need to do to create your levels.

For example, for defineable spawn points, you'll need to include some way of passing along where those spawn points are to the level loader and scene graph; one way to do that is with a particular object naming convention in the modeller (if you are using stock modelliing tools like Blender to create the levels), and your level loader would intercept that object and store its location in your game logic as a spawn point (as well as not include it in the scene graph).

Likewise for trigger points or zones (i.e. if you need to open doors automatically, one way to do it is with a proximity trigger, which removes the need to code for distance to particular object types or names).

You will also know how to texture your geometry based on what sort of user experience you desire. If you are satisfied with basic one-pass texture mapping, then that's all you'll need to do during your level creation. If you need more, you can do more.

Beyond that, there is nothing really special about creating level content for Ogre, other than the iterative trial-and-error required for optimizing scene cell density, which also has to take into account details such as the character design, types of animations and LoD in a typical scene. (This sort of density assessment is done systematically in game mod level creators, and the editor will issue a warning if you tried to have too much going on in a particular level cell).

If your app does background resource loading, you'll want to provide "pinch points" of relatively low density (hallways, elevators, etc) where the CPU can get a chance to load missing resources that would need to be used soon (based on where you are in the scene; this is where careful resource file layout is useful). With a relatively small level, you can probably just load up the whole thing at the beginning and go and not worry about it.

But in the end, the things you'll need in your level are usually driven by the technical requirements.

xavier wrote:one way to do that is with a particular object naming convention in the modeller (if you are using stock modelliing tools like Blender to create the levels)

You can assign so called "logic properties" (string, float, int, bool) to scene objects in Blender. E.g., spawn points could be "empty" objects with an int named "spawnpoint" where the value of the ints determine the ordering.

Good point. I was speaking in general terms, but that is a way to do it in Blender.

How does that information make it into Ogre (via .mesh)?

excellent help, thank you!

As they say, I don't know what I don't know but I know that I don't know something... or along those terms.

What I know is how to build a house (or whatever), texture and light it. I don't don't know about is making spawn points and the like or make it some level format. Something to learn.

My starting level is a basic open warehouse. A big square box basically. No doors or anything special. Just some clutter to "maze" it up a bit. Simple modeling and texturing to start.

Its the technical requirements I'm excited to determine. Should be a big change of pace from my typical 3D life. My current concern is isectoring issues. How do characters in the level stay within the boundaries defined by geometry, such as hallways or whatever? Is this purely isector info, or is there special geometry for intersection, etc.

Anyone have sample levels or links to geometry I can use to start our development, and also use as reference?

xavier wrote:How does that information make it into Ogre (via .mesh)?

The logic properties are assigned to Blender objects, i.e. Ogre SceneNodes, and therefore not limited to meshes resp. Ogre Entites. They are exported as node user data by the dotScene exporter.

ryanfoss wrote:Is this purely isector info, or is there special geometry for intersection, etc.

This is done with collision detection, provided with any physics library. See the documentation for ODE/OPCODE and Novodex (Novodex docs are probably easiest to read).

xavier,

Do you mean the geometry of the level itself is used for collision detection to keep the characters within boundaries? If so, wouldn't there be a penalty to creating more intricate/detailed level designs?

I expect that our game will have 100's of entities/characters. Level design for interaction of this magnitude I expect will be trickier. (No, its not an MMPORG or whatever.)

Physics libraries use either a collection of primitives (spheres, capsules, etc) that represent the geometry, or a convex hull can be created from the geometry (generic mesh) that represents the objects. Obviously the geometric primitive route is faster to process, but the convex hull (this is where you'll see the term "trimesh collision" used) is more accurate, at a performance penalty.

Neither method uses actual rendered geometry.

Here is what I recommend in level buiding with ogre
----
Small level for shooting game, or interior: BSP , search WIKI for how to make them, there is demo in ogreSDK too
----
Large scene: DOTSCENE , this format great, exporter are now for max,maya and blender, search wiki too for info and tool
With this format, use a physic plugin or addon to add physic like gravity, collision
----
Hope help