2012/2013, 4th quarter, time slot B [CS site | OSIRIS]
INFOGR: Graphics
Wolfgang Hürst (WWWEmail),

Home | Schedule | Lecture | Tutorials | Practicals (forum) | Exams & grading

There will be three practical assignments throughout the course of this lecture. You have to hand in all of them, and your grade from the practicals has to be at least 5.0 to pass this course (cf. Exams & grading). All necessary tools for the practicals are installed on the computers in room BBL 175, which is reserved for this course the whole week from 9-17h. During the following time slots, teaching assistants will be present to help you if you have questions or problems starting April 25:
  • Tue 11h-13h (Jordi van Duijn, Tom Rijnbeek)
  • Thu 11h-13h (Vazgen Gasparian)
  • Thu 15h-17h (Gydo Nieraeth, Paul Scharf)
Notice that we might extend, shorten, or otherwise change these time slots given the actual need (e.g. more hours before deadlines, shorter hours otherwise).


IMPORTANT INFORMATION
  • WORKING IN TEAMS: The programming assignments must be done in groups of 2 to max. 3 students. If you submit alone without prior consultation with the course instructor, the grade of your submission will be reduced by 1.0.
    Building groups: You can choose your partner(s) yourself among your fellow students. If you can't find one on your own, contact one of the TAs in the practicals (cf. time slots listed above). They will help you to team up with other students who are also looking for a team mate.
    If your partner drops the course, contact the instructor ASAP. In such a situation, you will either be assigned a new partner by us or be allowed to work alone. Working alone without prior consultation of the instructor of this course will have consequences for your grading!
    Important info considering the grading: It is up to you, how you split the work among your team members. However, this freedom comes at the price that you have to be prepared for situations such as team members dropping the course or not delivering what they promised to you. It is your responsibility to make sure that you are aware of your team's progress, so you can react to such issues in an appropriate way.

  • PREREQUISITES: The first assignment will be online on Tuesday, April 23. We recommend that you start working on it right away. Practical sessions where TAs are present start Thursday, April 25, at 11h (cf. time slots listed above). For the practicals, you need a Windows 7 PC with Visual Studio 2010 and XNA Game Studio 4.0 (sorry, Mac and Linux fans). If you don't own such a machine and software, you can use the computers in BBL 175. The room is reserved during the whole week for the graphics course, so you can go there anytime.

  • "GROEP INDELING" AND TA-SUPPORT: Ignore the "groep indeling" on OSIRIS. There are no groups other than the teams you form with your fellow students, and there are no fixed time slots where you have to be present. It is up to you when and where you will do the assignments. We have the room (BBL 175) for the whole week. TAs will be present at certain time slots to assist you. Note that space in the room is limited and it's first-come-first-served (well, first-seated actually). But we will offer enough time slots so everyone should be able to attend at least one session where a TA is present. Please take advantage of off-peak times if possible. If you are working on a laptop, you might consider bringing it along, so you can still ask questions to the TAs in case all computers are blocked.

  • STUDENTS DOING THE COURSE A SECOND TIME: The practicals will be comparable to last year. Minor changes may apply though. If you participated in this course last year, there are two options:
    • You re-do the practicals. If you are teaming up with someone who is doing it for the first time, you are not allowed to re-use your code. Be warned that we use software to check for plagiarism (and we have all code from last year at hand).
      If you are teaming up with someone who also took the course last year, you can re-use parts of your code. However, be aware that we can't guarantee the same grading (since criteria might slightly change). Second, we might be more critical in grading the parts that changed if we get the impression that you didn't put much effort into it but just copy-pasted your old stuff.
    • If you passed the practicals (i.e. got at least a 6.0 for the practical part of the course before rounding), you might get an exception allowing you to "pass on" the result from last year. If you want to take advantage of that, you have to send me an email till Thu, April 25, 9:00. I will then arrange a meeting with you (most likely in the afternoon during the practical session after the lecture). You have bring last year's implementation to this meeting and we will decide then if this exception is applicable for you or not.
    Other cases (e.g. students who did the course 2 years ago) have to redo the practicals. If you have any doubts about what criteria apply to you, make sure to contact me as soon as possible, so we can discuss it.

  • REFERENCE MATERIAL: Some reference material and links to further resources that might be helpful, especially for programming assignment 2 and 3:
    • Slides from the introduction talk for assignment P2 (by Marries van de Hoef): [PDF]
    • Slides from the introduction talk for assignment P3 (by Tom Rijnbeek and Paul Scharf): [PDF]
    • The HLSL reference guide from the Microsoft MSDN library.
    • Some free books on the developer section of NVIDIA's website:
      GPU Gems 3, GPU Gems 2, GPU Gems 1.
      (Thanks to Tigran Gasparian for providing these links.)
    • A book published by Gamedev:
      D3D Book: Table of Contents
      (Thanks to Tim de Jager for providing this link.)


For up to date info on the assignments you might want to keep a close eye on the forum for the practicals, where you can find tips, comments, and other related infos. Feel free to post questions and comments there (but don't give away parts of the solutions and don't post related code - violating this rule can have significant consequences including your exclusion from the course).
FIRST ASSIGNMENT (TUTORIAL)

The first assignment is basically a tutorial that teaches you how to set up the framework that we'll be using (VisualStudio, XNA, etc.), and introduce you to some of the basics of graphics programming. It is based on an online tutorial written by Riemer Grootjans (see here for Riemer's 3D Series 1: Terrain tutorial). If you don't feel challenged enough from this course and want to learn more, you might want to check out his other tutorials as well, cf. Riemer's XNA Tutorial > Home. Because we needed to make some adaptations to the tutorial to fit the needs of the course and local restrictions, it is password protected. You get the password in the first lecture (or you can ask your friendly TA about it).

Here is the assignment together with two additional files needed to do the tutorial:

Important note: If you downloaded the file before April 23, 11:30, the first page is missing! Make sure to download the updated version! Sorry for the inconvenience.

Deadline for the first assignment is Tuesday, May 7, 15h00 (strict). The deliverable (zip file as specified in the gray box on the first page of the assignment) has to be uploaded via the SUBMIT system (link for upload will be online within the next couple of days). There will be options for late delivery, but this will have a negative influence on your grading.

The first assignment counts 20% for the total grade that you will get for all practical assignments.


Important information:
  • Read the information on this page and in the assignment carefully!
  • Read the information on this page and in the assignment carefully!
    No, this is not a copy-paste error, but experience shows that it makes sense to stress this more often ;)
  • Take the deadline serious. Also consider that the server might be overloaded shortly before the deadline. Since this is also what happens in "the real world", related excuses will not count.
  • Unlike the following two assignments, this is a pretty easy one, where you basically get almost full credit (8 points) for just doing a tutorial. The reason for this is that there are also students in this course with limited experience, and they should have a fair chance to "catch up" with the others. More experienced students are welcome and encouraged to start working on the second assignment early on (i.e. way before the deadline of assignment 1).
  • Because it is so easy, we will be very critical considering coding style and comments, so be sure to make them well.
  • Last year, some students just copy-pasted code from Riemer's tutorial for the bonus assignments. Note that copying existing code is normally considered plagiarism and can be a reason for exclusion from the course. In this particular case however, we are of course expecting that many people will look at the tutorials (well, we are actually hoping you will because we want to encouraged you to look around various resources yourself). So, we expect that your code might look quite similar. However, just copying-pasting it is not ok, since the assignment explicitly notes that we want comments that reflect that you understood what is going on. So, no bonus for people who just copy-paste, some bonus when they clearly put at least some effort into it, and full bonus for people who have good comments, good and consistent code structure, and some modifications that reflected that they really wrote it and didn't just copy it (e.g. by making the variable names match consistently with the naming style in the rest of their code).
SECOND ASSIGNMENT (BASIC SHADER PROGRAMMING)

In the second assignment you will learn some basic shader programming. Please refer to the slides from the introduction talk given by the TAs to make yourself familiar with terms such as "pixel shader" and "vertex shader" and the references listed in the assignment (esp. the HLSL reference guide). Note that because you are (hopefully) starting to get more experienced with graphics programming by now, we expect that you look up these and further references and take them into account when you are encountering any problems with the assignment. Of course, you are also always welcome to contact the teaching assistants if you have any problems or questions.

Here is the assignment and further files that are needed: Notice that some of the theoretical background needed to complete some exercises will be covered later on in the lecture, esp. the one about texture mapping. We will discuss it soon, but students who already want to start with it are welcome to read the related chapters in the book (cf. references in the assignment) or listen to last year's lectures on texture mapping (part 1 and part 2). I might make some minor changes for this year, but it should be easy to figure out what parts are relevant for the programming assignment.

Deadline for the second assignment is Tuesday, June 4, 15h00 (strict). The deliverable (zip file as specified in the gray box on the first pages of the assignment) has to be uploaded via the SUBMIT system. There will be options for late delivery, but this will have a negative influence on your grading.

The second assignment counts 40% for the total grade that you will get for all practical assignments.



Important information:
  • Deliverables:
    Make sure you follow the instructions (including file structure, naming convenctions, read-me file, etc.). We have to grade >180 students this year, so we will not have the patience to spend extra time on a sloppily prepared deliverable.
  • Re-using code and software plagiarism:
    It should be a matter of course that reuse of existing code is not permitted (except for when it is explicitly noted, e.g. if you download a normal map and use it in the bonus assignment, that's ok; to avoid possible conflicts, it's a good idea to leave a related note about this in your read-me file though). We will use software to detect plagiarism. Students who get caught cheating will be reported to administration and fail the course.
  • Grading procedure:
    Because of the large number of students in this course, we will not be able to discuss the code individually with each team. For most students, the grading will therefore purely be based on their delivery. We will however randomly pick a few teams and have an individual session with them where they have to explain parts of their code to us. In general, each student should have a rough idea of the whole code that is delivered by his/her team and a detailed knowledge of the parts implemented by him/herself. If you are among those teams, you will be informed about the details by email.
  • Team work and how to split work:
    Assignments should be done in teams of 2-3 students. It is up to you if or how you split the work across team members. We expect that in the end, every team member has made some significant contributions to the code. As said above, each student should be familiar with the whole code on a higher level (e.g. can explain the overall structure of it), and very familiar with the parts written by him/her (e.g. can explain all details of these parts).
  • Problems with team members:
    Be prepared that members of your team might decide to stop with the course and not deliver what they promised to do. Also, unfortunately not everyone works as reliable as one might hope. Make sure to be prepared for such situations. For example, last year there were cases when students said that their 3rd team member dropped the course and because they didn't have contact with each other for 3 weeks, they now don't have the parts of the deliverable that he promised to do. Of course, they can't be blamed for the lack of commitment of their team member, but they can be blamed for bad team work. Working together includes that you constantly stay in touch with each other, even if you strictly split the tasks. Make sure to monitor each others progress, and share your code, so you can react appropriately even if individual team members cause problems or drop out!
We also recommend registering at the forum for the practicals and checking the related thread regularly, because the TAs might post valuable tips & comments there. You are of course welcome and encouraged to post your own questions there as well.
THIRD ASSIGNMENT (ADVANCED SHADER PROGRAMMING)

In the third assignment we will do some advanced shader programming. Here is the assignment and a related model: Notice that that this is the most difficult assignment of the three. Make sure you start in time! Don't be mislead by the word "easy" in parts of the assignment - "easy" is a relative term ;)

Deadline for the third assignment is Thursday, June 27, 15h00 (strict). The deliverable (zip file as specified in the gray boxes on the first pages of the assignment) has to be uploaded via the SUBMIT system. There will be options for late delivery, but this will have a negative influence on your grading.

The third assignment counts 40% for the total grade that you will get for all practical assignments.



Important information (similar to the 2nd assignment):
  • Deliverables:
    Make sure you follow the instructions (including file structure, naming convenctions, read-me file, etc.). We have to grade >180 students this year, so we will not have the patience to spend extra time on a sloppily prepared deliverable.
  • Re-using code and software plagiarism:
    It should be a matter of course that reuse of existing code is not permitted (except for when it is explicitly noted, e.g. if you download a normal map and use it in the bonus assignment, that's ok; to avoid possible conflicts, it's a good idea to leave a related note about this in your read-me file though). We will use software to detect plagiarism. Students who get caught cheating will be reported to administration and fail the course.
  • Grading procedure:
    Because of the large number of students in this course, we will not be able to discuss the code individually with each team. For most students, the grading will therefore purely be based on their delivery. We will however randomly pick a few teams and have an individual session with them where they have to explain parts of their code to us. In general, each student should have a rough idea of the whole code that is delivered by his/her team and a detailed knowledge of the parts implemented by him/herself. If you are among those teams, you will be informed about the details by email.
  • Team work and how to split work:
    Assignments should be done in teams of 2-3 students. It is up to you if or how you split the work across team members. We expect that in the end, every team member has made some significant contributions to the code. As said above, each student should be familiar with the whole code on a higher level (e.g. can explain the overall structure of it), and very familiar with the parts written by him/her (e.g. can explain all details of these parts).
  • Problems with team members:
    Be prepared that members of your team might decide to stop with the course and not deliver what they promised to do. Also, unfortunately not everyone works as reliable as one might hope. Make sure to be prepared for such situations. For example, last year there were cases when students said that their 3rd team member dropped the course and because they didn't have contact with each other for 3 weeks, they now don't have the parts of the deliverable that he promised to do. Of course, they can't be blamed for the lack of commitment of their team member, but they can be blamed for bad team work. Working together includes that you constantly stay in touch with each other, even if you strictly split the tasks. Make sure to monitor each others progress, and share your code, so you can react appropriately even if individual team members cause problems or drop out!
If you haven't done so already, we strongly recommend registering at the forum for the practicals and checking the related thread regularly, because the TAs might post valuable tips & comments there. You are of course welcome and encouraged to post your own questions there as well.

(c) Wolfgang Hürst