When your program is executed, the user will have the option of creating an SOR or reading in an SOR. If the user decides to read in an SOR, s/he will be prompted for the filename of the SOR. The file is read and SOR is displayed. If the user decides to create an SOR, s/he will be prompted for the filename to save the SOR. The user is then presented with the interface for creating an SOR, which is similar to the Lab1 assignment (details below). After the SOR is created and saved, it is also displayed as a wireframe.
After an SOR is displayed, the user again has an option of creating another SOR or reading in a different SOR to be displayed. This repeats until the user quits (by not doing anything further) i.e. the browser will display the last SOR. Only one SOR is displayed at a time.
Use the result of your Lab 1 assignment to create the profile curve. The profile curve is simply a polyline. We shall use an axis of revolution that runs vertically, splitting your screen into a left and right half. The profile curve shall be specified from top to bottom on the right half of the screen. This curve is then rotated in 10 degree increments in a "counter-clockwise" manner when viewed from the top of rotation axis.
The actual SOR is created by forming polygonal faces (quads in this case) by connecting the points on the profile curve as they are rotated around the axis. It is very important that the points are connected in the correct order so that surface normals are pointing outwards. Though you may not notice anything wrong with your wireframe drawing, it will become obvious when we "skin" your polygons in later programming assignments.
To recap, if the user elects to create an SOR, draw a blank canvas with a vertical line in the middle. You can assume that the profile curve will be drawn on the right half and going from top to bottom.
We have implemented the saving and loading function for you. You just need to provide the code that calls these functions.
You do not need to remove hidden lines in your wireframe rendering. Since the OBJ (and most other file formats for polygonal surfaces) file format describes a set of vertices and a set of faces (by connecting a series of vertices), sides of a polygon are usually rendered twice. Once, by each polygon that shares a common side. This is ok. Our models are small enough and line drawing is fast enough that we don't need to try to optimize this.
When the SOR is ready to be displayed (after it is read in from a file, or after the user has completed creating one), the canvas is cleared to white and the wireframe of the SOR is rendered in black.
If you treat the axis of rotation as the y-axis (positive going up), the x-axis (positive going right) bisects the y-axis at the middle of the screen, and the z-axis (positive going out of the screen towards the user), then we have a right-hand coordinate system. Assume the viewer is at location (0,0,∞), render an orthographic projection of your SOR. This can be achieved by simply dropping the z-coordinate of each vertex and drawing a 2D polyline for each polygonal face (which you already know how to do from Lab 1).
The line segment representing each surface normal does not have to be anchored at the center of each polygon. Easiest is to anchor it consistently at one of the vertices of each polygon. To make them easier to see, draw the surface normals in red.
Check out the parser in OBJViewer code from the Matsuda-Lea book.
Here is a link to where you can find the file read and save utility functions.
Rubric:
You start off with 100 points. You earn additional credit by turning in your assignment early and/or implement additional features. You lose credit for missing functionality, incorrect results, poorly documented or formatted code, or not following instructions. Below is a partial list: up to 10 points off for poor features.html file up to 10 points off for inadequate comments or hard-to-read code up to 10 points off for not following instructions up to 10 points off for special handling functionality points depending on importance Make sure you: a. submit the right files you want us to grade, b. have tested your code on the browsers in the lab. c. follow the general instructions described in overview.html
aashwin: aagrawa6 - victor: drooney - andy: mespirit -
Put materials in a folder named prog1 and zip it up. Submission must be done using the "submit" command from unix.ic.ucsc.edu
Last modified
Tuesday, 22-Jan-2019 09:42:16 PST.
