Polyobject

A polyobject is a movable convex group of one-sided linedefs. This extension of the Doom engine was originally implemented in Hexen by programmer Ben Gokey of Raven Software.

Theory

Although binary space partitioning results in a static BSP tree which is not amenable to dynamic geometry, it is possible to exploit the complete convex mapping of space provided by the tree to insert dynamic objects, so long as they obey certain restrictions:

• The dynamic objects must not intersect with any static geometry.
• The dynamic objects must not intersect with one another.
• The dynamic objects must themselves be convex, and must either be contained entirely within a single subsector or be split into fragments which are themselves contained within single subsectors.

So long as the dynamic geometry in each subsector follows these rules, it can be drawn first, before the normal contents of the subsector, and the other assumptions implicit within the BSP rendering algorithm will be maintained.

Glitches in rendering that can be caused when polyobjects cross node lines (and thus overlap with static geometry or into adjacent subsectors) can be partially but not entirely abated by use of a so-called "polyobject-aware" node builder, which includes the popular ZDBSP.

Original implementation

As mentioned above, polyobjects were originally an innovation in the Hexen codebase. In Hexen, polyobjects are chiefly used to create sliding and rotating doors, pushable walls, and dangerous horizontal crushers. Since polyobjects are also linked into the blockmap like normal linedefs, it is possible for them to clip the movement of things, as well as push things that block them and optionally inflict crushing damage while doing this.

Common setup of sliding door polyobjects.

Screenshot of above setup in-game.

The Hexen line specials which allow the creation and manipulation of polyobjects are known by the following ACS names:

• Polyobj_DoorSlide
• Polyobj_RotateLeft
• Polyobj_OR_RotateLeft
• Polyobj_RotateRight
• Polyobj_OR_RotateRight
• Polyobj_DoorSwing
• Polyobj_Move
• Polyobj_OR_Move
• Polyobj_MoveTimes8
• Polyobj_OR_MoveTimes8
• Polyobj_StartLine
• Polyobj_ExplicitLine

The latter two line specials are used to identify the lines that belong to the polyobject. Due to limitations of the Hexen map format, there cannot be more than 256 polyobjects in a single map. In addition, Hexen imposes an artificial limit of 64 segs per polyobject. Hexen can only reliably support one polyobject per subsector, and cannot deal properly with polyobjects that overlap into adjacent subsectors or that are made to move too far from their spawnpoint.

Hexen polyobjects additionally require two mapthings to identify the position at which they were built on the map, and how that point relates to the position at which they should be placed at runtime. These thing types are the "anchor point," with DoomEd number 3000, which must be placed near the linedefs that are part of the object, and the "spawn points," with DoomEd numbers 3001 or 3002, which are used as the runtime spawning location of the polyobject. The polyobject is translated to this location by moving the anchor point to the spawn point, and moving all linedefs so that their relationship to the anchor point remains constant. Use of the 3002 spawnpoint type denotes that the polyobject should do crushing damage to objects which block its motion.

Via use of line arguments, it is also possible to cause polyobjects to mirror the motion of other objects. When a move or rotate special is applied to an object, it will cause any objects mirroring it to move or rotate in the opposite direction.

Source port implementations

The ZDoom source port also implements polyobjects, but prefers the use of thing types 9300, 9301, and 9302 to those used by Hexen so as to avoid editor number conflicts with Doom and Strife (for example, 3001 is also used by the Imp and the Reaver). It also adds a third type of polyobject (9303) which hurts on simple contact. The ZDoom implementation of polyobjects was entirely redesigned for version 2.5.0, using dynamic line segment splitting and then constructing "MiniBSP" trees associated to each subsector and dynamically recomputed by the internal node builder when traversed by a polyobject. This removes all restrictions: they can intersect with static geometry, and with each other, any arbitrary number can share the same subsector, and they can have any arbitrary shape.

The Eternity Engine completed implementation of a dynamic seg rendering system which splits polyobjects through the BSP to generate subsector-contained fragments. This not only completely eliminates the need for a polyobject-aware node builder, but also allows any number of polyobjects per subsector and arbitrary motion of polyobjects between subsectors with reasonably similar properties. Anyhow Eternity's method isn't working perfectly, because it's sorting the polyobject fragments by comparing their middle point, which can lead to visual glitches with complex shaped polyobjects. Eternity is currently capable of allowing use of polyobjects inside Doom-format maps via the use of ExtraData, and will also support them in the Hexen and UDMF map formats when support for those formats has been finalized. Like ZDoom and for the same reason, Eternity supports the editor numbers 9300, 9301, and 9302 for polyobject anchors and spawn points, and support for ZDoom's new type (9303) was added in r851.