Raytracing: A (Very) Brief Introduction
I’ve recently started writing a basic ray tracer, and thought I’d write a bit about how they work.
The basic idea of ray tracing is to generate a 2D image (or series of images) from a 3D scene by simulating how rays of light travel.
One important difference here is that instead of simulating rays cast from a light source and eventually hitting the eye/camera, a ray tracer will generally cast rays backwards from the eye, taking information from light sources at the end. This means we don’t have to simulate all the rays coming from each light source, most of which we don’t see (i.e. they don’t hit the eye).
Rays are cast from the eye though a plane, which represents our render target, with one ray for each pixel of the render target.
The ray tracer then determines the (nearest) intersection of the ray with the scene geometry. From here we can cast secondary rays to simulate reflection, refraction, etc. Also rays can be cast directly to the light sources in the scene. These rays (which may in turn spawn other rays) are all combined to give a colour for the ray. This colour is then applied to the pixel that the ray was cast through.
That just about covers my basic introduction. I intend to write a few more articles on this, the next of which will probably cover how to determine intersections between rays and geometry. Bring your maths hats.
29 Jan 2008 13:24
| 
Tags: Raytracing
| 
Comments (20)
| 
Report a problem
Loading…
20 comments by 5 or more people
[Skip to the latest comment]Steven Carpenter
Yay!
Boo!
29 Jan 2008, 13:43
Mathew Mannion
So you’re writing this in Python, right?
29 Jan 2008, 14:35
Don’t worry, my maths hat was rather dusty to say the least :-)
and none of this new fangled rubbish. C++ all the way :-) I was intending to just go through some of the techniques (without code), but I’ll see how it goes.
29 Jan 2008, 14:52
Le Ray
No.. You. Can’t. Teach. Me….Things. Damn.
Sounds inneresting, though I think my maths hat was lost in the back of a cupboard when I was about 11.
29 Jan 2008, 15:06
John Dale
Takes me way back. In I guess 1988 or so, I did two games entirely with ray-traced graphics; E-Motion and Vaxine. There was, as I recollect, no compelling reason to do a game using such graphics, but having painfully groped our way to ray-tracing – gasp – spheres and pipes, we were so enamoured of them that we were determined to shoehorn them into a game somehow.
29 Jan 2008, 19:38
You’ll have to forgive me
:P
29 Jan 2008, 19:44
So all this stuff I’ve been reading about real-time ray-tracing being on the horizon is rubbish – it was done 20 years ago :-) I didn’t know anyone had done that before…
29 Jan 2008, 21:12
John Dale
Ah, no, your reading is true. There was nothing even slightly real-time about what we did; the rendering ran overnight to give us the ray-traced look we were so infatuated with, but the game just used the rendered graphics as regular sprites. Sorry!
(Having been reminded of the existence of those games, I had a quick poke around and was tickled to discover that someone’s done a pixel-perfect Windows version of E-Motion if you’re interested.)
29 Jan 2008, 22:45
I just had a quick go, I’m not very good at it – managed to get to level 6 after 4 or 5 attempts :-(
For a moment there I thought I recognised someone…
E-Motion title screen
Warwick Blogs’ very own mad prof
30 Jan 2008, 00:20
Mathew Mannion
Our secret plans to subconsciously make everyone buy all of John’s old games and live off the royalties are rumbled!
30 Jan 2008, 00:43
Andrew Ingram
Crikey, it’s the same actual photo. Just how long had John been planning Warwick Blogs for?
30 Jan 2008, 01:01
Mathew Mannion
High score hax!!!
30 Jan 2008, 01:07
John Dale
Um, yeah. Back to that ray tracing now, maybe? Tell us more about the intersections between rays and geometry…
30 Jan 2008, 07:10
Andrew Ingram
Yes, tell us about the intersections Nick, tell us.
30 Jan 2008, 08:32
Mathew Mannion
To get back on-topic, how does ray tracing work programmaticly in practice? I’m guessing that even if the processing power is getting to the stage where you can calculate every pixel in real time, what are the tricks to make it go faster? (i.e. to stop performance grinding to a halt with the increased resolutions people are using as monitor sizes get bigger and bigger)
30 Jan 2008, 08:55
One of the main steps in making a ray tracer go faster is the scene management. E.G. at the moment my crude ray tracer has a list of primitives, and checking for the closest intersection means looping through all them. If I want this to scale to a decent number of primitives then I’ll have to organise them better. You can organise them better by using various data structures including KD Trees, Binary Space Partitioning or Bounding Volume Hierarchies.
Another way to make a ray-tracer faster is to make use of the increasing parallelism available on CPUs or GPUs. As we’re tracing a ray for each pixel, it’s pretty easy to split the problem across cores.
Intersection will come soon, possibly tomorrow :-)
31 Jan 2008, 01:50
Oh man, this is going to be such a great series of posts. That first one is really clearly explained, I’m well keen for the rest.
I don’t care if I need my Maths hat on. I have a Maths degree and teach the subject full time. BRING IT.
31 Jan 2008, 22:35
Argh – people who can do maths without the aid of a hat!
Seriously though, I’ve got half of the next article written – It will be up as soon as I’m not too drunk to finish it :-)
01 Feb 2008, 03:29
Nick Howes
Hooray for raytracing! Let me know if you want any funky diagrams explaining rays bouncing off shit and stuff. I could render them. A raytraced image showing the act of raytracing!
01 Feb 2008, 13:28
The mind boggles :-)
01 Feb 2008, 15:17
Add a comment
You are not allowed to comment on this entry as it has restricted commenting permissions.