Hardware Brush

This page is largely obsolete discussion & speculation from pre-UT2003 days. See static mesh.

What are Hardware Brushes?

Hardware Brushes (or "Static Meshes" as they will be called from here on), are just as they are called, meshes. These are how the Unreal Engine can push the insane polygon counts this time around, because these meshes utilize your video card's T+L unit. They are created in an external 3D modelling program, such as 3D Studio Max or Maya, textured, then imported into UnrealEd using the ASE file format. BSP is still used for base construction of a map, but the Static Meshes should be used for decorations and much of the architecture.

Static meshes have a collision hull that's separate from their visual appearance. That collision hull can be either imported along with the mesh from the modelling program (as an object with a special name prefix), or automatically generated in UnrealEd (as a convex object with a definable complexity). Of course, the mesh itself can be defined to be its collision hull, which results in per-poly collision.

Some other thing to note:

Static Meshes can be rotated and scaled among X, Y, and Z
Movers are now static meshes, not brushes.
Static meshes can be converted to brushes and vice versa in UnrealEd.
Static Meshes use vertex lighting. To use lightmaps on static meshes, they must be "baked" onto the mesh's textures using a 3D program.
Static Meshes don't occlude; you have to use UT2003:antiportals for that. (For that matter, BSP doesn't automatically occlude either anymore.)

Another great thing about static meshes are that they can be set up with Karma courtesy of MathEngine. For example, you can set up a lamp mesh that hangs from the ceiling (via chain) using Karma. Upon being shot, it with swing and spin realistically. The possibilities can be endless with Karma physics.

See also: Building With Static Meshes

So what exactly is gonna be the deal with hardware brushes? Here's a [Wiki poll]... to vote, edit this page and increment your choice's count by 1. BTW, feel free to add options if you think they're required.

(the alternative, BTW is a [Wiki multiple vote] – harder to read though)

[2] bah, UT2 will ship with tons of groovy hardware prefabs. We'll have hours of endless amusement working with those, just as we were happy with UT's built-in textures for a long time.
[0] a minority of uber-l33t modellers will create new prefabs for the community to use. That will be enough to add to the creative mix.
[0] I intend to or already have a version of Max which dropped off the back of a lorry, honest guv OR I am a professional or rich and I have a legal copy (note: 5th amendment to the US constitution is deemed to apply internationally here )
[1] Existing cheap or free tools will suffice (GMax, MeshMaker etc)
[0] an open source Unreal engine modeller might be a good idea

EntropicLqd: Well, we know the answer now I guess - I looked in my prefab directory and it was empty. There's a rant coming ... I can feel it.

Mychaeel: Try looking into the StaticMeshes directory – it is not quite as empty. (And there are tons more static meshes in the maps.)

Mychaeel: Although I'm a bit biased in favor of MeshMaker, it's main purpose of getting prefabs into maps as decorations becomes more or less obsolete with the introduction of hardware brushes. I understand the new UnrealEd has exactly MeshMaker's functionality built in for converting regular brushes to hardware brushes. – What I don't know is whether hardware brushes are necessarily added to the BSP for collision checking or just optionally; same for raytraced lighting. If those two features (BSP and raytraced lighting) which come at an expense are mandatory for hardware brushes, there might even be a place left for MeshMaker in U2 and UT2003 mapping.

Tarquin: I didn't know UEd will be able to convert BSP brushes to hardware. The general rumblings on the forums are that unless you have Max, you're stuck with the HW brushes that Epic will deliver. Many mappers feel that this will make for custom maps which are just permutations of existing architecture. At the same time, I'm hitting the buffers with my BrushBuilders. There's things I could do, but the parameter list for a builder is longer than the box, has long arrays, and various hacky workarounds such as parameters doing different things in different circumstances. I could do a lot more with a more flexible interface.

Mychaeel: Maybe that's where an external program, putting the brush definition in .t3d format into the clipboard, could come in... that'd be much more flexible than UnrealEd's class property interface while still being way less complex to code and to use than a 3D modelling application.

Tarquin: I think I once saw an app that loaded & displayed a saved brush. I remember a single window app which just loaded a brush & allowed you to rotate it. There's UTToolkit which looks advanced.

Mychaeel: By the way, in response to the last votable option, I had the idea of trying to analyze GMax's native file format in order to create a converter for it a while ago. As far as I see not even GMax's license objects to that – the license for the game developer edition of GMax (with which you can create "game packs") is way more restrictive there, up to the point that game packs aren't allowed to make GMax export file formats that could be considered "industry standard."

Bean: From what I have gathered by snooping and generally trying to pay attention to developers (which is tough to follow sometimes ), you can covert between BSP and HW Brushes in the editor, but it turns out bad half the time. Also, you kinda need an external modelling program to make decent looking prefabs. It's easier to make things in 3ds max than UnrealED geometry-wise. Also, the HW brushes DO use BSP for their per-poly collision detection. Also, the light drawn on to the HW brushes I believe is vertex, but the light can be pre-lit in 3ds max so shadows can be raytraced on HW brushes for an overall more pleasing look. As for the prefabs shipping with UT2003, there will be TONS of them. But most mappers will definately make their own (like me.)

Mychaeel: My point was: Are hardware brushes required to use per-poly collision (and thus be part of the BSP tree)? Or is it also possible to have hardware brushes with the usual collision cylinder, or without collision at all?

Bean: Quoted from build 633 release notes:

BSP trees are now used for collision with static meshes. This results in a delay as the BSP is built when you add a static mesh. It also means static meshes can have per-polygon collision. Since a BSP is used for collision, collision is vulnerable to BSP errors.

Hmmm...

Tarquin: BSP holes in meshes... euwww...!

Mychaeel: Bean, I know that quote, but it still leaves me uncertain about what I asked. The first sentence sounds as if BSP trees are now used for collision with static meshes in any case (nothing in that sentence points to that it's an optional feature). That "can" in the third sentence doesn't mean at all that there are other options like a collision cylinder as well. – But that's all far beyond my point. What I'm actually interested in is: Are static meshes suited (and supposed) to replace decorations in the new engine?

Bean: Yes, hardware brushes are meant for deco and architecture. ive seen many screens of in-editor for U2 and UT2003, and all that BSP (from what ive seen) is used for is to subtract large spaces for terrain and to subtract rooms out for in-door areas. Static meshes are used for the rest.

Mychaeel: What is the difference between "static mesh" and "hardware brush"? (I thought those terms would be used interchangably.)

Bean: as far as i know, no difference. i just inadvertantly used both in my above reply.

Mychaeel: Well, as we know now, it's possible that Maya PLE will be bundled with the game, and static mesh collision hulls can have arbitrary complexity (as opposed to being bound to the mesh's actual poly complexity), so the statement about BSP errors may be true, but isn't as problematic as it may sound.

Mychaeel: Hehehe. Anybody up for creating new paragraph markup for automated polls? Like having live counters, radio buttons and a "Vote!" button? Shouldn't be so hard to implement...

Tarquin: awwww.... it's more fun this way. :-D

EntropicLqd: So what's the distinction between a "static mesh" and a "prefab"? As far as I can tell, a static mesh would typically be used in game as an object the player can interact with (player models, weapons, ammo, vehicles and the like), and a prefab would be part of the level the player doesn't interact with (walls and floors for example). However, they both appear to be sourced in exactly the same way - so maybe the distinction is one of logical categorisation - and a decision on import into UT.

Mychaeel: No. Static meshes are, like the name says, static (as in "can't be animated" – that'd defeat their main point of being one static set of vertex information in the video card's memory), so they can't be used for player models and the like. The closest equivalent to a static mesh is indeed a prefab in Unreal Tournament.

EntropicLqd: In one of the screenshots/videos featuring the editor I've seen, Meshes, Prefabs and static meshes all have separate tabs in the object viewer thingy (ooh techie terms).

Wormbo: The meshes are the same kind of meshes like the ones in UT. (used for weapons, etc.) Prefabs are also the same like in UT. (brushes built in the editor) Just the static meshes are new. (they are meshes, but are used like prefabs, that's how I understood it)

Mychaeel: They are used like decorations in Unreal Tournament. Technically, they're more like prefabs in that they're non-animated (and they can be created from actual prefabs even though it's discouraged), and like models in how they're usually created.

EntropicLqd: Right then .. lets see if I understand what's going on. Ultimately, a mesh, and a static mesh are the same thing. However, a static mesh cannot be animated (or form part of an animation chain) or deformed dynamically in any way whatsoever. So, the CTF flag would be a mesh, and a box of flak shells (assuming it doesn't move) would be a static mesh. However I've heard that static meshes are also used for ledges, walls, sky boxes, and whole pieces of geometry in the level - so the use of meshes has pretty much replaced the brush work required in UT. So where do prefabs fit in then? I've never knowingly used any prefabs in UT so I've got no real reference point. However, given the previous comments about static meshes, is the prefab system simply a mechanism for building up libraries of static meshes? In which case, there would be no difference between a static mesh and a prefab except the directory it's contained within. Possibly static meshes are part of the level data, but prefabs would be available to all levels (like putting textures in their own package or using MyLevel package). Am I close? I didn't get muc sleep last night (eldest was somewhat sick) and this is starting to make my head hurt.

Mychaeel: I suppose ammo packs are still regular meshes with a normal actor collision cylinder. – From a technical point of view, meshes and static meshes are quite different. The main purpose of static meshes is level for furnishing levels, and they're also used for movers now. The term "prefab" is occasionally used interchangably with "static mesh" for the new Unreal engine versions, but the "old" notion of a prefab (a saved builder brush) is still available too.

Category Mapping
Category To Do – merge into Static Mesh or delete