Polyobject

From 3DGE Wiki
Revision as of 14:04, 28 July 2015 by Corbin (talk | contribs) (Created page with "A '''polyobject''' is a movable convex group of one-sided linedefs. This extension of the Doom engine was originally implemented in [http://doomwiki.org/wiki/Hexen Hex...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

A polyobject is a movable convex group of one-sided linedefs. This extension of the Doom engine was originally implemented in Hexen.

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:[1]

  • 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. glBSP is also polyobject-aware, to a lesser extent.

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.

File:Poly05.png
Common setup of sliding door polyobjects.
File:Poly06.png
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.

3DGE Implementation

References

  1. Binary Space Partitioning Trees FAQ