The Curse Of Static Meshes

See also Building With Static Meshes for tips on working with SMs.

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.

The Curse of the Triangles

BSP polygons can be any shape and have a number of vertices.

But for meshes, Unreal only renders triangles. All the polygons of Unreal meshes are triangles. For every rectangle in a model, imagine it being two triangles in Unreal after triangulation. This can be misleading when modelling as you may think your model has 200 polygons when in reality it has more like 400. Just multiply in your head the number of polygon's in your model by 2 for a conservative estimate of the number of polygons your mesh will have when triangulated for Unreal.

This leads us to the next curse....

Arelius: Doesn't BSP really get converted to triangles (or atleast squares) before rendering? Last I checked, DirectX doesn't really like to render anything but Triangles.

Lighting on Static Meshes

Unreal Engine's current lighting on Static Meshes really really really really really really really really really really sucks.

Vertex lighting leads to awful artifacts on meshes with wide-area polygons. The reason is that all polygons in a mesh must be triangulated before brought into Unrealed. So if, while modelling, your mesh has large rectangular polygons (you may have been proud of your efficiency in modelling), by the time it is in Unrealed, it will be composed of triangles which breakup the rectangles in ways you did not intend. The lighting system takes the light values found at the vertices of the triangle and interpolates them in the space between the vertices. This creates very very ugly "triangle artifacts" on the model when lit by Unreal. Yuck.

For this reason, walls should almost never be made as Static Meshes for this reason. Getting them to light properly and smoothly will take more time and effort and light actors than it is worth, and probably you will *still* see lots of ugly shadows and highlights unnaturally tracing out the edges of the triangles of the Static Mesh! The worse offenders are slender, long triangles. Avoid these at all costs.

The workaround when triangulation on your mesh producese these long, slender triangles, is to keep static Mesh polygons relatively clustered by adding more triangles manually. Vertex lighting on meshes looks great for tight, complicated geometry, but awful for flat geometry with small, thin polygons in it.

If possible, use BSP surfaces for large flat areas! The lighting is 10 times better on BSP polygons than Static Meshes since BSP surfaces use per-pixel lighting. (Besides, this allows you to flesh out the level even before you have all the meshes, and also it's good for collision). Again, I can not stress enough, USE BSP FOR WALLS IF YOU CAN, as well as for wide-area polygons! DO not try to do this with Static Meshes unless you want to go bald from pulling out your hair, and then publish an ugly map OR your walls have quite a few windows and doors in them, and you have many such walls. In the latter case, BSP is too inefficient and you would be better off increasing the polygon count and using instancing of static meshes, than you would using BSP. Remember that BSP produces many unwanted, undeterministic cuts (polygons) at build time. In addition BSP surfaces bloat the lightmap with their per-pixel lighting.

Texturing Static Meshes

Texturing Static Meshes can be a royal pain the behind. UV mapping is tedious, but what is worse, you can not see the results of your mapping directly in the Unreal level. And what happens if you UV map for a non-square base texture, then decide to switch to differently proportioned texture? What happens if you rescale your skin texture up? You need to re-UV-map or use a TexScaler. This is obviously not a good situation for mappers. Again, using BSP moderately, especially for flat-polygon features of your level, is a great solution to help with this.

A workaround is to use more simple, base textures on your static meshes as much as possible. You can do this by increasing the real, true 3D detail in your meshes (more polygons), while simplifying the textures used. Keep the UV maps simple and straightforward. In other words, do not "skin" your mesh in the normal sense of the word. Then, you can easily swap out multiple tesxtures in Unrealed on particular instances of the static mesh, even if those textures differ in their dimensions (a 256x256 base texture might work just as well in your static mesh as a 512x512 texture.) This requires you to almost always use multiple materials on your static mesh, which has its own inefficiences associated with it at runtime, but most likely you will actually be making your level run faster because you can reuse more base textures throughout the level.

To change the textures used by your static mesh in Unrealed, right click on an INSTANCE of the static mesh in the level. Go to Display/Skins. Press the "add" button as many times as your static mesh has material slots. Then fill these in with the texture you want to stuff into each material slot. These "skins" override the global static mesh material properties seen in the Static Mesh Browser.

Creative Brush Shaping and Unwielded Vertices

Being able to quickly and visually layout geometry in Unrealed directly is very handy. Static Meshes disrupt this feature. For instance, if you are laying out an ancient city where the buildings are irregularly shaped and the streets and canals are curved, it is easier to do vertex editing of brushes directly in Unrealed than it is to use Static Meshes for the buildings, and "guess and check" each one to make sure it fits in the level where you want it.

If the buildings are mostly flat walls, considering using BSP for the basic structure, and ornating them with Static Mesh props (such as window frames, shutters, doors, etc). This not only allows for faster, easier layout directly in Unrealed, but also helps with the lighting problem mentioned above. If you need to build an irregularly shaped roof for the buildings, you could always convert the building brush to a Static Mesh and export it (you must save to a Static Mesh package, then open a blank level, insert the Static Mesh as an instance from your package, then go to the main Unrealed menu, File/Export, and save the map as an .obj file). You can edit, deform the mesh into a roof in Maya or 3D Studio.

Which brings us to yet another curse of Static Meshes (actually, of the BSP–>Static Mesh conversion process). Unfortunately, BSP brushes converted to editable meshes in this way tend to have unwieldednd vertices, which means that the polygons of the mesh that APPEAR to be attached, are actually not! Each vertex is actually two or more vetices!. To fix this, you can use Merge Vertices.

The Blessings

Static Meshes have many benefits as well, including:

1. Faster, easier modelling of complex shapes in Maya or 3DSMax. Maya is especially good at doing vertex-level editing, and unlike Unrealed, the vertices do not become unweilded. The scale and extrude tools in a good 3D editor come extremely handy. For instance, the scale tool (and extrude manipulator's scale submanipulator in Maya) can be used to quickly created draw a selection of vertices together on a Mesh whilst keeping the polygons of the mesh planar. For instance, you can grab the 4 vertices at the top of a box and "scale them down" (draw them closer together) to quickly create a tapered box, even if they are at some strange angle with respect to the grid. Try doing that in Unrealed with vertex editing!

2. They can be FAR MORE EFFECICENT than textures. Contrary to common belief, polygons are actually typically CHEAPER than textures, and here is why: suppose that in UT99 you had a 1024x512 texture that displayed virtual "3D" detail on a wall in 2D. Uncompressed, such a texture would take about 1.5 Megs! Even with compression, it's bound to consume a significant amount of map file size AND texture videocard memory, and plug out videocard bandwidth causing more hitches and lower FPS in game. By using Static Meshes, a mapper can create REAL 3D detail using more simple base textures to "skin" them (including stock textures). The texture use goes down, making everything smaller and faster, and 3D detail is represented with true 3D detail, which usually looks better. Note however, that a 2D texture emulated 3D shapes can show curved surfaces as almost perectly curved (limited only by the pixelation of the texture depending on its resolution). A Static Mesh however will always display some edginess to curves. This is usally not a problem though as gamers have come to accept this, and the effect can be minized by using smoothing groops (or smooth normals in Maya) and enough polygons in the mesh.

Note that Static Meshes are considerably fast when reused throughout a level, because they are cached in the videocard's memory and simply Transformed and Lit in different ways (T&L) to create all the instances in the map at runtime.

3. Reuse in a level with DrawScale3D to create different looking shape variations is very very flexible and much faster than doing scaling of texture elements (in Photoshop/PSP or in a TexScaler – either of these texture scaling methods takes longer than scaling a Static Mesh). If you are working with a lot of relatively simple Static Meshes, you can create many variations in your level very quickly by scaling them. (Note that overly complicated Static Meshes are a curse to mapmakers. It is better to break up the meshes into units that offer the best flexibility to the mapper, while also keeping the overhead of multiple Static Meshes reasonable. For instance, if you are modelling a Roman column, consider seperating the column capital from the column cylinder and base, so that different styles/sizes of cylinder and capitals can be mixed and matched).

4. Lighting information for static meshes consumes far less filespace than BSP. BSP surfaces use per-pixel lighting. Each aggregate of pixels in a BSP surface takes up one pixel of the lightmap. The size of these aggregates (called "sectors") is determined in Unrealed per surface. Right click on a surface, go to Pan/Scale/Rotate. The "Lightmap" option sets the sector size. The default setting is 32, which means that 32x32 pixel cubes on a BSP surface are represented by one lightmap pixel. If you had a BSP surface that was 512x512 pixels, since 512/32 = 16, you would have sixteen 32x32 sectors and sixteen pixels of the lightmap would be used by this BSP surface. You can imagine how big the lightmap becomes when there is a lot of BSP in your level. If you are concerned about keeping the filesize of your map down, then try to use more static meshes with higher tesellations. This will allow you to emulate the smooth lighting of BSP to some degree (although it will be finicky and time consuming to get it to look ad good), while keeping the filesize low. Lightmaps and heightmaps are the #1 contributor to huge filesize. The per-vertex lighting of static meshes buys you more efficient filesize at the cost of less efficient runtime. Note: this blessing will be nullified in future engine builds because of Normal Maps which will be HUGE and increase the filesize of maps considerably when static meshes are embedded in myLevel.

So what do I, the mapmaker do???

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.

King Mango BAD IDEA! This changes the package and creates potential mismatches. A better method for retexturing meshes is to open the particular mesh's properties and under display>skins, click add and then use as many slots as needed to reskin the mesh once it's actually in the level you are working on. You may find that you need ot add several and leave them blank before you get to the place holder related to the texture on the mesh that you are looking to replace.

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

CyberSirius: You Mean DeathMatch?

Foxpaw: It's meant DarkMatch - a deathmatch variant where all the lights are turned out. The precalculated lighting in the second generation Unreal Engine makes this very challenging.

Dirk Fist: Actually Quake1 did raytrace for lights (very low resolution, not every frame, and only for archetexture). Which was used to create Textures (called LightMaps) that would overlay the geometry. Quake 1 had good framerates on 100 Mhz machines WITHOUT a 3d card (Thats right NO directX or OpenGL not even Glide)

I realise that UT uses a different meaning for the term lightmap. But the absence of dynamic SHADOWS in what is otherwise such an advanced engine is a disgrace.

(more info) http://www.bluesnews.com/abrash/chap68.shtml

Dirk Fist: UED should have included a tool to convert Textures to static meshes. Using two filters the first would relate brightness directly to height. The other would relate brightness to change of height using a Light vector. This would let texture people produce static meshes of moderate complexity fairly quickly. (masked areas would be holes of course)

Radiosity: In response to Foxpaw's comments about DoomIII, yes they have modelled everything really high poly, but those meshes are then used to create a NormalMap for a lower poly version of the mesh. UnrealEngine 3 will be doing the same thing.

Foxpaw: Well... I have to disagree to an extent. A normal map is limited in what it can do. You can't turn use a normal map for hair follicles, because they are three dimensional. Yet, they claim that all the individual hair follicles were modelled in 3D. And, the pores on people's faces too. Though in theory that could be represented in a normal map, it would have to be a very high resolution normal map, which would eat up tons of memory. I'm fairly certain that iD is actually just making stuff up.

LegalAssassin: The inability to weld vertices in UED is by far the worst problem. Not only is it annoying being forced not to map in a map editor, but by not welding vertices the whole point of speeding up maps using Static Meshes is lost. Because the amount of vertices is at least doubled because of this, possibly even whatever it's called when you have 32 times the amount, maybe even worse.

Those claiming "You don't need a 3D application, you don't have to unwrap models, you can texture things in UED and then easily convert to an SM" I would say haven't had even the briefest look at WHY Static Meshes can make things go incredibly fast, rather than just fast.

The graphics card doesn't just have to draw the polygon, if so would be UED SM's would indeed work. Each polygon instead has three points it's drawn between, called vertices, each with its own set of properties such as position XYZ in relation to the model's 0. Each vertex also has the properties for how much light hits it, and what colour the light is, along with texture coordinates and god knows what.

When welding vertices the computer merges all vertices with the same XYZ position into one, thus making the other properties only having to be calculated once, as in the case of lightning, or is built into the SM such as texture coordinates.

I belive anyone can calculate what the lack of welding creates - a whole lot of vertices going back and forth through the graphics card with very few in cache for long, rather than simply having to load the one vertex per corner and thus keeping most vertices on screen in the cache at once.

In respect to this, nobody without knowledge in 3D modelling applications can be expected to have an optimized map which is as fast as it could be, despite knowing HOW to do it. Though I can't imagine the sales department of companies such as Alias Wavefront and Discreet, both selling expensive 3D modelling applications, have noticed the release of UT2003/4 causing a rise in sales, I'm sure warez networks have.

Two years ago one would have to search for hours before finding 3DS Max for instance. Now, when searching the same way, I can find 20 sources in 10 minutes. This is another point, however, and very much of the blame must be placed upon Discreet and for thinking hobbyists would pay $1000+ for doing what they want. Seeing how many of said hobbyists wishes to learn how to use the application completely in order to possibly become professional users one day, a stripped down, limited product such as G-max is completely obsolete. Again, this is not relevant to Epic's sudden lack of understanding modders can't afford the tools required.

Although including Maya PLE in UT2003, no attempts have been made to reduce this problem. Maya PLE was, despite a good idea maybe, rather much of a useless application seeing how more than half of the community in 2003 were still using Windows 98/Me.

I'm in no way impressed by Epic's behaviour neither in game development or the community. While one can argue they don't have to supply tools for modifying the game, the fact is they are using said tools as a sales argument. If they wish to indeed sell games with tools for modification as a bonus, they should make sure everybody can use these tools on the most common platforms and without having to shell out an additional minimum of $100 to use the tools properly.

I would request the immidiate addition of creating lightmaps and welding in UED. As these two things appear to be essential to be able of making something up to amateur level they should be included until Epic removes the large amount of advertising UED on the box of games. As if they'd actually read anything on the Wiki...

I really should have made that a separate rant... oh well, it fits the topic.

McNutcase:

Further reasons to despise smeshes:
- Smeshes are hell itself to align in UnrealEd
- Smeshes need extremely careful alignment to avoid visible holes
- The smeshes provided by Epic are exteremely painful to align with each other due to very badly tiling skins
- Smeshes respond unpredictably to lighting; often, lighting a group of smeshes to conceal the issues caused by Epic's terrible skinning will show the mismatch in sharp relief, and the fix will never be obvious.

Static Mesh Hall of Shame

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

SuicideMissions{CLR} April 5, 2005: added a ton of material to this page about how to deal with static meshes, from the perspective of a mapper who makes his own static meshes, textures, and map. Of course, this could apply to mapping team as well. I believe this page is no longer a pure rant page, but rather a thoughtful, advise-filled page. I realize there was another page for it, but the material seemed to fit better here. Needless to say, the contents need to be refactored. I also have some spelling and grammar typos which I would appreciate someone editing out .

Category Mapping
Category Rant