I wrote this for a Computer Animation course at University of Texas at Dallas in 2014. This project is pretty academeic in the sense that we reinvent the wheel and "roll our own" for many of the components involved in 3D animation. Modern SWE probably would use more pre-built components rather than writing one's own matrix, camera, 3D transformation classes and so on than what is done here.
It's written in C++ and uses OpenGL to create and render scenes, freeglut and glui are used for frontend components. These we just use, we don't reinvent the wheel for the GUI components. The purpose of the project I believe was basically to break down and really understand the components of a 3D engine more or less.
Here's what the actual program itself looks like when it runs:
It basically loads a skeleton file, which is just a text file containing a list of joints in 3D space and their connections, and a mesh file, which is just a text file containing a long list of vertices and their weights to each joint they are connected to. You can see that this mesh is basically a wasp. It's got some controls for rotating the mesh, moving the camera around etc, but we'll get to that later.
The controls are very rudimentary keyboard controls and you can rotate and translate the camera and the mesh. The boxes are joints to show the skeleton, normally I will not display these.
At the center of all this there is the Scene
The Scene class is simple enough. It contains all the logic for parsing the skeleton and the mesh files and drawing them. There are only 4 items in this class, a Model, a Camera, a ModelFactory, and a number for keeping track of the current joint. The user can iterate through the joints using this counter and rotate them.
Let's take a quick look at the Model class.
Models contain a Skeleton, the set of joints, and a Mesh, the set of all vertices forming the polygon "skin".
You can see we keep ModelFactory as a friend class. I intentially tried to commit to a design using composition as opposed to inheritance with the logic being, "a model HAS a set of joints which form a skeleton" as opposed to "a model IS a set of joints which form a skeleton" and then trying to extend the mesh class in there somewhere down the line. I was deeply convinced of the power of composition after reading about it in the Gang of Four Design Patterns book.
ModelFactory is also quite simple, it creates a Model from skeleton file and a mesh file. You need both a skeleton and a mesh to build a model. Mesh has it's own MeshFactory class
Skeleton it's own SkeletonFactory class and so on.
Skeletons are composed of BallJoints
BallJoints have a few mathematical helper classes, Matrix3, Vector3, Vertex, and Triangle. Triangles are also heavily featured in the Mesh class.
The SkeletonFactory uses SkelParser
You may notice above an enum TokenState. This SkeletonParser class does employ the use of the "State Machine" design pattern. This is partially because the BallJoint data structure is more complex than the vertices that compoase a mesh, and so the SkeletonParser does employ a few states.
It could get a token from the skeleton file that does not make sense in context of the previous one, resulting in a BallJoint that does not make sense or could not possibly exist.
As well, the MeshFactory uses the MeshParser
All Parser classes use a convenience class called Tokenizer that tokenizes text files. ie. It takes a file, opens it, extracts the text, and returns the text as a list of useful "tokens". Tokens are usually separated by a "delimiter", often a space, or a "comma-space" as in the case of "comma separated values" files or .csv files.
A solution for the build error Error 1 error MSB8020 should you run into it:
Tutorial for the tool I used to create the UML Diagrams
Another example of a token based state machine, parsing tool type utility I have written here:
Project is academic in nature and doesn't use modern commercial parsing and lexing tools, but rather reinvents the wheel for the sake of under standing concepts