Tässä osiossa selvitetään järjestelmän toteutettu arkkitehtuuri. Kehitystyön aika-na arkkitehtuuriin tulleita muutoksia ei ole kuvattu, koska arkkitehtuuri poikkeaa suunnitellusta vain videoiden näyttämisen suhteen ja toteutetut komponentit tar-kentuivat vasta kehitystyön aikana.
6.2.1 Funktionaaliset osat Ohjausdata; mallin attribuuttien muokkaus
Käyttösuhde; komponentti käyttää toista Nimi ehostemiehen ohjaus
T ehostemies T
Kuva 6.1: Järjestelmän arkkitehtuuri. Nuolet kuvaavat erilaisia käyttö- ja ohjaus-suhteita.
Kuvassa 6.1 on esitetty järjestelmän arkkitehtuurin funktionaaliset osat ja niiden
välinen viestitys. Funktionaaliset osat ovat: kuvantamisjärjestelmä, kasvoseuranta ja ohjauskäyttöliittymä.
Komponentit
Kuvantamisjärjestelmän vastuulla on tuottaa esityksen graikka ja kuvan anamor-foosi. Vaikka kuvantamisjärjestelmä on selkeä funktionaalinen kokonaisuus, se si-sältää arkkitehtuurin kannalta olennaisia pienempiä osia. Nämä osat ovat VirChor, komponenttijärjestelmä ja videopurku.
VirChor toimii alustana, joka antaa komponenttijärjestelmälle piirtokomennot se-kä piirtää kasvomallitehosteet. Kaikkien muiden tehosteiden luomiseen VirChor se- käyt-tää komponenttijärjestelmää. Teknisesti VirChor toimii alustana, jonka päälle kom-ponenttijärjestelmä on rakennettu itsenäiseksi kokonaisuudeksi.
Komponenttijärjestelmä koostuu komponenttihallinnoijasta ja useammasta sen alaisesta komponentista. Komponenttihallinnoija toimii alustana ja viestinvälittäjä-nä yksittäisille komponenteille ja tarjoaa yksinkertaisen rajapinnan komponenttien lisäämiseksi. Kukin komponentti toteuttaa jonkin graasen tehosteen.
Kasvoseurannan vastuulla on erottaa näyttelijän kasvoilta suun asento ja lähettää sitä vastaavat kasvomallin argumentit viesteinä kuvantamisjärjestelmälle. Ohjaus-käyttöliittymän tarkoituksena on tarjota tehostemiehelle helppo tapa ohjata graa-sia tehosteita. Se lähettää sopivat ohjausviestit kuvantamisjärjestelmälle.
Viestitys
Tehostemies ohjaa järjestelmää kahden graasen käyttöliittymällä: ohjaus- ja kasvo-seuranta-käyttöliittymällä kautta.
Kasvoseuranta lähettää lähettää VirChorille kasvomallien animointiparametrit.
Ohjauskäyttöliittymän lähettää komentoja niin VirChorille kuin Komponenttihallin-noijalle. Viestien käsittely on synkronoitu kuvapiirtoon siten, että mallien attribuutit muuttuvat efektiivisesti vasta seuraavan kuvapiirtoon. Viestintä on yksisuuntaista, joten käyttöliittymät eivät voi kysellä muiden järjestelmän komponenttien tiloja.
Ohjauskäyttöliittymän viestit muokkaavat yksittäisten komponenttien attribuut-teja, mutta modulaarisuuden ja ajoituksen vuoksi viestit kiertävät komponentti-hallinnoijan kautta. Kasvoseurannan, ohjauskäyttöliittymän ja kasvokomponentin VirChorille lähettämissä viesteissä muokataan vain kasvomallien attribuutteja.
Kolmas viestityyppi on käyttökutsu, jolla kutsuja haluaa saada kutsuttavan avulla juuri sen hetkisesti jonkin palautteen tai tehtävän tehtyä. Toteutuksessa nämä ovat funktiokutsuja funktionaalisten osien sisällä. VirChor käyttää funktiokutsuja
ohja-takseen komponenttijärjestelmän valmistautumaan kuvan muodostukseen tai piirtä-mään kuvan. Komponenttihallinnoija välittää kutsut kullekin komponentille. Video-komponentti käyttää videopurkua saadakseen kuvaan piirrettäväksi yksittäisiä kuvia videotiedostoista.
6.2.2 Funktionaalisen arkkitehtuurin perustelut
Arkkitehtuurin suunnittelun lähtökohtien merkittävin tekijä oli VirChorilla toteute-tun MARC-kasvomallin käyttäminen luomaan kaksi esityksen avataria. Kasvomallien valintaan johtaneet syyt esitellään toteutettujen komponenttien esittelyn kohdassa 7.2.1. Kasvomallien valinnan aikana selvitettiin ettei VirChor tulisi aiheuttamaan arkkitehtuurin kannalta ongelmia.
VirChor on itsessään tehosteiden esitys- ja kuvantamisjärjestelmä, mutta se ei soveltunut suoraan projektin pääasialliseksi esitysjärjestelmäksi siinä olevien puut-teiden vuoksi. VirChorilla tehtyjen tehospuut-teiden takia sen oli kuitenkin jollain tavalla oltava kuvantamisjärjestelmän osana, sillä kahden erillisen ohjelman toteuttaminen olisi rajoittanut tehosteiden yhdistelymahdollisuuksia, hankaloittanut tehosteiden ohjaamista ja tuonut epävarmuustekijöitä ja viiveitä tehosteiden esittämiseen.
Vaihtoehtoina oli siten muokata VirChoria toimimaan muun esitysjärjestelmän osana, tai käyttää VirChoria esitysjärjestelmän alustana. Toteutuksessa päädyttiin jälkimmäiseen ratkaisuun, koska sen arvioitiin olevan helpompaa. MARC-kasvomal-lin ja VirChorin muokkaaminen lisäosaksi johonkin muuhun esitysjärjestelmään kat-sottiin olevan työlästä.
VirChorin käyttö alustana ei katsottu aiheuttavan juuri mitään rajoitteita kom-ponenttijärjestelmälle, sillä komponenttijärjestelmä oli mahdollista toteuttaa hyvin itsenäiseksi järjestelmäksi VirChorin näkymägraan solmuna.
VirChorin puutteet
VirChorin puutteet olivat huono modulaarinen laajennettavuus, ohjausviestien kä-sittelyn puutteet, vahva tukeutuminen työlääseen XML-pohjaiseen skriptaukseen ja muutama toiminnallinen puute.
VirChorin esittämä maailma on toteutettu näkymägraana, jonka solmut ovat objekteja. VirChoria on mahdollista laajentaa lisäämällä siihen omia solmuluokkia.
Tämä osoittautui kuitenkin työlääksi, koska VirChor ei tarjonnut käytännössä min-käänlaista rajapintaa solmuluokille.
VirChorin viestijärjestelmän lähtökohtana on hyvin samanlainen idea kuin pro-duktion esitysjärjestelmälle haluttiin; esitysjärjestelmän mallia oli tarkoitus ohjata
<<laite>>
Kamera 2 ⨉ projektori
<<IEEE 1394>>
Kuva 6.2: Fyysiset laitteet ja ohjelmistojen sijoittelu.
erillisestä käyttöliittymästä verkon yli välitettyjen viestien avulla. VirChor ottaa vas-taan OSC-protokollan mukaisia viestejä ja suorittaa viestin OSC-osoitetta van XML-pohjaisen skriptin. Solmuluokille ei voi määritellä suoraan viestejä vastaa-via toimintoja, vaan kaikki muutokset näkymägraan solmuille on tehtävä skriptien kautta muuttamalla solmujen attribuuttien arvoja. Skriptien käyttö olisi rajoittanut toteutuksen joustavuutta ja tuonut merkittävästi lisätyötä.
VirChorin OSC-tuki ei sisältänyt niputettuja komentoja (engl. bundled messa-ges), joten tehosteiden yhtäaikainen ajoitus olisi pitänyt toteuttaa skriptien avulla.
Viestijärjestelmä myös yhdisti useampia saman osoitteen sisältäviä viestejä yhteen riippumatta niiden parametreista.
VirChorin videototeutuksella ei voinut näyttää videoita viestillä liipaistuna halut-tuna hetkenä eikä eri nopeuksilla. Myös nosto ja häivytysominaisuudet puuttuivat.
6.2.3 Sijoittelu
Kuvassa 6.2 esitetään, kuinka kolmea funktionaalista kokonaisuutta vastaavat toi-minnallisuudet toteutettiin omina ohjelmistoinaan ja ajettiin erillisissä tietokoneissa.
Kuvantamisjärjestelmä käytti molemmat saatavilla olleet kuvaulostulot datapro-jektorien ajamiseen, joten ohjauskäyttöliittymä tarvitsi oman koneensa ja näytön.
Kuvamateriaali analysoitiin näyttämön lähelle asennetussa tietokoneessa, koska yh-teysstandardit rajoittivat kameroiden johdonpituuksia ja viivettä voitiin vähentää lähettämällä vain kasvomallin ohjauskomennot yhteysverkon yli.
Fyysinen jako tuki järjestelmän robustisuutta, vaikka olikin käytännön sanele-ma. Ohjelmistojen ei tarvinnut jakaa resursseja, ja mahdollisten laitteistovikojen vaikutus olisi ollut rajoitetumpi. Kaikissa koneissa ajettiin 32-bittistä Ubuntu 8.10 -linuxjakelua.
(11 Uiminen) 9 MIK(4)
s tcp
Videossa tiukka leikkaus, joten ei näytetä.
random 100
sprintf send Waves|0.0|EX_%d_%d_3_%d APPLY
Lopeta ripple KUN Antti on hävinnyt näkyvistä
Luukku kiinni
KUN .. kertoivat tilaisuudessa Apollosoftin uusimmista linjavedoista"
send ALL|0.0|OFF Waves|0.0|ON Waves|0.0|iWaveCount_15 Waves|0.0|iDamperBorderWidth_10 Waves|0.0|iForce_0.012
Kuva 6.3: Kuva ohjauskäyttöliittymästä: kohtauksen 8 ja 9 ohjauskontrolleja.