Abstract Factory Blog

Pipi Object Model pt. 3

05 Apr 2014

In part 2, we further defined our pipeline, its intent and what is required to successfully implement it. Lets have a look at how tracking fits in with all of this.

Tracking

In electronics, tracking refers to

The maintenance of a constant difference in frequency between two or more connected circuits or components. – Google “Definition of tracking”

But for our intents and purposes, we may refer to it as the way in which data is inferred by other data.

Lets take an example.

Bob outputs an obj to John who turns it into an mb and sends it forward.

To the recipient of Johns output, there is only an mb – the obj is nowhere in sight, yet the obj had a significant impact on the creation of mb.

Here, tracking means to maintain a link between obj and mb so that the recipient of Johns output may later refer back to it.

Why Tracking?

Yes, why bother. The obj is done, mb is what the cool kids are all talking about these days. However, consider this.

You are looking at the output of Mary, the compositor. Mary has produced a sequence of images for review and in the review there is you and there is Mary.

“I want the plane to come in from the left” – you say.

It is not in Mary’s responsibilities to alter neither animation nor camera so the request must be passed up-stream to whomever is responsible and capable of processing this change.

Responding to Change

In part 2, we touched briefly on how to deal with change. We said that in order for change to enter into a graph, a node must be capable of outputting partially finished information, before it is finished.

Lean Manufacturing was first coined by John Krafcik in 1988 and later translated into something called Lean Software Development

In it, there are two principles applicable to our situation.

To us, this means that whoever is responsible for making that plane come in from the left has not yet decided on a side from which the plane is to come in. The data sent was partial and is still being computed.

Thus the decision is made as late as possible, ideally after Mary has had a chance to show her work to you so that you may comment and suggest change beyond her responsibilities.

Decide Late

Proceduralism

To decide late implies that changes may alter data as it is being processed and if there is any methodology in our industry that facilitates for this it is that of proceduralism.

Proceduralism involves working with a description of steps, rather than actually performing them. It means to have the output of each step be generated rather than created which may involve delegating such processes to an external medium, such as our computers.

Lets take an example.

No doubt the first thing that runs through your mind at this point is that of Houdini and its capabilities in regards to procedural generation of data. (If it isn’t, I envy you. You’ve got some rather delightful experiences ahead of you).

Proceduralism

In this example, Bob outputs a tetrahedron to John who rotates it 45° and sends it along to Mary who colours it red.

What all three of them have in common is how they have each described the steps necessary to achieve their processing. Houdini then is the one who actually performs the processing and creates the output.

If there is anything for us to absorb from this example it is that Bob may alter his output after John and Mary have finished processing without either John or Mary having to re-visit any of their work.

This is a key factor in our design and governs the majority of choices made for the Pipi Object Model and in fact those of Pipi itself.

Output = Description

When data is described rather than created, we facilitate change.

But how can we apply these same practices to something as abstract and perhaps difficult to grasp as that of the result of another artist?

By now, we have established that to a pipeline in terms of a graph there are two things for us to work towards.

When output is partial, we can transmit it quickly and when both the transmitter and recipient have both agreed to on what data they will each receive – i.e. have signed a contract – the transmission can happen repeatedly without either party having to look for differences across inputs.

Lets transform the illustration from part 1 into something a little more suited to our conversation.

Pipeline Conversion

There. Now we can clearly see the that each node is connected via a link and that in some cases, one node has multiple inputs. The plot thickens.

Limits of Proceduralism

The notion of a describing a set of steps for the computer to process is great, but is it applicable to everything?

Can we alter the output of Bob without involving John or Mary? Yes. But can we have the output of a Storyboard department alter its output, and have that change trickle down-stream without influencing any other node?

The Wolfram Computational Engine

When you ask Siri a question, your question is translated into text. The text is then sent to one or more processes, one of which may be the Wolfram Computational Engine [1], [2].

It may be possible to one day have a change in storyboarding trickle down-stream, and witness its repercussions interactively – just as we are with the Tetrahedron outputted by Bob, rotated by John and coloured by Mary.

Until then, lets locate our limits so that we may work within them.

Within Limitations

Reasonable Bounds

Here is my claim.

Each node within this red rectangle may be condensed into a set of descriptions – just like those illustrated in Houdini above.

You may not believe me, and I don’t blame you. What goes in and what comes out of each node within this illustration varies greatly between one studio and the next.

In many cases, there are no contracts. In others, there are no partial outputs.

Why are development studios different?

You may find it odd that even though talent in our industry never stays in one place for very long, best practices and a general approach to any given task may not be even partially the same across development studios.

This may have something to do with the speed at which technology shifts today. The process employed to produce the latest blockbuster is legacy as soon as the movie hits the theatres.

At this rate, how could we ever expect consistency?

Within Reasonable Bounds

It may be possible one day for full consistency to be achieved between productions; but just as render-times has hovered around 8 hours per frame for the past 12 years [1] despite the colossal increase in computing power, so too may requirements be added to any achievable consistency.

Until then, lets locate our bounds so that we may work within them.

Stay tuned for part 4, thanks and see you in a bit.

xoxo,
Marcus