The Curse Of Static Meshes

Unless you've been living under a rock for the last year you'll be aware that these things called static meshes are used to build most of the geometry, detail, and decoration within a UT2003 map. Static meshes greatly speed up the rendering of a level and make creating a great looking level as simple as dropping a set of appropriate meshes into position. Easy right? Wrong.

Constructor – Consumerism

The introduction of the static mesh forces level design into a constructor-consumer process. Maps cannot be created without static meshes. Static meshes require modelling and texturing. It is very unlikely that one person will be skilled in modelling, texturing, and map making. Instead a team of people are now required to create a single map.

A modeller, to build the required meshes to the specifications supplied by the map maker.
A texture artist to skin the static meshes, and provide the few "flat" textures required, in a style specified by the map maker
Someone to actually build the maps, handle bot pathing, weapon placement etc.

In itself this explosion of people required to build maps may not be a bad thing. It allows people to focus on what they do best (be it models, textures, or maps). The downside to this is the additional communication required between the people involved in producing the map. It takes more time, and a map now requires way more planning. After all, the modeller needs to know what meshes are required.

In theory map makers have enough static meshes at their disposal that they can build numerous and diverse worlds without giving players a sense of bland deja-vu. Which cunningly brings me on to my next point.

No Diversity

One of the criticisms of UT2003 is the lack of diversity amongst the levels. If you take some time to browse the mesh sets supplied with the game you quickly realise why that is. There are very few mesh sets in use. Compared with the overwhelming number of different textures supplied with UT, the number of textures available (even including the skins for the static meshes) in UT2003 is really very small. The diversity of the static meshes available to you by default is tiny.

You have a choice of computer technology, or industrial technology. There are a couple of odd ones (like the ruination set and the Egyptian set). Even then, the meshes that ship with the game have been restricted to those required to run the levels. There are no additional meshes for a map maker to use in the construction of their level.

It’s not surprising all the levels look and feel the same.

Since static meshes are here to stay people will have to live with them. I confidently predict that there will be a huge number of levels for UT2003 – and I also confidently predict that all of the maps release within the first six months to a year of the game’s release will look and feel the same. The only exception to this will be the out door maps. These have the potential to be unique.

Sets

Static meshes seem to be largely:

"techy" stuff: HumanoidArchitecture, Abbadon sets etc
natural stuff, like giant rocks, huge chunks'o'terrain, trees. Some of these seem very level-specific, eg most of the mountain pieces in CTF-Magma.
Quake3-ish stuff: basically, things with added spikes, and a few demonic heads
some large chunky bits of ruined castle, seen in BR_Ruination.

As far as I can tell, there's no set for castle-type stuff (eg the style of UT's DM-Curse][, DM-Codex, DM-Peak.)

LegalAssassin: Nor is there gothic stuff. So, instead of whining about Epic being lasy, I'm making a gothic pack of Shane_Church.utx. Sure, it'll take time, nut who's got a life AND adds to the wiki?

Tarquin: Wish they'd organized the packs better. So many meshes in the "misc" groups! A gothic pack would be great. I wonder if we should set up pages for requests – mappers could send in mini-maps of basic shapes they want for the modellers to consider.

LegalAssassin: Agree on that. There's even the same mesh in different packs to I think this page'd be cool, sort of a: request gothic stairs, doors and windows and unless the modeller is lazy he'll throw in a bunch of decos and some trim too. Basically what the good ol' texture pack should contain.

A New Process

So, how can the lone map maker survive in the brave new world of static meshes. A change of approach is required. One option is to simply wait for a year or two for the number of available static meshes to reach a critical mass where levels will look and feel different. Discounting this approach for the time being, the following is suggested.

Construct a basic map outline.: The map maker builds a map using very basic BSP geometry (cubes). At this point, the map doesn't have to be lit or textured. It just has to be good enough for the flow of the level to be tested. If a level feels good to run around in, it's likely that it will feel good to play. Basic player starts, flag positions, weapon positions may also be tested at this point. There should be no detail at all within the level. The pillar you want decorated with entwined snakes in the centre of your level should be built using a cube.
Specify meshes needed.: The map maker must then specify a set of required meshes complete with internal (in the case of arches) and external dimensions, and texturing ideas to the modeller and texture artist.
Create the meshes and texture them.: The modeller and texture artist then need to build the meshes the map maker has specified, passing them over to the map maker for actual insertion into the map.
Iterate until complete.: It is extremely unlikely that the flow of the level will be perfect once the BSP blocks have been replaced with meshes. It's also likely that meshes won't quite fit where expected, or have too many polygons, or the textures don’t look quite right. Map completion simply becomes a case of iterating back through all of the steps above until you are happy with the result.

Map Making in the Future

So are static meshes a step in the right direction? It feels like they are, but in the short term it will cause some pain. Until there is a huge diversity of meshes available to the casual map maker, mapping teams (or the occasional multi-talented uber-mapper) will be the only people producing things of any note.

The number and diversity of meshes shipped with UT2003 is nowhere near the critical mass required for an explosion in diverse maps with quality.

Some of tarq's thoughts

Firstly, there's going to have to be division of labour, just like UT mappers didnt make textures.

Next, how about making a map in old BSP-style, and THEN isolating parts to be re-made in Maya? Can UEd brushwork be ported to Maya for cleaning up, or is it only a 1-way process? Can Maya clean up whatever it is that UEd does that is suboptimal (me SLAPS UEd!)

erm. other thoughts to follow.

Foxpaw: UnrealEd doesn't actually do anything bad to static meshes, per se. The page on UDN is a bit misleading. Basically what happens is when you manipulate BSP a lot in UnrealEd, the faces become very slightly misaligned, so they don't share vertices anymore. If you were to say, import a brush as a DXF and make it into a static mesh, you don't have that problem. It only afflicts areas where a lot of intersection and transformation/rotation is taking place.

EntropicLqd: I did wonder whether you could encourage UEd to generate "clean" brushes (or meshes) with copious use of the Intersect operation. A static mesh is simply a whole heap of merged objects anyway. The other thing that occurs to me is that even though a UEd brush is not as efficient as a "Maya" brush" the number of polygons within the brush itself is likely to be much less. As for your suggested approach that's exactly the approach I'm going to take (as described in the second to last para above). While I agree that mappers rarely made texture sets, texture sets didn't influence the type of geometry available to the mapper. In UT2003, level geometry is ultimately controlled by the modeller and not the mapper. If I get time (hah) I might refactor this page so that it's worthy of the title. It's a little to random and ventive. At least when I rant here people have a clue about what I'm going on about. At work they just go, "yeah, whatever, drink less coffee."

Tarquin: textures influenced mappers! 32-wide trim everywhere!

EntropicLqd: I always scaled mine down to 16

Aphex: I make texture sets! Yes I agree with this - we're gonna be numbed with a load of generic-looking maps for a good while now. The whole mesh idea, whilst admittedly speeding up rendering, encourages plagiarism and maps to look similar. I feel I'm split between the olde bsp decor and the new static mesh method now.

I think you can achieve some sort of individuality by re-texturing existing meshes though (this from AGU.ed - not tried it yet)

) select the texture you want to use in the texture browser
) select the mesh in the static mesh browser
) click on → materials → 0 → material
) then click on the use button to use the current texture

the mesh should now be textured.

EntropicLqd: I'll have to try that. I'm going to re-write the above section at some point into a far more reasoned citique of the efect static meshes are likely to have. How do you scale textures back to a sensible size once you've scaled the mesh?. I read through the materials section of the UDN and my brain tried to escape out my ears. Have you looked through the texture sets shipped with the game? Never has so much disk space been taken up with so little. Still, I may have come up with a new approach to mapping (assuming I can stand the ugliness). And I could do with a nice wood/metal texture set sometime. Anything for a bit of variety. I think it's likely that the only cool map's well see in the short term will be outdoor ones.

Flashman: Do these static meshes mean larger downloads as well? Just a thought to go out to those poor, helpless 56k'ers. Re-usable Geometry of any kind is a usefull thing for a development team and I think thats what the design teams on UT2k3 were thinking of, in addition to the faster draw speeds. Previously I've managed to pull neat tricks with the tired texture sets in UT, but you can't achieve the same with a mesh, what are you going to do, submerge half of it into a wall? To a small extent the Level designer has been reduced to a high-tech Lego™ builder, and the texture artists and modellers will be the real creative force. But in having 3 or 4 creative egos on one project you come across another issue in the bedroom level-designer market - have you ever heard the phrase A Camel is a Horse designed by a commitee?

EntropicLqd: Interesting points. The huge level sizes (by the time you've got the textures and the meshes and the maps) are caused by the massive increase in detail. You could reduce the size of the game by bucket loads using lower poly meshes and smaller textures. But would you want to? Unless a map is using totally standard meshes and textures (and there's not a lot of flexibility there as far as I can tell from a very quick perusal) then the map sizes will be fairly significant. I can see where you are going with the brick by brick level designer idea, but level design is more about flow and object placement than it is about lovely architecture. It will be interesting to see what happens. If I was a modeller then I'd be making a light mesh set, with more lights than you can shake a stick at, and a door set, and stuff like that. As UT2K3 has shown, there's not much mileage in producing meshes and textures specific to a level - it's far to constraining. and yes you can embed a mesh in a wall if you so wish.

Tarquin: Try RMODE 2 in the UT2003 Console. I ran this on DM-Asbestos, and I was surprised at how much is still BSP. (and there are still plenty of ugly BSP cuts all over). You get a much clearer picture of how SMs are being used.

EntropicLqd: I did get to see the Electric Fields map from the leaked beta. The whole level was a single BSP cube, with the rest of the geometry made out of static meshes. I'll have a browse and see what I can see though. It will be interesting to see if the levels I prefer have a higher amount of BSP geometry than the ones I don't like, or whether there is a mix.

JoeDark: According to Sweeney there's no reason not to be able to use the old BSP method to make as much detail as you like. Though he says it will be more time consuming to get the level of detail into the map without the use of static meshes.

EntropicLqd: Apart from the performance hit that is associated with BSP geometry I'd agree. Meshes are simply processed more efficiently than BSP geometry. I suspect also that the ratio of BSP to Mesh geometry in the level determines how CPU (more BSP)/GPU (more Mesh) bound your level gets.

The Twiggman: Quite the good rant, made a good read to go with my suppliment of coffee.

RegularX: Also, is it me - or has static mesh usage completely ruined dynamic lighting for maps? In UT99, I could get a DarkMatch style play with little problem. A dynamic light hung off of a pawn would produce, lo and behold - LIGHT. In UT2003 it produces a little glowy point largely ignored by the static mesh around. I'm tempted to return to BSP for basic landscape work and find other ways to tune up performance.

Foxpaw: Well, you can't make a darkmatch style in UT2003 easily because of the lighing on BSP. Static meshes can be lit fairly nicely, but it might not be as obvious. (try setting RMode 6 to see the difference.)

RegularX: Ah, bah, I just caught up on the "BSP doesn't have dynamic lightmaps no more" in UT2003 factoid. So it's not static meshes, but Epic's engine design in general I should be frustrated with. Greeeat.

EntropicLqd: Indeed. The whole lighting thing really irritates me. Maybe they'll have tweaked it for 2K4 - but I doubt it. I'm not expecting it to be fixed until at least the next generation Unreal engine.

RegularX: I'm going to bug the ut2003mods list about it, but I'm of the same opinion - I think it's a beast we'll have to burden.

Foxpaw: Kind of an old discussion, but I think lightmaps are here to stay, though maybe at some point Epic will add a bool in LevelInfo that would allow you to specify whether to use dynamic vertex lighting or lightmaps.

I don't think they will get rid of lightmaps in future engine versions because for most purposes they are far superior from a performance and appearance standpoint. Lightmaps are raytraced, arguably the best way of lighting a 3D scene yet developed. However, as you may have noticed if you've ever built the lights in a large level, (and this is only the relatively simple BSP world that's getting raytraced) raytracing takes a rediculously long time, and won't likely get any faster because geometry complexity increases to keep pace with improvements in graphics technology.

Lightmaps give you the looks of raytracing with the speed of no lighting at all - very good, unless you want to dynamically change the lights. And if that's what you want to do, you CAN set the lights to bDynamicLight before building the map. This scraps the raytracing for that light and just does vertex lighting in real-time during play. Raytracing during play is not really an option for any time in the foreseeable future because that would require either incredible improvements in graphics technology, with no increase in scene complexity, or a massive decrease in scene complexity - by modern computing technology we're talking sub-Wolfenstein-3D level complexity if you want an acceptable framerate doing raytracing in real-time.

RegularX: Speed is all real dandy, but UT2003 still represents a step backwards for lighting tricks (with the exception of a few minor details) than UT99. Heck I had a much easier time trying to do the kind of spook map I currently am with the Half-Life engine. Sadly, I think the Source and Doom3 engine will probably not be burdened with this handicap (almost certainly the latter).

Foxpaw: Well, if you prefer the style of light from Unreal Tournament, you can always just set bDynamicLight true on the light. This skips it during raytracing and does vertex lighting during play. If you want it to move around or anything though, then you'll need to also set it's bStatic false and if you want to destroy it at some point, bNoDelete false as well. It wouldn't hurt to make a subclass of light with those things in it's defaults - otherwise the map will complain when you build it because it doesn't like bStatic things being set not bStatic. It'll still work though, the subclass suggestion should just stop UnrealEd from complaining.

I can tell you that Doom 3 will not have that "problem" since it just uses vertex lighting like Unreal Tournament did. They make it look better through extensive use of shadows though. Or so I've been led to believe. Given some of the claims I've seen from ID about the Doom III engine, (Apparently they've completely done away with textures and just modelled everything.. "down to the pores on people's faces..." so apparently Doom III is going to come with a super-renderer capable of handling a couple billion polygons on-screen at a time. :rolleyes: ) I'd take everything about Doom III with a grain of salt.

RegularX: I haven't found bDynamicLight to revert back to the ease of UT when it comes to terrain and static meshes - esp. for spawned lights, though perhaps I could go all the back to just BSP ... but now we've gone full circle on this . I agree, I take both Source and D3 info lightly, never judge an engine before a release - but the impressions seem to be that lighting will be more of a priority than Epic has made it with UT2kX.

I think all this hassle is a shame considered where Darkmatch was invented though.

Static Mesh Hall of Shame

HumanoidHardware.Walkways.mWalkStair01HA – what sort of size is this meant to be? it doesn't even tile with ITSELF.

Category Mapping
Category Rant