| Home Page | Recent Changes | Preferences

# General Scale And Dimensions

## Units & Scale

The Unreal engine uses two units:

### length

Unreal Units, or UU. Often simply called "units", or even not given a name at all ("build a 256x256x64 box"). The UnrealEd grid, dimensions of brushes, positions of actors and sizes of collision cylinders are all measured in these units. The Unreal World can have a maximum size of 65536 UU (=2^16) in Unreal/UT. UT2003 and U2 have worlds of 524288 UU (=2^19).

### angle

Unreal Rotation Units are used to measure angles, to set the direction and rotation of actors for example. 65536 (=2^16) is a full circle. These units are used by rotators, a special UnrealScript variable type. An actor's orientation is given by a rotator in the property Movement → Rotation.

Not all angles in unreal use these units though:

- maths functions such as sin() use radians.
- When importing a mesh into the engine with an exec directive, you can specify a rotation for the mesh during import ('# EXEC MESH ORIGIN MESH=Blablabla YAW=..PITCH=..YAW=...) . In this case the rotation unit is a byte: a full circle is 255.

See Useful Maths Functions for angle conversion factors.

### Linear scale

What's the size of one Unreal measurement unit? (UU)

- 256 UU = 487.68 cm = 16 feet.
- 1 meter = 52.5 UU
- 1 foot = 16 UU
- 1 UU = 0.75 inches

Legal: And WTF is this in world standard (metric) measurements?

Wormbo: According to the values above a meter corresponds to 52.5 UU, but this seems quite a lot for UT. It might be correct for UT2k3 though.

(v)adOnion: Epic could really move on to the mks system. Time has shown it's more sophisticated and efficient.

Foxpaw: I don't know what the MKS system is, can you explain?

(v)adOnion: mks = meter, kilogram, second - it's what most people refer to as the metric system. Unlike the confusing english measures everything is (prefixwise) consistent on powers of 10 and can thus be easily transformed.

Foxpaw: Oh, I see what you mean now. That would be bad, and here's why:

(v)adOnion: Yes and no. The point would be you could then easily scale everythign by powers of ten again.

Right now the world is entirely relative. There is no "x amount of units equals y distance" in the Unreal Engine, though the specific games usually pick a scale. If you took everything in the Unreal World and multiplied all distanced, speeds, etc. by 10, the whole world would look exactly the same. (Well, technically it likes to work on powers of 8, so you might get a few BSP holes.) This is better than the metric system for game programming because the scale may change. One game may be an FPS, while another may be a space sim with several planets on an entire map. Obviously, because of the constraint on the map size, you cannot have a whole planet on a map scaled to an appropriate size for an FPS. That is why everything works in abstract "units." If, however, you want to use a handy unit conversion, you can use a postoperator for this, like so:

    const Meter=52.5;

    // These can be somewhere fairly global...
    static final postoperator float Meters( float Units )
    { return Units * Meter; }

    static final postoperator float MPS( float Units )
    { return Units Meters; }

    function SetSomething()
    {
      SetCollisionSize( 5 Meters, 3 Meters );
      Velocity = Vector( Rotation ) * 5 MPS;
    }

Tarquin: I thought what they meant was that it would be nice if UU corresponded better to metric, say 1 UU = 2 cm instead of the current 16 UU = 1 foot

Daid303: Actualy, you can't see scale, everything is a big has you THINK it is. If anyone played Ultimated Droids, there the halls of the square race are 512uu width. That would be about 10 meters, but it looks much smaller.

This generally accepted information from world-renown authority Lode Vandevenne. Unreal dimensions are all relative to the view, and the perception of the scene is what actually determines design metrics. It has been suggested that the original Unreal designers were thinking approximately: 1 world unit equivalent to 1 inch. But they never had the intention of making UnrealEd grid units translate exactly and precisely into realworld dimensions. To illustrate, try converting the TournamentPlayer? (UT) dimensions listed here to the 16 units/foot and 12 units/foot scale and you will find that although the 12 units/foot scale is more reasonable, neither is quite right.

Using UnrealEd for other Unreal games, e.g. DeusEx or UT2003, is a little different, due to the characters being different sizes. Also, there is a slight distortion between the horizontal and vertical dimensions. If you were to try to create a replica of a real-world structure, the above conversion would make you a giant horizontally, though your vertical dimensions would seem only a little small. Therefore its best to use the following:

For all horizontal measurements:

1 meter = 70 units

For all vertical measurements:

1 meter = 60 units.

Foxpaw: I never really considered it before, but this is only partially true. In theory, Unreal Units are all relative, but in reality there are some things you have to scale to that you can't change. Specifically, light and sound have radii that have a set range, which you can't change. If you don't scale appropriately to the max limits of lightradius and soundradius, you will either lose resolution on those controls (if your world is too small) or be unable to make those things big enough. (if your world is too large)

Foxpaw: Apparently there's a couple of other issues with scaling that makes size a little more important than it seems. The engine will not render anything that's more than about 60000 UUs away from the camera, and if you make things too small the loss of precision when the engine converts various things from float point to integers becomes significant.

### Angular scale

Value | Degrees | Remarks
3640 | 20 | 0-19 degrees slope does not slow down players
6371 | 35 | 20-35 degrees slope slows down players but is climbable
8192 | 45
16384 | 90
24576 | 135
32768 | 180
40960 | 225
49152 | 270
57344 | 315
65536 | 360

### Conversion utilities

Two handy javascript unit converters:

- for linear units: http://home.wanadoo.nl/ariadohq/tutes/uu_convert.html
  - Standalone version/utility: http://home.wanadoo.nl/ariadohq/tutes/uuc.zip
  - Feature list (warning: pop-ups): http://www.angelfire.com/games3/thealien/util_ut.html
- for angular units: http://home.wanadoo.nl/ariadohq/tutes/ruu_convert.html

## Actor Dimensions

Dimensions of players and bots in UT:

- 78 units tall = Collision → CollisionHeight * 2
- 34 units wide = Collision → CollisionRadius * 2

Dimensions of players and bots in UT2003:

| standing | crouching
height | 88 UU | 58 UU
width | 50 UU | 50 UU

This is the size of the collision cylinder: it's this that determines an actor's size for bumping and fitting into spaces. Note that crouching does not change this in the original UT, although some mods have implemented it (Jailbreak).

Humans in UT are represented by the class TournamentPlayer?. To check other classes without having to add one to a map, right-click in the Actor Classes browser, open the default properties and look in the collision properties. Remember these give the radius and half the height: in this case, a CollisionHeight of 39 means the actor's cylinder is 78 units tall.

## Player Environment

### Ceilings

- Absolute minimum: 83 units
- Recommended: 128 units

From experience, it is known that a Player can walk into any room 83 Units or higher (the engine has the Player bobbing up and down), and cannot walk into a room with a height less than 83. It is suggested that rooms be designed a minimum of 128 units in height.

For best results, the ceiling should always be at least two feet above the player's head, and it looks best when significantly higher. In regular domestic architecture, ceilings under 10 feet high are uncommon.

### Hallways

- Absolute minimum: 48 units
- Recommended:

These must be a minimum of 48 units wide, and, this is generally considered too narrow for bot pathnoding. PathNodes should be placed at intersections and turns so that there is as much clearance as possible from corners (at least 50 world units if possible). And PathNodes should be clear to the width of the maximum width (twice the CollisionRadius) of creatures which will use this path. (See Bot Navigation)

Tahngarth: When creating a passage that must be crouched through, the minimum ceiling height is 66 units, the minimum hall width is 52 units, and the maximums are 1 less than the minimum values described above for normal hallways.

### Steps

- Maximum: 24 units
- Recommended: 16 units

TournamentPlayers can climb any step that is 24 units or less. Using 16 as default stepheight is a smart thing to do, because stuff will align to the grid better that way.

### Jumps

- Approx. maximum jump up a step: 64 - 72

It is generally reported that the ability of Players to jump to some maximum height in game varies somewhat. Typically, all Players can jump up to a height of about 64 units, and cannot reach 72 units without JumpBoots.

SuperApe: Could the variation be due to the bobbing up and down mentioned in 'Ceilings'?

#### Some things that might be handy to know

Does anyone know these?

- Equivalent minimum distances that Player can maneuver in Low Gravity and Water environments.\
- Normal running speed of a bot or a player (so we don't make a house with a room which takes 15 seconds to cross - i.e., out of proportion)
- Normal silent creeping speed of a player
- Maximum distance the translocator can be thrown.

SuperApe: It appears the maximum vertical distance a translocator can be thrown in normal gravity is 1536 units. Fancy math should be able to determine horizontal distance with normal gravity and a 45° angle.

SuperApe: The following are found in Movement Metrics (UT2003):

- Maximum horizontal distance cleared from an impact hammer jump.
- Maximum distance of dodges, sideways, backwards & forwards

### Slopes

- A slope less than 20 degrees behaves exactly like a floor (and is actually considered a floor). Players can move on these without obstruction.
- A slope between 20 and 35 degrees is a grade. The player can move up these but he/she slides and must continually struggle to climb to avoid sliding all the way down.
- A slope over 35 degrees is unclimbable.

## 3D Studio Max Grid

It's easy to set your grid in 3D Studio Max to match the grid in UnrealED. Under Customize → Grid and Snap Settings, goto the "Home Grid" tab. Under grid spacing, set it match UnrealEd's. The default is 10. Setting it to 16 will make it 16 units in UnrealEd. You can plug in whatever you please.

## Tips

Many experienced mappers place a model of a player in a prominent location when designing the level.

- Actor >> Decoration >> Introdude
- Actor >> Pawn >> Bot >> HumanBotPlus >> one of the child classes

Introdude is exactly the same height as the TournamentPlayer when set at a drawscale (in the Properties window) of 1.075.

I've had intermittent problems with an Introdude simply not showing in any view except Wireframe, so I use a bot. Anyone know why this might happen? —Tarquin

A good way of checking to see if bots will take an odd path is to try to set a pathnode in the region. Some brushes (128 units high) vertex edited up or down will be ok for a player to run through, but some bots will not take the path. Try setting a pathnode on the slope by right clicking and selecting "Set Pathnode Here (don't duplicate or move a pathnode there). If it appears, you're set. If not, you may want to change your brush.

## Comments

Niaht: I would like to suggest moving the "Scale" section to the top of the document. It seems to be good information to prep for reading the specs on the actors, player environment and other information. It was also one of my first questions when I started working in UnrealEd and I think would be canidate for entry into a kind of Mapping Quick Ref (is there one already?).

Tarquin: Done Some of the pathnoding stuff under Hallways and Tip should probably be moved to either Pathnoding or maybe a new page on design considerations for bots. (snappier title needed...)
On the subject of a Mapping Quick Ref: we have UnrealEd Tips and Unreal Mapping FAQ, but the problem is that any "quick ref" page rapidly bloats up, simply because there is sooooo much to cover. beginners expects them, but I'm starting to think that "quick ref" pages are the documentation equivalent of the beginner coder's "DoIt" procedure...

Kerlin: What about double jumps? Lift jumps? Jump distance increases with speed (adrenaline) but does jump height increase as well? If I had the first clue in gathering such metrics, I'd update it myself.

Wormbo: The Playtesting Values above are the results gathered using a HUD mutator for the original UT. I'm currently working on a hopefully network compatible version for UT2k3, but don't hold your breath.

Tarquin: This page is getting long. Here's my suggestion for splitting it:

- "Unreal Unit" – for the top bit
- either this name or "Metrics" for the rest.

Wormbo: I guess everything above == Player Environment == would be moved to Unreal Unit or UU then.

Tarquin: Yup. I'd forgotten about UU.

Tarquin: Phase 1 of cleanup: stuff has been moved out to:

- Movement metrics (UT)
- Movement metrics (UT2003)

EdgeCrusheR i dont know... i think there is something wrong with my AOT ed(its not so different from UTed) so anyway i make a CUBE 160*256*256 and from to TOP view it isnt a square!(looks more like 160*256*380 and the worst part is in AOT i can jump in this cube...

what is wrong with my ED?

Category Mapping

The Unreal Engine Documentation Site

Wiki Community

Topic Categories

Image Uploads

Random Page

Recent Changes

Offline Wiki

Unreal Engine

Console Commands

Terminology

Mapping Topics

Mapping Lessons

UnrealEd Interface

Questions&Answers

Scripting Topics

Scripting Lessons

Making Mods

Class Tree

Questions&Answers

Modeling Topics

Questions&Answers

Log In