I need the functionality of the linked_portal_door that's in Portal 2. I've searched a little in UDK and mostly got people trying to duplicate the portal gun. Does anyone know if UDK, CryEngine, Unity3D, or any other engine has something similar? I'm not against using Source, I just want to know what my options are.
-
1\$\begingroup\$ Few of the big established engines do, since most are derived from Quake or use similar techniques. Smaller or less well known engines have used portals as their core scene culling technique. I recall that CrystalSpace used to use portals to connect all sectors (similar to how Doom/Doom2 worked, but in full 3D). You might try that engine. I haven't kept up to date on its development, so I don't know if it has switche to another scene management technique or not. \$\endgroup\$– Sean MiddleditchCommented Aug 11, 2012 at 21:25
2 Answers
I'm pretty sure that the Source Engine is the only engine that will support this out of the box. You can read about some of the technical issues in an article I found on Gamasutra, copied here for future readers:
"Another problem we ran across was the need to change distance-based systems such as level of detail (LOD) for models, because with our game, distance is relative to the portal locations.
This means that the distance calculations became a choice of three lines connecting two points, rather than just one line. Also, line of sight can pass through a single portal more than once to reach its target.
The Source Engine does many pre-computed visibility optimizations for culling. Allowing users to bridge visibility leaves with portals added another level of complexity.
For better rendering, we implemented a stencil buffer drawing method for portal views, which gave us a lot of flexibility for handling the portal recursion depth. This allowed us to render an infinitely deep number of portals (limited only by performance), which made our "infinite" hallways look pretty neat.
Stencil drawing also helped us solve the problem of integrating properly with other technology in the Source engine like HDR blooming. Since we have to render our scenes an additional two times for our portals we poured a lot of our effort into making portals render as fast as possible, such as special view frustum culling based on the portal's edges, and render list optimizations for portal drawing."
I also remember reading somewhere that there are a lot of special cases, like having portals on opposite sides of the same block. Making portals is not a simple task.
EDIT:
Found an other good article containing this:
Quickly, we realized that we needed a more robust method for rendering the portals and allowing the player and other objects to move seamlessly between them. This required us to dig a little deeper into the Source engine's rendering and physics code, and we had to program our own portal system.
Basically, we had to tell the Source physics system to make a temporary hole on only one side of a wall, and that everything behind the portal is connected to geometry in another part of the map. Getting this to work and optimizing the solutions to run in real-time was a major challenge.
-
\$\begingroup\$ It's worth notIng that a lot of these problems were the difficulty of adding portals to the existing Quake2-derived Source engine. There are other engines that have been portal-based for scene culling since day one. \$\endgroup\$ Commented Aug 11, 2012 at 21:23
-
\$\begingroup\$ What are some of the engines you're referring too? \$\endgroup\$– wolfadexCommented Aug 12, 2012 at 15:29
You can in Unity3D, using render textures and teleporting the player behind the other one if he looks into the portal, and turning off the collision detection for the other portal, and then when the player moves out of the surface you could turn on its collision detection, or if he just goes through it without looking at it, just teleport him to the other portal (just a guess, dont know if it would work..), don't know about the other 2 though..