unrulybodies

Welcome to Etherpad!

This pad text is synchronized as you type, so that everyone viewing this page sees the same text. This allows you to collaborate seamlessly on documents!

Get involved with Etherpad at http://etherpad.org
Femke

In the context of Unruly bodies we want to speak about a concrete software object.

It has the curious title MakeHuman and is a 3D computer graphics middle-ware for modeling 3-dimensional humanoid characters.

We wanted to make space for this digital tool, and moreover for the practice of creating virtual bodies to bring up the entanglements of technology, representation and normativity in the context of the post-human condition.

MakeHuman is a popular Open Source tool that is actively being developed by a community of programmers, algorithms, modelers and academics.
It is used by amateur animators to prototype humanoid modeling,
by scenographers for the creation of museum displays,
by engineers for testing multi-camera systems
and by game-developers for the creation of bespoke characters.

The signature feature of the MakeHuman interface is a set of horizontal sliders.

They suggest that by interpolating gradients for gender, race, weight and age, any ‘human’ representation can be ‘made’.

But while the neat arrangements of incomparable and interconnected properties is already troubling in itself, further inspection reveals an extremely limited topology, a risky structuration based on reduced humanist categories that render the promise of infinite differentiations a mere illusion.

[screenshot slider]]
XG:
there is something we i rd with the horizontal slider (is it really conti nuous, without interruptions?)
insidiuous - norms are assumed, not made explicit (there is no 'male' 'female' mentioned on the slider, but implied).

XG:
realised one can animate these figures, by combining the humanoid with a captured movement.
we started exploring the possibilites, elements. We naively wanted to try to make a right-of-the-slider figure ('male') defined figure move like a 'woman'. Explore.

XG:
There is an assumption that something like 'female' and male movements are discrete, needs to fit with the gendered bodily appearance.
So the 'quality' can not be seen apart from the gendered body.

XG:
How does the software deal with the tendency to align?

[6m]

[textfile]] -> make sure you see title
Adva

We wondered how the pre-determined gender classification in makeHuman might influence, beyond the creation of a visual form of a humanoid, the way it/she/he moves.

In order to make a humanoid move, the language and logic of different software should come together (software assembly). The humanoid figure created by makeHuman has to be combined with movement files. Movement files are produced in three steps: recording of a human moving , capturing the motion into a software and translating it into xml files. The humanoid and the movement files ‘meet’ through the 3D animation software called Blender .

We started by looking into movement files. Even before opening the files, we already realized that each of them is classified as either male or female. Reading inside them, we found a hierarchical structure, which priorities the hip as the main part, through which the gender and the rest of the bones are defined.

[[screenshot capture software]]

We continued by looking into the process of producing a movement file and realized that after a movement is recorded, it has to be classified as female or male movement, in order to be captured and processed by the software., the idea that movement itself has a gender, independently from the gender of the body that produced that movement, is troubling on one hand, as it implements the dichotomic gender perception even on non-human phenomena and processes, but on the other hand can be an invitation to think of the body itself as an assembly of genders, as opposed to only ‘one gender per person’.
However, applying a gender to movement in the process of producing the files has nothing to do with the quality of the movement, but rather with the predetermined male or female skeleton it will be manifested through. This is how movement and software duet with each other in the processes we investigated.

The next step was a simple experiment:
We took the movement file of female crouch and combined it with a male figure created in makeHuman. The combination of the female movement with a construction of a male ‘body’ caused a software error. it produced a glitch. The movement somehow took place outside the boundaries of the human body according to the software. The result looked like a misaligned figure.

video of misaligned figure (mention Rebekka Eisner) -> loop

The misaligned figure was no doubt an alarming result of the presence of conventions about gender and human classifications within the digital realm. While acknowledging this, we also found an interesting potential in the misaligned moving humanoid to expand the space of possibilities in the relation between body and movement. From a queer perspective, even though the software experienced an error, a confrontation with an out-of-the-norm body was generated, and with it, an invitation to think out of the norm.

This experience has an interesting connection to a moment in the history of dance notation, that produced a new choreographic language, and a change in the perception of the human body.

Explanation ( Femke, Xavier - I will improvise this part (instead of writing it down in details here), as I feel confident about telling the story. Hope its fine with you two)

* the story: the discovery of the hip in occidental dance, which used until then to think of the hip as one with the torso.
* from documentation of movement produced by a body, to producing movement through writing. The system of dance notation became more than just a translation system, by being used as a generative practice that produced an unruly body.

Conclusion of Adva’s part:

* It would be interesting to think how the unruly moving body (which was produced by the glitch of the software in our process), could contribute to a new understanding not only of ourselves, but also of the nature of software we are in dialogue with.

[6m]

[stop loop]]

Femke


So that is how we return to the bugreport.

A bugreport is a type of formatted feedback used in collaborative software development.
The method is used in most Free Software projects in order to streamline the tracking of 'issues'.
Teams release often and early, and they rely on a community of users for testing, to report on problems or to formulate requests.
But the bugreport we are presenting here today is not drawn up in the expected format.
None of us is a so-called 'power-user'. We are not experts in 3D-modelling, and only some of us are proficient enough in Python (the programming language used) to actually understand the MakeHuman code.
We are seriously concerned though by the complicated intersection between understandings of gender, body representation and technology that are actively being reproduced by this Free Software tool.
But bugreports are limited to problems with individual 'features'. In such a technocentric space, the deep systemic issues with the human-machine-imaginations in MakeHuman become almost impossible to address.
Moreover (like many similar software projects), MakeHuman is the result of a set of micro-decisions that in and of themselves seem trivial. It results in a forms of sedimentation, or code-stability that altogether make it hard to question its basic assumptions.
How to report on the entanglement of norms, and mediated representations that go all the way from statistical anthromorphic data
via the fantasm of the quantified self
to Hollywood imagery?
How to speak back to the software assembly that is at work here?
Who to speak to and in what way?
Or could there be an altogether different approach to this?
What is sadly made invisible in the MakeHuman interface is the fact that the resulting images are being made by a collective of humans and non-humans.
Here, and humans are co-designing with technology and it would be interesting to think what interface could show the effect of this assembly, what would be the effect on the representation itself.
While the tool promises endless mestizos, it actually breaks with the basic means of representing cultural production.

These bodies, presences and relations are co-constructed through the imagination of both algorithms and humans but leave no space for wild combinations or un-normative renders. It all grows ordered within a limited and restricted field of cultivated possibilities, but is presented as 'natural' and 'horizontal'.

But what if we would take this tool serious as a digital companion, how would we be able to to imagine a relation?
Could the tool be thought of as the site of a frank conversation?
A conversation that would happen within bounds, obviously, as there will be no illusion about full mutual understanding. But the outcomes of the encounter would never be completely prescribed.
A conversation where the problematic understanding of these bodies as being somehow human, and made by humans would be replaced by an acknowledgement of the complicity between the various agents at work, by an awareness of the co-dependencies between imagination, gesture and machines.

Software-making is world-making. We would like to understand MakeHuman as a means for imagining relationalities, not as a crystallized cultural end.

---

emptying words, re-using them or putting them away.

Hierarchy, root, center:

HIERARCHY
ROOT Hips
{
OFFSET 39.5157 99.4896 24.7913
CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation
JOINT ToSpine
{
    OFFSET -0.0105055 1.38907 -7.13956
    CHANNELS 3 Zrotation Xrotation Yrotation
    JOINT Spine
    {
      OFFSET 0.0105055 10 1
      CHANNELS 3 Zrotation Xrotation Yrotation
      JOINT Spine1
      {
        OFFSET 0 12 1.60637
        CHANNELS 3 Zrotation Xrotation Yrotation
        JOINT Neck
        {
          OFFSET 0 27 2.26658
          CHANNELS 3 Zrotation Xrotation Yrotation
          JOINT Head
          {
            OFFSET 0 9 2.12705
            CHANNELS 3 Zrotation Xrotation Yrotation
            End Site
            {
              OFFSET 0 11 2
            }
          }
        }
        JOINT LeftShoulder
        {
          OFFSET 8 19.6109 2.86452
          CHANNELS 3 Zrotation Xrotation Yrotation
          JOINT LeftArm
          {
            OFFSET 12 1 0.681055
            CHANNELS 3 Zrotation Xrotation Yrotation
            JOINT LeftForeArm
            {
              OFFSET 19 0 -1.52608
              CHANNELS 3 Zrotation Xrotation Yrotation
              JOINT LeftHand
              {
                OFFSET 23 0 0
                CHANNELS 3 Zrotation Xrotation Yrotation
                End Site
                {
                  OFFSET 10 0 0
                }
              }
            }
          }
        }
        JOINT RightShoulder
        {
          OFFSET -8 19.6109 2.86452
          CHANNELS 3 Zrotation Xrotation Yrotation
          JOINT RightArm
          {
            OFFSET -12 1 0.681055
            CHANNELS 3 Zrotation Xrotation Yrotation
            JOINT RightForeArm
            {
              OFFSET -19 0 -1.52608
              CHANNELS 3 Zrotation Xrotation Yrotation
              JOINT RightHand
              {
                OFFSET -23 0 0
                CHANNELS 3 Zrotation Xrotation Yrotation
                End Site
                {
                  OFFSET -10 0 0
                }
              }
            }
          }
        }
      }
    }
}
JOINT LeftUpLeg
{
    OFFSET 9 -7.17245 0
    CHANNELS 3 Zrotation Xrotation Yrotation
    JOINT LeftLeg
    {
      OFFSET 0 -44.1113 0
      CHANNELS 3 Zrotation Xrotation Yrotation
      JOINT LeftFoot
      {
        OFFSET 0 -36.1829 0
        CHANNELS 3 Zrotation Xrotation Yrotation
        JOINT LeftToeBase
        {
          OFFSET 0 -4.84184 13
          CHANNELS 3 Zrotation Xrotation Yrotation
          End Site
          {
            OFFSET 0 1 6
          }
        }
      }
    }
}
JOINT RightUpLeg
{
    OFFSET -9 -7.17245 0
    CHANNELS 3 Zrotation Xrotation Yrotation
    JOINT RightLeg
    {
      OFFSET 0 -44.0551 0
      CHANNELS 3 Zrotation Xrotation Yrotation
      JOINT RightFoot
      {
        OFFSET 0 -36.1469 0
        CHANNELS 3 Zrotation Xrotation Yrotation
        JOINT RightToeBase
        {
          OFFSET 0 -4.92256 13
          CHANNELS 3 Zrotation Xrotation Yrotation
          End Site
          {
            OFFSET 0 1 6
          }
        }
      }
    }
}
}
MOTION
Frames:        683
Frame Time:        0.0333333
39.5107 99.4851 24.7919 1.29283 -5.72371 0.672317 0 0 0 2.52727 5.05271 0.319096 -5.56434 3.32673 1.29694 8.53147 3.12242 -2.34842 -4.43757 -2.29464 1.341 -29.1055 3.86484 -7.45312 -41.6174 27.5825 -18.4723 -6.84645 -13.417 0.262612 -9.01332 0.37924 -4.80751 26.2911 6.48437 16.3051 50.6802 17.8657 5.35063 5.04918 -6.43848 9.88527 2.839 0.0844801 3.41222 0.52226 7.09518 7.26472 -1.1878 5.46476 -9.93351 3.56859 -7.9309 0.247298 0.693993 2.24148 -3.2565 -3.21779 7.68437 -9.34312 0.0551059 5.01404 -4.71352 -8.88908 -3.36204 -0.261081 3.329 -12.1909 -3.65467

///////////////////////////////

looked disfigured
?

we have the capacity, desire, need to define.

queer methodology -> Sarah Achmed

we were wondering what might happen while trying to animate a 'neutral' figure
movment files were titled with M/F (must have meant that some movements belong only to specific genders)
we animated two figures, each having all the slider to one side (left/right)

hip - hunters and collectors - women started having a wider hip once they stopped being hunters. before that there was not much difference between male and female hip structure

structure of Adva's part as planned originally:

    AZ:
looking at the 'movement files' we realised a few things:
    - male - female folders

AZ:
    - actual files have a hierarchy, hips as root -> xml (history of the hips) -> software assembly

[[screenshot capture software]]

AZ:
How are these movement files produced: recording, captured an actual movement. At the moment of capture, gender is routinely determined, decided. It has nothing to do with the quality of the movement itself. Translation, duetting

AZ:
we realised - when we put the female crouch in combination with a 'slider to the right' figure ('male') - the body shape and movement misaligned.
software error -- it produced a glitch. Started moving outside the boundaries of the human body according to the software.

video of misaligned figure (mention Rebekka Eisner) -> loop

AZ:
Looking at the movement file, understanding the relation between skeleton and movements, realising the figiures on the right of the slider had a different construction than the figures on the left side of the slider.
skeleton, attachment points -- discreteness

AZ:
in the eyes of the software, it did not work.
but looking at the result of the misaligned moving humanoid, we found an interesting opening ...
while our research methodology was not queer, here Queer methodology -> without negating problems, seeing space of possibilities
Boundaries as generators, not

AZ:
discretisation -> history of dance notation. producing an unruly body
talking back to the software, taking the discussion somewhere.

AZ:
from documentation it became generative. That transition started the conversation.
from a specific solution, application -> partner in a dialogue. It talked back to its users.