5 ONDERZOEK: ONTWIKKELEN VAN DE AR-TOOLKIT

Na het vooronderzoek in de vorige hoofdstukken is het nu tijd om aan de slag te gaan met het ontwikkelen van de AR-Toolkit. In deze Toolkit komt het onderzoek samen als een concreet Augmented Reality concept. De Toolkit heeft als doel om te worden ingezet in een lessituatie, in dit geval specifiek in de geschiedenisles. Daarom is de input van een geschiedenisdocent van groot belang bij het ontwikkelen van prototypes. Tijdens de ontwikkelingsfase zal de mening van deze docent dan ook regelmatig geraadpleegd worden. De insteek van de Toolkit is dat deze voldoet aan de eisen van het ‘nieuwe leren’ (zie hoofdstuk 2), door het ‘pedagogisch model van verkennend en onderzoekend leren in kleine groepen’ (zie §1.4) als uitgangspunt te nemen.

In hoofdstuk 4 hebben we wegens daar genoemde redenen, gekozen om de Toolkit te ontwikkelen voor gebruik op een desktop of laptop computer met webcam en eventueel beamer. Daarna hebben we in hoofdstuk 4 een geschikte ontwikkelomgeving gevonden voor de uitwerking, Unifeye Design. In dit hoofdstuk gaan we nu concreet starten met de ontwikkeling van prototypes. De prototypes moeten gezien worden als AR-omgevingen waarmee of waarbinnen leerlingen opdrachten kunnen uitvoeren. De Toolkit kan meerdere van deze AR-omgevingen en opdrachten bevatten. Hierna beschrijven we in meer detail wat we precies onder de ‘AR-Toolkit’ verstaan.

5.1 DE AR-TOOLKIT

De AR-Toolkit heeft als doel om de docent een hulpmiddel te geven waarmee hij zijn leerlingen op een andere manier met de lesstof om kan laten gaan. De Toolkit kan in een ideaal geval gezien worden als een verzameling van op Augmented Reality gebaseerde opdrachten, welke de docent naar eigen inzicht in zijn les kan inzetten. In de ideale situatie kan een docent zelf opdrachten samenstellen. Dit samenstellen kan bijvoorbeeld gebeuren door het gebruiken van ‘opdracht-templates’, welke de docent zelf kan invullen met informatie. Deze templates49 bevatten de logica achter de opdracht. Een voorbeeld van een ‘opdracht-template’ is bijvoorbeeld een opdracht waarbij leerlingen een juiste combinatie (van markers/objecten) moeten maken. Wanneer de

combinatie juist is gebeurt er iets. De docent kan deze template nu gebruiken om zijn eigen informatie in te stoppen, bijvoorbeeld: “Combineer de juiste persoon met het juiste gebouw”. Bij dit voorbeeld zou de docent Augmented Reality modellen van enkele personages en gebouwen nodig hebben. Aangezien er van docenten niet verwacht kan worden dat zij deze zelf ontwikkelen, zou er een bibliotheek met (3D)modellen moeten zijn, waaruit geput kan worden, en welke steeds aangevuld wordt. Dit idee kwam ook ter sprake tijdens het interview met Harold van Ingen (zie bijlage 3: r342). Dit zou bijvoorbeeld kunnen in de vorm van een klapper met markers, waarbij elke marker een bepaald object, animatie, film, etc. vertegenwoordigt. Door de juiste markers uit deze bibliotheek te combineren kan de docent een opdracht samenstellen.

Voorgaande is zoals gezegd een beschrijving van een ideale situatie waarop het concept van de Toolkit zou kunnen werken. Voor dit project is dit echter te omvangrijk om volledig uit te werken en daarom richten we ons hierna op het uitwerken van enkele opdrachtomgevingen50, welke deel zouden kunnen uitmaken van een dergelijke Toolkit. Hierna doen we kort vooronderzoek naar de punten waar we rekening mee moeten houden bij het ontwikkelen.

5.2 VOORONDERZOEK VOOR ONTWIKKELING TOOLKIT

Bij het ontwikkelen van de Toolkit moet er rekening worden gehouden met de restricties van Augmented Reality en de Unifeye Design software. Unifeye Design ondersteunt bijvoorbeeld alleen VRML bestanden, en (3D)modellen moeten dus ook in dit formaat worden ingeladen. Hieronder meer daarover.

5.2.1 VIRTUAL REALITY MODELING LANGUAGE (VRML)

VRML staat voor Virtueal Reality Modeling Language. Het is een op ASCII (tekst) gebaseerde (markup-)taal, waarmee driedimensionale interactieve objecten kunnen worden beschreven. VRML ondersteunt animaties, ruimtelijk geluid, ‘collision detection’51 en ‘scripting’52. VRML bestanden worden ook wel ‘worlds’ genoemd en daarom hebben zij de bestandsextensie *.wrl (Jeginovic, 2004). Veel 3D modelleerpakketen ondersteunen het exporteren van VRML bestanden. In dit project

wordt Autodesk 3ds Max gebruikt als ontwikkelomgeving voor 3D modellen. Hierna gaan we dan kijken hoe we binnen 3ds Max kunnen werken met VRML bestanden.

5.2.2 3DS MAX & VRML

Figuur 4053: VRML97 toolbar in 3ds Max.

Voor het werken met VRML bestanden heeft 3ds Max een aparte toolbar met ‘Helper’ objecten. Hiermee kan onder andere geluid worden toegevoegd, kunnen animaties worden geactiveerd bij benadering van een object, etc. Niet alle ‘Helpers’ zijn geschikt voor gebruik in dit project, maar hieronder de beschrijving van enkele mogelijk interessante54:

• ProxSensor VRML97 Helper
  • Hiermee kan een animatie worden gestart wanneer de gebruiker in een bepaalde regio komt.
• TouchSensor VRML97 Helper
  • Hiermee kan er door het aanklikken van een object een animatie worden gestart.
• TimeSensor VRML97 Helper
  • Voor het aansturen en timen van animaties.
• Sound VRML97 Helper
  • Met deze ‘helper’ kan er ruimtelijk geluid worden toegevoegd aan een scène.
• AudioClip VRML97 Helper
  • Hier wordt het geluid gedefinieerd dat gebruikt moet worden door de Sound Helper.
• Anchor VRML97 Helper
  • Hiermee kunnen links worden gemaakt tussen objecten, of naar andere scènes.

3ds Max heeft een ook een speciale exporteerfunctie voor VRML bestanden. Hier kan nog een aantal instellingen worden meegegeven aan het bestand. Het grootste deel van deze instellingen heeft voor dit project echter geen toegevoegde waarde.

Figuur 4155: ARdu-test-snake dient uiteraard weer voor het testen van de exporteerfunctie! Rechtsboven de geëxporteerde versie als AR-model in Unifeye Design.

Nu het duidelijk is op welke manier we in 3ds Max VRML objecten kunnen maken voor gebruik in Unifeye Design, is het bijna tijd om te beginnen met het ontwikkelen van prototypes. We moeten echter eerst nog meer concreet kijken naar de rol van het geschiedenis ‘demonstratie thema’ in deze context.

5.1 HET MIDDELEEUWS DOMEINSTELSEL ALS THEMA

In het eerste oriënterende gesprek met de geschiedenisdocent, is er gesproken over de opbouw van de lessen en mogelijk interessante aspecten om uit te werken voor dit project (zie bijlage 1). Een kenmerkende uitspraak was “Als docent wil je het besproken object in de klas halen!” (zie bijlage 1 r36). Dit is precies wat we met de Toolkit willen doen. Maar wat gaan we dan precies in de klas halen in dit geval? In de gesprekken kwam het ‘middeleeuws domeinstelsel’ aan bod: “Een manier waarmee een middeleeuws domeinstelsel inzichtelijk kan worden gemaakt zou bijvoorbeeld interessant kunnen zijn. Waar staan bepaalde gebouwen? Waarom? etc.” (Bijlage 1 r46). Dit middeleeuws domeinstelsel lijkt na een kort vooronderzoek perspectief te bieden als demonstratie thema voor de Toolkit in dit project. Hierna onderzoeken we dit fenomeen verder.

5.1.1 WAT IS HET MIDDELEEUWS DOMEINSTELSEL?

Voordat er gestart kan worden met het ontwikkelen van onderdelen van de Toolkit met ‘middeleeuws domeinstelsel thema’, is het belangrijk om te weten wat dit fenomeen toen ter tijd inhield. Daarom bekijken we hier enkele omschrijvingen.

Volgens Buskop et al. (2004) is het middeleeuws domeinstelsel het volgende:

“Een domein was een dorp met omgeving. Het was eigendom van een edelman, een bisschop of een klooster. Een domein omvatte akkers, weilanden, bos, een molen, een dorp, het versterkte huis of kasteel van de heer of een klooster. Bijna altijd stroomde er een riviertje door het domein. Het riviertje had men nodig voor het water en vis. Het rivierwater werd gebruikt om de molen aan te drijven. Het bos verschafte voedsel voor de varkens, wild en hout. Iedere heer bestuurde minstens een domein”.

Dan ook nog een iets meer uitgebreide omschrijving, welke ingaat op de situatie rondom het domeinstelsel:

“De economie van de Vroege Middeleeuwen dreef vrijwel geheel op het boerenbedrijf. Handel en verkeer waren nog weinig ontwikkeld, zodat men was aangewezen op zelfvoorziening in de levensbehoeften van alledag. Niet alleen voedsel, ook kleding, schoeisel en allerlei gebruiksvoorwerpen moesten bij voorkeur in eigen beheer geproduceerd worden. Daarnaast moest men van een aantal producten voldoende overschot boven de eigen behoeften genereren, om door ruilhandel aan goederen te komen die men niet zelf voortbracht. Om in hoge mate zelfvoorzienend te zijn, moest het leven te lande georganiseerd zijn in eenheden van behoorlijke omvang. De hof van de grootgrondbezitter vormde dan ook de basiseenheid van het agrarisch bestel.

Een hof (curia of curtis) had als centrum de hofstede van de heer, de vroonhoeve, bestaande uit een herenwoning met bijgebouwen. Men moet denken aan houten bouwsels, eventueel omringd door een palissade. Een deel van de landerijen werd vanuit de herenhofstede bewerkt (terra dominicata), maar het grootste deel was ter bewerking aan horigen uitgegeven (terra mansionaria). De horige moesten een deel van de opbrengsten van hun land aan de heer afstaan en waren ook tot herendiensten verplicht. De eenheid van uitgifte was de hoeve (mansa of hoba)” ( Koene, Morren & Schweitzer, 2003).

Door deze voorgaande beschrijvingen hebben we nu een beter beeld van de betekenis van het middeleeuws domeinstelsel. Voor het ontwikkelen van prototypes hebben we echter concreter (visueel) referentiemateriaal nodig. Dit vinden we op de website www.geschiedenisklas.nl, in de vorm van een afbeelding met omschrijving (zie Figuur 42). Volgens geschiedenisdocent Bram de Wever vormt deze afbeelding met toelichting een goed uitgangspunt voor het ontwikkelen van een middeleeuws domeinstelsel model.

Figuur 4256: Middeleeuws domeinstelsel.

Deze omschrijvingen en afbeelding geven een voldoende beeld van het middeleeuws domeinstelsel, om dit hierna te gebruiken in de uitwerking van de prototypes.

5.2 AR-TOOLKIT - PROTOTYPE 1

Voor het eerste prototype gaan we een vereenvoudigde versie van een middeleeuws domeinstelsel als Augmented Reality model uitwerken. Daarvoor maken we een scène met alleen de meest belangrijke gebouwen. In overleg met de geschiedenisdocent (zie bijlage 2: r214) zijn dit de volgende:

• Huis van de heer (baas)
• Kerk (geestelijkheid)
• Huisjes (gewone mens/arbeiders)

Naast deze gebouwen worden er ook enkele andere zaken zoals bomen en kleine animaties aan de scène toegevoegd om het geheel interessanter te maken. Hierna gaan de benodigde modellen ontwikkelen.

5.2.1 HET MAKEN VAN OBJECTEN VOOR HET PROTOTYPE

De hiervoor genoemde modellen moeten in 3ds Max worden gemodelleerd en voorzien van textures. Belangrijk aandachtspunt hierbij is dat de modellen niet te gedetailleerd (‘low poly’57) zijn, aangezien dit een positieve invloed heeft op de ‘performance’ van de Augmented Reality. Hierna een overzicht van de ‘concept art’:

Kerk concept art

Model van de middeleeuwse kerk (de geestelijkheid).

Figuur 43: Kerk vooraanzicht

Figuur 44: Kerk achteraanzicht boven

Figuur 45: Kerk model in de viewport van 3ds Max.

Huisje concept art

Model van een middeleeuws huis. Hierin woonden de arbeiders. Dit model wordt voor nu ook gebruikt als huis van de heer (enkel met iets grotere afmetingen).

Figuur 46: Huis schuin vooraanzicht.

Figuur 47: Huis schuin achteraanzicht.

Figuur 48: Huis model in de viewport van 3ds Max.

Terrein

Model voor de ondergrond van de scène.

Figuur 49: Terrein model als ondergrond voor het dorp.

5.2.2 HET SAMENVOEGEN VAN DE OBJECTEN TOT ÉÉN SCÈNE

Door de gemaakte modellen nu op een slimme manier samen te voegen ontstaat er het beeld van een middeleeuws dorp (domeinstelsel). Hieronder een hoge kwaliteit ‘testrender’. Wanneer de scène als Augmented Reality verschijnt, zal de belichting minder realistisch zijn aangezien VRML geen schaduwen ondersteunt. Schaduwen zijn via een omweg (‘faken’) wel mogelijk, maar daar gaan we ons voor dit project niet in verdiepen.

Figuur 50: Hoge kwaliteit testrender met realistische belichting.

Figuur 51: Belichting in Augmented Reality, ietwat minder realistisch door ontbreken schaduwen.

Om de scène verder aan te kleden zijn er nog verschillende objecten en animaties toegevoegd. Daarnaast bevat de scène ook natuurgeluiden (met behulp van de Sound & AudioClip VRML97 Helper, zie §5.2.2). De animaties en het geluid zijn ook vooral bedoeld om de werking hiervan te testen wanneer het geheel verschijnt in Augmented Reality vorm. Dit gaan we nu realiseren.

5.2.3 PROTOTYPE 1 ALS AUGMENTED REALITY

Nu het domeinstelsel model klaar is kan het worden ingeladen in Unifeye Design, om de Augmented Reality versie tot leven te wekken. Hiervoor kennen we het model toe aan één marker (Figuur 52). Wanneer we nu de marker voor de webcam houden zien we het domeinstelsel verschijnen (Figuur 53). Door de webcam in de hand te nemen kan er worden ingezoomd op het model (Figuur 54).

Figuur 52: Marker voor het AR domeinstelsel model.

Figuur 53: Het AR domeinstelsel model op de marker.

Figuur 54: Inzoomen op het model met de webcam.

Bij de eerste test verlopen de animaties van de vogels en de kar enigszins ‘schokkerig’, maar door te experimenteren met de (animatie-)exporteerinstellingen in 3ds Max kan dit worden verholpen. We zien de vogels en de kar nu soepel door de scène bewegen. Daarnaast is ook het natuurgeluid te horen wanneer het model van dichtbij wordt bekeken. Het geluid is ‘ruimtelijk’ zoals eerder geschreven en dit houdt in dat het geluid harder wordt wanneer de gebruiker dichter bij de ‘bron’ komt. Dit principe kan leerlingen motiveren om objecten in een scène beter te onderzoeken, aangezien het geluid pas hoorbaar kan worden wanneer iets van heel dichtbij bekeken wordt.

Het eerste prototype is hiermee gerealiseerd, maar het mag duidelijk zijn dat er nog verdere uitwerking en verbetering nodig is. Voor geschiedenisdocent Bram de Wever heeft het nu echter al een meerwaarde en hij reageert dan ook enthousiast op het prototype. Hij geeft aan dat hij onder de indruk is van de mogelijk praktische toepasbaarheid in zijn lessen.

De mening van onderwijskundige Tanja van Kempen is wat meer kritisch na het zien van een filmpje van het prototype. “Wat is nu de meerwaarde hiervan t.o.v. een filmpje, eigen geknutseld dorpje of 2D plaatje? Dit is mij nog niet helemaal duidelijk. AR wordt meestal ingezet om tijd en plaats aan elkaar te kunnen koppelen. Je zou dan bijvoorbeeld rond kunnen lopen in je dorp en als je dan je telefoon voor een gebouw houdt dan zie je hoe het er vroeger uitzag.”

Een aantal van deze opmerkingen vormt zeker een aandachtspunt. We hebben echter eerder geschreven (zie Inleiding: ‘Beperkingen’) dat we bij dit project niet geïnteresseerd zijn in het ‘tijd & plaats aspect’ in combinatie met Augmented Reality. Door de grote populariteit van AR-browsers zoals Layar (§2.3.2) kan het echter zo zijn dat mensen het ‘plaats & tijd aspect’ als essentieel onderdeel van een Augmented Reality concept zien, terwijl het dat niet is. We zijn ons er van bewust dat het prototype nog veel verbeterpunten heeft, maar als reactie op de kritiek van de onderwijskundige formuleren we toch een aantal tegenargumenten. Wat is nu de meerwaarde hiervan t.o.v. een filmpje, eigen geknutseld dorpje of 2D plaatje?:

• Het model is real-time te bekijken, de gebruiker kan dus zelf het perspectief bepalen en specifieke details uitlichten. De gebruiker heeft daarmee zelf de regie in handen, in tegenstelling tot bij een plaatje of film.
• Het prototype zou kunnen worden uitgebreid met meer animaties (invloed tijd, invloed jaargetijde, mensen die op het land werken, etc.), die de gebruiker eventueel zelf kan activeren.
• Door de Augmented Reality vorm lijkt het ‘tastbaar’ te worden: het kan worden bewogen, opgepakt, etc.

Wanneer het doel van het concept wordt toegelicht - ‘het besproken onderwerp in de klas halen’ - en de hiervoor beschreven argumenten worden genoemd, is Van Kempen van mening dat het op deze manier inderdaad een meerwaarde kan zijn. Daarnaast doet zij nog een andere uitspraak van meer praktische aard:

“Het lijkt mij ook lastig om hier in een groepje mee te werken; dat vierkantje moet natuurlijk altijd in het zicht van de camera zijn.”

Dit is juist, de marker moet altijd in het zicht van de camera zijn, anders zal het AR-model niet zichtbaar zijn. Er zijn voor dit probleem echter wel oplossingen, in de vorm van het gebruik van meerdere markers voor één model, oftewel een ‘marker composite’. De mogelijkheden van deze ‘marker composite’ bekijken we op het einde van deze paragraaf. Verder is het probleem wellicht minder groot wanneer leerlingen tijdens groepswerk allemaal een eigen handheld (zie §3.1) zouden gebruiken. Ze kunnen dan immers zelf hun perspectief bepalen en ervoor zorgen dat de marker in beeld blijft.

Als we kijken naar dit prototype en het ‘pedagogisch model van verkennend en onderzoekend leren in kleine groepen’ (§1.3), kunnen we stellen dat dit zeker nog geen ideale uitwerking is. Toch kunnen we al een opdracht voorstellen met dit prototype, waarbij de ‘verkennende’ en ‘onderzoekende’ aspecten terugkomen. Dit zou als volgt kunnen gaan:

5.2.4 HET PROTOTYPE IN EEN LESSITUATIE

Hier beschrijven we een mogelijke lessituatie, waarin het prototype gebruikt zou kunnen worden.

1. Aan het begin van de les introduceert de docent het onderwerp middeleeuws domeinstelsel. 

- Hij illustreert zijn verhaal aan de hand van het prototype (zie Figuur 52, Figuur 53 & Figuur 54).

2. Na de inleiding krijgen de leerlingen zelf het AR-model en kunnen dit ‘verkennen’.

3. De docent kan nu opdrachten geven bij het AR-domeinstelsel, waardoor het ‘onderzoekende’ aspect een rol gaat spelen. De opdrachten zouden in dit geval gebaseerd zijn op visueel waarneembare zaken, aangezien er voor de rest nog geen interactie mogelijk is. Mogelijke opdrachten zouden kunnen zijn:

- “Welke bouwstijl heeft de kerk en welke tijd hoort hierbij?”

- “Waarom staat een gebouw pal naast de rivier?”

- “Wat kun je afleiden uit…..”

4. Nadat de tijd voor de opdrachten is verstreken kan er terugkoppeling plaatsvinden: Welke antwoorden hebben de leerlingen gevonden? Waar? Waarom?

Merk op dat we hier ook de fases van de ‘5E leercyclus’ (§1.4) terugzien. De inleiding is de ‘engagement’ fase, het moment waarop de leerlingen zelf met het model gaan werken is de ‘exploration’ fase, als de leerlingen oplossingen gaan zoeken voor de vragen is dit de ‘explanation’ fase en ten slotte kan de docent in de ‘elaboration’ fase aanvullende informatie en opdrachten geven. De ‘evaluation’ kan aan het einde van de les plaatsvinden, maar ook tussendoor wanneer de docent ondersteuning geeft bij de opdrachten.

Om aan te geven dat dit soort opdrachten erg geschikt zijn voor de geschiedenisles, verwijzen we naar het geschiedenis leerboek ‘Sprekend Verleden HAVO/VWO 1’ (Buskop et al. (2004). Hierin vinden we een opdracht waar leerlingen een gedetailleerde tekening van een middeleeuwse stad (zie Figuur 55) moeten onderzoeken, om zo vragen te beantwoorden. Het prototype kan gezien worden als dezelfde opdracht, maar dan meer aansluitend bij de principes van het ‘nieuwe leren’. Leerlingen zien immers niet meer enkel een plat plaatje in een boek, maar een ‘live’ middeleeuwse scène welke zij individueel of in groepsvorm kunnen onderzoeken.

 

 

 

 

 

Figuur 5559: Opdracht uit het geschiedenisboek Sprekend Verleden.

Enkele vragen die in het geschiedenisboek ‘Sprekend leren’ bij de afbeelding-opdracht (Figuur 55) worden gesteld zijn:

• “Kijk naar de rivier die door de stad stroomt. Als je goed kijkt dan kun je minstens acht manieren vinden waardoor mensen de rivier vervuilen.”
• “Welke sporen van een gelaagde samenleving zie je?”
• “Overal komt rook uit schoorstenen. Waarom stookten de mensen in die huizen?”

We durven te stellen dat deze vragen meer diepgang krijgen en leuker worden voor de leerlingen wanneer deze worden gemaakt in combinatie met het prototype (zie o.a. Figuur 53). Als het prototype verder wordt uitgewerkt zien we hierin ook zeker alle punten van het ‘nieuwe leren’ volgens Martens terug (zie §1.3). De leerlingen krijgen door het ‘live’ AR-model inzicht in de werking en onderdelen van het domeinstelsel (punt 1). De nieuwsgierigheid en drang tot exploreren worden gestimuleerd doordat de ‘simulatie’(=prototype) veel detail heeft zoals objecten, geluiden en animaties (punt 2). Verder kunnen leerlingen zelf bepalen op welke manier ze van het prototype willen leren, en er kan worden samengewerkt bij het zoeken van antwoorden (punt 3 & 4).

Zoals eerder geschreven bekijken we als afsluiting van dit deel de mogelijkheden van de ‘marker composite’, omdat dit het geheel meer gebruiksvriendelijk zou kunnen maken.

5.2.5 ‘MARKER COMPOSITE’

‘Marker composite’ is de benaming die Unifeye Design gebruikt voor het principe waarbij meerdere markers voor één AR-model worden gebruikt. Het voordeel hiervan is dat het AR-model zichtbaar blijft zolang één van markers in de ‘composite’ voor de webcamera zichtbaar is. Daarmee wordt het concept in theorie meer gebruiksvriendelijk. Bij de ‘marker composite’ is er één coördinatenstelsel (zie §2.4.1) voor alle gebruikte markers. We gaan nu zelf een ‘marker composite’ maken met 4 markers (zie Figuur 57). Hiervoor nemen we de markers en plaatsen we deze op vaste posities naast elkaar. In Unifeye Design geven we nu aan wat de positie van elke marker is ten opzichte van het coördinatenstelsel, bij de COS Offset instellingen (Figuur 56). Op deze manier weet de software waar een model weergegeven moet worden, ook wanneer sommige markers niet zichtbaar zijn.

Figuur 5660: COS Offset instellingen.

Op Figuur 57 zien we linksboven de ‘marker composite’ met daarop het virtuele coördinatenstelsel. Rechtsboven wordt het AR-model op de ‘marker composite’ weergegeven. Links- en rechtsonder dekken we enkele markers uit de ‘composite’ af en zien dat het AR-model nog steeds wordt weergegeven.

Figuur 57: Opstelling van een 'marker composite' met 4 markers. Linksboven is het coördinatenstelsel zichtbaar en links- en rechtsonder worden markers uit de ‘composite ’afgedekt, terwijl het AR-model steeds zichtbaar blijft.

De ‘marker composite’ is een interessante mogelijkheid om praktische problemen bij het werken met de AR-objecten op te lossen. De werking wordt minder gevoelig, aangezien een AR-model zichtbaar blijft zolang er ten minste één marker uit de ‘marker composite’ zichtbaar is. Een nadeel is dat het AR-model bij dit experiment wel ‘schokkerig’ was, maar dat is waarschijnlijk op te lossen door de instellingen te verfijnen.

Voordat we verdergaan met het ontwikkelen van een volgende prototype, kijken we eerst of er nog meer mogelijkheden (inhouden) zijn te bedenken voor de Toolkit. Dit doen we onder andere door enkele scenario’s te bedenken en overleg met de geschiedenisdocent.

Lees Hoofdstuk V: Ontwikkelen van de AR-Toolkit Deel 2