Invoerformaat en Planning (3)

Tussen alle andere werkjes door nog eens goed nieuws: het invoerformaat is eindelijk deftig aangepast, ik kan splines inlezen! Toch een klein beetje euforie, afgezien van het feit dat dat twee weken te laat is... De volgende stap is dan om splines vanuit Maya om te zetten naar het formaat dat PBRT nu kan lezen.

Ik heb daarnet in mijn meeting met Toon dan ook mijn planning voor de komende drie weken (de laatste drie van dit semester) opgesteld:

• 29/11-7/12: Maya/MEL bestuderen en een spline gedefinieerd in Maya uitschrijven naar PBRT (initieel gewoon vanuit MEL proberen uit te schrijven, daarna de Maya-PBRT plugin uitbreiden zodat dit automatisch gebeurt.
• 8/12-20/12: Proberen een spline te definiëren door gewoon rond te lopen in Maya, en punten van het gevolgde pad te pollen. Ook de presentatie en demo van 20/12 voorbereiden.

B

Splines (2)

Als ik dacht dat het frustrerend was een heel weekend zonder resultaat te zoeken naar een manier om met splines te werken in c++, verbleekte dat maandag bij het antwoord van Toon, die na even googlen een library had gevonden waar ik meteen mee aan de slag kon.

Meteen dient hier geïnterpreteerd te worden als 7 uur later, gezien ik les had tot 22u. Daarna ben ik als een gek beginnen programmeren, en heb ik ook nog een stuk in de ochtend doorgewerkt, om op een hoop compilatieproblemen te stuiten. Ik heb de meeting met Toon verzet naar woensdag om al die fouten er nog uit te krijgen en de kans te hebben om ook nog wat te testen. Na de compilatieproblemen opgelost te hebben (gisteravond, door omstandigheden overdag niet veel kunnen doen), bleken er ook nog problemen in mijn applicatie van de library te zetten (en compatibiliteitsproblemen tussen de c++ code van pbrt en de c-code van de library), zodat ik nu na weer een ganse nacht en ochtend programmeren kan zeggen: de splines werken! Ik kan effectief een aantal punten ingeven die op het pad van de camera moeten liggen, en de camera zal dan door deze punten bewegen.

Dat is mooi, maar de euforie is eerder beperkt... Niet alleen sta ik door die splines zwaar achter op schema, mijn aanpassing van het invoerformaat om camerapaden (lees: een reeks punten) te kunnen inlezen blijkt ook niet te kloppen. Deze had ik nog niet getest omdat ik er eerst splines mee wou kunnen maken. Op dit moment zijn alle punten dus nog gehardcoded in de cameraklasse, iets wat hopelijk zo snel mogelijk verholpen zal zijn. Toch nog een piccie om het te illustreren: hierin is enkel de positie van de camera veranderlijk, de kijkrichting niet. De implementatie om de kijkrichting volledig te laten verlopen via een spline is functioneel, maar ik heb nog geen goeie waarden gevonden en moet stilaan vertrekken naar een groepswerkje.

B-Een klein klein beetje opgewekter dan vorige post

Splines

Ik word er stilaan horendul van: na een kleine twee weken te zoeken achter een deftig pakket voor splines te modelleren in C++ heb ik er nog steeds geen gevonden dat minimaal aansluit bij wat ik nodig heb (een simpele manier om een spline-curve te modelleren op basis van een set van punten), en dat duidelijk gedocumenteerd is.

De libraries die ik heb onderzocht zijn:

• Geometrictools (www.geometrictools.com: erg onduidelijk gedocumenteerd, en, volgens wat ik er kan uit opmaken na bestuderen van de curve-klasse en de voorbeelden (die zowat alles exhaustief illustreren buiten het gebruik van de curve-klasse) geen mogelijkheid om enkel op basis van punten een curve te modelleren. Je moet er namelijk afgeleide(n) en normaal in het punt meegeven, wat geen gegevens zijn waarover ik beschik als ik bijvoorbeeld het gevolgde pad van iemand die interactief door een virtuele scene loopt wil samplen.
• De (aangepaste ?) versie van Geometrictools zoals beschreven staat in het boek 3D Game Engine Design, en dat op de bijgeleverde CD te vinden is. Volgens de website van Geometric Tools zou dit boek de documentatie bij hun library zijn, maar de referenties op de site kloppen totaal niet, en het boek levert in het hoofdstuk Curves niet meer dan een wiskundige uitleg over splines, en totaal geen uitleg bij de code of het gebruik ervan.
• NURBS++ (http://sourceforge.net/projects/libnurbs/), een library die zoals de naam al doet vermoeden NURBS-curven en -oppervlakken modelleert in C++. Ook hier was de documentatie zeer ondermaats. Op de site van het project is wel een paper te vinden die verscheidene eigenschappen van splines beschrijft en de generatie van curves illustreert, maar de documentatie is onvolledig (zegt de auteur zelf), en is sinds 2002 in onvolledige staat gebleven. Dit pakket laat wel toe op basis van punten een curve te genereren, maar vraagt ook nog een aantal andere parameters waarvan ik ook na het lezen van de 'documentatie' geen idee heb wat ze zijn.
• Diverse andere pakketten die beweren dat ze dienen om curves te modelleren maar eigenlijk enkel functies (en in de meeste gevallen dan ook nog enkel 2D-functies) blijken aan te kunnen, als je wat dieper in de documentatie graaft.

Er zijn nu drie mogelijkheden om mijn splineprobleem op te lossen. Ofwel blijf ik voortzoeken naar het ideale pakket tot ik het vind en mijn problemen op magische wijze verdwijnen (iets wat elke dag en met elke google-beurt onwaarschijnlijker wordt), ofwel blijf ik doorgraven in de documentatie van NURBS++ totdat ik uitvis wat de ontbrekende parameters zijn of erachter kom dat ook deze library totaal niet geschikt is, ofwel schrijf ik mijn eigen spline-klasse.

Mijn persoonlijke voorkeur gaat momenteel uit naar die laatste course of action. Op die manier kan ik de klasse perfect integreren in de PBRT-manier van werken (voorstellingen van punten etc.) zodat ik achteraf geen bridge tussen PBRT en het andere pakket moet gaan schrijven, ben ik er zeker van dat de klasse precies de opties gaat bieden die ik nodig heb, en weet ik zeker dat ik de intenties van de auteur bij het schrijven van de code ga begrijpen.

Nadelen hiervan zijn dan weer dat ik er extra tijd moet insteken, terwijl de tijd toch stilaan begint te dringen, dat er altijd het risico bestaat dat ik fouten maak met betrekking tot die splines, en dat het computationeel lang niet zo efficiënt (of erger: nauwkeurig) is als professionele pakketten zouden zijn. Anderzijds, betreffende dat laatste nadeel: ik heb ook niet de indruk dat NURBS++ zo ongelooflijk professioneel is, dus ook daar reken ik op een zeker risico qua efficiëntie en nauwkeurigheid.

Ik ga mij alvast voor de rest van vandaag (althans tot ik advies heb ingewonnen van Toon) opnieuw verdiepen in mijn cursus Numerieke Modellering en Benadering. Als ik zelf een spline-klasse ga schrijven zal ik het nodig hebben, zoniet kan het geen kwaad nog eens precies op te frissen hoe het ook weer allemaal werkte (de beschrijvingen waarop ik ben gestoten bij het researchen van de verschillende libraries waren nooit echt uitgebreid of diep wiskundig, de uitleg in het boek was wel wiskundig, maar gaf vooral een overview van verschillende soorten curven zonder echt diep op algoritmische details in te gaan). Nog verder zoeken naar splines op het web zie ik momenteel niet zitten.

Wat ik ook nog plan te doen vandaag is nog eens wat prentjes maken (dat is altijd goed om de moraal op te krikken), en een beetje research te doen naar de Maya-PBRT plugin en de mogelijkheden daarvan.

B

Planning (2)

Vorige week had ik met Toon mijn planning besproken tot het einde van dit semester. Die staat nog niet online, dus bij deze:

6/11 - 13/11: mogelijkheid uitwerken om een spline in te lezen in het invoerformaat van PBRT (eentje om het pad voor te stellen, eentje om de kijkrichting voor te stellen)

14/11-27/11: Maya, MEL en de Maya -> PBRT plugin bestuderen en aanpassen: een spline gedefinieerd in Maya uitschrijven naar PBRT, en proberen om bij het interactief lopen door een scene of het bewegen van de camera een spline te halen die naar PBRT kan worden uitgeschreven

28/11-11/12: Uittesten van de mogelijkheden die de viewer in Maya biedt, en of er dan interactief een multiperspectief beeld kan worden opgebouwd. Zoniet kijken wat mogelijk is met een OpenGL viewer.

Ondertussen kan ik ook melden dat ik nog geen spline kan inlezen, omdat ik nog geen goede C++ library hiervoor heb gevonden (ik probeer nu de fijnere puntjes van GeometricTools uit te zoeken), maar ik heb wel het invoerformaat van PBRT uitgebreid om vectoren van punten in te lezen, die dus kunnen dienen als basis voor de spline. Door verschillende deadlines (4 in totaal) heb ik dat vorige week dus niet kunnen afwerken.

B

Tweetuit

Nog snel een mooi prentje posten dat ik van het weekend heb gerenderd, voor ik naar Toon vertrek: dezelfde theepot als vorige keer, maar een camera die rechts vertrekt en daar naar links kijkt, en vervolgens naar links beweegt en naar rechts gaat kijken.

Prentjes!

Ik denk er zopas aan dat ik dit nog niet gepost heb: daarstraks ben ik er in het graphicslabo wél in geslaagd mijn eerste pbrt prentjes te renderen.

Even uitleg bij wat u ziet: het camerapad in elk prentje is een parametrische functie (drie coördinaten in functie van 1 parameter t, die 0 is helemaal links in het beeld en 1 helemaal rechts). Van boven naar onder zijn 1 en 4 stilstaande, gewone camera's, 2 heeft als pad (t, 10t^2, 0), en 3 en 5 hebben als pad (-5t^2, 30*(t-0.5)^2, 0). Ik had zeer graag nog wat doorgeëxperimenteerd, maar helaas moest ik naar de les, en werkt pbrt op mijn machine nog steeds niet. Als u zich zou afvragen wat die randen boven- en onderaan sommige van de prentjes zijn: mijn tooltje om afbeeldingen van het formaat dat pbrt uitspuwt te converteren naar een formaat dat blogger aankan werkt òòk niet.

Bon, bedtijd.

B

Problemen

Hoog tijd om hier nog eens een update aan te brengen.

Het thesissen lukt helaas minder vlot dan verhoopt, de laatste twee weken een stapeltje problemen gehad. Na de euforie van een degelijke presentatie ben ik begonnen aan 'het echte werk': het schrijven van een plugin voor PBRT (een academisch renderprogramma, voor de niet-graphicsmensen die ook dit blog volgen), die automatisch multiperspectief beelden genereert door middel van een nieuwe camera-implementatie.

Hiervoor moeten we natuurlijk eerst deftig weten hoe PBRT in mekaar zit. Dat is gelukkig goed beschreven in een boek, maar dat was uiteraard op dat moment uitgeleend in de campusbibliotheek. Ik heb het dan meteen gereserveerd, blijkbaar perfect gelijktijdig met een ander groepje thesissende studenten, zodat ik met hen maar ben overeen gekomen dat ik het boek enkele dagen zou houden, en het dan aan hen zou uitlenen.

Die paar dagen (die ook nog gevuld waren met andere werkjes) waren echter niet genoeg om een volledige systeemoverview te krijgen, dus heb ik het boek ook maar besteld. Gelukkig kon Toon ook nog een tussentijdse oplossing voorzien, zodat ik ondertussen verder kon.

Dan moest die PBRT natuurlijk ook nog geïnstalleerd geraken, wat ook niet zo straightforward bleek (de bij het boek bijgeleverde binary werkte niet naar behoren, dus was het compilen van de source geblazen, en daar horen wel wat dependencies bij. Maargoed, dat was dan uiteindelijk gefikst en de eerste renderings van de bijgeleverde voorbeeldscènes liepen heel vlotjes.

Ondertussen was de nieuwe versie van Mac OS X, Leopard uitgekomen. Apple-fan als ik ben heb ik dat meteen gekocht, maar de installatie op zich leverde al heel wat extra problemen op, waar ik hier niet dieper op zal ingaan. Wat wel belangrijk is: toen die waren opgelost (en na nog eens extra installatie van alweer een nieuwe versie van XCode) kon ik opnieuw aan de slag aan mijn PBRT-plugin. Tweede grote mijlpaal, na de eerste prentjes: de eerste lijntjes code. Altijd tof, programmeren, niets zo verfrissend als avonden voor de boeg gevuld met klassen, code en cola. Plugin geschreven, PBRT mét plugin hercompileren, ... problemen. Onleesbare errorboodschappen zelfs. En gezien ik op dat moment op de trein zat, en uw opties zonder internet sowieso eerder beperkt zijn, sloeg de frustratie meteen toe. Eenmaal thuisgekomen had ik dan het briljante plan opgevat PBRT eens opnieuw te downloaden, en de source eens clean te compilen. Wonderwel, het werkte!

Dan nog maar eens compilen mét mijn plugin: leesbare errors. Een hele vooruitgang op onleesbare errors, daar kan een mens tenminste wat mee. De fouten oplossen namelijk. En dat ging nog vrij gemakkelijk, in een mum van tijd had ik geen errors meer. Tot ik effectief probeerde een scène te renderen dan toch. PBRT geeft ondertussen segmentation faults. Voor de niet-technische mensen die dit blog volgen: dat wil zeggen dat er geschreven/gelezen wordt naar/van een stukje geheugen dat niet toegankelijk is (tenminste als ik mij niet vergis, de technische mensen die dit blog lezen mogen altijd corrigeren). En dat wil zeggen: oh-oh. Zeker voor iets dat voor die installatie van Leopard wél nog werkte. Ook daar heb ik weer lang op zitten zoeken en prullen, maar daar is tot op dit eigenste moment nog geen oplossing voor gevonden.

Wat nu? Zo dadelijk ga ik maar eens proberen op de pc's van het graphicslabo, kijken of het daar wel werkt. En als het werkt, kijken of ik dan gekke prentjes krijg. Zoja zal ik ze meteen posten hier. Verwezenlijkingen zijn altijd leuker om te posten (en zullen dus sneller gebeuren) dan tegenslagen...

En zo hebben we ook weer geleerd dat thesissen een proces is van vallen en opstaan.

B