When your program is executed, the user will have the option of creating a GC or reading in a GC. If the user decides to read in a GC, s/he will be prompted for the filename of the GC. The file is read and GC is displayed. If the user decides to create a GC, s/he will be prompted for the filename to save the GC. The user is then presented with the interface for creating a GC, which is similar to the Lab1 assignment (details below). After the GC is created and saved, it is also displayed as a wireframe.
After a GC is displayed, the user again has an option of creating another GC or reading in a different GC to be displayed. This repeats until the user quits (by not doing anything further) i.e. the browser will display the last GC. Only one GC is displayed at a time.
Use the result of your Lab 1 assignment to create the spine curve. The spine is simply a polyline. The closed circle is also represented by an n-sided polygon. For this assignment, use a 12-sided polygon to represent your circle (i.e. rotate a point in 30 degree increments a full revolution) Use a radius that is 5% of the smaller dimension of your window. For example, if your canvas is 500x800, your radius should be set to 25 (ie 5% of 500).
The GC is created by forming polygonal faces (quads in this case) by connecting the points on one closed circle with the next one along the spine. 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.
Another important aspect of the GC model is to keep the closed curve perpendicular to the spine. Since the spine is made up of individual line segments, we need to determine the appropriate orientation of the closed curve at each joint segment. Here, we will do simple averaging of the normals of the line segments sharing a joint.
To recap, if the user elects to create a GC, allow the user to create a spine curve. You can assume that the spine curve will be drawn starting with the "base" of the GC to the "top" of the GC.
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 GC 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 GC is rendered in black.
Assume x-axis is positive going right, the y-axis is positive going up, and the z-axis is 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 GC. 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 implementing 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 to grade your homework (usually because you did not check that it runs on the computers in the lab first). - 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
cole: a - k hugh: l - z
Put materials in a folder named prog1 and zip it up. Submission must be done using the "submit" command from unix.ucsc.edu
Last modified
Tuesday, 22-Jan-2019 09:42:16 PST.
