Behind the Scenes: A Study of Autodesk Maya

Aylish Wood

School of Arts

Jarman Building

University of Kent

Canterbury

CT2 7UG

Automation lies at the centre of many debates

surrounding computer-generated animation. These include

an interest in aesthetic innovation (Purse, 2013),

changing studio organizations (Tarantini, 2012), and the

out-sourcing of labour (Yoon and Malecki, 2009). Making a

connection between what we see on the screen and the

means of its production, Leon Gurevitch suggests that the

mass produced qualities of highly detailed and large

scale spaces, multitudes of digital entities, and complex

arrays of lighting in a final render, discloses the

presence of automation: ‘…what the viewer beholds is a

composite of animated and simulated image forms only made

possible by the synthetic means of computer automation

(Gurevitch 2012: 135).’

Automation is rarely used as a neutral term; rather,

it is frequently a marker of changing practices somehow

outside of the control of human users of technologies,

often threatening the terms on which agency is founded.

Remarking on anxieties specific to computer-generated

animation, Mihaela Mihailova comments:

1

Anxieties about the digital could be partially

provoked by the relative impenetrability of con-

temporary animation processes. To anyone who is not

a software developer, animation software might as

well run on arcane magic. And while it is possible

to demonstrate and subsequently demystify the

different creative tasks of cel animation because

they are performed by humans, computer processes

cannot be observed. Their inner workings can

sometimes remain unfathomable and mysterious, even

to those who have mastered their use (Mihailova,

2013: 142-143).

It is true that the inner workings of software seem

unfathomable because code is executed in ways that remain

invisible to human eyes, evocatively described as the

‘sourcery’ of code by Wendy Chun (Chun, 2008). The

difficulty is, as Matthew Fuller pointed out in 2003,

that: ‘Software lacks the easy evidence of time, of human

habitation, of the connotations of familial, industrial,

2

or office life embedded in the structure of a building

(Fuller, 2003: 43).’ Fuller’s remarks were written in the

spirit of finding ways into software, and subsequent

approaches within software studies, in particular those

relating to computer games, can be put to good use in

thinking about animation software. For instance, Noah

Wardrip-Fruin says that players gain an understanding of

the operational logic of a game as they play.

Understandings of automation and computer animation

software can be complicated by this insight, and is

developed further through an exploration of the user

interface (UI) of the 3D animation software Autodesk

Maya. Since users experience the automation of software

via their interactions with the UI, it offers a ground

for closely examining how the inputs generated through

human users and automation counterpoint rather eclipse

each other.1

This essay looks at the systematic and apparently

transparent processes of the UI of the 3D animation

software Autodesk Maya, and will argue that the visible

depictions of automation give insight into how a UI both

3

bundles and also disperses user agency during the process

of creating animations. Agency is meant in the sense of

the capacity to carry out actions, one that is

distributed between both human users of software and also

the software itself. Autodesk Maya, or Maya, has retained

a pre-eminent position in the visual effects, games,

television, and advertising industries since its release

in 1998. Maya is explored through a methodology that

combines an analysis of the visual organization of the UI

alongside interviews with users of the software, in

particular modellers and animators. My investigation of

the interview material is framed through software

studies: Noah Wardrip-Fruin’s ideas on expressive

processing and Adrian Mackenzie’s account of software and

agency. Drawing on these different approaches, the

argument put forward is that systematic building of

models and movements and also creative uses of automation

co-exist. Rather than seeing automation overwhelming user

agency, working with software is finally a balance

between automation and a user’s input.

4

Introducing Autodesk Maya and a Framework for Studying

its UI

One of many animation software packages, Autodesk

Maya is the central case study of this paper. Released in

1998 to great acclaim, the software won an Oscar for

Technical Achievement in 2003, and was rapidly associated

with films that won and were nominated for visual effects

Oscars. Some 10 years later, it remains a key component

of many studio pipelines, for instance in the making of

Avatar (2009, James Cameron), Epic (Chris Wedge, 2013), and

the Despicable Me films (Chris Renaud and Pierre Coffin,

2010 and 2013). One of the reasons for its wide adoption

in the visual effects, animation, and advertising

industries, and also in games and data visualizations, is

that the software is open. Many studios and users write

scripts that automate repetitive tasks or add

functionalities specific to the projects on which the

studio are working. Over the years a number of these

extensions have been incorporated into the core

functionality of the software, enabling developers to

5

keep innovating and Maya to retain its position amongst

an increasing range of competitive software. The

longevity of Autodesk Maya and its continued pre-eminence

makes it a good case study through which to ask questions

about the experience of users of computer animation

software.

Before moving more fully into a discussion about the

UI it is worth briefly outlining how the software is used

to create animations, whether they are used in visual

effects or animations. Animating a bouncing ball is a

fundamental learning exercise.2 The user first creates

their ball from a sphere primitive. Primitives come in

three basic shapes spheres, pyramids and cubes they

are the building blocks for modelling. Having used the

modelling tools to generate a ball, the user then works

with the animation toolset to make it move. A timeline is

set in numbers of frames per second. Along this timeline

the ball can drop from a height (say 5) to 0, bouncing

back to 3, beginning in position A, bouncing at B and

ending at C. The heights and positions are in the X and

Y-axes respectively. A very basic animation could have

6

three key frames in positions A, B and C. The software

would generate the movements between those the key frames

based on the calculation of the quickest route from A to

B to C. To achieve a more nuanced and stylised movement,

such as easing into and out of a bounce or the

acceleration of falling and deceleration of rising, the

user would work the tangents of the curve of motion,

adding key frames at intermediate points between A or B

or C to get the kind of movement they want to see. If the

ball needs to swerve through the depth of the Z-axes, the

user would control that curve too. Working this pathway

along the timeline is only one element of movement, as

the ball would most likely not only move but also rotate

in flight and deform on impact. Figure 1 shows the

animation curve of a ball that has been thrown over a

wall into a yard, and has bounced back off the wall on

the right of the image. The curve shows a range of

accelerations and decelerations. More complex animations

can be seen as developments of this exercise. A simple

complication is to animate 3 balls of different weights,

say foam, rubber and wood, where the task is to animate

7

in a way that demonstrates the different weights and

timings of a bounce. A further complication would be to

give the object personality, as is often the case in

animation. Extrapolate these options to a scene where a

figure is animated interacting with an object. A figure

is a complex rigged model. Each moving part of that

figure has a characteristic movement, many of which may

be active in a sequence generating a multiplicity of

animation curves. Each curve has their own set of key

frames on the timeline, each with different patterns of

movement. For instance, even in a scene with smaller

scale movements, such as a conversation between the

characters Ronin, M.K. and Mub and Grub in Epic, all the

different moving elements of the scene (gestures, small

changes in posture, the extended stalks of the creatures

eyes), have their own animation curves (See Figure 2). In

addition to the animation, Maya can be used to generate

the environment of the action, such as a landscape or

cityscape, inside or outside. To achieve a particular

look, such as the animation style of Epic that combines a

highly detailed texturing of the figures and their

8

environment, shading is added to the surface of the

wireframe models to create the minute details and

textures of a scene, along with lighting and shadow. To

create imagery such as that seen Epic and other films,

many different people would be involved in building the

scene. Teams work on different parts of a production

pipeline, involved in making models, rigs, doing the

animating, shading, and lighting before the sequences are

rendered and then edited to create the sequence of images

seen by an audience. (Figure 1 HERE; Figure 2 HERE)

As the primary site of engagement for the users of

software carrying out these various tasks, my discussion

focuses on the UI. The UI is complex, a consequence not

only of the sophisticated operations available via the

toolsets but also the history of the software’s origins.

Autodesk Maya was developed as a multifunctional program,

and marketed to the visual effects and game industries

from the outset, with a number of animation studios also

using the package. Initially released by Alias|Wavefront

in 1998, Maya has a hybrid code pedigree. The company

Alias|Wavefront was formed from a merger of Alias and

9

Wavefront after both were purchased by Silicon Graphics,

Inc. The merger brought several key programs and their

source codes under the same company roof. These were:

Wavefront Advanced Visualizer, TDI Explore, Kinemation,

and Dynamation, and Alias PowerAnimator (Ryan, 2011).

From this combination of source codes, Maya was developed

to offer a range of functionality, including toolsets for

modelling, animation, lighting, and rendering (Alt,

2002). Given this diversity of functionality there is a

potential for information overload. To combat this, the

UI was and continues to be designed to streamline

accessibility and enable users to easily locate their

toolset of choice.

From the perspective of design, the arrangement of

the UI prioritizes access to the toolsets. Writing in

1998 about Maya’s UI, interface designers George

Fitzmaurice and Bill Buxton suggest that: ‘The main goal

of UI design is to reduce complexity while augmenting the

ability of users to get their work done (Fitzmaurice and

Buxton, 1998: 64).’ A particular feature of Maya’s UI was

‘the hotbox’, an optional widget still important within

10

Maya and which was designed to enhance access for both

novice and expert users (Kurtenbach et al. 1999). Instead

of using drop-down menus or relying on hotkeys, the

screen can be overlaid with a customizable selection of

toolsets. To this day, introductory tutorials continue to

promote the UI’s flexibility, emphasizing how different

users find their own route of access into the software.

Escape Studio’s Introduction to Maya training module draws

attention to both the wide range of available toolsets

and also ways of customizing the UI to individual

preferences.3 Books such as How to Cheat in Maya 2010 (Luhta,

2010) and Introducing Maya 2013 (Derakshani, 2012) devote

time to explaining the organization of the UI, with

catchphrases such as ‘You Put the U in UI (Derakshani,

2012: 50)’.

These seemingly transparent ‘tidy desk tidy mind’

activities entrain users into a set of practices

associated with Maya, which often includes setting in

place expectations for being part of a studio team, with

an awareness of good workflow practices. As well as

providing training about toolsets and workflow, these

11

organizational strategies operate at a conceptual level

too. In a study of spatial arrangements at work and in

games, David Kirsch concluded that spatial cues are a way

of structuring the information taken in by users in any

given space: ‘Spatial cueing reduces the descriptive

complexity of the environment, as we informationally

structure our workplace (Kirsch, 1995: 66).’ With the UI

designed around different routes for gaining access to

the functionality of the software, opportunities develop

for enhancing degrees of control over the model, rig or

the movements of an animated sequence. As this occurs, a

user engages with the software’s operational logic, the

spatial cueing visible in the viewport and dialog boxes

providing a connection with the algorithms of the

software in ways that can both bundle and also disperse

their agency.

The term operational logic is taken from Noah

Wardrip-Fruin’s work on expressive processing. A software

studies approach to computer games, the framework of

operational logics provides a beginning point from which

to look more closely at the question of user agency in

12

the context of automated processes. Within software

studies, software is far from neutral (Fuller, 2003;

Chun, 2012). For instance, writing about programs and

operating systems such as Java and Linux, Adrian

Mackenzie observes that: ‘The incorporation of prior

knowledges, codings and practices within the sequence of

operations attaches specific frames and patterns to the

relatively abstract space and time of algorithmic

processes (Mackenize, 2006: 64).’ Ian Bogost and Noah

Wardrip-Fruin too advance this insight in the context of

computer games by examining how frames and patterns can

be discernible in player encounters with games. For

Bogost, the procedural systems of many different kinds of

games generate behaviour grounded in rule-based models,

in that they mount logic-based arguments that influence a

player’s decisions (Bogost, 2007). Noah Wardrip-Fruin put

forward a related idea in Expressive Processing, reasoning

that expressive processing in digital media are legible

examples of ‘things that we need to understand about

software in general (Wardrip-Fruin, 2009: 5).’ By

expressive processing Wardrip-Fruin means both the ways

13

in which authors and artists can use the expressive

potential of computational processes, and also that these

processes express meaning through their design and

histories. While Wardrip-Fruin’s ideas have been mostly

developed in relation to games, expressive processing is

relevant to an analysis of animation software. When using

Maya, artists exploit the expressive potential of the

software in creating animations, and these computational

processes express meanings that can be explored through

the visual organizations of the software’s UI.

Exploring how computational processes express

meanings via the visual organizations of the UI involves

recognizing how specific frames and patterns are attached

to the abstract space and time of the algorithmic

processes. In other words, how the routes through which a

seemingly abstract entity become part of a meshwork of

meaningful structures. Teasing out the interplay between

automation and the input of a user gains more traction

when the UI is perceived as more than only an array of

available toolsets, and conceived instead as a location

where a complex process of engagement takes place.

14

Encountering a game involves the interplay of ‘data,

process, surface, interaction, author, and audience

(Wardrip-Fruin, 2009: 13),’ and equivalently, a UI can be

described as both inward and outward facing, a relay of

interaction between a surface of toolset menus and the

deeper algorithmic structures where data is processed.

Seeing an interface as both inward and outward facing

resonates with Alexander Galloway’s position that

interfaces are not windows or doorways that simply

connect one world with another, but offer locations where

different kinds of logic can co-exist (Galloway, 2012).

Despite ‘new media foreground[ing] the interface like

never before (Galloway, 2012: 30),’ our understanding

remains grounded in the idea that interfaces are a point

of transition between different formats or logics.

Superficially, this would seem to be the case in Maya’s

UI: it provides a connecting layer between the user and

algorithm. But, by taking into account the inward and

outward facing connections, working at the UI can be

understood as holding together two sets of logic, rather

than transitioning from one to the other. Looking at the

15

visual organization of the UI, these logics can both be

described as spatial but referencing distinct

configurations of space. The viewport, where models are

built, rigged and animated by Maya users, presents

digital entities in three-dimensional space akin to that

of the dimensional world in which we live. Alongside the

viewport are dialog boxes showing schematic diagrams

depicting these same shapes as packets of data grouped

together in hierarchies of information as required by the

algorithms of the software. Looking at how users

articulate their experience of these two logics offer a

means of thinking through how users of Maya encounter

both a sense of freedom in creating anything they can

imagine, and also meet the challenge of being creative

within an automated system. Although this study does not

give a direct account of the organization of any given

studio, Maya’s design was and continues to be linked to

the workflow practices common in many visual effects,

animation or games studios. Writing about the history of

computer animation, Tom Sito remarks that: ‘By the 1980s

innovations in CG had progressed from corporate titans

16

like IBM, Bell, and Xerox to market-driven independent

companies like Adobe, Alias and Pixar (Sito, 2013: 88).

Alias|Wavefront, who first developed Maya, targeted

animation, visual effects and games studios as the market

for the software. There is, therefore, another layer of

system versus individual software user in play: that of

the hierarchy of the studio and the ways in which

creative input is conventionally attributed to some

personal more than others. Work in production culture

studies is a rich source for thinking through studio

organizations, for instance the line between creative and

technical labour (Stahl, 2009:57-62).4

Analysis of the visual organization of the UI is a

good starting point for understanding more about a

software like Maya, but as Wardrip-Fruin comments: ‘the

operations of digital media are, in crucial ways, only

truly realised in contact with audiences (Wardrip-Fruin,

2009: 11).’ The same is true of software, its operations

more fully grasped in the thoughts and observations of

users. In more fully exploring the relays of connections

between users and UI, interview responses are cited

17

throughout the remainder of the article. This material is

drawn from interviews whose questions were designed to

provide insights into a user’s experience of Maya. The

respondents work in large fx houses, and small and medium

sized animation and game studios based both in the UK, US

and Australia, with length of experience ranging from 3

to 15 years. Their observations are explored in terms of

the immediacy of the software, resisting the ‘machinic’

aesthetic created by automation, and experiencing the

technical aspects of the software.

Giving an account of user experience of software

through these different kinds of engagement provides

insight into the interplay of user defined input and

automation. A key element of this discussion is agency.

My starting point follows Adrian Mackenzie’s argument

that agency is distributed, folding in-between people and

machines via the mediating influence of software

(Mackenzie, 2006). Taking agency to be folded between

users and machines contrasts with Wardrip-Fruin’s account

of agency in relation to operational logic, where he

says: ‘In short, agency is a term for the audience’s

18

ability to form intentions, take actions, and see

satisfying results (Wardrip-Fruin, 2009: 344).’ Agency,

in this explanation, has the appearance of being in the

hands of the audience or user, whereas Mackenzie’s

account distributes it between users and algorithms,

where the latter is the computational process behind any

operational logic. When an algorithm or operational logic

selects and reinforces one option for action at the

expense of others, agency folds in-between the user and

software: ‘Agency, therefore, is by definition contested

in and through algorithms (Mackenzie, 2006: 44).’

Thinking in terms of such as distributed agency brings

into focus the ways in which processes bundle and

disperse action between individual and system. The

balance between the tendencies to bundle or disperse is

at the heart of how users experience software.

The Immediacy of Software and Resisting Automation

3D animation packages, Maya included, virtually

project models in ways that allow its users to digitally

19

sculpt the model. Though any object is essentially a

collection of data, virtual projection gives the object a

presence, albeit within a computer and reliant on the

processor to keep working to speed. The spatial

configuration of such objects gives the illusion of a

volumetric whole. The illusion of wholeness is picked up

in the following comments from modeller BS: ‘But in Maya

everything is just infinitely thin, it’s a shell. I mean

most people would have been used to it, but I still

remember finding that weird 10 years ago. And things can

be single sided. You can flip it and it disappears, so

that’s a bit weird.’ There is an interesting dual

perspective in play in this remark. An object is not

quite what it seems, but it has immediacy in that it can

still be moved and controlled. The viewport is central to

the virtual projection of objects in Maya as volume

filling digital entities. Orthographic projections

flatten images into 2D configurations viewed from the

top, front or side, while the perspective view shows a

projection of a 3D model on a 2D screen. Figure 3 shows a

perspective view of spheres and cubes virtually projected

20

in the 3D space of the viewport. Though these views will

initially be discussed separately from other elements on

the UI, they are very rarely the only visible part of the

UI on screen. More usually, drop-down panels are also

visible and operate together with the viewport, allowing

the user to pivot between different the spatial

organizations of the UI. (Figure 3 HERE)

The viewport, especially when used in three-

dimensional perspective view, creates a framed space

through which a user’s access to and control over the

object is central. This begins with the options for

customization promoting an individual user’s preferences.

As the following comment by animator JF describes, it can

be organized in different ways:

So for instance, the setup I like on my screen is to

have the camera view, what’s going to be seen, and

underneath that I have my graph editor, so I can see

all the curves. And then I have the big perspective

view that I’m constantly moving around, and the

21

model to see what it looks like from different

views.

When working within a perspective view, a modeller can

see their model from all sides, as well as zoom in and

out to increase or decrease the detail. As modeller BS

again comments: ‘I still like having something 3D in

front of you and being able to spin around, I still like

all that stuff, I still like the immediacy of being able

to manipulate something seemingly floating in front of

you.’ For BS, working with the viewport gives a

heightened impression of access to the model.

The viewport not only provides visual contact with

the model, in the sense of being able to spin around a

360º view of the model. Its toolsets also include

manipulators through which modellers can make alterations

to their models. Since such alterations are immediately

visible, this has the combined impact of enhancing

control over the model while at the same time making the

software seem transparent. There are three different

basic toolsets for modelling: polygons, NURBS, and

22

subdivision surfaces. Which set the modeller works with

depends on the kind of object they want to create, but

usually it involves beginning with a series of primitive

shapes to build the space filled by the model. Once the

basic shape is in place, various other tool sets can be

used to add more nuanced detail. For instance, Artisan is

a feature within Maya were users access a sculpt tool to

push, pull, and smooth areas of the model. As described

in The Art of Maya: ‘Painting with Artisan is an intuitive

way to make selections, sculpt surfaces and paint values

on selected surfaces or multiple surfaces (Autodesk,

2008: 52).’ The description of Artisan as intuitive

echoes the observations of users for whom the viewport

and various manipulators can be combined to give sense of

access and control.5 It gestures towards the familiarity

of real world space by projecting volumetric objects,

allowing control over constructed spaces. It is where an

artist’s creative endeavour succeeds or falls away. All

of this seems to set aside the system, accentuating

immediacy and user agency in the emphasis on ease of use.

It allows the animator to: ‘really create whatever you

23

want to create [AC].’ The process of negotiation with an

algorithm is displaced behind the more direct

manipulation of a model in the projected space.

Though the viewport tends towards an impression of

setting aside the system, the apparent privileging of

user agency is only ever provisional, reliant primarily

on access to the object via the viewport. By contrast,

engagement with other features of the UI suggests that a

user’s control is always in the end folded together with

influences from the technological system on which it

relies. J.P. Telotte writes that traditional animators

are concerned at being relegated to the periphery of

production, working primarily with already constructed

digital assets and:

…turned into functionaries whose job would simply be

“to manoeuvre and tweak”…No longer able to find work

as creative artists, no longer able to breathe life

into their own visions—to animate space—animators in

this brave new technological world could well become

24

little more than necessary mechanics, there to

“adjust things” as needed (Telotte, 2010: 225).

Tweaking is certainly a phrase commonly used by CG

animators working with Maya, not always in the diminutive

sense but rather associated with skilled labour.6 While

the influence of software is evident in explanations

given by animators and modellers as they negotiate with

the default settings of toolsets, managing that

negotiation requires knowing how to animate or model.

Negotiation is not meant in a literal sense here, but as

a working against and with the out-of-the-box or

automated qualities of the toolsets. Effective animation,

the movement of modelled characters and objects in space

and time, is based on timing and pose. Strong and pushed

poses give a nuance to an animation, whether that

involves small or larger movements. Either way, animators

describe how they have to work hard to ensure that those

movements are smooth, entering into a negotiation or even

battle with the software. When asked the extent to which

25

software influences animation, AC responds by saying that

animation is in the control of the animator:

For character animation especially, the animator is

doing it. There’s things like ‘sim’7 where the

computer can take over for sure, but every move is

calculated and precise and you know, it’s all about

timing. But it’s also all about arcs, having nice

arcs in your animation and the computer doesn’t do

that, it doesn’t do that at all. That’s everything

to do with the animator.

In the case of animation packages, the user will always

input parameters into the software (it does not create

movements or objects without input), the process of

negotiation is a matter of the extent to which those

parameters are modified, broken down into smaller and

smaller units. For instance, to get nice arcs an animator

may need to make changes in every frame, rather than

allowing the software to make a calculation to

interpolate movement between every third or fourth frame.

26

‘Touching’ or modifying something in every frame is often

the case on less time-restricted projects. An algorithm

will default to the quickest route between two points,

whereas the animator might prefer a slower arc whose

trajectory has an organic rather than algorithmic feel.

Speaking about this process of negotiation, LS comments:

‘it is a constant battle when using software that does

things for you…because the software doesn’t feel, you

know.’

Modeller BS also describes a process of negotiation

with what he refers to as the perfection of the computer.

All edges, for instance, are defined by co-ordinates in

space and joined by lines or curves. The lines are

perfect in a model, unless work is done to undo this

perfection. This can include enhancing the contours of

shapes, creating textures that deepen time and age an

object, knocking off corners, or adding scratches to give

an impression of a lived world within an computer

generated environment. Speaking of this aspect of the

software, BS remarks:

27

It is almost like a non-compliant colleague. You’ve

got a vision in your head. Then, you know, you go

“for gods sake, not like that!” It is what I was

saying earlier, I seem to do a lot of work getting

away from the perfect. Most of the effort I would

say in CGI or animation, it’s always taking away the

computer-ness, it is always removing the CG from the

CGI…I think for me, doing character modelling and

environment and things like that, you’re always

fighting to get computer-ness out of it.

In talking about how they tussle with the computer-

generated preferences in their animation and modelling,

Maya users assert their ability to control the software.

Since they are working in a context in which mechanistic

qualities in the imagery are the antithesis of the

dominant aesthetic conventions, their efforts are

directed to erase traces of automation. This is point

made explicitly in the following comment by animator BW:

28

‘It all needs a large amount of artist input. Again,

I think it is fighting against the CG realm, it’s

about keeping it alive. In the end it’s just binary

code, and binary code wants to be uniform,

monochrome, flat, simple, basic. And I’m happy for

that as that’s what makes the software work so well.

But, of course, what you’re trying to create is more

organic, it’s alive, it’s springy…I see that from an

animator’s view. Maya is such a wonderful tool that

it allows me to do my job, but if you leave it to

its own devices it will churn out very computer

generated looking images. So it’s important to keep

it alive.’

These thoughts about the immediacy experienced by

modellers and animators in their engagements with the UI,

and the more negotiated tussle with automated processes,

suggest that agency has the appearance of remaining with

users of software. It is bundled around user ability to

shape and manipulate objects, and to make them move with

liveliness. The viewport allows modellers and animators

29

to see the models and their movements in their volumetric

spaces and temporal transformations. Agency accumulates

around users in association with a spatial configuration

that is coherent and representational of objects in time

and space. In other words, the algorithms tend to become

transparent. When the influence of the software becomes

more insistent in the ‘computer-ness’ generated through

automated settings, the user narratives are about

resisting such settings. Being occupied in creating an

animation requires iteration after iteration, recursive

tweak after tweak to erase the traces of automation,

until the movement is good enough.

Yet even as the explicit narrative of users is one

of agency, resisting software suggests that one is always

working with the envelope of software, and against the

parameters that it sets, rather than being free to do

anything. The following section more explicitly engages

with the schematic representations of the operations of

Maya’s software, spatial configurations in which the

algorithms are more evident. Where the discussion of the

viewport has revealed one of the patterns constituting

30

Maya’s operational logic, it’s second one is explored via

graphic depictions in the dialog boxes of the modelling

and animation toolsets.

Schematic spaces and software relations

Of learning to use Maya, LS described the process as

being ‘like animating with boxing gloves.’ In gaining

greater experience, LS commented further of the software

that: ‘it sets something different in your brain.’ This

turn of phrase, that software sets something different in

your brain, draws attention to the ways in which users of

Maya are influenced by working within the parameters of

the software’s functionality. A stronger impression of

what these parameters might be emerges in the spatial

configurations of the schematic diagrams that co-exist

with the viewport on the UI. As well as showing the

virtual projection of objects in the viewport, figure 3

above shows a dialog box for rendering (see right hand

side of the image). The logic of the software’s automated

functionality is also embedded in the action of modelling

31

or animating, and this is evident in the following

interview responses. Talking about whether software has a

particular language, understood here to mean an evident

set of processes or protocols, modeller BS says:

Yes, yes, definitely. And all the software is

different. Anything you can do you can think of

being a step-by-step process, even the process of

making a cube. You click on the button to make the

cube, and then it asks you the size of the cube.

Anything you ever want to do, it’s almost like, the

sentence in front of you and you can’t change that,

you can’t say I want you to make me a cube and type

the size and then hit create this. It forces you to

think along a certain logical path.

Answering the same question, BT more directly draws

attention to the software algorithms:

To a certain extent you are in control, but maybe it

does dictate the way in which you do things to a

32

certain object. And then, obviously, the more time

you spend in there, you kind of understand. If

you’re modelling, that language is mirrored in

rigging, in the way that it needs to have something

done to make it work. I guess it’s to do with the

algorithms behind it, so the order in which you need

to constrain an object to another object, and what

you need to select first to do something.

These different responses suggest that having an

understanding of toolset operations anchor user

engagements with the software parameters, and not just

with the objects and entities they create. At the level

of practice, knowing how to follow the logical path, how

to work with a set of protocols, makes it possible to

communicate modelling decisions to the software. In this

sense, the automation of software processes is something

to be engaged with, rather than fully controlled by. In

addition, as well as anchoring a user in the toolsets of

Maya, dialog boxes are sites through which the deeper

structures of the software come closer to the surface.

33

Dialog boxes, accessible as drop down windows, add

visible interfaces to the UI in which information about

models, animation, rigging, lighting, shading or

rendering is available. Writing in 1998 about the UI

design of Maya, George Fitzmaurice and Bill Buxton

comment that while artists may not really want to know

about the deep structure of the program: ‘providing

access and acquiring such understanding is often

necessary for users to achieve their goals. Thus, we must

find ways of exposing the deep structure to the user in

ways that are compatible, intuitive and efficient

(Fitzmaurice and Buxton, 1998: 64).’ The primitive shapes

visible and accessible in the viewport sit alongside

dialog boxes that could include the channel box/attribute

editor, the outliner, graph editor and the script editor.

On such dialog boxes the schema reveal relationships

between the packets of data that constitute a scene, a

contrast to the viewport that shows relationships between

co-ordinates along lines of geometry, in other words

shapes. This is shown in figure 4a where data projected

as a simple sphere in the viewport is schematically

34

depicted in the hypergraph, which is shown as a separate

window on the UI. The elements visible as labels (pCube,

pSphere) would be ‘seen’ by the software as packets of

computable data about shape, position, size, colour.

Figure 4 b depicts in more detail a swivel base model as

a hierarchy of joints. These schemas bring the deep

structure closer to the surfaces. Contact with this deep

structure opens up a locality where the dispersal of

user’s agency within the automated process of the

software is more exposed. (Figures 4 a and b HERE)

The sense of a shift towards agency shared between

the user and system via these dialog boxes is evident in

the following remark made by PH about the script editor.

The script editor is a window that shows which code is

being executed in order to create a shape, in this

hypothetical example a box:

You know, if you open up the script editor and you

create a box, and it tells you, almost like, what

it’s come through to get you there. ‘Have you any

idea how hard I’ve worked to create this box for

35

you…’! You’ve got it there in a list, and that is

kind of fascinating to me, but it is something that

I really don't understand at all. The language of

Maya lies in the architecture: what is actually

running everything.

The sharing of agency between user and system is

increasingly evident when delving more deeply into what

the dialog boxes reveal about the protocols of the

software. Though users may ultimately input parameters

and so never fully relinquish control, algorithms too

hold agency in that they determine what operations do and

do not occur. In determining what operations can and

cannot occur, these algorithms generate not only a

systems’ agency but also a sense of ‘digital space,’

traced out in the schematic diagrams of the protocols.

The space that emerges is based around arrangements of

packets of data, reconfigured and connected through

computation. The organization of these packets of data is

a feature of the program language. Maya is programmed in

C++, which is an object-oriented program (OOP) language.

36

Alan Kay, who first developed object oriented programming

with the language Smalltalk in 1972, describes object

oriented programming as ‘a bit like having thousands and

thousands of computers all hooked together by a very fast

network (Kay, 1996: 517).’ Each of these ‘computers’ can

be thought of as a subroutine that acts on particular

packets of data, with the output of one routine

communicated to the next, an organization that speeds up

computation and also allows for more complexity. Digital

space so conceived does not rely on locatedness within a

given space and absolute dimensionality, but is instead

something that comes into being during the execution of a

program as it connects smaller interacting elements.

Described in this way, digital space at first seems to be

both deferred and diffuse, an abstract entity. Equally,

such a description brings out the ways in which the

agencies of the user and code are both dispersed and

bundled together. A user’s input is traced not through

the object virtually projected in the viewport, but as

moving through packets of data generated by the

software’s algorithms. How these packets of data connect

37

determines the ‘sentence structures’ and ‘logical

pathways’ described by users.

This second aspect of the operational logic of

Maya’s programming is more fully explored in relation to

specific elements of the UI, including the attribute

editor and dependency graphs. So as to give a sense of

the schematic nature of these dialog boxes, the

description is by necessity somewhat technical. The

attribute editor, outliner and hypergraph all depict

nodal relationships that make up Maya’s deep structure.

Nodes are object-oriented elements, whose nature is

described by MG: ‘It is like a schematic. It’s a logical

view of things. So is that very technical? Yes it is.

Maybe that’s contrary to how an artist uses things.

Possibly yes, I don’t know.’ In Maya any figure or object

in a scene is built from data contained in several or

many nodes. Figure 5 shows a subset set of nodes and

their relations from the creature on the right hand side

of the figure. The depicted nodes show animation curves

linked to joints, and includes data on shaders associated

with those joints (the textures of the creature). Types

38

of nodes include the creation node, the transform node

and the shape node, as well as information about lighting

and camera positions. In addition, nodes have attributes,

values that control how a node works, which are visible

in the attribute editor. In the transform node, which

controls movement, rotation and scale, the attributes

define the amount of transform that occurs. For example,

a nurbsCurve node has an attribute that contains a NURBS

curve, essentially a numeric description of the shape of

the curve. This attribute can be connected to the input

of a revolve node. The connection ‘tells’ the software to

transform the curve in ways that are defined by the

parameters of the revolve node. The revolve node also has

input attributes describing the sweep angle and the axis

that it would revolve around. (Figure 5 HERE)

Taken at a highly abstract level, working with Maya

involves using manipulators (in the viewport) to make

direct changes to nodes and attributes. But rather than a

scene being defined as objects in time and space, it can

be depicted as a dependency graph (DG), which is

essentially a chain of nodes (Autodesk, 2007). Most users

39

of Maya would not work directly with the DG level,

accessing the 900 or so commands available via toolsets

to alter information in the nodes, a point also made by

MC: ‘Under the hood it is technically node-based, and if

you really know what you’re doing you can go in and

rummage around tweaking the connections. But that’s not

usually within the purview of the average user.’ Instead,

they use the dialog boxes to connect with the deep

structure of the software. For instance, the attribute

editor and the hypergraph respectively show numeric

values and schematize the connections between nodes, the

input and output data of each node. In such dialog boxes,

data is depicted on the basis of conceptual modelling.

The data can never be seen to transform in the moment of

computation, so it can only be shown in diagrammatic

versions of the computational relationships. MG describes

this feature of Maya as follows:

So those are all graphically depicted and it’s like

a network, so you have your different icons and they

are connected with inputs showing that this is going

40

to this. It reminds me of, mostly of electronics,

logic gates and things. All the different tasks that

you want to achieve and, they all have their own

utility, they all have their own toolbox that you

can go into yourself. And that will effect what

you’re seeing on the screen. Pallettes and things. I

suppose it’s quite like any software.

Aside from the script editor, in which the executed

code scrolls by, nodes contain the strongest tracings of

the deep structures of the software, and are also the

place where the automated processes of software come

closest to being tangible. Casey Alt argues that OOP

objects in C++ (of which nodes are examples) are

autonomous because of the ways in which they are

connected together. He describes a process called

encapsulation that ‘breaks the unified linear

representation of the program into a diversity of several

autonomous, parallel, and entirely self-sufficient

computational entities (Alt, 2012: 292).’ Alt pushes the

idea of autonomy further in his description of how

41

objects (or nodes) co-ordinate with each other, as

messages run from one object to another, essentially a

sending of processing requests among and between objects.

An example would be, for instance, the connection

described above that ‘told’ software to transform a curve

according to the parameters of a revolve node, which is a

doing of space by an algorithm. Such messaging is hidden

by encapsulation so the sender has to trust the elements

of the program to co-ordinate and work together. Through

this kind of thinking, the idea that software is

invisible might easily come back.8 For users to gain

access to these encapsulated functionalities, an outward

facing element is necessary, a protocol or public face

that describes what the object does. In Maya these

outward faces are given in the toolsets on the UI, which

for Alt act as interfaces that pull users into the

system: ‘positioning them within the larger logic of

object orientation (Alt, 2012: 297).’ Though Alt’s aim is

to emphasize the autonomy of the program, his description

of OOP also fits as a description of user agency

encountering the automated processes of software. It is

42

precisely at such a moment that user agency is bundled

with that of software as they accommodate to its

procedural requirements.

Conclusion

Exploring the spatial organization of Autodesk

Maya’s UI and working with interviews given by users of

the software yields a rich description of both the UI and

also how users experience the UI. Working between the

virtually projected objects in the viewport and the

schematic diagrams of dialog boxes, user agency is

bundled and dispersed through different routes generated

by the connections between algorithms, with agency

accumulating in ways that are shared with both user and

software. When talking about automation it remains true

that software executes somewhere behind the scenes, but

the engagements by users of animation software with the

operational logics of automated processes is revealed via

the visual organizations of the UI. Maya’s UI depicts

automation through conceptual modelling of the

43

hierarchies and groupings of data. This takes its users

closer to the deeper structures of the software.

Automated processes are part of the terrain of computer-

generated animation, and so too is the skill necessary to

creatively work with those automated processes, whether

this engagement is with the surface of the software, or

at a deeper level. Adrian Mackenzie, when writing about

the complicated meshwork of connections around software,

suggests they hold together if they ‘tie[s] people

together, but not seamlessly, effortlessly or without

tensions (Mackenzie, 2006: 91).’ The terms automation and

user are tied together via software, and the lack of

possibility for resolving the tension between these

contradictory positions means that they co-exist, neither

superseding the other. As MG says: ‘That is the thing

about 3-D. It is the art side and the technical side

joining up.’

References

44

Alt C (2002) The Materialities of Maya: Making Sense of

Object-Orientation. Configurations 10:3: 387-422.

Alt C (2012) Objects of Our Affection: How Object

Orientation Made Computers a Medium. In: Huhtamo E and

Parikka J (eds). Media Archaeology: Approaches, Applications, and

Implications. Berkeley: University of California Press, 278-

301.

Autodesk (2007) Maya API| White Paper.

Autodesk (2008) The Art of Maya. 4th Edition. Indianapolis,

IN: Sybex.

Bogost I (2010) Persuasive Games: The Expressive Power of

Videogames. Cambridge, MA: The MIT Press.

Chun WHK (2008) On Sourcery and Daemons, or Code as

Fetish. Configurations 16: 299-324.

Chun WHK (2012) Programmed Visions: Software and Memory.

Cambridge, MA: The MIT Press.

Derakhshani D (2012) Introducing Autodesk Maya 2013.

Indianapolis, IN: John Wiley and Sons.

Fitzmaurice G and Buxton B (1998) Compatibility and

Interaction Style in Computer Graphics. Computer Graphics

32(4): 64-69.

45

Fuller M (2003) Behind the Blip: Essays on the Culture of Software. New

York: Autonomedia.

Galloway A (2012) The Interface Effect. Cambridge: Polity

Press.

Gurevitch L (2012) Computer Generated Animation as

Product Design Engineered Culture, or Buzz Lightyear to

the Shop Floor, to the Checkout and Beyond! Animation: an

Interdisciplinary Journal 7(2): 131-149.

Kay A (1996) The Early History of Smalltalk. In: Bergin

T and Gibson G (eds). History of Programming Languages volume 2.

New York: ACM Press.

Kirsch D (1995) The Intelligent Use of Space. Artificial

Intelligence 73: 31-68.

Kittler F (1997) There is No Software. In: Johnston J

(ed). Literature, Media, Information Systems. London: G&B Arts

International: 147-155.

Kurtenbach G, Fitzmaurice GW, Owen RN and Baudel T (1999)

The Hotbox: Efficient Access to a Large Number of Menu

Items. CHI 99: 231-237.

Luhta E (2010) How to Cheat in Maya 2010: Tools and Techniques for the

Maya Animator. Burlington, MA: Focal Press.

46

Mackenzie A (2006) Cutting Code: Software and Sociality. New York:

Peter Lang.

Mihailova M (2013) The Mastery Machine: Digital Animation

and Fantasies of Control. Animation: an Interdisciplinary Journal

8(2): 131-148.

Purse L (2013) Digital Imaging in Popular Cinema. Edinburgh:

Edinburgh University Press.

Ryan D (2011) History of Computer Graphics. Bloomington, IN:

AuthorHouse.

Sito T (2013) Moving Innovation: A History of Computer Animation.

Cambridge, MA: The MIT Press.

Stahl M (2009) Privilege and Distinction in Production

Worlds: Copyright, Collective Bargaining, and Working

Conditions in Media Making. In: Mayer V, Banks M and

Caldwell J (eds). Production Studies: Cultural Studies of Media

Industries. New York: Routledge, pp. 54-68.

Tarantini T (2012) Pictures that do Not Really Exist:

Mitigating the Digital Crisis in Traditional Animation

Production. Animation Practice, Process & Production 1(2): 273-283.

Wardrip-Fruin N (2009) Expressive Processing: Digital Fictions,

Computer Games and Software Studies. Cambridge, MA: The MIT

47

Press.

Yoon H and Malecki EJ (2009) Cartoon planet: Worlds of

Production and Global Production Networks in the

Animation Industry. Industrial and Corporate Change 19 (1): 239-

271.

48

1 Instead of the more familiar catch-all of animator, I use the word

user throughout this essay. Within the CG animation industry,

animator refers more specifically to the person who creates movement

using animation software, while modelers create the model, and

riggers rig the rigs.

2 There are many on-line tutorials for the bouncing ball exercise.

See for instance

(http://www.digitalmediaacademy.org/2010/03/29/learn-maya-animation-

bouncing-ball-part-1/), authored by Geoff Beatty©2013.

3 Escape Studio is a leading London and LA-based 3D animation

training studio. I was kindly given access to training videos.

http://www.escapestudios.com/

4 I am not seeking to claim that studio-based animation in the pre-

digital era did not involve personnel being embedded in systems of

industrial practice. Studio-based workers in the digital era are

similarly embedded in industrial practices, though the natures of

those influences alter in relation to the implementation of different

kinds of technologies.

5 Over half the people interviewed remarked on how easy or intuitive

they found Maya. Even so, 4 were also of the opinion that Maya is

counterintuitive.

6 Telotte’s description of animators simply adjusting pre-existing

digital assets resonates with Matt Stahl’s description of the

alienated experience of story boarders in an animation studio who

were only required to draw what they are asked to draw, rather than

being encouraged to have a creative input (Stahl, 2009: 62).

7 AC is referring to ‘simulated deformations,’ a feature of the

Dynamics toolset available in Maya.

8 Friedrich Kittler has famously argued that code evades perception

because it exists within a layered architecture whose interior is

inaccessible. As Kittler puts it: ‘We

simply do not know what our writing does (Kittler, 1997: 148).’