CS321 -- Lab 6: Transformations



->Courses
->CS321
-->Presentation
-->Lab 1
-->Lab 2
-->Lab 3
-->Lab 4
-->Lab 5
->Lab 6
-->Lab 7
-->Lab 8
->Electronic Submission
->Old Exams
->C++ Examples
->Unix Help
->Software
->Tentative Schedule
->Course Policies

[Courses]
[Rich][Home][Rich]
[Author]

Fall Quarter 2001

Purpose

The purpose of this lab is to develop a deeper understanding of two dimensional transformations.

Acknowledgement

This lab was developed by Dr. Henry Welch.

General Lab Information

Without removing any of your existing drawing capability (points, lines, polygons, and color) add functionality to your graphics system to support the following new features.

  • Implement support for the following shell buttons by overriding the respective Shell member functions:
    • Zoom - Scale by a factor of two about the drawing window center (the window is 500x350). For (not much) extra credit figure out how to query the drawarea widget to find the real window center.)
    • UnZoom - Scale by a factor of 0.5 about the drawing window center
    • Reset - Draw each shape in the original space (before any transformations).
    • Erase - Erase the image and free any dynamic memory associated with drawing objects.
  • Add commands on the command line to:
    • Rotate by any angle about any point
    • Select any point so that it is now drawn at the center of the drawing window (origin translate)
  • Don't forget to update your help information

Transformations often present a number of numerical problems to the graphics programmer. If implemented without thinking carefully the original drawing data can be corrupted beyond recovery. One of the best methods of doing this is to always maintain a copy of the original drawing data. As each transformation is processed have it base each shape on its original coordinates. This will prevent the rounding errors that can occur if we, for example, UnZoom and then Zoom using integer coordinate data. (This will also simplify Reset.) Nearly similar numeric performance can also be obtained by using floating point coordinates, but rounding may still be a problem, and in some cases the floats are computationally more expensive.

Some confusion always arrises on how to handle Reset. Reset sets the coordinate system back to before any shapes were drawn. This means that shapes drawn after one or more transformations must be inverse transformed to the original coordinate system. This can be done by keeping an inverse transform matrix that "undoes" all transforms to the present. This DOES NOT require a matrix inversion method if you think the problem through.

Constructive Suggestions:

  • Use a matrix class as the basis for your transformation information. Most of you should have something reasonably suitable from CS381. If you do not, you will be required to build at least a limited matrix class to support your needs here. Do keep in mind that you will need to extend your matrix class to handle three dimensional transformations in the future.
  • Have methods that build the basic transformations from their relevant parameters. (e.g., Build the rotation matrix from an angle.)
  • While the QPainter object does support some level of transformations they are not as general as MOST graphics systems require. Please implement your own work rather than spend excessive amounts of time trying to figure out Qt's mechanism.

Application demonstration

You should demonstrate the successful operation of your application before or during week 8 lab.

Lab report (due 11pm, the day prior to week 8 lab)

This lab report need not be self-contained. However, you should be sure to include all of the components listed below.

  • Discussion including:
    • A tally of the number of new Non-commented Lines Of Code (NLOC) written for this lab assignment. You should use the CLC perl script on your code. If possible, break the NLOC down into the various features you needed to implement.
    • A summary of your activity log indicating how much time you spent on each phase of the assignment. Please report the time in the following categories:
      • Designing
      • Coding
      • Debugging (before you think it's working)
      • Testing (after you think it's working)
      • Report writing
      • Other
    • A narrative describing any specific problems you encountered and how you solved them.
  • Conclusions (what you learned, suggestions of how the lab could be improved, things you would have done differently, etc.)
  • Documented source code (clearly identifying any changes made since your last submission). Note: you should include all the source code necessary to compile your project except for unmodified source code written by Dr. Welch. For example, you don't need to include shell.cpp if you didn't modify it.
    You may wish to use gensrc, a shell script which will produce an XML document that may be used as a starting point for your report. The file will include all of the source code files (provided you modify the script appropriately... edit gensrc for details on how to do this.)
  • Extra credit is available but only if it is clearly identified during the demonstration and in your report.
  • Be sure to address any areas concern from previous submissions.

As with any report you submit, correct spelling and grammar are required. In addition, your report should be submitted electronically following the Electronic Submission Guidelines. (You may wish to consult the sample report before submitting your report.) Be sure to keep copies of all your files, in case something gets lost. It may be wise to keep a diskette backup as well.

If you have any questions, consult the instructor.

© 1998-2001 Dr. Christopher C. Taylor Office: CC-27C Phone: 277-7339 Last Updated: May 9, 2001
I am responsible for all content posted on these pages; MSOE is welcome to share these opinions but may not want to.