Gateways
Gateways provide a method for seamless transition from one area to another. They have several important properties including destinationID, canSeeThrough, and canCollideThrough. The destinationID specifies the ID of the destination area. The flags refer to whether it is possible to see objects beyond the gateway and whether collisions with those objects happen respectively.
Gateways can have a tranlation and rotation component. These allow space to be warped through the gateway. Since one of the main purposes for gateways is to allow building worlds bigger than possible in a contiguous space due to floating point precision, this translation is intended to be used to warp the coordinate system on the destination area closer to the origin.
Gateways with canSeeThrough
This flag is checked by the PlayerView? when it searches areas. If an area contains a gateway with the canSeeThrough flag on, then the destination area of that gateway is also searched. Items within range are marked as in view taking into consideration the distance to the gateway and the distance from the gateway on the other side to the object.
On the client, areas on the other side of gateways with translations are stored with their position and rotation offset. The client creates a root node in the renderer which has this position and offset. All objects in the destination area are placed within that node at their normal positions. This causes the effect of the gateway warping space. However, it is important to note that Gateways do not (currently) work like portals in the Portal games. They aren't a window into the destination area, but are instead a merging of the two areas. So, if there is any overlap of objects between the two areas, they will be shown overlapping.
Gateways with canCollideThrough
Collision through gateways is tricky. It's especially tricky in the case of translating gateways. Unlike with the renderer, physics engines generally don't have a way to translate a whole space worth of colliders. In order to still support translating gateways, the gateway has two sets of collision geometry. One set is for colliding with the gateway. When an object hits this, it is transported through the gateway to the destination area. The other set is the near collider. This should surround the main collision geometry with enough space so that bodies outside the volume wouldn't be able to collide with bodies on the other side of the gateway.
The gateway keeps track of bodies which have collided with the near collider. These bodies get added to the gateway's near space using their enterSecondarySpace function. Each update, it collides the near space with the destination area. In the case of a translating gateway, it translates the bodies thorough the gateway, collides them, and then translates them back. This way, the bodies will collide with bodies on the other side of the gateway normally. A special iteration function is called on the bodies called iterateOtherArea. In this function, the body can handle anything special it needs to do related to the area through the gateway.
Attachments
-
gateway.dia
(1.5 KB) - added by mike
11 months ago.
Gateway diagram (source)
-
gateway.png
(12.0 KB) - added by mike
11 months ago.
Gateway diagram
-
gatewaycollision.dia
(1.8 KB) - added by mike
11 months ago.
Gateway collision diagram (source)
-
gatewaycollision.png
(19.6 KB) - added by mike
11 months ago.
Gateway collision diagram
-
gatewayseethrough.dia
(1.8 KB) - added by mike
11 months ago.
Seeing through a gateway diagram (source)
-
gatewayseethrough.png
(35.7 KB) - added by mike
11 months ago.
Seeing through a gateway


