Building a 3D Portal Engine - Issue 17 - End Of Transmission
by (23 April 1999)

Return to The Archives

Well, this is it. You are reading the last episode of the column. Why? Because it's time to quit. I have told you everything I know about portal rendering, and it's time to move on: Portals are not the only solution, as many people have pointed out. The 3D coding community has even been accused of 'focusing too much on the hype of portal rendering', and despite the fact that I have pointed out numerous times that portal rendering is just one approach, I feel a bit guilty. After all, the name of this column suggests that 'The Phantom' 'does Portals'. Well, it's not like that at all. The Phantom likes portals. Because they are easy. Because it's a good start. By now, you should know how to make a good start yourself, so this column has served it's purpose.

Don't get me wrong: I'm not 'quitting' because I don't like writing column issues anymore. I had a good time. Got nice feedback. I appreciate that! Thank you all.

This doesn't mean that these are my last words either. People who know me also know that I tend to get 'active' every now and then, and when that happens, I publish some sources, some articles, answer most of my e-mail, and so on. I believe in knowledge sharing, and as long as my employer doesn't forbid me to share everything I know, I will keep telling you everything I know. I believe that my personal knowledge increases when I share my ideas, because there's always someone with more knowledge, or fresh ideas (many thanks to Harmless, Jaap, DirtyPunk and countless others!), and I know these people feel the same. I also believe that the fun increases this way: After all, why should you feel good about a good idea when no-one knows you had a good idea? Why should you feel good if you did an incredible cool invention, when there's only you to take the invention further? You shouldn't.

I often wonder, does Carmack regret his sharing of knowledge, now that the Unreal engine seems to be more popular than his Quake2 engine? I don't think so. He'll just strike back with Quake3, and then Trinity, and so on, because the knowledge is of less value than the power to gather and generate knowledge. It won't matter.

Enough of that. By now, you should understand the following concepts, and if you don't, I suggest you read previous issues again, or you can write me an e-mail.
  • Getting something on the screen: Check out the latest version of OpenPTC, it's great stuff. I'm using it all the time, and it gets better all the time. Good work, Gaffer! You just made the transition to windows fun.

  • Rotating 3D coordinates, building basic 3D data structures, applying perspective: Check the wireframe example that I explained in a previous column. It's a good start if you have no idea where to start. After all, the best way to learn programming is to take a working source, and move on from there. Sure, some day you'll just throw away that code and write your own, but before that happens, you don't want to bother with each and every small detail.

  • Plane equations, Sutherland-Hodgeman clipping and the view frustum: Clipping is best done in 3D, especially if you intend to move on after you have completed your first program that displays something that is larger than the screen.

  • Portal rendering and shadow casting: Tough stuff, especially if you want it to be fast. I have explained how to do it, how to get it reasonably fast, and you should know what the weaknesses are. From there, you can explore the wonderful world of visibility determination, spatial subdivisions, collision detection and so on.

  • Mixing is the key... I hope I made it clear that no single approach will ever be 'the approach'. Make sure you know the possible ingredients: Harmless discussed a great selection of fine occlusion techniques, and all of these have variants, and all of these can be combined in interesting ways with various spatial subdivisions, but the most interesting things happen when you get creative. After all, there are not that many specialists, so you might find something that no-one thought of.
  • I hope I also made clear that you are not going to get away with some wimpy API, like OpenGL, Direct3D, or Fahrenheit for that matter; you really need in-depth knowledge of the theory, even if you decide to use an API nevertheless. Let me give you an example: When I was trying to get bilinear interpolation working in software, I first wrote a pure C++ implementation. It was already quite fast, since I used tables instead of multiplications, besides other things. Then I converted it to assembler. To get it efficient, I had to change my table structures a lot, but after I got everything working again, it was twice as fast as the C++ version. Then I converted it back to C++, using the same data structures. It got 10% faster than the assembler version. Conclusion? 1. I didn't spot all optimization opportunities in the assembler version. 2. Microsoft intentionally makes inline assembly slower to make it's compiler look good. :) 3. Your C++ code can only achieve the maximum performance when you know what's going on inside. The same goes for 3D: If you know how software rendering works, you'll benefit from that knowledge when you don't do everything yourself. One more example: My Riva128 3D accelerator frequently shows black pixels in Quake2. Why? Simple: T junctions. I know that, because I wrote my own software rasterizers, so I know that it's hard to get two edges exactly the same when one of the edges has an extra vertex somewhere. If I wouldn't have known that, every 3D engine that I wrote using an API would have had black spots, and I would be trying to get it right by enlarging the polygons slightly, or by applying some other hack. See?

    One final thing that I wish to say: Don't follow good 3D coders like lemmings. Why is everyone writing his/her own Quake engine? Because there's enough test data for it? Get real. Quake has it's limitations, and there are numerous ways to do a better job. Don't get me wrong, Quake was an awesome achievement. But there's no point in imitation, you don't achieve anything that way. True satisfaction comes from originality. Think about it.

    So: Mix. Share. Innovate. Have fun. Mail me.
    Love you all,
    Jacco Bikker (The Phantom)

    Article Series:
  • Building a 3D Portal Engine - Issue 01 - Introduction
  • Building a 3D Portal Engine - Issue 02 - Graphics Output Under Windows
  • Building a 3D Portal Engine - Issue 03 - 3D Matrix Math
  • Building a 3D Portal Engine - Issue 04 - Data Structures For 3D Graphics
  • Building a 3D Portal Engine - Issue 05 - Coding A Wireframe Cube
  • Building a 3D Portal Engine - Issue 06 - Hidden Surface Removal
  • Building a 3D Portal Engine - Issue 07 - 2D & 3D Clipping: Sutherland-Hodgeman
  • Building a 3D Portal Engine - Issue 08 - Polygon Filling
  • Building a 3D Portal Engine - Issue 09 - 2D Portal Rendering
  • Building a 3D Portal Engine - Issue 10 - Intermezzo - 8/15/16/32 Bit Color Mixing
  • Building a 3D Portal Engine - Issue 11 - 3D Portal Rendering
  • Building a 3D Portal Engine - Issue 12 - Collision Detection (Guest Writer)
  • Building a 3D Portal Engine - Issue 13 - More Portal Features
  • Building a 3D Portal Engine - Issue 14 - 3D Engine Architecture
  • Building a 3D Portal Engine - Issue 15 - Space Partitioning, Octrees, And BSPs
  • Building a 3D Portal Engine - Issue 16 - More On Portals
  • Building a 3D Portal Engine - Issue 17 - End Of Transmission

    Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
    Please read our Terms, Conditions, and Privacy information.