When looking at old games like Mario64 or DukeNukem3D, all the mirrors in the game are essentially just holes in the wall with a mirrored copy of the geometry in front of the mirror put behind them. In the case of DukeNukem3D one can even activate no-clip and walk into that mirrored room.

In contrast modern games use a render-to-texture approach for mirrors. This leads to the mirrors getting noticeably pixelated when getting to close to them. One of the first games I noticed this approach was Luigi's Mansion, but it seems to be used in almost all modern games.

What change in the hardware or engines made the second approach become so dominant these days and what are the benefits to it? In terms of pure visuals the first approach seems superior, as it doesn't suffer from pixelation issues.

  • 14
    \$\begingroup\$ What if you want a mirror on a door between two rooms? \$\endgroup\$ – Superbest Jul 25 '16 at 16:47
  1. Using RTT (render-to-texture) allows to easily scale rendering quality (resolution, LOD, lighting complexity) for adjustable performance. RTT also makes it easier to replace the surface with a cubemap at a certain distance where it's hard to see the reflection exactly.
  2. Since the output is a texture, there are more options regarding what can be done with it afterwards (lighting, shading, blending, distortion etc.).
  3. If a mirrored version of geometry is placed in the scene, it would require more complicated culling when it intersects with real geometry and could be seen behind the corner. In older games, levels were designed to avoid this. Not to mention that somebody has to do the actual mirroring.
  4. If geometry is not manually mirrored, rendering must be done by changing the view matrix and culling mode (to compensate for the space inversion in the matrix), and using the stencil buffer to cut out the mirror. Modern engines prefer to create all render states in advance, so there would be a minor issue with making copies of every scene render state with the required changes for mirror rendering.

So basically using RTT gives more freedom to everyone.

  • \$\begingroup\$ On 3.: Most (older) FPS game engines used bisection algorithms (like the famous "portal engine" DOOM uses) which already do clipping on (most likely quad) polygons for visibility culling. Such engines can easily tread a quad "mirror" as a sight portal into a room behind the mirror without worrying about the mirrored geometry outside of the mirror. \$\endgroup\$ – dronus Jul 27 '16 at 12:39
  • \$\begingroup\$ @dronus What? Than why bother making a "mirror" at the first place? Just open a hole in the wall. \$\endgroup\$ – S. Tarık Çetin Jul 28 '16 at 15:14
  • \$\begingroup\$ Because the real geometry may not leave space behind the mirror wall, like a real mirror does not need to have a room behind to work. \$\endgroup\$ – dronus Aug 1 '16 at 22:06

No, you are wrong - that's not how Duke Nukem 3D's mirrors worked at all.

DN3D used a portal engine. A joint between any two sectors was arbitrary to an extent, and when the rendering engine came to a portal, it knew that it has to start rendering another sector in that. The sector behind the mirror was basically a place holder to deal with a quirk in the engine - the only point of the sector was to be bigger than whatever you needed "reflected". It didn't contain any real geometry. In fact, it worked pretty much the same way "portals" work in Portal - except that Portal (itself being based on a portal engine) creates the portals at runtime, and has a limit to how many times the portals can recurse (i.e. A -> B -> A -> B -> A ...), while Build (DN3D) would simply crash as its stack overflowed if you pointed a mirror at another mirror.

It's obvious how simple it is to implement a mirror with that - make a portal that points back into the room. This meant that rendering the mirror would cost exactly as much as rendering the room itself, giving great performance and consistency. As long as you didn't point a mirror at another mirror, that is. If you look through the Build engine source code, you'll see there's no code handling mirrors at all - there doesn't have to be one, because that's how portals work NOTE: actually, there is code to flip the rendered pixels - it just doesn't flip the geometry and all the various sprites and effects. The editor had to be able to make these "fake" portals, though - looking back on itself. If you want to know more about the quite smart Build engine, there's a great analysis by Fabien Sanglard at Build engine internals. The whole engine has been open sourced and ported to modern platforms as well, though the old one still works flawlessly on Windows 10 (tested for you :P). Many of the games based on Build have also been open sourced and/or remade.

Why is this no longer used? Well, some engines no longer prefer portals, for one. It's tricky to apply a lot of graphics hacks and optimizations - I can't point you to anything specific, but a lot of post-processing depends on hacks that wouldn't work in a true portal engine (they make a lot of assumptions that no longer hold). This is basically the same kind of issue these games have with stereoscopic imagery - the hacks no longer work.

Most importantly, mirrors got more complicated. They can have complex shapes, textures, they may be on the ground (also known as "water") etc. While all of those problems are solvable in a portal engine, RTT becomes the simpler choice at some point, and GPUs are fast enough to handle it.

However, even with all that, there are plenty of games with hardware 3D acceleration that do things "real". Of the older games, Quake 3 or Alien vs. Predator, for example. As far as I know, Source engine games still use "real" mirrors. If you expect that people are going to get close to the mirror, and you can guarantee that there's not too many reflective surfaces at the same time (e.g. through level design), portal mirrors are still very attractive.

  • \$\begingroup\$ Apparently the reason for the common belief that Duke Nukem 3D worked this way is the fact that in the actual level designs, the space behind the mirror is as large as the room it reflects, even though the rendering engine doesn't actually require it. \$\endgroup\$ – Random832 Jul 25 '16 at 14:05
  • \$\begingroup\$ Also, non-mirror portals don't, well, mirror things, so I don't know how "there's no code handling mirrors" is possible. \$\endgroup\$ – Random832 Jul 25 '16 at 14:07
  • 5
    \$\begingroup\$ @Random832 It was kind of required - there were some visual artifacts if some sector appeared in the place where the mirrored room was supposed to be. That's one of those parts where mostly harmless assumptions mattered a lot for performance. If you ever played around with Build, you might have noticed that when two sectors cross at the same height, they will not render well. As for mirroring, it works the same way real-life mirrors work. Did you ever wonder why mirrors only "flip" on the y-axis? It's the same reason why you don't need to flip a portal that connects you back to the same room. \$\endgroup\$ – Luaan Jul 25 '16 at 15:30
  • \$\begingroup\$ The point is, a normal portal that leads into a room that faces in the opposite direction would have to rotate things 180 degrees rather than reflecting them. So having the ability to not do so counts as special handling for mirrors. (Not having the ability to do so would mean that the portals don't work as portals and are only suitable for mirrors, in which case the whole system is special handling for mirrors). And, yes, I know why mirrors "only "flip" on the y-axis". In fact, they flip on the z-axis. But the fact that they flip an odd number of axes makes them distinct from portals. \$\endgroup\$ – Random832 Jul 25 '16 at 15:59
  • \$\begingroup\$ @Random832 Depends on what you call the y-axis, of course :) And yeah, you're right, there is special handling. But it's very interesting - it flips the rendered data, not the geometry (and sprites and everything... quite a bit of work, actually). The portal frame is flipped, the portal is rendered as usual, and then the whole thing is rendered backwards, line by line. \$\endgroup\$ – Luaan Jul 25 '16 at 16:32

RTT would have been used if it was possible but the hardware rendering pipeline was one way.

Older hardware also had limitations that prevented render to texture. Writing to RAM means it can not be read at the same time. To improve rendering performance the destination buffer was locked to write only, only the display hardware could read from it. You could request reading, but that locked the RAM and the render had to wait for the lock to clear before it could start the next frame. RTT would cause a major bottleneck to the pipeline and thus other solutions were used.

You will find that befor Hardware rendering pipelines were the norm RTT was used as it provided a way to reduce the rendering load. 3D rendered to sprites to provide pseudo 3D content. Texture rendering was way too costly (CPU) to be used back then, apart from specialised machines that were outside the general consumer market.


Duke Nukem handle that by re-rendering the geometry behind the mirror, the other answers are partially correct. There are areas behind mirrors that actually contains no geometry (in game data files), the geometry is re-rendered at run time infact, the reason for those areas to exist is to avoid to place accidentally a piece of level there when editing the level:

since theres' an area marked you will not place accidentally any geometry in there.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.