Joe's Honours Project

The End is Nigh!

2009-05-14T16:10:00.002+01:00

I've not done any coding since the last update. I managed to sensibly draw that part of the project to a close and have been really concentrating on the dissertation.

I'm in the final stages and as it stands I'm around 7000 words and 59 pages through into a fully formatted dissertation with all the trimmings (front page, abstract, foreword, contents, main body text, references and bibliography, appendices) with only the following sections to complete:

Table of figures
Overview/Layout
Conclusion/Future work

So I'm probably looking at around 8000 words and 61 pages total. Hoping to print on Sunday night/Monday morning (a few days from now) and bind on Monday. Perhaps hand it in or take it home and stroke for a couple of days before I do so.

I'm pretty pleased anyway, I'm actually surprised that I've managed to keep my project organised and I'm not finding myself here panicking with only a literature review written or something, which is more than i can say for some people. I'm relatively stress free.. although looking forward to getting to enjoy the sun again and actually spend time with my girlfriend/friends.

Dissertation is with my dad for review at the moment. Will keep pushing for the rest of the time I have. Its not over yet :)

Update

2009-04-24T20:45:00.002+01:00

Woah! Looks like i havent updated in a while.. I've been getting on with my dissertation and other courseworks.

About half way through the dissertation now, looking to pick up speed.

As for the application: i managed to get a 1.4x speed increase by just using a different compiler! (intel c++) and a few tweaks here and there. Nothing major, i'm pretty happy with it. I've also noticed in simple scenes a super-linear speedup. For example, in the "two spheres" scene posted most often on this website, with one core running it, i can get about 15.1fps. Using 4 cores yields just over 70fps. a 4.66x speed increase! This is due to the "cache effect". My program utilises the cache super efficiently in the tiled rendering mode. so it has that performance improvement as well as the pure calculation speed increase.

XML parsing

2009-03-27T19:23:00.002Z

I've added the ability for my program to parse XML files as it builds. All application settings are contained in this file (technical settings, ray tracer properties, scene information etc..) so now i need not re-compile the project everytime I want to change a setting or the scene. Very handy! This was done using an Open source C++ XML parsing library called TinyXML. Its really very good.

I've also added a ray counter. A bit tricky because of thread specific storage and synchronisation to be dealt with at the end but its up and running. I won't bother posting a screen shot because its not really that exciting.

I've a couple of other little bugs to fix in the program but its all definetly coming to a halt, i've not done any work on it for a ew days actually.

I've been writing my dissertaition! So far I have about a thousand words written down in the introduction, objectives and background section. will aim to have 2000 - 2500 down by the end of the weekend.

2009-03-19T19:38:00.001Z

I've got the tile based approach of rendering up and running. I'm able to state how many thread i want it to use (like the split screen camera), and what size tiles i want to be rendered at a time for full flexibility. the tiles must be a number that the resolution of the screen can be divided by though. ie, for a 400*400 display, a tile can either be 1x1, 2x2, 4x4, 8x8, 16x16, 20x20, 40x40 and so on. I find that i get the best results from about 16x16 square tiles.

To make the concept of all this easier to see, I've added in a switch that turns a thread visualistation on. Here is a scene using one thread, with and without visualisation:

The red colour shows that thread one is doing the work on those pixels. Since threre is only one thread, all we can see is the red.

Introducing the splitscreen rendering method now:

We can see that four threads (red, blue, green and yellow) are working on their own portions of the screen.

Now heres the latest update, the tile based rendering approach, using 16x16 tiles:

We're able to see a very pretty map of work distribution between each thread.

On top of this, I'm able to report a few results that I'm happy with:

using those above, we not that one thread is able to render 2.7384 frames per second while the split screen method with four threads achieves 8.1917fps - a 2.991x speed increase.

The tiled approach however achieves 10.8726 frames per second - a 3.97x increase!

Showing that ray tracing can scale very NEARLY linearly with N numbers of cores. ie framerate = O(N*0.9926), according to the tile based approach.

In other news, I've started writing my dissertion and so far have a plan laid out and notes for each heading, detailing what each section should contain and hopefully these notes will give me a boost over the "where do I start" syndrome.

So I'm ahead in code but behind in writing. That may change this weekend.

Goals now? Continue writing.. get stuck into that, but also build into my ray tracer the ability to parse scene files, so i don't have to recompile the thing each time I want to run tests on a scene.

Oh and benchmark functionality might be nice (ie. run n number of cycles on the same scene using each render method, record the results and analyse accordingly.)

I've emailed Andy Sapeluk about using this PS3 Cluster. It might be too late now for anything to come of it but i still want to get my hands dirty!

2009-03-07T09:39:00.002Z

Heres a dragon model consisting of about 47k triangles

The same dragon, this time with 1.13 million triangles:

the same 1.13 million triangles, with 16 samples per pixel and 25*16 samples for AO per pixel:

Models! .Obj file parser and loader sculpted from lex and yacc.

2009-03-04T14:53:00.002Z

A lot of ray tracer use the .ply model format to load in meshes because its easy to use, since Greg Turk already wrote ply loading libraries back in the 90s, working with the stanford scanning repository. This why typically you only see the same scenes in ray tracers (who else is getting tired of the stanford bunny?) So I decided to write my very own Obj file parser using lex and yacc (yet another compiler compiler). Since the Obj file is an open text based format, it wasn't too hard to do. Although I did have (well, i was being a bit lazy) to tailor the parser specifically for the way milkshape exports .obj files, since so many exporters write the files in different ways (most leave out data, which is no good!) milkshap is kind, since if the model doesn't have texture co-ordinate data, it'll just stick one co-ord into the file and lets me not have to worry about checking for this kind of inconvenience. Anyway. Its done.. I'm a little annoyed though because milkshape can't handle models over about 50k triangles... so i can't test some amazing looking millions of triangle models in my ray tracer.

Currently the ray tracer doesn't support textures, groups and different materials per group.. so we'll just call them sculptures. ;) Nor anything but triangles...

There are a few screenshots below of a house and a helicopter. The helicopter is made of 4536 vertices and 4748 triangles and the house is 34075 vertices and 27545 triangles.

Each shot is 720p and for each model there is 2 renders using 4 samples per pixel, ambient occlusion (i think its about 144 samples per pixel), shadows and either a matte finish or reflective surface. The third of each set is a "real time" rendering at 1 sample per pixel and no AO. Click on them for larger.

:)

2009-02-23T18:37:00.000Z

Regular Grids

2009-02-23T00:18:00.004Z

I've implemented a spatial subdivision algorithm: Regular grids. Basically this is a grid of axis aligned boxes, all the same size, with each grid having a pointer to each object stored inside the box. The grid is traversed box by box and any intersection tests are made along the wat. once an objectis hit, the grid traversal stops. I can now render many objects in one scene with a minimal drop in framerate. the rendering time used to vary linearly with the number of objects in the scene, now the render time of a frame is denoted as a function of log(n), where n is the number of objects in the scene. Heres a nice picture showing depth of field with 100 matte spheres, rendered with 4 threads:

A scene showing 10,000 spheres all casting shadows and all reflective, with 3 levels of reflection:

And zoomed in:

It'll run about 20% faster using ten threads instead of four too!

Next step: Triangle meshes.

Just for fun

2009-02-17T20:45:00.003Z

A nice render of two matte spheres and a plane with depth of field.

Specs

1024x720 (720p)
9 Jittered Samples per pixel (9 primary rays per pixel)
36 shadow rays per primary ray intersection for ambient occlusion (324 pp)
One point light casting shadows.
Depth of field (144 Jittered samples per pixel) done as post process

click on it for a larger image.

Depth of field - for free!

2009-02-17T13:23:00.005Z

I realised that since I'm using an RGBA texture to render to (directx for some reason doesnt like RGB dynamic textures), i had a completely unused alpha channel. So I figured i could output the average length of ray per pixel into this channel to store the depth of the pixel in the scene - and then apply a depth based shader to the texture in directx. I've chosen depth of field because this is pretty expensive to model in ray tracing as it involves even more samples per pixel. Using the alpha channel of the texture to store scene depth for each pixel, i could quite easily assess how far this pixel was away from the focal plane and blur it accordingly. I used this paper from ATI and modified it to suit the ray tracer. Oh and I changed it to pixel shader 3.0 because 2.0 is a joke and doesnt allow you many calculations at all. Using 3.0, I've been able to increase the number of samples used for blurring from 12 to 144, giving a much nicer result. Its not really perfect and no-where near as nice as ray traced depth of field would be, but I can't argue with a 0% drop in framerate for the effect.

I've got some issues to sort out with it yet.. like bleeding of shard edges. That green sphere should be sharp, its reflections are the thing that is blurred. Shouldnt be too hard a fix though I'd imagine. Its looking good though! I'm especially suprised at the quality of blurring I'm able to achieve in a pixel shader in real time.

Here is what the scene looks like showing how much each pixel is blurred (white for full, black for none)

Multithreading

2009-02-17T13:02:00.006Z

I've succeeded in setting up a multithreaded version of the ray tracer, using a simple and naive split screen method. It took me a while to figure out some static data was making the whole thing very unsafe and slow but thats all now been sorted using thread local storage. I've had to take the ray counter out due to technical difficulties but i'll get that back in soon.

I'm getting the results I expected though: on one core the scene is capable of 18fps and using 4 cores it is achieving 50fps (~2.5x speed up). 4x in best case scenario. The reason? in parts of the screen the ray tracer has more work to do might be mostly assigned to one thread, leaving the other threads waiting for that one to finish at the end of the frame. Anyway as proof: here is out favourite test scene (400x400, 1spp, 2 spheres with 3 levels of reflections, one matte plane and no AO):

1 thread (one core):

4 threads (4 cores):

As you can see, thats a pretty significant increase in speed! Ambient occlusion still kills it though - with 36 samples per intersection for AO:

The images might look a little more zoomed out than all the previous examples. Well I realised i was rendering stuff outside of the directx window too, so i've fixed that and now the generated texture from the ray tracer goes right to the edge of the window.

CUDA, SSE SCOPS3 and Wald, I

2009-01-25T00:42:00.003Z

I've been doing a lot of reading lately trying to decide where my honours project is going other than the base multithreading work. If i can I'd like to do extra. And here are the options:

CUDA: GPGPU (general purpose graphics processing unit) programs can now be written to take advantage of all cores on graphics devices and NVIDIA has provided the tool to do this: CUDA. basically massively parralell problems (like ray tracing) can be offloaded to the GPU to carry out, yeilding big performance gains over standard intel multi-core CPUs. A ray tracer could therefore be written to take advantage of this power, rendering a pixel at a time, say, on one of the available cores.
SIMD, and in paticular, Intel's SSE insturction set, as it is almost become a standard for many processors (AMD chips are now supporting SSE as well as their own 3DNow!). SIMD or "simmed" stands for Single Instruction, Multiple Data and basically does what it says on the tin. Most modern processors are really good at floating point maths and come with special 128bit wide registers that allow you to carry out the same calculation on four floats (or 8 ints) at once. Which can come in handy in ray tracing
SCOPS3. Scientific Computing On the Playstation 3. A PS3 has 6 very powerful cell proccessors in it. Abertay has 6 Ps3s joined together in a cluster. So of course I want to play with it.

Ok so first of all; CUDA. I'm dismissing it. I took a really good look at it today and while its pretty awesome, its caused me a lot of stress. It took me a couple of hours alone to figure out how to get a Cuda project set up in visual studio and then to write a very simple program that just transfers memory to the graphics card, does a really simple calculation on it, and then transfers the memory back to the CPU. I thought it would be nice to port my ray tracer into a cuda project and tell the graphics card which bits i wanted it to take over at, maybe change a few thigns here and there but no, if you want to write a ray tracer for CUDA, it has to be done in C. And since my project is nicely object oriented, this isn't happening. Its too much work for something that would be "just a bit of fun". No, I'll just talk about it in my dissertation instead.

Something else that might be a decent amount of work is using SIMD to improve performance of my ray tracer, although i want to have a really good bash at it. Why? it's something that has existed for a long time now and I've personally never used it and frankly, I'm a little bit confused as to why we've not been taught about it in Uni. Anyway, given this utility, it is possible to speed up the performance of a ray tracer. I've already tried to convert some of my maths libraries into using SSE operations with negative reults. Its turns out using the operations for one off calculations is actually slower than not. Looking at this article, the best way to do it is by tracing packets of 4 rays at a time. I found a 311 page PhD thesis by Ingo Wald - the king of interactive ray tracing - on interactive ray tracing. In it, he describes how best to use SIMD in a ray tracer.

So I've already started stripping down my ray tracer and rebuilding a packet tracer, a architecture that will build packets of rays instead of single rays at a time, at the same cost. Hopeully i'll be able to get over double the performance out of my ray tracer if implemented well. This leads me neatly into SCOPS3.

The Cell proccessor is impressive really only when using SIMD (i guess in the same way as any intel CPU these days). Therefore, in order to make trying to use Abertay's PS3 Super computer worthwhile, i need to be able to efficently program it. Its a distant vison, but a beautiful one. Of course I could just port my current ray tracer onto it as it is and not use SIMD and it'll still run mega fast. Either way I do want to play around with it. I need to email someone to sort this out..

Honours Project Presentation

2009-01-23T15:58:00.004Z

As a quick "for the record" I'm going to post the slides I used to present my honours project ideas:

Speed increase!

2009-01-23T15:30:00.004Z

This week I've managed to get a decent speed increase from the ray tracer by:

Increasing the efficiency of the ray-sphere intersection algorithm and
Turning all my utility classes (maths libraries and shading record classes etc..) and classes that are accessed a lot into fully public classes. I know its against "the rules" but even with the private version using inlined accessors to get member data, I've noticed about a 5-6% increase from using public classes.

So I've gone from this:

To this:

from 6.6 million rays/second to 8.5 is about a 29% increase in speed! :)

Boost.Thread

2009-01-22T17:11:00.007Z

I've had a good look around for a way to thread a C++ application and have come accross Boost.Threads by way of recommendation and a good read in this and this.

The concepts and ideas are simple and easily illustrated. I've written a very simple program that uses the library that just starts a new thread out of a public class member function and prints an increasing number (and the thread ID) until the user requests the thread be interrupted. If an interrupt is requested, the thread kills its self at the next interruption point. When the main thread calls the interrupt, it "joins" the thread - meaning it waits for it to end.

#include <>
#include <>
#include <>
#include <>

boost::mutex io_mutex;

class counter{

private:

int id;

public:

void count(int ID) {
id = ID;

for (int i = 0; i < 10000000; ++i) {
boost::this_thread::interruption_point();
boost::mutex::scoped_lock lock(io_mutex);
std::cout << id << ": " << i << std::endl;
}
}

};

int main() {

counter *cP = new counter;
boost::thread thrd1( boost::bind(&counter::count, cP, 1));

system("pause");
thrd1.interrupt();
thrd1.join();
system("pause");

return 0;

}

2009-01-22T17:07:00.002Z

It has occured to me that i've not yet posted my honours project proposal ducument. Here it is:

Joe Taylor 0501535

Honours Project Proposal

CS1004A

Ray Tracing: A Multi-threaded Approach

Introduction

As the games industry grows, computer games are evolving to have increasingly believable universes (Luban, 2008 p. 4). One of the factors of a believable universe is lifelike graphics. Graphical abilities in games have been continually pushed forward every year and will continue to do so in the effort to create these environments.

Since 3D games were introduced to the market, Rasterization has been the dominating algorithm for rendering 3D scenes described in world space for two main reasons: it is efficient with low numbers of polygons and it produces reasonably good looking results.

The basic operation of rasterisation is to take packets of three vertices within a world space, project these onto a viewing plane and then shade the space described between all three vertices.

Yet problems are starting to occur with this approach. Ratserizastion does not permit subtle graphical effects such as per pixel shading. Calculating simple lighting effects like shadows and reflections can involve complicated shading programs to be run on specialised hardware. Furthermore, these effects can not be computed accurately and fakes must be used (Slusallek et. al 2005). Photo realistic graphics essentially require higher numbers of polygons too. With rasterization, the processing cost of adding polygons to a scene is linear (Shirley et. Al, p. 2), requiring faster graphics cards.

Ray tracing differs in that it more closely follows real light physics to achieve near perfect results. Light rays are traced backwards from a common point (a camera) through a view plane and into a 3D scene. Calculations based on surface physics determine the colour of the pixel on the view plane. The algorithm can model reflections, refractions, shadows and global illumination effects. The cost of adding polygons to a scene when using a spatial partitioning system in ray tracing is logarithmic (Shirley et. Al, p2) – extremely high numbers of polygons can be rendered with little cost relative to rasteriztion.

Using this rendering approach, very photo realistic results can be achieved. Indeed, it is the main algorithm used in offline rendering of animated films and conceptual visualisation of products. However, to enable the features that set ray tracing apart from the raster process, the algorithm must generate more rays from rays and become recursive. Due to this nature, it is too computationally expensive to be used in common real time desktop applications right now.

Ray tracing is gaining a lot of interest within the computer games community as a possible successor to rasterization as the main rendering algorithm for games. This is simply because ray tracing, by nature, achieves the effects that rasterization struggles over. More complicated, expensive hardware and complex shading algorithms drive rasterization forward whereas ray tracing simply just needs more power – which comes naturally over time. It is plain to see then, that there is an overlap in time when ray tracing will replace rasterisation in computer games. Some believe it could be as close as a few years.. But where will this extra processing power come from?

Research Question

“How is parallelism best achieved in real time ray tracing through the use of multiple core technology?”

Research Topic and Aims

Physical limits of fitting more and more transistors onto a single core are pushing the CPU manufacturing industry to shift towards multiple core architectures (Sutter, 2005). This shift allows ray tracing one massive advantage over the raster process; parallelism:

“Ray tracing is a prime example of such an “embarrassingly parallel”

algorithm as every pixel could be rendered independently from all

others.”

(Friedrich et Al 2006 p48)

In essence, the theoretical performance of a real time ray tracing engine should scale linearly with the number of cores it is run on. Daniel Phol has already shown at IDF (Intel Developer Forum) 2007 that Quake 4 can be ray traced at High Definition resolution (720p) at 90 frames per second using a dual X5365 system with a total of 8 cores, achieving a scaling factor of 7.8x over a single core (Shrout, 2007, p. 2)

This project will conduct research into the topic of real time ray tracing with specific regard to multi-threading. The main question the project proposes to answer is the how parallelization can be used to achieve high scalability.

An attempt will be made to analyse just how feasible it is to assume ray tracing will take rasterization's place in computer games. Clearly, each method has its own advantages and disadvantages for use in computer games. By examining these pros and cons while taking into account current and future technological advances, a conclusion will drawn on this popular assumption.

Methodology

The research question will be answered through the development of a number of applications. The first will be a single threaded ray tracer that demonstrates the abilities ray tracing has to offer (e.g. reflections, refractions, specular highlights, perfect diffuse specular reflection, accurate lighting and shadows, ambient occlusion, a spatial partitioning structure etc.) with a mind to traditional game technologies such as triangle mesh rendering, dynamic scenes, a moving camera and texture mapping. This application will serve as a benchmark to the other applications.

Those other applications will be copies of the first application, with the same functionalities and abilities as the base render. However, these will make use of different multi-threading optimisations. A few examples of how a ray tracer can be multi-threaded are:

A simple “Pixel Cyclic” method, whereby each core calculates the colour of every Nth pixel on the view plane.
A Split screen method. With this technique, each core is assigned an equal amount of screen space to render per frame.
A tile based approach. Rather than splitting the screen up into large chunks, much smaller tiles are used with index numbers loaded into a list. These tiles can be treated as tasks by each core and rendered individually.

(Stone, 2007)

Each application will be able to display the same test scenes for fair comparison.

Evaluation

The main area of evaluation, in determining how well each application performs, will be to measure how many frames per second the application can display under test conditions. If the single threaded application is taken as a benchmark, scaling factors can be determined by simply performing the calculation applicationFPS / benchmarkFPS. For example, if one multi-threaded application can render 10 frames per second while the benchmark application achieves only 2, we have a scaling factor of 10/2 = 5x.

The same calculation can be performed for rays per second. This measurement will give an indication as to how many calculations the application will be executing every second.

For real time scenarios, especially when discussed in respect to computer games, the standard unit of measurement for measuring the performance of a ray tracer is frames per second, since the frame-rate of the application is key to meeting the real-time condition.

Further conclusions can be made from turning on and off certain graphical effects and evaluating the performance implications of using these effects.

Issues

Running any demanding multi-threaded application under Windows will introduce a degree of uncertainty to the measurements. Windows will always have other tasks to be performing in the background, taking CPU time away from the application. What's more, Windows handles task assignments to cores itself, which would introduce another overhead in terms of thread management, albeit a small one. An ideal environment would be to run the application on a dedicated system that allows assignment of tasks to specific cores and very low level programming instructions. This way, a programmer could make optimal use of all available resources without having to compromise with other unimportant tasks. That said, uncertainties in measurements would only be minute and perhaps even negligible.

Project Plan

The Project will have three main components that can be seen as goals; critical, target and additional. The critical component will consist of everything required to construct a reasonable answer to the research question. Achieving the target goal will enable a more accurate response to the RQ and additional work will go further to compliment the response. These break down as follows:

Critical

A benchmark ray tracer with basic functionalities and visual effects will be constructed and at least two methods for optimising the application using multiple core processors will have been attempted.

Target

More visual effects will be achieved and the functionality will be better suited to computer games with implementation of a model loader, a spatial partitioning system and texture mapping.

Additional

Further optimisations will be implemented, perhaps including the use of SIMD (Single Instruction, Multiple Data). Attempts made at porting the application to a true multiple core system like a PS3 and/or using the hundreds of processors available on a graphics card to perform ray tracing.

Resource Requirements

Since the project focuses on multiple core technology, a PC running under windows (XP or greater) with a multiple core architecture is needed - preferably four cores for a reasonable set of results. It would be ideal to use a true multiple core system like the PS3 to test the applications on; to decrease synchronisation overheads and have more control over assignment of tasks to specific cores. This is not critical to the project, however.

Visual Studio 2005 will be required to write the programs and art may have to be acquired from either the internet or acquaintances willing to submit their own work.

References

Friedrich, H et. Al (2006) Exploring the use of ray tracing for future games. Proceedings of the 2006 ACM SIGGRAPH symposium on Videogames, [online] p. 41-50, Available at: http://portal.acm.org/citation.cfm?doid=1183316.1183323 [Last Accessed 8 December 2008]

Luban, P (2008) The Megatrends of Game Design, Part 1. Gamasutra [online] Available at: http://www.gamasutra.com/view/feature/3772/the_megatrends_of_game_design_.php [Last Accessed 8 December 2008]

Shirley, P et. Al (2007) Rethinking Graphics and Gaming Courses Because of Fast Ray Tracing, SIGGRAPH 2007 educators program, [online] 15, Available at: http://portal.acm.org/citation.cfm?doid=1282040.1282056 [Last Accessed 8 December 2008]

Shrout, R (2007) Rendering Games with Raytracing Will Revolutionize Graphics, PC Perspective [online] Available at: http://www.pcper.com/article.php?aid=455 [Last Accessed 8 December 2008]

Slusallek, P et. Al (2005) Introduction To Real Time Ray Tracing. SIGGRAPH 2005 Courses, [online] 1, Available at: http://portal.acm.org/citation.cfm?doid=1198555.1198740 [Last Accessed 8 December 2008]

Stone, J (1999) The Ups and Downs of Multithreaded Ray Tracing and Optimization, Ray Tracing News [online] Available at: http://tog.acm.org/resources/RTNews/html/rtnv12n2.html#art3 [Last Accessed 8 December 2008]

Sutter, H (2005), A Fundamental Turn Toward Concurrency in Software, Dr. Dobb’s Portal, [online] Available at: http://www.ddj.com/architect/184405990 [Last Accessed 8 December 2008]

Bibliography

Glassner, A (1989) An Introduction To Ray Tracing San Francisco, California: Morgan Kaufmann Publishers, Inc.

Shirley, P (2000) Realistic Ray Tracing. Natick, Massachusetts: A K Peters, Ltd.

Suffern, K (2007) Ray Tracing from the Ground Up. Wellesley, Massachusetts: A K Peters, Ltd.

Fixed bugs, added ray counter.. and Ambient Occlusion!

2009-01-20T13:11:00.005Z

So first of all: bug fixed. I was getting some artefacting on objects in the form of tearing when shadowing was enabled. What was happening was the shadow rays were being generated slightly inside the object and then firing out, hitting the object again and shading the outside of it because it thinks its in shadow. Anyway i fixed that.. so now the scenes are rendered niceley and reflections and shadows and diffuse and ambient shading all work in perfect harmony. Heres 400x400 x4 samples per pixel with reflections on both spheres... depth of 5 in reflections i think.

Pretty right? Wrong. Ambient occlusion makes all the difference. But comes at a cost. basically ambient occlusion is an effect that attempts to look like global illumination. By firing rays randomly in a hemisphere around the normal of an intersection point, we can determine how shaded that object should be, depending on how "occluded" that object is. It does however, come at a price. We can afford a small frame rate drop to get pretty rough looking ambient occlusion:

But this is wuite rough around the edges. This image was rendered using the same settings as the one above, but by firing 64 rays out into that hemisphere around the intersection points. To get a nice, smooth looking image with beautiful AO, we're looking at 256 samples per pixel and 256 samples for the AO:

better reflections, camera

2008-12-02T03:20:00.002Z

As for the ray tracer, I fixed a reflections problem i kind of didnt know I had.. its a quick fix, so the calculations arent that accurate now but the problem was that I was adding the reflected colour to the pixel colour without any colour over-run protection.. so colours were getting pretty bright and doing wierd things in levels of relection higher than 1.. it does look a little better now though.

And good news.. I've finally gotten round to writing my own all purpose plug and play camera class for the bezier curves coursework I've started too. Shoved it into the ray tracer and voila: fly around ray traced scenes!

2008-12-02T01:53:00.002Z

I've come accross an interesting "paper" by Brad Grantham, in which he asks leading computer games industry experts "When will ray tracing replace rasterization?". A list of the people he poses the question to:

Kurt Akeley
Stanford University
NVIDIA Corporation

David Kirk
NVIDIA Corporation

Larry Seiler
ATI Research, Inc.

Philipp Slusallek
Saarland University

It seems that most have the opinion that ray tracing WILL replace rasterization, whether its sooner or later. the general consensus is in about 5 to ten years, probably through a hybrid approach. Seiler however, says "Ray-tracing will never replace rasterization" and that another algorithm will triumph over both, one that can more accurately model lighting calculations than rasterization, but do it faster than ray tracing.

Kirk on the other hand says the question is "ill posed", in that the two are different algorithms with different uses. To back up his company though, he poses the question “When will hardware graphics pipelines become sufficiently programmable to efficiently implement ray tracing and other global illumination techniques?” since Nvidea are trying to promote fully programmable GPU architectures, they obviously want to bag ray tracing if it is to start becoming feasible for games.

Grantham explains exactly my own sentiment: from here on, the road gets easier for ray tracing and more complicated for rasterisation.

Ray tracing simply needs more power (or cores) whereas rasterization needs more approximations

Reflections!

2008-11-19T00:46:00.003Z

Today i sat down and gave my ray tracer the ability to process reflections! I had to create a perfect specular BRDF to calculate the reflection ray direction and the radiance at the reflection point. I've created a reflection material that inherits all of the phong material properties and adds a reflection colour and reflection constant into the equations. so this material now features ambient, diffuse, glossy specular and perfect specular reflections. The material generates rays upto a maximum depth for recurring reflections. its really quite lovely. anyway, some screenshots:

Worksheet 4

2008-11-15T20:26:00.005Z

Since I havent recieved my feedback, I'll just publish what I wrote anyway:

Introduction

The aim of this project is to show the speed increase in frame production of a real time ray tracing engine when different multi-threading technologies are applied to the ray tracing algorithm. I would like to show which technique (of the ones I assess) provides the greatest speed increase per number of cores and what that increase is.

Issues

It is well known that ray tracing is a computationally expensive algorithm due to its recursive nature. I want to show that the up side to this is that the algorithm can be scaled well over multiple cores using shared memory. As hardware becomes more and more parallelized in a bid to increase overall processing speed while transistors don't allow us to create much smaller processors, the ray tracing algorithm is falling into its place and threatens rasterisation as the leading 3D graphics rendering algorithm.

Research question

How scalable is the performance of real time ray tracing over multiple cores when the use of different multi-threading techniques are applied and which of these techniques offers the best performance?

Addressing the Question

I will write a base line ray tracer: a single threaded ray tracer with functionalities that both show off advantages over traditional rendering methods and ones that are most suited to computer games. This ray tracer will be a benchmark ray tracer. Then I will employ a few different multi threaded approaches separately and analyse how well each approach performs, in relation to the benchmark ray tracer. The performance of each ray tracer will be measured in both rays/sec and frames/sec. The approaches I've thought about taking are as follows:

Treating each ray as a separate task: Storing a list and having processors deal with one ray at the front of the list at a time
Split screen method: Assigning each processor an equal portion of the screen
Tile based method: Splitting the screen into n*n size tiles and having each processor 'consume' the tiles individually
Intelligent tile based rendering: Splitting the screen into different sized tiles and having cores consume different sized tiles, trying to minimise the waiting period cores have to wait for each other to finish a frame before moving onto the next one.

If I have time, I would like to implement the ray tracer on cell architecture, using either a PS3 dev kit or the PS3 super computer at abertay. This however, is not important to the project and would only serve as an interesting note and another set of results.

Progress

I have read countless papers on ray tracing, mainly to do with parallelising ray tracers and these have given me more insight into the topic and have raised questions I previously did not know about. I've written a significant amount of my base ray tracer and it boasts features such as multiple geometric shape rendering, phong shading with glossy specular highlights, diffuse and ambient shading, a material layer, Jittered super sampling at n^2 samples per pixel, multiple point lights, shadows, a perspective camera and an extendable, efficient architecture. I will be adding texture mapping, reflections and refractions, a model loader, a spatial partitioning system and a model loader to the engine before attempting to multi thread it.

Work Sheet 3. Draft research proposal.

2008-11-06T11:17:00.003Z

Introduction
The aim of this project is to show the speed increase in frame production of a real time ray tracing engine when different multi-threading technologies are applied to the ray tracing algorithm. I would like to show which technique (of the ones I assess) provides the greatest speed increase per number of cores and what that increase is.

Motivation
Ray tracing offers many advantages over rasterisation as a renderer for 3D geometry scenes. As a global technique, and one that closely models real world physics, incredibly realistic images can be created with relative simplicity when compared to rasterisation and this is the reason it is used as an off line rendering technique for many films and television shows. The algorithm is however, very expensive to compute. Hence its use in the film industry and not the games industry. To quote Daniel Phol in his article on ray tracing and gaming:

“Ray tracing has the potential to become the widely used rendering technology on desktop computers. The number of CPU cores is increasing and special purpose ray tracing-hardware-prototypes (http://www.saarcor.de/) show impressive results in speed improvement. It is still a long way to playing computer games in graphics like the Lord of the Ring movies, but we are getting closer to it.”

Real time ray tracing is gaining interest as a possible successor to the traditional game rendering techniques because home CPUs are heading towards the required power to carry out this very expensive task. Unlike rasterisation, the ray tracing algorithm lends itself to a multi core environment, as “rays are thus fully self-contained, and can easily be traced in parallel.” (Bikker, 2007) With recent advances in multi core home CPU technology, and intels future plans for many-core processors, this shines even more light on ray tracing as a candidate for rendering future games in real time.
Since ray tracing is an algorithm in which speed varies with the number of rays processed, lower screen resolutions take less time to render.. or, less power. “The frame rates in a raytraced title are in fact nearly linearly dependent on the number of pixels being rendered.” (Shrout, 2007) This poses the possibility of having hand held consoles or platforms which operate at low screen resolutions rendering ray tracing in real time using multiple low powered arm or cell processors, bringing hyper realistic graphics to these units.
It is important therefore, to asses how a ray tracer should be multi threaded for optimum performance and to suggest further techniques for greater optimizations.

This is pretty good. The only thing I am unsure of is the mention of hand-held platforms as your project seems aimed towards PC’s and the threading aspects of ray tracing, as opposed to changes in resolution, and as a result it seems somewhat irrelevant to your motivation.

Research question
How scalable is the performance of real time ray tracing over multiple cores when the use of different multi-threading techniques are applied and which of these techniques offers the best performance?

Addressing the Question
I will write a ray tracing engine that updates the image displayed on screen every time the ray tracer renders a full frame. The ray tracer will exhibit common properties of a ray tracer and those appropriate to a computer game engine. This will be my base engine. I will then apply a number multi threading techniques to the engine to take advantage of x amount of cores available to it. The results will be measured as a percentage increase in performance over the base engine, where the performance is a measure of how many frames each engine can render per second, when given the exact same scene.

This seems like it will answer the question well.

Resource Requirements
A multiple core computer is needed. My home computer has a quad core so tests can be carried out over 1,2,3 and 4 cores. If I have time, I would like to try and port one of my engines to the PS3 super computer at Abertay.

References and Bibliography

Daniel Phol. (2006). Ray Tracing and Gaming - Quake 4: Ray Traced Project. [Online] Available at: http://www.pcper.com/article.php?aid=334&type=expert&pid=4. [Last accessed 04 November 2008.]

Jacco Bikker. (2007). Architecture of a Real-Time Ray-Tracer. [Online] Available at: http://software.intel.com/en-us/articles/architecture-of-a-real-time-ray-tracer-2. [Last accessed 04 November 2008.]

Ryan Shrout. (2007). Rendering Games with Raytracing Will Revolutionize Graphics. [Online] Available at: http://www.pcper.com/article.phpaid=455&type=expert&pid=3. [Last accessed 04 November 2008.]

Shadows

2008-11-03T17:00:00.003Z

I've implemented shadows! this is a case of using a simplified hit function in each geometric object class. The function just has to determine wether a a shadow ray, fired from the primary ray hit point on an object in the direction towards any light sources, interescts any object on ts way. if it does, that point is in shadow! so only ambient light will affect it. its really that simple. And the results are beautiful. Here is a scene with two spheres, a plane (I've added a 'Plane' geometric object) and two point lights, the green sphere has a glossy specular reflection applied while the red sphere has a matte material. the image uses 4 jittered samples per pixel and is rendered at 400 * 400. Hence the slow frame rate!!

On another note, I tried implementing some vector SSE operations with success, but the actual framerate is slower than without.. which i dont really understand. the optimisations SSE pose must only be effective when carrying out calculations that involve a lot of maths, like matrix multiplications and the like. Oh well, I'll give SSE a bash when I'm actually using matricies in a camera or object transformations or something.

Specular reflection

2008-11-02T20:10:00.002Z

Getting specular reflection working was a case of writing a new bidirectional distributed reflectance function. This glossy specular material is a phong model that takes into account ambience, diffuse shading and specular shading. the specular shading function calculates the intensity of light based on the light source, the camera position, the normal on the surface and a phong exponent, e, to work out the intensity of the light at the point the ray hits.

Lighting!

2008-10-31T13:06:00.003Z

It took quite a bit of work to integrate lighting into the ray tracer. I had to make a BRDF (bidirectional reflectance distribution functions) base class and an inheriting lambertian class (perfect diffuse shading) and a Matte material class, which has both lambertian ambient functions and lambertain diffuse shading functions. This enables us to be able to set the influence both ambient light and direct light has on the material.

I created a Light base class and two lights: ambient light and a point light. The ambient light is stored as its own pointer in the world class but the point light (or lights) can be added individually to a light list, with light intensity and colour parameters.

I also had to change a few existing classes to account for these new light sources, materials and shading functions. Here is the result! a point light lighting the two spheres with 4 samples per pixel is displayed below:

Ray Tracer: Started!

2008-10-30T10:50:00.008Z

Last week I started writing my ray tracer. I bought a book by Kevin Suffern called Ray Tracing From the Ground Up. Its amazing! it basically teaches you how to write a ray tracer that is resonably fast, extendable and clean. It goes right through from a basic ray tracer to global illumination and realistic scene production.

I'll post some screen shots as I go through this. It'll illustrate the developement of the program.

1) Getting the ray tracer set up and running.

This was quite a big task to start off on. It required writing math libraries (ray class, vector class, normal class, point class RGBColour class) and the basic components of a ray tracer: geometric object base class and a sphere class to start off on, a tracer class, a world class, a view plane class and a shade record class. Thats about all thats required of a basic ray tracer.

The world class contains basically everything and describes what is present in the scene and builds it using a build function. The viewplane describes the screen we will be firing rays through and its co-ordinates in world space. The tracer is responsible for firing the rays into the scene and the shade record class stores all the information needed as the ray gathers it to calculate the final pixel colour at the end.

At this stage there was no camera involved, what was rendered was an orthographic projection (rays fired parallel through the view plane with no common origin) This was fine to render a single yellow sphere, however:

2) Multiple Objects

Thuis was a case of creating a new tracer class that could handle multiple objects and supplying the world class with an object list and adding them individually in the build function:

3) At this point I discovered that the main function slowing down the program was the windows GDI SetPixel() function, which writies a pixel colour to the back buffer which will be rendered on screen in the next frame. So slow I had to change it. So I gave OpenGL a bash but this turned out to be pretty slow too. What I needed was a was to take a pixel buffer that stored RGB values for every pixel in the RAM and then at the end of each frame, fire that buffer into a texture on the graphics card to be displayed since the graphics card is better at drawing to the screen than the CPU and anyway, the CPU has work to do!. The obstacle was getting data from RAM to graphics memory fast.

I found the solution in D3D dynamic textures. I set up a simple quad to face the camera in directx and a dynamic texture of the required size. Dynamic textures set up a fast pipeline between system memory and graphics memory (perfect!). This texture is mapped onto the quad with anistropic filtering (to keep things looking beautifully accurate) and every frame after the ray tracer has compelted its rendering, I lock the texture, memcopy each horizontal line of the image from the pixel buffer into the texture and then unlock it. I have to copy each line into the graphics card seperately with a pitch between them because this is how the graphcis card stores textures apparently. It took me a long time and a lot of hair pulling to figure this out. But the result is well worth it! The final render time on directx's part is small enough to be considered negligable to my ray tracer.

4) Perspective Pinhole Camera

This was a rather simple step. until now, the render function was in the world class (because I had no camera). So I set up a camera base class and a subclass called PinHole and created a camera with a world position, a distance from the view plane, a zoom factor, an up vector and UVW vectors. And thus, a fully moveable camera. The camera now has the render function as we would expect and fires rays from one point with different directions, based on the distance from the view plane and which pixel we're working with. Unfortunately I dont have a screen shot to illustrate the difference between orthographic projection and perspective projection. I deleted the orthographic render function. You might be able to imagine, however, that two spheres intersectig when viewed as an orthographic projection, show a straight intersection line. A prespective camera does not.

5) Sampling.

As with all computer graphics, and due to the finite nature of computers (a pixel has a size and does not denote a point), aliasing occurs in ray tracing too. To get around this we can send x amount of rays through different positions in one pixel, and average the result. This is what I employed. I've gone for a jittered sampling algorithm which is technically more accurate than a fully random algorithm but still random enough to make a good impact on aliasing.

A random sampler could in theory clump all rays together in one part of the pixel. Jittering the samples splits the screen up into n number of sections where n is the number of rays and gives the ray a random position in its own section. this still gives a degree of randomness required to simulate quantum mechanics (i won't get down to that level of detail though :P) yet won't produce artifacts resulting from rays clumping together.

My Jittered class enables me to set up any number of samples in a pixel.

Here is a screen shot of the two spheres above sampled with 4 samples per pixel.

And 256 samples per pixel:

6) Frame Counter

You might have noticed in the last screen shots I have a frame counter. I made a timer class that outputs an average frames per second. I just draw this using D3D font.

7) Lighting: next blog!

2008-10-15T00:21:00.004+01:00

ABSTRACT

Worksheet 2, annotated by Scott Downie

2008-10-15T00:08:00.003+01:00

Joe Taylor 0501535

Worksheet 2

(Comments by Scott Downie)

Formulate a research question for your project. Details on the research question can be found in presentation 1 in the module folder.

How scalable is the performance of real time ray tracing engines over multiple core systems?

I can’t see any flaws in the question. I feel that the question details the nature of the experiment well. However maybe you could add a line about implementing it in game situations like you have said at the bottom of the page. The only other issue I can see is that maybe the word “scalable” is a bit ambiguous. It does sound pretty well thought out to me though.

When developing a research question you must produce a question that can be answered by performing literature research, practical experimentation and critical analysis. The question should also focus the activities of your project.

a) What is the focus of your project?

To find out the advantages of multi-threading a real time ray tracing engine and to show what advantages a multiple core CPU might have over single core cpus and whether ray tracing might be a replacement for rasterisation within the foreseeable future.

Another aspect you might like to focus on or at least discuss briefly is the advantages of ray tracing over rasterisation and the shortcomings of the rasterisation process.

b) What information do you need to find out about?

I will need to find out about research that has been carried out in this field before, issues surrounding the performance of real time ray tracing engines, new developments in technology and future developments with respect to real time ray tracing.

What about the disadvantages of ray-tracing compared with photon mapping for realism. Mention any implementations of real-time ray tracing for instance the quake wars experiment where it ran on 16 cores (thank you wiki).

c) What Experimental work do you need to perform?

I will need to create a ray tracing engine, perhaps just a simple one, and analyse its performance when run on different multi-core systems (single core, dual core, quad core). I could also look into the possibility of using the OpenRT engine to network two quad core computers together to create a simulated eight core system.

This again seems pretty robust to me. I like the idea of using an ‘8-core’ system as that would simulate some future technology and allow you to speculate whether it would be possible within the next year or so.

How will the information that you obtain in 2 allow you to answer the research question?

By looking at examples of what other people have done in this field, taking results from my own work and looking at current technology in relation to proposed future technology, I should be able to show the relation between the number of cores in a system against performance increases and judge how much power might be needed to run a real time ray traced game in standard gaming resolutions.

Maybe mention that from this you will be able to draw another conclusion whether ray-tracing can replace rasterisation any time soon

Long Awaited Update

2008-10-14T22:17:00.004+01:00

Thanks to Google for blocking my blog for so long. I've been writing my thoughts today in my physical log book after spending a good few days reading up on all i can find on ray tracing. I don't see any point in re-writing it so I'll copy it out here:

What is ray tracing?

Used by the film industry
Accurate lighting model
Approximates real world physics
Gives hyper-realistic images
Simpler than rasterisation
more computationally expensive
Can handle reflection, refraction, and shadows by its nature (no shaders needed)

Basically ray tracing is a better way to render 3D scenes than rasterisation. It has mainly offline purposes (CG films, computer arts etc.) due to large frame rendering times.

How Does It Work?

In real world physics, we see things as a result of photons hitting our retinas with different wavelengths (colours) and energies (intensity), the cells in our retinas build up an image, just like pixels on a screen.

It would be possible to write a program that took light sources and emitted billions of photons into a virtual world, track them and record any that hit a certain defined area along with their new energies and wavelengths after interacting with the environment. however, this would be almost infinitely impossible to do, considering the amount of time wasted following photon paths that didn't even affect the final image.

The way ray tracing gets around this problem is by tracing rays backwards starting at the camera and following them into the scene like so:

Here we see three rays being traced from our camera, straight through pixels and into a virtual 3D scene consisting of a sphere.

Ray 1 is projected through the top left pixel and into the scene but does not intersect any objects and will eventually be terminated, leaving the pixels (the pixel it passed through) colour as black.
Ray 2 is sent through another pixel and this one intersects with a sphere. From this point a shadow ray (or shadow feeler - blue) is sent straight to the light source. If the ray does not intersect any objects on its way, this means the sphere is illuminated by the light source and depending on the surface properties of the sphere, the colour of the light and its intensity, a colour value for the pixel can be determined.
Ray 3 has hit the ground and its shadow feeler has reported that a sphere stands between the ground intersection point and the light source so the ground is in the spheres shadow and does not receive any light. However, the primary ray has detected that the ground has both transparent and reflective properties and so has spawned a reflection ray (red) and a refraction ray (green)

It is easy to see how ray tracing is a recursive algorithm that is surprisingly elegant and simple but can result in a lot of computations.

For a scene to be rendered at 720 x 1024 pixels (720p), 737280 primary rays must be sent out. add to this extra rays per pixel for anti-aliasing, shadow rays, recursive reflective and refractive rays, more lights and perform this at real time frame rates (over 30fps), you get a hell of a lot of rays to process. Indeed, it has been suggested that to play a real time ray traced game at 720p, an engine would need to follow over a billion rays per second and thats with optimisations!

SO: Optimisations are what I'm interested in. What optimisations could you have for a real time ray tracing engine? Well heres a list of a few important ones:

Multi threading

Its easy to see that ray tracing is scalable over multiple cores, since each ray is treated as an individual entity and reads the scene information rather than writing to it.

Better Anti-Aliasing Techniques

Aliasing is solved by firing x amount of rays through one pixel and taking the average colour value. However, firing for example, 16 rays through every pixel on the image plane is going to slow the engine down 16 times. How can this be solved?

Spatial Partitioning

Testing for multiple object intersections within a scene can also slow down render times. If we has 2 million triangles in a scene each ray would have to make intersection tests with every one of these triangles, which is very costly. Can spatial partitioning structures be used to speed things up?

SSE Instruction sets

Since ray tracing involves a lot of vector maths, wouldn't it be useful to use SIMD to speed things up? Single Instruction, Multiple Data allows multiple objects to be operated on in one instruction, greatly increasing the speed of certain operations. Better still, couldn't multiple rays be traced at once using these registers?

Which of these topics do I want to study for my dissertation? Well, I haven't really decided yet. I'm leaning towards multi threading as this also interests me. I think Anti-aliasing techniques are interesting but a dissertation on this might be too simple. Spatial partitioning doesn't really excite me as much as the other topics and I haven't read into SSE or had any experience with them yet so can't really judge that technique. It is interesting though.

Current State of the Art.

Ray tracing has until recently been used as an offline rendering technique for films and computer arts. However, with increases in home CPU power, ray tracing has been gathering attention as a possible successor to rasterisation. While rasterisation is a fast method for rendering 3D scenes, it has a lot of cons. Mainly:

It requires expensive, dedicated hardware
Shaders have to be used on separate parts of a scene to approximate lighting models
Complex APIs have to be used
It can't handle reflections and refractions well
It doesn't easily give a physically accurate representation of a 3D scene.

While it would be naive to say that ray tracing can solve all of rasterisations problems, it can handle them better and more accurately with very little persuasion. It just takes a lot of grunt. Hopefully soon, "grunt" won't be a problem. There are certain things ray tracing cant do due to its 'backwards' nature. Notably caustics and diffuse inter-reflections.

But it provides a better physical model for simulating light. In effect it is just a lighting model that works in the same way the physical universe does it and so can produce better results and hyper-realism.

So what is the future of ray tracing? It is hard to say. Intel is pushing for more raw power increases, making ray tracing possible on just the CPU, effectively phasing out graphics cards. Companies like ATI and Nvidea, who own the graphics card hardware market may be looking into using RPUs (Ray Processing Units) instead of traditional GPUs. Indeed, asking a CPU to render what a graphics card is capable of doing at over 30fps with dedicated hardware will yield results of only a couple of frames per second. What then, if we had dedicated hardware for processing rays? Saarland University have developed a prototype programmable RPU that operates at only 66mhz with a very low memory bandwidth (350mb/s) that is capable of achieving the same ray tracing performance as a 2.6Ghz Pentium 4. Could this be the future?

Reference

Personally I think ray tracing has a real time future that is going to take off soon. Whether it will be on dedicated hardware or not, I don't know. Since I don't have access to dedicated hardware I'm stuck with using the CPU and since Intels plans are for many-core CPUs, studying scalability of real time ray tracing engines seems like a sensible option.

Why do I want to do something to do with ray tracing anyway?

2008-10-06T15:06:00.001+01:00

Well, I've always had a thing with maths (and physics because we all know physics is really just a sub-set of maths).. A love/hate relationship if you will.

I always get a great satisfaction out of writing a program with elegant algorithms involving elegant maths that just.. work, to great effect. What appeals to me about ray tracing is its beautiful simplicity.

Human nature is all about looking for ways to make really complicated things simple. Look on the news! The large hadron collider is a massive, incredibly expensive experiment that deals with the smallest stuff imaginable. And why? Its aim is to find a proof of string theory, a theory or one algorithm that can describe the whole universe. Einstein spent most of his years after general relativity searching for this unified solution.

In a world where processing power in the home computer is increasing at what i think is still the Moores Law rate, and while traditional "bodge job" rendering techniques, designed to get around a lack of computational power are getting waaaay more complicated by the year (shaders, graphics APIs like opengl directx, physical graphics cards with multiple GPUs, dedicated memory and ever changing architecture), its getting towards the day where we need to say "wait! Forget rasterisation, lets just do this how our own universe does it! STAND BACK, I'M GOING TO TRY PHYSICS"

I believe a change for the better, more accurate rendering technique known as ray tracing is going to happen.

First Hurdle down?

2008-10-06T14:41:00.000+01:00

Dr Ozveren has taken a look at the first draft proposals for our class and hasn't said anything against any of them yet.. I'v been assigned Louis Natanson as my supervisor. I'm pleased, Louis is great :)

So I'll be meeting with Louis hopefully sometime this week, having a discussion with him about my project and then sending off a more detailed work sheet with a proposal question to Dr Oz.

Scott's 2p

2008-10-06T14:40:00.000+01:00

"Scott Says : You might want to look at it from a more games orientated angle. Maybe comparing ray tracing to current techniques used and seeing if it can be used in a game situation with current technology, rather than having a solely ray traced scene that just looks as good as today’s top graphics."

Scott Hampson

Thanks Scott!

Honours project proposal: first draft

2008-09-29T02:36:00.000+01:00

We've been given the task of answering a few simple questions on our initial idea for the project. We have to send it to the next person on our class register for it to be evaluated by them and then sent back to a) us and b) the lecturer. So here is what I sent off:

Joe Taylor 0501535 CGT Honours Project draft proposal

State the topic of interest that you may wish to take forward into a project.

Ray tracing as a next gen. Rendering approach

Indicate the issues surrounding this topic that you may wish investigate.

With the increase in the processing power of computers (with Intels plans for many core CPUs) and the increase in complexity of traditional rendering methods, it makes sense that one day the switch will be made to begin rendering computer games using the more physically accurate and simple but computationally expensive method of ray tracing. I would like to investigate how close we are to the 'jump', if at all there is a 'jump' and no hybrid, from rasterisation to ray tracing. In my opinion, ray tracing games is about to take off in a big way.

Outline your initial ideas about how you would carry out the practical aspects of the project. i.e. what do you envisage yourself actually doing for the project.

Since ray tracing treats every pixel on a display as an individual ray, this makes it easy to render a scene using multiple threads to build each frame perhaps using split screen methods or other methods. I'd like to write a real time ray tracer that takes advantage of multi-core technology to render 3D scenes with maximum speed. To see how close to 'real time' I can manage, and judge what kind of power a computer might need to render (using ray tracing techniques) a scene that would look just as good as todays top graphics in computer games.

Some Links worth looking at:

http://www.youtube.com/watch?v=oLte5f34ya8

http://www.youtube.com/watch?v=zKqZKXwop5E

http://www.youtube.com/watch?v=blfxI1cVOzU

http://www.realstorm.com/

Blog

I have also set up a web log for my honours project. This can be located at http://yeraveragejoe.blogspot.com

Hello World

2008-09-29T02:28:00.000+01:00

Well, This is my first public web log.. one that isn't part of a website whos main function is social networking. Hopefully it will include regular updates as I'm pretty sure my degree depends (at least on some level) on it.

I'm Joe Taylor. A fourth year student at The University of Abertay, Dundee studying Computer Games Technology. This year is my honours year and this blogs main function is to serve as a log of my honours project to my lecturer, Dr. Ozveren.

I'm not sure what else to put in this introduction... Oh, my student number is 0501535. That might help. Anyway, on with the first real post...