Project Instructions (DGI16)

Project 'spirit' and topics • An aim of the project is to start to develop you as a proactive and autonomous researcher in computer graphics and animation. That takes practice and time - you may not get everything right the first time you try. A good way to start the process is to create a project specification and seek feedback from the course team. It is up to you to ensure this! The more specific the details you provide in a specification, the more useful the feedback you will likely receive. Ideally, the process is iterative (you continue to update your specification and seek feedback throughout the project).

• You may choose your own project topic, but it is up to you to ensure that it complies with the objectives of DH2323 (easy way: write a specification and send it to the course team). As above: the more specific project specifications will enable us to provide more useful feedback. As above, this will likely be an iterative process as you may not have a lot of knowledge about your topic at the beginning of the project.

• One starting point for project ideas is to look at related conferences and books. Note that these are quite challenging and will often be for those aiming for higher project grades (unless you are simply looking for ideas). Publications from many other iterations of these conference are available online with a bit searching.

Conferences:

http://s2014.siggraph.org/

http://eg2014.unistra.fr/

http://chi2014.acm.org/

http://www.csee.umbc.edu/csee/research/vangogh/I3D2014/

Books:

http://http.developer.nvidia.com/GPUGems/gpugems_part01.html

http://http.developer.nvidia.com/GPUGems2/gpugems2_part01.html

http://http.developer.nvidia.com/GPUGems3/gpugems3_part01.html

• Other starting points include the various blogs from previous projects on this page or even projects mentioned on this page. Many of the general ideas from these projects can be scaled in terms of sophistication and scope to fit interesting projects. There is also a project wishlist here.

• Still not sure what to do? Talk to me! I usually have suggestions of a variety of interesting projects waiting to be done!

Deliverable Your project deliverable should be comprised of:

o A comprehensive project report. This is a textual and graphical description of how you designed the program, how it works and the theoretical aspects relating to the techniques used. This explanation should be written by you and relate to your own code (i.e. be more than simple general definitions from the lecture notes). See the “Marking Guide” below.

You should include your original project specification as an Appendix in the report (see here for an example of an MSc project specification).

o A link to a blog describing the progress of the project. If elements of the blog are relevant to the report, then they may be used to comprise parts of the report (although other aspects, such as individual contributions to the project may be less suitable to the blog).

o The commented source code, project files and executable for the application in a sensible directory structure.

o Some screenshots (or even better, a small movie demonstration), where appropriate, of the output of the program - something else that is nice to integrate into a blog. If using Unity, you may like to include a web player version of your project on your blog: it's very easy to create.

Details

• You may work individually or in groups up to size three. You should clearly identify respective contributions of group members to the final project i.e. the report should contain an explicit section outlining the individual contributions of each member of the group to the project.

• Your project - including all source (code, models, textures), executables and accompanying documentation – should be archived in .zip or .rar format and uploaded to Bilda. Do not forget to include the names, student IDs and official KTH email addresses of all members on the documentation.

• You may use any completed DGI15 lab-work, and the supplied code from the labs, as a basis for completing a project (see marking guide for details of incremental lab work). But make sure to reference all work used from sources and all collaborations, and do so clearly by identifying what sections of work you have completed.

• Make sure to keep a local copy of the source code, executable and other materials related to your project.

Project Reporting • Identification details on report. Names and student IDs and official KTH email addresses of all members.

• One-two page project specification.

• Clear, logical structure with headings and subheadings; well presented. Critical reflective evaluation of what you did, why you did it, what you learned. Anything interesting/surprising along the way? How did you solve challenging problems?

• Screenshots providing evidence of functionality where appropriate. A small, narrated movie demonstrating your program and its creation would be a great addition. Blogs describing progress and tutorials are also beneficial. Relevant blog entries may be taken to form report sections.

• A half page description of how the project could be improved by, informed by or related to perceptual user studies, with details from a user study that you attended.

• References to resources used and collaborations. Be explicit about exactly what work is yours and what belongs to other group members and external sources.

• References and description of state-of-the-art international work in the topic of the project and how your project relates to it.

• Presentation all of the above in a clear and concise way.

Project Grading Every project is different and will be marked based on its individual merits. However, there are some generic requirements. You should check with the course team for feedback on your project idea if you have doubts or questions. Generally, the more specific your specification/idea is, the better the feedback that you will receive.

Indicative requirements Scale Fully functioning, coherent implementation and demonstration, utilizing a good mix of graphics technologies (which should include a significant graphics programming aspect, but could also relate to modelling, interaction, perception and so on); comprehensive report. Demonstrated excellence in communication of concepts - through an illustrated blog, for example. A – C, depending on level of challenge, sophistication of results, presentation and level of achievement Small functional graphics program. Examples:

1) Extending one of the labs in order to add minor additional features;

2) A limited 3D graphics modelling project imported into Unity;

3) Another small project of your choice (check with course team).

All should include a comprehensive report.

D – E, depending on level of challenge, sophistication of results, presentation and level of achievement Additional Notes and Miscellany:

• Projects do not have to be programmed in C++, although it is desirable. One recommendation for higher grades is to re-implement a graphics and animation technique from a research paper as a C++ DLL and integrate it into the Unity engine.

• You may do projects related to plug-ins and scripts for 3D modelling software such as Blender, Maya, Max, but you should ensure that there is a programming aspect to the project (e.g. scripts to generate automated content). You can also use any engines, SDKs and libraries as required o support the project.