Last week I finally got my hands on Valve's Portal and I must say that it's a terrific game. It was a bit short, but I had a lot of fun. What I liked in particular was being able to make "combos", e.g. falling from the the ceiling through a portal on the ground and the shooting across the room through the newly opened portal on a wall. Very cool! So I figured, why not include it in my own raytracer which I'm building as part of my diploma thesis?

">Linky the link to a video on YouTube. The idea of portals can be applied to raytracing pretty easily by adding dummy geometry and ray transformations: In my app, portals can be opened by pointing at a wall and clicking either the left mouse button for the first endpoint or the right button for the second endpoint. I perform ray picking simply by tracing another ray from the camera origin. A portal is then created by adding a quad (two tris) to the scene. It's orientation is determined using the normal vector of the hit surface. In the rendering function that is invoked, when a ray hits the portal geometry, I perform some sort of clipping to give the portal a more appealing shape of a circle. Now that we got the dummy geometry in place, let's discuss how the portal effect is achieved. Portals are described by a 4x4 matrix, effectively establishing a local coordinate system. Since there are two portals, we have two matrices: matA and matB. When a ray hits the portal geometry, its origin and direction vector are transformed by multiplying with the matrix mat = matTo * inverse(matFrom), i.e. org' = mat * org, dir' = mat * dir. matTo is the matrix of the portal we wish to go to, matFrom is the current portal's matrix. And that's it already. Pretty simple, and due to the fact that mat can be precalculated the impact on performance is not that bad. Now I'd only need to add physics to the simulation for some serious Portal-styled fun, but that's not really the scope of my thesis.

I don't have a website yet, because I wouldn't have the time to keep it updated and post content. Heck, I wish I had enough time to finally start writing my thesis! But a lot of other projects needed my attention recently, so I keep adding quickly-to-implement features like these portals.

Some more details you asked for: The video on YouTube shows only one application I'm building on top of a more generic real-time raytracing library. It's an advanced level viewer for Elite Force maps with support for:
- Static and animated world geometry, e.g. Bèzier patches and water.
- Quake 3 surface shaders: I've created a compiler that translates these shader scripts to SSE accelerated C++ code that operates on 4 samples at once.
- Support for md3 and mdr models, they're used for player models.
- Lighting and shadowing, although that's switched off in the demo due to the performance hit it introduces.

The raytracing library is multi-threaded and uses packet tracing to reduce rendering times. It uses an SAH-based kd-tree for static geometry and a bounding volume hierarchy for dynamic parts of the scene. Some interesting features of the latter are:
- Support for instancing, which is used for the entities in the map.
- Lazy construction during rendering.
- Refitting of nodes to react to changes of dynamic geometry.
- Selective rebuilding: If the quality of a bvh-subtree has dropped below a user specified threshold it is rebuild from scratch.

This library will most likely be released under a permissive license in the future ... depending on when I finish my thesis. ;-)

The portal idea in a ray tracer is nice, but things break when you try to light geometry through the portal. The shadow rays to a light source on one side of the portal from a point on the other side would need to bend, and you get a problem similar to inverse kinematics.

I've posted a

">new clip at YouTube. It demonstrates the instancing capabilities of my raytracer.

If anybody is interested I can give you a rundown of the technique and implementation here.