Ra2 werkt correct

Na veel vloeken is het gelukt om ra2 bestanden correct te renderen. Ik heb heel lang zitten zoeken in mijn camera code, Ares was zelfs zo vriendelijk om voorbeeldcode te mailen. Helaas zat daar het probleem helemaal niet :(.

Het probleem zat in mijn straal-driehoek intersectie, ik veronderstelde namenlijk dat de straal parameter t altijd groter was dan 0. Dit was echter niet altijd het geval zodat de dichtsbijzijnde driehoek vaak achter de camera lag. Hierdoor kreeg ik egaal gekleurde plaatjes omdat ik de muur achter de camera renderde.

Het probleem met de geheugenallocatie is ook getraced. Sommige scenes geven een slecht gebalanceerde boom (1 heel diepe tak) bij median split (ik weet nog niet waarom). Omdat het bouwen van zo'n boom recursief is moet er bij een heel diepe tak een diepe stack worden bijgehouden. Op een bepaald moment zegt mijn kernel dan nu is het genoeg en wil geen geheugen meer alloceren voor mijn stack. Ik kan de stack size vergroten (dirty hack) of eens in mijn code duiken (eleganter). We zullen voor de elegante weg kiezen :)

Nog wat problemen op te lossen maar hier toch al een voorsmaakje:

De classroom scene (9400 driehoeken 300 x 300 pixels) gerendered in 31 seconden:


De office scene (34.000 driehoeken 300 x 300 pixels) gerendered in 115 seconden:


De Soda hall (141.640 driehoeken 300 x 300 pixels) gerendered in 1736 seconden:


Deze scenes komen uit de MGF example scenes.

Status update

Het is alweer maandag dus een meeting met Ares en tijd voor een status update. Deze week ga ik mijn BVH proberen foutloos te laten werken met grote modellen (meer dan 90.000 driehoeken). Ik heb net een paar scenebestanden van Ares gekregen dus die kan ik allemaal proberen te renderen (sommige met meer dan 1 miljoen driehoeken).

Als alle problemen opgelost zijn met de implementatie is het tijd om BVH's te implementeren met de Surface Area Heuristic (SAH). Ik verwacht hier nog een ordegrootte performantiewinst.

Volgende week ook presentatie van de eerste resultaten dus tijd om een draft op te stellen tegen maandag zodat Ares die nog eens kan bekijken.

Ra2 Parser

Vandaag heb ik wat tijd gespendeerd aan het schrijven van een parser voor ra2 bestanden. Ra2 is het (binair) bestandsformaat dat gebruikt in de bwfirt ray tracing benchmark. Nu kan ik enkele scenebestanden gebruiken van Ares en de snelheid van mijn ray tracer vergelijken met die van professionals :)

Helaas is door het kunnen inladen een andere bug aan het licht gekomen. Voor grote bestanden crasht mijn ray tracer bij het bouwen van de bvh tree. Reden hiervoor is dat niet genoeg geheugen kan gealloceerd worden bij grote scenes.

Wat ik nog moet implementeren is het inlezen van files met vertexnormalen. Op dit moment bereken ik slechts 1 normaal per driehoek (door het vectorproduct te nemen van 2 zijden) wat aanleiding geeft to crappy shading.

De volgende scene is de "Ulm Box" een Duitse kopie van de bekende Cornell Box.

Boundingbox intersection

Als code optimizen een drug is dan ben ik een junk. Eenmaal je begint met optimaliseren dan kan je niet meer stoppen. Door het profilen van mijn code heb ik vastgesteld dat de (huidige) bottleneck zit in mijn boundingbox intersection code.

De grootste kost in de intersection code is het maken van 3 delingen (delingen zijn een ordegrootte duurder dan vermenigvuldigingen) om de inverse x, y en z coordinaat van de straalrichting te berekenen. Omdat ik meerdere bounding boxes intersecteer met eenzelfde straal berekenen ik dus die 3 delingen telkens opnieuw. Het tweakje is om de inverse van de richting 1 keer te berekenen in de constructor van de straal en die daarna gewoon op te vragen bij de intersectietest. Eigenlijk voor de hand liggend maar soms is het moeilijk om het bos door de bomen nog te zien :)

Natuurlijk kan ik hiervoor geen enkele credit opstrijken maar heb ik dit trukje uit de volgende paper: "An Efficient and Robust Ray–Box Intersection Algorithm".

En dan natuurlijk de rendertijden:

figuur	#driehoeken	#seconde
kegel	32	< 1
cilinder	64	< 1
bol	480	< 1
torus	1024	1
theepot	4032	10
konijntje	5110	13

Weeral een mooie verbetering, ik hoop dat ik nog veel van die trukjes kan blijven toepassen want anders vrees ik dat ik naar het straffer spul moet grijpen (SIMD, packet ray tracing, ...) .

Möller - Trumbore intersection test

Net de paper "Fast, Minimum Storage Ray Triangle Intersection" gelezen. De paper beschrijft een snelle test voor het berekenen van een straal - driehoek intersectie.

Het zoeken van een straal - driehoek intersectie komt neer op het oplossen van een stelsel van 3 vergelijkingen en 3 onbekenden. In mijn code berekende ik het stelsel eerst en controleerde ik daarna de oplossing. De Möller - Trumbore test lost ook dit stelsel op maar doet dit in verschillende stappen zodat tussendoor al beslist kan worden of er een intersectie is of niet zonder dat het hele stelsel moet opgelost worden.

Dit geeft dan de volgende rendertijden:

figuur	#driehoeken	#seconde
kegel	32	< 1
cilinder	64	< 1
bol	480	< 1
torus	1024	1
theepot	4032	18
konijntje	5110	23

Een speedup van een kleine factor 2, bedankt Tomas en Ben!

Bounding Volume Hierarchies deel 3

Het is alweer even geleden dat ik nog eens kon bloggen over wat vooruitgang, vandaag komt daar verandering in. Gisterennacht om 00:45 is het gelukt om mijn nieuwe bvh implementatie werkende te krijgen en ongeveer 10 minuten geleden is het gelukt om ze sneller te laten werken dan de oude implementatie.

Het doorlopen van de bvh boom doe je, depth-first (i.t.t. breadth-first). In mensentaal, proberen eerst zo diep mogelijk af te dalen in de boom. De normale manier om zoiets te implementeren is recursief, eenvoudig en intuïtief. Het nadeel is dat er heel veel function call overhead is (er moet een heel grote call stack worden bijgehouden). Om het iteratief te doen kan je zelf een call stack bijhouden of zoals ik doe de knopen in het geheugen steken in de volgorde waarin ze moeten doorlopen worden. Nu heb je een lijst die je iteratief kan doorlopen. Omdat ik mijn scanner werkende heb gekregen onder Linux heb ik een schets bijgevoegd (best even vergroten voor de duidelijkheid).



Op deze manier doen we echter nog altijd teveel werk. Als bijvoorbeeld de boundingbox van knoop B wordt gemist heeft het geen zin om D en E nog te bezoeken. Daarom houden we per knoop een "skip pointer" bij die aangeeft naar welke knoop we moeten springen als de knoop gemist wordt. Dus bijvoorbeeld de skip pointer van B wijst naar C, dus als we B missen slaan we D en E over en springen we naar C.

Hoewel het concept simpel is heeft het me toch redelijk veel bloed, zweet en tranen gekost om dat in C++ vertaald te krijgen. Uiteindelijk werkt het dus tijd voor rendertijden!

figuur	#driehoeken	#seconde
kegel	32	<1
cilinder	64	<1
bol	480	<1
torus	1024	1
theepot	4032	29
konijntje	5110	38

Hoewel het weeral net iets sneller is had ben ik wat teleurgesteld, gezien het veel werk had ik toch meer spectaculaire resultaten verwacht.

Er is nog wel wat ruimte voor verbetering, bijvoorbeeld de knopen zijn nu nog 32 bytes, het zou leuk zijn om dit te reduceren naar 16 bytes. Ook de driehoek-straal intersectie is wat aan de trage kant, hiervoor heeft Ares me verwezen naar de snellere methode van Möller en Trumbore.

Status update

Er is ondertussen een week verstreken sinds de laatste post. Helaas heb ik nog altijd geen vooruitgang te melden :( Het implementeren van een geheugenefficiënte layout is een tijdrovende en moeilijk te debuggen karwei. Ik voel me op dit moment dan ook redelijk gefrustreerd.

Vandaag ook bij Ares langsgeweest en we hebben afgesproken dat ik deze week zal blijven verder debuggen aan mijn code voordat ik nieuwe gronden aanboor.

Een klein experimentje

Daarnet even met Ares aan het praten over g++ optimization levels. Hiermee geef je aan de compiler mee dat hij moet proberen je code zo optimaal mogelijk te compileren. Dus heb ik bij wijze van experiment alles gecompileerd met de flag -O3 (optimization leven 3, het meetst geoptimaliseerd). Dan krijg ik de volgende rendertijden:

figuur	#driehoeken	#seconde
kegel	32	<1
cilinder	64	1
bol	480	1
torus	1024	3
theepot	4032	37
konijntje	5110	54

Grosso modo een factor 3 snelheidswinst door 3 karakters te typen: -O3 !

In een van de besproken papers renderen ze een scene van 804 driehoeken in 0.7 seconden, de regel van 3 leert ons dat ze 1024 driehoeken renderen in 1.12 seconden (Ik veronderstel hier een lineair verband, in de praktijk is dit logaritmisch). Ik kan momenteel 1024 driehoeken renderen in 30 seconden bij een resolutie van 1024 x 1024 (In van één mijn vorige posts was ik mis bij mijn vergelijking omdat ik daar renderde in een resolutie van 300 x 300). Dat is een factor 27 trager dan hun implementatie. Nog wat werk af te leggen :)

Status update

Het is weeral maandag dus een afspraak met Ares en een nieuwe status update.

Waar ik me deze week vooral mee bezig zal houden is het efficiënter herimplementeren van mijn versnellingsstructuur (BVH). Concreet wil dit zeggen:

• Zorgen voor een kleinere memory footprint van mijn BVH nodes. Elke cache miss / memory access is duur.
  
• Het bannen van virtuele functies en polymorphism omdat je hier ten eerste de overhead hebt van de function call (virtuele functies kan je niet inlinen omdat je pas @runtime weet welke functie je moet aanroepen, duh) en de pointer naar de VTABLE is extra geheugengebruik.
• Bij BVH traversel proberen recursie te vermijden. Dus zelf voor compiler spelen en een eigen stack bijhouden.
  

Dat betekent pijnlijk genoeg geschreven code weggooien. Ares heeft me doorverwezen naar de phd van, u raadt het al Ingo Wald, voor verdere referentie.

Als ik dan alles terug draaiende heb gekregen, na lange uren van frustratie om uit te zoeken waarom alles niet compileert, dan is het tijd om een SAH-based BVH te implementeren.

Verder hebben we beslist om Cal3d integraal te gebruiken in mijn raytracer en als extra bestandsformaat ra2 van bwfirt te gebruiken.

Paper: On fast construction of SAH-based bounding volume hierarchies.

Alweer een paper van Ingo Wald deze keer: "On fast construction of SAH-based bounding volume hierarchies". De paper onderzoekt een methode om bij dynamische scenes voor elk frame de versnellingsstructuur terug op te bouwen.

De methode bouwt rond een verzameling driehoeken T een bounding box en neemt van deze bounding box de langste zijde. Die zijde wordt dan onderverdeeld door K equidistante vlakken. Hierdoor verkrijgen we K+1 bins (emmers) van gelijke breedte. Gegeven deze K bins B1 ... Bk dan zijn er K - 1 manieren om de verzameling driehoeken T hierover te verdelen in 2 partities. Bijvoorbeeld als K = 4 dan kunnen we de driehoeken verdelen in T_left = { B1, B2 } en T_right = { B3, B4 }.

Omdat er K-1 mogelijke partitioneringen (teken maar) zijn moeten we deze allemaal uitproberen. We evalueren vervolgens voor elke mogelijkheid een kostenfunctie (wederom de SAH of Surface Area Heuristic) en weerhouden de partitionering met de laagste kost. Van deze 2 partities nemen we dan de bounding box die we terug recursief gaan opsplitsen.

Normaal als je N driehoeken hebt dan kan je de bounding boxes daarvan op 2^N - 2 mogelijke manieren partitioneren. In dit algoritme proberen we maar K-1 mogelijkheden. Het gevolg hiervan is dat het algoritme veel sneller is dan de standaardmanier (alle 2^N-2 mogelijkheden beschouwen). Er is ook een keerzijde aan de medaille, omdat we slechts K-1 mogelijkheden beschouwen doen we een benadering. Als gevolg hiervan is onze BVH ook slechts een benadering van diegene die we zouden vinden met de standaardmethode. De auteurs verzekeren echter dat het snelheidsverlies bij het renderen slechts een paar procenten is.

Een interessante paper vooral voor de besproken techniek die ik uitendelijk zelf ook eens zal proberen te implementeren. Verder geven de auteurs nog enkele build times (tijd nodig om de structuur op te bouwen) en rendertimes. Allemaal op "general purpose" hardware, namenlijk een 8 core 2.6Ghz Clovertown met 8 keer 2Gb ramgeheugen. De definitie van "general purpose" hardware is toch net iets anders in Utah in vergelijking met Leuven.

Paper: Ray tracing deformable scenes using dynamic bounding volume hierarchies

Vandaag een beetje tijd gehad om een paper te lezen. Het is de paper "Ray tracing deformable scenes using dynamic bounding volume hierarchies" geworden wederom van onze goede vriend Ingo Wald.

De paper beschrijft eerst een algoritme om BVH's (Bounding Volume Hierarchies) op te bouwen volgens de "surface area heuristic" (SAH). Tot op vandaag is dit nog altijd de beste heuristiek om een versnellingsstructuur mee te bouwen. De auteurs geven ook een tabel met rendertijden voor BVH's gebouwd met de object median, de spatial median en de SAH. De eerste 2 zitten ook al in mijn eigen implementatie. De auteurs kunnen met de spatial median (ook median split genoemd) een scene renderen van 804 driehoeken in 0.7 seconden. Dit is ongeveer vergelijkbaar met mijn torus (1024 driehoeken) die ik render in 10 seconden, mijn ray tracer is dus een factor 14 trager.

De grote snelheidswinst is grotendeels te wijten aan het gebruik van ray packets. In ray packets worden rays gebundeld en worden die bundels in de scene getraced. Het is duurder om een packet door een scene te tracen dan een enkele straal maar we kunnen die duurdere kost wel spreiden over verschillende stralen. Dus de kost per straal is goedkoper.

Om met dynamische scenes rekening te houden worden de bounding boxes telkens vervormd, de bounding volume hierarchy blijft hetzelfde. Hoewel de kwaliteit van de BVH verslechterd per update is de performantieimpact niet veel slechter.

Deze paper is vooral nuttig om zijn techniek om rays sneller door een BVH te tracen en om zijn rendertijden. Nu heb ik een paar richtwaarden om de performantie van mijn ray tracer mee te evalueren.

Bounding Volume Hierarchies (BVH) part deux

Geprobeerd om median split te implementeren en het werkte van de eerste keer! Mijn computer kijkt heel dankbaar omdat ik hem deze keer geen schop tegen zijn ******* heb verkocht.

Median split komt erop neer dat we de bounding box nemen van een aantal objecten en hiervan het middelpunt berekenen. Als het middelpunt van een object voor het middelpunt van de box ligt (volgens een bepaalde as) dan steken we het in de linkerdeelboom anders in de rechter. Dit blijven we iteratief doen todat we geen objecten meer hebben om te verdelen.

Het deleten van de hierarchy lukt ook, ik krijg geen double free errors en volgens Valgrind is er ook geen geheugen dat verloren gaat.



Nu verkrijgen we de volgende rendertijden:

figuur	#driehoeken	#seconde
kegel	32	1
cilinder	64	1
bol	480	4
torus	1024	10
theepot	4032	162
konijntje	5110	209

De plaatjes zijn nog altijd hetzelfde dus die post ik niet.

Bounding Volume Hierarchies (BVH)

Tijd voor een korte update. Na 2 dagen hard werken is het gelukt om een simpele bounding volume hierarchy te bouwen. De code was snel geschreven en draaide heel snel. Alleen zijn segmentation violations redelijk pijnlijk om te debuggen :(.

Voor diegenen die de bounding hierarchy nog niet helemaal doorhebben kan misschien de volgende tekening een verduidelijking zijn. Het principe is eenvoudig, we bouwen rond alle objecten uit onze scene een doos. Die doosjes steken we terug in andere doosjes tot we uiteindelijk bij een doos uitkomen die alle objecten van de scene omvat.



De hierarchy (gewoon een boomstructuur) wordt heel simpel opgebouwd door de objecten alternerend aan de linker- en de rechtertak toe te voegen. Weinig efficïent maar het geeft wel al een geweldige speedup (zie tabel verder). Wat ik nog moet implementeren is het deleten van de met new gealloceerde knopen. Een beetje tricky omdat ik in principe in het midden van de hierarchie een knoop kan deleten waardoor al zijn kinderen voor eeuwig en 3 dagen (of toch tot de volgende reboot) in het geheugen achterblijven. Bovendien moet ik er ook op letten dat ik geen bladeren (de echte objecten) delete.

Ondertussen kan ik renderen aan de volgende snelheden:

figuur	#driehoeken	#seconde
kegel	32	1
cilinder	64	3
bol	480	8
torus	1024	17
theepot	4032	355
konijntje	5110	360

Op de grafiek is duidelijk te zien dat de grootste snelheidswinsten te halen zijn bij kleine scenes, waarschijnlijk omdat ik mijn hierarchie opbouw op de meest crappy manier.



Eigenlijk zijn mijn grafieken ook crappy aangezien er een heel gat gaapt tussen 1024 driehoeken en dan 4032. Hierover interpoleren is wel heel scherp afronden.

Meeting thesisbegeleider

Net een meeting gehad met Ares. We hebben even samengezeten om mijn werk van vorige week te bespreken en vooral om een planning voor deze week te maken.

De volgende dingen zouden tegen volgende week moeten gerealiseerd zijn:

• Het lezen en begrijpen van de paper: "On fast Construction of SAH based Bounding Volume Hierarchies" van Ingo Wald et. al.
• Het bouwen van een simpele bounding box hierarchie (dus nog niet SAH based).
• Het zoeken naar een algemeen bestandsformaat zoals dat van bwfirt.
• Uitvissen hoeveel informatie ik uit Cal3D kan halen (bones, joints, skinning, transformations, meshes, ...).

Als ik dan nog tijd over heb zou ik eens moeten op zoek gaan naar het boek "Visualizing quaternions" want op die manier worden rotaties voorgesteld in Cal3D. Concreet zou ik moeten weten hoe ik van een quaternion naar een transformatiematrix ga.

Bounding Boxes

Vandaag, een regenachtige zondag, dus een excuus om achter de computer door te brengen. Nog een beetje verder geprogrammeerd aan mijn ray tracer. Ondertussen is de normaaltransformatie geïmplementeerd en de shading werkt nu (op het eerste zicht) correct.

Verder ben ik begonnen met een poging om een eerste versnellingsstructuur in mijn ray tracer te bouwen namenlijk "bounding boxes". Voor de niet ingewijden een korte uitleg. Een bounding box is een doosje waarin je objecten uit je scene steekt (meshes). Als je nu de stralen (rays) in de scene schiet test je eerst of de stralen de box raken, pas als de straal de box raakt ga je daadwerkelijk kijken wat erin zit. Als een straal de box niet raakt moeten we dus ook niet meer verder kijken wat erin zit. Het voordeel van deze aanpak is dat we veel dure straal-driehoekintersectie testen niet moeten doen, in plaats daarvan doen we relatief goedkope box-driehoekintersectie testen. Bounding boxes zijn niet het enige alternatief je kan de objecten bijvoorbeeld ook in bollen of andere geometrische figuren steken (zie figuur).



Momenteel zijn mijn bounding boxes nog niet hiërarchisch opgebouwd. In mensentaal: als we een doosje opentrekken vinden we direct een lief konijntje, een teepot of iets anders. Bij hierarchishe boundingboxes is elk doosje op zijn beurt weer opgebouwd uit kleinere doosjes tot we uiteindelijk het laatste doosje openen waar een of meerdere driehoeken inzitten.

Als we onze figuren vergelijken met de eerste plaatjes dan ziet bijvoorbeeld de donut er al veel smakelijker uit.
















Hoewel bounding boxes een simple versnellingstructuur is kunnen we toch al een snelheidswinst vaststellen (zie volgende tabel).

figuur	#driehoeken	#seconde
kegel	32	3
cilinder	64	5
bol	480	36
torus	1024	102
theepot	4032	843
konijntje	5110	696

Om een onbekende reden is de rendertijd voor de teepot verhoogt van 534 seconden naar 855 seconden, hier heb ik echter (nog) geen verklaring voor.

Paper: On improving kd-trees for ray shooting

Omdat de paper "On building fast kd-trees for ray tracing, and on doing that in O(N log N)" nogal zware kost lijkt op het eerste gezicht ben ik begonnen met iets lichter. Dat iets lichter is de paper "On improving kd-trees for ray shooting" van Vlastimil Havran et al.

Ik schets hier slecht een kort overzicht geen samenvatting, om alles te weten moet je de paper zelf eens bekijken. De paper behandelt 2 methodes om kd-trees te verbeteren:

1. Een automatisch stopcriterium (Automatic Termination Criteria , ATC) voor het bouwen van een kd-tree. Normaal wordt de diepte en het aantal objecten per leaf door 2 ad-hoc constanten bepaald, voor deze constanten is geen wetenschappelijk argument. Meestal worden deze gekozen door experimenteren. Het ATC probeert het minimum van de globale kostenfunctie te benaderen en te stoppen als dit min of meer bereikt is.
2. Het split clipping algoritme splitst de bounding box van een object in 2 kleinere bounding boxes wanneer het snijdt met een split plane.

ATC geeft een maximale verbetering van 20% en worst case een verslechtering van 10%. Split clipping geeft gemiddeld een verbetering van 9%.

Havran geeft zelf toe dat de resultaten niet spectaculair zijn maar zegt dat dit een eerste stap is in het construeren van data structuren zonder ad-hoc constanten van de gebruiker.

Voor mijn thesis zijn deze resultaten niet echt heel belangrijk (denk ik). Voor mij persoonlijk was het vooral belangrijk om wat meer feeling te krijgen met kd-trees.

Transformaties en Shading

Toch nog even de tijd gevonden om wat code te schrijven. De mesh een beetje simpeler gemaakt en alles werkt. Dus tijd voor plaatjes!

Een kubus vervormd tot een balk en geroteerd rond de z-as.



Een onvervormde kegel.



Dit zou een platgedrukte bol moeten zijn maar het lijkt er niet echt op dus nog een fout in de implementatie. Waarschijnlijk omdat ik nog geen normaaltransformatie doe.


dus nu nog "make it right".

Status update

Het is de afgelopen dagen stil geweest op mijn blog dus tijd voor een update. Het plan was om vandaag al enkele resultaten en prentjes te tonen maar de realiteit heeft roet in het eten gegooid. Waar heb ik me de afgelopen dagen zoal mee bezig gehouden?

Het ondersteunen van transformaties (herschaling, translatie en rotatie). Dit heb ik getest op een kubus en ziet er (op het eerste zicht) visueel correct uit. Wel waarom dan geen plaatjes, ik zou zeggen lees even verder.

Na het bekijken van mijn mesh klasse vond ik het toch allemaal wat inefficiënt om dat ik volledige driehoeken bewaar in plaats vertices. Dus dacht ik laat ik dit eens snel optimaliseren door een lijst vertices bij te houden en indices per driehoek. Allemaal goed en wel tot ik tot de vaststelling kwam dat sommige modellen zoals de kubus 3 normalen hebben per vertex. Veel geklooi, slechte code, frustratie en tijdverlies om tot een elegante oplossing te komen. Uitendelijk zal ik toch maar gewoon volledige driehoeken bijhouden tot ik hier eens een goeie paper over heb gelezen. Het nadeel is dat we dan vertices meermaals bijhouden, het voordeel is minder frustratie en een betere gemoedsrust. Vanaf nu ga ik me niet meer laten vangen en werken volgens de "Is een waarheid als een koe" vuistregel: 

• Make it work
• Make it right
• Make it fast

Strikt militaristisch in die volgorde!

Na het ontvangen van de C++ sessie modeloplossing heb ik mijn code aangepast zodat het meer lijkt op de code van een pro en niet meer op die van een C++ wannabee Java coder. Concreet het ik mijn include guards allemaal van het prefix RT_ voorzien (van ray tracer, duh). Alles in een namespace gezet en geprobeerd om alles te herschrijven naar template classes. Alles gelukt hier behalve het omzetten naar template classes. Als meshes me frustreren dan brengen template klassen me in een toestand van waanzin :). Dus ik ga alleen nieuwe code nog parametriseren en afblijven van de dingen die werken.

Simple shading toegevoegd, werkt niet correct maar dit komt door het eerder genoemde probleem met mijn mesh en mijn normalen.

Als al die problemen van de baan zijn dan heb ik een basic raytracer in deftige C++ code (eigen mening) om het echte, interessante werk mee aan te vatten. Hopelijk kan ik dan volgende week een plaatje schieten van Cally.

Dit weekend geen programmeren maar het lezen van de vooropgestelde papers. 

Hoewel het lijkt alsof ik deze week (dinsdagnamiddag tot nu) veel heb gewerkt kom ik bij telling aan slechts 17u, amper de helft van wat ik zou moeten gewerkt hebben.