Multitasking en bakstenen bouwsels

Het is inmiddels volop zomer en de vacanties zijn losgebarsten. Even leek het erop dat we de samenkomst zouden laten vervallen, maar gelukkkig waren er nog genoeg mensen om deze cursusavond de moeite waard te maken. Net zoals de vorige keer verplaatsen we ons naar het grasveld buiten. Stoelen meenemen allemaal!

Multitaskend

Ik geloof dat het de vorige keer was dat ik het onderwerp: 'PovRay en Multitasking' heb aangeroerd. Ikzelf heb N.AES met de Thing desktop in gebruik maar laat over het algemeen PovRay in singletasking mode uren lang rekenen. Ik heb dus wat zitten mieren om uit te zoeken hoe ik Povray op de achtergrond kan laten werken terwijl ik zelf bezig ben met andere taken zoals een stukje tekst intypen. Uiteindelijk lukte het me via een apart venster waarin de command-shell 'Mupfel' om het voor elkaar te krijgen. Wat ik natuurlijk had moeten doen is: even navragen bij MiNT-deskundigen. Dan had ik kunnen horen hoe je zoiets doet. Ik ben nogal verward. Kijk ik op mijn desktop dan staat daar een ge-iconificeerd venster dat de simpele naam 'console' draagt. Daar vlak naast staat er nog eentje maar die heet 'Thing-Console'. Verder is er nog een ikoon met de naam 'MiniWin.App' dat in staat is om erop gedropte (met drag&drop) TTP-programma's te laten werken in een venster dat dan openklapt. Het blijkt nu, gek genoeg, dat de bij Thing geleverde console de verkeerde is. Die is nl. voor single-tasking. Wat ik moet gebruiken is 'TosWin2' en dan gaat het samen met een echte shell zoals die bij MiNT hoort (bash of tcsh) prima. Het is maar even weten. (red.: de nodige zaken komen op de disk behorende bij deze uitgave. TosWin2 is te vinden in versie 2.3 op PD disk nummer A 850)

Wat natuurlijk wel jammer is: dat zo'n shell al gauw weer 250 Kb geheugen opslorpt wat werken op 4 Mb computers wat aan de krappe kant maakt. Want vergeet ook niet dat TosWin2 ook nog eens als proces 200 Kb in beslag neemt. Een blik in de U:/proc/ pseudo-folder die ik onder multitasking voor ogen krijg, laat mij griezelen: ook nog eens 244 Kb voor MiNT, 475 kb voor N.Aes, en om echt van te schrikken: 1350 Kb staat genoteerd voor mijn desktop Thing. Ik kan dat laatste bijna niet geloven. Ik wil maar zeggen: multitasking kan leuk en handig zijn maar je hebt wel een Falcon met 14 Mb geheugen nodig, een TT met ook zo een hoeveelheid of een Milan.

MagiC lukt ook

Natuurlijk kon het niet uitblijven of ik kreeg van de redactie van dit blad het verzoek om a.u.b. ook iets te zeggen over MagiC. Dat heb ik toen beloofd maar MagiC moets ik gaan installeren, mijn harddisk was vol en dus het kwam er niet van. Gelukkig hebben we aandachtige lezers en zo ontving ik van Guido Goebertus via e-mail een tekst die mij vertelde hoe het moet. Ik zal het even voorlezen (red.: hier volgt een citaat) "Even een berichtje voor mensen die met Povray willen werken onder Magic.

Voor de duidelijkheid: de versie op disk C159 vertikt het onder dit OS. Ik ging dus op zoek naar een alternatief, en dat werd POVRAY.GTP 3.02B van Dirk Klemmt plus de shell 1.61 van dezelfde auteur. Eenvoudig POVRAY.GTP ombenoemen in POVRAY.TTP, paden instellen en de zaak werkt! Ik heb de shell bij Dirk geregistreerd voor 2 tientjes. Dat kan dus niemand de kop kosten. Vanuit de shell kun je heel comfortabel respectievelijk een texteditor als QED aanroepen, dan wel een grafische editor/viewer.

TOS2GEM hoeft niet geinstalleerd te worden, de VT52 van Magic vangt heel netjes de tekstuitgave van PovRay op. Enige schoonheidsfoutje: Iedere keer als je de shell opstart wordt er geklaagd dat TOS2GEM niet geinstalleerd is. Gewoon negeren dus. Geinteresseerden kunnen de zaak bekijken of ophalen op de site van Dirk Ik heb dit advies opgevolgd en nu kan iedereen die er behoefte aan heeft aan het eind van de avond een geschikte versie voor MagiC meenemen. (red.: in de PDbibliotheek zijn deze disks in de C-serie uitgebracht, zie daarvoor de rubriek 'ST Public Domain Service' elders in dit blad.)

Verplaatsen

Zo af en toe maak je een object aan, dan verplaats je het naar waar het heen moet en dan blijkt dat het verkeerd staat. Jolanda had zo'n probleem laatst. Wat je niet moet vergeten is dat de volgorde van translatie en rotatie van belang is voor het eindresultaat. Rotatie gaat altijd via een as die door het punt <0,0,0> loopt. Staat iets in de oorsprong en draai ik het om vervolgens (daarna dus) een translatie (verschuiven naar een punt in de ruimte) te verrichten dan weet ik (kwestie van inzicht en hoofdrekenen) waar het terecht komt. Maar doe ik eerst de translatie en dan pas de rotatie dan wordt niet het object zelf gedraaid maar krijg je een beweging om een verderop gelegen as. (door <0,0,0>) Het object wordt dus als het ware langs een cirkelboog door de ruimte gezwiept naar zijn eindbestemming.

Houdt er dus rekening mee. B.v.: maak je een bol dan zit het centrum in de oorsprong. Maar maak je een doos dan ligt het centrum niet in de oorsprong. Kijk maar na in de handleiding bij 'box' waar de syntax staat:

box { <Corner1>,<Corner2>}

Je moet de doos zelf direct juist plaatsen met zijn centrum in <0,0,0> of naderhand verschuiven want anders kan je nog heel rare verplaatsingen krijgen. Een voorbeeld:

box { <-1.0, -3.0, -0.25>,

            <-0.5, 3.0, 0.25> }

kan je beter opzetten als:

box { -1, 1
                scale <0.5, 6, 0.5>
                translate <-0.75, 0, 0> }

Ga maar eens na. Als je het niet snapt, teken het dan eens op papier. Er is een beperking in je vrijheid: elke waarde van de vector Corner1 moet altijd kleiner zijn dan de corresponderende Corner2 waarden.

Hollow

Oftewel 'hol'. Met dit woord maak men een object hol, zou je zeggen. Je hebt een doorzichtig voorwerp en je wil daar iets mistigs of een halo in stoppen of iets met 'medium' doen. Om nu te zorgen dat de zichtstraal als die het oppervlak van het voorwerp raakt niet stopt maar door gaat, is het woord 'hollow' bedacht. Het voorwerp wordt niet echt hol; het veroorzaakt alleen dat de berekening doorgaat zodat 'interne' zaken worden gezien. Het staat ook duidelijk in de handleiding. Daar gebruiken ze het Engelse woord 'empty' om de zaak te verduidelijken. Ik heb een voorbeeld gevonden met een diamant. je kan je eigen objectvorm gebruiken, dat spreekt vanzelf. Waar het om gaat is dat er in de diamand iets te zien is. Daartoe moet het oppervlak wel de goede eigenschappen hebben. Zie de pigment en finish waarden. Let eventjes niet op alle complicaties in de beschrijving van het media en bedenk dat 'hollow' totaal geen invloed heeft op de berekeningen die de refraction/reflection doen.

Mooi beeld

Ga je een beeld maken dan is altijd de prangende vraag: hoeveel pixels? Want dat bepaalt (o.a.) hoeveel rekentijd er opgeslurpt gaat worden. Daar komt bij dat je het liefst een schermvullend beeld hebt: alle pixels in gebruik als je het bekijkt. Natuurlijk kan je beeld groter worden dan het aantal beeldpixels van je schermresulutie maar dan moet je gaan scrollen. Nee, het hele beeld beeldvullend op het scherm is wat we willen. De meeste monitoren hebben een 4 op 3 verhouding dus 800 x 600 is te doen. Maar wat als je scherm ingesteld is op het maximaal haalbare, zoiets als 720 x 480? Dan maak je het beeld ook met net zoveel pixels. Maar dat kan raar worden: alles een beetje in horizontale of verticale richting uitgerekt of ingekrompen. Een cirkel die een ovaaltje wordt. Nu zegt Mina dat haar viewer dat goed doet, alleen is die zo langzaam. Dat kan en komt omdat het beeld helemaal herschaald wordt en ze toch met een zwarte rand op het scherm blijft zitten die ongebruikt blijft voor deze beeldweergave. Waar je naar moet kijken is de camera die je gebruikt in je scene. Die heeft nl. ook een beeldverhouding. Hoe stel je die in? Dat is simpel, zet in de camera definitie:

right x*720/480

Dan heb je voor jouw geval de goede 'aspect ratio' en kan je viewer het netjes 1 op 1 (1 Povray beeldpixel op 1 beeldschermpixel) tonen. Voor de duidelijkheid: bij default heeft de camera een ratio van 4 op 3.

Letters gebruiken

Er zijn een paar kant en klare lettersets in TIF-format die we in onze scenes kunnen gebruiken. Ik heb ze gevonden in /include/tif en een beetje bruikbare is tomrom.ttf. Laten we wat letters uithakken bij wijze van voorbeeld.

camera  {location <0, 0, -5> look_at 0}

light_source { <-10,10,-30> rgb 1}
difference {
        box { -1,1 scale<1.25,1,.25>

                translate <0,.5,.5>
                pigment {red 1}

                }
        text { ttf "timrom.ttf" "POV" .5,0

                translate x*-1
                pigment { rgb 2}

                }
}
background { rgb .35}

Ik heb hierbij de afbeelding. Ik hoop dat het gedrukt in z/w ook een beetje lijkt.

De gamma

Ik heb het al eerder over de gamma van een beeldscherm gehad. Het kwam ter sprake toen een fraai POV-beeld dat er op de Mac mooi doorlicht uitzag, op de PC veel te donker werd weergegeven. Het was een gewoon Targa (tga) format plaatje en het lag echt niet aan de helderheids- en kontrastinstellingen. Zet de twee computers naast elkaar en je krijgt de beide beelden niet hetzelfde. Dat komt door de gamma-waarde: de Mac had een 1.7 (Trinitron beeldbuis) en het scherm aan de PC (no-name) ongeveer 2.3. Laatst zag ik bij diverse cursisten het gebruik van 'assumed gamma' in de scenebeschrijving. Dat gaf mij te denken en waarschijnlijk is mijn uitleg op een vorige cursusavond verkeerd in de hoofden blijven hangen. We hebben inmiddels voor onze computers in ieder geval PovRay versie 3.1 en zelfs sinds kort 3.2. Ik zal uitleggen hoe het tegenwoordig zit. De default voor een beeldberekening is dat assumed_gamma een waarde heeft van 1.0. Vaak zie ik dat mensen die zetten op 2.2 en dat is fout. Zet hem altijd op 1.0 want dan komen kleuren 'onvervormd' in de file terecht. 'Als je hem altijd moet vermelden, waarom is het dan nodig?' is een goede vraag. Bij een waarde van 1.0 gedraagt het licht zich normaal in de zin van: het bijeenvoegen van lichteffecten. Simpel gezegd: als een beeldpunt van twee lichtbronnen 25 procent rood krijgt dan is de som 50 procent. Vertaald naar een 8-bits notatie voor de rode kleur (ligt tussen 0 en 255) zou dat 128 moeten opleveren. Zet de assumed_gamma niet op 1.0 en dergelijke rekensommetjes kloppen niet meer. Maar we zullen ons beeld toch zo echt mogelijk op de monitor zien te krijgen. De truc is om in de povray.ini file dit op te geven met Display_Gamma=2.2 en te bedenken dat jouw povray.ini file aan jouw systeem is aangepast. Je kan in de .ini-file behorende bij je povray source de instelling uit de povray.ini file overschrijven als dat nodig zou zijn. Ik geloof dat ik niet al te helder ben. Het tijd voor koffie en dit keer zal Willem de koffie maken. Maar laat ik snel verder gaan want de koffie zal zeer binnenkort mij verleiden tot een broodnodige rustpauze. Begin dus je scene met

global_settings (assumed_gamma=1.0}

Wat gebeurt er nu als er 'supersampling' of iets dergelijks optreedt waarbij de kleur van een pixel diverse malen berekend wordt en na afloop gemiddeld. Ik denk hierbij aan anti-aliassing en focal blurr. Ik zou zeggen dat na het midddelen de gamma-correctie moet worden uitgevoerd. Maar dat schijnt gek genoeg niet te gebeuren: het omgekeerde wordt gedaan. Maar waar je mee blijft zitten zijn de verschillende gamma's die je eigen monitor hebben, die op het werk en de printer. En je zou wel gek zijn om een scene drie keer te renderen met verschillende gamma's alleen. De enige goede oplosing ligt op systeemniveau. Daar zou je moeten kunnen vastleggen wat de diverse gamma's van aangesloten afbeeldingsapparaten zijn en verdere kleurcorrecties die nodig zijn voor de diverse apparaten. Het is de taak van de drivers om dan een beeld gemaakt op een gamma=1 op de juiste manier te corrigeren. Op de Mac's schijnt dat te kunnen, met Linux kennelijk ook. Waar je ook last mee kan hebben is b.v. dat de printer te donker drukt. Maar bij ophelderen zal blijken dat een 255 stappen per kleur (want er zit in een true-color Targa-beeld maar 3x8 bits voor notatie) te weinig is. Het klinkt raar maar 24-bits truecolor is prima voor het eindresultat maar het uitgangsmateriaal moet beter zijn. En dat kan. Sinds versie 3 kan je een beeld opbergen in een file van het PNG-type. Dat is modern en nieuw en bevat vele handige extra's. Zo wordt bijvoorbeeld de display-gamma in de file weggeschreven zodat iedere viewer of wat dan ook en waar dan ook de zaak kan omrekenen naar de plaatselijk aanwezige gamma. Helemaal om blij van te worden is het feit dat de optie +FN16 zorgt dat er 16-bits per kleur gebruikt worden voor de notatie. Dat levert wel een grote file op maar bij weergave ben je hoe dan ook gegarandeerd verliesvrij bezig!

Maar wat zeuren we nu over file-grootte: een 2,3 Mb grote BMP (Windows) file uit PovRay laten komen of hetzelfde beeld in een 0.3 Mb 48-bit PNG-file!

En nu is het tijd voor koffie.

Die PNG

Ik het toch niet nalaten na zo'n sterke kop koffie om nog snel even door te gaan over dat nieuwerwetse PNG-format.

PovRay maakt leuke PNG-files maar doet dat op een simpele manier. Met wat meer programmeerwerk kan het een stuk efficiënter. Onder DOS en Linux is er 'pngcrunch' dat misschien nu al verkrijgbaar is als ttp-programma voor onze Atari-computers. De file wordt met zo'n 25 procent verkleind en dan komt een 48-bits png kwa grootte overeen met een GIF-format. Helaas, ik kan het verhaaltje nu beëindigen: er is bar weinig software op onze Atari-computers die wat weten aan te vangen met png-format files. Maar niet getreurd; ook onder het veelgeroemde Windows is weinig goeds: Thumbs Plus vermaalt de 16-bits kleurinfo tot 8-bits prut en PhotoShop 5 idem dito. De koffie valt mij zwaar op de maag. Dus nu gaan we een lichter onderwerp behandelen.

Bakstenen

Ons land zit vol met bakstenen. Het is het standaardmateriaal om huizen mee te bedekken aan de buitenzijde. Logisch want natuurlijke steen treffen we in deze moddervlakte die ons Hollandse landje is van nature niet aan en muren van leem zijn niet ieders pakkie an. Ik kan dus de vraag van Jolanda goed begrijpen: 'hoe maak ik fatsoenlijke baksteen?'. Het lijkt zo simpel want we hebben een 'brick' kant en klaar tot onze beschikking:

pigment {

                        brick Color1, Color2

                        bricksize mortar}

staat in de handleiding. Je geeft de kleur van de bakstenen op (color2) en de kleur van het cement (color1). Met als gevolg dat muren en huizen er veel te popperig uitzien. In werkelijkheid hebben bakstenen nooit allemaal precies dezelfde kleur.

Je kunt als een metselaar een muur steentje voor steentje van verschillend gekleurde bakstenen opbouwen, maar dat is teveel werk, het aantal objecten in je scene loopt te gek hoog op en je rendertijd springt omhoog. Ook pogingen om met pigment te werken in plaats van blote kleur geven geen goed resultaat. Nu ben ik niet, zoals mijn naam suggereert, altijd maar bezig om zaken uit te vogelen. Ik ga gewoon zoeken op het internet want iemand zal vast en zeker wel deskundig zijn op dit gebied. En dat is Jeff Lee gebleken die er een hele homepage aan heeft gewijd. Het merendeel van de cursisten heeft geen internet dus ik zal het hier maar gaan vertalen en vertellen in mijn eigen woorden. Zijn grote ontdekking is het gebruik van 'repeat warp' en 'bozo' voor het pigment van de stenen. Laten we eerst eventjes de defaults in ogenschouw nemen. Steen plus cement heeft een afmeting van <8,3,4.5> eenheden en het cement is 0.5 dik. Jeff gaat eerst een bozo-patroon maken met drie tinten: gewoon, donker en licht die zich cyclisch herhalen. Zie maar:

    #declare P_RedBrickA = pigment {        bozo
      pigment_map {
        [0.00 colour rgb <0.60,0.10,0.10>]
         [0.20 colour rgb <0.40,0.05,0.00>]
                [0.80 colour rgb <0.75,0.25,0.10>]
        [1.00 colour rgb <0.60,0.10,0.10>]         }
    }

Dit is om warrelig van te worden. Met een scale 100 wordt het wat beter natuurlijk in verhouding met de grootte van de bakstenen. Maar het is te chaotisch. We willen verschillen tussen de stenen onderling hebben. Nu komt de warp-truc:

   #declare P_RedBrickB = pigment {
      P_RedBrickA
      warp { repeat x*8 offset <0,45,0> }
    }

We krijgen verticale banden van verschillende kleur. De herhaling vindt plaats om de 8 eenheden langs de x-as en dat is precies de breedte van de default baksteen.

Die offset een een beetje vreemd maar valt te verklaren omdat 45 een veelvoud is van 3 en kleiner is dan de scale 100 die we gebruikten voor het bozo-patroon. Als we de warp-grap ook in de y-richting herhalen dan zal het resultaat een geblokte indruk maken. En dat lukt met:

    #declare P_RedBrickC = pigment {
      P_RedBrickB
      warp { repeat y*3 offset <60,0,0> }
    }

Als we dit even analyseren: herhaling om de drie units langs de y-as (gelijk aan de default hoogte van de baksteen). Die offset is weer tamelijk arbitrair: dit keer zeven en een half steenbreedte wat neer komt op 60. Wat gedaan moet worden is e.e.a. combineren. Het resultaat zie je

en iedereen zal toegeven (die het in kleur ziet) dat het heel natuurlijk oogt.

#declare P_Mortar = pigment {
      colour rgb <0.90,0.89,0.85> }


 #declare P_RedBrick = pigment {
      brick
        pigment { P_Mortar },
        pigment { P_RedBrickC }
      mortar 0.35
    }

Een vermindering van de cementdikte van 0.5 naar 0.35 verstoort niet. Ik ben best tevreden met het resultaat maar volgens Jeff (tja, hij is de expert in deze) kan het nog veel beter. Dat gaat, u voelt het op uw klompen, wel extra rekentijd kosten. Nu zijn de stenen en dus de muur nog erg vlak en glad. Maar door de 'normal' van het oppervlak te veranderen kan je leuke effecten krijgen. Geef het oppervlak een wat korrelige structuur met behulp van het 'granite' patroon:

    #declare T_RedBrick = texture {
      pigment { P_RedBrick }
      normal { granite 0.1 }
    }

Ook het effect dat iedere steen op zich over zijn hele oppervlakte dezelfde kleur vertoont is te verbeteren. Een beetje turbulentie in de kleur werkt goed:

    #declare T_RedBrick = texture {
        pigment { P_RedBrick
        turbulence 0.075 }
        normal { granite 0.1 }
    }

Ik vind het een beetje overdreven: de standaard Nederlandse Kema-gekeurde baksteen is redelijk homogeen. Maar bekijken we de muur van opzij of van dichtbij dan is te zien dat het cement te regelmatig is. We maken het cement doorzichtig met

#declare P_RedBrick = pigment {
                brick
                pigment {colour rgbt<1,1,1,1>}
                pigment { P_RedBrickC }
                mortar 0.35
        }

en zetten een ander oppervlak een beetje terugwijkend ten opzichte van de stenen neer. Samengevat zien we het staan in de listing.

Maar dit is zo allemaal natuurlijk beperkt inzetbaar. Het wordt een heel gedoe om een driedimensionale muur goed te krijgen. Vandaar dat Jeff Lee een include-file heeft gemaakt. Met wat instellingen voor de grootte van de bakstenen en de dikte van het cement plus de pigmenten, normals en finishes kan iedereen aan de slag om bakstenen bouwsels minder popperig te laten lijken. Ik bedenk nu opeens dat wat ik nu heb verteld heb ook gebruikt kan worden voor mijn marmeren tegelvloer. Wat ik al eerder aanstipte: het gaat allemaal rekentijd kosten. Vandaar dat er voor testdoeleinden een vlugge manier van gebruik is. Door 'Quick' te definiëren wordt bemerkt dat er geen 'finish' en geen 'normal' gebruikt moeten worden bij de berekeningen. De spullen en een copie van de homepage van Jeff Lee zullen op de disk behorende bij deze uitgave van het blad gezet worden.

Steekvlam

Tusssen alle demo voorbeelden van Neon Graphics zit een raket met een vurige tong vuur die er aan de achterkant uit komt. De vraag is hoe we dit in PovRay kunnen doen want het lijkt zo simpel. Wel, dat is het niet. Het makkelijkste is het om met een object te beginnen dat al een beetje de vorm heeft:

cone { <0,0,0>, 4-.01, <30,0,0>, .01
//    hollow on
    pigment { red 0.9 green 0.4

blue 0.1 filter 1 }
    finish {reflection 0.7 }
    interior { ior 1.1 caustics 1.0 }
    normal { bumps 0.5 }
    }

cone { <0,0,0>, 4, <60,0,0>, .01
//    hollow on
    pigment { red 0.7 green 0.7

blue 1.0 filter 1 }
    finish {reflection 0.7 }
    interior { ior 1.1 caustics 1.0 }
    normal { bumps 0.5 }
    }

Je kan wat experimenteren met de 'filter' waarden die tussen de 0.7 en de 0.9 goede effecten geven. Als je deze samenstand van kegels nu op de juiste manier aan de raket plakt dan lijkt het redelijk echt.

Dit was het dan. Na de zomer gaan we weer met frisse moed verder.

Piet Vogelaar