Visualization and Graphics ➤ Interaction ➤ Dept ICS ➤ Faculty of Science ➤ UU

//webspace.science.uu.nl/~telea001/Site/TopBar

Frequently Asked Questions

1. What do I need to deliver to pass?

See the Assignment page (longer answer: report, code, and final presentation).

2. How do I get feedback/hints along the way?

The lecturer will discuss various tips and tricks concerning the assignment during every lecture. So, make sure you are present at the lectures (and ask questions if needed)!

Separately, you are asked to provide incremental progress reports on your work, once per week. Do this by mailing the lecturer. This includes submitting the current state of your report (PDF). That is, you develop the assignment and write the report in parallel, and send your progress-so-far to receive comments and feedback. This way, you don't need to allocate massive amounts of time at the end of the course to write your final report!

3. This is a lot of work! How to handle this?

You are allowed (actually advised) to work in groups of three, since, indeed, the assignment is quite heavyweight. Note that which partner(s) you find is entirely up to you to choose. Also note that a single grade will be given per group (so make sure you work smoothly together with your chosen team!)

3. Do I need to be at the final presentation?

Short answer: Yes, since you will be there to demo your work and also answer questions. Each group gets one presentation slot. Make sure that all persons in the group present during that slot (who present what is up to you to organize, as long as the split is balanced).

4. When is the deadline to hand in the code and report?

This is announced separately via online means (e.g. Blackboard, Teams, mail). Handing in:

  • code: Using Dropbox, GitHub, or similar file-sharing services is allowed, but you should make 100% sure that the sent material can be opened/read by the lecturer. Do not use mail as attachments are size-limited!
  • report: This should be sent by mail to the lecturer (PDF format only).

5. Do I have to be present at all the lectures (and/or labs, in case we have labs)?

Very strongly encouraged. As noted above, hints/tips concerning both the theory and practice (assignment) will be given and discussed during the lectures, so you'd better be there. Same for the labs as concrete programming/debugging/evaluation tips are given. In emergency cases, if you need to skip a lecture/lab, make sure your group-parter(s) will be there.

6. Which additional material do I need?

See the Readings page for a set of suggested books. As noted there, none of these is compulsory. The page includes also several key articles. You can successfully take (pass) the course if you are present at all lectures, take notes of what is discussed there, ask questions, and study the slides and Additional material carefully.

7. What do I need to know beforehand to take this course?

To be able to successfully complete this course (and have fun doing it), you should

  • have a good background in linear algebra (matrix-vector operations, determinants, dot/cross products)
  • have a minimal background in calculus (1st and 2nd order derivatives, gradients, finite differences)
  • have a reasonable background in computer graphics (3D meshes, viewing transformations, rendering)
  • be really fluent in a mainstream programming language (C/C++, Java, Python). This is really important since the assignment is pretty programming-intensive!

8. What to do if I get stuck at an assignment step?

First of all, be calm:) This does happen as the assignment is pretty complex. Next, as usual in computer science, divide-and-conquer to find where the problem is and what causes it. Useful tips:

  • study, then code: Do not jump into writing code just because you can. Make sure you read the corresponding slides/documents, and browse through the relevant code samples and demos. This can make you save a LOT of time by avoiding false starts and unnecessary experimentation.
  • plan a design: Again, do not jump into coding. Plan a modular design of your entire system first (after having read the entire assignment). Decide which programming language, tools, and libraries you will be using. Then start coding.
  • start simple: a few simple 3D shapes, a small shape database. Don't attempt to process hundreds of models right away;
  • do things one by one: for instance, implement/test a single feature (from simplest to more complicated) on a few shapes, then on all shapes; check results; only then advance to the next feature;
  • simplify where possible: Use a single format/data structure to store all shapes; do not proliferate useless designs e.g. trying to support all possible 3D mesh formats; converting all shapes to a single, easy-to-read, format (e.g. PLY or OFF) and using that format onwards can also save time;
  • be minimalistic: A common error is to start building an over-complex user interface (GUI). This is not really needed for this assignment and costs a lot of time! A fully working system can be actually built using a single (simple) viewing window and key-based commands.

9. My query results don't look good at all. What next?

First of all, do not panic. CBSR is notoriously difficult, and the databases part of this assignment are very difficult (they are used in benchmarks for state-of-the-art systems developed by far more advanced researchers than MSc students).

That being said, try to qualify your impression that your system is not working well. What does this mean precisely?

  • start with simple shapes; does the system really return a completely unrelated shape for a query? Does this happen when querying any kind of shape, or is it only happening for certain shapes?
  • check you loaded/parsed the mesh files correctly, e.g. by displaying them
  • if problems occur with a certain mesh, load it into GeomView and analyze it for problems such as degenerate faces, duplicate vertices, or holes. If these are present, skip the shape from the database.
  • make sure you executed the 4-step shape normalization correctly. This is easiest done by viewing the shapes after normalization - they should all be nicely aligned and scaled the same way.
  • make sure you extract your features correctly. For simple features, such as bounding boxes, it should be pretty simple to check the extracted values by hand. For other features, test them on simple shapes for which you know the ground truth (for example, a sphere should have a very high compactness; a snake-like shape, not).
  • make sure you standardize your features, so they all have (about) the same range before plugging them into the distance computation.
  • debug the distance function: manually invoke it for a shape against itself. You should get zero. Manually invoke it for two very similar shapes. You should get a low value.
  • do not get put off by a few bad retrieval results. The aggregated evaluation (Step 6) will show the final picture, which may be better than expected!

10. Which programming language/operating system should I use?

Entirely up to you. You can e.g. develop under Windows, Linux, or Mac OSX (as long as you deliver a working codebase at the end with clear building instructions).

Recommended development languages (in no particular order):

  • C/C++: high-performance; many 3D mesh libraries/tools/code samples are written natively in C/C++. Also easy for interfacing with OpenGL and/or other graphics toolkits. Bit more verbose than Python though.
  • Python: decent performance; comes with extensive libraries for statistics, math, machine learning, feature processing, charting. Bit less easy to interface with graphics toolkits.
  • Java: somewhere between the above two.

Above all: Choose a programming language you are really comfortable with. Note that you can code various assignment parts in different languages if this helps you.

11. Should I complete one assignment step per week or...?

Short answer: No. Read the Assignment carefully. The first steps (1,2) are quite easy, you should complete them in at most 2 weeks both. Step 3 is more complicated, it may take 2 weeks. Step 4 is quite simple, it may take less than 1 week. Step 5 depends a lot on the quality of implementation of the previous steps and your general coding skills (could take 1 week, less, or 2 weeks). Step 6 should not take more than 1 week if all before that is finalized well.

Note that the above are only rough guidelines! Every student has his/her own rhythm, which is hard to gauge upfront. The following guidelines are good to keep in mind:

  • if a step takes more than 2 weeks, then this is a serious warning sign!
  • push hard from the very beginning; every day you save is a day you have more for the next steps
  • we will not ask you to complete a certain step during a certain week. After all, this is a MSc course, and time management and planning is part of a MSc student's skills (to be assessed by this course). However, we will draw warning alarms when/if you are definitely lagging behind.

12. So, this final presentation. What is a good example?

See this example. It is from a 2020 edition of the course, and a presentation I graded highly. Of course, this is just a slide set. The talk is not there. Still, it should give you a good idea of what we're expecting.

Above all:

  • be timely: Do work every week; don't let things get delayed so you have to do a lot in the last week(s);
  • be critical: Test, test, test: After implementing every step, check your results against ground-truth e.g. by displaying computed values and comparing them with ground-truth known values for simple cases (shapes). Do not advance to the next step until the current one is not fully tested.
  • be proactive: Send weekly intermediate versions of your report, highlighting (e.g. on the first intro page) what was changed/added, so the lecturer can provide you with feedback;
  • write as you go: Once you completed a step, write the corresponding report piece (e.g. section) and send the intermediate report for feedback to the lecturer. This way, you receive timely feedback and calibration (i.e., how well you're doing), and you don't have to catch back massively as the end nears.
  • have fun :) Multimedia Retrieval is surprising, challenging, interactive, and a great source of creativity!