Logboek 16-5-2023

Het team is bezig met het ontwerpen van hun eigen boom en de groei animatie ervan. Titus doet de cacao bomen, de cedrela odorata en de mango. Lisa doet de grond, de khaya ivorensis, de mansonia altissima en de kokosnoot. Ikra doet de terminalia superba en de terminalia ivorensis. Ik doe zoals eerder aangegeven de bananenboom, de cashew en de entandrophragma angolense. Op dit moment zijn mijn boom en bijbehorende animaties succesvol voltooid en getest. Zo kunnen ze, zo nodig, overal ingezet worden om een vrij realistische boomgroei te visualiseren.

De bomen waren niet in een dag gemaakt. Eerst moest ik concluderen dat alles wat ervoor was ontworpen door mij niet voldeed aan de eisen. De exacte gegevens van de specifieke planten moesten genoteerd worden in het team-archief. Zowel de bananenboom als de entandrophragma angolense waren makkelijker te vinden op het web. Maar de specifieke cashewboom was een ander verhaal. Deze heeft vele synoniemen en de aandacht was meer gericht op de noot in de verschillende bronnen die ik tegenkwam. Uiteindelijk bleek niet alle informatie vindbaar te kunnen zijn binnen het bereik van de tijd die gegeven was. Echter waren er wel genoeg gegevens om een vrij rendabele boom te ontwikkelen. 

De nieuwste versies van de drie soorten waren dan ontworpen. Deze waren correcter, vergelijkbaarder en waren uitstekend voor de animatieonderneming. Voor zowel de cashew en de entandrophragma angolense had ik drie verschillende groottes gemaakt, waardoor de animatie er nog zuiverder uitzag. Voor de bananenboom was dat niet nodig, vanwege de hoge groeisnelheid en de kleine veranderingen naarmate de leeftijd toenam. Wat wel opmerkelijk was, was dat ieder in het team een andere stijl van ontwerpen produceerde. Wat heeft dit voor invloed op het uiteindelijke resultaat? Dat zal zichzelf uiteindelijk onthullen.

De laatste stap vereist de grootste inspanning van de computer. In mijn tijd als ontwerper in Fortnite Creative moest ik altijd opletten niet teveel geheugen te verbruiken, omdat de limiet beperkt was. Ook wel "memory besparend bouwen" genoemd. En dit geld ook voor blender. Er was voorzichtig nagedacht over elke buiging, strook, maar ook kwaliteit om een evenwicht te behouden tussen realisme, ethiek en geheugen besparing. Het bleek niet helemaal genoeg te zijn. Ik verklaarde aan het team dat 50 frames per jaar een acceptabele constante is. Ook al wist ik dat de opdrachtgever vroeg om een video van 5 minuten en met 50 frames per jaar zou de animatie circa 1 minuut zijn. Met 1 minuut zou mijn computer een laadtijd moeten afleggen van maximaal 11 uur. Ian vond dit geen logische wachttijd. Zo kwam de video voorbij:

https://youtu.be/gICWynCU9a8<br> 

Deze hielp met het verlagen van de rendertijd. Het zou mogelijk 3 tot 7 uur duren. Blender begeeft het meestal na anderhalf uur bij mijn computer en dan was de rendervoortgang ook vernietigt, dus dit was een stap in de goede richting maar geen acceptabele oplossing. Ik had nog alleen de laatste truc achter de hand en dat is segregatie. De video van circa 1 minuut wordt verdeeld in drie delen en later terug aan elkaar vast gehecht in een video-editing-software. Deze methode is amper getest, toch is er zekerheid dat het dit keer zal slagen.

Het volgende traject dat het team zal doorlopen is het combineren van alle planten tot een plantage. Het zal eruit zien zoals onze opdrachtgever het voor ogen heeft. De animatie laat een periode over dertig jaar zien, waar de vlakte tot leven komt en rijk is aan biodiversiteit. En de animatie zal renderen met meer dan honderd gepositioneerde bomen. Hier is nog niet in te schatten hoeveel tijd dat van de voortgang zal consumeren. Ik verwacht, dat ik nog steeds de video mag bewerken.

Logboek 7-6-2023

Eerst moest er een plattegrond worden gemaakt van de beschrijving van de ideale boerderij van de opdrachtgever. Van die plattegrond is een foto gemaakt. Om die foto naar blender te verplaatsen wordt gebruikgemaakt van een ''plain''. Wanneer een ''plain'' geplaatst is via ''add'' dan wordt er geklikt op ''materials''. Bij ''base'' komt een grote lijst tevoorschijn en dan wordt er geklikt op ''image texture'' en daarmee kan een plaatje op de eigen computer worden opgezocht. Zo ziet u dat de plattegrond is geplaatst, maar geperst tot het vierkant van de ''plain''. Om dit op te lossen moet er worden gekeken naar de foto verwerking op de telefoon. Daar kunnen de verhoudingen van elk plaatje weergeven worden. Het plaatje bleek 3:4 te zijn. Met de ''assen die blokjes vormen'' en het ''z-perspectief van boven naar beneden'' kan er van bovenaf duidelijk de verhoudingen van het plaatje bekeken worden. Zo kan je met een paar simpele muisklikken en vegen de verhoudingen van de ''plain'' aanpassen, zodat onze plattegrond klopt. Maar dat was nog niet alles. Voor de techniek die gevonden was kan een boom worden verbonden met meerdere ''vertices'' van een apart object. Zo hoeft niet elke boom een ''make instances real'' te krijgen en kan er bespaard worden op ''RAM memory'' en hoeft de pc niet te crashen door overbelasting. Daarna moet er voor elke punt waar een boom moet komen een ''vertices'' komen. Dat wordt gedaan met ''mesje''. Met ''mesje'' worden de verticalen en horizontalen gesneden, want dat zou het makkelijkst moeten gaan. Echter bleek uiteindelijk dat de foto die genomen was door de telefoon een afwijking was van 1,31 graden. Aangezien het oog niet bedoeld is om exact 90 graden hoeken te kunnen herkennen en de handen te veel ongewenste bewegingen maken, is het beter om de plattegrond zelf in blender aan te passen. Zo werd er gebruikgemaakt van ''UV editing''. Voorzichtig werden alle hoeken in de ''UV editor" achter elkaar steeds opnieuw verschoven, waardoor de hoeken van de plattegrond in balans waren met de horizontalen van de blender wereld. Daarvoor moeten die hoeken wel een duidelijkheid vertonen en was er met ''meet streep'' en de ''shortcut keys: x en y'' vier 90 graden hoeken gemaakt. Daarna moest opnieuw met ''mesje'' gesneden worden totdat er genoeg ''vertices'' een plek creëren voor een boom.

En zo kwam de eerste bomen test. Met de cacao boom werd getest, want van die waren het er het meest. De cacoa boom werd geselecteerd en de ''plain'' ook; met ''control p key'' moesten de objecten veranderen in ''parents'' van elkaar. Wel moest daarvoor de optie ''object (keep transform)'' voor worden in geklikt. En daarna in de rechter ''bar'' gaan naar ''Plane'' en zo naar ''instancing'' met daarop staat de ''default'' op ''none''. Die moet dus staan op ''vertices''. Toen bleek het dat de bladeren van de cacao ongewenst gedrag vertoonden en teniet zijn gegaan. Daarnaast keken alle bomen dezelfde richting in. Ze waren een identieke groep. Een verklaring hiervoor was niet te vinden. Zo werd er geklikt op ''make instances real'' en crashte blender, dus ging het over op het volgende gedeelte. Met het volgende gedeelte worden de andere bomen bedoeld. Het geniale plan om wat van de identieke bomen te ''disablen'' was om een secundaire boom te instaleren die alleen verschilt van kijkrichting. Voor dit alles kon gebeuren moest eerst onderzocht worden hoe ''key frames'' verplaatst kunnen worden. Het bleek dat de verplaatsing van de boom zelf niks oplevert, want de animatie is sterker dan een externe muisveeg die alleen de uiterlijke verplaatsing kan veranderen, maar het ziet er al snel uit, wanneer de animatie wordt gestart, dat het verplaatste deel wordt terug getrokken door de kern van de ''keyframes''. Er is ontdekt dat er twee manieren zijn om een animatie zo te beïnvloeden dat er daadwerkelijk ook iets verplaatst. De eerste manier die ontdekt werd was dat er in de ''plane'' van een object een ''setting'' staat voor ''delta transform'' voor ''location'', ''rotation'' en ''scale''. Maar let op. Elk object heeft een individuele kern en daarvoor moet elk object op een individuele manier verplaatst worden. De tweede manier is toch het veranderen van het object op een externe manier, via muisvegen. Daarna moest geklikt worden op ''clear single keyframes'' en dan waren de nieuwe coördinaten van het object gevestigd. Echter waren er wel scheuren in de tweede manier, want het bleek dat de animatie een verandering onderging. Wat er van buitenaf werd gezien waren objecten die niet gingen naar de plek waar ze moesten zijn. De ''key frames'' waren defect en moesten opnieuw geprogrammeerd worden, zodat ze niet ongewenst gedrag vertonen. Echter was dat wel riskant, want het kon zo zijn dat er een kwaliteitsverlies zou optreden. De conclusie was dat de tweede manier geen goede manier was om animaties te verplaatsen. Er werd daarom besloten om de begane grond omhoog te laten gaan, want de ''control p'' en daarna select ''vertices'' techniek om het daarna te zetten bij ''instancing'' zorgt er ook voor dat de ''origineel'' ook blijft bestaan, waardoor die op een verkeerde coördinaat zit, de kern van de coördinaten object is samen met de kern van de originele boom verbonden. Verder zitten de bomen op ''spawn'' vaak ook op de ''default'' begane grond, waardoor die op dezelfde horizontaal kan zitten als de hele boerderij en dat kan ongewenst zijn voor de toekomstige achtergrond. Er is dus besloten om de begane grond van de boerderij te verhogen.

Zo moest de object coördinaten geconstrueerd worden. Twee voor elke boom. Eerst wordt de plattegrond gekloond naar het kader die de coördinaten van de cacao bezit en worden die coördinaten geëlimineerd, maar de plaat blijft. Daarna wordt er zorgvuldig met ''mesje'' de specifieke coördinaten gesneden van de boom. Van die object coördinaten worden nog twee gekloond. Bij eentje elimineer je de helft van de ''vertices'' en bij de andere de andere helft, zodat ze elkaar aanvullen en de bomen van dezelfde soort twee verschillende richtingen in kijken. Daarna wordt eentje terug geplaatst in het kader. De eerste boom werd ingezet voor de boerderij. Van ongeveer 120 meter onder de boerderij worden de kernen van de object coördinaten op dezelfde locatie geplaatst als de boom. Zo zijn de twee kernen indirect geconnecteerd. Daarna wordt de boom in totaal en de object coördinaten geselecteerd en met ''control p key'', ''object (keep transform)'', ''Plane'', ''instancing'',''default: none'' naar ''vertices'' en dan zijn de bomen er. Maar voor de boom die in de andere richting kijkt moet de ''origineel'' worden gekloond met ''shift d'' en daarna met een verschil van besloten 30 meter verplaatst moeten worden met de ''delta transform(location): x''. Daarna gaat ''delta transform(rotation): z'' de rotatie van het object veranderen. Daarna moet de tweede object coördinaten in de kern op dezelfde locatie zitten als in het kader als de boom. Het handige is dat de kern en object aan elkaar verbonden zijn, maar op gebied van verhouding en niet van locatie. De verhouding kan alleen verandert worden in de ''editing'' van de object. Dit zelfde methoden wordt meerdere keren herhaald voor elke boom.

Een van de bomen had echter een ''as'' verbonden met het gebied waaruit de boom zou groeien en mogelijk ook met de kern van de. De ''as'' was verbonden met de boom en gaf ongewenst gedrag aan animaties van de boom. Wanneer die werd gekloond werd waren de kernen van het origineel verbonden met de kloon en vertoonde een defecte reactie. Ander storingen treden op bij de verbinding met de object coördinaten. De boom groeide op een alternatieve wijze, wat niet voor hen zo bedoeld waren en kon niet een functionele bijdrage leveren. Wanneer de ''as'' geëlimineerd kon worden kon de boom weer efficiënt worden ingezet. Verder was de cacaoboom van een te grote omvang en het defect van de bladeren bij de kloon 's. Voor niet alle bomen is dit een probleem, maar van de cacao werden veruit de meeste van ingezet. Het zou te veel van de capaciteiten in de pc vragen en hem uitputten tot het programma crasht. Dus is de cacao gereconstrueerd met minder ondersteuning van de ''vertices'' in het object en zonder de animatie. Zo kan het uiterlijk van cacao efficiënter worden ingezet voor de boerderij zonder dat het de diensten van de pc te veel worden belemmerd.

De ''render'' van de video is ook een onderwerp op zichzelf. Het cameraperspectief en de camerabeweging moeten worden bepaald met "keyframes". En het renderen van een minuut kan wel 6 uur lang duren met de zelfs beste settings. Het is belangrijk om de ''sampels'' en ''time limit'' laag te houden. Verder moet het in delen worden gerenderd, want als de computer 6 uur lang achter elkaar rendert is de kans op crashen groter en is de render voortgang verloren gegaan.