How does Cycles work and how is it different from Blender Internal?
Which is better?
Cycles is an unbiased, physically based, path tracing engine designed for animations, which means that it produces an image by tracing the paths of "rays" through the scene.
Specifically, cycles is a "backwards" path tracer, which means that it traces light rays by sending them from the camera instead of sending them from light source(s).
Path tracing is a computer graphics method of rendering images of three dimensional scenes such that the global illumination is faithful to reality. Fundamentally, the algorithm is integrating over all the illuminance arriving to a single point on the surface of an object. This illuminance is then reduced by a surface reflectance function to determine how much of it will go towards the viewpoint camera. This integration procedure is repeated for every pixel in the output image. When combined with physically accurate models of surfaces, accurate models of real light sources (light bulbs), and optically-correct cameras, path tracing can produce still images that are indistinguishable from photographs.
Path tracing naturally simulates many effects that have to be specifically added to other methods (conventional ray tracing or scanline rendering), such as soft shadows, depth of field, motion blur, caustics, ambient occlusion, and indirect lighting. Implementation of a renderer including these effects is correspondingly simpler.
Due to its accuracy and unbiased nature, path tracing is used to generate reference images when testing the quality of other rendering algorithms. In order to get high quality images from path tracing, a large number of rays must be traced to avoid visible noisy artifacts.
To visualize this, take the following image:
The pixel the gray ray was sent from will be dark, as it did not encounter any light sources. The pixel from which the orange ray was sent will be bright, as it hit a light source after bouncing off a diffuse object.
Most materials scatter light, so Cycles needs to account for light bouncing in different directions. How this is done depends on which Integrator is used.
When using the Progressive integrator, this is done by taking multiple samples of the scene. A sample refers to a single ray being sent from each pixel. For materials that scatter light, many samples are required to account for every possible angle at which a ray could be reflected/transmitted.
The Branched path integrator splits the ray at the first bounce.
To visualize this, take the following animation:
For more information on the mechanics of cycles, see the following questions:
BI is a biased rasterization engine, which means that it works by calculating which objects are visible to the camera and not by simulating the behavior of light.
Neither engine is necessarily "better", they both have strengths and weakness.
To visualize some of the differences between BI and Cycles, take the following example inspired by Mike Pan's shaped bokeh demonstration:
In cycles this works because cycles is actually simulating light, so you will get a result similar to what you would get in the real world:
In BI however, this does not work because the plane is calculated as "visible", and then everything behind it is obscured:
There are many more differences between cycles and BI, such as caustics:
Cycles can render caustics, however due to its backwards path tracing nature, rendering caustics under some conditions can be hard to the point of practically impossible. There are algorithms such as Bidirectional path tracing and Metropolis Light Transport (MLT) that are good at rendering caustics, unfortunately there are no plans to implement these in cycles anytime soon.
Update: There is now a working patch for metropolis sampling, which also includes working adaptive sampling and stopping for the existing path tracing integrator. There are also plans to add lightgroups and PIS to the same patch.
BI cannot render caustics, however there is a workaround.
This does not necessarily make cycles "better", for instance BI usually renders noiseless images while cycles must sample a scene many times to reduce the noise to an acceptable level.
Both rendering engines have different advantages, which one is best depends on what you want.
One thing to keep in mind is that each render engine is fundamentally different and so are its settings and most importantly its material and texture definitions. As such you can't render Cycles materials in Blender internal, and the opposite is also true.
Materials designed for one render engine will mostly only work for that one render engine they were created for. You have to stick with your choice, if you created a scene for Cycles you must always render it in Cycles, and vice versa; you can't just switch at will and expect things to work. At least, not without recreating all of your materials.
Check the active render engine in the header of the Window. The currently active render engine at any moment will determine which type of materials is created when you press the + button to add a new one.
Cycles usually produces more photo-realistic renders while Blender Internal is faster. If you're test-rendering a model to see how it looks rendered, I suggest Blender Internal, while I would use Cycles for final animations.