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. glBSP is also polyobject-aware, to a lesser extent, and it is still recommended to build Hexen-format maps with zdBSP, and let glBSP handle the GL nodes internally.
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.
The Hexen line specials which allow the creation and manipulation of polyobjects are known by the following ACS names:
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 (as of version 2.0.2) ignores Hexen polyobjects since those THINGID's conflict with DDF internals. Instead, 3DGE adopts the ZDoom IDs (9300, 9301, and 9302). In the future, 3DGE will be able to detect Hexen polyobjects and convert them to ZDoom as necessary.
In order to use them, you need to use Hexen format maps as they are only spawned in the presence of a BEHAVIOR lump.
See Polyobject Tutorial to get started on how to build them.