When exploring a new domain, one of the most exciting and difficult parts is learning all the new concepts and terminology and then attempting to implement the code to realize models and algorithms in that domain. Computer graphics has a wide range of relevant domains which ultimately boils down to interpreting data and then rendering a scene as an image. While interpreting data is what all programs do, I find learning computer graphics to be a unique experience compared to other domains. In the end, there are 3 competing factors which I keep in mind: intentions, definitions, and implementations.
Intentions
Code is written with an intention. The code may not be bug free or efficient or even correct, but there is always an underlying intent behind what the code should do. Unlike most domains, for graphics, there is also an artistic desire mixed in with the intention. The final image could be a photo realistic representation of a scene, a cel-shaded image like in games, animation, and comic books, or many other artistic and stylish representations. While most business applications have requirements based on processes or rules, graphics rendering has more freedom for creativity which can lead to a greater variety of intentions.
Definitions
While the underlying intention is a major influence, the realization of the intention begins with defining models which describe how things should work. For instance, the intention could be for a photorealistic scene, but there needs to be a definition for how concepts like light should be rendered. A model for light can be built from math and physics. There is a wide range of definitions for light from simplistic models to complex physics based models. Lights, shadows, materials, and everything else which can affect a rendered scene can have various definitions depending on the needs and the level of understanding.
Implementations
Ultimately, there is the implementation of the definitions in code. Code is shaped by available APIs and resources such as the underlying hardware. Whether the scene is rendered in real-time or offline, code must be written to realize the desired model and the limitations of the APIs and hardware can constrain the ability to realize the model.
In the end, the rendered scene is molded by intentions, definitions, and implementations. In many cases, an individual factor may influence the others. For example, perhaps the hardware limits what can be displayed on screen at one time with the given definition of how light data should be processed. Then, the underlying vision of the intention may be compromised. Beyond having a wide range of domains to understand to render, perhaps the most interesting thing about graphics is trying to realize the original intention by figuring out ways to make definitions and implementations more efficient.