When working within a particular level editor/engine, at what point do you decide that complexities in architecture may be better suited to modeling in an outside package, then importing the model for editing/placement? Does the robustness of an engine play a large role? (say, differences in a powerhouse like UEd versus the Torque engine.) Thanks for any comments,

I'd say that depends on your engine's structure. Certain engines use bsp tree's, in which it may be better to use a simple architecture to create the tree with, then put objects (models, though architecture that is set to be ignored while creating the nodes can be used too) into these nodes. With such an approach, model usage becomes interesting.
It also depends on the level-editor. Some editors are quite restricted to rougher shapes, while others allow much more modelling-like approaches. Most editors I worked with don't allow for sub-unit vertex placement for example, so that's where modelling the details comes in handy.

It also depends on the way models are handled compared to level data. In a lot of games models are cheaper to render, for example when they are vertex-lit instead of using a lightmap.
A certain advantage of models is their reusability. You create a model once and you can use it in multiple levels without recreating the same shape, or storing the same shape's data over and over.

I hope that helps you some with deciding what to do. :)

Much thanks, Captain P, for the comments/suggestions.

Quote:

Original post by Captain P Certain engines use bsp tree's, in which it may be better to use a simple architecture to create the tree with, then put objects into these nodes.

I believe UEd uses binary space partitioning, but it seems to promote very complex architecture (in terms of its editing power), then importing static meshes for specifics. (I'm not an expert, so perhaps my interpretation is inaccurate.)

Quote:

It also depends on the level-editor. Some editors are quite restricted to rougher shapes, while others allow much more modelling-like approaches. Most editors I worked with don't allow for sub-unit vertex placement for example, so that's where modelling the details comes in handy.

This makes good sense. (related to my inquiry about the robustness of the engine/editor.)

Quote:

It also depends on the way models are handled compared to level data. In a lot of games models are cheaper to render, for example when they are vertex-lit instead of using a lightmap.

This also makes sense, but raises a question (again, I'm not an expert): in terms of polys alone, will level data and imported models be treated the same when rendered?

Quote:

A certain advantage of models is their reusability. You create a model once and you can use it in multiple levels...

And the over-abundance of reusable Weapon Crates and Flammable Barrels continues. :)

In all seriousness, I recall reading an interview with Rockstar North's technical director (Adam Fowler, I believe?), in which he said they were experimenting with this reuse of models, except applying it to level architecture (for the San Andreas engine). I assume they reuse buildings, signs, etc., in different parts of the game world, but change parameters like scale & color/texture - is this correct?

Thanks again,

Quote:

I believe UEd uses binary space partitioning, but it seems to promote very complex architecture (in terms of its editing power), then importing static meshes for specifics. (I'm not an expert, so perhaps my interpretation is inaccurate.)

Yeah, true. Those detailed or smaller objects don't necessarily need to be models. It comes down on creating objects that don't split up the level into a needless complex bsp-tree. So that may not be a real reason to use models.

Quote:

This also makes sense, but raises a question (again, I'm not an expert): in terms of polys alone, will level data and imported models be treated the same when rendered?

Technically, they're all just meshes of some sort, so in the end, they're treated the same. The difference lies in how you process them - throwing in extra layers like lightmaps or detail-textures takes more time. Of course, adding shaders to objects increases their processing time so a model with normal mapping and other shaders is likely to be more expensive to render than a simple textured and lightmapped level object.

Quote:

And the over-abundance of reusable Weapon Crates and Flammable Barrels continues. :) In all seriousness, I recall reading an interview with Rockstar North's technical director (Adam Fowler, I believe?), in which he said they were experimenting with this reuse of models, except applying it to level architecture (for the San Andreas engine). I assume they reuse buildings, signs, etc., in different parts of the game world, but change parameters like scale & color/texture - is this correct?

Heh, yeah, 'prop' models as they're called are often overused. But the same goes for so-called prefabs, level objects that are made prefabs so they can be easily inserted into new levels. I'd call the problem just generally lazyness... ;)

I haven't read that interview so I don't exactly know what they meant with that, but what I remember from looking at the FarCry editor once is that they had importable models with parts you could texture in the editor. And as far as I know the Unreal editor allows model scaling in the editor. And I know of Half-Life (2) models that they have a groups and textures system that allows you to pick what combinations of mesh parts and what skins you want to use (though these skins or their paths are compiled into the model beforehand).
It depends on how you set up your model format or your levels entity parsing, you can make it as free and modifyable as you want it to be, as long as you set up your engine to recognize these parameters.