Teaching computer graphics programming to non-programmers

I know a number of artists who don’t program computers, yet use computer graphics tools such as Unity or Maya or Photoshop. Several of them have expressed interest in going deeper. Rather than seeing the computer as a black box, they want to understand how things really work.

In order to do that, you need to learn to program. But where to begin? I am thinking of putting a series of lessons on-line on this blog, aimed at people who use computer graphics tools, and don’t already know how to program, but would be interested in learning to program if it could give them a greater insight into how all this stuff works.

The major question I’m wrestling with is whether to start from the bottom up, with things like procedural shaders that you program at every pixel, or from the top down, with things like animated characters that you move around.

Each approach has advantages and disadvantages. I think it may come down to the particular learner. People who are motivated by creating things that look visually beautiful would be more drawn to the procedural shader approach. People who are motivated by creating animated things that come to life would be more interested in the animated character approach.

Maybe I will figure out a way to do both.

4 Responses to “Teaching computer graphics programming to non-programmers”

  1. J. Peterson says:

    Photoshop has this (incredibly obscure) feature where (after a few secret handshakes) it’ll spit out JavaScript code corresponding to the actions you took with the application (mouse clicks, menu choices, dialog box results, etc.). Now, the code you get back isn’t particularly readable, and I certainly wouldn’t hand it over to “non-programmers”.

    However, I think this *concept* is very useful for your situation.

    Imagine a simple, toy drawing program that lets you create lines, rectangles, circles, etc. Alongside the graphics window you draw into, there’s a “transcript” window translating what you did to executable code. For example, you the select the rectangle tool, then click and drag out a rectangle, then:

    rectangle( point(122, 140), point( 250, 400) );

    appears in the transcript. If you go to the color palette and choose green, then

    setColor( 0, 1.0, 0 );

    appears. As you play with the drawing program, the transcript fills up with source code describing what you’ve done.

    Now imagine another “source code” window. If you simply take the contents of the transcript window, paste it into the source code window, and hit “Play”, Voila, you have an exact copy of your drawing.

    But you can take this very same source code and start adding programmer stuff to it: variables, loops, functions, etc. Some of the “tools” can even give you hints about this. For example, maybe one of you’re “tools” draws an arbitrary N-sided polygon. But when you draw the polygon, the transcript has a for loop drawing it side by side, so you get a worked programming example just by using the polygon tool. This concept also eliminates the need to learn/memorize a graphics library. Just select the tool and do it, and you’ll learn how it works in the transcript.

    Now of course, building such an environment is going to keep somebody busy for a month or two…but hey, you’ve got grad students, right? : )

  2. Stephan Ahonen says:

    My favorite way to teach complex technical crafts is to first start with a “playground,” a finished work that contains all the concepts I want to teach. Map out all of the dependencies for all the concepts that need to be taught, and sort things into an order where you don’t have to teach ideas before teaching the ideas they depend upon. Note that “built on top of another technique” is not necessarily the same as “depends upon knowledge of another technique,” as long as you have ways of invoking the underlying technique without needing to know how it works (i.e. using libraries).

    Then for each concept, I make a separate, simple demo containing *only* that concept, so that it’s easy to demonstrate how that technique is built from all of the layers of the technology stack. After you teach the concept in isolation, you go back to your playground where you can see how it interacts with the whole.

  3. admin says:

    J. Peterson: I’ve tried that approach. I have found two problems with it: (1) it doesn’t focus on the coding itself as the means of expression, and (2) it doesn’t encourage the learner to explore outside of the paradigms already provided by the graphic user interface.

    Stephan: I totally agree. I generally take the same approach.

  4. Antonio says:

    Hi! For a first, basic approach I always recommend the Crunchzilla tutorials, they focus a lot in graphical programming and help bridge the gap. As for the procedural shader approach, I don’t know anything similar, and would love to see it in action!


Leave a Reply