Building With Static Meshes

The introduction of Static Meshes has radically changed how maps are built. In the The Curse Of Static Meshes article, mappers explain their problems with this new technique. Here you'll find solutions.

Acclimatizing

rough thoughts to refactor:

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)

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.

Problems

Quick cures for static mesh ailments:

Finding the right mesh

Epic's mesh packages are notorious for being an absolute mess, with no logic to the way the meshes are organized. (Hello? 80% of meshes in "misc" group?)

Try our Static Mesh Package/Index. There's also an app being worked on that will let you search them by keyword.

Meshes stuck in maps

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).

However, some players delete standard maps they do not like from their hard drive – mention the dependency in your map's accompanying text file.

PrePivot

Some meshes are always off-grid, no matter what you do to. This appears to be down to shoddy work on the part of Epic.

Use Display → PrePivot to put awkward meshes back on grid.

Scaling Textures

SMs can be scaled to any size, which is great! But the texture they carry is scaled too, and sometimes this looks like crud if you make the mesh too large.

Create a TexScaler in MyLevel to rescale textures in a flash for static meshes you've scaled. For example, if you have doubled the size of the mesh, halved the size fo the texture to compensate.

Bad lights

A number of light meshes have the actual light part displaying a material that is set to unlit. You can find normal versions of the material if you look in the texture package it comes from, eg UCGeneric.

No back face

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

You might have to put two meshes back to back, or create a two-side version of the material that is applied. Or use CSG brushes to fill in the gaps.

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.

Briefly, you can change the following aspects of a placed mesh:

size
rotation
displayed textures

Opinions on static mesh mapping

The Curse Of Static Meshes – the curse

anything below here please refactor or delete!

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.