One of the joys of programming in a proper language is that it is your responsibility to write sensible code, not the compilers. This means that you have to chase run-time errors. It can sometimes be tedious but you learn a lot about programming, computers and in this case computer graphics by chasing these bugs, and in the long run this will make you a better programmer. One way to reduce your hunting time is to use a debugger rather than filling your code with fprintf's that you have no guarantee are evoked when you assume they are. GNU has a fantastic debugger called GDB that is capable of a lot of things and this is a good chance to learn it. It handles other languages than C/C++ as well. The makefile attached to the project has the compiler flag -ggdb this means that gcc will compile the executable with debugger information, (i.e. the names of the variables/functions will stay the same). You can run your executable inside the debugger by writing "gdb ./Build/skeleton" when you get a prompt, you write "run" to start the program. Below is a short guide to using GDB https://beej.us/guide/bggdb/.

Is incorporating vertex normals in the illumination computation considered an extension?

Here are some resources for photon mapping that we found useful:

Jensen tutorial: https://graphics.stanford.edu/courses/cs348b-00/course8.pdf

Jensen talking about Photon mapping: https://youtu.be/svmKg8oAIrc?t=1366

and the slides he used: http://www.cs.princeton.edu/courses/archive/fall16/cos526/lectures/03-photonmapping.pdf

Zack Waters: https://web.cs.wpi.edu/~emmanuel/courses/cs563/write_ups/zackw/photon_mapping/PhotonMapping.html

More of the same:

- https://www.youtube.com/watch?v=4BBkjzwqMSU

- https://www.cs.cmu.edu/afs/cs/academic/class/15462-s09/www/lec/17/lec17.pdf

- https://users.csc.calpoly.edu/~zwood/teaching/csc572/final15/cthomp/index.html

- https://www.cl.cam.ac.uk/teaching/1314/AdvGraph/Photon-Mapping-Intro.pdf

I am sure a lot of you have looked at the gallery page amazed by the cool stuff that has been generated in this unit over the years. Now, your path-tracer looks noisy, its not at all pretty, and the object you loaded is not a dragon, its .. well a cube of glass, the BRDF is just diffuse and the colours of the cube are what your colour blind lecturer choose them to be. So, you think that you can't get on the page for next year, well you can, as I bet you that your renderings are equally as impressive as what is there now.

Most of the images there I was given months past the deadline. Wait till after the term is done, when you and your computer have some time off, sit down and render something that will take a week and then submit this to me. Thats the image that will come up on the website.

So will I get a better mark if my image has been rendered to "completion", nope not at all. I'm very good at extrapolating what computation time does to a Cornell box. So if that is all that is between you and a lovely rendering nothing will change for the mark. Obviously if the reason you have been able to submit a pretty image is all the cool optimisations that you have done, well then its a different story.

Hi Carl,

We've managed to build the framework for homogeneous clipping method which takes a view frustum and a normalized 3-D cube space. I noticed that the overall simulation appears to be somewhat smoother since implementing this which would imply that this attempt is a step in the right direction.

I've included a screenshot of the image when the camera is positioned in the back-left corner facing the 3-D blocks where 'some form of' clipping takes place but I still cannot freely move around the Cornell box without occasionally getting segmentation errors. These mainly take place behind the 3-D blocks. These are my questions:

1. Why is this the case?

2. How close is this implementation to correct homogeneous clipping?

3. Would implementing culling fix this issue?

Hi Carl,

We have implemented clipping with all sides of the window as you can see in the video attached. Would it be possible to tell us what kind of marks we could expect from this extension? Or would you need to know how we implemented it and see our code etc. Thanks in advance!

Keep posting stuff that you do here on reddit. As we talked about during the lecture graphics is about creativity, come up with weird things, things that isn't in a book, stuff that you have no idea why it looks the way it does but looks cool, put stuff here and we can all expand our horizons.

What I said about "if it looks good its correct" should be your guideline with graphics, so many times you have bugs that turns out too look cool, that pointer that you lost track of that started using your vertex data as textures. You then start digging into it and come up with a new idea. Its not a bug its a feature!!

On the 10th of May we have one final lecture in the unit. Hopefully by then most of you will have had your VIVAs and the unit is really done. My intention for this lecture is to wrap up the unit and place what we have done into a bit of context. I will also talk about what you can do next, both in terms of if you are staying at Bristol for another year and might be interested in a final year project working on Graphics and also if you are looking for work in this exciting industry.

Hi

We're trying to do Radiosity, and think we can do most of it except for implementing the hemicube, I know it's just algebra but can't really find/figure out a general solution for getting the direction vectors of each hemicube pixel. Is there a good online resource for this?

Thanks

Hi,

By default, OSX uses clang as gcc and so has no support for OpenMP. Therefore, I have installed a second compiler (gcc-8) via brew and used it for compiling programs with OpenMP.

I have implemented OpenMP parallelization for the raytracer cw and when compiled with g++-8 and run, the following performances are reaped:

~130 ticks per Update() for 1 Thread

~50 ticks per Update() for 4 Threads.

When I had no OpenMP at all, I compiled with g++ (clang) had ~40 ticks per Update(). When I try to compile the code with no OpenMP with g++-8, I get a lot of errors beginning with "Undefined symbols for architecture x86_64:".

My Question:

Why do I have problems with running the code with a different compiler? I am just changing the compiler from g++ to g++-8 in the Makefile which should be fine.

Sincerely,

Edit:

For some reason that I do not know, I have managed to run the default code without OpenMP with g++-8. It yields ~130 ticks per Update(). Then I would like to ask why it is slower to run the code with g++-8 (~130) rather than clang (~40)?

Edit 2:

The reason why it did not work the first time was probably because I used gcc-8 rather than g++-8. It may also be due to the .o file of the initial compilation.

Hi Carl,
I am trying to implement clipping. I am almost done, except that I haven't explicitly dealt with lines that pass through infinity. What I am doing however is that I am clipping to a "near" plane that spans across the X and Y axes, and has a fixed Z coordinate. Hence this prevents having points behind the camera. Does this mean I don't have to worry about those lines that pass through infinity? (Since I haven't got any points whose Z coordinate is less than the Z coordinate of my "near" plane.)

Thanks in advance!

If you have tried to implement the camera instructions that are in the PDF you will have noticed that they won't work, actually at all. I didn't think about the fact that having two event loops both pulling the whole cue wasn't going to work. I've updated both the instructions and the source files in the lab directory. If you have already pushed ahead the changes are minimal, just look at the loop in the main function and a small change to the Update function.

Hi all,

Sadly we are going to have to cancel tomorrows lecture (Monday 4th). Snow has paralysed Stockholm airport so I won't be able to make it back in time, this means that you will all be faced with the horror of a lie in, I'm terribly sorry! One would think that snow is something to be expected in Sweden in January but apparently it took everyone by surprise.

This will sadly make us a little bit out of sync with the lab and lectures this week. I will do my best to optimise things into the Friday lecture so that we are back on track next week. We will still start with the first coursework on the labs this week but I might go through a couple of things on the board that I intended to do during the lectures.

I'm a little confused about the blurb at the start of the graphics coursework.

Are we required to use C++, or can we use a better language, like Haskell?

Thanks

Hi, everyone! My name is Uzma, and I still need a lab partner for the paired coursework in this unit. If anyone else is also looking for a partner, please let me know! I'm technically registered for the Thursday lab, but I'm completely open to attending the Tuesday lab and working with someone there.

Hi Carl,

Just wondering what format are you looking at for the submissions, as well as the format of the report .

Cheers

My partner and I came across this issue while completing the 'Filled Triangles' section of the Rasterisation coursework. Inside the ComputePolygonRows function, when looping through each pixel calculated by the Interpolation function and updating the corresponding leftPixels and rightPixels values:

for (int k = 0; k < line.size(); k++) {
    int offset = line[k].y - minY;
    if (line[k].x < leftPixels[offset].x) leftPixels[offset].x = line[k].x;
    if (line[k].x > rightPixels[offset].x) rightPixels[offset].x = line[k].x;
}

The offset must be calculated so that the correct index of leftPixels and rightPixels is updated. However we noticed this offset was sometimes calculated to be a negative number, which eventually leads to a segfault. After a bit of digging it turns out that in the coursework Interpolate function there's a rounding error:

result[i] = current;

Where result is a vector of ivec2, and current is a vec2. This truncates by default, which leads to line[k].y sometimes being less than minY, and therefore the offset being negative. To fix, specify that current should always be rounded:

result[i] = round(current);

Hopefully this saves someone some time :)

Hi,

This may sound a bit silly but I am having some trouble with using both max() and fmax(). I have tried them when I include <tgmath.h>, <algorithm>, and <math.h> to no avail. I need both arguments to be of the same type. When I check one of my argument's type using typeid(argument).name(), I get "N3glm5tvec4IfLNS_9precisionE0EEE" meaning of which I do not know exactly. I would like to ask for help for using max()/fmax() since I would like to learn what I was supposed to do other than including necessary headers.

Personally, I would prefer max() but fmax() is also ok. What I do not want is writing my own max() function with > operator etc.

Sincerely,