Project 2: Trains and Rollercoasters revisited – The modern OpenGL rendition

by Eftychios Sifakis on April 21, 2015

The second project for CS559 has, traditionally, been focusing on creating an animated town, using existing framework code and (to a certain extent) legacy OpenGL features, while incorporating on a number of technical embellishments. This year, Project #2 will remain thematically close to the “Trains and Rollercoasters” scene you have already started building in your first project, but the requirements will emphasize adoption of modern OpenGL constructs, and a number of the technical add-ons will become mandatory.

Mandatory requirements

The content and principles of function of the virtual environment you are asked to generate will be a continuation of what you crafted for Project #1. However, a number of embellishments will be required:

      1. You must have at least FOUR different shader pairs utilized among the various objects in your scene.
      2. At least one of the aforementioned shaders must provide a procedural texture.
      3. In addition to the procedural texture above, at least one more object needs to be textured with an image-based texture. It is acceptable to address both challenges jointly, if you read an image texture and further modify it in a procedural fashion (in the shader).
      4. You must have at least two (optionally more) moving objects.
      5. You must have at least one time-varying appearance feature (i.e. depending on the time of day, or another timer with observable granularity that you include in your program). This could be a time-varying texture, color, light, geometry (e.g. position of vertices) or transform. This requirement is in addition to the moving objects mandated above.
      6. You must include at least one object made out of a curved surface. You can implement subdivision, or some form of parametric surfaces, or do a surface of revolution, or …
      7. You must attempt “enough” technical challenges (see the technical challenges page – which tries to define “enough” and “attempt”).

Good assignments always go way beyond the minimums. See section “Evaluation” below for a discussion of how much is enough.

Working Together

You are encouraged to work with a partner, subject to some rules.

Each person must:

  • Create at least one curved surface object.
  • Write at least one shader pair that is a procedural texture (and use it on an object).
  • Program at least one moving object, using a different methodology than the one implemented by their partner.
  • Implement at least one time-varying appearance behavior (see point #5 of “mandatory requirements”, above).
  • Write at least two shader pairs, attached to various objects.
  • Provide solutions to at least two of the technical challenges.

Other than that, the requirements are the same as for individuals – we expect you to have a little more than we expect individuals to have. Each person must document the pieces they did individually, in addition to the overall documentation.

Teams must choose to work together by the April 28th checkpoint. Teams may not split up after May 5th, unless they have a very tangible plan (approved by the instructor or TA) on how to complete the assignment individually. Generally, teams get the same grade, but we reserve the right to make exceptions.

Timetable

  • April 28th –You must let us know by that time if you plan to work with a partner. You must also provide a tentative list of technical challenges you are interested in, and (optionally) some ideas for what you want to do overall. You are not tied to these – we mainly ask to make sure you are thinking about things, also so we can better prepare for providing feedback and assistance.
  • May 5th – Signs of life checkpoint – you will have to show us a picture of your virtual world, demonstrating at least initial progress on the stated goals. This is the last day to “break up” your group (with consent from instructor/TA).
  • May 13th – Project Due AT TIME OF FINAL EXAM. (7:45 AM.) NO LATE PROJECTS WILL BE ACCEPTED!

Evaluating aspects

There are three aspects of this project, all will be considered in evaluating your project:

  1. Technical challenge (how much hard graphics technique did you use). See the technical challenges page. Note: that some of the technical challenge of the project comes from how complicated the objects are, how complex your shaders are, etc. AS A ROUGH GUIDELINE, addressing 4-5 of the technical challenges would place you in a competitive position for an “A” grade, 3 well executed challenges will put you in contention for an “AB” grade, and 2 well executed challenges will put you in position to claim a “B” grade. Quality matters every bit as quantity, so the above scale is just a crude indication.
  2. Visual Complexity of your world (how cool/interesting does it look – sometimes a few really interesting things can be as good as a lot of simpler things). The first criteria is that it is different than the sample solution. You should avoid using same regular grid of houses from the example. Getting rid of my silly looking houses is an important first step, even if your make new ones that aren’t much better.
  3. Behavioral Complexity of your world (how interesting are the things that happen in it).

This is the order of importance. While having some degree of success in all categories is important, sometimes excellence in one category can outweigh deficiencies in another. However, you must meet the minimum basic requirements.

Note that it is important that you are able to show off the features of your system. If you have written a shader, you need to use it on an object that makes it clear that your shader is doing what it advertises.

 

Shader Tools

In the past we provided a file to help get you started compiling, linking, and loading shaders from files. You can download the .cpp file HERE and the .h file HERE

 

Opportunity to Improve Project 1 Grade:

If there are advanced features or “bells and whistles” from project 1 that you wanted to implement, had trouble implementing, or didn’t have enough time to implement, you are free to add them to project 2. Since you have partners for project 2, you cannot simply copy your partner’s work if they already had a feature implemented. You must clearly document (in a separate section of your README,) what features you added, who worked on what feature, and how you implemented it.

Out of fairness to those who completed most of the advanced project 1 features, the most you can improve your grade will be 1/2 letter grade. This limit is also here so you focus on the project 2 technical challenges rather than old project 1 requirements.

To be eligible, you must have completed all basic requirements for project 2.

Previous post: