Skip to content

Week 3

Jump to bottom
Hebali edited this page Oct 7, 2014 · 5 revisions

Week 3:

  • GoF design pattern presentations
  • Transformations and matrices in OpenGL (Part 2):
  • Design patterns introduction:
    • Software as a collection of building blocks
    • Efficiency, ease-of-use and other architectural considerations
  • Designing graphics software:
  • Towards an API: (see below)

In-class Exercise:
Please form groups of two or three students. With your group, discuss the features that you would like to include in your scenegraph API. You can start with whiteboarding, prototyping or whatever method works best for your team. Ultimately, during this class exercise, you should arrive at a sketch of your header files - an outline of the classes and functions that will comprise your system. The actual implementation will come later. You’ll likely want to include features that relate to subjects we haven’t studied yet: cameras, lights, etc. This is a common predicament in software architecture. Take a stab at how these features might fit into your API and you can refine them later as you learn the underlying details. As a group, you might want to start by making some of the big picture decisions, for example - do you want to focus on 2D, 3D or both?

Homework:
With your group, please implement the scenegraph API you started in class.

The goal of this project is to build a set of tools (an “API”) that makes it easier for other programmers to construct and draw “scenes” containing a hierarchy of geometric data within a Cinder application.

The user of your API should be able to create nodes of various kinds (several geometry types as well as a camera type and possibly a light type), add a node as a child of another node, set the transformation matrices for each node (relative to its parent node) and configure stylistic settings such as the color or material of a geometry node.

Your API can focus on 2D geometries, 3D geometries or both. It's up to you to determine which features are most important to support. As you make these decisions, keep the user in mind.

Once you've developed the API, put yourself into the role of its user and create a Cinder application that uses your API to construct a specific scene. For example, if you're focusing on 3D functionality - you could construct a simple model of the solar system (a hierarchy of stars, planets and moons).

Implementations will be evaluated on the following:

  • Correctness: Proper memory management, separation of concerns, etc
  • Ease-of-use: Consistent naming schemas / data structures, comments, etc
  • Depth: Broad feature support and configurability

Depth and ease-of-use often work against each other. Try to achieve a balance between these two. If you can’t, then really overcompensate with one or the other. A less feature-rich API should be extremely easy to use - think iOS vs Android.

Please be prepared to present this work in two weeks. In your final implementation, please be sure to include a "sample project" that demonstrates basic usage of your API in a graphics application.

Clone this wiki locally