Project Philosophy - cmu462/Scotty3D GitHub Wiki

Welcome to your first day of work at Scotty Industries! Over the next few months you will implement core features in Scotty Industries' flagship product Scotty3D, which is a modern package for 3D modeling, rendering, and animation. In terms of basic structure, this package doesn't look much different from "real" 3D tools like Maya, Blender, modo, or Houdini. Your overarching goal is to use the Developer Manual to implement a package that works as described in the User Guide, much as you would at a real software company (more details below).

Note that the User Guide is not an Assignment Writeup. The User Guide contains only instructions on how to use the software, and serves as a high-level specification of what the software should do. The Developer Guide contains information about the internals of the code, i.e., how the software works. This division is quite common in software development: there is a design specification or "design spec", and an implementation that implements that spec. Also, as in the real world, the design spec does not necessarily specify every tiny detail of how the software should behave! Some behaviors may be undefined, and some of these details are left up to the party who implements the specification. A good example you have already seen is OpenGL, which defines some important rules about how rasterization should behave, but is not a "pixel-exact" specification. In other words, two different OpenGL implementations from two different vendors (Intel and NVIDIA, say) may produce images that differ by a number of pixels. Likewise, in this assignment, your implementation may differ from the implementation of your classmates in terms of the exact values it produces, or the particular collection of corner-cases it handles. However, as a developer you should strive to provide a solution that meets a few fundamental criteria:

• Failing gracefully is preferable to failing utterly---for instance, if a rare corner case is difficult to handle, it is far better to simply refuse to perform the operation than to let the program crash!
• Your implementation should follow the principle of least surprise. A user should be able to expect that things behave more or less as they are described in the User Guide.
• You should not use an algorithm whose performance is asymptotically worse just because it makes your code easier to write (for instance, using bubble sort rather than merge sort on large data sets).
• That being said, when it comes to performance, premature optimization is the root of all evil! The only way to know whether an optimization matters is to measure performance, and understand bottlenecks.
• Finally, you should take pride in your craft. Beautiful things just tend to work better.

Just to reiterate the main point above:

As in real-world software development, we will not specify every little detail about how methods in this assignment should work!

If you encounter a tough corner case (e.g., "how should edge flip behave for a tetrahedron"), we want you to think about what a good design choice might be, and implement it to the best of your ability. This activity is part of becoming a world-class developer. However, we are more than happy to discuss good design choices with you, and you should also feel free to discuss these choices with your classmates. Practically speaking, it is ok for routines to simply show an error if they encounter a rare and difficult corner case---as long as it does not interfere with successful operation of the program (i.e., if it does not crash or yield bizarre behavior). Your main goal here above all else should be to develop effective tool for modeling, rendering, and animation.