I’m sure most web developers know about image rollovers (using separate images for normal and “hover” states of anchors). Hopefully also the use of “CSS Sprites” is becoming better known – combining the normal and rollover images into a single physical image file to speed up load times and reduce flicker. I won’t cover those techniques here.

However, if you want the anchor or button to size to its contents, it’s more difficult to make use of these techniques. Here’s one way.

(The final result – view demo).

Start With Markup

Before diving into fancy techniques, get the markup down as you would like it, if you didn’t have to style anything.

<a href="..." class="rollover">Button Text</a>

Ideally we want the markup to be clean and not compromised by styling requirements.

Handle Degradation Gracefully

My technique is going to make use of JavaScript, so let’s handle the case where the user has it disabled for some reason. Here’s some very basic CSS to give the button a simple style:

a.rollover
{
  background-color: #00f;
  border: solid 1px #000;
  color: #fff;
  font-weight: bold;
  padding: 4px;
  text-decoration: none;
}

a.rollover:hover
{
  background-color: #008;
}

Add Styling Naively

Next, I’m going to add some rollover styling – but in a way that isn’t complete. Firstly I created a simple rollover image, but made it very wide – it needs to be at least as wide as the widest button is ever going to be:

I’m going to define my rollover styling against a class selector of “extra” – you’ll see where that comes from in a moment.

a.rollover.extra
{
  background: url(buttons.png) repeat-x left 0;
  border: none;
  height: 27px;
  padding: 23px 40px 10px 40px;
  position: relative;
}

a.rollover.extra:hover
{
  background-position: left -57px;
}

Note that we’ve had to undo some of the styles applied previously, such as border.

We’re kind of getting there, but our buttons won’t look correct on the right-hand-side.

Use JavaScript To Add Styling Markup

To fix the right-hand end-caps, we need to modify our markup. However, I really don’t want to have to do that on my pages – afterall, I might change my mind about the site styling.

Here I recommend using JavaScript to tweak at runtime the markup to what we need. I’m going to use jQuery for this:

$(function() {
  $('.rollover')
    .addClass('extra')
    .append('<div class="cap"></div>');
});

Basically, when the pad is ready, I find all elements with class “rollover”, add another class (“extra”), and append into the rollover button an empty span element which has a class of “cap”.

That class “extra” triggers the image rollovers. The “cap” span can be styled as follows:

a.rollover.extra .cap
{
  background: url(buttons.png) no-repeat right 0;
  height: 100%;
  position: absolute;
  right: 0;
  top: 0;
  width: 40px;
}

a.rollover.extra:hover .cap
{
  background-position: right -57px;
}

And voila!

If you’d like to see this technique in action, please view the demo.

(I’m going to use C# in my examples here: some of these points might not apply to all languages. By default, an assertion will not fire in a C# release build, and furthermore, the code inside will not even be executed).

Update 2009-06-11: I probably haven’t been clear enough, but luckily various commenters have picked up on this: I’m not advocating removing assertions and replacing them with nothing! In general, I think assertions should be replaced with a stronger check that also runs (or can run) in a release build.

1. Pointless Guard Checking

Unfortunately in my coding travels I see quite a bit of code like this:

void Foo(Bar bar)
{
  Debug.Assert(bar != null);

  bar.DoSomething();
}

What’s the point? If bar is null, then using it will throw an exception anyway. Why add unnecessary lines of code that make reading harder?

2. Bad Argument Checking

But, you’re thinking, what if the usage is separated from the assignment?

class Foo
{
  public Foo(Bar bar)
  {
    Debug.Assert(bar != null);

    _bar = bar;
  }

  public void Method()
  {
    _bar.DoSomething();
  }

  private Bar _bar;
}

True, you want to catch the error as it happens, not later on in the method. But shouldn’t you be throwing an ArgumentNullException instead?

3. Difficult Detective Work

So now you’re telling me that you’re not writing component code, and the only client of this class will be the application it’s embedded in. Why not save some effort and skimp on the checking code, and make it debug-only?

Fine idea… until you get a crash report from one of your users, and the stacktrace points to a NullReferenceException in Method(). Now you have to figure out where the null value got passed to the constructor… a potentially much more difficult task.

4. Differences Between Debug and Release

If you’re like me, you generally run the applications in debug. Your customers however, run in release. Why make the differences between these two versions any bigger? Even if you don’t intend your debug statements to change program state, it’s all too easy to accidentally do so:

• Running lazy-initializers or singleton constructors;
• Loading data from the database via an ORM;
• Moving data in or out of a cache;
• Running static constructors.

5. Too-Shy Sanity-Checking

Sometimes, despite the above warning, you really do have sanity-checking code that you’d like to run in a development or test environment to catch regressions, but which is too slow to give to general users. (I read somewhere that Excel has two computation engines: a simple, slow, reference one, and a fast, parallel, release one. Testers can run the two in parallel, and any differences are automatically flagged as errors).

So you might be tempted to do something like:

Debug.Assert( SlowlyAndCarefullyVerifyInternalState() );

The problem I have with this is that the debug/release division is way too blunt.

• Suppose a tester wants to test a release build, but also perform the sanity-checking?
• Suppose a customer finds a bug in a complex calculation, and you want them to run the checks?
• Suppose a developer wants to debug performance issues in the non-checked code?

I would suggest you move the conditionals for code like this to a (possibly hidden) configuration setting. Someone wants to run in slow-and-safe mode? No problem, just tell them the registry setting (or whatever). By all means, change the splash screen or title bar or whatever so it says “test mode”.

The advantages of this method are:

• Anyone can turn it on and off;
• Sanity-checking can be controlled at a much finer granularity than all-on / all-off.

6. Is It Recoverable, Or Not?

The final argument against debug assertions concerns just exactly what an assertion means.

To my mind, an assertion is different to a simple flow-control test (“did the user enter a valid number?”), which is something the program can (should) handle. By definition, an assertion is checking for a disallowed state. An assertion doesn’t check for incorrect data; it checks for an incorrect program. Continuing after an assertion leads to undefined behaviour.

So how can you continue? More to the point, why should a user even be allowed to continue? If the state really is unrecoverable, then fail. Fail fast, log the error, and bail (possibly trying to allow the user to save work, or whatever). Having a release-build application continue after what would have been an assertion is just plain wrong.

Let’s start with an example graphic, Arrow.xaml:

<UserControl x:Class="WebImagesGenerator.Graphics.Arrow"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  Height="64" Width="64">
  <Canvas Width="64" Height="64">
    <Polygon Points="32,4 60,32 42,32 42,60 22,60 22,32 4,32"
      Fill="Red" Stroke="Black"
      StrokeThickness="3" StrokeLineJoin="Round" />
  </Canvas>
</UserControl>

That’s just a standard XAML file, nothing fancy there.

Rendering WPF content to an image is really easy; you use the RenderTargetBitmap class. I wanted to be able to produce a strip of images, all the same except rotated, that can be used as CSS sprites. For my actual web application, I have a quick console application that generates the images as a batch. If I ever change the XAML files, I can quickly re-generate all the auto-generated images in my project just be running my console application.

Let’s get started on the console application:

[STAThread]
static void Main( string[] args )
{
  var arrow = new Graphics.Arrow();

  SaveStrip( arrow, GenerateSeries( 0, 360, 10 )
           , "..\\..\\Testing\\arrows.png" );
}

WPF must be run in a [STAThread] context. I create an instance of my graphic, then call my SaveStrip routine. GenerateSeries simply returns an array of integers:

static int[] GenerateSeries( int start, int end, int step )
{
  var series = new List<int>();

  for( var v = start; v < end; v += step )
  {
    series.Add( v );
  }

  return series.ToArray();
}

The real magic happens in SaveStrip:

static void SaveStrip( FrameworkElement fe, int[] angles, string filename )
{
  var outer = new Canvas();

  outer.Width = fe.Width * angles.Length;
  outer.Height = fe.Height;

  outer.Children.Add( fe );

  outer.Arrange( new Rect( 0, 0, outer.Width, outer.Height ) );

  var bmp = new RenderTargetBitmap
    ( (int) fe.Width * angles.Length
    , (int) fe.Height, 96, 96, PixelFormats.Pbgra32 );

  for( var i = 0; i < angles.Length; ++i )
  {
    var transforms = new TransformGroup();

    transforms.Children.Add
      ( new RotateTransform( angles[i], fe.Width / 2, fe.Height / 2 ) );

    fe.RenderTransform = transforms;
    fe.SetValue( Canvas.LeftProperty, i * fe.Width );

    // The following line is VITAL!
    outer.Arrange( new Rect( 0, 0, outer.Width, outer.Height ) );

    bmp.Render( fe );
  }

  var encoder = new PngBitmapEncoder();

  encoder.Frames.Add( BitmapFrame.Create( bmp ) );

  using( var stream = File.Create( filename ) )
  {
    encoder.Save( stream );
  }
}

When I first tried this technique, all my output bitmaps were completely blank. After debugging for a while, I realised that all my graphics were of zero size. You MUST call Arrange() on your elements before calling Render(), otherwise they won’t have been laid out properly.

When run, this console app produces the following (reduced in size to fit):

Fantastic! To get a better idea of how such images might appear in a web-page, I’ve created a little HTML+jQuery demo to see a very quick example of the images in use:

View Demo

Firstly, the discussions for reference:

• Discussion on Reddit;
• Post on InfoQ.

#1: It’s Not Functional

Imagine the following SQL statements:

SELECT * FROM [Order] WHERE [CustomerId] = 1
SELECT * FROM [Order]
SELECT * FROM [Order] WHERE [CustomerId] = 1

In the absence of any other concurrent users, if I suggested that the first and third identical queries should return different values, you’d think I was nuts. But that’s exactly what LINQ-to-Entities does.

The world is moving towards functional programming. Functions named “Get” (or “SELECT”) really shouldn’t have side-effects. LINQ-to-Entities violates the principle of least surprise – most coders would expect a SELECT to have no (functional) side-effects.

#2: Performance Over Correctness

I understand why LINQ-to-Entities doesn’t load the values in the first instance. There is a danger when using ORMs that queries inside loops can lead to N+1 queries, killing performance. (In my last job I was involved in writing a custom ORM system, so I know a little about the problem).

However, in my opinion there really are two options to solve this:

1. Performance indicators are applied as ‘hints’ that don’t affect functionality – if you find a block of code is producing bad or multiple queries, you add pre-loading hints.
2. Performance is determined to be sufficiently important that idea #1 is no good. In that case, if the appropriate pre-loads haven’t been issued, an exception is thrown.

LINQ-to-Entities have decided to go for ‘option’ #3, silently return the wrong answer. I always thought the guiding principle of .NET was managed coding – sacrifice a little performance for a great deal of safety: bounds checking, type checking, and so forth. Perhaps the ADO.NET team still think they’re writing C code?

#3: It’s Not A Replacement To LINQ-to-SQL

There’s no one correct way to write an ORM. Different applications have different requirements. A general purpose ORM will never satisfy 100% of developers. Fine. I’m happy with that; there’s a nice market for specialist providers.

What I’m not happy with is that while LINQ-to-SQL seemed to make 90% of developers happy, it’s being replaced with LINQ-to-Entities that (judging by the feedback I’ve seen) makes far less developers happy.

I’m fine with the ADO.NET team writing a solution that fills that 10% gap or otherwise augments LINQ-to-SQL. I’m not happy with them replacing a 90% solution with a specialist 10% solution.

#4: It Hinders Common Scenarios

I work largely in the web app development area, which I understand is just one of many dev scenarios that Microsoft must support. Having said that, it is an increasingly large area (perhaps the largest commercial area, considering that Windows desktop applications are essentially dead apart from internal coporate dev).

Let’s take a typical data-driven web-page:

http://stackoverflow.com/users/6604/stusmith

(Now you can put a face to my writing).

I can imagine the pseudo-LINQ being something like this:

var user = (from u in data.Users
            where u.UserName == "stusmith"
            select u).Single();

// Display the header details.

var questions = from q in user.Questions
                orderby q.Votes desc
                select q;

// Display each question.

var answers = from a in user.Answers
              orderby a.Votes desc
              select a;

// Display each answer.

// Etc for tags, badges, and so forth.

It’s very common, doesn’t involve any performance issues, but LINQ-to-Entities demands that I explicitly load from the database.

#5: Is It Nothing More Than LINQ-to-Objects – or – Where’s The Magic Gone?

The response to my article from the ADO.NET guys is:

“The case here is actually a misunderstanding on the part of the author. The second query that they [sic] author runs, var order, is actually a LINQ to Objects query, not a LINQ to Entities (or LINQ to SQL) query.”

So… LINQ-to-Entities only kicks in when I either (a) query top-level tables, or (b) call Load() methods?

In which case, LINQ-to-Entities actually does a lot less than LINQ-to-SQL. Another quote:

“…the explicit loading in the Entity Framework means that it will not make extra trips to the database “magically” for you.”

My point exactly.

LINQ-to-Entities is like LINQ-to-SQL but with the magic removed.

(Maybe that should be their marketing slogan? “LINQ-to-Entities – now with 100% less magic!”).

I always thought the point of an ORM was that it was a transparent mapping from database to objects. I can write explicit loads myself; they’re called SELECT statements. The wonder of LINQ-to-SQL was that I didn’t have to. Now I do. Is that really progress?

Note: the first part of this article is a bit of an opinionated rant – if you want to skip to the actual code examples a little further down and make up your own mind, that’s fine by me.

A Bit of History

One of the best new features to appear in .NET recently has been LINQ (language integrated query) – and particularly, LINQ-to-SQL. This marvellous bit of the framework lets you define a mapping between database and objects (or more likely, automatically generate the mapping from a database schema), and then query and update the database in a type-safe manner, using syntax that nicely bridges the gap between C# and SQL.

Unfortunately, LINQ-to-SQL was a bit of a skunkworks project – while hyped projects such as ObjectSpaces and WinFS collapsed under their own weight, LINQ to SQL quietly delivered.

Clearly for political reasons this successful ORM project had to be stopped, and fast. (Nice article here).

So enter LINQ-to-Entities – the ADO.NET team’s “answer” to LINQ-to-SQL. Unfortunately, while LINQ-to-SQL was a wonderful, polished jewel of functionality that was a nice example of IJW (“it just worked”), LINQ-to-Entities seems to be a product of Architecture Astronauts who would rather bamboozle us with their cleverness than actually provide useful solutions.

Enough Ranting – Some Examples

I’ve written a small handful of applications using LINQ-to-SQL, so when I found that LINQ-to-Entities was its replacement, I thought I’d start my next application experiment using it. I’m going to include the source for these examples in a little test application at the end of this article, if you’d like to try it for yourself. I’ve used identical code for both LINQ-to-SQL and LINQ-to-Entities, with minor changes for logging and creation of the entity model. Both schemas were imported from the same database.

The Schema

The schema contains just two tables, joined by a single foreign key relationship:

Problem #1 – Silently Gives Differing Results

This problem is to my mind the worst that I’ve found so far.

Suppose I search for a customer:

var alice = data.Customers.First( c => c.Name == "Alice" );

Fine, that works nicely. Now let’s see if I can find one of her orders:

var order = ( from o in alice.Orders
              where o.Item == "Item_Name"
              select o ).FirstOrDefault();

LINQ-to-SQL will find the child row. LINQ-to-Entities will silently return nothing.

Now let’s suppose I iterate through all orders in the database:

foreach( var order in data.Orders )
{
  Console.WriteLine( "Order: " + order.Item );
}

And now repeat my search:

var order = ( from o in alice.Orders
              where o.Item == "Item_Name"
              select o ).FirstOrDefault();

Wow! LINQ-to-Entities is suddenly telling me the child object exists, despite telling me earlier that it didn’t!

Let me put that in bigger letters in case you missed the significance:

LINQ-to-Entities will return different results depending on what previous queries you’ve executed!

That’s hardly a transparent mapping between database and objects.

Problem #2 – No Support for Constant-Folding

Consider the following code:

using( var data = new LinqToEntities() )
{
  var names = new[] { "Alice", "Bob", "Dummy" };

  for( var i = 0; i < names.Length; ++i )
  {
    var customers = from c in data.Customers
                    where c.Name == names[i]
                    select c;

    // Do something with the customers found.
  }
}

LINQ-to-SQL handles this fine, treating names[i] as a constant expression. LINQ-to-Entities fails with:

“The LINQ expression node type ‘ArrayIndex’ is not supported in LINQ to Entities.”

Problem #3 – No support for Single() or SingleOrDefault()

LINQ-to-SQL supported a nice method of ‘asserting’ that you were expecting zero or one results – for example if querying against a key:

var customer = ( from c in data.Customers
                 where c.Name == "Alice"
                 select c ).SingleOrDefault();

LINQ-to-Entities however says:

“The method ‘Single’ is not supported by LINQ to Entities. Consider using the method ‘First’ instead.”

But First() doesn’t express what I want – namely that more than one result is a logical error.

Problem #4 – Exceptions

The final problem I’ve noticed is that LINQ-to-Entities throws and catches exceptions internally. Just running the test application with exceptions turned on throws multiple exceptions:

A first chance exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll

Additional information: Could not find file
'C:\<snip>\bin\Debug\System.Data.Resources.CodeGenerationSchema.xsd'.

and

A first chance exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll

Additional information: Could not find file
'C:\<snip>\bin\Debug\System.Data.Resources.EntityStoreSchemaGenerator.xsd'.

I now have the choice between turning off exceptions (thus hampering my own debugging), or having to press ‘continue’ several times. I guess they hadn’t heard of File.Exists().

Bonus #1 – Refresh From Database

OK, I’ve been a little mean to LINQ-to-Entities. Surely it has some good points?

From my perspective, there is just one feature that I like over LINQ-to-SQL. (I know it supports many-to-many mappings of tables and classes. Seriously, what tiny percentage of users would want to do that?). The designer in LINQ-to-Entities allows you to refresh your mappings from database changes, whereas LINQ-to-SQL forces you to either make the changes manually, or delete everything and re-import.

However, that’s a designer feature. Couldn’t we have had that for LINQ-to-SQL as well?

Source Code

If you’d like to try these examples out for yourself, I’ve included an ZIP file. You’ll need Visual Studio 2008 SP1, and MS SQL Server 2005 or later.

The ZIP file contains a create database script you’ll need to run, which creates a database called ‘LinqTest’ and populates it with a few rows of data.

Download “linqtest.zip”, 14Kb.

Conclusion

In my opinion, we seem to have given up on a perfectly good, working ORM solution (LINQ-to-SQL), and replaced it with a buggy, half-baked one (LINQ-to-Entities). I sure hope v2 improves matters, because for now, switching to the entity framework is a downgrade.

Instead of ray-tracing every single pixel, we instead start by tracing pixels in an evenly-spaced grid, say every two or four pixels. (So if we have an interpolation step of two, we trace one out of every four pixels, and if we have an interpolation step of four, we trace one out of every sixteen pixels).

The image on the left above represents the pixels that would be traced with an interpolation step of two; the image on the right, an interpolation step of four.

Once we’ve performed this initial trace, we then examine each square region formed by the grid of traced pixels. For each square region, there are two cases to consider:

1. The four corner colors are roughly the same;
2. The four corner colors differ.

Based on these two cases, we take one of two actions:

1. If the four corner colors are roughly the same, we can save time by interpolating (estimating) the colors for the remaining pixels from the four corners.
2. If the corner colors differ, then we need to trace the rest of the pixels in the square region normally.

(Alternatively for option two and a large interpolation step, we could subdivide the square and apply the same algorithm with a halved interpolation step).

(As an added bonus, if we want to anti-alias the scene, we only need to anti-alias the pixels in a square that we aren’t interpolating).

As an example, I’ve added debug code to display the interpolated pixels as green in my usual shiny-spheres-on-a-chessboard scene; interpolate step of two above, interpolate step of four below:

So what sort of speed-ups have I seen? Well, I haven’t put much effort into optimizing my interpolation algorithm, since I’m moving onto radiosity, but here’s some numbers:

• No interpolation: 360ms
• Interpolation of two: 200ms
• Interpolation of four: 230ms
• Interpolation of eight: 310ms

As you can see, there’s an optimal interpolation step, in this case, of two. As the interpolation step increases, it becomes more likely that the colors at the corner of each square will differ, and so less interpolation will happen. Higher interpolation steps are also more likely to introduce artifacts into the image.

As I mentioned at the start, this technique does trade off image quality for speed. In the images below, the upper image is properly traced; the lower one has been interpolated with a step of two. You will be able to see some blurring of the reflection of the chessboard in the spheres.

Anti-aliasing is a technique to remove the “jaggies” in a rendered image. Let’s start with the standard shiny-balls-on-a-chessboard:

I’ve zoomed into the image a little, so that you can see the pixellated edges.

Anti-aliasing is most simply achieved by multi-sampling each pixel. Instead of casting one ray through the center of each pixel, you cast several rays (say around four), distributed within the pixel area. (You might want to distribute them in a grid, or you might want to distribute them randomly). We then take the average color value of each of those tracings.

Obviously however, this is going to slow down rendering – if I use 4x anti-aliasing, then the render will take four times as long. Not good. I can be a bit smarter about it though.

Looking at the image above, it’s only really the edges that are “jaggy” and need anti-aliasing. Everywhere else could be left alone really. So rather than tracing multiple rays through every single pixel, I just need to identify the edges. This is really easy and fast. Assuming I have a (non anti-aliased) rendered image, I can compute an “edge factor” for a single pixel as follows:

var g = Math.Abs( ( p1 + 2 * p2 + p3 ) - ( p7 + 2 * p8 + p9 ) )
      + Math.Abs( ( p3 + 2 * p6 + p9 ) - ( p1 + 2 * p4 + p7 ) );

Where p1..p9 are the pixel values around the pixel in question – p1 is above and to the left, p5 is the pixel itself, and p9 is below and to the right. (I perform this calculation on the intensity of the pixels, to avoid having to deal with RGB values).

[This is the "Sobel operator" - there are other faster edge detection operators, but this one seemed to work nicely for me.]

If g is bigger that some value (say 0.5), we consider the pixel to be part of an edge. In the following image, I’ve displayed the edges in red:

(Of course, in normal use you’d actually save the edge flags into a separate store, rather than overwriting your rendered image, but I’ve done this here for debugging).

So now, wherever I’ve detected an edge pixel in my status buffer, I cast a further four rays through it, and average them with the single ray I’ve already done prior to edge-detection:

I find that I can achieve 5x anti-aliasing for just a doubling in render time.

• Those which speed up the ray-tracing, without affecting the image;
• Those which speed up the ray-tracing, but degrade the image quality, and;
• Those which improve the image quality, but slow down the ray-tracing.

Obviously implementing the first set of optimizations is a no-brainer, but which blend of the others is of course up to you.

So let’s start with the most effective speed-up: multi-threading. Rendering each pixel in the image happens pretty much independently of the others, so we can partition the rendering amongst the available processors (or cores).

One naive way of partitioning the scene is to simply divide it into N parts, assuming we have N processors. This however doesn’t necessarily make best use of the processors: if one of those partitions has less complexity than the others, then that processor will be idle for most of the render.

In this example, we’ve partitioned the rendering of a scene amongst four processors, but the first slice will finish way before all the others, since it contains nothing but background colour. Slice three will probably finish last. Essentially, we have a very uneven usage of our CPUs.

A better way to use the available processors is to divide the rendering into many more parts than we have processors, and put them in a work queue. Each processor can then pop a piece of work from the queue every time it’s ready. When the queue is empty and all processors are done, then the rendering is complete. This method makes far better use of the available CPU power.

In fact, we can be even more cunning with our division of the scene. Suppose we divide the scene displayed here into a grid. Each grid line corresponds to a plane passing through the camera. (If you have trouble with that idea, consider the edges of your monitor: you can imagine triangles with points at your eye, and two points on the corner of the monitor).

We can work out which spheres (yes, those coloured circles are supposed to be spheres) intersect each column (left to right):

• Red;
• Red, Green, and Blue;
• Red (just), Green, and Blue;
• Blue.

Similarly, we can work out which spheres intersect each row (top to bottom):

• Green;
• Green and Blue;
• Red, Green (just) and Blue;
• Red and Blue.

(See last article for a selection of intersection tests).

[To speed up this pre-processing stage, I used a binary chop algorithm - repeatedly partitioning the scene into two sets of objects.]

Once we’ve performed this pre-processing, we can make use of this information to speed up the actual processing. When rendering each part, the primary ray intersection test only needs to consider those objects which are in the intersection of the appropriate row and column sets.

As an example, consider the top-left part. The row contains the green sphere; the column the red sphere. We can therefore see that the area doesn’t contain any objects – so there’s no point rendering each pixel – we just fill it with background.

For parts that do contain one or more objects, we can speed up primary ray intersection testing by only testing against the identified objects – we don’t need to test against every object in the scene.

(Please note that these algorithms most definitely aren’t my work: I’ve adapted most of them from “Real-Time Rendering“).

So here we go: a variety of intersection methods, implemented in C#.

Intersection Constructor

The intersection tests return either an intersection object, if the ray intersects the object, or null, if not. The constructor of the intersection class has the following form:

public Intersection( Vector position, Vector normal, double t )

The plane tests given determine whether the object is completely on one side of the given plane, completely on the other side, or whether the plane passes through the object. Planes are represented as a point on the surface, and the surface normal.

Ray-Sphere Intersection

public override Base.Intersection Intersect( Base.Ray ray )
{
  var el = _center - ray.Start;
  var d = Base.Vector.Dot( el, ray.Vector );
  var els = Base.Vector.Dot( el, el );
  var rs = _radius * _radius;

  if( d < 0 && els > rs )
  {
    return null;
  }

  var ms = els - d * d;

  if( ms > rs )
  {
    return null;
  }

  var q = Math.Sqrt( rs - ms );
  double t;

  if( els > rs )
  {
    t = d - q;
  }
  else
  {
    t = d + q;
  }

  var p = ray.Start + ray.Vector * t;

  return new Base.Intersection( p, ( p - _center ).Normalize(), t );
}

Ray-Triangle Intersection

Note that _epsilon is somee small number, say 0.00001. _p0, _p1, and _p2 are the three vertices of the triangle.

public override Base.Intersection Intersect( Base.Ray ray )
{
  var e1 = _p1 - _p0;
  var e2 = _p2 - _p0;
  var p = Base.Vector.Cross( ray.Vector, e2 );
  var a = Base.Vector.Dot( e1, p );

  if( a > -_epsilon && a < _epsilon )
  {
    return null;
  }

  var f = 1 / a;
  var s = ray.Start - _p0;
  var u = f * Base.Vector.Dot( s, p );

  if( u < 0 || u > 1 )
  {
    return null;
  }

  var q = Base.Vector.Cross( s, e1 );
  var v = f * Base.Vector.Dot( ray.Vector, q );

  if( v < 0 || u + v > 1 )
  {
    return null;
  }

  var t = f * Base.Vector.Dot( e2, q );

  if( t < 0 )
  {
    return null;
  }

  var position = ray.Start + ray.Vector * t;

  return new Base.Intersection( position, _normal, t );
}

Plane-Sphere Test

public override Base.PlaneSide GetPlaneSide( Base.Plane plane )
{
  var p = _center - plane.Point;
  var distance = Base.Vector.Dot( p, plane.Normal );

  if( distance > _radius )
  {
    return Base.PlaneSide.NormalSide;
  }
  else if( distance < -_radius )
  {
    return Base.PlaneSide.OtherSide;
  }
  else
  {
    return Base.PlaneSide.Intersects;
  }
}

Plane-Triangle Test

public override Base.PlaneSide GetPlaneSide( Base.Plane plane )
{
  var p0 = _p0 - plane.Point;
  var d0 = Base.Vector.Dot( p0, plane.Normal );
  var p1 = _p1 - plane.Point;
  var d1 = Base.Vector.Dot( p1, plane.Normal );
  var p2 = _p2 - plane.Point;
  var d2 = Base.Vector.Dot( p2, plane.Normal );

  if( d0 > 0 && d1 > 0 && d2 > 0 )
  {
    return Base.PlaneSide.NormalSide;
  }
  else if( d0 < 0 && d1 < 0 && d2 < 0 )
  {
    return Base.PlaneSide.OtherSide;
  }
  else
  {
    return Base.PlaneSide.Intersects;
  }
}

Calculating the colour of a reflective surface is (usually) a recursive process – a secondary ray is cast from the reflective surface, and used to calculate the contribution to the primary colour. Of course, if the secondary ray hits a reflective surface, another ray will be fired, and so forth… so a limit of some kind is usually applied to this process, to end any potentially endless recursion.

Let’s hope the above image makes things clearer. On the left is the camera/eye, casting a primary ray (marked “1″) which intersects a reflective sphere. (We can see that the colour of the pixel should be green).

Since the surface is reflective, we  recursively cast a secondary ray (marked “2″) at a vector that is the reflection of the primary ray against the surface (calculated against the intersection normal, “N”).

This secondary ray intersects another object (the green sphere), and here we calculate the colour as usual based on the lighting calculations.

Since the final object wasn’t reflective, the recursion ends, and the pixel is assigned the colour calculated via the secondary ray.

Here’s my code for a reflective material:

public sealed class ReflectiveMaterial : Material
{
  public ReflectiveMaterial( double reflectivity, Material material )
  {
    _reflectivity = reflectivity;
    _material = material;
  }

  public override Base.Color GetColor( Scene.Scene scene, Base.Intersection intersection, int depth )
  {
    var surfaceColor = _material.GetColor( scene, intersection, depth );
    var reflectColor = scene.BackgroundColor;

    if( depth < 3 )
    {
      var c1 = -Base.Vector.Dot( intersection.Normal, intersection.Ray.Vector );
      var r1 = intersection.Ray.Vector + ( intersection.Normal * 2 * c1 );
      var reflectRay = new Base.Ray( intersection.Position, r1 );

      var reflectIntersection = scene.GetIntersection( reflectRay, intersection.Primitive );

      if( reflectIntersection != null )
      {
        reflectColor = Tracing.Tracer.TraceRay( reflectIntersection, scene, depth + 1 );
      }
    }

    return surfaceColor * ( 1 - _reflectivity ) + reflectColor * _reflectivity;
  }

  private double _reflectivity;
  private Material _material;
}