From Polyobjs to Decorations

skyjake

<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Engine, Games, jHexen.</i>

I was thinking that we now also have an opportunity to rethink polyobjs a bit. There is no longer any obligation for them to be composed of 2D wall segments, for example. Internally, Doomsday could use model decorations to represent polyobjs. Hitchecking could be done using the current "2D polygon" approach, augmented with top and bottom planes, or alternatively something else (cylinders?).

Another solution might be to use mobjs to represent polyobjs, which would simplify hitchecking a bit and make the polyobjs easier to handle in netgames, as their data would be transmitted as mobjs.

DaniJ

Hmm this is a very interesting idea and definetly worth discussing further. We really should be treating these as objects as there is much to be gained from NOT handling them as groups of moveable wallsegs (though the same drawing routines should still be used for them of course).

Using mobjs to represent the location of polyobjects in the game world would indeed simplify things greatly. With the mobj basically acting as an anchor point.

So, on map load Doomsday could generate a loop of vertices for each polyobject (easy as they are already in the map), these need to be 2D because we should "extrude" them during the rendering stage as currently done. Potentially, if they are not being rendered as wall segments and their anchors are mobjs; they could move freely between subsectors and different sectors using the existing subsystems. Due to this new found freedom we would have to "extrude" the base polygon at each vertex independantly depending on the floor/ceiling height it is in (or not if we want 3D polyobjects with "caps"). Note that this will be a requirement for implementing slopes where the z position of vertices will depend on a slope equation.

If we think about this a bit further a polyobject is basically a non-sentient mobj but represented by a strip of polygons rather than a sprite or model. However, polyobjects must be collision/hit checked correctly, so we cannot simplify their shape as we require accuracy (obviously a polyobject bounding box could be used for trivial rejections though) due to the fact that they can be in practically ANY shape. So, to intergrate this fully mobjs should be allowed to have different types of collision primitive: cube, cylinder, 2D regular and irregular polygon with "caps". The correct hit/collision algorithm picked accordingly.

Another thing to consider and a plus point for using mobjs as their anchor; we could implement a path system to control their movement (a simple sliding door would be a two node path closed<->open). This would have immediate knock on benefit as other objects in the game world could then follow paths. Cut scenes anyone? I'm sure a mobj path movement system could be used for other cool things too (ay Yagisan? ;-)).

dengDevs Import

<i>This comment was posted by dengDevs user <b>Melfice</b>.</i>

DaniJ: Remember a long time ago when I suggested the thought of a glowing soul guiding you through a series of dark corridors in Map02. Would such a thing be possible with a path system like you spoke of?

Yagisan

Melfice, it is, but the bot system DaniJ alludes to is a something that I'm specing up for post 1.9.0, as it will need extensive design work before it's integrated.