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 :)
Thursday, 14 May 2009
Friday, 24 April 2009
Update
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.
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.
Friday, 27 March 2009
XML parsing
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.
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.
Thursday, 19 March 2009
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!
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!
Saturday, 7 March 2009
Wednesday, 4 March 2009
Models! .Obj file parser and loader sculpted from lex and yacc.
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.
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.
Monday, 23 February 2009
Subscribe to:
Posts (Atom)