Polyobject - Revision history

Corbin at 22:31, 28 July 2015

2015-07-28T22:31:47Z

Corbin at 21:11, 28 July 2015

2015-07-28T21:11:25Z

Corbin: 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..."

2015-07-28T21:04:35Z

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..."

New page

A '''polyobject''' is a movable convex group of one-sided [[linedef]]s. This extension of the [[Doom engine]] was originally implemented in [http://doomwiki.org/wiki/Hexen Hexen].

== Theory ==

Although [[Wikipedia:Binary space partition|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:<ref>[http://www.faqs.org/faqs/graphics/bsptree-faq/ Binary Space Partitioning Trees FAQ]</ref>
* 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 [[thing]]s, as well as push things that block them and optionally inflict crushing damage while doing this.

[[Image:Poly05.png|thumb|right|210px|Common setup of sliding door polyobjects.]]
[[Image:Poly06.png|thumb|right|220px|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 [[seg]]s 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 ==
<references />
[[Category:Doom engine]]
[[Category:New features]]

@@ Line 38: / Line 38: @@
 == 3DGE Implementation ==
-DGE (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.
+DGE (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. Also, 3DGE does not yet support ACS.
-In order to use them, you need to use Hexen format maps as they are only spawned in the presence of a BEHAVIOR lump.
+In order to use them, you need to use Hexen format maps with the correct Polyobject linetypes, but ensure that the THING types are ZDoom-based, otherwise the engine will not render them.
 See [[Polyobject Tutorial]] to get started on how to build them.

@@ Line 1: / Line 1: @@
-A '''polyobject''' is a movable convex group of one-sided [[linedef]]s. This extension of the [[Doom engine]] was originally implemented in [http://doomwiki.org/wiki/Hexen Hexen].
+{{DoomWiki}}A '''polyobject''' is a movable convex group of one-sided [[linedef]]s. This extension of the [[Doom engine]] was originally implemented in [http://doomwiki.org/wiki/Hexen Hexen].
 == Theory ==
@@ Line 10: / Line 10: @@
 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.
+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 [http://zdoom.org/wiki/ZDBSP 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.
 == Original implementation ==
@@ Line 38: / Line 38: @@
 == 3DGE Implementation ==
 == References ==
 <references />
 [[Category:Doom engine]]
 [[Category:New features]]