Project 2 Handin Instructions

by Mike Gleicher on December 7, 2014

With something as big as project 2, getting to us is a bit of a trick.

Remember that everything needs to get to us before Saturday morning!


You will need to turn in:

  1. All the files needed to build and run your project 2.
  2. Some pictures/screenshots of your system in action.
  3. Documentation of what you did.
  4. A handin form (on the web)

Parts 1-3 will be a single ZIP file that you turn in via Moodle. In the event that your file is too big to turn in by Moodle, we will have alternative methods to turn it in (see below). Do not send us files by email!

Every person must do the handin form! Yes, if you worked as a team, each person must do the handin form. (the form isn’t ready yet – look for an announcement of it).

Each team (which may be a pair of people) only needs to turn in one ZIP file. Everyone should turn in something via Moodle. If your partner is turning in the ZIP file, put a note saying that (remember to say who your partner is!).

Everything you turn in should be in one zip file! (plus you have to fill in the web form)

What to do with that (potentially Giant) ZIP file

If your ZIP file is less than 20MB, you can upload it to Moodle. That is the preferred method.

If your ZIP file is more than 20MB, check to make sure that you haven’t included any extra stuff that you don’t need. For example the Visual Studio debugging files (.pdb, .idb) – or generally anything in the “Debug” or “Release” folders isn’t necessary. Nor is the “.sdf” file (which is often gigantic).

But if you have a big ZIP file, put it in your AFS public folder (U:/public) and tell us how to find the file in the Moodle handin.

Do not send us files by email!

You can also try some other web-based way of sending the file. For example, the University gives you a file sharing account, and you could send us a URL for the sharing link (Dropbox is similar). Again, be sure to put all the information in the Moodle handin (and on the handin form). Do not “share” the file with us: send us a link to the file.

What to turn in for your program

You need to include all files necessary to build and run your program. We need to be able to double click on the .sln file, press “Ctril-F5”  (that’s run without debugging) and have your program build and run. But sure to include all the code files, the solution file, and any data files (shaders, images for textures, models, …) your program needs. Don’t forget the Utilities folder! (some people forgot those with P1)

Hopefully, we will be able to download and try all programs early on Saturday, so if we encounter a problem we can contact you. However, there is no guarantee that we will be able to have time to let you fix something that is broken, or that we won’t penalize you if we have to fix something that is broken.

You an assume that GLM and FlTK are installed the way that they are on the CSL lab computers (e.g. the same as the prior projects and assignments).

What to turn in for your screenshots

You need to turn in at least 2 screen shots of your program, showing off it’s nicest features. You can turn in up to 20 pictures. Please do not turn in more than 20 pictures!

You may want to pick pictures that show off the things you write about in your documentation / on the web form. For example, we’ll ask you questions like “what is the coolest object you made” – you can have a picture of it. Or, if you are describing a technical challenge you did, it can be handy to refer to a picture (“see screenshot7.jpg for an example of my subdivision surfaces apply to make a car”).

You should definitely include a picture of something if it’s hard to see or that we might miss it when flying around playing with your program.

Note: All of your pictures should have captions. One line descriptions for each picture. This can either be a separate text file, or make a big document file (word, html, pdf) that has the pictures with the captions below it.

Note: even if you give us the pictures inside of another document (your documentation or your captions file), please also give us a set of JPG or PNG files for your screen shots.

What to turn in for your documentation

Because we aren’t doing live demos, it is really important that your documentation explain what you’ve done, otherwise, we may not know about it!

Some of the documentation will be redundant with the web form. That’s intentional. Write it in your documentation, then cut and paste into the text boxes on the form.

Make sure your documentation is clear about:

  1. Who did the project (name both partners – only one person needs to turn it in)
  2. The overall theme/description – what were you trying to do with your town.
  3. How you filled all of the requirements (list the requirements, and the things that you did to fill them – for example, name of one the curved objects)
  4. The technical challenges that you attempted, and how they appear in your program. For example, it’s not enough to say “I did subdivision surfaces” – your documentation must tell us the details of how they work, where we can see them in your city, and why you think you know that they are working correctly. For an important technical challenge, you might want to include a screenshot.
  5. Anything you are particularly proud of. If there’s a really cool object hiding some place, or something which is more interesting than it appears, be sure to say so.
  6. Where you got pieces from. If you used a model loader or library, say so – and where you got it. If you took a model or an image (for a texture), give proper attribution (say what and where it came from). If you took a code fragment from someplace (like a shader copied from a tutorial), make sure you list it. Academic honesty requires giving proper credit for parts you borrow.

Turning in your document as a Word file or PDF is good – especially if you put pictures into it (but some screenshots need to be submitted separately).

The online form

You will need to fill out an online form. A lot of the material will be redundant with the documentation – this is a good check to make sure you have it all there! In particular, don’t expect that we can get all the technical challenge details from the form – we will look at your documentation! The form is here.

Important: everyone must do the online form. Even if your partner is turning in the project.

The online form tells us the highlights of your project so we know where to look first when grading. It also helps us make sure all the checkboxes get checked. In the past, this was a checklist we went through during demos.

If there are problems…

If you have problems turning things in, send email to both the Professor and TA as early as possible – preferably before Friday night when things are due the next morning!

Do not send us files by email. We will not look at them.

If we have problems getting your files and/or building your program on Saturday, we may try to contact you via email. You might want to check your email on Saturday to see if we have a question. We may also try to find you at the exam to ask you questions (preferably at the end, after you turn things in).

We really will be grading these on Saturday, so it really is important that you turn things in before then.


  1. Everything in one ZIP file, preferably turned in via Moodle
  2. Everyone (both partners in a pair) fills out the web form

{ 1 trackback }

Previous post:

Next post: