Object (.OBJ) loading
Koden var ret lige til, vi brugte sscanf lige som i
OBJResource::LoadMaterialFile med en masse
if, else if.
Vi valgte at ignorere alle linjer uden
{v, vt, vn, f, mtllib, usemtl} i starten, i
stedet for at smide exceptions. Der var ikke rigtig nogen grund til ikke at prøve at
loade selv om man støder på noget ukendt.
Det eneste problem vi stødte på er at de index man læser efter et
f ikke starter
fra 0, men fra 1.
Vi fandt én
reference som vi synets var god nok. I hvert fald den vi lavede det ud fra.
Kritik
Man kan ikke bruge
Vertex Arrays eller
Vertex Buffer Objects da de kræver
at man har sine værdier liggende med fast mellemrum(man kan kun angive en start og en
stride der siger hvor langt der er til starten af næste).
Det krav duer ikke sammen med at en
Face da:
Face er for det første heap allokeret, så et FaceSet har dem ikke liggende i et
sammenhængende stykke.
- Hvis man gik i gennem det ekstra besvær med at få allokeret en bunke
Faces efter
hinanden, ville man stadig have et problem da de er lavet som 3 punkter, 3 normaler,
3 texture coordinater osv.
De ville være nødt til at være 1 punkt, 1 normal, ..., 1 punkt, 1 normal, ...
Man kunne ændre
Face og
FaceSet, eller tilføje en
OptimizedGeoNode der ikke bruger
dem, hvis man virkelig gerne vil bruge en mere optimal måde, men vi rodede os ikke ud i
det. En anden måde at optimere det på er med
Display Lists. Det skulle være
muligt, men dog ikke uden at enten ændre
GeometryNode til at vide hvilken list der
passer til dens
FaceSet, eller ved at cache i RenderingView.cpp på pointeren til
FaceSet. Så må man bare håbe de ikke bliver opdateret in-place
Joystick support
Da i vores gruppe har adgang til et joystick (det er nu nærmere en gamepad i playstation stil der har fået transplanteret halen...), så er det jo lidt en must have at kunne køre bilen med dette. Vi har derfor implementeret joystick understøttelse i Enginen.
Implementation er i samme stil som både keyboard og mouse, vi har defineret et interface (IJoystick) til enginens devices afdeling, samt et par nyttige structs.
Af structs har vi defineret:
JoystickState som indeholder joysticket tilstand, dvs. hvilke knapper der er trykket ned, og hvor på akserne de forskellige styrepinde står.
JoystickAxisEventArg der som navnet antyder indeholder data der benyttes i akse, dvs. id'et på aksen der har udløst begivenheden, samt tilstanden af alle andre akser.
JoystickButtonEventArg der ganske ligesom den foregående er til en begivenhed, indeholder id'et på knappen der udløste begivenheden, samt alle knap tilstande.
Da det må forventes at der kan sættes flere joysticks til, så skal disse også kunne håndteres, alle strukturerer indeholder derfor et id på joystick som strukturen tilhører. Joystick id starter fra og med 0 for første enhed, og til og med n-1 for n'te tilkoblede enhed.
Struct'sne er som følger:
struct JoystickState {
int JoystickID;
int NumberOfButtons;
int ButtonState;
int NumberOfAxis;
std::vector AxisStates;
};
struct JoystickButtonEventArg {
int JoystickID;
int NumberOfButtons;
int ButtonState;
int button; //button that triggered the event;
};
struct JoystickAxisEventArg {
int JoystickID;
int Axis;
std::vector AxisStates;
};
selve interfacet specificerer 3 metoder, en til at hente hele tilstanden på et givent joystick, en til undersøge om en knap er trykket ned (Vi overvejer at markere den som deprecated), og tilsidst en til at finde ud af hvor mange joysticks computeren besidder.
Metoderne er deklareret som følgende:
JoystickState GetJoystickState(int id);
bool IsPressed(JoystickButton b, int id);
int GetNumberOfJoysticks();Slutteligt specificerer interfacet 3 event, Knap op, knap ned, og sidst men absolut ikke mindst, en til når en styrekæp flyttes. Alle events er statiske ligesom i IMouse og IKeyboard for en mere konsekvent stil.
Event'sne er som følger:
static Event joystickButtonDownEvent;
static Event joystickButtonUpEvent;
static Event joystickAxisMovementEvent;Interfacet er ikke komplet, i kampens hede har vi opdaget at der også er noget der hedder hats og balls i en joystick sammenhæng, og vi ved virkelig hvad det er :) Derudover kunne det så også have über nice med Force Feedback understøttelse.
Selve implementationen er sket modulet SDLInput, som der så ellers ikke er så synderligt meget ophidsende omkring.
Når modulet initialiseres åbnes alle joysticks, deres tilstand aflæses, og gemmes.
Deres tilstand opdateres så vha. af de events vi får fra SDL.
Specielt er akserne, hvor der er sat en grænse på ca. 10% fra 0 (akse centrum) før en begivenhed udløses, +- 10% er derfor et dødt område. Dette er indført da flue ellers ville kunne køre bilen i grøften :)
Joysticks kan benyttes på ca. samme måde som keyboard og mouse vha. events.
Race car movement
For at teste en lidt mere avanceret kamera-kontrol ville vi lave en forløber til det vi kommer til at bruge senere hen, nemlig et modul der kan simulere det at køre i en bil.
Vi simulerer en racerbils bevægelser ved at have en "Velocity", "Direction" og "Position" vector.
En racerbil behøver ikke nødvendigvis bevæge i den retning den peger da den kan skride ud i sving m.m. derfor holder vi Velocity og Direction adskildte variabler.
Vi arbejder løbende på at gøre bevægelsen mere realistisk og efterligne en rigtig bil mere og mere.
Vi er klar over at der kommer konkret teori om dette senere, men vi bruger dette til at teste forskellige ting.
Målet med vores RaceCar modul er senere at koble det på FutureTank modellen så man kan styre den rundt på banen.
Vi kan både styre bilen med tastaturet og med joystick.
Tastaturet begrænser input til at være "konstant" som f.eks. at trykke "pil op" vil resultere i at give fuld gas, mens det er muligt at kun gasse lidt op når man bruger joysticket.
I vores implementation har vi gjort plads til det ved at gøre alle input variable til floats der går fra -1 til 1.
Ved brug af tastatur vil en variabel som f.eks. accelerationFactor blive sat til 1 (fuld acceleration) hvor joysticket kan have en hvilken som helst acceleration efter ønske.
