I don't need to test my programs. I have an error-correcting modem.
"Static" in "static mesh" doesn't mean "doesn't move" – it can be moved, rotated, retextured and scaled (even disproportionally) in realtime. The "static" only refers to the fact that it can't be animated, that is, the relative positions of the vertices are fixed. Hence, static meshes are useful for displaying pieces of architecture that don't move at all or might move as a whole, but they're no good for displaying players, whose bodies need to bend and change shape.
Static meshes are cached into video memory, and so can be displayed many times with little extra overhead. Static meshes are a list of vertices stored once in the video memory (as opposed to "once per frame"), so drawing many copies of one static mesh is a relatively simple operation. When the static mesh is to be displayed on the screen, the engine only has to tell the video card where (and at which size, rotation, and with which textures) to do it.
- to create non-BSP map geometry; the so-called "Hardware Brush". It is this that allows UT2003 to have much higher polycount than the previous UT. Some mappers use these almost entirely after simple subtractive brushes. The StaticMeshActor holds a reference to the static mesh resource. In a way, this is a special kind of Decoration which is completely lifeless.
- Movers display a static mesh (this is changed from UT, where they were a special type of Brush. Movers can no longer be created directly from the red builder brush: a static mesh must be made first.)
- Decorations, pickups and other actors can use a static mesh when their Display -> DrawType property is set to DT_StaticMesh.
In fact, any Actor can be set to display a Static Mesh, just as any actor can be given a sprite icon (such as classes like Trigger have by default): set Display -> DrawType = DT_StaticMesh, and Set The Resource Property Display -> StaticMesh. The static meshes used to build geometry are just actors which do nothing apart from display the mesh
There is a difference to be made between "static mesh resources", as seen in the browser, which are stored like textures; and "static mesh actors" which are placed into a map. Don't confuse meshes with actors. A mesh (static or otherwise) is just the visual representation of an actor. For instance, weapon pickups display a static mesh in UT2003 as long as they're just waiting to be picked up over their spawn point.
There is no Level of Detail optimizing on static meshes or procedural static meshes (Xprocmesh and FluidSurfaceInfo), meaning the full poly count of the mesh is rendered if it is not occluded via antiportals or zoning.
Static mesh resources hold information about how they are textured. However, an actor that dislays a static mesh can override these textures with the Display -> Skins array and Display -> UV2Texture.
Dynamicly accessing original Static Mesh textures requires difficult code but is possible, this allows you to effectively simulate Alpha/Translucent Styles which are not normally possible with static meshes.
The way I'm reading udn2:CollisionTutorial, there are 3 ways a Static Mesh can block:
- per poly collision – the individual polys of the mesh collide with actors, set for each material group, but its slow & sticky for complex meshes, because sometimes collision calculation for thousands of polys take place.
- none at all – use a separate BlockingVolume, or a second static mesh set to invisible (eg DM-FLux2: the ice caves don't block, and a mesh of the same shape but with fewer triangles blocks, set to Advanced -> bHidden)
- Collision Models – which is a bit like giving the SM a permanently built-in blocking volume, and "more effecient memory-wise than blocking volumes" (UDN)
I (Zxanphorian) found, that if you convert your map from UT2003 to UT2004, you might encounter spaces where you stick on some of the static meshes if you rotated/scaled them. Try anything you can to fix it, like aligning it to the grid, tweak the scaling/rotation, or even change the map layout. If all else fails, you can remove these snagging areas as follows:
- Convert the existing static mesh into another static mesh, merely duplicating it.
- On the existing staticmeshactor, set it to the newly created static mesh.
- Change the scaling of it to X=1, Y=1, Z=1
- Change the rotation of it to X=0, Y=0, Z=0
- If you did it correctly, you have now fixed the snagging points! ;)
This is one of the many undiscovered ways to fix the static mesh snagging problem.
This is an example of a snagging static mesh, and if you followed the preceding steps, it will now not snag you:
Begin Map Begin Actor Class=StaticMeshActor Name=StaticMeshActor298 StaticMesh=StaticMesh'SC_Volcano_M.Walkway2' Level=LevelInfo'myLevel.LevelInfo0' Tag="StaticMeshActor" Location=(X=0,Y=0,Z=0) Rotation=(Yaw=1536,Roll=-3072) StaticMeshInstance=StaticMeshInstance'myLevel.StaticMeshInstance551' DrawScale3D=(X=0.375000,Y=0.375000,Z=0.250000) Skins(0)=Texture'ArboreaTerrain.ground.flr02ar' Skins(1)=Texture'ArboreaTerrain.ground.flr02ar' bSelected=True End Actor Begin Surface End Surface End Map
DeepQantas: Be aware that the simple collision models do not save Surface Type or Material information. This is an issue if you need to have metal footsteps, or maybe arrows that stick to wooden surfaces. Per poly collision handles these cases perfectly, while with simple collision you need to find a workaround. Otherwise you'll be stuck with generic footstep sounds. (PS. Please prove me wrong)
JCBDigger: The collision properties are set in the static mesh and cause UT2004 to crash if you try to change them from within UnrealScript. This may be obvious to some but I spent most of the weekend trying to add Karma collision to block vehicles to existing static meshes from with UnrealScript and failed. If anyone knows better please tell me.
Changes from UT
In UT, there was one type of mesh. Decorations that didn't move were just meshes that happened to only have one frame. Collision on these meshes were ALWAYS a simple cylinder collision model.
In UT2003, static meshes are differentiated from animated meshes:
|Type||Directory||Package Extension||[[UnrealEd Interface||Browser]]|
|Static Mesh||/StaticMeshes||.usx||Static Mesh Browser|
|Character Animations||/Animations||.ukx||Animation Browser|
Note: For UT2004 the reference to a Mesh being *.u is not accurate since this type is an UnrealScript compiled code package however "vertex meshes" are fused to the package via importing at compile-time.
The StaticMesh class
Static meshes are completely different from the animated meshes used in UT, even if those only had one anim sequence with one frame. Meshes and static meshes only have as much in common as meshes and brushes, as you can see in this part of the UT2003 class tree:
Object +- ... +- Primitive | +- ConvexVolume (the actual shape of an Antiportal actor) | +- FluidSurfacePrimitive | +- Mesh (meshes without LOD information, e.g. some UT decorations) | | +- LodMesh (meshes with LOD information, e.g. most UT player models) | | +- SkeletalMesh (e.g. some UT and all UT2k3 player meshes) | | +- VertMesh | +- MeshInstance (?) | | +- LodMeshInstance | | +- SkeletalMeshInstance | | +- VertMeshInstance | +- Model (an actual brush in the map) | +- ProjectorPrimitive | +- StaticMesh | +- TerainPrimitive +- ... +- StaticMeshInstance (Contains per-instance static mesh data, like static lighting data.) +- ...
Static Mesh FAQ
- What's the difference between a Static Mesh and a...
- hardware brush
- None, they are the same.
- Decoration actor
- A Decoration actor is more than a piece of world geometry – it can have behaviour (code) associated with it as well. The shape or manifestation of the decoration could be a static mesh.
- normal brush
- A normal brush and be added or subtracted from the world. It may be semisolid or nonsolid. Static meshes however can only ever be added to the world. Solid brushes always cause collisions to occur based upon their geometry. Static meshes on the other hand can be given Collision Models that are distinct to their shape (generally the collision boundary of a static mesh is simpler than the mesh itself for performance and gameplay reasons).
- A mover is a particular type of Actor that can move around the map in response to events. In UT2003, a mover's geometry is taken from a static mesh, so it's just one more of many actor types that display them, with DrawType = DT_StaticMesh. In Unreal and UT, movers were a type of moving brush, with DrawType = DT_Brush
- a "regular" mesh?
- A mesh like in UT,they can be vertex animated.
- Procedural Mesh
- A static mesh whose vertices can be animated by means of UnrealScript. (Foxpaw: I think this might be a regular mesh who's vertices can be animated through UnrealScript.. it seems awfully hard on the video card to attempt to animate a static mesh.)
- udn2:LevelOptimization - How to optimize.
- udn2:HardwareBrush - General information on hardware brushes. //Page Not Found
- udn2:StaticMeshesTutorial - Tutorial on Static Meshes / hardware brush .
- udn2:NoLodOnHardwareBrushes - No LOD is possible on static meshes.
- udn2:ConvertingBspBrushesIsSuboptimal - Why converting BSP brushes to StaticMeshes is a bad idea.
- Building With Static Meshes
- Hardware_Brush - General information on hardware brushes.
- Static Mesh Package – listing of the default SM packages
- Static Mesh Browser
- Static Mesh Modeling
SuperApe: This should be a class page (as well).
Tarquin: No, because that would be StaticMeshActor and StaticMesh without spaces.
Category:Legacy To Do – Needs to be class page.