4 ONDERZOEK: SOFTWARE & TECHNOLOGIE

Augmented Reality is een cruciaal aspect binnen dit project. Om grip te krijgen op deze techniek moet er onderzocht worden op welke manier deze het beste in het project kan worden toegepast. Daarom wordt er geëxperimenteerd met verschillende software en technologieën, om zo uiteindelijk de meest geschikte te vinden. In het vorige hoofdstuk is de computer in combinatie met een webcam (en beamer) als hardware gekozen voor dit project. Daarom wordt er in dit hoofdstuk onderzoek gedaan naar de meest geschikte software om Augmented Reality op deze hardware tot stand te laten komen. Achtereenvolgens bekijken we FLARManager, BuildAR, Augmented Reality A Practical Guide, AR plug-in voor Quest3D en Unifeye Design. We beginnen met de Augmented Reality toolkit FLARManager.

4.1 FLARMANAGER

FLARManagerFiguur 23: Adobe Flex Builder 3). Binnen Flex Builder kan er worden gewerkt met de bestanden (ActionScriptFiguur 24). Deze ‘eye candy’ is ‘leuk’, maar het is interessanter om te weten of er ook zelf modellen kunnen worden geïmporteerd. 27 is een framework28 dat het eenvoudiger maakt om FLARToolkit Augmented Reality applicaties te maken voor flash (). FLARToolkit is een belangrijke doorbraak voor Augmented Reality, omdat het hiermee mogelijk is om AR-applicaties te maken voor online gebruik. Om meer inzicht te krijgen in de werking van FLARManager zijn eerst enkele tutorials doorlopen. Om te kunnen werken met FLARManager moet de toolkit worden ingeladen in een ontwikkelomgeving, in dit geval gebruiken we daarvoor Adobe Flex Builder(zie 29) uit de toolkit om zo Augmented Reality toepassingen te ontwikkelen. Na het volgen van de ‘Getting Started’ tutorial komt er al snel een poppetje op de voor de webcam zichtbare marker lopen (zie

Figuur 2330: Adobe Flex Builder 3.	Figuur 2431: FLARManager voorbeeld poppetje op marker.

Een eigen model importeren

Het voorbeeld poppetje bestaat uit een DAE-bestand. Als we eigen modellen willen gebruiken, kunnen we er dus het beste voor zorgen dat deze ook het DAE-bestandstype hebben. Met de 3D modelleersoftware Autodesk 3ds Max kunnen 3D modellen worden gemaakt en geëxporteerd naar DAE. Om de werking hiervan in praktijk te testen maken we een simpel 3D testobject: een ARdu-test-snake! (zie Figuur 25).

Figuur 2532: Screenshot van de viewport in 3Ds Max met de ARdu-test-snake.

In 3ds Max krijgt de ARdu-test-snake ook twee textures33, een voor de ogen en een voor het lichaam (geel/oranje patroon). Op deze manier wordt gelijk zichtbaar of de textures ook worden meegenomen bij het exporteren en inladen in FLARManager. Na

wat trial & error verschijnt de ARdu-test-snake uiteindelijk als Augmented Reality versie op zijn marker en kan het nieuwe huisdier in de armen worden gesloten (zie Figuur 26).

Figuur 2634: ARdu-test-snake is alive!

Zoals we hierboven hebben gezien werkt het inladen van eigen (3D)modellen met FLARManager zonder veel problemen. Voor dit project hebben we echter meer mogelijkheden en functionaliteiten nodig qua Augmented Reality, aangezien we minimaal meerdere markers & modellen tegelijk willen kunnen gebruiken. We bekijken hierna welke mogelijkheden FLARManager ons hiervoor biedt

‘Multiple markers’

Voor het gebruik van meerdere markers bevat FLARManager een voorbeeld bestand (FLARManagerExample_PV3D). Met dit voorbeeld kunnen er meerdere markers tegelijk worden herkend. Het voorbeeld werkt echter enkel met eenvoudige kubussen. Dit is op het eerste gezicht geen probleem, aangezien deze vervangen kunnen worden door eigen modellen?

Figuur 2735: FLARManager Multiple markers/objects.

Helaas blijkt het vervangen door eigen modellen minder makkelijk dan gehoopt. Dit blijkt ook uit een tekst op de website van squidder.com, waar men zich ook bezig houdt met FLARToolkit/FLARManager: “One of the big things we’ve been wrasslin’ with recently here at Squidder is how to handle multiple instances of multiple markers using FLARToolKit. Well we haven’t totally nailed it — close, but there are still a few niggling issues. So we’re looking to you, dear Squiddite, to help us out.”

Ook anderen stoeien met de ‘multiple marker’ kwestie, zo blijkt uit een project op de website Flartoolkitdocs.org, ‘AR fighters’. Hierbij verschijnen twee karakters op twee verschillende markers, in de vorm van een vechtspel. De karakters kunnen worden bestuurd met het toetsenbord en wanneer de tegenstander getrapt wordt, stijgt de score. Maar ook hier vinden we commentaar als: “* THIS CODE IS FULL OF BUGS AND ERRORS, it's an exercise of AS3 understanding by a non expert. Don't expect an elegant coding :)”

Het komt erop neer dat er op het moment van schrijven geen betrouwbare manier is voor het gebruiken van meerdere markers/objecten in FLARManager. Wanneer we FLARManager toch willen gebruiken voor het laten zien van meerdere Augmented Reality objecten op verschillende markers, zal de ActionScript code hiervoor zelf geschreven moeten worden. En dan nog blijft het de vraag hoe stabiel het geheel in dat geval gaat werken. Genoeg reden om nog verder te kijken naar andere mogelijkheden, zoals het programma BuildAR.

4.2 BUILDAR

BuildAR van HITLabNZ (www.hitlabnz.org ) is een programma waarmee eenvoudige AR scènes kunnen worden gemaakt. Dit klinkt interessant, alleen is de vraag hoe beperkt het ‘eenvoudige’ is. Dit gaan we nu bekijken.

Figuur 2836: BuildAR interface met marker en kubus.

Wanneer het programma wordt geopend, zien we een eenvoudige interface (zie Figuur 28). In de bovenbalk een aantal knoppen voor het verplaatsen, roteren en schalen van objecten en aan de linkerkant de mogelijkheid om AR-markers en objecten toe te voegen.

Figuur 2937: Verplaatsen van het object ten opzichte van de marker.

AR-markers kunnen worden toegevoegd door het inladen van patt-files. Er worden standaard een aantal markers in patt-formaat meegeleverd, maar deze kunnen ook zelf worden gemaakt met behulp van de ‘Generate Patterns’ optie. Wanneer een marker is toegevoegd, kan hieraan een (3D)object worden gekoppeld. Deze modellen kunnen onder andere de bestandstypes *.ive, *.obj of *.3ds hebben. Het aan de marker gekoppelde object kan met de knoppen in de bovenbalk worden verplaatst (t.o.v. de marker), geschaald of gedraaid. Het proces kan een aantal keer worden herhaald, zodat er meerdere markers en objecten tegelijkertijd gebruikt kunnen worden.

Figuur 3038: BuildAR demonstratie tijdens een van de interviews: ARdu-test-snake met een buddy!

Met een paar klikken hebben we wat eerder met FLARManager niet lukte: meerdere eigen AR-modellen. Dit lijkt mooier dan het is aangezien we hiermee ook alle functionaliteiten van het programma hebben gezien en het niet mogelijk is om dit verder uit te breiden of aan te passen. De eenvoudige en simpele werking van het programma is echter wel ideaal om snel het principe van Augmented Reality uit te leggen en daarom is het ook gebruikt tijdens de interviews (zie Figuur 30).

Aangezien we met BuildAR niet veel verder gaan komen binnen dit project, zetten we de zoektocht voort. Hierna bekijken we in hoeverre het boek ‘Augmented Reality A practical guide’ interessant is.

4.3 AUGMENTED REALITY A PRACTICAL GUIDE

Het boek ‘Augmented Reality A Practical Guide’ van Stephen Cawood en Mark Fiala is volgens de schrijvers een praktische handleiding voor het maken van eigen Augmented Reality applicaties. Het boek gaat in op de werking van Augmented Reality en bevat een aantal voorbeelden, waarmee geëxperimenteerd kan worden. Als eerste bekijken we deze voorbeelden. Het geeft nogal wat problemen om deze aan de praat te krijgen, waarschijnlijk door compatibiliteitsproblemen met Windows 7 dat op het testsysteem draait. In een Windows XP omgeving werken de voorbeelden wel. Hieronder enkele afbeeldingen daarvan:

 

Figuur 3139: Augmented Reality A Practical Guide voorbeelden.

De standaardobjecten zoals de auto en de vis zijn via een configuratiebestand (setup_artag_3d.cfg) eenvoudig te vervangen met eigen modellen. Dit kunnen modellen zijn met *.obj-, *.wrl- of *.ase bestandstype welke zijn te exporteren vanuit 3ds Max. Wanneer er zelf een applicatie moet worden geschreven, zal er geprogrammeerd moeten worden in C++ of C#. Aangezien mijn persoonlijke kennis van het programmeren in deze talen nihil is, zal dit een obstakel zijn wanneer het gekozen wordt voor het ontwikkelen van de Toolkit in hoofdstuk 5. Op het online support forum van het boek is op het moment van schrijven nog weinig activiteit, en daarom moet hier ook geen ondersteuning van worden verwacht. Daarnaast is het boek ondertussen meer dan 2 jaar oud, en wanneer we werken met snel evoluerende technieken als Augmented Reality is dit een lange tijd. De vraag is of er ondertussen geen betere en toegankelijkere alternatieven zijn te vinden? Hierna kijken we naar een recent uitgebrachte mogelijkheid.

4.4 AR PLUG-IN VOOR QUEST3D

Op 19 februari dit jaar bracht het bedrijf DPI een Augmented Reality plug-in (gebaseerd op ARToolkit40) voor Quest3D op de markt. Quest3D is een software pakket waarmee 3D applicaties kunnen worden ontwikkeld. Het pakket kenmerkt zich door een visuele stijl van programmeren, waardoor dit ook voor minder ervaren programmeurs toegankelijk zou moeten zijn. Een interessante optie om te bekijken met het oog op dit project. Aangezien er geen ervaring is in het werken met Quest3D worden er eerst introductie tutorials doorlopen. Deze tutorials behandelen onder andere de Quest3D interface, logica en interactie, geluid, texturing, etc. Na het volgen van de tutorials is de werking van Quest3D redelijk duidelijk. Echter wordt opgemerkt dat de logica welke nodig is voor het aansturen van grotere projecten redelijk snel complex kan worden.

Door contact op te nemen met Lex van der Sluijs van DPI is een demoversie verkregen van de AR-plug-in voor Quest3D (‘DPI AR for Quest3D release 1.01 alpha’). Het betreft hier zoals de naam doet vermoeden een ‘alpha’ versie, wat betekent dat de plug-in nog geen ‘final’ status heeft bereikt en nog bugs kan bevatten. Daarnaast heeft de demo de volgende beperkingen:

• Maximaal 4 AR-markers
• Elke 10 min stopt de werking voor 30 seconden

Deze beperkingen zijn echter geen obstakel voor het experimenteren met de plug-in in Quest3D. De plug-in komt met enkele voorbeelden, welke gebruikt kunnen worden om inzicht te krijgen in de werking. Door een van de voorbeelden te openen in Quest3D zien we het scherm van Figuur 32. Dit is de achterliggende workflow van de voorbeeldapplicatie. De werking van deze workflow is niet bepaald intuïtief te noemen en komt nogal cryptisch over. Dit heeft niet zozeer te maken met de plug-in, maar met de algemene werking van Quest3D. Na enkele dagen experimenteren met het programma en de plug-in lukt het om kleine wijzigingen aan te brengen in de Augmented Reality voorbeelden, maar het proces verloopt stroef.

Figuur 3241: Quest3D AR voorbeeld workflow.

 

 

 

 

 

 

 

 

 

 

Figuur 3342: Wanneer de workflow wordt uitgevoerd zien we twee objecten op de markers verschijnen.

Quest3D is van oorsprong niet bedoeld voor het ontwikkelen van Augmented Reality applicaties, maar met de plug-in wordt het wel mogelijk. Dit heeft als nadeel dat het programma zeer veel opties bevat voor het ontwikkelen van andere soort applicaties en dat maakt het geheel niet overzichtelijker. Het visueel programmeren lijkt in eerste instantie een uitkomst, maar in praktijk blijkt het al snel complex te worden. De algemene leercurve van Quest3D is steil te noemen. Dit zou wellicht te overkomen zijn, wanneer er het idee was dat de combinatie van Quest3D met de plug-in een oplossing zou kunnen betekenen voor dit project. Maar de plug-in is echter nog een ‘alpha’ versie en daarom is deze nog niet betrouwbaar te noemen. Door de recente verschijning is er ook weinig documentatie en ondersteuning te vinden voor het ontwikkelen van AR-applicaties met Quest3D en de plug-in. Alles opgeteld zullen we voor dit project op zoek moeten naar een ander alternatief. Daarom bekijken we hierna de Unifeye Design software van Metaio.

4.5 UNIFEYE DESIGN

Unifeye Design is een stand-alone Augmented Reality softwarepakket voor 3D professionals, aldus de website van Metaio. Met het oog op de designer doelgroep hoeft er binnen het programma niet ‘geprogrammeerd’ te worden, maar wordt er gewerkt met een visuele programmeerstijl (vergelijkbaar met Quest3D, zie §4.4). De marketingpraatjes klinken interessant, maar om de praktijk te bekijken gaan we eerst de demoversie aan een nader onderzoek onderwerpen.

De interface van het programma (zie Figuur 34) komt in eerste instantie eenvoudig en overzichtelijk over. Wanneer we beter kijken, wordt het duidelijk dat het programma toch veel mogelijkheden heeft. In de rechter werkbalk zien we een viertal tabs, achtereenvolgens ‘Objects’, ‘Measurement’, ‘Configuration’ en ‘Extras’. Elke tab is weer onderverdeeld in subcategorieën, waarmee bijvoorbeeld objecten kunnen worden gemanipuleerd of ‘Marker Tracking Configurations’ kunnen worden gemaakt. Dit zijn functionaliteiten die we graag zien met het oog op het ontwikkelen van Augmented Reality.

Figuur 3443: Interface van Unifeye Design.

Het programma bevat een aantal voorbeeldbestanden die bekeken kunnen worden om zo de werking beter te begrijpen. Een interessant voorbeeld is de ‘Architecture Workflow’. Dit voorbeeld bestaat uit een AR-model van een huis met meerdere verdiepingen op een grasveld. Wanneer de AR-marker (in de vorm van een plattegrond) in beeld komt, verschijnt het huis en kan de gebruiker met de pijltjestoetsen verdiepingen verwijderen, zodat er binnenin het huis gekeken kan worden (zie Figuur 35, Figuur 36 en Figuur 37).

Figuur 3544: De marker in de vorm van een plattegrond.	Figuur 3645: AR-huis op de marker.
Figuur 3746: Door op de pijltjestoetsen te drukken zijn verdiepingen verdwenen en is een doorsnede zichtbaar.

Om de werking van dit voorbeeld te begrijpen moeten we het ‘Workflow’ bestand bestuderen. Dit is het bestand met de logica van het voorbeeld, zoals de functionaliteit van de pijltjestoetsen, het verschijnen van het huis op de marker, etc. In een Workflow bestand kan zoals eerder beschreven de logica van het project op een visuele manier ‘geprogrammeerd’ worden. Door de juiste elementen met elkaar te verbinden kan er een scène ontstaan met extra functionaliteiten, zoals het gebruiken van het toetsenbord voor input, het weergeven van meerdere objecten, etc. Hieronder een voorbeeld van een deel van het Workflow bestand van het huis.

Figuur 3847: Interface Workflow Authoring van het huisvoorbeeld.

Het programma bestaat uit twee belangrijke delen: De Workflow Authoring interface (zie hierboven) en de Unifeye Design interface (zie Figuur 34). Het doel van de Workflow Authoring interface hebben we net gezien, daarom kijken we nu naar het doel van de Unifeye Design interface.

Zoals eerder geschreven bestaat de Unifeye Design interface o.a. uit 4 tabbladen: ‘Objects’, ‘Measurement’, ‘Configuration’ en ‘Extras’. De ‘Objects’ en de ‘Configuration’ zijn de belangrijkste en daarom hier een korte omschrijving van de functies van deze twee tabbladen:

• Objects
  • (3D)objecten inladen als VRML bestanden (zie ook §5.2.1)
  • Objecten toewijzen aan specifieke markers
  • Objecten aanpassen: verplaatsen, schalen, draaien en VRML-parameters.
• Configuration
  • Camera Calibration: kalibreren van de camera voor betere tracking
  • Tracking Configuration/Marker Tracking Configuration: het configureren van de te gebruiken marker(s).

Samengevat is de Unifeye Design interface dus bedoeld voor het opzetten van de ‘statische’ setup. Er kunnen (3D) modellen worden ingeladen, deze kunnen worden gekoppeld aan markers en er kunnen configuraties worden gemaakt en opgeslagen. Dit is grofweg wat de meeste eerder besproken programma’s en toolkits ook konden, alleen kunnen er nu zonder problemen meerdere markers en objecten worden gebruikt. Wanneer de statische scène klaar is kunnen de configuratiebestanden in de Workflow Authoring interface worden ingeladen en kan de logica worden ‘geprogrammeerd’.

Unifeye Design lijkt van alle in dit hoofdstuk onderzochte oplossingen het meeste perspectief te bieden voor dit project. Het programma voelt ook ‘degelijk’ aan, wat bij andere nog wel eens ontbrak. De visuele manier van programmeren spreekt meer aan dan dat het geval was bij bijvoorbeeld Quest3D. Dit is ook te wijten aan het feit dat Unifeye Design specifiek is bedoeld voor het ontwerpen van Augmented Reality concepten, en dus geen overbodige functionaliteiten bevat die voor verwarring kunnen zorgen. Het enige minpunt is dat Augmented Reality concepten niet geëxporteerd kunnen worden naar stand-alone applicaties, waardoor het niet mogelijk is om projecten op een computer zonder Unifeye Design te gebruiken. Voor dit project is dat echter geen breekpunt, aangezien het hier vooral over het concept gaat. Als laatste is er wel nog de ‘professionele’ prijs van het softwarepakket, en dat is wel een obstakel te noemen.

Aangezien Unifeye Design een van de meest interessante oplossingen lijkt voor dit project is er contact opgenomen met ontwikkelaar Metaio. Na het horen van de inhoud en doelstelling van het project, was Metaio bereid om de software tegen een sterk gereduceerd tarief beschikbaar te stellen. Dit aanbod is dankbaar aangenomen en daarom zullen we de Toolkit in hoofdstuk 5 gaan ontwikkelen met Unifeye Design. Als eerste test wekken we alvast ons huisdier, de ARdu-test-snake, tot leven  (zie Figuur 39).

Figuur 3948: Ardu-test-snake in Unifeye Design.

 

 

 

 

 

 

 

Als laatste geven we nog een kort overzicht van andere mogelijke oplossingen die zijn bekeken, maar waarbij het geen meerwaarde was om deze hier uitgebreid te vermelden.

4.6 OVERIGE PROGRAMMA’S

Naast de hiervoor beschreven programma’s en toolkits zijn er tijdens het onderzoek nog vele andere de revue gepasseerd. Voor elk platform of technologie lijkt momenteel wel een Augmented Reality plug-in/variant/addon te worden gemaakt. Zo is er SLARToolkit, een Augmented Reality ‘library’ voor Microsoft Silverlight, is er een ARToolkit ‘library’ voor Processing, etc. Verder zijn ook de programma’s SSTT Visualizer, reacTIVision en LinceoVR bekeken, maar al deze programma’s konden voor gebruik in dit project niet overtuigen.

4.7 CONCLUSIE

De moeizame zoektocht naar de juiste software en technologie heeft uiteindelijk toch zijn vruchten afgeworpen. Na het vele zoeken, experimenteren, weer zoeken en weer experimenteren, werd er eindelijk een bruikbare oplossing gevonden voor dit project: Unifeye Design. Dit neemt echter niet weg dat er door de zoektocht beter inzicht is verkregen in de materie, aangezien er geëxperimenteerd is met verschillende technologieën, toolkits, markers, (3D)modellen, etc. Al deze opgedane kennis kan voor een groot deel gebruikt worden bij het verder werken in Unifeye Design en daarmee heeft de zoektocht toch zijn nut gehad. In het volgende hoofdstuk beginnen we met het ontwikkelen van de AR-Toolkit in Unifeye Design.

27 Website: http://words.transmote.com/wp/flarmanager/
28 Een framework is een omgeving waarbinnen applicaties ontwikkeld kunnen worden.
29 ActionScript is de scripttaal van Adobe Flash.
30 Bron: Screenshot Adobe Flex Builder 3
31 Bron: Screenshot FLARManager voorbeeld
32 Bron: Screenshot Autodesk 3ds Max
33 Afbeeldingen welke op een 3D model worden ‘geplakt’, om zo een oppervlaktepatroon te creëren.
34 Bron: Screenshot FLARManager experiment
35 Screenshot FLARManager experiment
36 Bron: Screenshot BuildAR
37 Bron: Screenshot BuildAR
38 Bron: Screenshot BuildAR demonstratie
39 Bron: Cawood, Fiala (2007).
40 Niet de ‘AR-Toolkit’ die we in dit project ontwikkelen!
41 Bron: Screenshot Quest3D interface.
42 Bron: Quest3D experiment met AR plug-in.
43 Bron: Screenshot Unifeye Design interface.
44 Bron: Screenshot Unifeye Design voorbeeld.
45 Bron: Screenshot Unifeye Design voorbeeld.
46 Bron: Screenshot Unifeye Design voorbeeld.
47 Bron: Screenshot Workflow Authoring interface.
48 Bron: Screenshot Unifeye Design met experiment.

Lees Hoofdstuk V: Onderzoek: Ontwikkelen van de AR-Toolkit