Installeren en belichting

De vorige keer heb ik stilgestaan bij een PovRay versie voor een DOS-doos. Dat leek een beetje buiten de normale gang van zaken te vallen maar ik voelde aan mijn water dat het niet lang kon duren of een deskundige Atariaan zou de versie 3.1 gaan overbrengen naar onze computers. En dat is gebeurd door Mr. LeCoat uit Frankrijk, zodat ik deze keer ga vertellen hoe we allemaal moeten handelen bij de overschakeling. Bij het rondneuzen op het net kwam ik een vermelding tegen dat er iets nieuws was voor PovRay. Wat verder nazoeken leverde op dat in de FTP-site van Martin Byttebier in België de spullen te vinden waren. En inderdaad kon ik met behulp van aFTP heel makkelijk diverse versies voor onze CPU's downloaden. Als het goed is zijn deze versies (voor 68000, 68030 (+68060) en 68040) in de Public Domain bibliotheek van de Stichting ST te vinden (red: zie de betreffende rubriek want ze zijn er!). Ten eerste de afmetingen. In alle gevallen ligt de grootte van het programma zo om en nabij de 700 Kb. Het is dus onbruikbaar voor de 520 ST (met maar een halve Mb aan geheugen) en ook inzet op een 1 Mb machine is heel twijfelachtig. Wat betreft snelheid: die verschilt niet zoveel van onze vorige versie 3.01. Verder: deze versie is door Mr. LeCoat uit Frankrijk als een .TTP uitgevoerd en niet als een GTP. In bepaalde opzichten is dat jammer, maar echt lastig hoeft het niet te zijn.

TTP-en

Cursisten die de veel kleinere versie 2 gebruiken zullen geen last hebben met de overgang want zij gebruikten al een TTP versie. Wel doen ze er goed aan om eens even terug te lezen hoe de versie 3 in gebruik wordt genomen want we hebben hier weer te maken met .ini files. Voor de andere mensen ga ik het verder toelichten. De meeste mensen zitten te werken onder gewoon TOS. Dan is de manier van werken simpel: dubbelklik de povray.ttp die in een directory venster zichtbaar is. Het systeem komt met een box ophet scherm waarin iets getypt moet worden. In ons geval het volledige pad van de gebruikte .ini file. Ga niet proberen om de ini-file te droppen op de povray.ttp want het is geen GTP en kent geen drag&drop en/of AV-protocol. Wat wel kan is: aanmelden bij de desktop als applicatie die zorgt voor de ini-files. Dan kan een dubbelklik op de ini-file de zaak op gang brengen. Onder multitasking is het allemaal wat lastiger om goed op te zetten. Ik herinner mij van heel vroeger dat je b.v. met MiNT een (1) GEM-applicatie kan draaien en heel veel andere taken parallel kan laten uitvoeren zolang die anderen maar ttp's zijn. Met dit in gedachte probeerde ik het maar helaas, zodra onze povray.ttp aan de gang gaat kom je er niet meer tussen: de muispointer verdwijnt en dan kan je weinig meer doen. De vraag is: hoe kan je dit omzeilen? Ik heb heel wat zitten proberen maar kwam niet tot een simpele oplossing. We moeten nogal wat extra's doen. Ten eerste moeten we zorgen dat de uitvoer naar het scherm netjes in een venster terecht komt. Dat lukt meestal wel: zo heb ik met desktop Thing en N.AES een speciaal console-venster voor dit doel en ook is er nog eens een tos2win venster dat ook uitvoer van programma's onderschept en netjes in een venster toont. Maar helaas, het kan aan mij liggen maar ook aan de TTP: met de uitvoer in zo'n venster is de muispijl nog steeds zoek. Gelukkig is er een zgn. 'miniwindow'- applicatie. Gooi je daar een TTP bovenop dan wordt die actief en produceert een eigen console-venster op het scherm (dat wordt dan de derde maar dat kan de pret niet drukken). Meestal wordt in een console venster een commandline interpreter gebruikt. Ik heb de wel bekende 'Mupfel' uit de kast gehaald (die zit bij de Gemini desktop, ook te vinden ergens in de PD) want die kan parallel ttp's starten. (red: op disk A 671)

Ik zorg dat er op het scherm een ikoon staat van miniwin.app. Daarop laat ik dan de mupfel.ttp vallen (drag&drop) en een console venster springt te voorschijn. Daarin staat een $-teken en een knipperende cursor. Nu komt de clou: we gaan helemaal niets intypen. We openen een directory-venster waarin povray.ttp te vinden is, klikken hem aan en slepen die naar het console venster. Na loslaten zal de volledige pad-naam in het venster staan op de commandline van Mupfel. Vervolgens doen we hetzelfde met onze ini-file. Gemak dient de mens en we hebben zo een regel tekst gekregen waar wat mee gedaan kan worden door Mupfel. Een simpele <return> activeert het samengestelde commando en PovRay komt op gang. Meldingenverzamelen zich in het venster. En wonder boven wonder: we hebben ook weer een muis-cursor waarmee we verder kunnen werken terwijl in de achtergrond PovRay staat te werken. Ik merk wel een langzamer reageren van het systeem: de desktop werkt minder vlot, maar dat is een kwestie van tijdtoewijzing. De time-slices wat veranderen en de desktop reageert weer vlotjes. En hoe time-slices veranderd worden (tijdtoewijzing aan programma's) is te vinden in handleiding van jouw multitasking operatingsysteem.

Environment

Er wordt, indien aanwezig, gebruik gemaakt van de environment variabelen. Bij multitasking bestaan die maar bij gewoon TOS moet je ze met een extra programma ze aanmaken. (b.v. S_Env op PDdisk A 705 is hiervoor, geplaatst in de autofolder, zeer bruikbaar.)

In elk geval is er een POVINI die het pad moet bevatten voor de default file met instellingen: povray.ini. Ook is het nu de gewoonte geworden om uitvoerfiles, waarvan niet is opgegeven waar ze moeten komen, te plaatsen in de directory die met 'home' wordt aangegeven. Ik was dan ook verbaasd (maar niet voor lang) toen files zoals fatal.out en all.out opdoken in mijn c:\multitos\ folder. Wat betreft het gebruik van de ini-files valt niet veel nieuws op te merken: eerst gebruikt Povray zijn eigen ingebouwde defaults en gaat dan zoeken naar de povray.ini file. Is die gevonden en ingelezen dan wordt de door de gebruiker opgegeven ini-file ingelezen gevolgd door eventuele opties die ook nog in de commandline kunnen staan.

Handig grapje

Het niet goed instellen van defaultwaarden kan op onze Atari-computers tot rampen leiden: PovRay start wel op maar stopt zonder opgaaf van reden. En dan is het zoeken en proberen wat er aan de hand kan zijn. Gelukkig kan je nu opgeven dat in een file alle opties moeten worden geschreven die er actief zijn. Dan kan je ongerechtigheden in je eigen ini-file gauw opsporen. Deze voor jouw gemaakte ini-file kan je ook gebruiken om zeker te zijn dat je met precies dezelfde opties gaat renderen als de vorige keer in geval een trace onderbroken is geraakt.

Batch files

Gelukkig hebben we geen Windhoos systeem: dat moeilijk knutselen met de exec.bat is er voor ons niet bij. Maar ik moet toegeven dat het zetten van de environment ook niet erg makkelijk is. Of je hebt een speciaal programma daarvoor nodig of je moet gaan knoeien aan een configuratiefile van je multi-tasking system (met als toegevoegde moeilijkheid dat je pas na een reset iets van je veranderingen bemerkt). Er is een andere manier. De al eerder vermelde command-interpretor 'Mupfel' heeft vele mogelijkheden. Ik gaf al een voorbeeld van hoe je een commandline kon opbouwen door het slepen van files op het venster, maar er is meer mogelijk. Ook Mupfel kent batch-files, of script-files of macro-files of hoe ze nog meer mogen heten. Dat houdt in dat met het intypen van een paar letters hele complexe reeksen opdrachten kunnen worden afgehandeld. We gaan dit netjes opzetten.

Mupfelen

Bij de Nederlandse versie van de desktop Gemini (in de PD van de Stichting ST te vinden) zit een uitgebreide handleiding voor Mupfel, vertaald door Henk Radersma in 1994. Daaruit blijkt dat er heel wat mogelijk is. Gelukkig hoeven we maar een paar dingen te weten. Ten eerste: 'hoe stop je Mupfel?' Door in te typen 'exit' (zonder quotes). Verder kan je een hoop typewerk besparen. Dat geldt natuurlijk niet als je multitasking doet en Mupfel draait via MiniWin door te zeggen (bijvoorbeeld): cd g:\povray\ oftewel 'change directory' maakt het mogelijk om vervolgens op te geven: povray g:\povray\werk\xxx.ini Ik vermeldde in het voorgaande ook de environment variabele. Typ je in: env dan komt er een lijstje met alles wat bekend is over de huidige environment. Iets toevoegen gaat met: setenv POVINI G:\povray\povray.ini Ook is het handig om te weten dat met de toets 'pijltje naar boven' je de voorgaande ingetypte regel krijgt. Die kan dan bewerkt worden (ge-edit) en met een 'Return' uitgevoerd worden.

Aan het werk

Met behulp van de voorgaande tekst moet iedereen in staat zijn om PovRay versie 3.1 werkend te krijgen. Lukt het niet kijk dan eens of er ergens een file met de naam fatal.out te vinden is of all.out. Als laatste redmiddel: kijk de povray.ini file na of daar geen verkeerde dingen in staan. Neem dan ook je eigen .ini file nog eens onder de loep. Voor cursisten die deze cursus in schriftelijke vorm volgen is de opdracht: lees de vorige les eens na. Speciaal dat gedeelte over 'interior' en 'media'. Kijk eens in de folder met de naam 'scenes' want daarin zitten demo-voorbeelden voor de nieuwe syntax (folders interior en media) en voor het gebruik van mist.

Belichting

Uit vragen van cursisten is mij gebleken dat nog niet iedereen een goed begrip heeft van de verlichting zoals we die gebruiken. Laten we beginnen met het eindresultaat. Normaal krijgen we een Targa-file als output. Dit is een zgn. 'true-color' plaatje. Er is notatie voor 3 kleuren apart en ieder voor zich worden ze in 255 stapjes genoteerd. Er wordt ook wel gezegd dat er 3x8=24 bits kleur is. Als we nu even gaan omdenken in grijstinten dan zijn er 255 verschillende grijstinten mogelijk. Ik kan verzekeren dat ons oog last heeft om zoveel gradaties te onderscheiden. Daar komt bij dat monitoren een kontrastverhouding hebben van 1 op 300 en een verschrikkelijk gaaf video-signaal nodig hebben om die 255 stapjes te kunnen afbeelden. Onze PovRay camera is heel eenvoudig in de bediening: geen sterptestelling, geen belichtingstijd, geen diafragma e.d. Hoe donker of helder de scne eruitziet hangt niet van de camera af maar van de verlichting. Daar ga ik over door. Verlichting

Brengen we geen verlichting aan dan zien we maar bar weinig van onze scne. Willen we zonlicht hebben dan kunnen we heel simpel:

light_source{ <500,500,-500>
color White }

opgeven. Tenminste als onze scne zich afspeelt zo ongeveer 40 eenheden binnen de oorsprong. Het licht valt op deze schaal dan nagenoeg evenwijdig de scne binnen net zoals de zon dat doet. Ga je de lichtbron dicht bij je objecten plaatsen dan wordt het voor ons oog gauw lastig om kop en staart te zien vanwege rare schaduwen. Een lichtbron in het blikveld van de camera tussen voorwerpen in is helemaal verwarrend want de lichtbron zelf is onzichtbaar en werkt niet als referentiepunt voor ons oog. We weten allemaal dat naarmate je verder van een lichtbron verwijderd raakt dat dan de hoeveelheid licht die op een oppervlak valt afneemt met het kwadraat van de afstand. Onze lichtbron werkt zo niet: of een vlak dichtbij of heel veraf staat maakt niet uit voor de lichthoeveelheid die erop valt. Leg maar eens een tegelvloertje neer en hang er een lichtbron boven. Tot aan de horizon kan je het tegelvloertje nog zien. Wel natuurlijk is het effect dat als een vlak zich steeds meer afwendt van de lichtbron, dat dan de lichthoeveelheid die erop valt afneemt. We zien dit als we b.v. een bol verlichten. Naarmate het licht het oppervlak schuiner treft wordt de mate van verlichting minder, net als in de werkelijke (dus niet-virtuele) wereld. Daardoor ziet de bol er niet uit als een platte schijf maar echt als een bol. Kijk maar eens in de figuur waar geprobeerd is dit effect aan te geven. Voor de duidelijkheid heb ik het ook nog eens getekend voor een lichtbron vlakbij een vlak wanneer de stralen niet evenwijdig invallen. Wat we eigenlijk missen is een lichtverzwakking door de afstand. Maar ook daar is op gerekend. Je kan de lichtbron een fade_distance opgeven en een fade_power. Het is alleen zinvol in te zetten als de lichtbron dichtbij staat. Maar soms wil je het effect ook hebben van een verre lichtbron. Maar dan is het licht door de afgelegde afstand zo verdund dat je weinig licht overhoudt op je scne. Vandaar dat je het startpunt op moet geven van waaraf de lichtvermindering begint. Zuiver natuurkundig gezien is dat natuurlijk onzin, maar het is voor ons handig. Met fade_distance geef je een afstand vanaf de lichtbron op. Voor een natuurlijke vermindering is een fade_power van 1 voldoende. Is het effect wat minnetjes dan kan die waarde verhoogd worden naar 2 maar hoger zou ik niet gaan: je lichthoeveelheid neemt zo exponentieel met de afstand af dan je al heel gauw geen licht meer overhoudt. Nog even een waarschuwing voor het gebruik van die fade_distance. Worden er oppervlakten verlicht die op een afstand kleiner dan de fade_distance van de lichtbron af liggen dan kan er daar plaatselijk overbelichting optreden. Dit is zuiver een gevolg van de gebruikte rekenmethode en meer niet.

Lichtsterkte

Stel dat licht loodrecht valt op een middelgrijs vlak van color Gray50 waar we loodrecht op kijken. Hebben we een (1) lichtbron van kleur White die licht geeft dan zal in ons gerenderde plaatje we ook een halfgrijs kleurtje aantreffen. Weet u nog wel?:

255 stappen waar nu we precies middenin zitten; waarvoor we dus een waarde van 127 hebben in de Targa-file en naar we hopen met een goed ge-ijkt beeldscherm en de juiste gamma-instelling (zie de vorige lessen) ook de uitgestraalde lichthoeveelheid van de monitor halfweg tussen zwart en wit zit. Denk eraan: we geven nu eenmaal kleuren van voorwerpen op zoals ze eruit zouden zien als ze met White licht bestraald worden. Voor de duidelijkheid: White is gedefinieerd als color rgb<1.0, 1.0, 1.0>. Een voorbeeld: we hebben een scne met voorwerpen van maar een paar eenheden groot. We hangen een lichtje op:

Light_source { <0,20,0>
color Gray75
fade_distance 5
fade_power 1 }

Een lichtbron met een fade_power van 2 moet je een grotere fade_distance opgeven (10) in dit geval omdat het licht dat anders erg snel uitsterft. En dat werkt. Zou onze lichtbron verder weg moeten omdat we nagenoeg parallelle lichtstralen willen hebben dan moet je de afstand tot je scne schatten (zeg 500) om dan een fade_distance op te geven van 485 ongeveer om eenzelfde soort lichtvermindering te krijgen. Maar stel nu eens dat we onze scne met mist vullen, een beetje grauw van kleur met een 'Gray50' kleur. Onze lichtbron op 500 afstand zal dan niet genoeg licht opleveren om door zoveel mist heen schijnend nog wat licht over te houden. Wat nu? De kleur van de lichtbron ophogen! En wel tot 40000 * White. Dat lijkt raar, maar het werkt wel!

Vuistregel

Zwarter dan zwart en witter dan wit kan de zaak nooit worden. Het beste effect heb je als de totale belichting zo om de waarde 1 schommelt. Heb je 5 lichtpunten neergehangen, laat ze dan niet allemaal White uitstralen maar gemiddeld genomen Gray20. Zijn delen van de scne nog te donker, hang er dan een zwak niet-schaduwwerpend lichtje bij. Vergeet je om de no_shadow aan te zetten dat raak je van de regen in de drup omdat er te pas en te onpas schaduwen opduiken die je weer moet uitlichten enz. Ga je met mist enzo werken dan zuigt die licht weg. Zonder bezwaar kan de de lichthoeveelheid van een lichtpunt groter dan 1 maken. De scne kan ook te wit uitvallen: alle kleuren bleken weg alsof je een overbelichte dia ziet. Ga je verlichting dan wat temperen door 'Gray' licht te gebruiken.

Schaduwen

Meestal zijn schaduwen nooit naar onze zin. Ze zijn te donker en ze zijn te scherp; allebei gevolgen van de miezerige afmetingen van de lichtbron. Maar helaas, de beperkte rekenkracht maakt het niet mogelijk om lichtbronnen met volume na te doen. We zijn dus aangewezen op trucs. Voor de hand liggend is het natuurlijk om meer lichtbronnen te gebruiken. Enerzijds om de schaduwen wat minder donker te laten zijn en anderzijds om de lichtbron meer volume te geven. Voor dit laatste hebben iets speciaals:

light_source { <2,10,-4>
color White
area_light <5,0,0>, <0,0,5>,4,4 adaptive 1 jitter }

Wat we doen is: we hangen een (rechthoekig) rekje op met een aantal rijen lichtbronnen. De vorm en grootte van het 2-dimensionale rekje geven we op met twee vectoren. Aangezien het rekje rechthoekig is moet je twee vectoren geven die ook een rechte hoek met elkaar maken. We hebben dan dus zowel plaats, grootte als stand in de ruimte vastgelegd. Ook is opgegeven dat we 9 lichten hebben in rijen van 3. Het voordeel ten opzichte van het zelf met de hand de lichtbronnen per stuk neerhangen is de 'adaptive' en 'jitter' mogelijkheid. Een aantal van 9 lichtbronnen zal de rekentijd omhoog laten schieten. Door de lichten in een area_light te plaatsen kunnen allerlei grollen en grappen extra worden uitgehaald die de rekentijd verkorten (adaptive) en de schaduwen verzachten (jitter). Zonder jitter zal je toch nog banden zien in de schaduwen en ook zijn er nog steeds scherpe grenzen. Door de positie van de lichten een beetje te verschuiven krijgen de schaduwen een vaagheid erbij. Dan krijg je de mooie geleidelijke overgangen, precies wat je wil. Er is een eigenaardigheid: alleen in de schaduwen werkt een area_light door: overal waar het licht van alle lampjes op valt is het nog steeds alsof het een puntbron is. De vraag wordt gesteld: het zit het met de lichtsterkte? In ons voorbeeld wordt de White-hoeveelheid verdeeld over de 9 lampen in gelijke porties {rgb <1,1,1>/9}. Wil je een TL-buis achtige verlichting hebben dan kan je de lichten op een rij zetten.

Schijnwerpers

Wil je licht laten vallen op een beperkt gebied dan is de 'spotlight' een oplossing. Een lichtbundel die aan de randen afzwakt heeft natuurlijk wat meer attributen dan een gewone light_source. Behalve de plaats waar die hangt moeten we nu ook opgeven waarop de bundel gericht wordt. Dan zijn er typische zaken die het licht zelf betreffen. De kleur natuurlijk als vanouds maar ook zaken als de radius, de fall_off en de tightness die, zoals de namen als zeggen, opgeven wat de breedte van de hoofdbundel is, waar duisternis begint en hoe sterk de overgang tussen licht en donker verandert. Een voorbeeld:

light_source {<10,10,-10>
color White
spotlight radius 12
falloff 14
tightness 10 point_at <0,1,0> }

Stel we laten de lichtbundel loodrecht op een vlak vallen en we gaan met een belichtingsmeter door de bundel lopen. Wat meten we dan? Het is te zien in de figuur 1.

We treden de bundel binnen op het punt dat overeenkomt met de fall_off. Die wordt, eventjes voor de duidelijkheid, opgegeven als een hoek in graden ten opzichte van de fictieve middellijn. De lichthoeveelheid stijgt totdat ik de 'hot-spot' bereik, aangegeven door radius, ook weer in graden. De lichthoeveelheid blijft constant totdat we weer van de hotspot via de 'umbra' naar de duisternis gaan. Wil je een scherpe overgang dan maak je de radius amper groter dan de fall_off. Met een 'tightness' geven we op hoe het verloop moet zijn van volledig donker naar het helle licht. Waarden lager dan 10 maken de overgang stijler doordat naar het centrum toe er meer licht is en hoger (tot maximaal 80) maakt dat op de rand van het heldere gebied er zeer snel lichtvermindering optreedt. Zie de figuren 2 en 3. Ikzelf vind dat werken met spotlight erg lastig: je moet hoeken gaan opgeven en dat is een kwestie van uitproberen omdat de grootte van de lichtvlek ook afhangt van de afstand tot de scne. Vaak kan een vervanging van spotlight door 'cylindrical' helpen. We hebben dan nog steeds alle effecten van een spotlight maar het afstandseffect dat zo lastig is vanwege die hoeken vervalt. Probeer het maar eens en maak tegelijk de radius en fall_off hoeken wat groter. In het eerder gegeven voorbeeld: 20 en 30 graden is een goede waarde. Dit komt door de rekenmethode: licht wordt tot een cylinder beperkt en dan valt er wat overboord. Soms is het effect van een spotlight te erg. Per slot van rekening heb je nog steeds haarscherpe schaduwen. Maar er is niets op tegen om dergelijke lichtbronnen ook in een area_light te zetten. Maar vergeet niet wat ik gezegd heb over een area_light: het werkt alleen op de schaduwen. Voor de rest blijft je het effect van een puntvormige lichtbron houden.

Oplichten

Drie manieren dienen zich aan om te donkere delen die in de schaduw liggen van wat licht te voorzien. De simpelste is de ambient van het oppervlak te geven als ambient 0.2 wat tot gevolg heeft dat geen deel van het oppervlak donkerder wordt dan rgb < 0.2, 0.2, 0.2>. Wil je dit effect overal voor hebben dan is er een tweede manier: global_settings{ ambient_light Gray20} om dit voor elkaar te krijgen. De derde methode heb ik al eerder aangestipt: gebruik shadowless lichtbronnen.

Object geeft licht

Stel, je wilt een TL-buis als verlichting gebruiken die in je scne ook zichtbaar is als een object waar licht uit komt. We gaan als volgt te werk: we hangen de lichtbron ter plekke, we maken er een area_light van met zeg 5 op een rij en zorgen dat die in de lange as van de TL-buis liggen. Dan geven we aan de lichtbron op dat die looks_like met het TL-buis object moet zijn. Het gevolg is dat de TL-buis het attribuut 'no shadow' krijgt want anders zou die het licht tegenhouden. Om te zorgen dat de TL-buis zelf zichtbaar is moet je hem een hoge 'ambient' opgeven of ervoor zorgen dat een andere lichtbron buiten de TL-buis zelf het TL-buis oppervlak verlicht. Op deze manier kan je ook matglazen gloeilampen namaken. Wil je toch dat er op bepaalde plaatsen om de lichtbron heen schaduwen geworpen worden zoals b.v. een schemerlamp dat kan doen of een lantaarn met een kaars erin, dan moet je een 'union' maken met de schaduwgevende delen. Bij onze TL-buizen zou je de lichtuitstroming willen verhinderen aan de uiteinden. De twee zwarte schijven plak je dan met een 'union' samen met de pijp van de TL-buis.

Union{
light_source { <x,y,z>
color White ....
looks_like {MyLamp}}
object {My_lampshade} }

Buigen

Alle cursisten zullen zich nog wel herinneren wat voor moeilijkheden er waren bij het maken van een wipkip. Maar gelukkig was er een kant en klaar pakket voor ons om spiralen en dus in dit geval een spiraalveer op een makkelijke manier te maken. Nu komt men met de vraag: 'Hoe kan ik een bestaand object verbuigen?' Ik ben het bij Chris Colefax gaan navragen en die had al zo'n vraag beantwoord in juni 1997. Hij heeft er toen ook maar tegelijk een include-file van gemaakt. En zijn puzzelwerk kunnen we gaan gebruiken. Laten we ervan uitgaan dat we een compleet object hebben dat we willen vervormen. Dan geven we b.v. op: #declare bend_object = object (MYFlower scale 2) Voor de duidelijkheid: zolang ons object een CSG-object is, dus samengesteld uit de basisvormen of een zgn. triangle-mesh is, gaat het goed. We moeten opgeven langs welk pad in de ruimte gebogen moet gaan worden. Vandaar dat er dus een virtuele buigas moet worden opgegeven. Het beginpunt ligt op object_axis1 (default -y) en het eindpunt (dat dus zal gaan veranderen van positie tijdens het buigen) is object_axis2 (default +z). Vervolgens geven we op hoeveel het object moet buigen in graden. Maximum buiging is 360 graden en je kunt ook negatieve hoeken nemen on achterwaards te buigen. Wat we nu nog missen is 'bend_angle' die opgeeft in welke richting we zo dolgraag willen buigen. De default is +x. Het buigen is in werkelijkheid een stap voor stap proces. Met als gevolg dat er een stapgrootte moet worden opgegeven. Normaal staat bend_smouthness op 100, maar bij testen kan die best sterk verlaagd worden want het parsen loopt nogal gauw uit de klauw als je niet oppast. Omdat bij het buigen het oorspronkelijke object wordt opgesneden in plakjes worden er vele objecten gemaakt en dan wil het renderen niet vlot verlopen. Zoals ik bij bomen ook al heb gezegd: hoe meer objecten hoe langzamer de rendering.

Het is gebleken dat men vaak de buiging niet van begin tot het eind wil hebben maar vaak aan het begin zo houden als het is en het eind ook. Geeft dan een bend_start op: een waarde van 0.5 laat het buigen halverwege beginnen. Een bend_finish doet iets dergelijks; zo geeft 0.8 aan: stop als je op 80 procent van de buigweg bent gekomen. Het leuke is dat de richting waarin het object staat dan wordt doorgezet. Ideaal dus voor bloempjes op steeltjes. Als er ruimte voor is zal ik een listing bij dit verhaal plaatsen waarin een verlepte bloem wordt gemaakt.

Nawoord

Iemand komt met de vraag 'Hoe zit het met 32-bits kleur? Is dat beter?' Dat is geen gekke vraag want her en der kom je tegenwoordig de kreet '32-bits kleur' tegen. Dit begrip wordt voor heel verschillende zaken gebruikt. Laten we als eerste de 32-bits kleurenscanners nemen. Die moeten zo goedkoop mogelijk gemaakt worden. Dus worden knoppen en andere instellingsmogelijkheden verwijderd. Zo kan je b.v. de helderheid van de belichting niet meer aanpassen. Het gevolg is dat de scans dan te donker of te licht kunnen zijn. Maar dat wordt voorkomen door de lichtdetector een grotere helderheidsrange te geven. Die 8 bits meer (32-24=8) geven ruimte om zowel heel donkere delen als heel lichte delen nog te beschrijven. De software moet dan de helderheid van het plaatje bijstellen en dan worden die 8 extra bits weggerekend. Ik moet zeggen, ik weet dat het niet pleit voor de mensheid, maar de software doet het beter dan de modale gebruiker die wat met kontrast- en helderheidknoppen gaat foezelen. Er zijn ook grafische kaarten die met 32 bits werken. Soms is dat een armoedebod omdat het video-geheugen in happen van 32 bits tegelijk moet worden gelezen waarbij die extra 8 bits gewoon 'gaten' zijn zonder informatie. Bij wat duurdere kaarten die dan ook een video-in en een -uitgang hebben, ligt dat anders. Dan worden die extra 8 bits gebruikt voor transparantie. Bij het mengen van het video-beeld met het computerbeeld heeft de laatste meer of minder doorzichtige plaatsen: het video-beeld schijnt erdoorheen. Een kreet in dit verband is 'alpha blending'. Echte 32 bits kleur of zelfs nog meer kom je alleen tegen bij satellietbeelden en zo die ook infra-rode en ultraviolette kleuren bevatten. Maar dan weer: gaat men het beeld op het beeldscherm zetten dan wordt weer in 24 bits kleur gekeken. Ons oog heeft ook maar een beperkte nauwkeurigheid bij het kleurenzien. Alleen in het groene deel van het spectrum zouden een paar bitjes extra nauwkeurigheid voor de kleur geen kwaad kunnen. Waarschijnlijk waren onze verre voorouders vegetariers.

Piet Vogelaar

Bij dit artikel zijn diverse afbeeldingen van elders geplaats. Met dank aan de makers: Michael Hough, Steve Anger en Daniel Despain.