Create the rotation controller

1. Create a point entity and place it at the exact centre of rotation for the object.
2. Give it these properties:

classname   func_rotate_entity
origin      <centre of rotation>
rotate      <rotation angles>   // eg 0 0 90 = windmill, 0 90 0 = record, also you can change the rotation direction by putting a minus on the value, eg '0 -90 0'
spawnflags  2
speed       1
target      windmill

 Create the target helper

3. Create a second point entity and place it at the centre of where the object will be.
4. Give it these properties:

origin      <centre of object>
targetname  the_rotator

Create the rotating brush

5. Build the brush that will be the rotating object.
6. In TrenchBroom, position the brush so its rotation pivot is at:

0 0 0

7. Convert the brush to a brush entity (right-click → Create brush entity → pick any func), then assign these properties:

classname   func_rotate_object
origin      <same origin as func_rotate_entity>
spawnflags  2
target      the_rotator
targetname  windmill

Note: Setting the origin on func_rotate_object does not move the brush in TrenchBroom—the brush stays at 0 0 0 in the editor, even though the in-game origin will be where you set it.

AI explanation:
‘

Why TrenchBroom does NOT move a brush when you set an origin key

1. In Quake, origin is NOT a position — it’s a pivot offset

This is the key misunderstanding most mappers have at first.

In Quake:

• A brush entity’s actual position is defined by the brush’s vertices.
• The origin key is not “where the brush is”.
• The origin key is a pivot point used by the engine for:
  • rotation
  • movement
  • physics
  • interpolation

So the engine uses origin like this:

“Rotate/move this brush as if its centre were at this coordinate.”

But the brush’s geometry stays wherever the mapper built it.

2. TrenchBroom only edits geometry — it does NOT simulate engine transforms

TB’s job is:

• store brush vertices
• store entity keyvalues
• show you the geometry where you placed it

TB does not:

• apply Quake engine transforms
• move brushes based on origin
• simulate entity behaviour
• recalc geometry based on keyvalues

TB treats origin as just a string key, nothing more.

It does not interpret it.

3. The Quake engine applies the origin transform at runtime

When the map loads:

1. The engine reads the brush’s geometry (still at 0 0 0).
2. It reads the origin key.
3. It applies a transform:
   • “pretend the brush is located at this offset”
4. It rotates/moves the brush around that point.

TB never sees this transform. It only exists in the engine.

4. If TB did move the brush when you set origin, it would break everything

Imagine this:

• You build a rotating brush at 0 0 0 (correct).
• You set origin 512 256 128.
• TB moves the brush to 512 256 128.
• Then the engine ALSO moves it to 512 256 128 at runtime.

Result: The brush ends up double‑moved, in the wrong place, with the wrong pivot.

This is why editors must not apply the transform.

5. Historically, Quake editors never applied origin transforms

Worldcraft, Radiant, QuArK, TB — none of them ever moved brushes when you set origin.

Why?

Because the Quake engine’s transform system is:

• runtime‑only
• entity‑only
• not part of the map format
• not part of the editor’s geometry model

TB is simply following the same rule every editor has followed since 1996.

🧩 So why do rotating brushes need to be built at 0 0 0?

Because:

• The engine rotates brushes around their own origin.
• The only way to guarantee the brush’s local origin is correct is to build it at 0 0 0.
• The origin key then tells the engine where the pivot should be in world space.
• TB does not apply this transform, so the brush stays at 0 0 0 in the editor.

This gives the engine a clean, predictable pivot.

🧨 Bottom line

TrenchBroom doesn’t apply the origin transform because that transform only exists inside the Quake engine. TB is a geometry editor, not a runtime simulator.

If TB moved brushes based on origin, rotating entities would break.’