Description
CPSC453 Assignment 1 Introduction to OpenGL Solved
General Specification of the Assignment
This assignment will practise working with graphics APIs (OpenGL, Qt, GLSL) to build a graphics
application. The assignment will be written in C++ using the Qt GUI toolkit. In this assignment
you will be working with simple OpenGL commands for drawing, using matrices for transformations and supporting basic GUI for interaction.
The application is a game, where the user controls falling block formations to create solid lines
within the well of game play. When a line is completed it is removed from the game. When blocks
reach the top of the well, the game is over.
This assignment is adapted, with permission, from Assignment 1 of CS488 – Introduction to Computer Graphics at the University of Waterloo.
Game Play
The game takes place in a U-shaped well of unit cubes enclosing a grid of width 10 and height 20,
in which the block formations can fall. The blocks occupy discrete positions in the grid (ie. they
don’t fall smoothly, but jump from position to position).
Block formations start within a four unit tall region at the top of the well. Every time a predetermined interval elapses, the current formation falls one unit. The value of 500ms is a good
novice interval; 100ms is more challenging. At any time, the current piece can be moved to the left
or right, rotated clockwise or counter-clockwise, and dropped the rest of the way down the well.
When the piece can fall no further, it stops and any rows in the well that are completely filled are
1
removed from the game. The game ends when a block cannot clear the starting region.
You should have at least three different speeds at which the block formations fall.
Interface
The user interface will be written in Qt, a cross-platform application and UI framework used in
industry by C++ developers. You will need to implement the follwing functionality. The letters in
”()” indicate the keyboard short cut; remember – both upper and lower case should work for the
keyboard shortcut.
• A File menu with the following menu items:
– New Game (N): Start a new game.
– Reset (R): Reset the view of the game.
– Quit (Q): Exit the program. (This one is already implemented – do not break it!)
• A Draw menu, with the following menu items:
– Wireframe (W): Draw the game in wireframe mode.
– Face (F): Fill in the faces of the game. Each different piece shape should have its
own uniform colour.
– Multicoloured (M): Similar to Face mode, but each cube has six faces of different colours (ie. no two faces should have the same colour). Funky colours and
combinations are encouraged.
The Draw menu should use radio buttons to indicate which state is selected.
• A Game menu, with the following menu items:
– Pause (P): Pause the game.
– Speed Up (Page Up): Increase the speed of the game play.
– Slow Down (Page Down): Decrease the speed of the game play.
– Auto-Increase (A): Slowly and automatically increase the speed of the game
play.
A QTimer may be helpful with setting up game play timing.
• Mouse Movements:
– Mouse operations are initiated by pressing the appropriate mouse button and terminated
by releasing that button. Only motion in the horizontal direction should be used.
2
– The left mouse button should rotate the game around the X-axis.
– The middle mouse button should rotate the game around the Y-axis.
– The right mouse button should rotate the game around the Z-axis.
– When the shift key is pressed, use of any mouse button will uniformly scale the
game – both the board and the pieces. When the mouse moves to the left, the game
should become smaller. When the mouse moves to the right, the game should become
larger. The maximum and minimum scales should be restricted to a reasonable range.
You will need to make reasonable decisions about how much to scale or rotate for every
pixel’s worth of mouse motion. For example, if the mouse isn’t moving, there should be no
scaling or rotation.
You are also required to implement a feature known as “persistance” or “gravity.” If, while
rotating, the mouse is moving at the time that the button is released, the rotation should
continue on its own. This decision should be made at the time of the release; after that it
should persist independently of mouse movement, until the next button press.
• Keyboard Input:
– The left arrow key should move the currently falling piece one space to the left.
– The right arrow key should move the currently falling piece one space to the right.
– The up arrow key should move the currently falling piece counter-clockwise.
– The down arrow key should move the currently falling piece clockwise.
– The space bar should ‘drop’ the piece, sending it as far down into the well as it will go.
Much of these actions are already implemented within the provided game code (game.h,
game.cpp), however you will need to construct the appropriate GUI and OpenGL for handling
and displaying this functionality.
Qt, OpenGL and C++
Qt provides a great deal of GUI management, and has recently expanded to offer more support
for OpenGL-style commands. For the assignment, you are to use the OpenGL commands directly where possible. If needed, using Qt to assist with shader loading is permissible. Use of the
QMatrix4x4 Qt class, and other such classes is permitted.
When building your data buffers to send to the provided shader (ie. vertices, per-vertex colours and
per-vertex normals), use Vertex Buffer Objects and Vertex Array Objects. This
is a more efficient display style.
For more information, see the Qt documentation: http://doc.qt.io/qt-5/.
3
Walk Through
The provided source code is a good starting ground for building your application. This includes:
• main.cpp – The main entry point for the program.
• renderer.cpp, renderer.h – The OpenGL widget, where all of the OpenGL-related
code should go.
• window.cpp, window.h – The application window. Most of the GUI-related code
(menus, etc.) should go here.
• game.cpp, game.h – A game engine that implements the core of the falling blocks
game. Should not need to be modified.
• per-fragment-phong.vs.glsl – Vertex shader used to determine the position of every vertex. Should not need to be modified.
• per-fragment-phong.fs.glsl – Fragment shader used to determine the colour of
each pixel. Should not need to be modified.
To compile and run the start program, execute:
qmake -project QT+=widgets
qmake
make
./a1
The provided code creates a user interface with an OpenGL window. As a test, it draws triangles
where the corners of your game (not including the well) should appear. The camera is setup so
that the triangles appear centered and correctly sized. You need to modify this code to render the
current state of the game and respond to user interface events. A suggested to-do list, in an order
that will help you is as follows:
• Write a function to draw a unit cube using OpenGL.
You can write a single cube to a Vertex Buffer Object (VBO). You would then create a
Matrix4x4 model matrix for each cube and use the matrix functions to translate, rotate and
scale this model. You will need to have a buffer of per-vertex unit-length normals to pass to
the shader as well. These may be hard-coded for this assignment alone.
• In your render function, draw a U-shaped border for the well, out of the cubes.
• Implement face rendering and wireframe rendering.
4
• Implement rotation and scaling. You should be able to see the effect on the well.
• Add code to draw the current contents of the game. Each piece type should be drawn a
different colour – the colour is up to you.
Note: The colour is sent off to the shader similar to the vertices.
• Hook up a simple timer (using the QTimer class) that calls the game’s tick method, and
re-renders. You should be able to see pieces falling.
• Implement the rest of the controls for game play and the remaining user interface.
Bonus (20 Marks)
There are lots of ways this simple application could be modified to enhance playability and attractiveness. You are encouraged to experiment with the code to implement these sorts of changes, as
long as you have already met the assignment’s basic objects. The maximum additional marks from
bonuses is 20.
• A scoring mechanism. (5 marks)
• Head-to-head networked play. (10 marks)
• Modified cubes for pieces. The blocks look much better if individual cubes have their edges
slightly beveled. (5 marks)
• Animations for certain events. For example, having the board spin around when you lose. (5
marks)
• Additional light and lighting – requires shader modification. (10 marks)
If you make an amazing modification (an actual feature, not an unintended bug…), document it in
your README and it will be considered and graded at the discretion of the TA.
If you make extensive changes to the game, additionally offer a “compatibility mode” by default.
You should support at least the user interface required by the assignment. You can activate your
extensions either with a special command line argument or a menu item. Document this in your
README file.
Non-functional Requirements (20 Marks)
Documentation
1. You must provide a README file. A sample one has already been provided.
5
2. Your README file should contain:
(a) Your name and UCID.
(b) Short description of algorithms you implemented to complete the program.
(c) A brief description of the data-structures you used to implement the assignment.
Source Code
1. All your source code must be written in C/C++ and properly commented. All graphics rendering must be done using OpenGL. All event handling and windowing must be performed
via Qt. Your source code must compile on the lab machines in MS 239 without any special
modifications. Your source code must be clear and well commented.
2. You will lose marks for inefficient and slow implementations.
3. You may reuse source code:
(a) which has been provided by the instructor for use in the course,
(b) which has been written by you which implements basic data structures, such as linked
lists or arrays,
(c) which you have received permission from the instructor or one of the TAs of CPSC 453
prior to handing-in your assignment,
4. Any instances of code reuse by you for this assignment must be explicitly mentioned within
the README file. Failure to do so will result in a zero in the assignment. Please read the
University of Calgary regulations regarding plagiarism http://www.ucalgary.ca/
honesty/plagiarism.
Functional Requirements (80 Marks Total)
Display (25 Marks)
1. Support wireframe mode. (10)
2. Support face colour mode. (10)
3. Support multicoloured face mode. (5)
6
Game Play (25 Marks)
The user should be able to:
1. Increase the speed of the game play (5)
2. Decrease the speed of the game play (5)
3. Work with the user interface as specified (menus, mouse interactions, etc). (10)
4. Play with the game as described under “Game Play.” (5)
Transformations (30 Marks)
1. The game can be rotated. (10)
2. The game can be scaled. (10)
3. Persistence works for rotation. (10)
Lost Marks
Possible areas for losing marks:
• Polygon vertices should be specified in counter-clockwise order (otherwise you may not see
the face if you have backface culling on).
• Persistent rotation shouldn’t start because of mouse movements for scaling.
• Persistent rotation shouldn’t start, get faster, nor slow down on its own.
• Normals should all point outside the cubes.
• Radio button should be initialized correctly.
• Persistence should only happen when the user releases the mouse button while the mouse is
moving.
• Not allowing the user to use two buttons at the same time.
• Allowing negative scaling.
• Jerky persistence.
• Rotation and scaling should be continous, which means should start from where it was left
last time and not resetting.
• Uncontrollable rotation, scaling etc. e.g. Game rotates constantly, rotates a bit and resets
right away, etc.
7
Demo
You are required to give an approximately 5 minute live demo to your TA. Failure to show up at
the presentation will result in a zero in the assignment. You will need to schedule your demo with
your TA – they will have details about how your tutorial section demos will run.
8
CPSC453 Assignment 2 Graphics Pipeline Solved
Overall Description
You are to write a program that displays and interactively manipulates a wire-frame box that you
should construct with vertices at the 8 unit points (±1, ±1, ±1).
You are to provide a set of coordinate axes (a modelling gnomon) that you should construct with
three lines, drawn from (0, 0, 0) to (0.5, 0, 0), (0, 0.5, 0) and (0, 0, 0.5) respectively. This gnomon
will represent the local modelling coordinates of the box, and it must be subjected to every modelling, viewing and projection transformation applied to the box, except scaling.
You are also to draw a separate set of axes for the world coordinates, which are the same size
(coordinates) as the modelling gnomon, but are alinged with the world coordinate axes instead
of the modelling axes. The world gnomon should be at (0, 0, 0). You should subject this world
gnomon only to the viewing and projection transformations. Note that the gnomon are merely
graphical representations of the coordinate axes; for the coordinate axes themselves you should
use orthonormal bases.
You are to apply modelling transformations to the box (rotations, translations, and scales) and
viewing transformations to the eyepoint (rotations and translations). Transformations will be
menu-selected and will be applied according to mouse interactions. Specifically, x motion of
the mouse will be used as a controller to the amount of each transformation, and the mouse buttons
will be used to select the axis of the transformation, and a menu will be used as the choice device
to determine the major modes of the program’s execution.
You will need to maintain four distinct coordinate systems in this assignment. Three of these coordinate systems are 3D and one is 2D: the box (“model”) coordinates (3D), the eye point (“view”)
1
coordinates (3D), the universal (“world”) coordinates (3D) and the display (“screen”) 2D normalized device coordinates (which arise from the perspective projection of the eye’s view onto the
eye’s x − y plane).
The modelling transformations apply with respect to the model coordinates (ie. a model mode
rotation about the x axis will rotate the box around its current x axis, not the world’s x axis). The
viewing transformations apply with respect to the view coordinates (ie. a view mode rotation about
the x axis will appear to swing the objects of the view up or down on the screen, since the eye’s
x appears parallel to the screen’s horizontal axis). None of the modelling transformations will
change the world coordinates (ie. the world gnomon never changes its location, though of course
it may drift out of our view as a result fo the viewing transformations).
You are to form all the matrices yourself and accumulate all matrix products in software. You will
also do the perspective projection yourself, including the division to convert from 3D homogeneous
coordinates to 2D Cartesian coordiantes. This means that you will have to do a 3D near-plane
line/plane clip in the viewing coordinate system to avoid dividing by zero or having line segments
“wrap around.”
The Interface
As with the previous assignments, this is implemented in C++ with Qt. We have provided some
code for you that sets up a window and draws an example set of lines for you. You will need to
add the parts that do all the 3D transformations, projections, etc. Note that algebra.h, algebra.cpp
contains custom in-house class implementations of Point2D, Point3D, Vector3D, Matrix4x4 and
Colour. You are to use (and if needed expand) these classes rather than their Qt implementations, to demonstrate your understanding of the transformation matrices. Additionally, for drawing, you will not be using VAOs, VBOs, or any other OpenGL commands. Instead you will use
the set colour and draw line commands for any drawing. Examples of use are found in Renderer::paintGL.
We suggest you add a few matrices to the Renderer – which ones you add and what each means is
up to you. At the very least, you will need a modelling matrix and a viewing matrix.
You should implement the stub functions already found in Renderer and perhaps add some more
of your own. You will also want to implement the missing matrix functions in a2.h and a2.cpp
and use these in your Renderer.
Drawing Lines
In draw.cpp, we provide the following C++ routines to draw lines and set colours in an OpenGL
window:
2
• draw init(int width, int height) – call this before drawing any line segments.
It will clear the screen and set everything up for drawing.
• draw line(const Point2D& p, const Point2D& q) – draw a line segment. p
and q are in window coordinates.
• set colour(const Colour& col) – set the colour of subsequent calls to draw line.
• draw complete() – call this after you are done drawing line segments.
These routines use OpenGL. Your assignment should not contain any further OpenGL calls. Further, you should not modify draw.cpp. You should call these routines from renderer.cpp with the
GL widget active. There is already example code in renderer.cpp that does this for you.
Top Level Interaction
The menubar will support (at least) two menus: the File and Mode menus. The File menu will
have to selections: Reset (keyboard shortcut A), which will restore the original state of all transforms and perspective parameters, and set the viewport to its initial state; and the Quit (keyboard
shortcut Q) which will terminate the program. The Quit menu item and shortcut are already implemented in the provided code; be sure not to break it.
The Mode menu selections will be used to determine what effect mouse dragging on the viewing
area will have on the transformations. The Mode menu will consist of a list of radiobuttons which
select among the viewing and modelling modes, and a viewport mode. There should be an onscreen indication of what mode is currently active (eg. a status bar).
In any View and Model interaction modes, transformations are initiated with the cursor in the 3D
viewing area, up on a button down event. Relative motion of the cursor is tracked and the transformations are continuously updated until a button up event is received. The current interactive mode
should be presented in a status bar somewhere on the display widget.
If multiple mouse buttons are held down simultaneously, all relevant parameters should be updated
in parallel. For rotation, you may apply the rotations in a fixed order, as opposed to composing
multiple infintesimal rotations. However, this ONLY applies to the case where multiple mouse
buttons are held down; in general you will want to be able to compose an arbitrary sequence of
transformations.
These interaction modes are a bare minimum, and form a poor 3D user interface. We’ll look at
better ways to create an interface for 3D rotation in Assignment 3.
3
View Interaction Modes
The following view interaction modes should be supported:
• Rotate (keyboard shortcut O): Use x-motion of the mouse to:
– LMB: Rotate sight vector about eye’s x (horizontal) axis.
– MMB: Rotate sight vector about eye’s y (vertical) axis.
– RMB: Rotate sight vector about eye’s z (straight) axis.
• Translate (keyboard shortcut N): Use x-motion of the mouse to:
– LMB: Translate eyepoint along eye’s x axis.
– MMB: Translate eyepoint along eye’s y axis.
– RMB: Translate eyepoint along eye’s z axis.
• Perspective (keyboard shortcut P): Use x-motion of the mouse to:
– LMB: Change the FOV over the range of 5 to 160 degrees.
– MMB: Translate the near plane along z.
– RMB: Translate the far plane along z.
A good default value for FOV (Field of View) is 30 degrees.
Model Interaction Modes
The following model interaction modes should be supported:
• Rotate (keyboard shortcut R): Use x-motion of the mouse to:
– LMB: Rotate box about its local x axis.
– MMB: Rotate box about its local y axis.
– RMB: Rotate box about its local z axis.
• Translate (keyboard shortcut T): Use x-motion of the mouse to:
– LMB: Translate box along its local x axis.
– MMB: Translate box along its local y axis.
– RMB: Translate box along its local z axis.
• Scale (keyboard shortcut S): Use x-motion of the mouse to:
4
– LMB: Scale box along its local x axis.
– MMB: Scale box along its local y axis.
– RMB: Scale box along its local z axis.
The initial interaction mode should be model-rotate, and this mode should be restored on a reset.
The amount of translation, rotation or scaling will be determined by the relative change in the
cursor’s x value referenced to the value read at the time the mouse button was last moved. Make
sure your program doesn’t get confused if more than one butto is pressed at the same itme; all the
motion events should be processed simultaneously, as specified above, although individual “incremental” transformations can be compused in a fixed order.
You should use appropriate scaling factors to map the relative mouse motions to reasonable changes
in the model and viewing transformations. For example, you might map the width of the window
to a rotation of 180 or 360 degrees.
Do not limit the accumulation of rotations and translations; ie. there should be no restriction on the
cumulative amount of rotation or translation applied to an object, or to the number of sequential
transformations.
Viewport Mode
The viewport mode allows the user to change the viewport. Assume you have a square window into
the world, and that this window is mapped to the (possibly non-square) viewport. The window-toviewport mapping has been described in lecture and in the optional course textbook; if the aspect
ratio of the viewort doesn’t match the aspect ratio of the window (ie. the viewport is not square),
then the objects appearing in the viewport will be stretched. Further, when you change the viewport, you will see the same objects in the new viewport (possibly scaled and stretched) that you
saw in the old viewport.
You should draw the outline of the viewport so we can tell where it is.
In the viewport mode, the left mouse button is used to draw a new viewport. The left mouse button
down event sets on corner, while the left mouse button up event sets the other corner. You should
be able to draw a viewport by specifying the corners in any order. If a mouse up position is outside
the window, clamp the edges of the viewort to the visible part of the window.
The initial viewport should fill 90% of the full window size, with a 5% margin arond the top, buttom, left and right edges. This is important so we can verify that your viewoprt clipping works
correctly – if you do not do this, you may lose marks in two places. The user should be able to
set the viewport to any portion of the window, including sizes larger than the original size. Note
also that the viewport is to be reset to the initial size when the reset option is selected from the File
5
menu.
The keyboard shortcut for viewort mode should be V.
Projective Transformation
You will need to implement a projective transformation. This will make the cube look threedimensional, with the perspective foreshortening distinguishing front and back. You may use a
projective transformation matrix if you wishs. However, note that for this assignment there is no
need to transform the z-coordinate. You can use the mappings x/z and y/z, although note that
some additional scaling will be necessary to account for the field of view.
Orthographic View
If you cannot get your projective transformation matrix working, you may implement an orthographic view (no perspective) instead. However, you will not get full marks. You may also want
to implement an orthographic view first, and do your projective transformations last.
Line Clipping
You will need to clip your lines to the viewing volume. There are several ways to clip, any of
which will suffice for this assignment. Note, however that you must clip to the near plane before
completing the perspective projection, or you will get odd behaviour and coredumps. You may find
it easiest to clip to the remaining sides of the viewing volume after you complete the projection
(since you will be clipping to a cube), but you may clip at any point in your program. Note that we
will be testing clipping against all sides of the view volume.
Donated Code
You have been provided with the following files:
• main.cpp – The main point of entry into the application.
• draw.cpp, draw.h – The drawing routines.
• window.cpp, window.h – The application window, to which you may add widgets.
• renderer.cpp, renderer.h – A widget that will display your rendering. This is
where the core part of your code will go.
• algebra.cpp, algebra.h – Routines for geometry, points, etc.
• a2.cpp, a2.h – Matrix routines you should implement and use.
6
To compile and run the provided program, execute:
qmake -project QT+=widgets
qmake
make
./a2
The provided code creates the UI for your simple box drawing program. As a test, it draws four
lines, cross through the center of the screen, and in the top left corner. You need to modify this
code to draw your visible viewport, render a box and the two gnomons, and perform the requested
transformations and clipping. A suggested to-do list, in an order that will help you is as follows:
• Draw the outline of the default visible viewport.
• Consider an orthographic projection and define the coordinates necessary for drawing a box.
Transform each 3D line segment into your 2D screen coordinates. You may wish to create
a helper function that takes an arbitrary line segment, and draws it on the 2D screen. If this
goes well, work directly with a perspective projection, otherwise leave it till later.
• Extend your viewport to support resizing, and implement clipping.
• Incorporate model transformations. Then incorporate view transformations. Make sure to
leave sufficient time to debug the composition of matrices as you generate your final MVP
transformation.
• Wrap up the necessary UI controls and if not already done, perspective projection including
near/far/FOV controls.
You may wish to create helper methods, helper classes or use data structures such as queues or
stacks, depending on your design. C++ standard template library offers stacks, queues and other
collection mechanisms which may be used.
Bonus (20 Marks)
The core of this assignment is fundamentally a decent amount of work. However, if you have time,
and the creative inclination, there are a lot of ways this simple graphics pipeline can be made much
more interesting. You are encouraged to experiment with the code to implement these sorts of
changes, as long as you have already met the assignment’s basic objects. The maximum additional
marks from bonuses is 20. It is at the discretion of the TA to determine coolness factors in awarding
bonus points.
• A fancy way of drawing the viewport. (up to 5 marks)
7
• Additional geometric shapes; 3 marks per shape. (up to 10 marks)
• Support for OBJ file loading. (5 marks)
• Support and GUI support for adding, transforming and removing multiple 3D shapes on the
screen. (10 marks)
• Support face drawing (rasterization), including hidden surface and z-buffer algorithms. (10
marks)
If you make an amazing modification (an actual feature, not an unintended bug…), document it in
your README and it will be considered and graded at the discretion of the TA for a maximum of
10 marks.
If you make extensive changes, additionally offer a “compatibility mode” by default. You should
support at least the user interface required by the assignment. You can activate your extensions
either with a special command line argument or a menu item. Document this in your README file.
Non-functional Requirements (20 Marks)
Documentation
1. You must provide a README file. A sample one has already been provided.
2. Your README file should contain:
(a) Your name and UCID.
(b) Short description of algorithms you implemented to complete the program. This includes how you set up the view volume clips and what you called the function that
implements these clips.
(c) A brief description of the data-structures you used to implement the assignment. This
includes what matrices you chose to store in the renderer.cpp and their purpose.
3. You must provide at least one screenshot of your assignment demonstrating its capabilities.
Additional screenshots are necessary to demonstrate any implemented bonuses. Screenshots
should be named ‘firstname.lastname a2 #.png’ where # is 1-n for n screenshot images.
Source Code
1. All your source code must be written in C/C++ and properly commented. All graphics rendering must be done using OpenGL. All event handling and windowing must be performed
via Qt. Your source code must compile on the lab machines in MS 239 without any special
modifications. Your source code must be clear and well commented.
8
2. You will lose marks for inefficient and slow implementations.
3. You may reuse source code:
(a) which has been provided by the instructor for use in the course,
(b) which has been written by you which implements basic data structures, such as linked
lists or arrays,
(c) which you have received permission from the instructor or one of the TAs of CPSC 453
prior to handing-in your assignment,
4. Any instances of code reuse by you for this assignment must be explicitly mentioned within
the README file. Failure to do so will result in a zero in the assignment. Please read the
University of Calgary regulations regarding plagiarism http://www.ucalgary.ca/
honesty/plagiarism.
Functional Requirements (80 Marks Total)
Transformations (30 Marks)
1. Model transformations performed with respect to the box’s local origin. (8)
2. Model’s gnomon undergoes all transformations except scaling. (4)
3. Viewing transformations work as specified. (8)
4. Rotation, translation and scale can occur in any order, at any time, with no restrictions on
model or view transformation ordering. Regardless of the sequence, the box never distorts
so that edges fail to meet at right angles (in 3D). (10)
Viewing and Clipping (30 Marks)
1. Perspective transformation correctly implemented. (8)
2. Viewport mapping works as specified. Defaults to a centered square with 90% maximum
size. (8)
3. Lines are clipped to the near and far planes. (7)
4. Lines are clipped to the sides of the viewing volume. (7)
9
UI Interaction (20 Marks)
The user should be able to:
1. Access pull down menus for controls as specified. (5)
2. On-screen feedback for current mode as specified. (5)
3. Mouse controls for model, view and viewport as specified. (5)
4. Perform transformations smoothly while mouse is moving. Pressing two buttons simultaneously results in two transformations performed together. (5)
Lost Marks
Possible areas for losing marks:
• Lines drawn outside the viewport region.
• Gnomon does not follow box model.
• Gnomon size scales.
• Unable to see box and gnomons on application start up.
• Poor choice of mapping from mouse x values to transformations (eg. cause excessively rapid
or excessively slow transformations). Ideally the motion follows the mouse movement.
• Poor cumulation of transformations. eg. As the mouse moves uniformly across the screen,
the box translates faster and faster.
• Application redraw slows down over time, as more transformations are applied.
• Draw updating is not live with mouse movements.
Demo
You are required to give an approximately 5 minute live demo to your TA. Failure to show up at
the presentation will result in a zero in the assignment. You will need to schedule your demo with
your TA – they will have details about how your tutorial section demos will run.
10
CPSC453 Assignment 3 OBJ Model Loading Solved
Overall Description
For this assignment, you are to write a model loader program for OBJ files. The application is
able to select an OBJ file, read it in, and render the mesh in a number of ways on the screen. As
with prior assignments, a number of affine transformations may be performed on the model. It also
provides the user with options for changing the view and drawing. To facilitate this, the program
has a number of user input tools through the mouse, keyboard, and menu.
The assignment will be written in C++ using the Qt GUI toolkit. In this assignment you will be
working with OpenGL commands for drawing, using matrices for transformations and supporting
basic GUI for interaction.
A number of example models have been provided. The user may choose which model to load and
render it on the screen. Even though models come in different sizes it should still be centered and
fit within the viewable window on loading. This may require determining the model’s dimensions,
and calculate the default transformation required to reposition the model or the view.
Standard model and view transformations will be available. These are mostly the same from prior
assignments, however the view will be transformed based on the “lookat” setup, and the model
will rotate based on trackball rotation. To visualize the view transformations, a patterned square
will be drawn and fixed in the scene, similar to our gnomon from Assignment 2.
Many of the provided models are characters adapted from the MD2 files of the old Quake engine.
These characters have both a main mesh as well as a weapon or prop mesh. To support these
characters, the application must be capable of loading in additional OBJ files. Since the props are
in the same coordinate system as the main mesh, they will need to have the same transformations
1
applied as the main mesh. This forms a small example of a hierarchical model with the main mesh
the parent of the prop mesh. We will refer to these props as submodels, and they inherit the transformations of their parent model.
Three main drawing modes will be supported: wireframe, face and textured. The first two we saw
in Assignment 1. To support texturing, the application must be able to select a texture (2D image)
and apply the texture coordinates to the model. These texture coordinates are found within the
OBJ model, with one texture coordinate (u, v) for each vertex.
To ensure nice rendering of the scene, normals need to be computed for the model. The two modes
are face normal – where each vertex on the same face receive the same normal, generating a flat
shading style; and vertex normal – where each vertex has its own normal, computed as an average
of the adjacent face normals, generating Phong shading style. Normals may be optionally displayed on the mesh. An easy approach is to generate a small line with one point located at the
vertex or center of the face, and the other point some small length away in the direction of the
normal. Toggling between face and vertex mode should visualize different normals.
Lastly, one should be able to select a currently active model. This selected model (and any of
its associated submodels) is affected by the model transformations. Additionally, when loading a
texture, it is applied to the selected model. For full marks, 3D picking must be used for selection.
For partial marks, an additional menu should be created allowing the application to select between
loaded models.
You are are allowed to use the existing Qt matrices, the matrices you created in Assignment 2 or
helper matrices in the glm library. You may also wish to use the QFileDialog and QImage
class for file and image loading. A perpsective projection has been implemented and should be
used for the assignment.
The Interface
The user interface will be written in Qt. You will need to implement the following functionality.
The letters in ”()” indicate the keyboard short cut; remember – both upper and lower case should
work for the keyboard shortcut.
• A File menu with the following menu items:
– Open Model (CTRL+O): Load a new model. This becomes the selected model
– Open Submodel (CTRL+B): Load a new model (eg. a weapon), setting the selected model as its parent. This new becomes the selected model.
– Load Texture (CTRL+T): Load a texture for the selected model
– Reset Models (R): Reset models to their default positions
2
– Reset View (R): Reset camera view
– Reset All (A): Reset models and camera
– Clear (C): Clears all models
– Quit (Q): Exit the program. (This one is already implemented – do not break it!)
• A Draw menu, with the following menu items:
– Wireframe (W): Draw the scene in wireframe mode.
– Face (F): Draw the scene in face mode.
– Textured (T): Draw the scene in textured mode.
– A nested Normals menu, with the following menu items:
∗ Face (CTRL+F): Draw the scene using face normals
∗ Vertex (CTRL+V): Draw the scene using vertex normals
∗ Show Normals (N): Toggle between drawing normals indicators
Face and Vertex should use radio buttons to indicate which state is selected.
– Select Model (S): Turns on picking mode to select a currently active model.
Picking mode is deactivated when a user selects a model, or presses the escape key
(ESC) (and clears the selection).
Wireframe, Face and Textured should use radio buttons to indicate which state is
selected.
• Mouse Movements:
– Operations are initiated by pressing the appropriate mouse button and terminated by
releasing that button. The SHIFT and CTRL modifiers cause the view movements to
be used instead.
– LMB: Translate the selected model, or if none, all models, along the X and Y axis.
– MMB: Translate the selected model, or if none, all models, along the Z axis. Only use
the horizontal change in mouse position.
– RMB: Rotate the selected model, or if none, all models, using trackball rotation.
– LMB with SHIFT: Translate the position of the camera along the X and Y axis.
– MMB with SHIFT: Translate the position of the camera along the Z axis. Only use
the horizontal change in mouse position.
– RMB with SHIFT: Rotate the up direction of the camera. Only use the horizontal
change in mouse position.
– LMB with CTRL: Translate the camera’s look at location along the X and Y axis.
3
– MMB with CTRL: Translate the camera’s look at location along the Z axis. Only use
the horizontal change in mouse position.
– The maximum and minimum scales should be restricted to a reasonable range.
You will need to make reasonable decisions about how much to scale or rotate for every
pixel’s worth of mouse motion. For example, if the mouse isn’t moving, there should be no
scaling or rotation.
An on-screen display, such as a status bar, should indicate: which drawing mode (Wireframe, Face
or Textured), which normal style (Face or Vertex) and which model is selected.
As with previous assignments, this is implemented in C++ with Qt. We have provided some code
for you that sets up a window and draws an example triangle. You will need to add the required
functionality. As with Assignment 1, when building your data buffers to send to the provided
shaders (ie. vertices, per-vertex colours, per-vertex normals and per-vertex texture coordinates),
use Vertex Buffer Objects and Vertex Array Objects. This is a more efficient display style.
Donated Code
You have been provided with the following files:
• main.cpp – The main point of entry into the application.
• window.cpp, window.h – The application window, to which you may add widgets.
• renderer.cpp, renderer.h – A widget that will display your rendering. This is
where the core part of your code will go.
• objModel.cpp, objModel.h – Routines for loading OBJ files. You may wish to add
code here.
• per-fragment-phong.vs.glsl, per-fragment-phong.fs.glsl – Simple phong
shader code.
• textured-phong.vs.glsl, textured-phong.fs.glsl – Phong shader code
that supports textures.
• models.zip – A collection of OBJ models.
• demos.zip – A simple example of transformations, including code for trackball rotations
which you will likely want to adapt for this assignment.
4
To compile and run the provided program, execute:
qmake -project QT+=widgets
qmake
make
./a3
The provided code creates a simple starter UI. As a test, it draws a triangle in the center of the window. You need to modify this code to load in your models and textures, draw using the rendering
styles and perform the requested transformations. A suggested to-do list, in an order that will help
you is as follows:
• Draw a simple patterned square in the scene (eg. checkerboard).
• Load an OBJ file. You may wish to draw them in wireframe mode before face mode.
• Reposition the model based on its dimensions so it fits in the center of the window.
• Incorporate the model and view transformations, including virtual trackball and the camera’s
look-at mechanism.
• Calculate the face normals, and then the vertex normals, passing them off to the shader. Then
optionally draw the normals on the model.
• Add support for one submodel using the provided weapons. Be able to transform it separately from the main model.
• Add support for textures.
• Add support for 3D picking.
• Add support for multiple models and submodels.
You may wish to create helper methods, helper classes or use data structures such as queues or
stacks, depending on your design. C++ standard template library offers stacks, queues and other
collection mechanisms which may be used. Describe your design decisions in your README.
Bonus (20 Marks)
The core of this assignment is a decent amount of work. However, if you have time, and the creative
inclination, there are a lot of ways this can be made much more interesting. You are encouraged to
experiment with the code and implement these sorts of changes, as long as you have already met
the assignment’s basic objects. The maximum additional marks from bonuses is 20. It is at the
discretion of the TA to determine coolness factors in awarding bonus points.
5
• Support animation. (up to 5 marks)
– A separate folder of OBJs has been provided indicating an animated sequence. Within
these sequences are mini-animations (2-10 frames each). Automatically loop through
all types of animation (see animation list below) and adjust display speed to match the
specified fps (10 marks),
// animation list
typedef enum {
STAND,
RUN,
ATTACK,
PAIN_A,
PAIN_B,
PAIN_C,
JUMP,
FLIP,
SALUTE,
FALLBACK,
WAVE,
POINT,
CROUCH_STAND,
CROUCH_WALK,
CROUCH_ATTACK,
CROUCH_PAIN,
CROUCH_DEATH,
DEATH_FALLBACK,
DEATH_FALLFORWARD,
DEATH_FALLBACKSLOW,
BOOM,
MAX_ANIMATIONS } animType_t;
• Support animation GUI. (up to 3 marks)
• Perform one of our subdivision techniques on the mesh. (up to 10 marks)
• Highlight the selected model. (up to 3 marks)
• Support scene generation: loading multiple models, saving and loading transformation descriptions, etc. (up to 8 marks)
• Support undo/redo for transformations. (up to 5 marks)
• Provide an alternative rendering style. (up to 5 marks, based on coolness factor)
6
If you make an amazing modification (an actual feature, not an unintended bug…), document it in
your README and it will be considered and graded at the discretion of the TA for a maximum of
10 marks.
If you make extensive changes, additionally offer a “compatibility mode” by default. You should
support at least the user interface required by the assignment. You can activate your extensions
either with a special command line argument or a menu item. Document this in your README file.
Non-functional Requirements (20 Marks)
Documentation
1. You must provide a README file. A sample one has already been provided.
2. Your README file should contain:
(a) Your name and UCID.
(b) Short description of algorithms you implemented to complete the program. This includes how you set up the submodel transformations and calculate the normals.
(c) A brief description of the data-structures you used to implement the assignment. This
includes what matrices you chose to store in the renderer.cpp and their purpose.
3. You must provide at least one screenshot of your assignment demonstrating its capabilities.
Additional screenshots are necessary to demonstrate any implemented bonuses. Screenshots
should be named ‘firstname.lastname a3 #.png’ where # is 1 − n for n screenshot images.
Source Code
1. All your source code must be written in C/C++ and properly commented. All graphics rendering must be done using OpenGL. All event handling and windowing must be performed
via Qt. Your source code must compile on the lab machines in MS 239 without any special
modifications. Your source code must be clear and well commented.
2. You will lose marks for inefficient and slow implementations.
3. You may reuse source code:
(a) which has been provided by the instructor for use in the course,
(b) which has been written by you which implements basic data structures, such as linked
lists or arrays,
(c) which you have received permission from the instructor or one of the TAs of CPSC 453
prior to handing-in your assignment,
7
4. Any instances of code reuse by you for this assignment must be explicitly mentioned within
the README file. Failure to do so will result in a zero in the assignment. Please read the
University of Calgary regulations regarding plagiarism http://www.ucalgary.ca/
honesty/plagiarism.
Functional Requirements (80 Marks Total)
Modelling & Rendering (40 Marks)
1. Simple patterned square is drawn. It is affected by view, but not model transformations. (3)
2. UI for loading models. (2)
3. Draw model and be able to toggle between wireframe (2), face (2) and textured (10). This
includes 2D texture loading for the selected model.
4. Compute and optionally display indicators for face normals (5) and vertex normals (7).
5. Render using face normals – flat shading (2) and vertex normals – smooth shading (2).
6. Support weapon submodel loading. (5)
Transforming (25 Marks)
1. On model loading, model fits within window and is centered. (5)
2. Model transformations: translation (3) and trackball rotation (5).
3. Submodel transformations: hierarchical – moves independently or with parent model. (3)
4. View transformations: translate camera position (3), translate camera lookat location (3),
rotate through camera’s up-direction (3)
UI Interaction (15 Marks)
The user should be able to:
1. Access pull down menus for controls as specified. (3)
2. Display on-screen feedback for current mode and selected object as specified. (2)
3. Able to select models (5) – full marks for 3D picking; maximum 2 for menu listing.
4. Mouse controls for model and view as specified. (5)
8
Lost Marks
Possible areas for losing marks:
• Model is non-uniformly stretched on loading.
• Model is cropped on loading. Model is clipped or cropped on initial rotation.
• On load, model does not rotate about its center, nor the center of the window.
• Specific model values are hardcoded into the program.
• Application redraw slows down over time.
• Draw updating is not live with mouse movements.
• Transformations are buggy, jerky, uneven, too fast or too slow.
• No screenshot. No README.
Demo
You are required to give an approximately 5 minute live demo to your TA. Failure to show up at
the presentation will result in a zero in the assignment. You will need to schedule your demo with
your TA – they will have details about how your tutorial section demos will run.
9
CPSC453 Assignment 4 Raytracer Solved
Overall Description
For this assignment, you are to write a recursive ray tracer. For ray tracing, you need to create an
image of a scene including several objects and models. You may specify the scene in the code and
output the resulting image to a file or to the screen. The type of image file you use is your choice,
but the user must be able to specify the desired width and height of the resulting image through the
command line or an input file.
You are are allowed to use the C++ standard template library, algebra.h, algebra.cpp files
from Assignment 2 and the provided files. No other libraries files are to be used.
The Interface
No graphical user interface is required for this assignment. The user must be able to specify
the image resolution (width and height), for example through command line arguments. All other
interactions are designed at your discretion.
Donated Code
You have been provided with the following files:
• main.cpp – The main point of entry into the application, including an example of how to
populate and save a 2D image.
• polyroots.cpp, polyroots.h – Routines for solving quadratic functions. Maybe
useful for intersection tests.
1
To compile and run the provided program, execute:
qmake -project QT+=widgets
qmake
make
./a4
The provided code illustrates an example of populating and saving a 2D image to a file, output.png.
As a test, it loops through the pixels and sets the RGB tuple for that pixel. You need to modify this
code to colour the pixels based on the algorithm for a recursive ray tracer. A suggested to-do list,
in an order that will help you is as follows:
• Generate scene specifications for the camera and image plane. Compute the rays for each
pixel.
• Implement sphere intersection.
• Generate scene specifications for a virtual sphere object that should be visible by the camera.
• Colour the scene using a binary colour scheme (eg. red versus blue) where an intersection
with the sphere generates one colour, and no intersection generates another.
• Generate scene specifications for a light source. Implement the Phong illumination model.
• Generate shadow rays and shadows.
• Add support for triangles and quads.
• Support reflection via recursive secondary rays.
You may wish to create helper methods, helper classes or use data structures such as queues or
stacks, depending on your design. C++ standard template library offers stacks, queues and other
collection mechanisms which may be used. Describe your design decisions in your README.
Bonus (30 Marks)
This assignment is a decent amount of work. However, if you have time, and the creative inclination, there are a lot of ways this can be made much more interesting. You are encouraged to
experiment with the code and implement these sorts of changes, as long as you have already met
the assignment’s basic objects. The maximum additional marks from bonuses is 30. It is at the
discretion of the TA to determine coolness factors in awarding bonus points.
• Read scene and light specifications from an input file. (up to 5 marks)
2
• Dynamic eye position and viewing direction specification. (up to 5 marks)
• Refraction (recursive). (up to 10 marks)
• Simple anti-aliasing as discussed in class. (up to 5 marks)
• Use a triangle mesh in OBJ format in the scene. (up to 5 marks)
• Animated MD2 (a sequence of images generated by ray-tracing). (up to 5 marks)
• Add other primitives such as cones, cylinders or other implicit surfaces. (5 marks each, up
to 15 marks)
• Generate an OpenGL user interface to create and preview the scene for ray tracing. This
interface should include controls to position, orient and scale objects within the scene. (10
marks)
• Support texture mapping and/or bump mapping (5 marks each)
• Support CSG operations (intersect, union, diff, etc). (10 marks)
• Efficiency Improvements:
– Intensity Threshold: If the accumulated mirror reflectance is less than epsilon, cease
recursive on the branch. (up to 5 marks)
– Bounding Boxes: (Extends mesh bonus) Compute a bounding box to check for intersections before performing whole OBJ intersections. (up to 5 marks)
– Spatial Partitioning: Modify your intersection routine to use a spatial partitioning
scheme (eg. BSP trees, uniform spatial subdivision or octrees). (up to 10 marks)
• Provide an alternative rendering style (eg. toon shading). (up to 5 marks, based on coolness
factor)
If you make an amazing modification (an actual feature, not an unintended bug…), document it in
your README and it will be considered and graded at the discretion of the TA for a maximum of
10 marks.
If you make extensive changes, additionally offer a “compatibility mode” by default. You should
support at least the user interface required by the assignment. You can activate your extensions
either with a special command line argument or a menu item. Document this in your README file.
3
Non-functional Requirements (20 Marks)
Documentation
1. You must provide a README file. A sample one has already been provided.
2. Your README file should contain:
(a) Your name and UCID.
(b) Short description of algorithms you implemented to complete the program. This includes how you have designed your ray tracer.
(c) A brief description of the data-structures used to implement the assignment. This includes what classes you chose to use and their purpose.
(d) A brief description of each of image and what portion of the assignment it illustrates.
3. Due to speed issues, you must provide at least three screenshots of your assignment demonstrating its capabilities. Your submitted images must show each of the features you have
implemented. You will not receive marks for features that are not demonstrated in the images you submit. Additional screenshots are necessary to demonstrate any implemented
bonuses. Screenshots should be named ‘firstname.lastname a3 #.png’ where # is 1 − n for
n screenshot images.
Source Code
1. All your source code must be written in C/C++ and properly commented. OpenGL and Qt
are not to be used for this assignment unless it is for a bonus. Your source code must compile
on the lab machines in MS 239 without any special modifications. Your source code must
be clear and well commented.
2. You will lose marks for inefficient code and a slow demo sample.
3. You may reuse source code:
(a) which has been provided by the instructor for use in the course,
(b) which has been written by you which implements basic data structures, such as linked
lists or arrays,
(c) which you have received permission from the instructor or one of the TAs of CPSC 453
prior to handing-in your assignment,
4. Any instances of code reuse by you for this assignment must be explicitly mentioned within
the README file. Failure to do so will result in a zero in the assignment. Please read the
University of Calgary regulations regarding plagiarism http://www.ucalgary.ca/
honesty/plagiarism.
4
Functional Requirements (80 Marks Total)
1. Objects in the scene: spheres (15 marks), triangles and quads (15 marks)
2. Phong illumination model, and point light sources (20 marks)
3. Shadows (15 marks)
4. Reflection (recursive) (15 marks)
Lost Marks
Possible areas for deductions:
• Unable to enter image resolution (width, height).
• Demo scene takes too long.
• You need to give us comparison images for things like antialiasing.
• If your eye point is too far, or your fov is too wide, the objects near the edges will appear
distorted (stretched).
• For scaling to work properly, you need to normalize the ray every time you transform it.
• The images shouldn’t be upside down.
• The background shouldn’t obscure the view especially if using a unique background.
• If images look washed out and shadow areas are gray, it is probably because you are adding
the ambient light to your colour instead of ambient*material.ka.
• Missing screenshots, README.
Demo
You are required to give an approximately 5 minute live demo to your TA. For this demo, you’ll
need to construct a simple example which will compile and raytrace your scene within 30 seconds.
Failure to show up at the presentation will result in a zero in the assignment. You will need to
schedule your demo with your TA – they will have details about how your tutorial section demos
will run.
5
