CS4451A: Assignment 2

"Hierarchical Coordinate Systems"

Due: September 25th

Purpose

To become familiar with hierarchical coordinate systems.

Task

Write a Java program using Magician OpenGL that reads in a file describing a graphical scene (see below for the format) and displays it.

Your program should open two windows: one described in the file, that contains the graphical scene, and another containing a vertical set of checkbox fields with the names of the nested coordinate systems. Clicking on the checkbox next to the name of a nested scene element should toggle that element on/off in both windows: if the entry is on (checked), it should be displayed in the 3D scene, and if it is off (not checked), it (and all the nested elements below it) should be hidden in the 3D scene.

You must also hand in two test files that you create yourself. Each should use a reasonable camera position so that all the scene is visible, and takes up a large part of the window:

1. Checkerboard. Create a standard sized checkerboard (alternating black and white squares) and put red and black checkers in the standard starting locations. You should use a mesh for the board (with a face for each square) and a squished cube for each piece. The pieces should be 1.5 units wide, and the squares should be 2 units.
2. Blobby man. Create a humanoid out of spheres that have been scaled to different sizes, including many (such as those for the arms) that are long and thin. The humanoid should have 14 spheres: head, torso, upper and lower arms, hands, thighs, calves, and feet.

Turn in

Your program should consist of a set of java files which should be commented with your name (the name you are registered under!) and ID number. One of the java files should implement a class "A2" (so the TA can execute it using the command "java A2".) The files should be emailed as attachments to a single email message to cs4451@cc.gatech.edu.

The time the mail is received will be used to determine whether or not the program is late, so be sure to allow a couple of minutes for the mail system to transmit your file if you are working right up to the deadline.

IMPORTANT: If the TA has to edit your files you will lose points. Similarly, the TA should be able to execute the class "A2", so using any other class as your main class will result in lost points.

Due date

This program is due on or before Monday, September 25th. This means it must be received by 11:59pm EDT on Monday to not be considered late.

Additional Instructions

For your camera views in your input files, try not to use "straight-on" views, as a camera that is slightly to the side and slightly angled looks better (ie. if you are looking at (0,0,0), don't look from (0,0,100), but rather from something like (25,25,100)).

You program should probably create a set of objects for each "element" it reads from the file, and then assemble the needed ones together after the file is read. You should do the obvious error checking, and simply stop your program on a bad input file: if an undefined element is used, if not enough numbers are specified on a given line, etc.

Any reasonable data structure will do: the most important thing is that the data structure you create to use during rendering be easy (efficient) to traverse. So, do not store the elements in a dictionary (indexed by their text name), and then look each one up each time it is referred to. Rather, you should simply have arrays, lists, trees or graphs of objects that you follow. Your data structure does not need to be general or editable: it is fine (and probably easier) to end up with a set of objects or arrays that create the right scene, as long as the subhierarchies defined by the group elements can be toggled on and off.

You program should be able to use an element more than once: for the checkerboard, you should be able to define one red box for the red checker piece, and refer to it more than once. The transformations on the group elements above the element should position it in the correct place.

The format of the input file is as follows:

• A blank line, or a line starting with "#", is a comment and should be ignored.
• The file contains a list of named elements, which can be referred to before being defined.

The possible elements are:

• "cube name r g b"
  A cube of unit size with color (r,g,b) where r,g and b are in the range 0..1
• "sphere name r g b"
  A sphere of unit size with color (r,g,b) where r,g and b are in the range 0..1
• "polygon name r g b
  numverticies
  v1x v1y v1z
  v2x v2y v2z
  ..."
  A polygon element with the specified number of verticies with color (r,g,b) where r,g and b are in the range 0..1. Each vertex is defined on a separate subsequent line. The last polygon should be closed (the last and first vertices are joined). For example, a unit square might be
  "polygone square1
  4
  0 0 0
  1 0 0
  1 1 0
  0 1 0"
• "mesh name
  numverticies
  v1x v1y v1z
  v2x v2y v2z
  ...
  numfaces
  r1 g1 b1 face1numverticies face1v1 face1v2 face1v3 ...
  r2 g2 b2 face2numverticies face2v1 face2v2 face2v3 ...
  ..."
  A polygon mesh with the specified number of vertices, and the specified number of faced defined using those verticies, with face i having color (ri,gi,bi) where ri,gi and bi are in the range 0..1. As with the polygons, each vertex is defined on its own line. After all verticies are defined, the faces are defined. The first line is a single number specifying the number of faces, and the subsequent lines each have a number (the number of verticies for that face) followed by the vertex numbers (specified as indexes into the list of verticies).
• "ambientlight name
  r g b"
  An ambient light of color (r,g,b) where r,g and b are in the range 0..1
• "pointlight name
  r g b"
  An point light source of color (r,g,b) where r,g, and b are in the range 0..1
• "group name
  transformation
  child1name child2name ..."
  A hierarchical group element. It must have one transformation applied to it (see below for a list of possible transformations) and can have any number of elements (children) nested under it. The children are specified using their names.
• "window name
  size width height
  lookat fromx fromy fromz tox toy toz
  perspective fovy near far
  rootname"
  The 3D window specification. The window name should be used for the name of the window presented to the user. The 3D canvas should be of the size specified. You should use gluLookat and gluPerspective to create your virtual camera. The fovy parameter specifies the field of view in the y direction; the missing "aspect" parameter for gluPerspective should be dynamically computed using the aspect ratio of your window. The rootname is the name of the element that is at the top of the element hierarchy.

The possible transformations that can be specified on a group element are:

• "rotate x y z angle"
  Rotate by angle degrees, where the angle is a rotation around the vector defined by (x,y,z)
• "rotateX angle"
  Rotate by angle degrees around the X axis
• "rotateY angle"
  Rotate by angle degrees around the Y axis
• "rotateZ angle"
  Rotate by angle degrees around the Z axis
• "translate x y z"
  Translate by (x,y,z) units along the x, y and z axes respectively
• "scale x y z"
  Scale by (x,y,z) units along the x, y and z axes respectively
• "identity"
  The identity transformation

  Here is an example file, that creates a cross with a red verticle axis and a blue horizonatal axis:

  cube topbottom .8 .2 .2
  cube leftright .2 .2 .8
  
  group top 
  translate 0 1 0
  topbottom
  
  group bottom
  translate 0 -1 0
  topbottom
  
  group left
  translate -1 0 0
  leftright
  
  group right 
  translate 1 0 0
  leftright
  
  group grid
  scale 2 2 2 
  left right top bottom
  
  window fourcubes
  size 300 300
  lookat 2 2 -10 0 0 0
  perspective 30 1 20
  

  This example creates a hierarchical set of coordinate systems as follows:

  grid
   |______________
   |   \    \     \
   |    \    \     \
  left right top bottom
   |     |    |     |
   \     /     \    /
  leftright   topbottom
  

  There are five coordinate systems (each represented by a group element). The four visible cubes are each 2 units wide (because the top coordinate system scales up by 2). The lower coordinate systems position the unit cubes in a pattern that is 3 units high and wide. The visible pattern is 6 units high and wide (and 2 deep).

  Lighting must be handled before geometry. Think about why? (it has to do with the immediate execution of commands)

EXTRA CREDIT

There are two extra credit options on this assignment. You may do one or both, and each is worth a possible one point.

1. Add a button named "Jiggle" beside each labelled checkbox in the list of nested elements. Clicking on the button will cause the element (and all elements under it) to have a small set of rotations applied to it's z-axis over the next 3 seconds in a decreasing sinusoidal pattern: the element will rotate clockwise and counterclockwise through 3 periods of a sin wave (one per second), with the degree of rotation decreasing linearly from 45 degrees*val(sinfunction) a time=0 to 0 degrees*val(sinfunction) at time=3. Clicking jiggle before a jiggle on the current element is finished should do nothing. Multiple elements can jiggle at once.
2. Add a button labelled "Edit" beside each labelled checkbox in the list of nested elements. Clicking on the button will pop up a dialog box to allow the user to edit the transformation on the element. The title of the dialog box should contain the name of the element, so that multiple dialog boxes can be open at the same time.
   The dialog box should contain a list of all the possible transformations, with a checkbox beside each, and with the current transformation being checked. There should be numeric fields for each of the parameters to each transformation (ie. the translate transformation should have 3 fields after it, one for x, y and z.) The scene should change immediately when the user enters a change in a field, not when the box is dismissed.