Eternity Wiki - User contributions [en]

Cardboard engine

2010-01-15T18:38:28Z

SoM: Changed the reference to point to my user page.

'''Cardboard''' is the new floating-point renderer which debuted in version 3.37.00 of the [[Eternity Engine]]. Cardboard was created by programmer '''Stephen "[[SoM]]" McGranahan''' to address deep-seated problems inherent in the Doom engine's method of projecting and rendering lines and flats.

Advantages of the Cardboard renderer include greatly improved behavior of anisotropic two-sided lines, giving a clean-scaled appearance to textures even when the camera is looking down a line that it is practically on, and even when mlook is engaged to the minimum or maximum of its vertical range. Long wall error is reduced, allowing maps to contain much longer linedefs without numeric instability causing the walls to appear to "wobble". Behavior of the engine with respect to extreme height differences is also improved, retaining earlier repairs of crashes and eliminating most remaining rendering glitches associated with tall areas. Rendering of flats is now pixel-perfect in most circumstances.

Cardboard also includes optimizations. Flat drawing has been sped up significantly, and two-sided lines have also been improved via tweaks to the main seg-drawing loop and the ability to treat closed lines as one-sided for rendering purposes.

Unlike previous attempts by the Boom team and other source ports, Cardboard manages to allow the game engine to retain full compatibility by creating an optimum interface between fixed-point level geometry and the floating-point renderer. For example, floating-point vertex coordinates and sector heights are cached on a per-frame basis, minimizing integer-to-float conversions. As a result, frame rates under Cardboard are in most cases superior to the original renderer.

Cardboard includes some qualities which will improve the ability to later add true color support. It was originally developed outside of the Eternity Engine as a stand-alone program which could draw Doom textures and flats in 32-bit color with dynamically calculated light fading.

Portal linedef types

2010-01-14T22:53:33Z

SoM:

Portals turn a set of floors, ceilings, or linedefs into "windows" onto another part of the map, allowing for some otherwise impossible visual effects. Portals are not interactive, however -- objects cannot travel through them, enemies cannot see through them or fire into them, etc.

For an in-depth explanation of the behavior of simple portal types refer to the [[Portals]] article.

=Plane Portals=

A plane portal linedef creates a portal which displays an infinite plane. The flat and light level used are determined from the ceiling of the sector on the front side of the plane portal control linedef.

Plane portal linedefs are as follows:
283 Ext -- Applies plane portal to ceilings of all like-tagged sectors.

284 Ext -- Applies plane portal to floors of all like-tagged sectors.

285 Ext -- Applies plane portal to floors and ceilings of all like-tagged sectors.

=Horizon Portals=

A horizon portal linedef creates a portal which displays two infinite planes which converge on a fixed horizon at the center of the screen. The flat and light level of the two planes come from the floor and ceiling of the sector on the front side of the horizon portal control linedef.

Horizon portal linedefs are as follows:
286 Ext -- Applies horizon portal to ceilings of all like-tagged sectors.

287 Ext -- Applies horizon portal to floors of all like-tagged sectors.

288 Ext -- Applies horizon portal to floors and ceilings of all like-tagged sectors.

=Skyboxes=

A skybox is a portal which renders part of the map from the point of view of a control object. To setup a skybox, an EESkyboxCam object (doomednum 5006) must be placed in a sector. Then, one of the following skybox portal lines must be placed in that same sector such that it is the sector on the front side of the line. When viewed in the map, the surroundings of the control object will be seen at their real, fixed distance from that point, although the player's viewing angle will still be applied (so the scenery will turn, but not move).

Skybox linedefs are as follows:
290 Ext -- Applies skybox portal to ceilings of all like-tagged sectors.

291 Ext -- Applies skybox portal to floors of all like-tagged sectors.

292 Ext -- Applies skybox portal to floors and ceilings of all like-tagged sectors.

=Anchored Portals=

Anchored portals are the most complicated portal type. They define a portal similar to a skybox, but which moves relative to the player's point of view. This allows an anchored portal to appear as if it is a seamless part of the surrounding map.

To create an anchored portal, first one of the below anchored portal control linedefs should be placed into the sector which will appear inside the portal. Then, the sector in which the portal will appear should be tagged the same as the control linedef. This is the same as for all other types. However, an anchor line is also required so that the renderer can guage the offset between the real map area and the portal sector. This line, with specials 298 or 299, must be placed in the real sector, and must share the same tag as the sector and control linedef.

Here is an illustration of an anchored portal setup:
+---+ +---+
| A |-298 linedef | B |-295 linedef
+---+ +---+
Sector A is the normal sector in which the player will walk. Sector B is the portal sector which will be drawn into the portal. The 298 linedef, the 295 linedef, and sector A all share a common tag. Eternity will guage the distance between the portal linedef and the anchor linedef and will know how far to offset the camera in order to render the portal. In this case, Eternity will render sector B over the ceiling of sector A, and the two will appear to be placed directly on top of each other.

As of Eternity Engine v3.31 public beta 7, the 296 anchored portal type uses line special 299 for its anchor line. This was revised to allow separate anchored portals to be used for the floor and ceiling of the same sector, which would not previously work. 295 and 297 still use the 298 anchor type.

Note that the areas drawn within the anchored portal will render at the player's current viewheight, so if the view within sector B in this example were above the ceiling or beneath the floor of sector B, a HOM effect would appear in the portal instead of the expected view. Be sure that areas inside an anchored portal are large enough both in terms of area and height so that the offset camera position always remains within valid space regardless of where the player is viewing the portal from.

Anchored portal linedefs are as follows:
295 Ext -- Applies anchored portal to ceilings of all like-tagged sectors.

296 Ext -- Applies anchored portal to floors of all like-tagged sectors.

297 Ext -- Applies anchored portal to floors and ceilings of all like-tagged sectors.

298 Ext -- Anchor line, required for use alongside specials 295 and 297.

299 Ext -- Anchor line, required for use alongside special 296.
Warning: As of Eternity Engine v3.33.33, normal anchored portals should no longer be used for two-way setups, where both areas of an anchored portal are visible from each other. Use the new two-way types discussed below instead for this situation. If the lines above are used instead, the player may see seemingly spontaneous error messages and feel annoying pauses during gameplay.

==Two-Way Anchored Portals==

For two-way anchored portal setups, where each area involved in the portal can be seen from the other area, you are now required to use the following set of linedefs instead of those outlined in the section above. This change is necessary to support visibility of normal portals even when the player's viewpoint would be beneath the floor or ceiling. Unfortunately, such a change causes the normal anchored portals to begin drawing each other repeatedly when used in a two-way setup. Although this will no longer crash Eternity, it is considered an error and will be displayed to the player as such. To avoid this, use only these types in such a situation.
344 Ext -- Applies two-way anchored portal to ceilings of all like-tagged sectors.

345 Ext -- Applies two-way anchored portal to floors of all like-tagged sectors.

346 Ext -- Anchor line, required for use alongside special 344 only.

347 Ext -- Anchor line, required for use alongside special 345 only.

289: Portal Transfer

The portal transfer linedef allows the effects of any type of portal to be transferred to the front side of a one-sided line (it will *not* work on 2S lines). To accomplish this, simply give the 289 line the same tag used by the portal control linedef which is being targetted. Any number of 289 lines may share a portal, and the portal may still be used normally. If the normal effect of the portal (applied to a floor or ceiling) is not needed, it does not have to be tagged to a sector.

An example:
+------+---+ +------+
| \ B|<- B tag = 1 | |
| \ | | C |
| A + | |
| | | * |<- Skybox line special 290 , tag = 1
+----------+ +------+
^ ^
Line special 289, tag = 1 Control thing 5006
In this example, sector C will be visible in sector B's ceiling as a skybox. However, it will also appear on the line in sector A with special 289, giving it a window-like effect.
289 Ext -- Transfers a like-tagged portal to the first side of this linedef.
=Linked portals=
''See [[Linked portals]].''

----

''Back to [[Linedef types]]''

Linked portal

2010-01-14T22:43:44Z

SoM:

(If you have not read [[Portals]], please do so now before reading this article.)

'''Linked portals''' are a powerful feature which make it possible to connect two separate areas of a map via the floor/ceiling or one-sided linedefs, allowing the player to see, shoot, and even move seamlessly from one area into another. They are used similarly to two-way portals, apart from the fact that you can pass through them. They can be used to create 3D architecture and room-over-room effects, with very few limitations.

==Line triggers==
# Class Trig Description

358 Ext -- Apply linked portal to like-tagged ceilings

359 Ext -- Apply linked portal to like-tagged floors

360 Ext -- Linked portal anchor line for special 358

361 Ext -- Linked portal anchor line for special 359

376 Ext -- Apply linked portals to like-tagged lines

377 Ext -- Anchor line for special 376

==Terminology==
Linked portals have their own specific sub-set of terminology used to describe certain aspects and behaviors.

===Portal Plane===
Unlike the basic portal types, which were rendered and could cover height variances (much like the doom sky), linked portals form an actual map structure. The '''Portal Plane''' refers to an X/Y plane that bisects the sector(s) that contain the portal. The z-position of the portal is fixed, and should be the same height on both sides of the linked portal.

===Beyond the Plane===
Map architecture is said to be beyond the portal plane when its vertical height is equal to or beyond the portal height--that is, at or above a ceiling portal plane or at or below a floor portal plane. When map architecture is beyond a portal plane, the portal will display at the height of the plane.

===Inside the plane===
Map architecture is said to be inside the portal plane when its vertical height is not beyond the portal plane--that is, below a ceiling portal or above a floor portal. Any architecture that is inside the portal plane will render normally and will obscure rendering of the portal.

==Usage==
Linked portals use trigger and anchor lines (much like anchored portals) to determine an X and Y offset from one part of the map to another, but there are specific requirements unique to linked portals:

*Linked portals must be two-way, meaning the upper area must reference the lower area and visa versa.
*Linked portals have specific behavior relating to z-coordinates of the portal plane.

===Setup (Doom line specials)===

==Tutorial==
Refer to Zarkyb's [[linked portals tutorial]] for in-depth information on usage.

[[Category:Editing]]

Linked portal

2010-01-14T22:39:35Z

SoM: Started fleshing out the article.

(If you have not read [[Portals]], please do so now before reading this article.)

'''Linked portals''' are a powerful feature which make it possible to connect two separate areas of a map via the floor/ceiling or one-sided linedefs, allowing the player to see, shoot, and even move seamlessly from one area into another. They are used similarly to two-way portals, apart from the fact that you can pass through them. They can be used to create 3D architecture and room-over-room effects, with very few limitations.

==Line triggers==
# Class Trig Description

358 Ext -- Apply linked portal to like-tagged ceilings

359 Ext -- Apply linked portal to like-tagged floors

360 Ext -- Linked portal anchor line for special 358

361 Ext -- Linked portal anchor line for special 359

376 Ext -- Apply linked portals to like-tagged lines

377 Ext -- Anchor line for special 376

==Terminology==
===Portal Plane===
Unlike the basic portal types, which were rendered and could cover height variances (much like the doom sky), linked portals form an actual map structure. The '''Portal Plane''' refers to an X/Y plane that bisects the sector(s) that contain the portal. The height of the portal is at a fixed height.

===Beyond the Plane===
Map architecture is said to be beyond the portal plane when its vertical height is equal to or beyond the portal height--that is, at or above a ceiling portal plane or at or below a floor portal plane. When map architecture is beyond a portal plane, the portal will display at the height of the plane.

===Inside the plane===
Map architecture is said to be inside the portal plane when its vertical height is not beyond the portal plane--that is, below a ceiling portal or above a floor portal. Any architecture that is inside the portal plane will render normally and will obscure rendering of the portal.

==Usage==
Linked portals use trigger and anchor lines (much like anchored portals) to determine an X and Y offset from one part of the map to another, but there are specific requirements unique to linked portals:

*Linked portals must be two-way.
*Linked portals have specific behavior relating to z-coordinates of the portal plane.

===Setup (Doom line specials)===

==Tutorial==
Refer to Zarkyb's [[linked portals tutorial]] for in-depth information on usage.

[[Category:Editing]]

Linked portal

2010-01-14T21:52:20Z

SoM: /* Line triggers */

'''Linked portals''' (development versions only) are a powerful feature which make it possible to connect two separate areas of a map via the floor/ceiling or one-sided linedefs, allowing the player to see, shoot, and even move seamlessly from one area into another. They are used similarly to two-way portals, apart from the fact that you can pass through them. They can be used to create 3D architecture and room-over-room effects, with very few limitations.

==Line triggers==
# Class Trig Description

358 Ext -- Apply linked portal to like-tagged ceilings

359 Ext -- Apply linked portal to like-tagged floors

360 Ext -- Linked portal anchor line for special 358

361 Ext -- Linked portal anchor line for special 359

376 Ext -- Apply linked portals to like-tagged lines

377 Ext -- Anchor line for special 376

==Tutorial==
Refer to Zarkyb's [[linked portals tutorial]] for in-depth information on usage.

[[Category:Editing]]

Linked portal

2010-01-14T21:52:02Z

SoM: Maintain format with other articles.

Linked portal

2010-01-14T21:49:13Z

SoM: Disambiguation of line triggers

'''Linked portals''' (development versions only) are a powerful feature which make it possible to connect two separate areas of a map via the floor/ceiling or one-sided linedefs, allowing the player to see, shoot, and even move seamlessly from one area into another. They are used similarly to two-way portals, apart from the fact that you can pass through them. They can be used to create 3D architecture and room-over-room effects, with very few limitations.

==Line triggers==
*358 - Apply linked portal to like-tagged ceilings
*359 - Apply linked portal to like-tagged floors
*360 - Linked portal anchor line for special 358
*361 - Linked portal anchor line for special 359
*376 - Apply linked portals to like-tagged lines
*377 - Anchor line for special 376

==Tutorial==
Refer to Zarkyb's [[linked portals tutorial]] for in-depth information on usage.

[[Category:Editing]]

Main Page

2009-07-25T21:09:52Z

SoM: added a link to drdteam's daily SVN builds

__NOTOC__
==Welcome to the Eternity Engine Wiki==

The [[Eternity Engine]] [[Wikipedia:Wiki|Wiki]] is a community-maintained documentation resource for the Eternity Engine [[Doom Wiki:Source port|source port]] and everything related to it. It is powered by [[Wikipedia:MediaWiki|MediaWiki]]. Feel free to edit and create articles to help make this a valuable source of knowledge. If you're not familiar with wiki markup, [[Wikipedia:Wikipedia:How to edit a page#Wiki markup|look here]].

==Articles and areas of interest==
*[[Eternity Engine]]
*[[SMMU]]
*[[List of command line parameters]]
*[[List of codepointers]]
*[[Small]]
*[[MapInfo]]
*[[3DMidTex tutorial]]
*[[3DMidTex advanced topics]]
*[[Portals]]
*[[Linked portals]]

==Latest version==
The latest version of the Eternity Engine is currently {{Latest}}.

[http://svn.drdteam.org/eternity/ Daily unofficial SVN builds.]

[[Category:Eternity Wiki]]

Portal

2008-04-04T22:54:08Z

SoM: External links to the doom wiki relating to HOM

Portals are a powerful mapping feature which allow a variety of rendering effects; they allow an architectural surface to be used as a "window" which can display something besides the texture that would normally cover the surface. Anything from simple fixed plane, to another area of the map can be rendered within these surfaces via the same architecture.

== Terminology ==

=== Portal Window ===

'Portal window' refers to the area of the screen that a portal occupies. For example:

[[Image:Pterminology01.png]]

This is a simple map with no portal surfaces, and no portal window.

[[Image:Pterminology02.png]]

This is the same simple map with a fixed plane portal applied to the ceiling of the sector. The portal window is outlined in white.

[[Image:Pterminology03.png]]

This is the map, but the same plane portal is applied to the ceiling and the far wall. The two surfaces display the same portal, and as such, they share a common portal window (also outlined in white).

All surfaces in a scene that have a common portal will share the same portal window.

=== Dummy Sector ===
A sector off of the main map area which is used by line or sector specials as a model, or as housing for lines which need to be a specific size.

== Fixed Plane Portals ==

Fixed plane portals (as the name implies) render a single, fixed plane into the portal window. The plane is always rendered a the same height and texture offset even when the camera changes it's position.

Line specials:

:283 Apply fixed plane portal to the ceilings of tagged sectors
:284 Apply fixed plane portal to the floors of tagged sectors
:285 Apply fixed plane portal to the floors and ceilings of tagged sectors

The front side sector of the special line is used to generate the plane. The ceiling texture, sector light, and ceiling texture scrolling are all used as attributes for the rendered fixed plane. The absolute height of the ceiling is used as the height of the plane. That is, if the special line front sector has a ceiling height of 64, the plane will always render at 64 units above the camera height. If the ceiling height is 128, the plane will always render at 128 units above the camera height, and so on.

For example:

[[Image:Pfixedplane01.png]] [[Image:Pfixedplane02.png]]

The left image shows a simple map with a small sector off to the side of the rest of the map. One of the lines in this sector has been given a 283 special which will apply a fixed play portal to all tagged sector ceilings. The height of the dummy sector is set to 128, the blue water texture FWATER1 is the ceiling texture, there is no scrolling applied to the ceiling, and the ceiling height is 128.

The right image shows what the map looks like in [[Eternity]]. Notice the rendered height of the plane is the same as a ceiling 128 units above eye level.

The line special 289 can be used to apply fixed plane portals to walls as well. The special will find a portal with the same line tag and will display that portal on the surface of the line.

Here is the map from above:

[[Image:Pfixedplane03.png]] [[Image:Pfixedplane04.png]]

The highlighted wall has been given a special of 289 and tagged to the portal line. In-game, the tagged wall now displays the portal. Note: The 289 line special works for all portal types.

== Horizon Plane Portals ==

Horizon portals display two planes which appear to go on forever until they meet in the middle (horizon). The plane coordinates are not fixed, and will appear to move with the camera. This can be used to achieve the illusion that water or grass goes off far into the distance without having to make overly large sectors.

Line Specials:

:: 286 Apply horizon portal to the ceilings of tagged sectors
:: 287 Apply horizon portal to the floors of tagged sectors
:: 288 Apply horizon portal to the floors and ceilings of tagged sectors

Like the fixed plane portals, the front sector of the special line is used. The top plane uses the front sector ceiling (height, texture, scrolling, light) as its model, and the bottom plane uses the front sector floor (height, texture, scrolling, light) as its model. Example:

[[Image:Phorizon01.png]]

This map has a horizon portal applied to the ceiling and wall of the sector where the player starts. Both sectors have a floor height of 0, and a ceiling height of 72, but the floor texture in the dummy sector is set to a grass texture, and the ceiling texture is set to FSKY_1. This produces a field of grass which goes on into the horizon. If the camera moves up or down, the floor plane will appear to move along with it. If the ceiling plane had a regular texture on it, it would also move with the camera and appear to go off into the distance.

Note: If the camera ever travels below the floor height of a horizon portal, the bottom plane will appear to move in the opposite direction of the camera movement until the camera is once again above the floor height.

== Skybox Portals ==

Skybox portals draw another part of the map into the portal window. The scene in the portal window will use the angle from the player camera, but will render the scene from the location of the skybox camera. This helps create the illusion that the contents of the skybox actually surround the map and are much larger in size than they really are.

Line Specials:

:: 290 Apply skybox portals to the ceilings of tagged sectors
:: 291 Apply skybox portals to the floors of tagged sectors
:: 292 Apply skybox portals to the floors and ceilings of tagged sectors

The front sector of the special line becomes the "skybox sector". This is not the only sector that gets rendered, but this sector is where [[Eternity]] will look for the skybox camera object which will be the point the skybox is rendered from.

For example:

[[Image:Pskybox01.png]]

This map has a skybox portal applied to the ceiling and wall of the sector with the player start. The "Skybox sector" is the small rectangular one which contains the EESkyboxCamera object. The camera object always spawns on the floor, so the skybox sector has been made a glass floor 48 units above the surrounding area so the camera will be above the floor of the box.

[[Image:Pskybox02.png]] [[Image:Pskybox03.png]]

The first image is the view in-game when the player no-clips into the sky box. The second image is the view from inside the main map area with the skybox portal applied. No matter where the player moves inside the map area, the skybox portal will always render from the location of the camera inside the skybox, however, the skybox is rendered from the angle the player is looking. [[ExtraData]] also provides a means of assigning a z-height to objects in maps. This could also be used to raise the skybox camera off the floor. If the skybox camera is left on the floor, the floor plane will not render and result in [http://doom.wikia.com/wiki/HOM HOM].

The skybox is not restricted to simple boxes. Any map architecture the skybox camera can see can be part of a skybox. Below is an example of a basic mountainous landscape created with map architecture.

[[Image:Pskybox04.png]]

== Anchored Portals ==

Anchored portals are the most powerful and complex of all the basic portal types. Anchored portals will render another area of the map into the portal window, but the portal camera moves as the player moves, creating the illusion that the other area of the map is actually connected to the main area. This can be used to create the appearance of 3D architecture. Before use, however, an understanding of how these portals work is important.

In order to piece the parts of a map together, an anchored portal needs to know how far apart they are. The distance is determined with the use of specific line specials. Each anchored portal needs a "portal line" (the line with the anchored portal special) which usually area the portal should render, and an "anchor line" which is usually located in the main map area. The distance between these lines becomes the offset, that is, how far [[Eternity]] needs to move the camera from where the player stands to get the portal area.

Line Specials:

:: 295 Apply anchored portal to the ceilings of all tagged sectors
:: 296 Apply anchored portal to the floors of all tagged sectors
:: 297 Apply anchored portal to the floors and ceilings of all tagged sectors
:: 298 Anchor line (for specials 295 and 297)
:: 299 Anchor line (for special 296)

There are two different anchor line types so a different anchored portal can be placed on the ceiling and floor of the same sector. The two portals will share the sector tag.

For example:

[[Image:Panchored01.png]]

The above map has a single anchored portal applied to the inner sector of the area the player start is in. The "portal area" is to the right, and the "main area" is to the left. The view height is not changed, so the portal area needs to be set above the main area, or there will be [http://doom.wikia.com/wiki/HOM HOM] in the portal window. Note that no camera objects are needed for this effect. The portal will create a temporary camera automatically.

Here's how it works:

When the map is loaded, the the centers of both lines (the portal and the anchor line) are calculated, and the distance between those centers is determined:

[[Image:Panchored03.png]]

In the example, the distance is 512 units to the east and 0 units north. This set of numbers becomes the "portal offset" (distance between where the player stands and where the portal camera should go) and when the portal is rendered, the portal camera is place 512 map units east of the player camera, and the map is rendered from the portal camera.

If the portal camera becomes obstructed, unwanted results can occur:

[[Image:Panchored04.png]]

In the example above, the camera actually "wanders" out of the portal area and into the main part of the map resulting in an unwanted wall rendering in the portal window. To prevent occurrences such as this, it is usually a good idea to place the portal area a good distance away from any other map architecture to prevent the camera from "wandering into" anything else. If the camera moves out of the portal area, it won't cause problems as long as it is not obstructed by other map architecture.

(This article is currently a work in progress)

Portal

2008-04-04T22:46:04Z

SoM: Added the anchored portals section.

Portals are a powerful mapping feature which allow a variety of rendering effects; they allow an architectural surface to be used as a "window" which can display something besides the texture that would normally cover the surface. Anything from simple fixed plane, to another area of the map can be rendered within these surfaces via the same architecture.

== Terminology ==

=== Portal Window ===

'Portal window' refers to the area of the screen that a portal occupies. For example:

[[Image:Pterminology01.png]]

This is a simple map with no portal surfaces, and no portal window.

[[Image:Pterminology02.png]]

This is the same simple map with a fixed plane portal applied to the ceiling of the sector. The portal window is outlined in white.

[[Image:Pterminology03.png]]

This is the map, but the same plane portal is applied to the ceiling and the far wall. The two surfaces display the same portal, and as such, they share a common portal window (also outlined in white).

All surfaces in a scene that have a common portal will share the same portal window.

=== Dummy Sector ===
A sector off of the main map area which is used by line or sector specials as a model, or as housing for lines which need to be a specific size.

== Fixed Plane Portals ==

Fixed plane portals (as the name implies) render a single, fixed plane into the portal window. The plane is always rendered a the same height and texture offset even when the camera changes it's position.

Line specials:

:283 Apply fixed plane portal to the ceilings of tagged sectors
:284 Apply fixed plane portal to the floors of tagged sectors
:285 Apply fixed plane portal to the floors and ceilings of tagged sectors

The front side sector of the special line is used to generate the plane. The ceiling texture, sector light, and ceiling texture scrolling are all used as attributes for the rendered fixed plane. The absolute height of the ceiling is used as the height of the plane. That is, if the special line front sector has a ceiling height of 64, the plane will always render at 64 units above the camera height. If the ceiling height is 128, the plane will always render at 128 units above the camera height, and so on.

For example:

[[Image:Pfixedplane01.png]] [[Image:Pfixedplane02.png]]

The left image shows a simple map with a small sector off to the side of the rest of the map. One of the lines in this sector has been given a 283 special which will apply a fixed play portal to all tagged sector ceilings. The height of the dummy sector is set to 128, the blue water texture FWATER1 is the ceiling texture, there is no scrolling applied to the ceiling, and the ceiling height is 128.

The right image shows what the map looks like in [[Eternity]]. Notice the rendered height of the plane is the same as a ceiling 128 units above eye level.

The line special 289 can be used to apply fixed plane portals to walls as well. The special will find a portal with the same line tag and will display that portal on the surface of the line.

Here is the map from above:

[[Image:Pfixedplane03.png]] [[Image:Pfixedplane04.png]]

The highlighted wall has been given a special of 289 and tagged to the portal line. In-game, the tagged wall now displays the portal. Note: The 289 line special works for all portal types.

== Horizon Plane Portals ==

Horizon portals display two planes which appear to go on forever until they meet in the middle (horizon). The plane coordinates are not fixed, and will appear to move with the camera. This can be used to achieve the illusion that water or grass goes off far into the distance without having to make overly large sectors.

Line Specials:

:: 286 Apply horizon portal to the ceilings of tagged sectors
:: 287 Apply horizon portal to the floors of tagged sectors
:: 288 Apply horizon portal to the floors and ceilings of tagged sectors

Like the fixed plane portals, the front sector of the special line is used. The top plane uses the front sector ceiling (height, texture, scrolling, light) as its model, and the bottom plane uses the front sector floor (height, texture, scrolling, light) as its model. Example:

[[Image:Phorizon01.png]]

This map has a horizon portal applied to the ceiling and wall of the sector where the player starts. Both sectors have a floor height of 0, and a ceiling height of 72, but the floor texture in the dummy sector is set to a grass texture, and the ceiling texture is set to FSKY_1. This produces a field of grass which goes on into the horizon. If the camera moves up or down, the floor plane will appear to move along with it. If the ceiling plane had a regular texture on it, it would also move with the camera and appear to go off into the distance.

Note: If the camera ever travels below the floor height of a horizon portal, the bottom plane will appear to move in the opposite direction of the camera movement until the camera is once again above the floor height.

== Skybox Portals ==

Skybox portals draw another part of the map into the portal window. The scene in the portal window will use the angle from the player camera, but will render the scene from the location of the skybox camera. This helps create the illusion that the contents of the skybox actually surround the map and are much larger in size than they really are.

Line Specials:

:: 290 Apply skybox portals to the ceilings of tagged sectors
:: 291 Apply skybox portals to the floors of tagged sectors
:: 292 Apply skybox portals to the floors and ceilings of tagged sectors

The front sector of the special line becomes the "skybox sector". This is not the only sector that gets rendered, but this sector is where [[Eternity]] will look for the skybox camera object which will be the point the skybox is rendered from.

For example:

[[Image:Pskybox01.png]]

This map has a skybox portal applied to the ceiling and wall of the sector with the player start. The "Skybox sector" is the small rectangular one which contains the EESkyboxCamera object. The camera object always spawns on the floor, so the skybox sector has been made a glass floor 48 units above the surrounding area so the camera will be above the floor of the box.

[[Image:Pskybox02.png]] [[Image:Pskybox03.png]]

The first image is the view in-game when the player no-clips into the sky box. The second image is the view from inside the main map area with the skybox portal applied. No matter where the player moves inside the map area, the skybox portal will always render from the location of the camera inside the skybox, however, the skybox is rendered from the angle the player is looking. [[ExtraData]] also provides a means of assigning a z-height to objects in maps. This could also be used to raise the skybox camera off the floor. If the skybox camera is left on the floor, the floor plane will not render and result in HOM.

The skybox is not restricted to simple boxes. Any map architecture the skybox camera can see can be part of a skybox. Below is an example of a basic mountainous landscape created with map architecture.

[[Image:Pskybox04.png]]

== Anchored Portals ==

Anchored portals are the most powerful and complex of all the basic portal types. Anchored portals will render another area of the map into the portal window, but the portal camera moves as the player moves, creating the illusion that the other area of the map is actually connected to the main area. This can be used to create the appearance of 3D architecture. Before use, however, an understanding of how these portals work is important.

In order to piece the parts of a map together, an anchored portal needs to know how far apart they are. The distance is determined with the use of specific line specials. Each anchored portal needs a "portal line" (the line with the anchored portal special) which usually area the portal should render, and an "anchor line" which is usually located in the main map area. The distance between these lines becomes the offset, that is, how far [[Eternity]] needs to move the camera from where the player stands to get the portal area.

Line Specials:

:: 295 Apply anchored portal to the ceilings of all tagged sectors
:: 296 Apply anchored portal to the floors of all tagged sectors
:: 297 Apply anchored portal to the floors and ceilings of all tagged sectors
:: 298 Anchor line (for specials 295 and 297)
:: 299 Anchor line (for special 296)

There are two different anchor line types so a different anchored portal can be placed on the ceiling and floor of the same sector. The two portals will share the sector tag.

For example:

[[Image:Panchored01.png]]

The above map has a single anchored portal applied to the inner sector of the area the player start is in. The "portal area" is to the right, and the "main area" is to the left. The view height is not changed, so the portal area needs to be set above the main area, or there will be hom in the portal window. Note that no camera objects are needed for this effect. The portal will create a temporary camera automatically.

Here's how it works:

When the map is loaded, the the centers of both lines (the portal and the anchor line) are calculated, and the distance between those centers is determined:

[[Image:Panchored03.png]]

In the example, the distance is 512 units to the east and 0 units north. This set of numbers becomes the "portal offset" (distance between where the player stands and where the portal camera should go) and when the portal is rendered, the portal camera is place 512 map units east of the player camera, and the map is rendered from the portal camera.

If the portal camera becomes obstructed, unwanted results can occur:

[[Image:Panchored04.png]]

In the example above, the camera actually "wanders" out of the portal area and into the main part of the map resulting in an unwanted wall rendering in the portal window. To prevent occurrences such as this, it is usually a good idea to place the portal area a good distance away from any other map architecture to prevent the camera from "wandering into" anything else. If the camera moves out of the portal area, it won't cause problems as long as it is not obstructed by other map architecture.

(This article is currently a work in progress)

File:Panchored04.png

2008-04-04T22:44:25Z

SoM: Example of a portal camera encountering an obstruction.

Example of a portal camera encountering an obstruction.

File:Panchored03.png

2008-04-04T22:09:22Z

SoM: Automap screen shots detailing how offsets are calculated for anchored portals.

Automap screen shots detailing how offsets are calculated for anchored portals.

File:Panchored02.png

2008-04-04T22:08:37Z

SoM: View of map from Panchored01.png before portal is rendered.

View of map from Panchored01.png before portal is rendered.

File:Panchored01.png

2008-04-04T21:32:57Z

SoM: Simple map with an anchored portal.

Simple map with an anchored portal.

Portal

2008-04-04T06:38:11Z

SoM:

File:Pskybox04.png

2008-04-04T06:32:57Z

SoM: A slightly more complex skybox than in previous examples.

A slightly more complex skybox than in previous examples.

Portal

2008-04-04T06:03:33Z

SoM:

File:Pskybox03.png

2008-04-04T05:57:53Z

SoM: Simple skybox map viewed from within the main map area.

Simple skybox map viewed from within the main map area.

File:Pskybox02.png

2008-04-04T05:57:35Z

SoM: Simple skybox map viewed from within the skybox area.

Simple skybox map viewed from within the skybox area.

File:Pskybox01.png

2008-04-04T05:57:11Z

SoM: Simple map with a skybox portal.

Simple map with a skybox portal.

Portal

2008-04-02T19:49:51Z

SoM: added horizon portal section.

File:Phorizon01.png

2008-04-02T19:43:49Z

SoM: A simple map with a horizon portal applied to the ceiling and wall of a sector.

A simple map with a horizon portal applied to the ceiling and wall of a sector.

Portal

2008-04-02T19:07:01Z

SoM: Re-arranged the images a bit to shorten the vertical length

Portal

2008-04-02T19:03:08Z

SoM: slight change.

Portal

2008-04-02T19:01:03Z

SoM: Finished the fixed plane portal section.

File:Pfixedplane04.png

2008-04-02T18:59:20Z

SoM: Map with the same fixed plane portal applied to the ceiling and a wall of the same sector.

Map with the same fixed plane portal applied to the ceiling and a wall of the same sector.

File:Pfixedplane03.png

2008-04-02T18:58:02Z

SoM: The map from Pfixedplane01.png with an additional line special which will display the fixed plane portal on the line in the back of the room.

The map from Pfixedplane01.png with an additional line special which will display the fixed plane portal on the line in the back of the room.

Portal

2008-04-02T18:49:01Z

SoM: New page: Portals are a powerful mapping feature which allow a variety of rendering effects; they allow an architectural surface to be used as a "window" which can display something besides the text...

File:Pfixedplane02.png

2008-04-02T18:47:31Z

SoM: The map shown in Pfixedplane01.png as it appears in Eternity

The map shown in Pfixedplane01.png as it appears in Eternity

File:Pfixedplane01.png

2008-04-02T18:34:08Z

SoM: uploaded a new version of "Image:Pfixedplane01.png": An overview of a map in editor. The line pointed to has been given a fixed plane portal special and has been tagged to the sector the player is in.

An overview of a map in editor. The line pointed to has been given a fixed plane portal special and has been tagged to the sector the player is in.

File:Pfixedplane01.png

2008-04-02T18:31:44Z

SoM: An overview of a map in editor. The line pointed to has been given a fixed plane portal special and has been tagged to the sector the player is in.

An overview of a map in editor. The line pointed to has been given a fixed plane portal special and has been tagged to the sector the player is in.

File:Pterminology03.png

2008-04-02T18:08:24Z

SoM: uploaded a new version of "Image:Pterminology03.png": A simple map with a fixed plane portal applied to the ceiling and a wall. Both surfaces share a single portal window, which is outlined in white.

A simple map with a fixed plane portal applied to the ceiling and a wall. Both surfaces share a single portal window, which is outlined in white.

File:Pterminology03.png

2008-04-02T18:06:35Z

SoM: A simple map with a fixed plane portal applied to the ceiling and a wall. Both surfaces share a single portal window, which is outlined in white.

A simple map with a fixed plane portal applied to the ceiling and a wall. Both surfaces share a single portal window, which is outlined in white.

File:Pterminology02.png

2008-04-02T18:04:35Z

SoM: A simple map, with a fixed plane portal applied to the ceiling. Note the portal window is outlined in white.

A simple map, with a fixed plane portal applied to the ceiling. Note the portal window is outlined in white.

File:Pterminology01.png

2008-04-02T18:01:12Z

SoM: A simple map with no portal surfaces, and no portal window.

A simple map with no portal surfaces, and no portal window.

3DMidTex advanced topics

2006-01-10T05:23:56Z

SoM: Initial post

[[3DMidTex]] are useful for more than just bridges. This tutorial will walk you through to process of making a door, a lift, and a floating switch. If you have not read the first tutorial, you may want to read [[3DMidTex tutorial]].

== 3DMidTex switches ==
When a 3DMidTex line has a linedef switch special, the 3DMidTex acts as the switch, and is height restrictive. This means, the player has to be touching the switch (on the z axis, as well as x and y) to trigger it.

== Linking a 3DMidTex to sector movement ==
[[Eternity]] provides linedef specials which allow you to link sector movement (either floor or ceiling) to 3DMidTex lines. Using these specials you can create any kind of moving structure.

Special 281 - Link linedef front sector floor movement to all tagged 3DMidTex lines.
Special 282 - Link linedef front sector ceiling movement to all tagged 3DMidTex lines.

(Note: In the current Doom Build eternity configuration, these specials can be found in the "Sector" category.)

=== Making a 3D door ===
Making a 3DMidTex door is very simple. First, create the door.

[[Image:3dmidtex_tut5.jpg]]

Here the example door is in the middle of a bridge that crosses a large expanse, and a fence has been built on either side of the bridge to prevent the player from running around the door. Notice I made the door into two lines, both lines having their front sides facing out. Set the special of both these lines to 63 (SR Open door wait close) and set the tag to 1. If you run the map right now, nothing will happen because these two lines comprise the door that the player will interact with. The actual movement is going to be caused off screen.

Create a small sector out of the way. Set the floor height to 0, the ceiling height to 0 (so it's closed) and set the tag to 1. This sector will become the sector that moves the 3DMidTex door, and this door will be triggered when the player presses on the 3DMidTex door. Next, create another sector attached to your first one. Set the floor to 0, the ceiling to 64 and set the tag to 0. This sector will give the door sector you just created a height to raise up to.

Last, set one of the lindefs of the door sector (make sure it's one that faces in the door sector) to have a 282 special, and a tag of 1. This links the movement of the sector's ceiling to the 3DMidTex door (which you will remember also has a tag of 1.)

[[Image:3dmidtex_tut6.jpg]]

Now simply run the map and press on the 3DMidTex door. The door should now raise up, wait for 3 seconds, and close. If the player is caught under the door, it will now close (just like if the player was caught under a sector ceiling closing) because the link is two way. This also means that crushing ceilings will cause 3DMidTex lines to do damage to things when they are caught.

This tutorial is not yet complete. Please check back later.

File:3dmidtex tut6.jpg

2006-01-10T05:20:14Z

SoM:

File:3dmidtex tut5.jpg

2006-01-10T05:02:21Z

SoM:

3DMidTex tutorial

2006-01-07T04:53:27Z

SoM: /* Clipping */

[[Eternity]] provides the possibility of using the middle textures of linedefs as solid objects that can be walked over or under, and can block map object passage. Monsters can walk across them, and they can even be moved (with the assistance of some linedef specials) to create lifts, doors, anything you like. They are quite useful and easy to implement.

This feature is called [[3DMidTex]], and this tutorial covers the basics of how to use it. Once you are finished with here, you may want to read [[3DMidTex advanced topics]] to learn about the use of 3DMidTex lines with switches, doors, and lifts.

== Your first 3D bridge ==

For the purposes of this tutorial, I'll assume you are familiar with Doom editing and your level editor, and with the use of middle textures. You will need to use an editor that either has support for Eternity features (e.g. [[Doom wiki:Doom Builder|Doom Builder]]) or an editor that allows you to manually change the flags value for linedefs.

First, open up a new Doom 2 level for editing, and create a simple room with a pit running through it.

[[Image:3dmidtex_tut1.jpg]]

(I added cool, ultra-hurty lava to mine)

Now you need to create the structure the player will eventually be able to cross to get to safety. Again, I assume you know how to create two sided lines and place and align middle textures in them.

[[Image:3dmidtex_tut2.jpg]]

If you run this map, the player obviously falls down through your middle texture bridge. So we perform the final step: setting the lindef flag. The flag is 1024 (0x400 in HEX), so if you are editing the flags yourself, just add 1024 to your flag value; if you are using Doom Builder, and you don't see the lindef flag called "3dMidTex", press F2 and make sure you are editing your map as an Eternity map. Once your flags are set for your linedefs, run the map, and the player should now be able to cross the bridge as if the middle textures were solid objects.

== Some things to watch out for ==

=== Holes in your structures ===

Each structure needs to be closed enough to support the objects running over it. That is, the lines need to be close enough together so that an object can't slip through the gaps.

[[Image:3dmidtex_tut3.jpg]]

=== Clipping ===

It is important to note that clipping is determined by the '''front side''' offset and texture height, so if both sides of the 3DMidTex aren't aligned to be in the same spot or the textures are different heights, the solid part of the line will be where the front side texture is. 3DMidTex lines will only block objects and not bullets. So a 3DMidTex will stop a rocket but not a shotgun blast.

Also, please note that the entire height of the texture is considered solid regardless of the transparency of the texture. So the player can't pass through a 64x32 unit hole in a texture.

=== Monsters crossing ===

Because of the way monster AI in Doom works, it can be VERY tricky to get monsters to cross a 3D bridge. When a monster contacts a line in a map with a drop that's too far for it, the monster will not cross that line, because the engine assumes there is nothing on the other side for the monster to step on. Here are some tips to help you overcome this.

When a monster comes in contact with a 3DMidTex line that it can stand on (i.e., is not under or high above) the monster will ignore all lines with big drop-offs that it would otherwise not cross. The easiest way is to ensure that the monster will not cross any big dropoff lines before stepping on a 3DMidTex line. One way to do this is to create stair steps on either side of your bridge that drop 16 units down, and place a 3DMidTex line inside the nitch you just created.

[[Image:3dmidtex_tut4.jpg]]

Now monsters are much more likely to cross your bridge. Another thing to note is that monsters have no idea which line is the edge of the 3D bridge, and will hang off the edges. They won't fall down, so don't worry, but it just looks bad. One remedy is to make the outer edges monster impassible. When the 3DMidTex flag and this are used in conjunction, monsters will be blocked when they try to cross on top of that 3DMidTex; however, they won't be blocked by going under it.

Now that you've mastered the art of the 3D bridge, you should give [[3DMidTex advanced topics]] a try.

[[Category:Tutorials]]

3DMidTex tutorial

2006-01-06T04:36:30Z

SoM: /* Monsters crossing */

[[Eternity]] provides the possibility of using the middle textures of linedefs as solid objects that can be walked over or under, and can block map object passage. Monsters can walk across them, and they can even be moved (with the assistance of some linedef specials) to create lifts, doors, anything you like. They are quite useful and easy to implement.

This feature is called [[3DMidTex]], and this tutorial covers the basics of how to use it. Once you are finished with here, you may want to read [[3DMidTex advanced topics]] to learn about the use of 3DMidTex lines with switches, doors, and lifts.

== Your first 3D bridge ==

For the purposes of this tutorial, I'll assume you are familiar with Doom editing and your level editor, and with the use of middle textures. You will need to use an editor that either A. has support for Eternity features (IE. DoomBuilder) or an editor that allows you to manually change the flags value for linedefs. I use DoomBuilder, you should too ;)

First, open up a new Doom2 level for editing, create a simple room with a pit running through it.

[[Image:3dmidtex_tut1.jpg]]

(I added cool, ultra-hurty lava to mine)

Now you need to create the structure the player will eventually be able to cross to get to safety. Again, I assume you know how to create two sided lines and put middle textures in them.

[[Image:3dmidtex_tut2.jpg]]

So if you run this map, the player obviously falls down through your middletexture bridge. So we perform the final step: setting the lindef flag. Now the flag is 1024 (0x400 in HEX) so if you are editing the flags yourself just add 1024 to your flag value, if you are using Doombuilder, and you don't see the lindef flag called "3dMidTex", press F2 and make sure you are editing your map as an Eternity map. Once your flags are set for your linedefs, run the map and the player should now be able to cross the bridge as if the middle textures were solid objects.

== Some things to watch out for ==

=== Holes in your structures ===

Each structure needs to be closed enough to support the objects running over it. That is to say, the lines need to be close enough together so that an object can't slip through the gaps.

[[Image:3dmidtex_tut3.jpg]]

=== Clipping ===

It is important to note that clipping is determined by the '''front side''' offset and texture height, so if both sides of the 3DMidTex aren't aligned to be in the same spot or the textures are different heights, the solid part of the line will be where the front side texture is.

Also please note that the entire height of the texture is considered solid regardless of the transparency of the texture. So the player can't pass through a 64x32 unit hole in a texture. This would have required too much processor power to accomplish.

=== Monsters crossing ===

Because of the way monster AI in doom works, it can be VERY tricky to get monsters to cross a 3d bridge. When a monster contacts a line in a map with a drop that's too far for it, the monster will not cross that line because the engine assumes there is nothing on the other side for the monster to step onto. Here are some tips to help you overcome this.

When a monster comes in contact with a 3DMidTex line that it can stand on (ie, is not under or high above) the monster will ignore all lines with big drop-offs that it would otherwise not cross. The easiest way is to make sure that the monster will not cross any big dropoff lines before stepping on a 3DMidTex line. One way to do this is to create stair steps on either side of your bridge that drop 16 units down, and place a 3dMidTex line inside the nitch you just created.

[[Image:3dmidtex_tut4.jpg]]

Now monsters are much more likely to cross your bridge. Another thing to note is that monsters have no idea which line is the edge of the 3d bridge, and will hang off the edges. They won't fall down, so don't worry, but this just looks bad. One remedy is to make the outer edges monster impassible. When the 3DMidTex flag and this are used in conjunction, monsters will be blocked when they try to cross on top of that 3DMidTex, however, they won't be blocked by going under it.

Now that you've mastered the art of the 3D bridge, you should give [[3DMidTex advanced topics]] a try.

[[Category:Tutorials]]

3DMidTex tutorial

2006-01-06T04:27:07Z

SoM:

[[Eternity]] provides the possibility of using the middle textures of linedefs as solid objects that can be walked over or under, and can block map object passage. Monsters can walk across them, and they can even be moved (with the assistance of some linedef specials) to create lifts, doors, anything you like. They are quite useful and easy to implement.

This feature is called [[3DMidTex]], and this tutorial covers the basics of how to use it. Once you are finished with here, you may want to read [[3DMidTex advanced topics]] to learn about the use of 3DMidTex lines with switches, doors, and lifts.

== Your first 3D bridge ==

For the purposes of this tutorial, I'll assume you are familiar with Doom editing and your level editor, and with the use of middle textures. You will need to use an editor that either A. has support for Eternity features (IE. DoomBuilder) or an editor that allows you to manually change the flags value for linedefs. I use DoomBuilder, you should too ;)

First, open up a new Doom2 level for editing, create a simple room with a pit running through it.

[[Image:3dmidtex_tut1.jpg]]

(I added cool, ultra-hurty lava to mine)

Now you need to create the structure the player will eventually be able to cross to get to safety. Again, I assume you know how to create two sided lines and put middle textures in them.

[[Image:3dmidtex_tut2.jpg]]

So if you run this map, the player obviously falls down through your middletexture bridge. So we perform the final step: setting the lindef flag. Now the flag is 1024 (0x400 in HEX) so if you are editing the flags yourself just add 1024 to your flag value, if you are using Doombuilder, and you don't see the lindef flag called "3dMidTex", press F2 and make sure you are editing your map as an Eternity map. Once your flags are set for your linedefs, run the map and the player should now be able to cross the bridge as if the middle textures were solid objects.

== Some things to watch out for ==

=== Holes in your structures ===

Each structure needs to be closed enough to support the objects running over it. That is to say, the lines need to be close enough together so that an object can't slip through the gaps.

[[Image:3dmidtex_tut3.jpg]]

=== Clipping ===

It is important to note that clipping is determined by the '''front side''' offset and texture height, so if both sides of the 3DMidTex aren't aligned to be in the same spot or the textures are different heights, the solid part of the line will be where the front side texture is.

Also please note that the entire height of the texture is considered solid regardless of the transparency of the texture. So the player can't pass through a 64x32 unit hole in a texture. This would have required too much processor power to accomplish.

=== Monsters crossing ===

Because of the way monster AI in doom works, it can be VERY tricky to get monsters to cross a 3d bridge. When a monster contacts a line in a map with a drop that's too far for it, the monster will not cross that line because the engine assumes there is nothing on the other side for the monster to step onto. Here are some tips to help you overcome this.

When a monster comes in contact with a 3DMidTex line that it can stand on (ie, is not under or high above) the monster will ignore all lines with big drop-offs that it would otherwise not cross. The easiest way to insure that the monster will not cross any big dropoff lines before stepping on a 3DMidTex line. One simple way to do this is to create stair steps on either side of your bridge that drop 16 units down, and place a 3dMidTex line inside the nitch you just created.

[[Image:3dmidtex_tut4.jpg]]

Now monsters are much more likely to cross your bridge. Another thing to note is that monsters have no idea which line is the edge of the 3d bridge, and will hang off the edges. They won't fall down, so don't worry, but this just looks bad. One remedy is to make the outer edges monster impassible. When the 3DMidTex flag and this are used in conjunction, monsters will be blocked when they try to cross on top of that 3DMidTex, however, they won't be blocked by going under it.

Now that you've mastered the art of the 3D bridge, you should give [[3DMidTex advanced topics]] a try.

[[Category:Tutorials]]

File:3dmidtex tut4.jpg

2006-01-06T04:21:17Z

SoM:

3DMidTex tutorial

2006-01-06T01:37:26Z

SoM:

[[Eternity]] provides the possibility of using the middle textures of linedefs as solid objects that can be walked over or under, and can block map object passage. Monsters can walk across them, and they can even be moved (with the assistance of some linedef specials) to create lifts, doors, anything you like. They are quite useful and easy to implement.

This feature is called [[3DMidTex]], and this tutorial covers the basics of how to use it. Once you are finished with here, you may want to read [[3DMidTex advanced topics]] to learn about the use of [[3DMidTex]] lines with switches, doors, and lifts.

== Your first 3D bridge ==

For the purposes of this tutorial, I'll assume you are familiar with Doom editing and your level editor, and with the use of middle textures. You will need to use an editor that either A. has support for Eternity features (IE. DoomBuilder) or an editor that allows you to manually change the flags value for linedefs. I use DoomBuilder, you should too ;)

First, open up a new Doom2 level for editing, create a simple room with a pit running through it.

[[Image:3dmidtex_tut1.jpg]]

(I added cool, ultra-hurty lava to mine)

Now you need to create the structure the player will eventually be able to cross to get to safety. Again, I assume you know how to create two sided lines and put middle textures in them.

[[Image:3dmidtex_tut2.jpg]]

So if you run this map, the player obviously falls down through your middletexture bridge. So we perform the final step: setting the lindef flag. Now the flag is 1024 (0x400 in HEX) so if you are editing the flags yourself just add 1024 to your flag value, if you are using Doombuilder, and you don't see the lindef flag called "3dMidTex", press F2 and make sure you are editing your map as an Eternity map. Once your flags are set for your linedefs, run the map and the player should now be able to cross the bridge as if the middle textures were solid objects.

== Some things to watch out for ==

=== Holes in your structures ===

Each structure needs to be closed enough to support the objects running over it. That is to say, the lines need to be close enough together so that an object can't slip through the gaps.

[[Image:3dmidtex_tut3.jpg]]

=== Clipping ===

It is important to note that clipping is determined by the '''front side''' offset and texture height, so if both sides of the 3DMidTex aren't aligned to be in the same spot or the textures are different heights, the solid part of the line will be where the front side texture is.

Also please note that the entire height of the texture is considered solid regardless of the transparency of the texture. So the player can't pass through a 64x32 unit hole in a texture. This would have required too much processor power to accomplish.

=== Monsters crossing ===

Because of the way monster AI in doom works, it can be VERY tricky to get monsters to cross a 3d bridge. When a monster contacts a line in a map with a drop that's too far for it, the monster will not cross that line because the engine assumes there is nothing on the other side for the monster to step onto. Here are some tips to help you overcome this.

Note: this is obviously unfinished. Check back later.

[[Category:Tutorials]]

3DMidTex tutorial

2006-01-06T01:34:30Z

SoM:

[[Eternity]] provides the possibility of using the middle textures of linedefs as solid objects that can be walked over or under, and can block map object passage. Monsters can walk across them, and they can even be moved (with the assistance of some linedef specials) to create lifts, doors, anything you like. They are quite useful and easy to implement.

This feature is called [[3DMidTex]], and this tutorial covers the basics of how to use it. Once you are finished with here, you may want to read [[3DMidTex advanced topics]] to learn about the use of [[3DMidTex]] lines with switces, doors, and lifts.

== Your first 3D bridge ==

For the purposes of this tutorial, I'll assume you are familure with Doom editing and your level editor, and with the use of middle textures. You will need to use an editor that either A. has support for Eternity features (IE. DoomBuilder) or an editor that allows you to manually change the flags value for linedefs. I use DoomBuilder, you should too ;)

First, open up a new Doom2 level for editing, create a simple room with a pit running through it.

[[Image:3dmidtex_tut1.jpg]]

(I added cool, ultra-hurty lava to mine)

Now you need to create the structure the player will eventually be able to cross to get to safety. Again, I assume you know how to create two sided lines and put middle textures in them.

[[Image:3dmidtex_tut2.jpg]]

So if you run this map, the player obviously falls down through your middletexture bridge. So we perform the final step: setting the lindef flag. Now the flag is 1024 (0x400 in HEX) so if you are editing the flags yourself just add 1024 to your flag value, if you are using Doombuilder, and you don't see the lindef flag called "3dMidTex", press F2 and make sure you are editing your map as an Eternity map. Once your flags are set for your linedefs, run the map and the player should now be able to cross the bridge as if the middle textures were solid objects.

== Some things to watch out for ==

=== Holes in your structures ===

Each structure needs to be closed enough to support the objects running over it. That is to say, the lines need to be close enough together so that an object can't slip through the gaps.

[[Image:3dmidtex_tut3.jpg]]

=== Clipping ===

It is importaint to note that clipping is determined by the '''front side''' offset and texture height, so if both sides of the 3DMidTex aren't aligned to be in the same spot or the textures are different heights, the solid part of the line will be where the front side texture is.

Also please note that the entire height of the texture is considered solid reguardless of the transparency of the texture. So the player can't pass through a 64x32 unit hole in a texture. This would have required too much processor power to accomplish.

=== Monsters crossing ===

Because of the way monster AI in doom works, it can be VERY trickey to get monsters to cross a 3d bridge. When a monster contacts a line in a map with a drop that's too far for it, the monster will not cross that line because the engine assumes there is nothing on the other side for the monster to step onto. Here are some tips to help you overcome this.

Note: this is obviously unfinished. Check back later.

[[Category:Tutorials]]

3DMidTex tutorial

2006-01-06T01:27:59Z

SoM: Save to be safe... again

[[Eternity]] provides the possibility of using the middle textures of linedefs as solid objects that can be walked over or under, and can block map object passage. Monsters can walk across them, and they can even be moved (with the assistance of some linedef specials) to create lifts, doors, anything you like. They are quite useful and easy to implement.

This feature is called [[3DMidTex]], and this tutorial covers the basics of how to use it. Once you are finished with here, you may want to read [[3DMidTex Advanced Topics]] to learn about the use of [[3DMidTex]] lines with switces, doors, and lifts.

== Your First 3D Bridge ==

For the purposes of this tutorial, I'll assume you are familure with Doom editing and your level editor, and with the use of middle textures. You will need to use an editor that either A. has support for Eternity features (IE. DoomBuilder) or an editor that allows you to manually change the flags value for linedefs. I use DoomBuilder, you should too ;)

First, open up a new Doom2 level for editing, create a simple room with a pit running through it.

[[Image:3dmidtex_tut1.jpg]]

(I added cool, ultra-hurty lava to mine)

Now you need to create the structure the player will eventually be able to cross to get to safety. Again, I assume you know how to create two sided lines and put middle textures in them.

[[Image:3dmidtex_tut2.jpg]]

So if you run this map, the player obviously falls down through your middletexture bridge. So we perform the final step: setting the lindef flag. Now the flag is 1024 (0x400 in HEX) so if you are editing the flags yourself just add 1024 to your flag value, if you are using Doombuilder, and you don't see the lindef flag called "3dMidTex", press F2 and make sure you are editing your map as an Eternity map. Once your flags are set for your linedefs, run the map and the player should now be able to cross the bridge as if the middle textures were solid objects.

== Some things to watch out for ==

=== Holes in your structures ===

Each structure needs to be closed enough to support the objects running over it. That is to say, the lines need to be close enough together so that an object can't slip through the gaps.

[[Image:3dmidtex_tut3.jpg]]

=== Clipping ===

It is importaint to note that clipping is determined by the '''front side''' offset and texture height, so if both sides of the 3DMidTex aren't aligned to be in the same spot or the textures are different heights, the solid part of the line will be where the front side texture is.

Also please note that the entire height of the texture is considered solid reguardless of the transparency of the texture. So the player can't pass through a 64x32 unit hole in a texture. This would have required too much processor power to accomplish.

=== Monsters crossing ===

Because of the way monster AI in doom works, it can be VERY trickey to get monsters to cross a 3d bridge. When a monster contacts a line in a map with a drop that's too far for it, the monster will not cross that line because the engine assumes there is nothing on the other side for the monster to step onto. Here are some tips to help you overcome this.

Note: this is obviously unfinished. Check back later.

[[Category:Tutorials]]

3DMidTex tutorial

2006-01-06T01:05:59Z

SoM: Wrote most of the tutorial... Just saving in mid-write to be save

File:3dmidtex tut3.jpg

2006-01-06T01:00:32Z

SoM:

File:3dmidtex tut2.jpg

2006-01-06T00:42:45Z

SoM:

File:3dmidtex tut1.jpg

2006-01-06T00:31:53Z

SoM: image used in the tutorial for using 3DMidTex lines in eternity

image used in the tutorial for using 3DMidTex lines in eternity