Masterproef Tunnel Simulator

Masterproef Tunnel Simulator

Studiegebied Industriële wetenschappen en technologie Opleiding Master in de industriële wetenschappen: Elektronica-ICT Afstudeerrichting Multimedia en informatietechnologie Academiejaar 2009-2010

Kristof Hennebel

Howest – departement Academische bachelor- en Masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

Masterproef Tunnel Simulator

Studiegebied Industriële wetenschappen en technologie Opleiding Master in de industriële wetenschappen: Elektronica-ICT Afstudeerrichting Multimedia en informatietechnologie Academiejaar 2009-2010

Kristof Hennebel

Howest – departement Academische bachelor- en Masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

Woord vooraf De masterproef rond de tunnelsimulator was voor Karel, Frédérique en ikzelf een grote uitdaging. Wij hadden weinig tot geen praktische ervaring of voorkennis rond 3D modeling en 3Dsimulaties. Toch besloten we om de uitdaging aan te gaan. Ikzelf heb de keuze gemaakt uit interesse voor 3D graphics, video, multimedia en softwareontwikkeling in het algemeen. De masterproef sluit ook mooi aan bij de afstudeerrichting MIT. De keuze voor deze thesis hield in dat er een groot deel zelfstudie en initiatief vereist was. Doorheen de opleiding als ingenieur heb ik geleerd om zowel zelfstandig als in groep te werken, en steeds een kritische houding aan te nemen ten opzichte van nieuwe informatie. Gecombineerd met een gezonde portie inzet en nieuwsgierigheid op vlak van multimedia zou dit voldoende moeten zijn om de masterproef mee uit te voeren. Graag wil ik bij deze ook enkele mensen bedanken. Ten eerste onze interne promotor, prof. ir. Filip De Pauw. De lessen in vakken zoals softwareontwikkeling, multimedia en computer graphics geven een goede basis om de masterproef mee te beginnen. En dankzij zijn toestemming werd het computerlokaal in het PIH tijdens de weekends omgetoverd tot een render farm. Ten tweede wil ik ir. Mike Slembrouck bedanken, onze externe promotor die ons werk van dichtbij heeft opgevolgd. Waar nodig hielp hij en stuurde hij het werk bij tijdens het jaar. Ten slotte wens ik vrienden en familie te bedanken voor hun niet aflatende steun door het jaar heen. Kristof Hennebel

I

Abstract De ontwikkelde applicatie genereert een videobestand dat een fotorealistische simulatie weergeeft van tunnelverkeer. Traficon gebruikt dit videobestand om zowel nieuwe als bestaande detectiealgoritmes op uit te testen. De vraag naar dergelijke simulatievideo’s komt er door een tekort aan echte beelden van bijvoorbeeld botsingen of files in tunnels. Omtrent verkeersveiligheid is een zeer hoge detectiegraad vereist. Het is dus belangrijk dat de algoritmes grondig getest worden. Aan de hand van de detectieresultaten van de gegenereerde beelden kan ook aan de klant getoond worden dat de detectie in zijn tunnel zal werken. De gebruiker kan via een grafische gebruikersinterface alle parameters omtrent het gewenste verkeer en de vorm van de tunnel instellen. Op basis van deze parameters wordt op de achtergrond een tunnelscene opgebouwd in het 3D modelleerpakket Blender. Hierbij wordt ook een animatie opgesteld die een verkeersstroom simuleert. Elke wagen krijgt op voorhand een snelheidsbeschrijving die zijn gedrag zal bepalen tijdens de animatie. Op deze manier kunnen verkeersevents die voldoen aan de eisen van de gebruiker gegenereerd worden. Ten slotte kan deze animatie gerenderd worden op een instelbare kwaliteit, resulterend in een videobestand. Het filmpje geeft een fotorealistisch en waarheidsgetrouw beeld weer dat geschikt is om detectie op te doen.

The developed application generates a video file containing a photorealistic simulation of traffic in a tunnel. Traficon then uses this video file to test its detection algorithms on. The lack of existing video material featuring real crashes or traffic jams in a tunnel environment causes the need for such simulation videos. The highest detection rate is required concerning traffic safety. This makes it important to test the algorithms thoroughly. Traficon can also show its customers that the detection in a specific tunnel is working correctly, based on the detection results from the generated video file. The user is able to set all parameters in the application’s graphical user interface to shape a tunnel and define a traffic situation. Based on these parameters, 3D modeling software Blender builds up a scene in the background. At the same time, an animation is being created featuring a traffic flow. Each car gets a speed description in advance. This description will determine the car’s behaviour during the animation. This way, traffic events which satisfy the user’s wishes can be generated. Finally, the animation can be rendered at a chosen quality, resulting in a video file. This gives the user a photorealistic and accurate image, suitable for video detection.

II

Inhoudsopgave Woord vooraf ...................................................................................................................................... I Abstract .............................................................................................................................................. II Gebruikte symbolen en afkortingen .................................................................................................. V Lijst van formules .............................................................................................................................. VI Lijst van tabellen .............................................................................................................................. VII Lijst van figuren ............................................................................................................................... VIII Lijst van codevoorbeelden ................................................................................................................. X 1.

Inleiding ...................................................................................................................................... 1

2.

Literatuurstudie.......................................................................................................................... 6

3.

2.1

Bestaande verkeerssimulaties............................................................................................ 6

2.2

Geschikte 3D-applicaties .................................................................................................. 10

2.2.1

Raytracing via PovRay .............................................................................................. 10

2.2.2

Valve Hammer Editor ............................................................................................... 14

2.2.3

OGRE Engine ............................................................................................................. 17

2.2.4

3D Studio Max .......................................................................................................... 19

2.2.5

Blender ..................................................................................................................... 23

2.2.6

Samenvatting bestaande technieken ....................................................................... 26

Implementatie van de verkeersmodule ................................................................................... 27 3.1

Doelstellingen................................................................................................................... 27

3.2

Werkwijze ......................................................................................................................... 28

3.2.1

Versiecontrole .......................................................................................................... 28

3.2.2

Scrum........................................................................................................................ 30

3.3

Normaal verkeer............................................................................................................... 31

3.3.1

Snelheid per rijvak .................................................................................................... 31

3.3.2

Het debiet ................................................................................................................. 38

3.3.3

Kans op klasse van voertuig ..................................................................................... 39

3.3.4

Uni- of bidirectioneel verkeer .................................................................................. 40

3.4

Stops ................................................................................................................................. 42

3.4.1

Positie ....................................................................................................................... 43

3.4.2

Rijvak van het event ................................................................................................. 44

3.4.3

Start van het event ................................................................................................... 45

3.4.4

Einde van het event.................................................................................................. 45

3.4.5

Afstand tussen stopauto’s ........................................................................................ 45

3.4.6

Aantal stoppende auto’s .......................................................................................... 46

3.4.7

Extra’s ....................................................................................................................... 47

3.5

Files................................................................................................................................... 50

III

3.5.1

Positie ....................................................................................................................... 51

3.5.2

Rijvak ........................................................................................................................ 51

3.5.3

Start en einde van het event .................................................................................... 51

3.5.4

Snelheid van de filerijdende wagens........................................................................ 52

3.5.5

Onderlinge afstand tussen filewagens ..................................................................... 52

3.5.6

Aantal deelnemende wagens ................................................................................... 53

3.5.7

Extra’s ....................................................................................................................... 53

3.5.8

Bijkomend probleem ................................................................................................ 53

3.6

Vallend Object .................................................................................................................. 57

3.6.1

Vallende animatie .................................................................................................... 58

3.6.2

Instellen van het rijvak ............................................................................................. 60

3.6.3

Tijdstip waarop het event gebeurt ........................................................................... 60

3.6.4

Positie waar het event plaatsvindt ........................................................................... 60

3.6.5

Aantal wagens die stoppen ...................................................................................... 61

3.6.6

Doos moet uit een wagen vallen .............................................................................. 63

3.7

Spookrijders...................................................................................................................... 64

3.7.1

Aanvang van het event ............................................................................................. 64

3.7.2

Rijvak waarop het event plaatsvindt ........................................................................ 65

3.7.3

Extra’s ....................................................................................................................... 65

4.

Maken van een realtime 3D preview ....................................................................................... 66

5.

Opstellen van de render farm .................................................................................................. 69

6.

Validatie.................................................................................................................................... 72

7.

Conclusies ................................................................................................................................. 75

8.

Literatuurlijst ............................................................................................................................ 78

9.

Bijlagen ..................................................................................................................................... 80

IV

Gebruikte afkortingen API: Application Programming Interface CEO: Chief Executive Officer CGI: Computer Generated Images CPU: Central Processing Unit FPS: Frames Per Second GPU: Graphical Processing Unit GUI: Graphical User Interface HDR: High Dynamic Range IDE: Integrated Development Environment KMO: Kleine of Middelgrote Onderneming MIT: Multimedia en Informatie Technologie OVF: ObjectVideo File RAM: Random Access Memory SDK: Software Development Kit SPE: Stani’s Python Editor SDL: Scene Descripting Language XML: Extensible Markup Language

V

Lijst van formules Formule 3-1: Intervalberekening op basis van gewenste snelheid................................................. 33 Formule 3-2: Snelheid instellen per rijvak ...................................................................................... 35 Formule 3-3: Berekening van de werkelijke baanlengte bij een tunnel met een bocht .................. 37 Formule 3-4: Tussenafstand omzetten naar aantal frames ............................................................ 39 Formule 3-5: Omrekenen van de stoppositie .................................................................................. 43 Formule 3-6: Berekening van de stoppositie voor de volgende wagen........................................... 46 Formule 3-7: Nodig bij het instellen van de onderlinge afstand tussen filewagens ........................ 52 Formule 3-8: Berekening van tijdsvertraging om snelheid in te stellen .......................................... 56 Formule 3-9: Uitgewerkt voorbeeld van berekening van tijdsvertraging ........................................ 56 Formule 3-10: De bewegingsvergelijking van een vallend object.................................................... 59 Formule 3-11: Omrekenen van de positie ....................................................................................... 61

VI

Lijst van tabellen Tabel 1-1: De taakverdeling ............................................................................................................... 3 Tabel 1-2: De promotoren.................................................................................................................. 3 Tabel 1-3: De input van de masterproef ............................................................................................ 4 Tabel 1-4: De gegenereerde output van de masterproef .................................................................. 4 Tabel 1-5: De KPI van de masterproef................................................................................................ 5 Tabel 1-6: De beperkingen van het project........................................................................................ 5 Tabel 2-1: Onderzochte mogelijkheden ........................................................................................... 10 Tabel 2-2: Voor- en nadelen van raytracing ..................................................................................... 13 Tabel 2-3: Voor- en nadelen van de Hammer Editor ....................................................................... 16 Tabel 2-4: Voor- en nadelen van de OGRE Engine ........................................................................... 18 Tabel 2-5: Voor- en nadelen van 3D Studio Max ............................................................................. 22 Tabel 2-6: Voor- en nadelen van Blender ........................................................................................ 25 Tabel 2-7: Resultaten van het voorafgaand onderzoek ................................................................... 26 Tabel 3-1: De verkeersvereisten ...................................................................................................... 27 Tabel 3-2: Parameters bij normaal verkeer...................................................................................... 31 Tabel 3-3: Parameters bij het stopevent.......................................................................................... 42 Tabel 3-4: Parameters bij het file-event........................................................................................... 50 Tabel 3-5: Parameters bij een vallend object................................................................................... 57 Tabel 3-6: De parameters bij een spookrijderevent ........................................................................ 64

VII

Lijst van figuren Figuur 1-1: Detectieresultaten ........................................................................................................... 1 Figuur 1-2: Architectuur van de volledige masterproef ..................................................................... 2 Figuur 2-1: Het running lines principe bij een verkeerssimulatie ...................................................... 6 Figuur 2-2: Een bestaande verkeerssimulatie in 3D........................................................................... 7 Figuur 2-3: Overzicht van de types voertuigen. ................................................................................. 7 Figuren 2-4 en 2-5: Een voorbeeld van een verkeerssimulatie door TranSystems ........................... 8 Figuur 2-6: Een verkeerssimulatie in AIMSUN ................................................................................... 9 Figuur 2-7: Werking raytracing......................................................................................................... 10 Figuren 2-8 en 2-9: Raytracing voorbeelden .................................................................................... 11 Figuur 2-10 Snelheidswinst op de GPU voor diverse toepassingen ................................................. 11 Figuur 2-11: Een scene in PovRay .................................................................................................... 12 Figuren 2-12 en 2-13: Bestaande verkeerssimulatie in PovRay 3.6 ................................................. 13 Figuur 2-14: Een scene onder verschillende soorten HDR-belichting ............................................. 14 Figuur 2-15: Spiegelende en diffuse reflecties in de Source engine ................................................ 15 Figuur 2-16: Automodel in de Hammer Editor ..................................................................................... 15 Figuur 2-17: De Hammer Editor GUI.................................................................................................... 16 Figuren 2-18 en 2-19: MotorM4x ..................................................................................................... 17 Figuur 2-20: Verkeerssituatie in OGRE Engine ................................................................................. 18 Figuren 2-21 en 2-22: 3D Studio Max showcases ............................................................................ 19 Figuur 2-23: Tunnelontwerp in 3D Studio Max, door Parsons Brinckerhoff .................................... 20 Figuur 2-24: Script Editor in 3D Studio Max ..................................................................................... 21 Figuur 2-25: Tunnel Run in Blender.................................................................................................. 23 Figuur 2-26: Script editor in Blender ................................................................................................ 24 Figuur 2-27: API voor communicatie tussen Blender en Python ..................................................... 25 Figuur 3-1 Het branching principe bij versiecontrolesystemen ....................................................... 28 Figuur 3-2: Het copy-modify-merge principe bij een versiebeheersysteem ................................... 29 Figuur 3-3: Voorkomen van inconsistente data bij een versiecontrole ........................................... 29 Figuur 3-4: De werkcyclus bij Scrum ................................................................................................ 30 Figuur 3-5: De mogelijke statussen van een taak bij Scrum ................................................................... 30 Figuur 3-6: De onderdelen van een animatie in Blender ................................................................. 32 Figuur 3-7: De snelheidsbeschrijving van een wagen ...................................................................... 32 Figuur 3-8: Een Béziercurve in Blender. ........................................................................................... 33 Figuur 3-9: De layercurve in Blender................................................................................................ 36 Figuur 3-10: Het probleem bij de buitenbocht ................................................................................ 37 Figuren 3-11 en 3-12 : Resultaat van de methode gauss(). ............................................................. 38 Figuur 3-13: De personenwagens in de bibliotheek ........................................................................ 39

VIII

Figuur 3-14: Enkele grotere voertuigen uit de bibliotheek .............................................................. 40 Figuur 3-15: Een bidirectionele verkeersstroom.............................................................................. 40 Figuur 3-16: Voorbeeld van een pad in Blender .............................................................................. 41 Figuur 3-17: Resultaat van de methode switchDirection() op een pad ........................................... 41 Figuur 3-18: Snelheidsbeschrijving voor een stoppende auto ......................................................... 42 Figuur 3-19: Een tweede snelheidsbeschrijving voor een stoppende auto ..................................... 43 Figuur 3-20: Wagen die aan 50% van het traject stopt.................................................................... 44 Figuur 3-21: De snelheidsbeschrijving bij figuur 3-20 ...................................................................... 44 Figuur 3-22: De layerbeschrijving van de stoplampen ..................................................................... 47 Figuur 3-23: De stoplichten .............................................................................................................. 48 Figuur 3-24: Layercurve van knipperlichten..................................................................................... 48 Figuur 3-25: De snelheidscurve van een filewagen.......................................................................... 51 Figuur 3-26: Andere snelheidscurve van een filewagen .................................................................. 52 Figuren 3-27 en 3-28: Bijkomend probleem bij aanpassen van lineair stuk in snelheidscurve ....... 53 Figuren 3-29 en 3-30: Uitrekken van de snelheidscurve langs de x-as ............................................ 54 Figuren 3-31 en 3-32: Voorbeelden van tijdscurves ........................................................................ 55 Figuur 3-33: De standaard beginsnelheid bij een snelheidscurve ................................................... 55 Figuur 3-34: Een specifieke tijdsbeschrijving ................................................................................... 56 Figuur 3-35: Vier zelfgemaakte modellen van een kartonnen doos ................................................ 57 Figuur 3-36: Beschrijving van de z-coördinaat bij vallende animatie .............................................. 58 Figuur 3-37: Beschrijving van de y-coördinaat bij vallende animatie .............................................. 58 Figuur 3-38: Beschrijving van de rotatie rond x-as bij vallende animatie ........................................ 58 Figuur 3-39: Assenstelsel van een vallend object ............................................................................ 59 Figuur 3-40: Beschrijving van de z-coördinaat bij vallende animatie .............................................. 59 Figuur 3-41: De procentuele positiebepaling van de doos .............................................................. 60 Figuur 3-42: De snelheidsbeschrijving van een vallend object ........................................................ 61 Figuur 3-43: Eindresultaat van een falling object event. ................................................................. 64 Figuur 3-44: De snelheidsbeschrijving van een spookrijder ............................................................ 65 Figuur 4-1: Beeld uit de realtime 3D preview .................................................................................. 66 Figuur 4-2: Een auto met lampobjecten en een auto zonder .......................................................... 68 Figuur 5-1: De architectuur van een render farm volgens Morisson, G. ......................................... 69 Figuur 5-2: Toevoegen van een netwerklocatie............................................................................... 70 Figuur 5-3: De opgestelde render farm in het PIH ........................................................................... 71 Figuur 5-4: De rendertijden (in minuten) voor 600 frames ............................................................. 71 Figuur 6-1: Een detectietest op gegenereerd beeldmateriaal ......................................................... 72 Figuur 6-2: Gedetecteerde spookrijder in een gegenereerd filmpje ............................................... 73 Figuur 6-3: Valse detectie van een spookrijder................................................................................ 73 Figuur 6-4: Een file wordt met succes gedetecteerd ....................................................................... 74

IX

Lijst van codevoorbeelden Codevoorbeeld 2-1: Een mappable eigenschap............................................................................... 22 Codevoorbeeld 2-2: Een Python voorbeeld ..................................................................................... 23 Codevoorbeeld 3-1: De snelheidscurve manipuleren ...................................................................... 34 Codevoorbeeld 3-2: Een punt van een Béziercurve verplaatsen ..................................................... 34 Codevoorbeeld 3-3: Een volledige Béziercurve verschuiven ........................................................... 35 Codevoorbeeld 3-4: Een object uit de scene verwijderen ............................................................... 36 Codevoorbeeld 3-5: De Gauss-functie in Python ............................................................................. 38 Codevoorbeeld 3-6: De zin van een traject inverteren .................................................................... 41 Codevoorbeeld 3-7: Opletten voor stopevents tijdens het genereren van free flow ..................... 46 Codevoorbeeld 3-8: Maken van een layercurve voor een knipperlicht........................................... 49 Codevoorbeeld 3-9: Toekennen van de layercurve aan een object ................................................ 49 Codevoorbeeld 3-10: Het toevoegen van een extra stopevent ....................................................... 62 Codevoorbeeld 3-11: Instellen van de stopevents via parameters ................................................. 62 Codevoorbeeld 3-12: Oorspronkelijke definiëring van de eventparameters .................................. 62 Codevoorbeeld 3-13: Aanpassen van normale wagen om falling object event te vervolledigen ... 63 Codevoorbeeld 3-14: De zin van een traject inverteren .................................................................. 64 Codevoorbeeld 4-1: Blender opstarten in een kleiner scherm ........................................................ 67 Codevoorbeeld 4-2: Het voorbereiden van een realtime 3D preview ............................................. 67 Codevoorbeeld 5-1: FarmerJoe opstarten in slave of in master modus. ......................................... 70 Codevoorbeeld 5-2: De appserver van FarmerJoe opstarten .......................................................... 71

X

1. Inleiding Situering Deze masterproef wordt uitgevoerd in opdracht van Traficon. De KMO is gevestigd in Wevelgem en heeft een veertigtal werknemers werk in dienst. Reeds tien jaar is het wereldleider op vlak van videodetectie voor verkeerssituaties. Traficon is gestart als pionier in de markt voor videodetectie. Door de verworven kennis, de voortdurende investering in innovatie en de samenwerking mett een Amerikaanse onderzoeksgroep blijft het bedrijf marktleider. marktleider De R&Dafdeling is essentieel voor het bedrijf. In West-Europa, Oost-Europa, Europa, Afrika en Rusland heeft het het grootste deel van de markt in handen, aldus CEO Jo Versavel. Het bedrijf kent een jaarlijkse groei van ongeveer twintig procent. Naar de toekomst toe liggen nieuwe mogelijkheden en uitdagingen in China en India. De overheid is een belangrijke klant voor Traficon. Daardoor is het bedrijf weinig conjunctuurgevoelig. Dit betekent dat men men weinig hinder zal ondervinden van bijvoorbeeld de economische crisis. Voor een tunnelcomplex in Parijs bestelde de Franse overheid duizenden camera’s met een overkoepelend detectiesysteem1. Volgende figuren tonen het resultaat van een succesvolle detectiee in een tunnelomgeving. Op de linker afbeelding heeft het algoritme een stilstaand voertuig gedetecteerd. Op de rechter rechter afbeelding werd een voorwerp op de weg gedetecteerd.

Figuur 1-1:: Detectieresultaten

Probleemstelling Voor het uittesten van zowel oude als nieuwe detectiealgoritmes is er vaak een tekort ort aan geschikt beeldmateriaal. Dit is in het bijzonder het geval voor tunnelverkeer. Er bestaan niet voldoende beelden van bijvoorbeeld een botsing in een tunnel waarop Traficon detectie kan doen. Zodoende kunnen de ontwikkelde algoritmes niet voor alle situaties uitgetest worden. Omtrent verkeersveiligheid is nochtans een uiterst hoge detectiegraad en een snelle reactietijd vereist. Valse detecties moeten absoluut vermeden worden omdat de tunnel dan ten onrechte afgesloten zou kunnen worden. Het algoritme moet dus op voorhand grondig getest worden.

1

Verschillende succesverhalen staan op http://www.traficon.com/references/references.jsp

1

De masterproef moet een oplossing bieden voor het tekort aan bruikbaar beeldmateriaal. Het doel is het ontwikkelen van een applicatie die een videobestand genereert. In dit filmpje wordt een bepaalde verkeerssituatie geschetst, op basis van een aantal gekozen instellingen van de gebruiker. Traficon gebruikt het resultaat om zijn detectiealgoritmes op uit te testen. Wanneer bijvoorbeeld een algoritme geschreven wordt dat stilstaande voertuigen detecteert, kan Traficon de ontwikkelde applicatie gebruiken om allerlei situaties te genereren waarin voertuigen stoppen. Zodoende kan het algoritme op verschillende scenario’s uitgetest worden. De tests zijn absoluut nodig om het algoritme te optimaliseren en zo de hoogst mogelijke detectiegraad te bekomen. Architectuur Het overzicht in figuur 1-2 legt de architectuur van de masterproef vast. De modules van de te ontwikkelen applicatie hebben elk een eigen functie. In de GUI (front end) van de applicatie kan de gebruiker gaan instellen hoe de tunnel en de belichting er moeten uit zien. Er kan ook gespecificeerd worden welke verkeersgebeurtenissen (files, botsingen, spookrijders, … ) er moeten optreden en wanneer. Op basis van al deze instellingen wordt op de achtergrond een scene opgebouwd door de “Scene Generator” en de “Traffic Generator”. De gebruiker krijgt vervolgens een realtime 3D preview te zien van de gecreëerde verkeerssituatie. Indien de gebruiker tevreden is over de gegenereerde scene dan kan het renderen van start gaan. Dit kan enkele tientallen uren in beslag nemen, afhankelijk van de gekozen resolutie en de gewenste kwaliteit. Om het renderproces te versnellen kan een render farm opgesteld worden.

Figuur 1-2: Architectuur van de volledige masterproef

Bij het gerenderde videobestand wordt een ObjectVideo bestand (OVF) meegeleverd waarin alle speciale verkeersevents met het bijhorende tijdstip gedocumenteerd staan. Het bevat alle referentiedata die zijn opgesteld bij het opbouwen van de scene en heeft een XML-structuur. Het OVF-formaat biedt een meerwaarde bij videodetectie; aldus Lipton, A.J. (2004: p.56-60). Op het resulterende beeldmateriaal kan Traficon nu verkeersdetectie gaan doen. Door de resultaten van het detectiealgoritme te vergelijken met het bijgeleverde OVF-bestand kan men gaan meten in hoeverre de detectiealgoritmes correct functioneren.

2

Op elke module van Figuur 1-2 werkt telkens één student. Er is vooraf duidelijk afgesproken wie op welk aspect werkt. Zodoende wordt dubbel werk voorkomen. Tabel 1-1 geeft de taakverdeling weer. Deze verhandeling heeft het hoofdzakelijk over de aanpak rond het genereren van verkeer, namelijk de “traffic generator” module. Verder wordt er ook gesproken over de opstelling van de render farm en hoe de realtime 3D preview tot stand kwam. Enige overlapping met de andere modules is daarbij onvermijdelijk. De overblijvende modules worden besproken in de masterproefteksten van Karel Azou en Frédérique Vanneste. Naast de drie masterproefstudenten werken ook drie promotoren mee aan de masterproef. Tabel 1-2 geeft een overzicht. Tabel 1-1: De taakverdeling

Frédérique Vanneste

Kristof Hennebel

Karel Azou

Scene generator

Traffic generator

OVF generator

Prototype front end

Render farm

Front end

Render farm

3D preview

Autobibliotheek

Tabel 1-2: De promotoren

Naam

Functie

Prof. ir. Filip De Pauw

Interne promotor

Ir. Mike Slembrouck

Externe promotor

Ir. Wouter Favoreel

Externe promotor

Bij het uitvoeren van deze masterproef kwamen volgende onderzoeksvragen aan bod: 1. Hoe kan men virtueel realiteitsgetrouwe verkeerssituaties bouwen? Er bestaan een aantal technieken om deze opdracht mee uit te werken. Zijn er al gelijkaardige projecten uitgevoerd? Welke techniek is er het best geschikt? Wordt er een 3D game engine gebruikt of een modelleerpakket? Hoeveel moet men betalen voor zo’n pakket? Een voorafgaand onderzoek dringt zich op. Door een verkenning te doen van de bestaande mogelijkheden kan een geschikte oplossing gevonden worden die tevens de beste prijs/kwaliteit verhouding heeft. De gegenereerde verkeerssituatie moet een waarheidsgetrouw beeld schetsen. Dit is belangrijk voor de detectiealgoritmes. Enerzijds moet hiervoor aan fotorealisme gedaan worden. De gebruikte automodellen moeten van hoge kwaliteit zijn, alsook moet het belichtingsmodel overeen komen met de realiteit. Er moeten koplampen, stoplampen, knipperlichten, … aanwezig zijn en elk moet een bepaalde mate van reflectie en diffusie creëren. Bepaalde detectiealgoritmes maken bijvoorbeeld gebruik van de reflectie van de koplampen op de muur om een voorbijkomend voertuig te detecteren. Anderzijds moet de gegenereerde stroom aan verkeer vlot en echt overkomen. Optredende events zoals files of stops moeten vloeiend verlopen. Auto’s mogen niet onredelijk bruusk accelereren of remmen. De verkeersstroom mag niet stroef overkomen.

3

2. Hoe kan men de uitvoeringstijd voor de weergave gaan beperken? Bij de keuze van software om de masterproef mee uit te werken moeten een aantal zaken afgewogen worden. De keuze voor een bepaalde techniek zal ook grotendeels de duur van de uitvoeringstijd bepalen. Wanneer gewerkt wordt met een game engine dan is het resultaat er onmiddellijk. Door de masterproef uit te voeren in een gratis, open source applicatie zal het renderproces beduidend langer duren. Wanneer geopteerd wordt om een professioneel modelleerpakket aan te schaffen, dan is de rendertijd veel korter. Elke techniek brengt voor- en nadelen mee die moeten afgewogen worden. Verder is er onderzoek vereist naar externe tools die het renderen kunnen versnellen. Ook interessant is het zoeken naar de optimale renderinstellingen. 3. Kunnen deze vragen opgelost worden met open source software? Er moet afgewogen worden tussen de prijs en de kwaliteit. Indien men opteert om open source software te gebruiken moet er op bepaalde gebieden ingeboet worden. Een voorbeeld daarvan is de rendertijd. Is het eindresultaat ook kwalitatief wel evenwaardig indien gewerkt wordt met open source software? Projectsheet In de bijlage zit een Gantt chart die het jaaroverzicht van de volledige masterproef toont. De taakverdeling van de drie studenten wordt weergegeven over het schooljaar heen. Aangezien de studenten aan de masterproef beginnen zonder veel voorkennis of ervaring in 3D modeling, is een groot stuk zelfstudie en initiatief doorheen het jaar vereist. De masterproef kan enkel tot een goed einde gebracht worden met voldoende inzet, communicatie tussen de drie studenten, een kritische geest en het vermogen om zelfstandig bij te leren. Tabellen 1-3 en 1-4 geven de nodige input en de gecreëerde output van de volledige masterproef weer. Tabel 1-3: De input van de masterproef

Input







Literatuurstudie Kennis, ervaring en raadgeving van de externe en interne promotor Kennis van multimedia, computer graphics en softwareontwikkeling Kennis van C#, Python, XML en Blender Blender Artists Community 3D Modellen (“low polygon”)

Tabel 1-4: De gegenereerde output van de masterproef

Input






Traffic simulator applicatie Videobestand Referentiefile Render farm opstelling Masterproeftekst

4

De kwaliteit van het eindresultaat kan gemeten worden met volgende key performance indicatoren. Tabel 1-5: De KPI van de masterproef

KPI






Benadering fotorealisme Gebruiksvriendelijkheid van de GUI Correlatie tussen video en referentiebestand Waarheidsgetrouwe verkeerssituaties Detectiealgoritmes op uittesten

De beperkingen van het project worden samengevat in volgende tabel. De tijd is gelimiteerd tot één maand stage en een schooljaar. Er is vanuit Traficon in de eerste instantie geen budget voorzien. Het project heeft lagere prioriteit dan de core business van het bedrijf zelf. Concreet betekent dit dat geen dure softwarepakketten kunnen aangekocht worden, dat geen render farm kan gehuurd worden en dat de gebruikte automodellen gratis zullen moeten verkregen worden. Indien het project veelbelovend blijkt tijdens de ontwikkeling kan wel een klein budget voorzien worden. Daarmee kunnen extra’s aan het project toegevoegd worden zoals bijvoorbeeld een uitgebreidere bibliotheek met automodellen. Ten slotte is ook de scope van het project beperkt tot de modules weergegeven in figuur 1-2. Tabel 1-6: De beperkingen van het project

Beperkingen  



Tijd Budget - Software - Infrastructuur render farm Scope

In de bijlage zit nog een overzicht met alle mijlpalen door het jaar heen.

5

2. Literatuurstudie In de voorafgaande literatuurstudie worden enkele bestaande verkeerssimulaties besproken. Er wordt gekeken hoe andere mensen dit aangepakt hebben en wat het belang is van dergelijke simulaties. Daarnaast worden ook een aantal onderzochte technieken besproken.

2.1

Bestaande verkeerssimulaties

Voordat de verkeersgenerator praktisch uitgewerkt werd, is onderzoek gedaan naar bestaande verkeerssimulaties. Dergelijke simulaties worden volgens Pursula, M. (1999, p. 1-8) reeds meer dan veertig jaar gebruikt. Dit gebeurt vaak voordat een nieuwe brug, tunnel of rotonde aangelegd wordt. Aan de hand van virtuele verkeerssituaties kan men het ontwerp optimaliseren zodat er geen opstoppingen, files of andere problemen zouden ontstaan. Voor elke situatie (tunnel, kruispunt,…) wordt vaak een volledig nieuwe simulatie opgebouwd. Het vereist veel tijd en moeite om telkens een scene van scratch te bouwen. Mede door de complexiteit van de voertuigmodellen kan de uitvoeringstijd van de simulaties nog verslechteren. Namekawa, M. (2010) stelt een nieuw soort verkeerssimulatie voor om deze problemen op te lossen. Daarbij heeft elk voertuig een beslissingsmechanisme en een “running line”. Deze lijnen komen overeen met alle rijvakken op de baan waar een wagen mag rijden en zijn noodzakelijk om te voorkomen dat een wagen van het traject zou afwijken. Figuur 2-1 illustreert het “running lines” principe.

Figuur 2-1: Het running lines principe bij een verkeerssimulatie

Op deze manier kan met een stratenplan van de gewenste regio en informatie over de verkeerslichten, een verkeerssimulatie opgebouwd worden. De output van het proces is een 3Danimatie met bijhorende statistieken die de verkeersdrukte beschrijven. Hieruit kan afgeleid worden of het ontwerp voor problemen zal zorgen. Figuur 2-2 geeft een voorbeeld van een bijhorende animatie. De beelden zijn verre van fotorealistisch in dit geval. Dit is niet belangrijk omdat hier enkel statistische data omtrent verkeersdrukte verzameld worden.

6

Figuur 2-2: 2: Een bestaande verkeerssimulatie in 3D

Op deze manier wordt een nieuwe brug, tunnel of rotonde virtueel uitgetest. Zonder simulaties is analytisch onderzoek rzoek naar problemen bij een nieuw ontwerp vaak te gecompliceerd. Om aan verkeersmanagement te doen bij de Lincoln Tunnel onder de Hudson rivier werd ook een verkeerssimulatie gebruikt. Dit wordt beschreven in de paper van Mosseri, G., et al. (2003). Aan de hand van de simulatie kon onder andere uitgerekend worden hoeveel tol men maandelijks kan innen. Telkens een bepaalde wagen door de tunnel wil rijden, moet deze tol betalen afhankelijk van het voertuigtype type.

Figuur 2-3: 3: Overzicht van de voertuigtypes.

7

Daarbij worden vijf klasses voertuigen opgesteld, zoals weergegeven in figuur 2-3. Afhankelijk van de grootte van het voertuig en het aantal inzittenden wordt het tarief bepaald. De simulatie zal ook uitwijzen hoe grote files of opstoppingen bij het innen van de tol voorkomen kunnen worden. Ten slotte volgt een tweede case rond het optimaliseren van logistieke processen. Dronzek, R. (2007) schrijft dat het bedrijf TranSystems zijn succes baseert op verkeerssimulaties. Het bedrijf is actief in meerdere transportsectoren waaronder luchthavens en treinstations. Onderstaande afbeeldingen geven een beeld weer van de O’Hare Western Bypass. Links is de bestaande situatie. Rechts geeft het ontwerp weer voor de nieuwe situatie. Aan de hand van verkeerssimulaties wordt het nieuwe ontwerp virtueel uitgetest en verder geoptimaliseerd. TranSystems gebruikt 3D Studio Max voor het verwezenlijken van de animaties. 3D Studio Max is de industriestandaard op vlak van modelleren en animeren in 3D. Een uitgebreide bespreking van het pakket komt later aan bod.

Figuren 2-4 en 2-5: Een voorbeeld van een verkeerssimulatie door TranSystems

Om specifiek de verkeersstroom te genereren bestaan verschillende softwarepakketten. Jones, S., et al. (2004) vergelijkt een tiental bestaande simulatiepakketten. SimTraffic, CORSIM en AIMSUN komen er als beste uit. Elk pakket heeft zijn beperkingen waardoor afhankelijk van de situatie één oplossing de beste zal zijn. SimTraffic blijkt het gebruiksvriendelijkst. Het neemt weinig tijd in beslag om een simulatie op te stellen. Er is weinig voorkennis vereist. Om een complexere stedelijke situatie voor te stellen is CORSIM beter geschikt. Deze tool houdt bijvoorbeeld ook rekening met de impact van parkerende wagens. Ook botsingen of andere incidenten kunnen gesimuleerd worden. Het nadeel van CORSIM is de grote tijd die nodig is om een dergelijke scene op te bouwen. AIMSUN vereist het meest tijd en moeite vooraleer een scene opgebouwd is. Het is een compleet pakket dat enkel optimaal gebruikt kan worden om een stedelijk of regionaal netwerk te simuleren. Zowel CORSIM als AIMSUN lijken de capaciteit van een netwerk iets te overschatten. In de realiteit passeert het verkeer minder vlot dan voorgesteld door CORSIM of AIMSUN. Jones, S., et al. raadt daarom aan om de simulatie zorgvuldig te kalibreren en te valideren.

8

Figuur 2-6: Een verkeerssimulatie in AIMSUN

Figuur 2-6 geeft een beeld weer uit een simulatie opgebouwd met AIMSUN. De gegenereerde beelden zijn absoluut niet fotorealistisch. Er zijn geen schaduwen of reflecties aanwezig. Dit is ook niet belangrijk omdat er enkel statistische gegevens verzameld worden. De simulatie verloopt wel realtime, aan dertien frames per seconde. De scene is gebaseerd op een 3D engine die voor elk frame nieuwe berekeningen doet om het gedrag van de auto’s te bepalen. Auto’s zijn geprogrammeerd om te vertragen wanneer de bestuurder voor hen vertraagt. Een dergelijk resultaat is niet genoeg voor Traficon. Op deze beelden kan geen videodetectie gedaan worden omdat ze niet voldoende de realiteit benaderen. De automodellen, de texturen en de lichteffecten zijn te simpel. De prijs voor een dergelijk pakket ligt in de grootteorde van enkele duizenden euro’s2. Er is voor de uitwerking van de thesis geen budget voorzien. Er kan dus geen bestaande simulatiesoftware gebruikt worden voor het genereren van het verkeer. Er moet gezocht worden naar software waarin zelf gemodelleerd en geanimeerd kan worden. Vervolgens moet daarin een animatie gegenereerd worden die een verkeersstroom uitbeeldt.

2

Een overzicht van enkele prijzen is te vinden op http://www.trafficware.com/assets/pdfs/pricesheet_061407.pdf

9

2.2

Geschikte 3D-applicaties

Een aantal onderzochte 3D-applicaties worden besproken. Hierbij komt telkens aan bod welke de voor- en nadelen zijn, en of de techniek al dan niet geschikt is om de Traffic Generator mee uit te werken. Tabel 2-1 geeft weer welke bestaande mogelijkheden verkend werden. Dit vooronderzoek vond plaats tijdens de stage in augustus 2009. Daarnaast werd ook onderzoek gedaan naar bestaande problematiek rond tunnelveiligheid. Een algemene situering van de probleemstelling rond verkeersveiligheid in tunnels wordt uitgebreid besproken in de verhandeling van Frédérique Vanneste. Tabel 2-1: Onderzochte mogelijkheden

Kristof Hennebel






2.2.1

Raytracing via PovRay Valve Hammer Editor OGRE Engine 3D Studio Max met MAXScript Blender met Python

Frédérique Vanneste






Raytracing via PovRay CryEngine Autodesk Maya 3D Studio Max Blender

Raytracing via PovRay

Principe Raytracing werd voorgesteld door Traficon als een van de mogelijkheden om de masterproef mee te gaan uitwerken. Hierbij wordt telkens één viewray per pixel vanuit de camera geschoten. Bepaalde rays (stralen) zullen botsen tegen objecten in de scene. Dit stelt voor wat de gebruiker zal zien op de bijhorende pixel. Bij zo’n botsing kunnen hoogstens drie nieuwe stralen ontstaan: schaduw, reflectie of refractie. Figuur 2-7 illustreert de werking. Door op deze manier te werken kan een ongeziene graad van fotorealisme bereikt worden. Refracties van bijvoorbeeld licht in water of glas worden perfect nagebootst.

Figuur 2-7: Werking raytracing

Voordelen Het grootste voordeel van raytracing is de hoge graad van realisme. Afbeeldingen 2-8 en 2-9 illustreren de mogelijkheden. Dit zijn geen foto’s maar beelden gegenereerd via raytracing. Zoals ook verklaard door Qu, H. (2003: p. 202 - 209) zijn de fotorealistische schaduwen, reflecties en refracties de grootste troeven van de techniek.

10

Figuren 2-8 en 2-9: Raytracing voorbeelden

Nadelen Het grootste nadeel van de raytracing techniek is de lage performantie. Complexere beelden vereisen een grote CPU-kracht en veel rekentijd. Per frame kan de rendertijd oplopen van enkele minuten tot enkele uren. Het is voorlopig onmogelijk om een realtime preview te geven via raytracing, net omdat deze techniek enkel de CPU gebruikt. Er zijn initiatieven om raytracing te laten uitvoeren door de GPU. Hierdoor kan mogelijk ook een kortere rendertijd verkregen worden. Deze techniek is echter nog niet geoptimaliseerd. Volgens Christen, M. (2005) is dit omdat de architectuur van de GPU zich niet volledig schikt voor berekeningen van raytracing. In het gastcollege rond de GPU heeft Bart Pieters van Multimedia Lab (UGent) dit verklaard. De GPU bestaat uit vele kleine processorkernen. De gemiddelde grafische kaart heeft een tweehonderdtal cores. De bedoeling is om via de hoge graad van parallellisme realtime meerdere beelden van games te renderen. Er kan voor elke berekening van een pixel een CPU core benut worden. De efficiëntie is maximaal indien de berekeningen voor elke core van gelijke complexiteit zijn. Indien dit niet zo is treedt branching op. Dit is het fenomeen waarbij enkele cores inactief worden doordat andere cores langer bezig zijn met een grotere berekening. Bij raytracing waarbij elke pixelberekening een verschillende complexiteit heeft treedt te vaak branching op. Daardoor schikt de hedendaagse GPU zich niet goed voor raytracing berekeningen en wordt dus nog steeds de CPU gebruikt. Figuur 2-10 geeft de snelheidswinst weer bij diverse toepassingen. De honderden cores van de GPU bieden niet genoeg meerwaarde in het geval van raytracing.

Figuur 2-10: Snelheidswinst op de GPU voor diverse toepassingen

11

Volgend citaat geeft een beeld weer van hoe lang het renderen van een animatiefilm duurt en hoe parallellisme gebruikt wordt in de studio van Pixar.

“During Ratatouille, the render farm consisted of about 850 machines with nearly 3200 processors between them. When rendering the final Ratatouille film frames on a 2.66 GHz processor, each frame took an average of six hours. It took about 1532 CPU-years to render Ratatouille, including the lower-resolution renders done at various points in the pipeline and working iterations. That means that if we only had one CPU in the render farm, Ratatouille wouldn't have been released until the year 3539. To store the images generated while making the movie, we used 12 terabytes of disk space” - Jen Becker, Pixar (2007) Naast de lage performantie heeft PovRay nog een nadeel. Het is te omslachtig voor de gebruiker om een volledige, realistische scene te gaan beschrijven in de SDL. Een complete scene opbouwen (in code) kan enkele weken tot maanden duren. PovRay laat ook niet toe om parameters in te voeren die het de eindgebruiker mogelijk maken om een scene te gaan personaliseren. Dit laatste is een van de voornaamste vereisten van Traficon. Figuur 2-11 geeft een voorbeeld weer van de code die nodig is om een simpele scene voor te stellen.

Figuur 2-11: Een scene in PovRay

12

Hierbij wordt alles in de scene gedefinieerd vanuit code. De lichtinval, de atmosfeer en de camerapositie moeten allemaal manueel ingesteld worden. PovRay geeft geen ondersteunende gebruikersinterface face waarin dergelijke derge instellingen gemakkelijker gekozen kunnen worden. Voorbeeld Tijdens het voorafgaand onderzoek werd PovRay 3.6 en enkele bestaande toepassingen verkend. Een daarvan heet Autobahn en is gemaakt door de Spaanse paanse raytracing expert, Jaime Vives Piqueres.. Autobahn is een simulatie van een verkeersstroom op een autostrade. Figuren 2-12 en 2-13 2 geven een beeld weer uit de applicatie.

Figuren 2-12 en 2-13:: Bestaande verkeerssimulatie verkeers in PovRay 3.6

Om deze verkeerssituatie ituatie op te bouwen zijn enkele duizenden regels code vereist. Het resultaat is fotorealistisch en geeft een waarheidsgetrouw beeld, maar is niet bruikbaar voor de masterproef. Bij de masterproef moet de scene zich immers vormen naar de ingestelde vereisten vereist van de eindgebruiker. Autobahn is slechts één uitgewerkt geval. Om bijvoorbeeld een extra rijvak toe te voegen is veel extra codewerk nodig. Mogelijkheden Raytracing schikt zich goed voor het gebruik van parallellisme omdat elke ray rekenkundig onafhankelijk nafhankelijk is van zijn buren. Op vlak van parallellisme zijn er drie huidige trends. Ten eerste zijn er de multi-core core processoren. Door de berekeningen te verdelen over meerdere CPU-cores zal de totale rekentijd beduidend omlaag gaan. Een tweede mogelijkheid mogelijk is de manycore architectuur. De Intel Larrabee chip is hiervan een voorbeeld. Renderen met de 16-core 16 versie van deze processor is ongeveer tien keer sneller dan GPU rendering, aldus Smelyanskiy, M. (2009: p. 1563 - 1570). Voorlopig ondersteunt enkel de 3.7 beta versie van PovRay multicore rendering. De GPU zelf is een derde hedendaagse techniek op vlak van parallellisme, maar schikt zich niet goed voor raytracing berekeningen zoals reeds aangegeven werd. Het onderzoek rond parallellisme en de bijhorende ende resultaten staan in de paper van Smelyanskiy, M. Besluit PovRay is een goede tool voor fotorealisme maar is niet geschikt om de masterproef mee uit te werken. De huidige gebruikte SDL vereist een hogere graad van abstractie om aan aa de vereisten van Traficon te kunnen voldoen. Tabel 2-2 geeft een overzicht. Tabel 2-2: Voor- en nadelen van raytracing

Voordelen

Nadelen


Gratis
Goede documentatie beschikbaar
Fotorealisme

 SDL is complex en contra-intuïtief contra  CPU-intensief  Ongeschikt voor video animaties animat

13

2.2.2

Valve Hammer Editor

Een tweede onderzochte mogelijkheid is de Hammer Editor van Valve. Deze editor maakt gebruik van de Source engine. Dit is een game engine gemaakt door Valve. Door een game te kopen van Valve krijgt men automatisch deze editor tool er bij. Zodoende kan men zelf levels maken voor de gekochte game. De gemiddelde prijs voor een game van Valve is veertig euro. In vergelijking met professionele modelleerpakketten is dit dus een zeer goedkope oplossing. Voordelen Het grootste voordeel bij game engines in het algemeen is de rendertijd. Game engines zijn in staat om een gebouwde scene realtime in 3D te tonen. Dit betekent dat per seconde minstens vijfentwintig frames gemaakt en getoond worden. Deze snelheid staat in schril contrast tot het renderen bij modelleerpakketten. Hierbij duurt het gemiddeld enkele minuten om één enkel frame te renderen. Games gaan voor het genereren van de frames hoofdzakelijk de GPU gebruiken in plaats van de CPU. Dit resulteert in een veel sneller renderproces. Een hedendaagse GPU bevat gemiddeld 256 tot 1024 MB RAM-geheugen en is speciaal ontworpen om games te ondersteunen. Vanuit de game industrie is er veel geïnvesteerd in de ontwikkeling van de GPU, speciaal ter ondersteuning van games. Nvidia CEO Jen-Hsun Huang (2009) voorspelt dat de komende jaren de performantie van de GPU met een factor 500 zal verhogen. Dit is veel sneller dan de ontwikkeling van de CPU. Een tweede voordeel van game engines zijn de ingebouwde physics zoals schademodellen en botsingsdetectie. Deze physics zijn niet aanwezig in een modelleerpakket zoals Blender of 3D Studio Max. Het doel ervan is om gemakkelijk een game te kunnen ontwikkelen. Bij deze masterproef kunnen de physics goed van pas komen om bijvoorbeeld botsingen tussen auto’s te simuleren. De Source engine bevat ook geavanceerde belichtingsmodellen zoals Lambert diffusie en High Dynamic Range (HDR) belichting. Deze technieken worden besproken in het werk van Mitchell, J., McTaggart, G. en Green, C. (2006). Volgende afbeeldingen illustreren dit.

Figuur 2-14: Een scene onder verschillende soorten HDR-belichting

14

Ook spiegelende (specular specular) en diffuse reflecties zitten ingebouwd in de engine. Figuur 2-15 2 beeldt dit uit. De eerste twee linker afbeeldingen tonen respectievelijk de diffuse en de spiegelende reflecties. Rechts wordt het gecombineerde model getoond.

Figuur 2-15: Spiegelende en diffuse reflecties in de Source engine

Naast de ingebouwde physics en belichtingsmodellen is ook de multi-user user optie een voordeel. Er kunnen en meerdere gebruikers verbinden naar een gecompileerde scene. Dit maakt het mogelijk om, in het level, één persoon te laten rondrijden in een wagen terwijl een andere verbonden gebruiker dit gaat filmen. Deze methode is echter te omslachtig om gebruikt te worden voor de masterproef. De Hammer Editor bevat een uitgebreide bibliotheek met modellen en texturen. Zo zijn er reeds een aantal automodellen of asfalttexturen beschikbaar. De editor is gebruiksvriendelijk en bevat een intuïtieve GUI. Het neemt enkele enkele uren in beslag om als leek een scene op te bouwen in de Hammer Editor. De graphics zijn goed maar nog niet volledig fotorealistisch. Figuur 2-16 toont de mogelijkmogelijk heden. De texturen van het plafond, de vloer en de muren zitten allemaal al ingebouwd in de editor. Ook het automodel zit in de bibliotheek. De spiegelende en de diffuse reflecties reflectie zijn zichtbaar. Figuur 2-16:: Automodel in de Hammer Editor

De GUI is overzichtelijk en vlot gebruikbaar. De icoontjes om te modelleren zijn simpel en duidelijk. Dee gebruiker krijgt vier schermen te zien. Links bovenaan een ee 3D-zicht zicht, gevolgd door een standaard bovenaanzicht, zijaanzicht en vooraanzicht. Er zijn goede tutorials op het web beschikbaar waardoor de doorsnee gebruiker gemakkelijk een scene kan opbouwen.

15

Figuur 2-17: De Hammer Editor GUI

Nadelen De Source Engine heeft ook enkele nadelen waardoor hij niet meer geschikt is om de masterproef mee uit te werken. Ten eerste is er geen API voorzien voor Visual Studio. Dit maakt de communicatie tussen een front end (in VB.NET of C#) en de engine onmogelijk. Ten tweede is er geen ingebouwde mogelijkheid om videomateriaal van een scene te genereren. Het blijft een game engine, die zich in de eerste plaats richt tot games. Ten slotte is de resulterende scene niet parametriseerbaar. Om een extra rijvak toe te voegen aan een bestaande scene moet de Hammer Editor opgestart worden en de scene manueel veranderd worden. Dit gaat sneller dan bij PovRay het geval was maar gaat nog altijd niet automatisch. Het uiteindelijk doel is immers om een applicatie te maken die automatisch een scene bouwt die volledig voldoet aan de wensen van de gebruiker. Tabel 2-3: Voor- en nadelen van de Hammer Editor

Voordelen

Nadelen







 API voor Visual Studio is moeilijk  Geen mogelijkheid tot genereren van videomateriaal  Scene niet parametriseerbaar

Erg goedkoop Ingebouwde physics Multi-user Snel en gebruiksvriendelijk

16

2.2.3

OGRE Engine

Werking Ook de OGRE Engine werd door Traficon voorgesteld als een mogelijke techniek om de masterproef mee uit te werken. OGRE staat voor “Object-Oriented Graphics Rendering” en is een gratis, open source 3D engine die object georiënteerd programmeren ondersteunt. De engine bevat een API waardoor communicatie met een front end in Visual Studio mogelijk is. Via deze API kan de scene vanuit een front end automatisch aangepast worden. Net als bij de Source Engine van Valve zijn een aantal physics aanwezig die handig zijn voor bijvoorbeeld het berekenen van schademodellen van auto’s. De OGRE Engine wordt hoofdzakelijk gebruikt voor games. Het vereist veel tijd om met de OGRE engine een scene te gaan opbouwen. Hierbij moet er van scratch begonnen worden en is een goede voorkennis van C++ noodzakelijk. Voorbeeld Een voorbeeld van een game die de OGRE Engine gebruikt is de racegame MotorM4x zoals figuren 2-18 en 2-19 illustreren. Dit zijn beelden uit de game zelf. Ze geven de verschillende voordelen van de engine weer. Door de ingebouwde physics ontstaan remsporen op de baan doordat de wielen wrijving veroorzaken met het wegdek. Het linker wiel van witte wagen staat op het trottoir. Bij een animatie in een modelleerpakket zou de wagen gewoon dwars door het verhoogde trottoir rijden. Dit komt omdat een modelleerpakket geen physics bevat en dus ook geen botsingen of dergelijke effecten kan genereren. Het is de OGRE Engine die er voor zorgt dat dit linker wiel wel op het trottoir gaat rijden. Ook het gebruik van schademodellen wordt mogelijk met de OGRE Engine. De voorkant van de witte auto is geblutst zoals figuur 2-19 weergeeft. De engine gaat daarbij ook “particles” genereren die rook simuleren. Onder de auto’s is schaduw te zien. De automodellen zijn van hoge kwaliteit en zijn erg gedetailleerd. Om tot een dergelijk resultaat te komen is jaren werk vereist door een team van experts. Dit is niet mogelijk zonder ruime voorkennis of ervaring.

Figuren 2-18 en 2-19: MotorM4x

17

Beperkingen Enerzijds is de hoge instapdrempel een nadeel van de OGRE engine. Anderzijds heeft de engine nog een tweede beperking. Hij maakt namelijk geen gebruik van meerdere CPU cores. Hedendaagse systemen bevatten vaak meerdere CPU cores. Indien OGRE ondersteuning zou bieden voor multicore rendering, zou het renderproces nog efficiënter gebeuren. Andrews, J. (2009) kaart het probleem aan en stelt multithreading voor als mogelijke oplossing. Figuur 2-20 geeft een voorbeeld van wat wel mogelijk is zonder uitgebreide voorkennis. Bij deze scene zijn de graphics niet meer fotorealistisch, de automodellen simpel, de texturen en lichteffecten minimaal. Het resultaat voldoet niet meer aan de eis tot fotorealisme van Traficon.

Figuur 2-20: Verkeerssituatie in OGRE Engine

Besluit Zonder voorafgaande ervaring is de OGRE Engine ongeschikt om de masterproef mee uit te werken. De engine is wel gratis en object georiënteerd maar heeft een te grote instapdrempel om er een fotorealistische verkeerssituatie mee op te bouwen. Ook kunnen geen parameters ingevoerd worden. Daardoor kan een scene zich niet automatisch vormen naar de wensen van de gebruiker. Een nieuwe scene moet telkens van scratch gemaakt worden. Tabel 2-4: Voor- en nadelen van de OGRE Engine

Voordelen

Nadelen








 Geen gebruiksvriendelijkheid  Moet van scratch beginnen  Weinig mogelijkheid tot genereren van videomateriaal  Voorkennis van C++ vereist

Gratis en open source Tutorials beschikbaar API en SDK Volledige 3D mogelijkheden Object georiënteerd

18

2.2.4

3D Studio Max

Algemeen 3D Studio Max is een professioneel pakket van Autodesk voor 3D modeling en animaties. Het is verkrijgbaar vanaf $ 3499. Het renderen gebeurt standaard via het scanline rendering algoritme. Er zijn ook een aantal third-party renderers aanwezig zoals bijvoorbeeld mental ray of indigo renderer. De rendertijd ligt beduidend lager dan bij gratis alternatieven. Puech, Y. verklaart dat 3D Studio Max gebruik maakt van DirectX shaders voor het renderen van standaardmaterialen. Zodoende wordt niet enkel meer de CPU belast bij het renderen maar wordt ook de GPU optimaal benut. DirectX of Direct3D is de bekendste en efficiëntste verzameling van API’s voor het ontwikkelen van 3D games. 3D Studio Max wordt bij sommige recente films gebruikt ter ondersteuning van de visuele effecten. Voorbeelden daarvan zijn Spider-man 3, The Day After Tomorrow, The Matrix en XMen3. Figuren 2-21 en 2-22 geven de CGI weer die gebruikt worden bij voorgenoemde films. In de films worden ‘echte’ scenes afgewisselde met vaak spectaculaire scenes die gemaakt werden met de computer. Soms wordt ook een combinatie van de twee getoond, waarbij een geacteerde scene opgepoetst wordt met speciale effecten.

Figuren 2-21 en 2-22: 3D Studio Max showcases

Naast professionele filmstudio’s gebruiken ook architecten, bouwkundig ingenieurs en universiteiten het pakket. Volgende citaat staaft dit.

“There is a growing awareness of the multiple usages of 3ds Max and Maya within other departments and faculties. The continuing rapid change and growth of the media industries means that Creative Technologies at Portsmouth University is always at the forefront of technology, supporting this with its close ties with industry leaders like Autodesk.” —Alex Counsell, Faculty of Creative and Cultural Industries University of Portsmouth

3

Een overzicht is te vinden op http://en.wikipedia.org/wiki/List_of_films_made_with_Autodesk_3ds_Max

19

Voorbeeld Een ander voorbeeld van een succesverhaal met 3D Studio Max is het virtuele tunnelontwerp door Parsons Brinckerhoff. Dit bedrijf heeft een verkeerssimulatie gemaakt in opdracht van de San Francisco County Transportation Authority4. Voordat de tunnel effectief gebouwd werd, deed de overheid beroep op een dergelijke simulatie. Deze geeft een idee van hoe het resultaat er zou kunnen uitzien. Op aanvraag van de klant kunnen nog aspecten veranderd worden.

Figuur 2-23: Tunnelontwerp in 3D Studio Max, door Parsons Brinckerhoff

Het eindresultaat voldoet aan alle eisen van Traficon. De scene benadert fotorealisme en geeft een waarheidsgetrouw beeld weer. De gebruikte automodellen bevatten voldoende details. De licht- en schaduweffecten zijn van goede kwaliteit. 3D Studio Max lijkt dus een goede kandidaat om de masterproef mee uit te werken. Scripting Naast de uitgebreide ondersteuning voor modeling en animatie is er ook de mogelijkheid om aan scripting te doen. Er bestaat nog geen API die instaat voor de communicatie tussen Visual Studio en 3D Studio Max. Om toch iets te kunnen programmeren moet MAXScript gebruikt worden. Dit is belangrijk voor de uitwerking van de masterproef. Een van de vereisten is namelijk de mogelijkheid om parameters in te voeren. Deze stellen de gebruikerswensen voor. Voorbeelden van dergelijke parameters zijn het aantal rijvakken, de lengte van de tunnel, het aantal wagens, enzovoort. Na invullen van de parameters kan vanuit het script een scene opgebouwd worden. Dit wil dus zeggen dat in MAXScript onder andere methodes bestaan om te modelleren en te animeren. Onderstaande afbeelding geeft de script editor weer die ingebouwd is in 3D Studio Max. Het script kan ook bewerkt worden met een externe tekstverwerker zoals kladblok.

4

Het volledige verhaal is uitgeschreven op http://images.autodesk.com/adsk/files/parsons_brinckerhoff.pdf

20

Een handige tool is de macrorecorder. Deze genereert automatisch de bijhorende methodes die gebruikt kunnen worden in MAXScript na gebruikersinteractie met de 3D Studio Max GUI. Wanneer de gebruiker bijvoorbeeld een kubus verplaatst dan resulteert de macrorecorder in een aantal methodes voor MAXScript waarmee objecten in de scene verplaatst kunnen worden.

Figuur 2-24: Script Editor in 3D Studio Max

MAXscript maakt gebruik van events en eventhandlers. Het lijkt goed op een basic taal zoals C# of VB.NET. Het is op expressies gebaseerd en is volledig hoofdletterongevoelig. Variabelen worden gedeclareerd zonder een expliciet type wat het programmeren gemakkelijker maakt. Codeblokken en namespaces worden aangeduid met ronde haakjes. Objecten in de scene kunnen vanuit het script direct aangesproken worden. Eigenschappen van deze objecten kunnen opgevraagd worden via de puntoperator, zoals codevoorbeeld 2-1 aanduidt.

21

Methodes en eigenschappen zijn “mappable”, dit wil zeggen dat ze een of meerdere objecten als argument aanvaarden. Codevoorbeeld 2-1 illustreert een mappable eigenschap. Hierbij krijgt elk object dat begint met ‘Box’ een nieuwe hoogte van 10. Het sterretje * is een wildcard. $Box*.height = 10 Codevoorbeeld 2-1: Een mappable eigenschap

Er zijn verschillende gebieden waarop MAXScript wordt toegepast. Ten eerste is er de command line interface, die gebruikt kan worden om statische data over de huidige scene te printen of om snelle wiskundige berekeningen te doen. Ten tweede wordt MAXScript ook gebruikt om user interfaces te maken. Er zijn allerhande objecten beschikbaar ter interactie met de gebruiker, zoals buttons, numeric up downs, enzovoort. Deze kan je volledig aanpassen met Visual MAXScript, een omgeving gelijkaardig aan Microsoft Visual Studio.5 Besluit Als besluit kan gesteld worden dat 3D Studio Max zeer geschikt is om de masterproef mee uit te werken. De mogelijkheden omtrent modeling zijn zeer uitgebreid en er is scripting voorzien. Het enige nadeel van dit pakket is de prijs. Tabel 2-5: Voor- en nadelen van 3D Studio Max

Voordelen

Nadelen







 Duur  Werkt enkel op Windows

Uitgebreide ondersteuning Professioneel modelleren en animeren Scripting DirectX renderen

5

Een volledige lijst met features van MAXScript is te vinden op http://wiki.cgsociety.org/index.php/MAXScript

22

2.2.5

Blender

Algemeen Blender is een gratis 3D modeling pakket. Het is volledig open source en werkt op verschillende platformen, waaronder Windows en Linux. Blender bevat grotendeels dezelfde functionaliteit als 3D Studio Max. Het gebruiksgemak en de performantie liggen wel lager. 3D Studio Max maakt bij het renderen gebruik van DirectX terwijl Blender enkel software rendering via de CPU of het verouderde OpenGL gebruikt. Het renderen duurt bij Blender merkbaar langer. Korva, T. (2007) verklaart dat software renderen veel trager is omdat de GPU daarbij niet benut wordt. Wanneer DirectX gebruikt wordt bij het renderen wordt de GPU wel benut. Bij DirectX verloopt de aansturing van de videokaart beduidend sneller dan bij concurrent OpenGL. Professionele pakketten die DirectX gebruiken kunnen wel enkel op Microsoft machines uitgevoerd worden. Blender daarentegen is niet gebonden aan één platform. Wanneer voor een gratis programma als Blender gekozen wordt, moet dus ingeboet worden op vlak van performantie en van gebruiksgemak. De GUI van Blender is wat contra-intuïtief en vergt tijd om aan te wennen. Voorbeeld Er bestaan reeds enkele tunnelsimulaties die gemaakt zijn in Blender. Een voorbeeld daarvan is “Tunnel Run”, gemaakt door Clark Thames. Hierbij zijn de graphics echter nog niet goed genoeg. De gebruikte texturen zijn nog te simpel. Er zijn ook geen licht -of schaduweffecten. De maker heeft er wel wat functionaliteit ingestoken. De auto kan sturen, accelereren en remmen.

Figuur 2-25: Tunnel Run in Blender

Scripting Net zoals in 3D Studio Max kan men in Blender ook aan scripting gaan doen. De programmeertaal is Python. Codevoorbeeld 2-2 beeldt uit hoe een Python script er kan uit zien. Scripts worden at runtime geïnterpreteerd en moeten dus niet gecompileerd worden. import Blender import Scene from Blender import Object scn = Scene.GetCurrent() for objects in scn.objects: loc = objects.getLocation() print loc Codevoorbeeld 2-2: Een Python voorbeeld

23

In het begin van het script moeten de nodige modules geïmporteerd worden. Door deze manueel in te laden gebruikt Python niet meer dan de nodige resources. In het voorbeeldscript worden de modules “Blender” en “Scene” geladen. Er kunnen nog submodules geladen worden, zoals in het codevoorbeeld gebeurt bij de Blender module. Het voorbeeldscript gaat van alle objecten in de huidige scene de globale locatie printen in de console. Dit gebeurt via een for-lus. Eigenschappen van objecten kunnen geraadpleegd worden met de puntoperator. Alle logische functionaliteit is aanwezig: for- en while-lussen, if - then statements, enzovoort. Python is een object georiënteerde taal die gemakkelijk aan te leren is. Het is de scriptingtaal bij uitstek voor animaties. Blender bevat een ingebouwde script editor. Deze voorziet in een beperkte functionaliteit. Er is “syntax highlighting” en regelnummering voorzien. Er is echter geen mogelijkheid tot het zetten van breakpoints. Stap voor stap debuggen is niet mogelijk in de huidige editor. Het is wel mogelijk om op een bepaald punt een variabele te laten printen naar de console. Debuggen van de Python code verloopt moeizaam en inefficiënt in de script editor van Blender.

Figuur 2-26: Script editor in Blender

Er zijn maar weinig IDE’s voor Python die ook Blender ondersteunen. De enige degelijke is Stani’s Python Editor. Deze editor herkent naast gewone Python-code ook Python-methodes die naar Blender verwijzen. SPE bevat syntax highlighting en intellisense waarmee half getypte methodes herkend worden en automatisch aangevuld worden. Daarnaast bezit het ook de broodnodige debug mogelijkheid. Er kunnen breakpoints gezet worden en er kan stap voor stap gedebugd worden. SPE wordt daarom door Famler, B. (2007) aangeraden als editor bij uitstek voor Python scripts.

24

De API die de communicatie verzorgt tussen Python en Blender is volledig uitgeschreven6. Deze bevat alle klasses met methodes in Python die relevant zijn voor Blender. In de documentatie wordt telkens vermeld welke argumenten vereist zijn en wat de methode doet. In figuur 2-27 wordt een deel van de methodes van de klasse ‘Object’ getoond. De methode Object.clearIpo() zal bijvoorbeeld de interpolatiecurve verbonden aan het object verwijderen.

Blender Kern C/C++

Script Python

API

Figuur 2-27: API voor communicatie tussen Blender en Python

Naast een API in Python is er ook een API in de programmeertaal C voorzien. Hiermee kunnen alle handelingen uitgevoerd worden die de gebruiker in de GUI van Blender kan doen. Deze API is dus compleet, tegenover de Python API waarbij soms enkele kleine of zeldzame functies ontbreken. De C API wordt echter niet vaak gebruikt omdat er geen documentatie rond uitgeschreven is en omdat deze crashes kan veroorzaken. Dit wordt uitgelegd in het artikel van Dunbar, D. (2003). Besluit Voor de masterproef is geen budget voorzien. Blender is dus de beste kandidaat omdat het dezelfde functionaliteit als 3D Studio Max aanbiedt én gratis is. Tevens is ook scripting mogelijk met Python. Enkele nadelen bij Blender zijn enerzijds de lagere gebruiksvriendelijkheid. De GUI is contra-intuïtief en is minder toegankelijk voor leken. Anderzijds ligt de performantie ook wat lager. Het renderen duurt wat langer door dat enkel de CPU benut wordt. Tabel 2-6: Voor- en nadelen van Blender

6

Voordelen

Nadelen


Gratis en open source
Tutorials beschikbaar
Multiplatform

 Weinig intuïtief  Weinig gebruiksvriendelijk  Lange rendertijd

De volledige API is te vinden op http://www.blender.org/documentation/249PythonDoc/frames.html

25

2.2.6

Samenvatting bestaande technieken

Nu de vijf onderzochte technieken besproken zijn worden de belangrijkste criteria samengevat. Deze krijgen telkens een score tussen 0 en 10 om de kwaliteit van de techniek te beoordelen. De belangrijkste aspecten staan bovenaan in de tabel. Voor Traficon is de rendertijd het minst belangrijk. Het is aanvaardbaar wanneer het renderen enkele dagen in beslag neemt. Tenslotte wordt de totale score berekend. Deze geeft weer hoe goed de techniek geschikt is om de masterproef mee uit te werken. Tabel 2-7: Resultaten van het voorafgaand onderzoek

Criteria

PovRay

Hammer Editor

OGRE Engine

3D Studio Max

Blender

Parameters

0

0

0

9

9

Fotorealisme

10

7

7

9

9

Prijs

10

8

10

0

10

Rendertijd

0

10

10

4

1

50%

62.5%

67.5%

55%

72.5%

Totaal

Een vollediger overzicht van bestaande technieken wordt beschreven in het werk van Korva, T. (2007), hoofdprogrammeur bij LudoCraft. Dit is een Finse game studio. In het werk komen de voornaamste softwarepakketten aan bod die gebruik maken van een 3D engine. Hij beschrijft daarbij onder andere Blender en de OGRE engine. Bij elke techniek worden de voor- en nadelen opgesomd. Bij Blender wordt aangehaald dat het renderproces bij complexe scenes traag verloopt, zoals tijdens het onderzoek ook geconstateerd werd. Bij de OGRE engine wordt de hoge instapdrempel geweten aan het ontbreken van een gebruiksvriendelijke editor. Over de gehele lijn scoort het programma Blender het best. Enkel de rendertijd scoort hierbij slecht. Dit is echter toelaatbaar. Voor Traficon mag het renderen enkele dagen duren. Aldus wordt gekozen om de masterproef uit te werken in Blender. Het modelleerpakket wordt gebruikt om de tunnel en de verkeerssimulatie in 3D op te bouwen. Dit alles gebeurt op de achtergrond. De voorkant (front end) die de gebruiker te zien krijgt is een GUI gemaakt in de .NET omgeving. Het gebruik van parameters wordt mogelijk door aan scripting te doen in Python. Een script kan op basis van een aantal gekregen argumenten (de instellingen van de gebruiker) een scene op de achtergrond volledig opbouwen in Blender en vervolgens het geheel renderen. Vanuit de front end kunnen de parameters die ingesteld werden door de gebruiker meegegeven worden aan het script. Dit gebeurt via string replacements. De exacte werking daarvan komt aan bod in de verhandeling van Karel Azou. Hoe de tunnel zelf in 3D opgebouwd wordt met bijhorende belichting wordt beschreven in de masterproeftekst van Frédérique Vanneste.

26

3. Implementatie van de verkeersmodule 3.1 Doelstellingen Voor de verkeersmodule heeft Traficon een aantal vereisten opgesteld. De gebruiker moet de verkeersgebeurtenissen weergegeven in tabel 3-1 kunnen instellen aan de hand van parameters. Om de verkeersmodule uit te werken is het de bedoeling dat een script ontwikkeld wordt in Python. Het script moet op basis van de ingestelde argumenten de gevraagde events kunnen genereren. Een event wordt gesimuleerd aan de hand van een animatie in Blender. Dit script moet van scratch gemaakt worden. Er bestaan reeds dergelijke verkeerssimulatoren maar deze niet gratis. De code er achter wordt niet vrijgegeven. Het gewenste gedrag van de wagens in de tunnel wijkt ook af van dat in de reële wereld. Zo is het bijvoorbeeld geen vereiste dat wagens van rijvak kunnen veranderen. Tabel 3-1: De verkeersvereisten

Gebeurtenis

Parameters

Normaal verkeer







Willekeurige stroom van auto’s zonder speciale events.

Stop Op één rijvak stoppen een aantal auto’s. Na een bepaald interval rijden ze weer door. Op de andere rijvakken rijdt enkel “normaal” verkeer.

File Op één rijvak ontstaat een file, voor een bepaalde duur. Op de andere rijvakken rijdt enkel normaal verkeer. De mogelijkheid om van rijvak te veranderen is geen vereiste.

Vallend Object Uit een bepaalde auto valt een object. De auto’s erna moeten stoppen.

Spookrijder Op een bepaald rijvak rijdt één spookrijder.

Debiet: aantal wagens per minuut Kans op klasse van voertuig Snelheid, per rijvak (km/h) Uni- of bidirectioneel verkeer


Positie van het event (in meter, ten opzichte van de camera)
Rijvak waarop de stop gebeurt
Start van het event
Einde van het event
Onderlinge afstand tussen de wagens
Aantal wagens die deelnemen aan het event
Positie van het event (in meter, ten opzichte van de camera)
Rijvak waarop de stop plaatsvindt
Start van het event
Einde van het event
Snelheid van de filerijdende auto’s
Onderlinge afstand tussen de wagens
Aantal wagens die deelnemen aan het event
Rijvak waarop het event plaatsvindt
Tijdstip waarop het event gebeurt
Positie (in meter, ten opzichte van de camera) waar het object valt
Aantal wagens die stoppen
Aanvang van het event
Rijvak waarop het event plaatsvindt

27

3.2 Werkwijze 3.2.1

Versiecontrole

Bij het opbouwen van het script dat een gepersonaliseerde tunnel en verkeerssituatie genereert wordt gewerkt met een versiecontrolesysteem. Traficon gebruikt daarvoor TortoiseSVN7. Deze software is volledig gratis en open source. Subversion is recent uitgegroeid tot de industriestandaard en wordt typisch gebruikt wanneer meerdere mensen aan dezelfde code werken. Tevens is het ook een gemakkelijke manier om een dagelijkse backup van het werk te hebben. Voor de thesisstudenten is een repository aangemaakt waar het werk regelmatig opgeslagen kan worden. Dit is een server waarin een kopie van het werk komt. De gebruiker heeft ook een lokale kopie staan waarop hij kan werken. Aan het begin van de dag haalt de gebruiker het werk af van de server. Na aanpassen wordt het werk weer naar de server opgeladen. Deze bevat de mappen ‘trunk’ en ‘branch’. Algemeen kan geschreven code bijgehouden worden in de trunk. Wanneer een nieuwe maar onzekere weg ingeslagen wordt, kan de code in een nieuwe branch opgeslagen worden. Wanneer het werk in de branch succesvol blijkt kan deze weer samengevoegd (“merge”) worden met de trunk. Volgende figuur beeldt dit uit. Bovenaan in het groen wordt na versie r4 een branch aangemaakt. Deze blijkt goed te functioneren en wordt later weer bij de trunk toegevoegd. De evolutie van de trunk wordt uitgebeeld in het blauw. In het rood staat de versienummering.

Figuur 3-1 Het branching principe bij versiecontrolesystemen

Wanneer twee mensen veranderingen aanbrengen in de zelfde code dan zal het versiebeheersysteem de twee gekregen versies laten samensmelten. Op deze manier kunnen meerdere mensen tegelijk aan eenzelfde script werken. Praktisch gezien kan zo door twee thesisstudenten aan eenzelfde Python script gewerkt worden dat de tunnel én het verkeer genereert. Figuur 3-2 beeldt het copy-modify-merge werkingsprincipe uit. Zoals uitgelegd door Küng, S., Onken, L. en Large, S. (2007) geeft de afbeelding weer dat telkens een gebruiker zijn code wil opladen naar de server, er aan versiecontrole gedaan wordt. Indien de versie niet overeenkomt moet er aan merging (samenvoeging) gedaan worden.

7

Alle documentatie kan gevonden worden op http://tortoisesvn.net

28

Figuur 3-2: Het copy-modify-merge principe bij een versiebeheersysteem

Wanneer een gebruiker de code van de repository afhaalt (‘Read’) moet inconsistente data vermeden worden. Daarvoor gebruikt het versiecontrolesysteem volgende methodiek.

Figuur 3-3: Voorkomen van inconsistente data bij een versiecontrole

29

3.2.2

Scrum

Tijdens het et werken aan de code wordt de Scrum S techniek iek gebruikt. Ook de werknemers van Traficon werken op deze manier. Volgende figuur geeft het principe weer.

Figuur 3-4: De werkcyclus bij Scrum

De “product backlog” is een verzameling van alle taken die moeten gebeuren om een nieuw product te ontwikkelen. Hieruit wordt een takenpakket gehaald, namelijk de sprint backlog. Dit pakket wordt verdeeld over de verschillende leden van een projectteam. Vervolgens Vervo wordt de sprint uitgewerkt over een kleine periode van enkele weken tot een maand. Elke werkdag in deze periode wordt de status van elke taak geüpdatet. In Traficon gebeurt dit aan de hand van post-its post waarmee een werknemer aanduidt in hoeverre een taak afgewerkt is. Afbeelding 3-5 3 illustreert dit. Er wordt elke dag kort vergaderd om te zien hoe het werk vordert. Afgewerkte functionaliteit wordt gedemonstreerd. Het voordeel van een dergelijke aanpak is de snelheid en de flexibiliteit. Er kan op korte termijn ingegrepen worden en eventueel bijgestuurd worden waar nodig. Ook kan binnen enkele weken de ontwikkeling van een nieuw product gestart worden. Eliasson, M. (2005) geeft aan dat een versiecontrolesysteem een meerwaarde biedt bij Scrum en XP (eXtreme (eXtrem Programming). De combinatie van Scrum en TortoiseSVN is een goede manier om snel software te ontwikkelen. Verder wordt via Scrum Scrum ook de vooruitgang en de efficiëntie van het team in de gaten gehouden. Vooraf, bij het vastleggen van het takenpakket worden ook de risico’s in kaart gebracht en geminimaliseerd. Zoals uitgelegd door Pauwels, I. (2010) wordt Scrum crum best gebruikt bij kleine projectteams waarbij de requirements nog kunnen veranderen.

Figuur 3-5:: De mogelijke statussen van een taak bij bi Scrum

30

3.3 Normaal verkeer Wanneer geen speciale verkeersgebeurtenissen zoals files of botsingen optreden tijdens de verkeersstroom, dan spreekt men van normaal verkeer of free flow. Bij dit type verkeer moet de gebruiker vier parameters kunnen instellen. Deze vier parameters worden aan een script meegegeven die een animatie opstelt die het gewenste verkeer simuleert. Tabel 3-2: Parameters bij normaal verkeer

Parameters





3.3.1

Snelheid, per rijvak (km/h) Debiet: aantal wagens per minuut Kans op klasse van voertuig Uni - of bidirectioneel verkeer

Snelheid per rijvak

Animaties In Blender is het onmogelijk om op een bepaald frame in te grijpen en een auto te laten vertragen of versnellen. Het is niet mogelijk om vanuit code op een bepaald frame in de animatie te kijken of er wagens vertragen en daardoor de volgende wagens ook te laten vertragen. Dit realtime event karakter ligt in het gebied van de game engines. Daar kan tijdens een simulatie ingegrepen worden en kan de eindgebruiker zelfs de scene beïnvloeden door bijvoorbeeld de camera te verplaatsen of zelf een wagen te besturen. Blender kan enkel voorgedefinieerde animaties laten renderen. Dit wil dus zeggen dat elke wagen vooraf een snelheidsbeschrijving moet krijgen. Eens de animatie gemaakt is en van start gaat, kan niets meer veranderd worden. Het script bouwt de animatie opnieuw op wanneer de gebruiker een verandering doorvoert. Een animatie in Blender bestaat telkens uit drie onderdelen. Ten eerste is er het object dat de animatie ondergaat. In dit geval is dit het voertuig. Het normale verkeer wordt opgebouwd met een for-lus die een aantal methodes herhaalt voor een willekeurig opgehaalde wagen. Het voertuig wordt telkens geïmporteerd uit een bibliotheek met een tiental automodellen, en wordt in de scene geplaatst. Ten tweede is er het te volgen pad. Dit is een curve die de vorm heeft van de tunnel. Het pad wordt exact in het midden van de tunnel gelegd zoals figuur 3-6 weergeeft. De gekregen offset ten opzichte van dit pad zal bepalen op welk rijvak de wagen rijdt. In de figuur rijdt de wagen op het meest rechtse rijvak, door de gekregen offset. Men kan ook het te volgen pad zelf naar rechts verschuiven in plaats van te werken met een offset. Deze methode zal echter problemen opleveren bij een tunnel die een bocht maakt. Het lineair verschoven pad beschrijft het rijvak niet meer correct in geval van een bocht. Zodoende is geopteerd om steeds te werken met een offset. Deze zal ook in bochten de wagen exact op het rijvak laten rijden. Op de offset zit een kleine afwijking zodat niet elke wagen exact in de midden van het rijvak rijdt. Deze afwijking is een willekeurig getal en wordt begrensd tussen min twintig en plus twintig centimeter.

31

Figuur 3-6:: De onderdelen van een animatie in Blender

Snelheidsbeschrijving Het laatste benodigde onderdeel om een animatie op te stellen, stellen is de snelheidsbeschrijving van het bewegende object.. Dit gebeurt in Blender aan de hand van interpolatiecurves. Deze curves bepalen dynamisch een bepaalde waarde (zoals positie, rotatie, rotati grootte, …) van een object in functie van de tijd. Interpolatiecurves zijn de enige mogelijkheid om op een bepaald frame een gebeurtenis te lanceren en zijn dus cruciaal voor de uitwerking van de verkeerssimulatie. Figuur 3-7 illustreert een voorbeeld van een mogelijke snelheidsbeschrijving. Op de horizontale as wordt de tijd in frames uitgezet. De verticale as stelt de relatieve positie voor op het traject.. De cyaankleurige curve is de snelheidsbeschrijving zelf. Deze vertelt hoe de positie van het object moet veranderen in functie van de tijd. Een waarde van 0.0 betekent de positie aan het begin van het bijhorende pad. Het einde van het pad komt overeen met de waarde 1.0. Wanneer de snelheidsbeschrijving een rechte lijn is gaande van 0.0 tot 1.0 dan zal de positie van de wagen lineair veranderen in functie van de tijd. tijd. Dit wil zeggen dat de wagen met een constante snelheid van het begin naar het eindee van de tunnel zal rijden. In de figuur begint de wagen na exact honderd frames met rijden. Ongeveer 180 frames later bereikt de wagen het einde van het traject. De y-waarden waarden van de curve geven procentueel weer hoever de wagen zich bevindt in de tunnel. Het aantal effectief afgelegde meters hangt af van de totale lengte van het traject.

Figuur 3-7: De snelheidsbeschrijving nelheidsbeschrijving van een wagen

32

De snelheid van de wagen kan ingesteld worden door het tijdsinterval waarin de wagen het traject aflegt rijdt, te veranderen. De lengte van het nodige tijdsinterval (in frames) om een bepaalde absolute snelheid (in km/h) te simuleren kan berekend worden met onderstaande formule.

Formule 3-1: Intervalberekening op basis van gewenste snelheid

De gevraagde snelheid wordt eerst omgezet van km/h naar m/s door te delen door 3.6. Vervolgens wordt het ingestelde aantal frames per seconde gedeeld door de snelheid in m/s. Zo weet men hoeveel frames nodig zijn om een wagen één meter te laten rijden. Na vermenigvuldigen met de totale lengte van de baan (in meter) bekomt men het aantal frames nodig om het volledige traject af te leggen. Wanneer dit tijdsinterval wordt ingesteld bij de snelheidsbeschrijving zal de wagen zich van begin tot eind verplaatsen aan de gewenste snelheid. Naast de helling van de snelheidsbeschrijving is ook het moment waarop de wagen vertrekt belangrijk voor de simulatie. In figuur 3-7 is dat op frame 100. De volgende wagen op dat rijvak mag pas iets later vertrekken. Stel dat de volgende wagen twee seconden later aan het traject begint dan zal deze zijn startpunt op frame 150 liggen, indien er wordt gewerkt met een FPS van 25. Het debiet van de verkeersstroom is instelbaar door de gebruiker. De snelheid van de wagens op een bepaald rijvak is constant en voor elk voertuig op dat rijvak gelijk. De wagens op één rijvak kunnen niet veranderen van snelheid. Dit is noodzakelijk omdat alle wagens vooraf hun snelheidsbeschrijving moeten krijgen. Eens de animatie gestart is kan niet meer ingegrepen worden. Het is niet mogelijk om bijvoorbeeld op frame 200 een wagen iets te laten vertragen en de andere wagens daar rekening mee te laten houden. Er is geen mogelijkheid tot automatische interactie tussen de wagens, tenzij dit ook vooraf in de snelheidsbeschrijvingen ingesteld zou zijn. Dit komt aan bod bij de bespreking van de file- en de stopevents. Béziercurves De snelheidsbeschrijving in Blender is een Béziercurve. Deze curve is opgebouwd uit “Bézier triples” die verbonden zijn door een vloeiende lijn. Een Bézier triple is een verzameling van twee handlers en een knot. De knot is het punt waardoor de Béziercurve gaat, de handlers geven de in- en uitgaande richting aan. Figuur 3-8 geeft dit weer.

Figuur 3-8: Een Béziercurve in Blender.

33

Aan de hand van deze curves wordt het gedrag van een wagen vloeiend beschreven. Codevoorbeeld 3-1 manipuleert een Béziercurve vanuit code. Eerst wordt het volledige interpolatieobject NormaalVerkeer ingeladen. Dit bevat onder meer de snelheidsbeschrijving maar kan nog meer curves bevatten die bijvoorbeeld de rotatie of de actieve layer van het object bepalen. Deze worden later besproken. Met het attribuut CU_SPEED wordt de benodigde snelheidscurve opgevraagd. Vervolgens worden alle Bézier triples van de curve opgevraagd met de methode bezierPoints(). Dit resulteert in een lijst van triples. Een element uit een lijst kan opgevraagd worden met een index tussen vierkante haakjes. Het eerste element heeft index nul. Om nu de knot en de handler van het gekozen triple op te vragen moet het attribuut vec gebruikt worden. Van de gekregen handlers of knot kan men nu de coördinaten opvragen en veranderen om zodoende de snelheidscurve aan te passen. from Blender import Ipo Ipo1 = Ipo.Get('NormaalVerkeer') snelheidscurve = Ipo1[Ipo.CU_SPEED] beztriples = snelheidscurve.bezierPoints() beztriple1 = beztriples[0] h1, k, h2 = beztriple1.vec coordinaten = [h1[0], h1[1], h1[2]] Codevoorbeeld 3-1: De snelheidscurve manipuleren

Dit manipuleren van de snelheidscurve moet voor elke wagen opnieuw gebeuren, daar elke wagen het traject in een verschillend tijdsinterval aflegt. Om herhalende code te vermijden werd de functie Verzet() aangemaakt zoals weergegeven in Codevoorbeeld 3-2. Een functie wordt gedefinieerd met het woord def. Vervolgens komt de naam met de argumenten tussen haakjes. Deze regel moet afgesloten worden met een dubbelpunt. De coderegels die tot de functie behoren moeten beginnen met een inspringing. De functie wordt niet expliciet afgesloten. Wanneer een regel code niet meer met een inspringing begint dan maakt deze regel geen deel meer uit van de gedefinieerde functie. Dit is eigen aan de syntax van Python. def Verzet(beztriple,X,Y): h1, k, h2 = beztriple.vec h1 = [h1[0] + X, h1[1] + Y, 0] k = [k[0] + X, k[1] + Y, 0] h2 = [h2[0] + X, h2[1] + Y, 0] return [h1, k, h2] Codevoorbeeld 3-2: Een punt van een Béziercurve verplaatsen

De functie Verzet() neemt drie argumenten. Het eerste argument is het te verzetten Bézier triple. De andere argumenten zijn respectievelijk de gewenste x- en y-offset. In de functie worden de knot en de handlers van het meegegeven triple elk verschoven over een offset van X en Y. Hierbij is h1[0] de x-coördinaat van de eerste handler en h1[1] de y-coördinaat. h1[2] is de z-coördinaat maar deze is standaard gelijk aan nul aangezien de snelheidsbeschrijving een 2Dcurve is. De functie resulteert in een verschoven triple.

34

Om alle punten van een Bézier curve te verplaatsen is de functie GeheelOpschuiven() gemaakt. Hierbij wordt elke Bézier triple van de curve verschoven over een bepaalde x- en yoffset. De gebruikte structuur komt overeen met een foreach-lus in C# of VB.NET. Dit betekent dat het script automatisch voor elke (for each) gevonden Bézier triple van de curve de methode Verzet() zal uitvoeren. Het doel van de functie is het tijdsinterval waarin de wagen het traject aflegt, te verschuiven. Wanneer de curve in zijn geheel verschoven wordt naar rechts start de wagen op een later tijdstip. De helling van de snelheidscurve blijft gelijk waardoor de snelheid van de wagen niet verandert. def GeheelOpschuiven(icu, deltaX): for triple in icu.bezierPoints: Verzet(triple,deltaX,0) Codevoorbeeld 3-3: Een volledige Béziercurve verschuiven

Free flow Om nu een verkeersstroom op een rijvak te genereren wordt een for-lus opgesteld. Deze gaat telkens een willekeurige wagen inladen vanuit een bibliotheek met automodellen. Vervolgens wordt de wagen aan een pad vast gemaakt en krijgt hij een snelheidsbeschrijving, zoals eerder beschreven werd. De volgende wagen krijgt opnieuw een pad met een gelijkaardige snelheidsbeschrijving waarbij enkel het moment van vertrek anders zal zijn. De onderlinge afstand tussen de wagens hangt af van het gekozen debiet. De for-lus resulteert in een verkeersstroom op een bepaald rijvak. De gekregen offset ten opzichte van het pad bepaalt op welk rijvak de wagen gaat rijden. De for-lus kan volledig herhaald worden voor een andere offset, om een volgend rijvak te vullen met verkeer. Auto’s op eenzelfde rijvak hebben allemaal exact dezelfde snelheid. Dit is een noodzakelijke toegeving omdat elke wagen een eigen snelheidsbeschrijving heeft. Automatische interactie tussen de wagens in free flow is niet vereist. Een verkeersstroom op het volgende rijvak kan wel een andere snelheid hebben. Formule 3-2 demonstreert hoe dit kan geïmplementeerd worden. Op het volgende rijvak kan X bijvoorbeeld gekozen worden zodat men daar 10 km/h sneller rijdt. De mogelijkheid om wagens van rijvak te laten veranderen is geen vereiste van Traficon.


 

   ⁄3.6

Formule 3-2: Snelheid instellen per rijvak

Renderen Om de rendersnelheid te verhogen mag de wagen niet in de scene getoond worden voor het moment van vertrek. Ook nadat de wagen de volledige weg afgelegd heeft mag hij niet blijven staan op het einde van de tunnel. Indien bij een verkeersstroom elke wagen blijft staan op het einde van het tunnel wordt de rendertijd nutteloos verhoogd. Op het moment dat de wagen zijn traject heeft afgelegd moet de wagen dus verdwijnen uit de scene.

35

Een object verwijderen vanuit Python kan met de code in Codevoorbeeld oorbeeld 3-4. 3 De functie unlink() gaat de link tussen de scene en het meegegeven object verwijderen, zodat het object niet meer zichtbaar is in de scene. Een object echt verwijderen uit een scene is in Blender onmogelijk, de data blijftt op de achtergrond bestaan b totdat Blender heropgestart wordt. import Blender from Blender import Scene scn = Scene.GetCurrent() Wagen = Blender.Object.Get(‘Wagen1’) scn.objects.unlink(Wagen) Codevoorbeeld 3-4:: Een object uit de scene verwijderen

Werken met de methode unlink() is echter geen mogelijkheid bij animaties. animaties Het doel is om op een bepaald frame in de animatie de wagen te verwijderen uit de scene. In Blender is het (zoals reeds besproken) onmogelijk om realtime op een bepaald frame in te grijpen.. Dergelijke events eve bestaan niet in Blender noch h in Python. Eens een animatie afgespeeld wordt kan niet meer ingegrepen worden. Om toch iets te laten gebeuren op een bepaald frame moet opnieuw gewerkt worden met interpolatiecurves. De layercurve is ideaal om het probleem mee op o te lossen. Analoog als bij de snelheidsbeschrijving snelheidsbeschrijv zal de layercurve bepalen op welke layer de wagen zich bevindt, in functie van de tijd. Figuur 3-4 illustreert de werking.

Figuur 3-9:: De layercurve in Blender

Bij de specifieke curve in Figuur 3-9 3 zal het object waaraan de curve verbonden is, zich initieel op layer twee bevinden. Enkel de objecten op layer één zijn zichtbaar in de rendering. rendering Wanneer de animatie 100 frames ver is zal het object verschijnen op layer één volgens de layercurve in figuur 3-9.. Even later, nadat het traject afgelegd werd moet moet het object weer verdwijnen naar layer twee. Deze layercurve is net zoals de snelheidsbeschrijving een Béziercurve. curve. Het instellen ervan kan dus weer gebeuren door de d Bézier triples te verschuiven, afhankelijk kelijk van wanneer de bijhorende ende wagen moet verschijnen en verdwijnen. Elke wagen krijgt naast een snelheidssnelheids beschrijving ook een aangepaste layerbeschrijving zodat hij voor en na het afleggen van het traject niet zichtbaar is.

36

Buitenbocht Bij het instellen instellen van de snelheid per rijvak moet ook rekening gehouden worden met de kromming van de tunnel. tunnel Stel dat de gebruiker een snelheid van 90 km/h wenst op elk rijvak. Dan krijgt elke wagen een snelheidsbeschrijving met dezelfde helling, helling, waardoor elke wagen het traject in hetzelfde tijdsinterval aflegt. Daarbij wordt er van uitgegaan dat elk traject exact dezelfde lengte heeft. Dit klopt echter niet indien de tunnel een bocht maakt. Daarbij is het rijvak van de wagen die de buitenbocht volgt iets langer. Wanneer een wagen in de binnenbocht van een tunnel rijdt, is de af te leggen afstand iets kleiner.

Figuur 3-10:: Het probleem bij de buitenbocht

In figuur 3-10 vertrekken de twee wagens op hetzelfde tijdstip. Ze komen ook aan op exact hetzelfde tijdstip, omdat hun un snelheidsbeschrijving dezelfde helling heeft en hen het traject laat afleggen in dezelfde tijd. Voorheen werd voor elk rijvak de lengte van het pad in de midden van de tunnel gebruikt om de snelheidbeschrijving mee in te stellen. Dit pad wordt in i het rood aangeduid op figuur 3-10. De wagen die de buitenbocht aflegt moet echter een iets grotere afstand afleggen dan in het rood aangeduid. aangeduid. Om op elk rijvak de correcte snelheid te simuleren moet bij het instellen van de snelheidscurve de echte afgelegde afstand afstand gebruikt worden, in plaats van de lengte van het rode pad. De echte afgelegde weg kan met formule 3-3 berekend worden. Daarbij is “Padlengte” gelijk aan de lengte lengte van het rode pad in figuur 3-10. 3 De hoek van de bocht wordt weergegeven door “α”.. “Breedte” is gelijk aan de breedte van een rijvak. “Offset” is de afstand tussen de wagen en het midden van de tunnel. Aan de hand van de werkelijke baanlengte kan de snelheid nu voor elk rijvak exact ingesteld worden. Indien de tunnel geen bocht bevat,, is de baanlengte voor elk rijvak hetzelfde. Dit blijkt ook uit de formule omdat dan de hoek α gelijk is aan nul graden. De tangens van nul graden blijft nul .

Formule 3-3: 3: Berekening van de werkelijke baanlengte bij een tunnel met een bocht

37

3.3.2

Het debiet

Gauss-verdeling De gemiddelde onderlinge afstand tussen de wagens is instelbaar. Deze zal resulteren in een bepaald debiet. Wanneer de gebruiker ervoor kiest om een gemiddelde afstand van vijftig meter tussen de wagens te laten dan wordt niet elke tussenafstand op telkens vijftig meter gezet. Om een realistische en willekeurige stroom van wagens te genereren moet er een bepaalde afwijking zitten op deze tussenafstand. Het gemiddelde moet wel vijftig meter blijven. In de uitgewerkte versie van het script wordt gewerkt met een gauss-verdeling. import Blender import random from random import gauss gemiddelde = 50 Tussenafstand = gauss(gemiddelde, 0.3*gemiddelde) Codevoorbeeld 3-5: De Gauss-functie in Python

De methode gauss() neemt twee argumenten. Het eerste is het gewenste gemiddelde en het tweede is de gewenste standaardafwijking. Deze laatste wordt gekozen als dertig procent van het de gemiddelde tussenafstand. Figuur 3-11 toont een reeks getallen die via een gauss-verdeling gegenereerd werd. Elk getal heeft dus een bepaalde afwijking ten opzichte van de tussenafstand. Wanneer het gemiddelde van de getallen berekend wordt, bekomt men ongeveer vijftig (in dit voorbeeld). In grafiekvorm beschrijven de resulterende getallen een curve zoals op figuur 3-12. Deze staat beter bekend als de gausscurve. Daar er een natuurlijke afwijking zit op de afstanden tussen de wagens onderling, komt de verkeersstroom realistischer over.

Figuren 3-11 en 3-12 : Resultaat van de methode gauss().

De berekende tussenafstand wordt nu gebruikt om de volgende wagen op een later ogenblik te laten vertrekken. Dit moment van vertrek kan ingesteld worden door de bijhorende snelheidsbeschrijving aan te passen, zoals reeds besproken werd. Uit de gewenste tussenafstand (in meter) wordt berekend hoeveel frames later de volgende wagen moet vertrekken.

38

Formule 3-4: 3 Tussenafstand omzetten naar aantal frames

Hierbij wordt net zoals in Formule 3-1 3 berekend in hoeveel frames de wagen één meter aflegt. Vervolgens wordt dit getal vermenigvuldigd vermenigvuldigd met de onderlinge tussenafstand. Het resultaat hiervan is de tijd (in frames) die nodig is om de wagens de gevraagde tussenafstand te geven. Deze bekomen tijd kan nu gebruikt worden bij het instellen van de snelheidsbeschrijving van de volgende wagen. De tussenafstand in meter is voor elke wagen verschillend door de gaussgauss verdeling.

3.3.3

Kans op klasse van voertuig

for Bibliotheek Een dergelijke verkeersstroom wordt opgebouwd aan de hand van een for-lus. De lus laadt telkens een wagen uit de bibliotheek in om deze vervolgens olgens een pad en een snelheidsbeschrijving beschrijving te geven. Om een natuurlijke stroom van verkeer te simuleren moet de kans op een bepaalde klasse van voertuigen ingesteld worden. De bibliotheek bevat negen personenwagens, twee vrachtwagens en drie drie verschillende bussen. Telkens de for-lus for een voertuig moet inladen wordt een willekeurig nummer berekend tussen één en tien. Indien dit nummer tussen één en negen ligt, wordt de bijhorende personenwagen opgehaald uit de bibliotheek. Volgens deze instellingen instelli is er dus negentig procent kans op een personenwagen. Indien het gekozen nummer tien is, wordt een nieuw willekeurig nummer berekend van één tot vijf.. Dit nummer zal bepalen welke vrachtwagen of bus er ingeladen wordt. Zodoende is er tien procent kans op een groter voertuig. Figuur 3-13 3 toont de negen personenwagens in de bibliotheek. Van elke wagen bestaat een versie met lichten en een versie zonder lichten. Figuur 314 geeft enkele grotere voertuigen weer.

Figuur 3-13:: De personenwagens in de bibliotheek bibl

39

Figuur 3-14:: Enkele grotere voertuigen uit de bibliotheek

3.3.4

Uni- of bidirectioneel verkeer

De gebruiker moet de keuze krijgen om unidirectioneel verkeer of bidirectioneel verkeer door de tunnel te sturen. Indien de gebruiker kiest voor eenrichtingsverkeer, eenrichtingsverkeer, kan nog worden ingesteld of het verkeer inkomend of weggaand moet zijn.

Figuur 3-15:: Een bidirectionele verkeersstroom

Om tweerichtingsverkeer op te bouwen wordt in de for-lus for lus die de verkeersstroom genereert, eerst de rechter helft van de rijvakken gevuld met normaal, weggaand verkeer. Daarna wordt de linkerhelft gevuld met toekomend verkeer. Het traject dat de wagens volgen is identiek maar heeft een tegengestelde zin. Codevoorbeeld 3-6 3 geeft weer hoe dit in Python geïmplementeerd wordt. Dee resultaten van de methode worden geïllustreerd aan de hand van figuren f 3-16 en 3-17.

40

import Blender from Blender import Object pad = Object.Get(‘Baan’) pad.switchDirection() .switchDirection() Codevoorbeeld 3-6:: De zin van een traject inverteren

Figuur 3-16: Voorbeeld d van een pad in Blender

Figuur 3-17:: Resultaat van de methode switchDirection() op een pad

De methode switchDirection() heeft als gevolg dat de wagen verbonden aan het pad, in de tegengestelde richting zal rijden. Aan het traject zelf wordt niets gewijzigd. gewi Aangezien de rechter helft van de rijvakken weggaand verkeer heeft en de linker helft toekomend verkeer, kan bidirectioneel verkeer enkel toegepast worden op situaties met een even aantal rijvakken. Wanneer de gebruiker eenrichtingsverkeer instelt, mag het aantal rijvakken ook oneven zijn.

41

3.4 Stops event vindt plaats wanneer een aantal wagens plots stopt op een bepaald rijvak. Op Een stopevent de andere rijvakken blijft gewoon free flow verkeer rijden. Auto’s die kunnen veranderen van rijvak is voor or Traficon geen vereiste. Zoals reeds vermeld bij de bespreking van het genereren van free flow, is het onmogelijk om automatisch interactie te hebben tussen voertuigen op een bepaald frame. In Blender kan een wagen niet vanzelf vertragen indien de wagen voor hem op een bepaald tijdstip vertraagt. vertraagt. De enige mogelijkheid is om vooraf alle acties te gaan definiëren via een snelheidsbeschrijving. Zo kan een simulatie van een stop gemaakt worden door aan een aantal wagens een specifieke snelheidsbeschrijving te geven. De gebruiker moet volgende parameters kunnen instellen omtrent het stopevent: Tabel 3-3: Parameters bij het stopevent stop

Parameters
Positie van het event (in meter, ten opzichte van de camera)
Rijvak waarop de stop gebeurt
Start van het event
Einde van het event
Onderlinge afstand tussen de wagens
Aantal wagens die deelnemen aan het event Snelheidscurve De snelheidsbeschrijving van een wagen die midden op het traject vertraagt, stopt en weer er aanzet, wordt weergegeven in figuur 3-18. 3 Dit is in tegenstelling stelling tot bij free flow geen lineair verloop meer. Op frame 32 zal de wagen beginnen aan het traject, met een constante snelheid. Daarvoor stond de wagen stil, in het begin van de tunnel. tunnel. Dankzij de layerbeschrijving is deze wachtende wagen echter onzichtbaar onzic op de rendering. Op frame 56 zal de wagen beginnen vertragen. Op frame 100 verandert de positie van de wagen niet meer. Dit wil dus zeggen dat de auto stil staat. 54 frames later versnelt de wagen geleidelijk aan weer om op frame 198 terug aan constante ante snelheid de rest van het traject af te leggen.

Figuur 3-18: Snelheidsbeschrijving voor een stoppende auto

42

Om nu het stopevent in te stellen naar de wensen van de gebruiker kan deze snelheidsbeschrijving aangepast worden, net zoals bij het genereren genereren van free flow gebeurt. De initiële helling van de curve is de snelheid waarmee de wagen vertrekt. Deze snelheid moet exact gelijk zijn aan de snelheid van het andere verkeer op dat rijvak. Het moment waarop de wagen vertrekt kan worden uitgesteld door de volledige curve te verschuiven naar rechts. De tijd dat de wagen stilstaat in de tunnel kan eveneens verlengd worden door het horizontale stuk van de curve langer te maken.

3.4.1

Positie

oor een offset te gaan Het rijvak waarop het stopevent plaatsvindt is gemakkelijk instelbaar door bepalen ten opzichte van het pad. De positie waar de wagen stopt in de tunnel is instelbaar door de snelheidsbeschrijving te veranderen. Een wagen die een beschrijving als in figuur 3-18 3 gekregen heeft zal aan 50% van het traject stoppen. stoppen. Wanneer een tunnel honderd meter lang is, dan zal de wagen vertragen en stilstaan na vijftig meter. Een wagen die een snelheidsbeschrijving als in figuur 3-19 gekregen heeft, zal aan 80% van het traject stoppen. Dit is dus na tachtig meter in een tunnel nel van honderd meter. Het instellen van de positie van de stop kan dus door de curve in zijn geheel naar boven of naar onder te verschuiven.

Figuur 3-19:: Een tweede snelheidsbeschrijving voor een stoppende auto

In de uitgewerkte applicatie heeft de gebruiker de mogelijkheid om de plaats van het event in meter uit te drukken, ten opzichte van de camera. Volgende formule zet de gebruikersinstelling (in meter) om in een procent.

Formule 3-5: Omrekenen van de stoppositie

43

De formule resulteert in een n procent dat gebruikt kan worden om de snelheidsbeschrijving mee in te stellen. Het maakt gebruik van de huidige camerapositie (in meter) en de gekozen stoppositie ten opzichte van de camera (in meter). Figuren 3-20 en 3-21 illustreren de werking van de positie nog eens. Figuur 3--21 toont de snelheidsbeschrijving van de wagen. Uit de hoogte van het horizontaal gedeelte weet men dat de bijhorende wagen aan 50 % van het traject zal stoppen. Figuur 3-20 bevestigt dit.

Figuur 3-20: Wagen die aan 50% van het he traject stopt

Figuur 3-21:: De snelheidsbeschrijving bij figuur 3-20 3

3.4.2

Rijvak van het event

Het rijvak (niet te verwarren met de eerder ingestelde positie) waarop de stop plaatsvindt kan eenvoudig ingesteld worden door de wagen een bepaalde offset te geven geven ten opzichte van zijn pad. Dit verloopt volledig analoog als bij het instellen van het rijvak van free flow verkeer.

44

3.4.3

Start van het event

Ook de aanvang van het event kan ingesteld worden aan de hand van de snelheidsbeschrijving. Wanneer figuur 3-18 opnieuw beschouwd wordt, blijkt dat de wagen vertrekt op frame 32. Het effectieve stilstaan begint op frame 100. Door dit punt te verleggen wordt ook het moment waarop het stopevent plaatsvindt, veranderd. Zodoende kan men vanuit Pythoncode de snelheidscurve zo manipuleren zodat het stopevent zou voldoen aan de gebruikerswensen.

Figuur 3-18: Snelheidsbeschrijving voor een stoppende auto

3.4.4

Einde van het event

Door de laatste drie punten van de snelheidscurve te verschuiven, wordt de duur dat de wagen stil staat veranderd. Zo kan afhankelijk van de gebruikerswensen de duur van de stop ingesteld worden in de snelheidscurve. Bij figuur 3-18 duurt de stop 54 frames (van frame 100 tot frame 154). Wanneer de gebruiker de stopduur in seconden instelt dan kan het interval berekend worden aan de hand van het ingestelde aantal frames per seconde. Wanneer het aantal FPS gelijk is aan 25, dan duurt een interval van 54 frames net iets meer dan twee seconden.

3.4.5

Afstand tussen stopauto’s

De wagen die na een stilstaande auto komt moet ook stoppen, om een botsing te vermijden. Het is onmogelijk om op het moment zelf nog in te grijpen. Wanneer op een bepaald frame een wagen stopt, is de animatie al gestart en kan het gedrag van de volgende wagen niet meer veranderd worden. De enige optie is om vooraf de volgende wagens ook al van een aangepaste snelheidscurve te voorzien. De curve is grotendeels gelijk aan die van de eerste wagen. De initiële snelheid waarmee beide wagens vertrekken en de duur van het interval is gelijk. Er zijn echter twee verschillen. Ten eerste is voor de volgende wagen het moment van vertrek iets later. Dit komt er dus op neer dat zijn volledige snelheidscurve iets meer verschoven ligt naar rechts, afhankelijk van het door de gebruiker ingestelde debiet. Ten tweede mag de volgende wagen niet op exact dezelfde positie stoppen als de eerste wagen. De wagen moet enkele meters tussen

45

laten. Dit betekent dus dat de snelheidscurve van de tweede wagen iets lager moet liggen. Zodoende stopt deze wagen procentueel gezien iets vroeger op het traject. Formule 3-6 geeft het verband tussen de stoppositie (van de tweede wagen) en de tussenafstand. Hierbij is Stoppositie1 de ingestelde plaats van de eerste wagen, in meter ten opzichte van de camera. Het resultaat is de stoppositie voor de tweede wagen. Wanneer deze gedeeld wordt door de baanlengte kan dit procent gebruikt worden om de snelheidscurve in te stellen. De stoppositie van een derde wagen kan op analoge wijze berekend worden. 2 1 ! "#$ Formule 3-6: Berekening van de stoppositie voor de volgende wagen

3.4.6

Aantal stoppende auto’s

Om meerdere auto’s na elkaar te laten stoppen wordt gebruik gemaakt van een for-lus. De snelheidsbeschrijvingen van de verschillende auto’s zullen immers gelijkaardig zijn. Zodoende kan een algoritme dat de gebruikersinstellingen vertaalt naar een snelheidscurve meermaals herhaald worden om auto’s te plaatsen die na elkaar stoppen. Hierbij moet telkens enkel nog het moment van vertrek en de stoppositie aangepast worden, afhankelijk van welke auto geplaatst wordt. Nadat het gevraagde aantal stopauto’s geleverd is mag er even geen free flow verkeer meer komen op dat rijvak. Indien er nog een extra free flow wagen zou vertrekken zou die botsen met de stilstaande stopwagens. Bij de generatie van free flow verkeer moet er dus extra op gelet worden dat er bij het moment van vertrek geen stopauto’s stilstaan op dat rijvak. Dit kan door bij het genereren van free flow verkeer het geplande startframe van een wagen te vergelijken met het tijdsinterval waarin het stopevent plaatsvindt. De wagen mag niet vertrekken tijdens zo’n tijdsinterval indien de wagen voor het rijvak van het stopevent bestemd is. Het script zal dan volgens het ingestelde debiet het startframe van de volgende normale wagen berekenen en opnieuw de controle uitvoeren. Wanneer een gepland startframe niet meer in het stopinterval ligt dan mag de normale wagen wel weer door de tunnel rijden, omdat de stopauto’s dan weer vertrokken zijn. Een wagen mag natuurlijk ook vertrekken indien hij zich op een ander, leeg rijvak bevindt. Volgend codevoorbeeld illustreert de controle. Deze gebeurt in de for-lus die het free flow verkeer genereert. Elke keer de lus uitgevoerd wordt verhoogt het frame (genaamd AutoFrame2) waarop de nieuwe wagen mag vertrekken. Dit gebeurt aan de hand van de gauss-verdeling. for i in range(0,20): AutoFrame2 = AutoFrame2 + gauss(…) if (AutoFrame2 < BeginStop or AutoFrame2 > EindStop) # geldige wagen else: # stop bezig, wagen mag niet vertrekken Codevoorbeeld 3-7: Opletten voor stopevents tijdens het genereren van free flow

46

In Python wordt een commentaar aangeduid met een #-teken. BeginStop en EindStop zijn de grenzen van het tijdsinterval val waarin het stopevent plaatsvindt. Beginstop is het moment waarop de eerste stopwagen vertraagt. EindStop is het moment dat de laatste stopwagen weer aanzet. Tijdens dit tijdsinterval interval mag er geen gewoon verkeer meer gestuurd gestuurd worden op dit rijvak, om botsingen te voorkomen. Het script vraagt de waarden voor BeginStop en EindStop op nadat de stopauto’s auto’s hun snelheidsbeschrijving gekregen hebben. Pas nadatt het script de ingestelde stopevents events gegenereerd heeft, wordt er free flow flow gegenereerd om de verkeersstroom mee aan te vullen. Free flow kan pas op het einde gegenereerd worden omdat dan pas het tijdsinterval van de stopevents bekend is.

3.4.7

Extra’s

Om het stopevent event realistischer te maken zijn naast voorgenoemde elementen nog een aantal zaken toegevoegd. Deze zijn niet noodzakelijk om de goeie werking van een stop te garanderen maar geven wel een extra waarde waardoor het geheel realistischer overkomt. overkomt Layer Ten eerste krijgt elke stoppende auto ook een layerbeschrijving zoals bij bi de free flow auto’s gebeurde. Deze layerbeschrijving gaat volledig analoog als bij het normale verkeer gaan bepalen wanneer een auto zichtbaar is en wanneer niet. Voor en na het afleggen van het traject staat de stopwagen op layer twee zodat deze niet mee gerenderd wordt. Achterlichten Ten tweede zijn ook achterlichten toegevoegd aan de wagens. Deze lichten op wanneer de auto remt. Wanneer opnieuw figuur 3-18 3 beschouwd wordt, is het duidelijk dat de wagen vertraagt tussen punt twee en punt drie. Van framee 56 tot frame 100 moeten dus stoplichten zichtbaar zijn. Het plots verschijnen van deze lichten vanaf een bepaald frame kan enkel ingesteld worden door de lichten een layerbeschrijving te geven. Figuur 3-22 3 illustreert dit.

Figuur 3-22: De layerbeschrijving rijving van de stoplampen

47

Figuur 3-23:: De stoplichten

Figuur 3-23 geeft het resultaat weer. De wagen dichtst bij de camera is aan het remmen voor de twee wagens voor hem die stil staan. Tijdens het remmen is duidelijk een rode gloed zichtbaar, veroorzaakt akt door de stoplichten. Knipperlichten Een derde toegevoegd extra is het gebruik van knipperlichten. knipperlichten Het script zorgt er voor dat de eerste auto die op een rijvak stopt, alle vier de knipperlichten laat werken. werken Dit gebeurt enkel tijdens het stil staan zelf. z Om dit te implementeren moet opnieuw gewerkt worden met een layercurve. Toegepast voor de situatie in Figuur 3-18 3 zou de layerbeschrijving rbeschrijving er uitzien uit als in figuur 3-24. Vanaf frame 100 tot aan frame 154 zullen de knipperlichten afwisselend zichtbaar en onzichtbaar zijn. Dit is het tijdsinterval interval waarin de wagen stil staat.

Figuur 3-24:: Layercurve van knipperlichten

48

Het maken van een dergelijke layercurve kan zoals weergegeven in volgende code. hoogte1 = 1 frame1 = BeginFrame while (frame1 < EindFrame): frame1 = frame1 + Fps/2 KnipperLayer.append(hoogte1) if hoogte1 == 1: hoogte1 = 2 else: hoogte1 = 1 Codevoorbeeld 3-8: Maken van een layercurve voor een knipperlicht

Het opbouwen van de layercurve gebeurt met behulp van een while-lus. BeginFrame en EndFrame zijn de grenswaarden van het tijdsinterval waarin de auto effectief stil staat. Frame1 wordt, beginnende vanaf de waarde van BeginFrame, telkens verhoogt met FPS/2 zodat per seconde het knipperlicht één keer aan en uit gaat. Op de plaats van Frame1 wordt nu aan de layercurve KnipperLayer een punt toegevoegd (via de methode append) met hoogte gelijk aan hoogte1. Als frame1 nu telkens verhoogt en hoogte1 telkens afwisselt tussen de waardes 1 en 2, wordt nu een knipperend effect gecreëerd. Dit gaat door tot de waarde van frame1 groter is dan EindFrame. Vanaf dan vertrekt de stopauto weer en moet er niet meer geknipperd worden. Nadat een dergelijke layercurve opgebouwd is moet deze curve nog toegewezen worden aan de vier knipperlichten van de wagen. De wagen zit samen met al zijn lichten in één groep. Volgend codevoorbeeld gaat de layercurve toekennen aan enkel de vier knipperlichten. group1 = Blender.Group.Get(‘WagenGroep5’) for obj in group1.objects: naam1 = obj.name if naam1[0:6] == 'Oranje': obj.setIpo(KnipperLayer) Codevoorbeeld 3-9: Toekennen van de layercurve aan een object

Er wordt gebruik gemaakt van een foreach-lus. Deze gaat elk object in een groep overlopen. De behandelde groep heet group1 en bevat een wagen met al zijn lichten. In de lus wordt eerst de naam van het element opgevraagd. Vervolgens wordt gekeken naar de eerste zes letters van de naam. De knipperlichten hebben allemaal een naam van de vorm “OranjeLamp.XXX”, waarbij het suffix “XXX” een uniek getal is. Wanneer de naam van een element begint met ‘Oranje’ betekent dit dat het element een knipperlicht is. Dus moet het de layercurve toegekend krijgen. Dit kan met de methode setIpo(). Op analoge manier wordt ook een aangepaste layercurve aan de stoplichten toegekend. Hierbij wordt niet meer gezocht naar ‘Oranje’ in de naam maar naar ‘Rode’. De stoplichten hebben immers een naam van de vorm ‘RodeLamp.XXX’.

49

Debiet Om het vormen van een dergelijke rij van gestopte auto’s natuurlijk en vlot te laten overkomen wordt ook kort ingegrepen. Indien het debiet van de bijhorende free flow wagens te klein is dan wordt dit voor de stopwagens aangepast. Zodoende moet de eerste stopwagen niet eindeloos wachten tot de volgende stopwagen zich in de rij vervoegt. Controle Een laatste toegevoegd detail is een extra controle. Indien de gebruiker instelt om twee stops op het zelfde moment en op het zelfde rijvak te laten plaatsvinden, dan zullen de gecreëerde stops tegen elkaar botsen. Er wordt wel rekening gehouden dat er geen free flow meer rijdt op dat interval, maar de gebruiker kan nog steeds twee stops door elkaar zetten. Dit wordt opgelost door een extra controle in te voeren. Iedere keer dat een stopevent gegenereerd is wordt het resulterende tijdsinterval (begin- en eindframe van het stopevent) vergeleken met de bestaande intervals van vorige stopevents. Indien er enige overlapping optreedt tussen deze intervals en het event op het zelfde rijvak plaatsvindt, dan wordt deze pas geplaatste stopevent verwijderd uit de scene. Zodoende zullen er nooit twee stopevents door elkaar optreden. Indien de events zich op een verschillend rijvak of een verschillend tijdstip voordoen is er natuurlijk geen probleem.

3.5 Files Het file-event lijkt goed op het stopevent. Er is slechts één extra parameter, namelijk de snelheid van de filewagens. Daar waar de wagens bij een stopevent vertragen om volledig stil te staan, gaan de filewagens vertragen en voor een bepaalde duur aan een tragere, constante snelheid rijden. Een stopevent kan ook beschouwd worden als een file met snelheid nul. Dit wil zeggen dat een groot deel van de code in het uiteindelijke script hergebruikt kan worden. De methodes die een file genereren kunnen grotendeels ook ingezet worden bij het creëren van een stopevent. Hierbij is enkel de snelheidscurve verschillend. Verder moeten zowat alle parameters op gelijkaardige wijze ingesteld worden. Tabel 3-4: Parameters bij het file-event

Parameters
Positie van het event (in meter, ten opzichte van de camera)
Rijvak waarop de file plaatsvindt
Start van het event
Einde van het event
Snelheid van de filerijdende auto’s
Onderlinge afstand tussen de wagens
Aantal wagens die deelnemen aan het event

50

De bijhorende snelheidscurve ziet er als volgt uit.

Figuur 3-25: De snelheidscurve van een filewagen

Net zoals bij de stopcurve begint de filewagen op een bepaald moment met een constante snelheid. In figuur 3-25 vertrekt de wagen op frame 43. Vanaf frame 69 vertraagt de wagen om op frame 100 weer met een constante maar tragere snelheid vooruit te gaan. Op dit moment vindt dus de effectieve file plaats. Op frame 167 versnelt de auto weer en op frame 207 rijdt de auto weg met de initiële snelheid. Het enige verschil met een stopcurve is het interval van frame 100 tot 167. Hierbij gaat de wagen traag vooruit aan een constante snelheid, in plaats van stil te staan.

3.5.1

Positie

Het instellen van de positie waar het file-event plaatsvindt gebeurt volledig analoog als bij het instellen van het stopevent. Hoe hoger het deel van de curve ligt waarop de auto traag rijdt, hoe verder dit gebeurt op het traject. De gebruiker stelt de positie in in meter ten opzichte van de camera. De procentuele positie nodig voor het instellen van de snelheidscurve kan dan berekend worden aan de hand van formule 3-5.

3.5.2

Rijvak

Het instellen van het rijvak waarop het file-event moet gebeuren kan door de betreffende wagens een offset te geven ten opzichte van hun pad. Dit gebeurt op dezelfde wijze als bij het instellen van free flow verkeer of een stopevent.

3.5.3

Start en einde van het event

Beide kunnen ingesteld worden door het derde en het vierde punt in de snelheidscurve (zoals getoond op figuur 3-25) te verschuiven. Dit kan vanuit Python met dezelfde methodes als voor het instellen van een stopevent.

51

3.5.4

Snelheid van de filerijdende wagens

De helling van het lijnstuk gevormd door punt drie tot punt vier stelt de snelheid voor van de wagen. Indien dit stuk van de curve horizontaal ligt, staat de wagen stil. Hoe steiler de helling, hoe sneller de filewagen zal rijden. Figuur 3-26 geeft een snelheidscurve bestemd voor een filewagen die iets sneller rijdt dan bij figuur 3-25 het geval was. Hierbij is de helling tussen punt drie en punt vier steiler en dus de snelheid van de wagen hoger.

Figuur 3-26: Andere snelheidscurve van een filewagen

3.5.5

Onderlinge afstand tussen filewagens

Extra De tussenafstand bij filewagens is op dezelfde manier instelbaar als bij het stopevent. Door per wagen de absolute positie van het gebeuren vast te leggen kan de tussenafstand ingesteld worden. Bij de filewagens moet er echter een extra maatregel genomen worden. Eens een filewagen op positie is en aan filesnelheid rijdt, duurt het een korte tijd voor de volgende filewagen er is. Bij de stop is dit niet belangrijk, maar bij het file-event zal de afstand tussen de filewagens onderling groter zijn dan ingesteld. Dit komt doordat de filewagen al enkele meters afgelegd heeft alvorens de volgende filewagen deel neemt aan de file. Door van de ingestelde tussenafstand de nodige meters af te trekken kan het effect gecompenseerd worden. Zodoende zal het event toch voldoen aan de gebruikerseisen. Het aantal meter dat reeds werd afgelegd alvorens de tweede filewagen er is, wordt als volgt berekend.

Formule 3-7: Nodig bij het instellen van de onderlinge afstand tussen filewagens

Hierbij wordt de filesnelheid omgezet in m/s door te delen door 3.6. Vervolgens wordt gekeken hoeveel meter de eerste wagen aan deze snelheid aflegt in de tijd dat de tweede wagen nodig heeft om zich te vervoegen in het file-event. Deze tijd wordt berekend door de af te leggen afstand tot het filegebeuren te delen door de initiële snelheid van de wagen in m/s. De baanlengte vermenigvuldigd met de procentuele filepositie stelt de af te leggen afstand voor.

52

3.5.6

Aantal deelnemende wagens

Dit aantal iss gemakkelijk instelbaar vanuit Python code. Net zoals bij bij de implementatie van de stopevent event kan het aantal ingevuld worden in de bovengrens van de genererende for-lus. for Deze forlus herhaalt de methodes voor het creëren van een geschikte snelheidsbeschrijving snelheidsbeschrijv voor de bijhorende filewagen.

3.5.7

Extra’s

Aan het file event worden dezelfde extra’s toegekend als bij het stopevent. event. Elke filewagen krijgt een bijhorende layerbeschrijving die er voor zorgt dat de wagen niet zichtbaar is voor of na het afleggen van zijn n traject. Wanneer een wagen vertraagt dan verschijnen achteraan de stoplichten. De filewagens krijgen geen knipperlichten toegekend omdat geen enkele wagen een volledig stop doet. De extra controle waarbij gekeken wordt of er geen twee file-events file door elkaar kaar geplaatst zijn, wordt wel uitgevoerd.

3.5.8

Bijkomend probleem

Zowel bij het instellen van de snelheidsbeschrijving voor een filewagen als een stopwagen doet er zich een extra probleem voor.

Figuren 3-27 en 3-28: Bijkomend probleem p bij aanpassen van lineair stuk in snelheidscurve

53

Extra probleem Dit probleem doet zich voor bij het veranderen van de helling van een lineair stuk in de snelheidscurve. Het aanpassen van deze helling is nodig om de snelheid van de bijhorende wagen in te stellen. Figuur 3-27 geeft de standaard snelheidscurve weer voor een filewagen. Figuur 3-28 toont de curve waarbij de initiële snelheid verlaagd is. Dit komt er op neer dat de richting van het eerste lineaire stuk (punt één tot punt twee) in de snelheidscurve veranderd is. Zoals figuur 3-28 weergeeft is er nu een probleem met de kromming tussen punt twee en punt drie. Deze kromming is een optimale overgang tussen de verschillende snelheden in het geval van figuur 3-27. Wanneer een van deze snelheden echter aangepast wordt is de kromming geen goede overgang meer. Er kan getracht worden de kromming vanuit Python code automatisch aan te passen zodat deze een goede overgang zal garanderen. Het is echter onnodig complex om vanuit Python de handlers en de knots van de bijhorende Bézier triples aan te passen. Voor elke situatie is een andere kromming nodig die niet telkens absoluut bepaalbaar is. Om toch een goed resultaat te bekomen moet een alternatief gezocht worden. Herschalen Een eerste mogelijke oplossing is om de snelheidscurve the herschalen volgens de x-as. Zodoende wordt de helling van de curve veranderd. De kromme overgangen worden ook mee geschaald waardoor ze een optimale verbinding blijven. Het resultaat wordt getoond in figuur 3-30. Hierbij werd de curve in figuur 3-29 uitgerekt langs de x-as waardoor de initiële helling minder steil is. Een ongewenst neveneffect is dat het tweede lineaire stuk van de curve (het stuk dat de snelheid van het filerijden beschrijft) nu ook een minder steile helling heeft. Door de gehele curve uit te rekken verloopt het volledige event minder snel. Ook het vertragen voor het filerijden of het terug aanzetten na het event gebeurt een stuk trager. De kromming tussen de lineaire stukken blijft wel een vloeiende overgang. Herschalen kan dus gebruikt worden om de helling in te stellen. De bijkomende effecten zijn toelaatbaar.

Figuren 3-29 en 3-30: Uitrekken van de snelheidscurve langs de x-as

54

Vanuit de Blender GUI zelf kan elk object verschaald worden in elke gewenste richting. In Python daarentegen kunnen slechts een beperkt aantal objecttypes types een verschaling ondergaan. Er bestaat in de klasse van de interpolatiecurve geen methode die verschaling verzorgt. Het is dus onmogelijk om dit automatisch te laten verlopen vanuit het Python script. Dit is nochtans noodzakelijk voor het manipuleren van de snelheidscurves. Er moet dus een tweede alternatief gezocht worden. Tijdscurves Het uitrekken van een snelheidscurve kan ook bereikt worden met een extra interpolatiecurve, namelijk de tijdscurve. Figuren 3-31 en 3-32 zijn voorbeelden van dergelijke curves. Wanneer de tijdscurve uit figuur 3-31 3 samen met een snelheidscurve toegekend wordt aan een wagen dan heeft dit geen effect. Wanneer echter de curve uit figuur 3-32 3 wordt gebruikt dan zal de wagen halff zo snel rijden als de gegeven snelheidscurve aanduidt. Als de wagen normaal gezien na 100 frames vertrekt dan zal dit na toepassen van de tijdscurve uit figuur 3-32, 3 pas na 200 frames zijn. Met een dergelijke tijdscurve kan het gehele traject van een wagen wag vertraagd of versneld worden. Dit geeft hetzelfde elfde resultaat als wanneer de snelheidscurve verschaald zou worden. Verschalen van curves is echter onmogelijk vanuit Python code waardoor deze bijkomende tijdscurve vereist is.

Figuren 3-31 en 3-32: Voorbeelden oorbeelden van tijdscurves

Figuur 3-33:: De standaard beginsnelheid bij een snelheidscurve. snelheidscurv

55

Zoals de rode lijn in figuur 3-33 3 aantoont zou de bijhorende wagen, aan initiële snelheid, het traject afleggen in 80 frames. De getoonde snelheidsbeschrijving is de standaardcurve waaraan nog niets veranderd is. Door nu een tijdscurve toe te voegen aan de wagen kan de snelheid aangepast worden. Wanneer neer de baanlengte 80 meter is dan zal de wagen rijden aan een snelheid van één meter per frame. Wanneer een FPS ingesteld ingesteld wordt van 25 dan rijdt de wagen dus 25 m/s zijnde 90 km/h. Dit is het geval bij de standaard snelheidsbeschrijving. Om vertrekkende van deze snelheidscurve curve een wagen aan 60 km/h te laten rijden moet een tijdscurve curve toegevoegd worden die de wagen voor 66.6 % vertraagt. vertraagt Figuur 3-34 en formule 3-9 geven dit weer.

Figuur 3-34:: Een specifieke tijdsbeschrijving

Door deze extra tijdsbeschrijving op te leggen aan de wagen zal hij geen 90 km/h rijden maar 60 km/h. Op deze manier kan elke wagen de gevraagde gevra snelheid krijgen. De nodige tijdsvertraging kan berekend worden afhankelijk van de gewenste snelheid, de baanlengte en het ingestelde FPS. Volgende formule geeft het verband weer.

Formule 3-8:: Berekening van tijdsvertraging om snelheid in te stellen stell

De snelheid is in km/h en wordt omgezet omgeze naar m/s door te delen door 3.6. 6. Dit wordt gedeeld door het aantal FPS om te weten hoeveel meter de wagen aflegt per frame. Wanneer de baanlengte groter is dan 80 meter, dan legt de wagen het traject standaard toch to af in 80 frames, zoals vastgelegd door de initiële helling van de curve in figuur 3-33 3 . De wagen rijdt dus sneller. Om dit te compenseren wordt in formule 3-8 3 nog vermenigvuldigd met 80 en gedeeld door de baanlengte.

Formule 3-9:: Uitgewerkt voorbeeld voorbeeld van berekening van tijdsvertraging

56

Beperkingen Op deze manier wordt de beginsnelheid van de file- en stopwagens ingesteld. Dit is noodzakelijk opdat de kromming tussen de lineaire delen in de snelheidscurve optimaal zou blijven. Bijgevolg is de snelheid waarmee de wagen remt voor het filegebeuren en weer aanzet na de file, afhankelijk van de ingestelde initiële snelheid. Ook de snelheid van het filerijden zelf is niet meer absoluut te bepalen. De snelheid van een file is wel telkens beduidend lager dan de snelheid van de free flow wagens. De resulterende snelheid van de file ligt meestal tussen de vijf en de twintig km/h. Het volledige event komt vloeiend over dus is de afwijking aanvaardbaar. De gebruiker krijgt geen optie om de snelheid van de filerijdende wagens absoluut in te stellen. Bij het instellen van de snelheid van het free flow verkeer is er geen probleem omdat daar geen gebruik gemaakt wordt van tijdscurves. De snelheidscurve van een free flow wagen is gemakkelijk instelbaar vanuit Python code door een Bézier triple van de curve te verschuiven.

3.6 Vallend Object Tijdens het free flow verkeer valt er een kartonnen doos uit een wagen. Een aantal auto’s op dat rijvak moeten stoppen. Hierbij kan de gebruiker volgende parameters instellen. Tabel 3-5: Parameters bij een vallend object

Parameters
Rijvak waarop het event plaatsvindt
Tijdstip waarop het event gebeurt
Positie (in meter, ten opzichte van de camera) waar het object valt
Aantal wagens die stoppen In de bibliotheek zitten vier modellen van kartonnen dozen. Bij het genereren van een event met een vallend object wordt er een willekeurige doos gekozen. Zodoende wordt voor afwisseling gezorgd. Figuur 3-35 geeft de modellen weer.

Figuur 3-35: Vier zelfgemaakte modellen van een kartonnen doos

57

3.6.1

Vallende animatie

Animatie Om zo’n doos op een bepaald frame uit een wagen te laten vallen moet gebruik gemaakt worden van interpolatiecurves. Wanneer de doos uit een wagen valt dan vertrekt deze van op een hoogte van ongeveer één meter. Vervolgens moet deze d een meter naar beneden en enkele meters achteruit vallen ten opzichte van de rijdende wagen, en een draaiende beweging maken rond zijn x-as. as. Op deze manier lijkt het alsof de doos echt valt uit de wagen. De bijhorende beschrijvingscurves zien er als volgt vo uit.

Figuur 3-36: Beschrijving van de z-coördinaat z bij een vallende animatie

Figuur 3-37:: Beschrijving van de y-coördinaat y bij een vallende animatie

Figuur 3-38:: Beschrijving van de rotatie rond x-as bij een vallende animatie

De curve in figuur 3-36 zorgt er voor dat het object verandert van hoogte. De z-coördinaat z wordt gemanipuleerd. Vanaf frame 0 tot ongeveer frame 12 lijkt het object zo naar beneden te vallen. In de curve wordt rekening gehouden met de valversnelling waardoor een kwadratische kwadratis kromme ontstaat. Formule 3--10 geeft de bewegingsvergelijking weer.

58

Formule 3-10 10: De bewegingsvergelijking van een vallend object y positie bepaalt. Vanaf frame 0 vergroot de yy Figuur 3-37 geeft de curve weer die de y-positie coördinaat van het object, tot op frame 15. In combinatie met de beschrijving in figuur 3-36 3 gaat het object achteruit vallen. Om het object te laten draaien rond zijn x-as x as wordt gebruik gemaakt van de rotatiecurve in figuur 3-38. 3 . De curve zorgt ervoor dat het object van frame 0 tot frame 12, 360 graden rond zijn x-as as zal draaien. In Blender zijn nog twee andere curves instelbaar om de rotatie rond de y- en de z-as as te bepalen, maar deze zijn hier niet nodig. Met behulp van een rotatiecurve voor de x-as draait het object terwijl het van de wagen valt. De as waarrond dit gebeurt wordt weergegeven in figuur 3-39. 3 De rode as is de x-as, as, waarrond gedraaid wordt. De blauwe as is de z-as as en is belangrijk opdat het object naar beneden zou vallen. De groene as is de y-as as en is opnieuw belangrijk omdat omdat het object achteruit uit de wagen zou vallen.

Figuur 3-39: Assenstelsel van een vallend object

Het moment waarop de animatie plaatsvindt kan opnieuw bepaald worden door de interpolatiecurves te verschuiven. Wanneer de gebruiker wenst dat het event na drie minuten in de tunnel optreedt dan moeten de curves zo verschoven worden opdat de valanimatie val begint op frame 4500. Dit frame wordt berekend door het aantal seconden (3 minuten = 180 seconden) te vermenigvuldigen mett het aantal FPS (= 25). 25 Na een bepaald interval val moet de doos ook weer verdwijnen. nen. Het is niet de bedoeling dat eens de doos er ligt, er een eindeloze stopevent wordt opgebouwd. Het verdwijnen van de doos wordt ook ingesteld met interpolatiecurve van de d z-as. In figuur 3-40 wordt de volledige dige curve weergegeven. Hierbij zal het gevallen object op frame 100 onder het wegdek verdwijnen. De wagens die stopten voor de gevallen doos kunnen weer verder rijden.

Figuur 3-40: Beschrijving van de z-coördinaat z bij vallende animatie

59

3.6.2

Instellen van hett rijvak

Het rijvak waarop dit event plaatsvindt plaatsvindt is net als zoals alle andere events instelbaar door het object een offset te geven ten opzichte van zijn pad.

3.6.3

Tijdstip waarop het event gebeurt

Om het object later te laten vallen moeten de bijhorende interpolatiecurves interpolatiecurves verschoven worden naar rechts. De curves in figuren 3-36 3 tot 3-38 beschrijven een vallend object dat begint op frame 0. Wanneer de gebruiker een falling object event instelt dat moet optreden na exact één minuut, dan moeten de curves 1500 frames frames opgeschoven worden naar rechts. Dit komt overeen met 60 seconden indien met een FPS van 25 wordt gewerkt.

3.6.4

Positie waar het event plaatsvindt

Om in te stellen waar de doos exact zal vallen v moet een pad, een offset en een snelheidsbeschrijving gebruikt kt worden. Aan de hand van het pad en de gekregen offset kan de doos op eender welke plaats in het traject gedropt worden. De bijhorende snelheidscurve zal bepalen len hoe de doos het traject aflegt. aflegt In tegenstelling tot het verkeer moet de doos zich niet vanaff het begin tot het einde voort bewegen. Hij moet aan een bepaald percentage van het traject blijven liggen. Figuur 3-41 3 illustreert dit. In het voorbeeld ligt de doos op 80% van het tunneltraject. De doos heeft een offset gekregen van -4.5 meter zodat dezee op het meeste linkse rijvak ligt. De breedte van één rijvak is drie meter. Zoals in figuur 3-42 getoond wordt is de bijhorende snelheidsbeschrijving een rechte lijn. Zodoende legt de doos het traject niet af met een bepaalde snelheid, maar zal hij op een bepaalde positie in het traject gewoon blijven liggen. Wanneer nu nog de x- en y-positie positiecurves curves en de rotatiecurve (zoals in figuren 3-36 3 tot 3-38) gesuperponeerd worden op de snelheidscurve zal de animatie van de vallende doos zich afspelen op de ingestelde positie.

Figuur 3-41:: De procentuele positiebepaling van de doos

60

Figuur 3-42:: De snelheidsbeschrijving van een vallend object

De procentuele positie nodig om de snelheidsbeschrijving van het vallende object mee te bepalen kan berekend worden met dezelfde formule als bij de positiebepaling van filefile en stopevents. De gebruiker stelt in op hoeveel meter van de camera het event moet plaatsvinden. plaats Het in te stellen procent hangt af af van de lengte van het traject en van de camerapositie.

Formule 3-11: Omrekenen van de positie

3.6.5

Aantal wagens die stoppen

Het is de bedoeling dat er een aantal wagens stoppen na het gevallen object. Het is niet nodig om te kunnen veranderen van rijvak. Na een tijdje verdwijnt de doos door het wegdek en kunnen de wagens weer doorrijden. door De gebruiker kan bepalen hoeveel wagens er precies stoppen na het gevallen voorwerp. Dit stopevent stop dat volgt op het gevallen object kan toegevoegd worden aan de scene met de reeds ontworpen methodes. In deel 3.2 3.2 wordt uitgelegd hoe een stopevent st tot stand komt. Nog een stopevent stopevent toevoegen aan de scene kan gemakkelijk door dezelfde methodes nogmaals uit te voeren, zij het met nieuwe argumenten. Deze argumenten zijn het moment van aanvang, de duur, het aantal wagens enzovoort. Door deze argumenten zorgvuldig uit te kiezen kan een stopevent event gegenereerd worden dat ervoor zorgt dat een aantal wagens op het juiste moment voor de doos stoppen. Het moment waarop het stopevent event moet beginnen moet gelijk zijn aan het moment waarop de doos net op het wegdek ligt. Het stopevent stop moet even lang duren als de tijd die de doos blijft liggen. Zodoende vertrekken de wagens weer op het moment dat de doos door het wegdek verdwijnt. Het et toevoegen van een extra stopevent stop aan de huidige lijst van stopevents events kan gemakkelijk gema met de methode append(). Codevoorbeeld 3-10 3 geeft dit weer. De stopevents en de bijhorende parameters die vooraf door de gebruiker werden ingesteld, worden bijgehouden in een matrixstructuur matrix zoals weergegeven even wordt in codevoorbeeld 3-11. De parameters ers van de stopevents stop zitten dus in een lijst. Door te werken met een dergelijke structuur voor elke parameter staat er geen limiet meer op het aantal events. Ook kan er ten allen tijde nog een event toegevoegd worden, zoals nodig is na het gevallen object. object.

61

Special = append(Special, 'Stop') Rijvak = append(Rijvak, RijvakBox) StopDuur = append(StopDuur,DuurBox) BeginStop = append(BeginStop, BeginBox) TussenAfstandStop = append(TussenAfstandStop,2) AantalStopWagens = append(AantalStopWagens, WagensNaBox) StopSnelheid = append(StopSnelheid, 'Slow') StopPlaats = append(StopPlaats, BoxPositie) Codevoorbeeld 3-10: Het toevoegen van een extra stopevent

Special2 = [‘Stop’, ‘Stop’, ‘Stop’, ‘Stop’] Rijvak = [3,1,2,2] StopDuur = [20,15,34,28] # in seconden BeginStop = [100,50,80,23] # in seconden TussenAfstandStop = [2,3,2,4] # in meter AantalStopWagens = [8,10,13,6] # aantal StopPlaats = [20,40,35,65] # in meter Codevoorbeeld 3-11: Instellen van de stopevents via parameters

Codevoorbeeld 3-11 geeft weer hoe de stopevent met alle bijhorende parameters ingesteld wordt. De gebruiker kan deze instellingen definiëren in een front end. De werking ervan wordt uitgelegd in de verhandeling van Karel Azou. Deze front end gaat dan alle parameters invullen in het script. Vervolgens maakt het script gebruik van de gekregen parameters om de events mee te genereren. In een eerste stadium werd gewerkt met aparte variabelen voor elke parameter. Dit betekent dat er ook maar een beperkt, vast aantal stopevents kon ingesteld worden. Codevoorbeeld 3-12 illustreert dit. Special1 = ‘Stop’ Rijvak1 = 0 Stopduur1 = 20 BeginStop1 = 100 TussenAfstandStop1 = 2 AantalStopWagens1 = 8 StopPlaats1 = 20 Special2 = ‘Stop’ Rijvak2 = 0 Stopduur2 = 20 BeginStop2 = 100 TussenAfstandStop2 = 2 AantalStopWagens2 = 8 StopPlaats2 = 20 Codevoorbeeld 3-12: Oorspronkelijke definiëring van de eventparameters

62

Deze techniek werd aanvankelijk gebruikt maar heeft duidelijk enkele nadelen. Ten eerste kan de gebruiker niet meer dan twee stopevents instellen. Ten tweede wordt het ook moeilijker om bij het normale verkeer te controleren wanneer er al dan niet verkeer mag rijden op een rijvak. Een matrixstructuur kan algemeen doorlopen worden aan de hand van een for-lus en een index. Bij aparte variabelen kan dit niet en moet elk geval afzonderlijk bekeken worden. Door te werken met matrices kan de gebruiker om het even welk aantal stopevents gaan instellen en kan ook gemakkelijk nog een extra event toegevoegd worden met de methode append().

3.6.6

Doos moet uit een wagen vallen

Voorheen werd een animatie opgesteld die een doos laat vallen op een bepaald moment en plaats. Het vallen gebeurt van op een hoogte van één meter. Het is de bedoeling dat de doos uit een rijdende auto valt. Volgende code gaat dit verzorgen. Dit is een deel van de code die uitgevoerd wordt bij het genereren van free flow verkeer. Het is een for-lus die telkens een startframe (AutoFrame2) berekent waarop een geplande wagen vertrekt. De berekening gebeurt met de methode gauss(), op basis van het ingestelde debiet. Om grote extrema te vermijden in de afstand tussen de wagens onderling wordt het resultaat van de gauss() methode begrensd tussen GaussMin en GausMax. Op het einde van de code wordt het startmoment van de wagen opgeslagen in AutoFrame1. Wanneer de for-lus de code opnieuw herhaalt bevat AutoFrame1 dus het startframe van de vorige wagen. bHuidige en bSpecialBox stellen respectievelijk het rijvak voor dat de for-lus aan het vullen is en het rijvak waarop de doos ligt. Nu wordt tijdens het plaatsen van de wagen gekeken of deze terecht komt op het rijvak met de vallende doos. Indien dit het geval is wordt het startmoment van de wagen vergeleken met het moment waarop de doos begint te vallen. Indien het moment waarop de doos valt ligt tussen het startframe van de vorige wagen en het grootst mogelijke startframe voor de nieuwe wagen ( = AutoFrame1 + GaussMax), wordt het geplande startframe aangepast. De auto zal nu op de plaats van het falling object event passeren exact op het moment dat de doos valt. Zo lijk het alsof de doos uit de wagen valt. for i in range(0,AantalWagens): add = Gauss(Debiet) if add < GaussMin: add = GaussMin if add > GaussMax: add = GaussMax AutoFrame2 = AutoFrame2 + add if (bHuidige == bSpecialBox): if AutoFrame1 < BoxFrame and AutoFrame1 + GaussMax > BoxFrame: AutoFrame2 = BoxFrame AutoFrame1 = AutoFrame2 Codevoorbeeld 3-13: Aanpassen van normale wagen om falling object event te vervolledigen

63

Het uiteindelijke resultaat is een kartonnen doos die valt uit een rijdende jdende wagen Enkele wagens stoppen voor de doos. Nadat de doos verdwenen is rijden de wagens weer door. Figuur 3-43 geeft het eindresultaat weer.

Figuur 3-43:: Eindresultaat van een falling object event.

3.7 Spookrijders Een laatste mogelijke event is de spookrijder. Daarbij kan de gebruiker twee parameters instellen. De eerste bepaalt wanneer het event begint. Het tweede is het rijvak waarop het event moet plaatsvinden. Tabel 3-6:: De parameters bij een spookrijderevent

Parameters
Aanvang van het event
Rijvak ijvak waarop het event plaatsvindt

3.7.1

Aanvang van het event

Het moment waarop de wagen vertrekt wordt ingesteld zoals dat gebeurt bij het free flow verkeer. De spookrijder krijgt een pad en een snelheidsbeschrijving zoals in figuur 3-44. 3 Door de curve in zijn ijn geheel te verschuiven kan het moment waarop de wagen vertrekt veranderd worden. Ook de snelheid van de spookrijder kan veranderd worden door de helling van de curve aan te passen. Dit is dezelfde techniek als besproken bij de andere events. Het pad van de wagen wordt geïnverteerd met volgende code, zodat de wagen in de tegengestelde richting zou rijden. pad = Object.Get(‘Baan’) pad.switchDirection() .switchDirection() Codevoorbeeld 3-14: 14: De zin van een traject inverteren

64

Figuur 3-44: De snelheidsbeschrijving nelheidsbeschrijving van een spookrijder s

3.7.2

Rijvak waarop het event plaatsvindt

Het rijvak is gemakkelijk instelbaar op dezelfde manier als bij de andere events.

3.7.3

Extra’s

Layer Zoals bij de andere events krijgt de spookrijder ook een layercurve. Deze bepaalt wanneer de wagen op de actieve actieve layer staat. Zodoende verschijnt de wagen op het moment dat hij vertrekt. De wagen verdwijnt weer wanneer hij het traject volledig heeft afgelegd. Controle Bij het genereren van het free flow verkeer moet nu ook rekening gehouden worden met het spookrijderevent. ijderevent. Terwijl de spookrijder door de tunnel rijdt mag er geen normaal verkeer meer komen op dat rijvak om botsingen te voorkomen. Het normale verkeer wordt pas gecreëerd wanneer alle gewenste speciale events geplaatst zijn. Zo kan bij het normale verkeer rekening gehouden worden met de events. Er mag nooit een free flow wagen vertrekken wanneer op dat rijvak een event bezig is. Na het creëren van de spookrijderevent worden twee tijdwaardes bijgehouden. Het eerste is het frame waarop de spookrijder begint begint te rijden. Het tweede bevat het frame waarop de spookrijder de tunnel verlaat. Nu dit tijdsinterval bekend is kan het gebruikt worden tijdens het genereren van het free flow verkeer opdat er geen wagens zouden vertrekken terwijl er een event bezig is op o het rijvak. Op dezelfde manier worden bij filefile en stopevents dergelijke tijdsintervallen opgeslagen. Dit om ten allen tijde te voorkomen dat auto’s botsen. Blender is immers geen game engine en schademodellen van voertuigen vallen buiten het bestek van deze masterproef.

65

4. Maken van een realtime real 3D preview Om de gebruiker snel een idee te geven van hoe de tunnel met het gegenereerde verkeer er zal uitzien, wordt een realtime time 3D preview aangeboden. Deze preview bevat nog geen texturen texture of lichteffecten maar is wel realtime. time. Dit wil zeggen dat de gebruiker onmiddellijk bewegend verkeer ziet aan een snelheid van ongeveer 25 frames per seconde. Figuur 4-1 1 illustreert dit.

Figuur 4-1: 1: Beeld uit de realtime real 3D preview

Nadat de scene met het verkeer gegenereerd gegenereerd is volgens de wensen van de gebruiker, wordt deze opgeslagen in een Blender-bestand Blender genaamd Result.blend. Vervolgens wordt de scene voorbereid om de gebruiker de preview te geven. Hierbij worden onder andere de lichtobjecten verwijderd aangezien er toch geen lichteffecten getoond worden. Om de scene te renderen wordt gebruik gemaakt van het opgeslagen bestand Result.blend. Scene aanpassen Wanneer de gebruiker in de front end op “Preview”” klikt, klikt wordt het resultaat getoond in een nieuw venster. Dit is het Blender programma zelf dat opgestart wordt. Blender bevat een 3D-scherm scherm zoals weergegeven in figuur 4-1, 4 waarin de scene realtime getoond wordt. Het is geen vereiste om dit 3D-scherm te integreren in de front end zelf, maar dit is wel mogelijk. Blender der is immers volledig open source. Het programma is geschreven in C. Het zou dus mogelijk zijn om de functionaliteit die er voor zorgt dat de scene in 3D getoond wordt, over te nemen en te integreren in de GUI. Dit is echter vrij complex en valt buiten de de scope van de masterproef. Het aangeboden alternatief biedt dezelfde waarde. Het getoonde venster wordt immers beperkt tot enkel de 3D view en de tijdslijn.

66

Zo ondervindt de gebruiker geen last van alle andere opties en vensters die anders in Blender aanwezig zijn. Blender opstarten in een specifieke venstergrootte kan aan de hand van opstartparameters. Codevoorbeeld 4-1 beeldt dit uit. Na de parameter “-p” wordt de gewenste hoogte en breedte meegegeven. >> Blender.exe –p 800 600 Codevoorbeeld 4-1: Blender opstarten in een kleiner venster

Volgend codevoorbeeld gaat de gegenereerde scene voorbereiden zodat deze getoond kan worden aan de gebruiker. scn = Scene.GetCurrent() lichtpad = Object.Get('LightPath') scn.objects.unlink(lichtpad) for obj in scn.objects: obj.restrictSelect = True obj.setDrawType(3) name = obj.name if (name[0:4] == 'Lamp'): scn.objects.unlink(obj) Blender.Window.RedrawAll() Blender.Window.CameraView() Blender.Set("curframe",1) Codevoorbeeld 4-2: Het voorbereiden van een realtime 3D preview

De methode scene.objects.unlink(objectnaam) zal de link tussen het object en de scene verwijderen. Zodoende is het object niet meer zichtbaar in de scene. Eerst wordt het object LightPath verwijderd waardoor de muurverlichting die dit pad volgt, ook verwijderd wordt. Aan de hand van een for-lus worden vervolgens alle objecten in de scene overlopen. Bij elk object in de huidige scene wordt het attribuut restrictSelect op “True” gezet. Dit zorgt er voor dat de gebruiker geen objecten kan selecteren in de getoonde preview. Het is niet de bedoeling dat de gebruiker objecten verplaatst of aanpast in de preview. De preview is er enkel om de gebruiker een idee te geven van hoe het verkeer er uit ziet. Daarna wordt van alle objecten het tekentype op ‘Solid’ gezet. Dit kan door met de methode setDrawType(). De waarde 3 zorgt voor het ‘Solid’ tekentype. Wanneer dit niet gedaan wordt krijgt de gebruiker de objecten te zien in het tekentype ‘WireFrame’, wat niet de bedoeling is. Vervolgens worden de namen van alle objecten in de huidige scene overlopen. Wanneer de eerste vier letters gelijk zijn aan “Lamp”, mag het object niet getoond worden in de scene. Vermits er in de realtime preview geen lichteffecten aanwezig zijn, is het ook niet nodig dat de gebruiker de lampobjecten ziet.

67

Figuur 4-2 2 illustreert het verschil tussen een auto met lampobjecten en een auto zonder. De lampobjecten zijn in het groen getekend en zijn in de preview enkel storend voor de gebruiker.

Figuur 4-2: 2: Een auto met lampobjecten en een auto zonder

Nadat alle aanpassingen doorgevoerd zijn, wordt het 3D-scherm geüpdatet met de methode Window.RedrawAll(). Daarna wordt het 3D-scherm 3D gevuld met het zicht van de camera via de methode Window.CameraView(). ow.CameraView(). Ten slotte wordt het eerste frame van de animatie gezet als het huidige getoonde beeld met de methode Blender.Set("curframe",1). De scene is nu volledig omgebouwd om door de gebruiker beschouwd te kunnen worden als preview. De gebruiker zelf kan geen objecten meer selecteren en kan geen dingen veranderen in de scene. Hij kan wel de animatie laten afspelen en kan sprongen maken in de tijd aan de hand van de tijdsas.. Storende elementen zoals lampobjecten zijn uit de scene verwijderd. Door de 3D preview te laten gebeuren in een venster van Blender zelf wordt veel werk uitgespaard.

68

5. Opstellen van de render farm Infrastructuur Om de rendertijd in te korten kan gebruikt gemaakt worden van een render farm. Dit betekent dat meerdere computers tegelijkertijd aan eenzelfde filmpje zullen werken. Ze krijgen elk de opdracht van een master om een aantal frames te renderen. De PC’s die renderen heten slaves. Wanneer het werk verdeeld wordt onder tien computers die elk een deel van de frames renderen, wordt de rendertijd ongeveer gedecimeerd. Daarvoor moet dan wel geïnvesteerd worden in infrastructuur. Er moeten computers aangekocht worden met een degelijke CPU. Er moet ook een netwerk aangelegd worden dat de PC’s met elkaar verbindt. Er bestaan tools om de taakverdeling automatisch te laten verlopen. De tool die verkend werd heet FarmerJoe en is volledig gratis. Deze applicatie runt op de master PC. De master PC fungeert als een server en is in een LAN-netwerk verbonden met de slaves. Naast de FarmerJoe applicatie moeten ook Blender en Python geïnstalleerd zijn op de master PC. Volgende figuur illustreert het principe. De figuur komt uit een paper van Morisson, G. (2009), die uitlegt hoe men een render farm met FarmerJoe kan optimaliseren.

Figuur 5-1: De architectuur van een render farm volgens Morisson, G.

69

In het geval van FarmerJoe moet er op de slave computers geen extra software geïnstalleerd worden. Er moet enkel een netwerklocatie toegevoegd worden. Figuur 5-2 geeft weer hoe dit gebeurt.

Figuur 5-2: Toevoegen van een netwerklocatie

De toegevoegde netwerklocatie “\\Master\Farmerjoe_0.1.3” wordt voorgesteld met de letter “R:\” op elke slave. De netwerknaam van de master computer is “Master”. Deze bevat een gedeelde map genaamd “Farmerjoe_0.1.3”. Op deze locatie staan FarmerJoe en Blender geïnstalleerd. De slave kan in deze netwerklocatie browsen en FarmerJoe opstarten. FarmerJoe kan opgestart worden in twee modi. Voor de slave PC’s is het de bedoeling dat de slave modus gestart wordt. Dit kan met de opstartparameter --slave. Op de server zelf moet FarmerJoe opgestart worden onder de master modus. Dit gebeurt met de parameter --master. Codevoorbeeld 5-1 toont aan hoe dit werkt. >> FarmerJoe.exe --slave >> FarmerJoe.exe --master Codevoorbeeld 5-1: FarmerJoe opstarten in slave of in master modus.

Taakverdeling Nu kan vanaf een computer in het netwerk een taak toegevoegd worden. Dit gebeurt door de te renderen scene te openen in Blender en vervolgens submit.py uit te voeren. Dit is een Python script dat een taak gaat toevoegen aan FarmerJoe. De taak houdt in dat de gekozen scene gerenderd moet worden van het ingestelde startframe tot het eindframe. Er kan ook ingesteld worden hoeveel frames elke slave moet doen. Wanneer een slave een taak krijgt wordt de volledige scene (die vaak enkele honderden megabytes groot is) doorgestuurd over het netwerk. Om het netwerk niet te veel te belasten wordt geopteerd om elke slave per taak een vijftigtal frames te laten doen. Het is niet rendabel om de slaves een taak te geven van één frame. Wanneer een slave rendert wordt het frame opgeslagen naar de jobmap die zich op de master PC bevindt. Zo wordt het werk van de slaves centraal verzameld. Dit gebeurt niet op externe harde schijf zoals voorgesteld op figuur 5-1, maar op de harde schijf van de master PC zelf.

70

Werkstatus De gebruiker kan het verloop opvolgen via de appserver. Deze is ingebouwd in FarmerJoe en wordt gestart met volgende parameter. De appserver runt op de master server en kan geraadpleegd raadpleegd worden door in een webbrowser (verbonden met het LAN-netwerk) netwerk) te surfen naar http://master:2007.. Hier krijgt de gebruiker een overzicht te zien van de slaves en de jobs. Van elke slave wordt de status weergegeven. Deze kan “Idle” of “Rendering” zijn. Bij elke job kan de status van de aparte frames bekeken worden. De status is “Done”, “Rendering” of “Pending”. Deze laatste status betekent dat het frame nog niet als taak uitgedeeld werd aan een slave. >> FarmerJoe.exe --appserver Codevoorbeeld 5-2: De appserver van FarmerJoe opstarten

Figuur 5-3: De opgestelde render farm in het PIH

Praktisch In het PIH werd een kleine render farm opgesteld met de PC’s aanwezig in i het computerlokaal. Figuur 5-3 geeft dit weer. In de opgestelde render farm staan n een twintigtal computers ter beschikking. Elke PC doet er gemiddeld twee à drie minuten over om een e frame te renderen. Figuur 5-4 geeft een overzicht weer van de nodige CPU-tijd CPU tijd voor het renderen van telkens één frame van een animatie. De animatie is in totaal 600 frames lang. De rendertijd kan oplopen tot ongeveer tien minuten, afhankelijk van de complexiteit van de verkeerssituatie in de scene.

Figuur 5-4:: De rendertijden (in minuten) voor 600 frames

71

6. Validatie Nu de verkeersgenerator op punt staat wordt deze gecombineerd met de tunnelgenerator van Frédérique Vanneste. Dit is ook een script dat de gewenste tunnelomgeving opbouwt in Blender. Beiden worden aangestuurd door de front end, ontwikkeld en besproken door Karel Azou. De gebruiker kan met het afgewerkte product alle gewenste eigenschappen van een tunnelsituatie instellen in de GUI. Vervolgens wordt een 3D-scene 3D scene gecreëerd die voldoet aan deze eisen. Na renderen (eventueel via een render farm)) resulteert dit in een fotorealistisch fotoreal filmpje. Daarnaast worden ook de bijhorende referentiegegevens referentie afgeleverd. Hierin staan alle speciale events met bijhorend tijdstip gedocumenteerd. Stopdetectie Traficon kan nu detectiealgoritmes uittesten op het verkregen videomateriaal. Het resultaat van de detectietesten testen kan vergeleken worden met de bijgeleverde referentiedata. Zodoende kan gemeten worden in hoeverre het algoritme correct events detecteert. Afbeelding 6-1 1 illustreert de detectie toegepast op een gegenereerd filmpje. Op het beeld van de tunnel worden bepaalde zones aangeduid met een configuratietool. Zodoende weet het algoritme waar de rijvakken liggen. De stoppende wagens op het rechter rijvak worden correct gedetecteerd. Op het scherm wordt de “bounding box” van de stilstaande wagen getekend en wordt word de tekst “STOP ALARM: 4”” weergegeven. Daarbij is 4 het nummer van het meest rechtse rijvak. rijvak De getekende bounding box omhult niet alle stilstaande auto’s en is dus gedeeltelijk verkeerd. Dit is te wijten aan een foutieve configuratie van de detectietool voor deze specifieke tunnelsituatie. tunnelsituatie Het kan er echter ook op wijzen dat het uitgeteste detectiealgoritme nog niet volledig op punt staat.

Figuur 6-1: 1: Een detectietest op gegenereerd beeldmateriaal

72

Figuur 6-2:: Gedetecteerde spookrijder in een gegenereerd gegenereer filmpje

Spookrijderdetectie Figuur 6-2 6 illustreert een correct gedetecteerde spookrijder. De tekst “INV DIR: 3” wordt op het scherm weergegeven en betekent dat er zich een spookrijder (“inverse ( direction” in het Engels)) op rijvak 3 bevindt. Op ditzelfde rijvak wordt later in het filmpje onterecht nog een spookrijder gedetecteerd zoals figuur 6-3 6 aantoont.

Figuur 6-3: 3: Valse detectie van een spookrijder

73

Deze valse detectie wordt veroorzaakt door de passerende bus op rijvak 2. De bus is een hoog voertuig waardoor ook rijvak 3 bijna volledig gevuld is wanneer de bus voorbij rijdt. Het algoritme detecteert dit als een spookrijder op rijvak 3. Dergelijke “false positives” of valse positieve detectieresultaten moeten vermeden worden in een echte verkeerssituatie. verkeerssitua Ten gevolge van zo’n foutieve detectie zou een tunnel bijvoorbeeld onterecht kunnen afgesloten worden, wat in dat geval een verspilling is van tijd en geld. Een verfijning van het algoritme dringt zich op. Er moet rekening gehouden worden met dergelijke dergelij hoge voertuigen. Filedetectie Figuur 6-4 beeldt tenslotte een correcte detectie van een file. Op het scherm verschijnt de tekst “UNDERSPEED: 4”. Dit betekent dat op rijvak 4 een aantal wagens trager rijdt dan de gemiddelde snelheid in de tunnel. De snelheid sne van de wagens wordt telkens opgemeten door het algoritme.

Figuur 6-4: 4: Een file wordt met succes gedetecteerd

Tijdens de detectie worden alle metingen weggeschreven in een ObjectVideo bestand. Dit wordt achteraf vergeleken met de referentiedata referentiedat die meegeleverd werden bij het filmpje. Zo kan systematisch gecontroleerd worden in hoeverre de detectieresultaten correct zijn. Dit kan natuurlijk ook manueel gebeuren. Op de beelden wordt immers aangeduid wat er gedetecteerd wordt. Om een algoritme echter echter volledig uit te testen is het beter dat dit automatisch gebeurt aan de hand van de referentiedata.

74

7. Conclusies Voordelen Door Béziercurves als snelheidsbeschrijving te gebruiken kunnen wagens vloeiend een event uitvoeren. Dit gebeurt niet stroef of in schokjes maar kan optimaal verlopen door de kromming die kan gegeven worden aan een Béziercurve. Door van elke wagen het gedrag te bepalen aan de hand van een snelheidsbeschrijving kan een natuurlijke stroom van wagens gegenereerd worden. De onderlinge afstand tussen de wagens wordt bepaald door een Gaussverdeling. Zo wordt een realiteitsgetrouw beeld bekomen. Met de helling van een Béziercurve kan een snelheid (in km/h) exact ingesteld worden. Dit is belangrijk omdat sommige algoritmes snelheidsmetingen uitvoeren. Uit metingen blijkt dat op de ingestelde snelheid een kleine afwijking zit van ± 1 km/h. Dit wijst er op dat de traffic generator een snelheid correct kan instellen en dat de snelheidsdetectie van Traficon goed functioneert. De automodellen komen uit een uitgebreide bibliotheek waardoor een goed gevarieerde verkeersstroom gecreëerd wordt. Alle automodellen zijn gratis verkregen. Met een klein budget zou de bibliotheek nog uitgebreid kunnen worden met betere modellen. Het is daarbij belangrijk dat de modellen niet te veel polygonen hebben. Indien te complexe modellen door te scene rijden verhoogt de rendertijd aanzienlijk. Er wordt geen gebruik gemaakt van bestaande verkeerssimulatoren. Deze pakketten zijn duur en de broncode ervan kan niet opgevraagd worden. De verkeersgenerator is volledig van scratch geprogrammeerd. Daarnaast zijn Blender en Python gratis tools. Het volledige project is dus gerealiseerd zonder budget. Daardoor moet op bepaalde vlakken wel ingeboet worden aan performantie. De speciale events kunnen allemaal in onbeperkte mate toegevoegd worden aan de verkeersstroom. De vooropgestelde doelstellingen zijn allemaal bereikt. De gebruiker kan per verkeersevent instellen hoe dit er precies moet uitzien aan de hand van parameters. Er is zelfs nog een extra event toegevoegd, namelijk het fallen object event. Dit is het event waarbij een voorbijrijdende wagen een kartonnen doos laat vallen. Voor de doos moeten een aantal wagens stoppen. Dit event kan ook in onbeperkt aantal toegevoegd worden aan de simulatie. Voordat een event toegevoegd wordt in de scene, kijkt het script of het nieuwe event niet overlapt met een bestaand event. Het script is robuust en zorgt er voor dat twee wagens nooit zullen botsen of door elkaar rijden. Beperkingen De gekozen techniek heeft echter ook enkele nadelen. De rendertijd is de grootste drempel van de applicatie. Om een fotorealistische animatie van enkele minuten lang te renderen, is een tiental uur nodig. Om een algoritme grondig te testen zijn veel beelden van diverse verkeerssituaties nodig. Er moet enkele dagen gerenderd worden voordat er voldoende beeldmateriaal beschikbaar is. Best wordt er geïnvesteerd in een render farm. Terwijl een algoritme ontwikkeld wordt kan het bijhorende beeldmateriaal gerenderd worden op de render farm. Een alternatief is om zelf de baan op te gaan terwijl een camera enkele manoeuvres filmt.

75

Dit is economisch gezien echter minder interessant, maar ook risicovol en omslachtig. Daardoor blijft de ontwikkelde applicatie de beste oplossing. Ten tweede kan er niet meer ingegrepen worden eens de animatie gestart is. Botsingen of automatische interacties tussen wagens kunnen niet geprogrammeerd worden. Het gedrag van de wagens moet volledig op voorhand worden ingesteld. Eens een wagen rijdt kan zijn snelheid niet meer veranderen, tenzij dit in de snelheidsbeschrijving vastgelegd werd. Daardoor moeten wagens op eenzelfde rijvak aan exact dezelfde snelheid rijden, om botsingen te voorkomen. Door het gedrag op voorhand vast te leggen wordt het bijzonder omslachtig om wagens te laten veranderen van rijvak. Op voorhand is het immers moeilijk te voorspellen wanneer dit nodig zal zijn. Dit is ook geen vereiste voor Traficon. Het is toelaatbaar dat wagens op eenzelfde rijvak blijven rijden. Indien gewerkt zou worden met een game engine is het gemakkelijker om wagens van rijvak te laten veranderen. Met een dergelijke engine is het immers mogelijk om het gedrag van de wagens te programmeren, zodat deze realtime interactie kunnen vertonen. Voordat een wagen aan een traject begint staat deze in het begin van de tunnel. De wagen is onzichtbaar doordat deze tijdelijk op een andere layer staat. Zodoende gaat het renderen sneller doordat er op elk tijdstip maar een beperkt aantal wagens in de scene zichtbaar zijn. De grootte van het bestand waarin de volledige scene wordt opgeslagen verhoogt echter telkens met enkele megabytes wanneer een nieuwe wagen toegevoegd wordt aan de animatie. Een lange animatie met veel wagens zal dus zwaar wegen op het systeem en kan zelfs een crash veroorzaken. Blender blijft een gratis programma waardoor op bepaalde vlakken aan performantie moet ingeboet worden. Onderzoek wijst uit dat een animatie best beperkt wordt tot hoogstens tien minuten. Indien met een render farm gewerkt wordt moet de scene ook verstuurd worden naar alle slaves. Daarbij is het belangrijk dat netwerk voldoende snel is en de bestandsgrootte van de scene niet te groot is. Indien gewerkt wordt met scenes groter dan één gigabyte levert dit problemen op. Een laatste beperking is de snelheid van het filerijden. Deze kan niet absoluut ingesteld worden. Dit komt doordat er bij het manipuleren van de snelheidsbeschrijving van een filewagen moet gewerkt worden met een extra tijdsbeschrijving. Deze zorgt ervoor dat de initiële snelheid van de filewagen exact gelijk zal zijn aan de wagens van het normale verkeer. Daardoor kunnen de andere snelheden (van het vertragen, het filerijden en het weer versnellen) niet meer exact ingesteld worden. Het algoritme zorgt er wel voor dat een file telkens aan een realistische snelheid rijdt. De snelheid is beduidend lager dan deze van het normale verkeer en ligt ongeveer tussen de vijf en de twintig km/h. Toekomst Enkele mogelijke uitbreidingen voor de verkeersgenerator zijn verkeerssituaties op een autostrade of op een kruispunt. Het verkeer op een autostrade verloopt vrij gelijkaardig aan dat in een tunnel. Algemeen rijdt het verkeer daar aan grotere gemiddelde snelheid. De snelheid is echter al volledig instelbaar in de ontwikkelde verkeersgenerator. Om verkeer voor een kruispunt te genereren moeten wel enkele dingen aangepast worden. Indien het verkeerslicht op rood springt, moet een volledige verkeersstroom stoppen. Dit kan vrij gemakkelijk gerealiseerd worden door op die rijvakken een groot stopevent in te stellen. Dit event moet duren totdat het

76

verkeerslicht weer op groen springt. De huidige traffic generator bevat reeds alle logica om stopevents in te stellen. Het aanpassen van de omgeving wordt iets moeilijker. Een tunnelmodel is relatief gemakkelijk te maken. Bij een kruispunt moeten echter meer details verzorgd worden zoals de omringende huizen, het voetpad en de verkeerslichten. Een laatste mogelijke uitbreiding is de mogelijkheid tot “vehicletracking”. Daarbij worden meerdere camera’s geplaatst in de tunnel. Voor elke camera wordt een filmpje van het voorbijkomende verkeer gerenderd. Aan de hand van dit beeldmateriaal kan Traficon algoritmes uittesten die speciaal ontworpen zijn om één voertuig te volgen (tracken) doorheen meerdere filmpjes. Deze uitbreiding is gemakkelijk realiseerbaar. In plaats van één camera moeten er nu meerdere camera’s doorheen de tunnel opgehangen worden. Voor het renderen is het mogelijk om vanuit Python in te stellen welke camera er gebruikt moet worden. Van elk camerazicht moet een filmpje gerenderd worden.

77

8. Literatuurlijst Lipton, A.J. (2004) “ObjectVideo Forensics: Activity-Based Video Indexing and Retrieval for Physical Security Applications” In IEE Intelligent Distributed Surveillance Systems, Reston (USA) Pursula, M. (1999) “Simulation of Traffic Systems - An Overview" In Journal of Geographic Information and Decision Analysis, vol. 3, Helsinki: Helsinki University of Technology Namekawa.M., et al. (2010) “A road traffic simulation system with microscopic model using running line”, Tokyo: College of Management and Economics, Kaetsu University Mosseri, G., et al. (2003) “Lincoln Tunnel corridor study: traffic micro-simulation” New York, Port Authority of New York and New Jersey Dronzek, R. (2007) “Using Modeling to Optimize Transportation & Logistics Processes”, Chicago: TranSystems Jones, S., et al. (2004) “Traffic simulation software comparison study”, Alabama: The University of Alabama at Birmingham Qu H., Qiu F., Zhang N., Kaufman A., Wan M. (2003) “Ray tracing height fields” In Computer Graphics International, New York: Center for Visual Computing Christen, M. (2005) “Ray Tracing on GPU”, Switzerland: University of Applied Sciences Basel Smelyanskiy, M. (2009) “Mapping High-Fidelity Volume Rendering for Medical Imaging to CPU, GPU and Many-Core Architectures”, California: IEEE Computer Soc Huang, J. (2009) “Keynote Address.” In Hot Chips: A Symposium on High Performance Chips 21, Stanford (California): IEEE Technical Committee on Microprocessors and Microcomputers Mitchell, J., McTaggart, G., Green, C. (2006) “Advanced Real-Time Rendering in 3D Graphics and Games Course”, Washington: SIGGRAPH Andrews, J. (2006) “Threading the OGRE3D Render System”, California: Intel Puech, Y. (2007) “Using DirectX Shaders in 3ds Max”, Frankrijk Korva, T. (2007) “Open Source & Low Cost Game Engines”, Finland: LudoCraft Ltd. Dunbar, D. (2003) “The Python API”, Nederland: NaN

78

Famler, B. (2007) “Mobile Application Prototyping with Python for S60”, Hagenberg (Oostenrijk): University of Applied Sciences, Hagenberg Küng, S., Onken, L., Large, S. (2007) “TortoiseSVN: A Subversion client for Windows”, Zwitserland Eliasson, M. (2005) “Advantages Of SubVersion Over CVS When Working With XP Projects”, Zweden: Lund University Pauwels, I., (2010) “Agile Scrum Principles”, Berchem (Vlaanderen): Litic BVBA

79

9. Bijlagen