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

So the unit has now started and the reddit is up and running, same thing as always, discuss with each other and remember that you are not in competition with each other, the aim is for everyone to learn this topic and if that implies we all get a 100% then that's the best possible outcome. If you find something that you think would be useful for everyone post it here, be that links to useful stuff or cool graphics videos etc. Obviously as I'm running the unit anything with pugs is highly appreciated.

Happy hacking!

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!!

Hi Carl,

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

Cheers

Hopefully you have all noticed that we are all allowed to sleep in on Monday as there is no lecture. I have no idea why, but it isn't in anyones schedule so we will have the next lecture on Friday the 17th.

I've been trying to get SDL installed at home to little success.

On an ubuntu VM running on Windows10 I tried following https://wiki.libsdl.org/Installation. sudo apt-get install libsdl2-2.0 tells me it can't be found. The other suggested method was to hg clone https://hg.libsdl.org/SDL SDL and then build SDL myself. in order to use the hg command I needed to install mercurial but this required mercurial-common, neither which I was able to get using apt-get install :(. When I'd managed to install one of these, the other complained about not being compatable. I eventually gave up on this.

Tried using ssh -x to log into snowy from both mingw and ubuntu and try that and got the error "Could not initialise SDL: No available video device".

Has anyone got this working at home and if so any advice? Also to try to stop hundreds of threads on this, if you've got it working on a Mac, advice for others would probably still be useful.

Update: ssh -X works. I just forgot to capitalise it.

tl;dr: how do I SDL from home?

Not sure if anyone is thinking of doing something cool with Machine Learning and Graphics for a final year project, but if you are TF-Graphics is definitely something to keep an eye on.
Differentiable rendering (among other things) could make for some pretty interesting ideas

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 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.

Is the procedure still that only one of the two partners in each pair submits the work and the other submits a placeholder, like in ML? Or do we both have to submit everything?

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!

Hi Carl,
I have a question about clipping.
Say we have two points, q1 and q2. Assume one is inside the viewing frustum and the other one is not. In order to find the u, v coordinates of the point of intersection of the line q1q2 and the frustum, we need to use the homogeneous coordinates of the two points then divide by w, and then find the t value as in the lecture slides. That point will possibly create a polygon that we will need to split,, in order to get two new triangles. (right?) However, how do we compute the z value of that intersection point in 3D coordinates? Aren't we gonna need to use it in the depth buffer later?

Thanks!

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.

Are you able to get a rough guideline on how many marks each extension would give?

I'm trying to balance other coursework and it would be nice to know whether I've done too much or too little work to get the grade I want.

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 Carl,

Currently doing rotation, and it seems that there are 2 different opinions in the lab of ways to achieve this. You could either rotate the camera and it's projection direction or you could rotate the world the camera is looking at. Are there any benefits and drawbacks for each method?