Building With Static Meshes

Static Mesh – Definition & basics
Static Mesh Modeling
Static Mesh Package – listing of the default SM packages

rough thoughts to refactor into a proper page:

to get an idea of how to use SMs, use RMODE 3 in game, or Viewport Caption Context Menu → Show → Static meshes.
despite what has been said, maps are not mere boxes with meshes: many maps still have a reasonably complex BSP, with things like subtracts for lowered floor areas (in the first map of the DD ladder)

Acclimatizing

Getting used to SM... some rough ideas:

adapt DavidM's old advice about mapping for UT: copy. Take a UT2003 map you like – then rip it up and rip it off. Copy the style. Make corridors, entrances, walkways etc the same way as in that map. If you feel brave, load up the SM packages it uses and experiment with the other SMs in those packages.

Customizing

See StaticMeshActor for useful properties that can be set to alter individual placed static meshes; see Static Mesh for properties of the actual resource that can be edited.

Problems

meshes with no back face – eg the windows in DM-Oceanic

Opinions on static mesh mapping

The Curse Of Static Meshes – the curse

anything below here please refactor or delete!

Using the Epic Meshes

(stealing shamelessly from Mych's post)

If you want to use any of the static meshes Epic's or Digital Extremes' mappers put into their maps' MyLevel packages, you do not have to re-import them into your own MyLevel package. Simply load the map they're in in the static mesh browser as if it was a static mesh package (in fact, since it contains static meshes, it's as good as one)

Lee Perry (of Epic) writes on the Polycount Message Boards:

"Levels and environment meshes are far more my area of expertise. There's many factors that go into your frame rate of course, but it's normal to have about 30K to 60K polys *in view* at any time. Your level could have a great great GREAT deal more than than, it's all about what's visible, and there's many (easy to use) new tools to help with visibility, such as anti-portals and volumes.

For the most part we build level shells out of BSP at about 2-5 times the polys of a UT level, and then we populate it very densely with environment static meshes. These are built (most of the time) in a modular fashion, and pull a lot of the weight level textures used to in UT. Instead of slapping a texture on a wall, now you grab a couple of models and stick in front of the wall. The modular designs allow for a great deal of detail in a level without having to meticulously model a high-detail level. Building static mesh sets is pretty fun stuff, especially when you get the payoff of seeing them all over the web in everyone's levels, and largely used in ways you never would of expected.

You could model 2-3 basic walls (built with edges on a grid prederably), make a door, maybe a cieling piece or two, maybe 2 good decoration pieces if you feel like it, and voilà you'll have 9000 user maps using your prefabs everywhere they can fit them. It's cool to walk into a room you modeled, and not really recognize it because it was built so differently than you intended"

and

"Oh, BTW, for sea surfaces, you'd most likely drop in a dynamic water plane and it would be generated realistically in a way that should never tile. And you can set things like mesh resolution, wave height, etc... on that"

Source: [Polycount Message Board]

General Forum on Static Meshes

Amid cries that "Unreal Mapping is over", let's establish some rough ideas. First of all, people should realize that they're discussing based on suppositions.

Models may come to be treated much like textures are currently treated. That is:

no-one complains that they can only use UT bundled textures,
there's plenty of variety bundled with the game
Epic mappers such as CliffyB have previously expressed surprise at the originality with which l33t community mappers use the built-in textures
some people will specialize and create model packs, the same way people produced texture packs.

Model creating will become an extra job in the process of making environments; this is a natural direction to take since the complexity of the worlds is increasing.

Some more information taken from the Polycount message board (once again eepers stumps up the goods).

Lee Perry (of Epic) writes some more on the Polycount Message Boards:

Actually, Ent, the prefab modeling and level design questions are completely what I'm most familiar with, so no prob at all, ask away, detailed as you like!

No, nothing has replaced zones. They are still the best and fastest way to break up a map. Volume is a general term that could be anything from a damage volume to a volume that changes the physics within it. I imagine you're pretty much refering to "anti-portal volumes though (APV's if you will)"

An APV or simple Anti-portal sheet is something you use only when zoning won't do the trick for you. Rooms connected by hallways and so forth should still be zones, but if a room is really big with an object in the middle, you stick an APV in it, and it helps obscure things behind it (in the same zone). Another key use is in terrain. Say you've got a map with big hills on it. The whole outside is a single zone, but you don't wanna go drawing the whole world when you're outside. So you take an anti-portal and stick it in your major hills so the engine knows it doesn't need to draw things on the other side.

APVs can be any convex shape, preferably with low polys. Honestly I don't think once in the game has one been used that wasn't a simple cube though. it's not a big precision-mesh-fitting operation. Too many anti-portals start to outweigh the benefits of themselves as well, don't go dropping them in every little item just in case someone crouches behind it.

Naming areas can be done in Zone Infos, or a volume can be dragged over an area that does nothing but change the location name.

I don't know why anyone would claim APVs don't work in multiplayer, they're a key factor in getting maps running fast. They do.

Fog does occlude polys beyond it, yes. Unless a material specifically states it's double sided, the engine doesn't draw the backs of polys. It's still a good idea to delete polys you won't see, because there's still overhead with those polys as the engine runs around talking to the vid card trying to decide wether it needs to draw them or not.

Level polys vary a great deal, it's just one of many aspects you keep in mind. Overdraw from loads of particles have a big hit (learn to make efficient emitters!), some materials slow it, etc. But if you're just looking for a ballpark... 20K to 45K polys in view, onscreen, is pretty reasonable. As said before though, it varies widely. You can find cases where a test level pushes 600K polys at a steady 50 FPS, and you can find cases with loads of materials and overdraw and gameplay issues that runs 12K polys at 15FPS.

Luckily there are many tools in game that let you pull up stats and see exactly where your framerate is going as you run around a level, it's pretty easy to spot problem areas.

Source: [Polycount Message Board]

And heres some more fromthe same thread. Lee Perry is one patient guy.

"The way it works is this... if you're looking through an anti-portal and you see a little corner of a wall mesh sticking out behind it, the whole wall mesh gets drawn. If you move so as the whole thing is out of view, obscured by the volume, the whole mesh isn't drawn. So making a complicated volume for this use will generally not make it work better, you're always going to be moving around and seeing things around corners. It's best to use the simplest shape to get the job done."

Static Meshes and Collision

Here's some more fascinating information taken from the UT Modelling thread over at polycount (Props to Lee Perry again ).

"Collision for static meshes is specified in the editor. Bullets and line-trace effects will default to per-polygon no-fuss collision. Player collision will too, but it's a good idea to make a simplified version in editor to reduce this, it gets expensive when you've got 16 people running around your area. That's an easy task, BTW, even though it sounds like a drag, Karma will benefit from that step anyway.

Karma collision *CAN* use per-poly collision, but it gets expensive quick. As with player collision, it's best to bring in your wall, build a relatively simplified BSP surface around it, and designate that as that object's collision. You only have to do that once. As you do that, every instance of that wall mesh throughout the level gains that same collision."

Also, if that's not something you're jazzed about, or you've got something that should really just be a cylinder or a box, in the little mesh browser you can create a collision mesh with like 2 clicks. They're called DOPs, and essentially you tell it which of the simple shapes you want and it shrink wraps that primative to your object. It's very fast, very user friendly, and it speeds up player and karma collision calculation VASTLY. BSP shells generally are only resorted to if a DOP shape isn't really appropriate.

By using these two collision techniques, there's really very few places you need to make any kind of blocking volumes."