Home Creatief met POVRay Halo's en een wipkip Een zijpad, wat bomen en de radiosity
 

Sterren aan het firmament

Op de vorige cursusavond heb ik laten zien hoe we fraaie wolkenluchten konden maken en hoe je een realistisch kleurverloop voor een zonsondergang maakt. Als praktische toegift is toen ook het gebruik van spiralen besproken en hoe je daarmee een wipkip in elkaar kan zetten. We gaan nu verder met de nachtelijke hemel. Als eerste moet ik de cursisten melden dat het toch lukt, ondanks mijn sombere opmerkingen de vorige keer, om PovRay versie 3 te draaien onder multitasking. Zodoende kan je op de achtergrond PovRay laten rekenen terwijl je werkt aan andere zaken. Verwacht geen wonderen natuurlijk maar het zal voor sommige mensen een opluchting zijn dat PovRay niet meer de hele computer tot zich neemt. Wel moet men natuurlijk ruim in geheugen zitten. Wat heb je nodig? In elk geval een multitasking systeem: het is uitgeprobeerd met N.AES versie 1.1 (oud inmiddels) met als kernel een MiNT (recent), NVDI 5 en de desktop Thing.

In de autofolder staan dan dus:

  • LetemFly (niet absoluut nodig),
     
  • MiNTnp.prg (echt nodig)
     
  • NVDI.prg
     
  • Tos2Win.prg
     
  • Selectric.prg (handige fileselector, niet per se nodig)
     
  • WDialog.prg (wel nodig)
     

Verder moet men natuurlijk ook de diverse zaken die specifiek MiNT betreffen of N.AES, goed doen: de juiste auto-startende applicaties uitkiezen e.d. Van belang is het dat men het goed voor elkaar krijgt om TOS/TTP-uitvoer een venster binnen te loodsen. Ook moet men Povray.gtp als applicatie aanmelden bij de desktop en hem als een ikoon op de desktop leggen. Ga je dan een .ini file op het applicatie ikoon slepen dan start PovRay en de uitvoer komt in een venster. Het is zelfs mogelijk (in elk geval op een kleurenscherm) om ook het display-venster te activeren. Op de TT met zijn VGA-scherm moet men met de default voor het display-type werken: we hebben nu eenmaal geen luxe grafische kaarten.

In de gaten houden

De leukste manier om de vorderingen van de raytracing gade te slaan is om niet alleen de optie

Display=on

op te geven maar tegelijk:

Preview_End_Size=1
Preview_Start_Size=16

Ik zie de vraag al komen: 'Waarvoor dit laatste?'. Ik zal het uitleggen. Het toekomstige beeld wordt opgesplitst in blokken van 16 x 16 beeldpixels. Begonnen wordt met het eerste pixel in de linker bovenhoek. Die wordt 16 maal groter in het venster gezet.

Voorwaarde is natuurlijk wel dat het beeld zich netjes laat opdelen. Zowel het aantal pixels horizontaal als vertikaal van het beeld moeten dus een veelvoud van 16 zijn. In de volgende pass worden er als het ware 8 x 8 pixelblokken genomen. Van elk wordt weer het linker bovenhoek pixeltje uitgerekend, natuurlijk alleen maar als het pixeltje nog niet voordien berekend was.

Noodstop

Niet alleen is het leuk om bij te houden hoe de kwaliteit van het beeld langzamerhand verbetert, ook kan je gauw zien of er iets mis is en dan de rendering onderbreken. We hebben natuurlijk allemaal per default de

Test_Abort=on

aan staan zodat een gerammel op het toetsenbord (vooral indrukken van control-Z, control-C , control-K dan wel control-S wil goed helpen) de raytracing kan onderbreken en

Continue_Trace=on

geeft PovRay de mogelijkheid om weer verder te gaan waar die de vorige keer is gebleven. Op die manier verlies je alleen de uitgerekende pixels die in de buffer zaten op het moment van de geforceerde stop en die is meestal maar 1 beeldlijn groot. Onder multitasking lukt het ook om PovRay te onderbreken maar soms kan het voorkomen dat een ander programma de Control-toetsen wegsnoept. Wil je toch de computer laten stoppen dan kan je grijpen naar de Reset-knop. Voor zover het resultaat op disk is weggeschreven blijft dat natuurlijk behouden. Ik heb wat timing gedaan: met het display venster aan verlies je wat tijd: ongeveer 30 procent langzamer wordt het naar schatting. Je kan de snelheid wat omhoog krijgen door de 'mosaic-view' af te zetten. Dan beperkt het verlies zich tot 10 procent. Er is nog een gevaar bij dat 'langzaam op scherpte brengen': er gaat pas output naar disk alsalles berekend is. Onderbreekt de boel tijdens rendering dan ben je alle resultaten kwijt. En het vergt extra geheugenruimte om berekende pixels tijdelijk op te bergen. Er is nog iets tegen het gebruik van de 'mosaic view': heb je de anti-alias aanstaan dan moet er tenslotte een extra rekenpass over alle pixels worden uitgevoerd. En dat vreet tijd! Mij advies is: gebruik het display-venster niet. Het tekstvenster geeft voldoende informatie over de vorderingen.

Hemel en sterren

Als de zon onder gegaan is (voor een ondergaande zon: zie de aanwijzingen in de vorige aflevering) dan wordt de lucht donker. Zijn er geen wolken (het maken van wolken: zie de vorige aflevering) dan kan je planeten en sterren zien. Hoe maak je die? De werkwijze ligt voor de hand: maak een of ander texture dat je kunt gebruiken om de oppervlakte van de hemelbol of het hemelvlak te voorzien van een uiterlijk. Dus een zwarte ruimte met her en der in kleur en grootte verschillende sterren. Jeff Burton heeft ook daarover zitten na te denken en kwam tot een simpele en hanteerbare oplossing die we in de includes kunnen terugvinden als file stars.inc. Een beetje open veld met sterren krijg je met:

#declare Starfield1 =

texture {
  pigment {
    granite
    color_map {
        [ 0.000  0.270
         color rgb < 0, 0, 0>
         color rgb < 0, 0, 0> ]
        [ 0.270  0.280
         color rgb <.5,.5,.4>
         color rgb <.8,.8,.4> ]
        [ 0.280  0.470
         color rgb < 0, 0, 0>
         color rgb < 0, 0, 0> ]
        [ 0.470  0.480
         color rgb <.4,.4,.5>
         color rgb <.4,.4,.8> ]
        [ 0.480  0.680
         color rgb < 0, 0, 0>
         color rgb < 0, 0, 0> ]
        [ 0.680  0.690
         color rgb <.5,.4,.4>
         color rgb <.8,.4,.4> ]
        [ 0.690  0.880
         color rgb < 0, 0, 0>
         color rgb < 0, 0, 0> ]
        [ 0.880  0.890
         color rgb <.5,.5,.5>
         color rgb < 1, 1, 1> ]
        [ 0.890  1.000
         color rgb < 0, 0, 0>
         color rgb < 0, 0, 0> ]
    }
   turbulence 1
   sine_wave
   scale .5
  }
  finish { diffuse 0 ambient 1 }
}

Het slimme is dat er gebruik gemaakt wordt van het al bestaande 'granite'. Ik ga niet iedereen opnieuw uitleggen hoe het korrelige gesteente graniet eruit ziet: stel je maar voor dat je divers gekleurde steentjes op elkaar plakt. Sterren zijn al of niet felle lichtpuntjes met een beetje kleur in een verder donkere ruimte. De structuur van granite wordt beschreven met een wiskundige functie. Het gaat er zo aan toe: we nemen een punt in de 3-D ruimte. De formules worden op de positie los gelaten en die leveren een getal op tussen nul en 1. Dit getal wordt gebruikt om in de color_map op te zoeken wat voor kleur er in dat punt in de ruimte heerst. Zo verkrijg je een ruimte die gevuld is met een korrelige structuur. In de tabel geeft men aan dat alles tussen 0 en 1 zwart is behalve en paar kleine bereiken. We zien dit: van 0 naar 0.27 is er geen kleur (zwart zou je kunnen zeggen). Dan over een korte afstand 0.27 naar 0.28 is er geelachtige kleur, dan weer een heel gebied zonder kleur enz. Omdat we de sterren niet regelmatig verdeeld willen hebben geven we wat zwier aan de zaak door turbulentie toe te voegen; we kennen dit al van het maken van houtnerven en wolken. Als we dit patroon gebruiken voor een hemelvlak of een hemelbol dan moeten we ook iets aan de oppervlakte doen. We gebruiken de 'finish' en we geven een maximale 'ambient' op van 1.0. Dat is heel logisch: sterren stralen licht uit. Zouden we geen grote ambient opgeven dan zouden we alleen maar sterren zien als er een lichtbron is die de sterrenhemel belicht. En dat willen we niet. Dat we tegelijk een diffuse 0 opgeven is dan ook logisch: de hemelbol weerkaatst dan geen opvallend licht van lichtbronnen in onze scŠne.

Meer sterren

Een heel wat dichter bezaaide hemel waarbij de de sterren ook wat meer kleur hebben krijg je met:

#declare Starfield6 =

texture {
  pigment {
    granite
    color_map {
        [ 0.000  0.250
          color rgb < 0, 0, 0>
          color rgb < 0, 0, 0> ]
        [ 0.250  0.300
          color rgb <.5,.5,.4>
          color rgb <.8,.8,.4> ]
        [ 0.300  0.450
          color rgb < 0, 0, 0>
          color rgb < 0, 0, 0> ]
        [ 0.450  0.500
          color rgb <.4,.4,.5>
          color rgb <.4,.4,.8> ]
        [ 0.500  0.650
          color rgb < 0, 0, 0>
          color rgb < 0, 0, 0> ]
        [ 0.650  0.700
          color rgb <.5,.4,.4>
          color rgb <.8,.4,.4> ]
        [ 0.700  0.850
          color rgb < 0, 0, 0>
          color rgb < 0, 0, 0> ]
        [ 0.850  0.900
          color rgb <.5,.5,.5>
          color rgb < 1, 1, 1> ]
        [ 0.900  1.000
          color rgb < 0, 0, 0>
          color rgb < 0, 0, 0> ]
      }
  turbulence 1
  sine_wave
  scale .5
  }
  finish { diffuse 0 ambient 1 }
}

Ik zie een paar mensen met vragen zitten. Ik ben het even vergeten uit te leggen: de scale en de sine_wave, wat doen die? De scale werkt op de color_map. Die krijgt een half zo klein verloop oftewel in de range van 0 naar 1 wordt de map twee keer ingepast. Je zou dit ook anders kunnen doen door op te geven

frequency=2

Ik ga nu niet filosoferen 'wat is het beste', die discussie is tijden geleden al gevoerd. Doordat er in granite een functie zit ingebouwd die 'scherpe kantjes' geeft vervangen we die door de vloeiend verlopende sinus-golf. Scherpe afscheiding tussen de korrels van echt graniet is prima maar voor onze sterren is een vloeiender verloop wat meerwelkom.

Resultaat

Gebruiken we de voor de hand liggende kant en klare hemelbol zoals we dat twee afleveringen geleden gedaan hebben voor een ondergaande zon, dan krijgen we dus op analoge manier

sky_sphere{
      texture{Starfield_1}
//   ----verdere zaken----
}

Na rendering zien we een normale aardse sterrenhemel. (red.: een afbeelding nagenoeg geheel zwart op een paar witte stipjes na laat zich niet goed printen. Geen illustratie dus.)

En nu is het tijd voor koffie.

SF-space

Het leuke met PovRay is dat je niet gedwongen bent om herkenbare aardse scŠnes te maken. Zolang ons oog maar wat met het plaatje kan beginnen (onze eigen ingebouwde beeldbewerking is vooral blij met perspectief), zijn we vrij in het afbeelden. Ik zal dan nu de vraag van Wimpie gaan behandelen: hoe maak ik iets waarbij je een astronomisch uitzicht hebt vanuit een ruimteschip. Dus iets met sterrenstelsels, sterrenhopen, kometen, meteorieten enz.: Science-Fiction achtig dus. Ook hier is het weer: wat men wil is niet nieuw: ook anderen hebben zoiets bedacht. En Chris Colefax heeft de eisen verwerkt in een pakketje: De galaxy-include spullen. Ze staan op de disk die jullie vanavond mee naar huis krijgen (red.: het zal voor de lezers gezet worden op de disk behorende bij deze uitgave van dit tijdschrift).

Achtergrond

Als eerste gaan we ons bezig houden met het maken van een achtergrond waarvoor de file galaxy.bg gebruiken. Even iets wat we goed moeten begrijpen: normaal zetten we aan het begin van een scŠne-beschrijving neer wat we nodig hebben later verderop: de 'include' opdracht zoals

#include "colors.inc"

Maar de bij Galaxy gebruikte include-files gedragen zich wat complexer. Als vuistregel geldt: je moet pas de include doen (eventeel meermalen) als dat nodig is. Ga je de diverse gedeelten van dit pakket allemaal in een scŠne gebruiken dan wordt dit erg belangrijk. Maar daarover later. We blijven nu bij het maken van een achtergrond. Wat voor dingen kunnen we met de Galaxy BackGround File doen? De zaak op de sky_sphere afbeelden zal meestal gewenst zijn, maar er is een alternatief: afbeelden op een eigen bol. Bij default wordt er een sky_sphere aangemaakt want anders kan met:

#declare galaxy_declare_only = true
#include "GALAXY.BG"

Dan ben je vrij om alle pigmenten die gemaakt worden in deze include file te gebruiken naar eigen inzicht zoals:

  sky_sphere {
     pigment {BGStars3}
     pigment {

           BGMilkyWay rotate z * 45}
     pigment {BGNebula5 scale 2}
     pigment {
         BGNebula1 rotate <60, 50, 0>}}


  box {<-1, -1, -1>, <1, 1, 1>
     pigment {

            BGStars6} finish {phong .5}}

Ja, ik weet het, nu maak ik toch weer een sky_sphere maar wel met dit verschil: ik kan hem voorzien met zaken naar eigen wens. Waar het om gaat is die doos die glimmend en hard eruit ziet dankzij de phong. (voor de phong: die is al eerder behandeld.) We zien nu ook dat er als het ware diverse pigmenten zijn. Op een rijtje gezet zijn dat:

  • BGStars1 t/m 6
     
  • BGNebula1 t/m 5
     
  • BGMilkyWay
     

Laten we de achtergrondssterren nemen. Van 1 t/m 3 komen er meer sterren (de sterdichtheid dus) datzelfde geldt voor 4 t/m 6 maar dan met dit verschil dat terwijl de eerste drie groepen bestaan uit een mix van zwakke en lichte sterren de laatste drie groepen bestaan uit heldere sterren met diverse kleuren. De patronen die in de pigmenten besloten zitten kunnen we ook manipuleren: rotatie en schaling zijn mogelijk. Na sterren is een mogelijke achtergrondsvulling ook: nevels in allerlei vormen en mate die af en toe wat weg hebben van wolken natuurlijk. De vijf soorten in dit pakket dekken wel alle astronomische vondsten af:

  1. wat de auteur 'normaal' noemt
     
  2. een nevel die licht reflecteert. Hierbij moet je aan foto's denken van nevels die door nabije sterren verlicht worden: dit effect wordt hier nagedaan
     
  3. een nevel met her en der donkere gebieden erin
     
  4. een nevel met spin-achtig uiterlijk (een explosie-nevel)
     
  5. een nevel van grote dichtheid die reflecteert . Tot slot hebben we nog een speciale:
     
  6. Milky way patroon: een sliert met niet van elkaar te onderscheiden sterren. Er zit richting in zodat de rotatie in ons voorbeeld heel zinnig is.
     

Ik ben er zelf achter gekomen dat je beter zelf alles van de background in handen kan nemen en te werken op de zojuist beschreven manier. Zoals toen we voor de koffie een 'granite' misbruikten om een sterrenhemel te krijgen zo moeten we ook nu zorgen dat de pigmenten van zichzelf al licht uitstralen want anders hebben we veel gezeur met lichtbronnen. Op de achtergrond wordt ervoor gezorgd dat dit hier goed gaat: je hoeft zelf niet te vogelen. Waar ik het wel over moet hebben zijn de kleuren die gebruikt worden. Die kan je veranderen en vanzelfsprekend heeft elke groep effecten zijn eigen parameters daarvoor. De pigmenten met BGStar erin en Milkyway hebben galaxy_star_coloration die van nul (0) = geen kleur naar 1 (totaal kleur) loopt. De nevels maken gebruik van diverse kleuren. Ook wordt er gebruik gemaakt van turbulentie en zijn er schaalfactoren. Die kan je allemaal naar eigen wens instellen maar ik waarschuw jullie; dat is een heel gedoe. Vergeet ook niet dat onze patronen berusten op random getallen. Wat dus inhoudt dat als je een andere random reeks gebruikt het er allemaal opeens heel anders uit kan zien. Ik zou zeggen probeer dat maar eens:

#declare galaxy_seed=19

en zie het verschil met de oude rendering. (red.: hier laat Piet twee dia's zien: helaas ze zijn niet op papier te reproduceren).

Starfield

Er zal vast wel een Nederlands woord voor zijn maar dat ken ik niet. In elk geval is het zo dat we met galaxy.sf erin slagen om echte sterren te maken. Met andere woorden: we maken geen textures zoals daarnet (die pigmenten) maar echte objecten. Het enige nare aan het gebruik is: je zit al gauw met veel objecten in de scŠne en dat verlengt de tijd die nodig is voor het uitrekenen van de afbeelding. Het aantal sterren wordt geregeld door star_count die als je niets opgeeft op 1000 staat. De kleur van de sterren kan je zetten met star_color die normaal op <0.9 0.9 0.9> staat en het type kan zijn (star_type) 1 voor gewone ronde sterren, 2 voor een halo erbij en 3 voor sterren met 6 stralen. Er is evenwel iets lastigs met de methodes die gebruikt worden: zolang je resoluties van de nette 640 x 480 (of desnoods 320 x 240) gebruikt lijkt het goed, maar wijk je daarvan af dan klopt de grootte van de sterren zelf niet meer. Met star_scale kan je daar dan wat aan doen. De default is 1. Een andere kwestie is: hoe verdelen we de sterren in de ruimte? Hier wordt gebruik gemaakt van een bol met een straal van 20.000. Als we alles eventjes in Europese maten beschouwen en 1 eenheid van Povray een meter geven dan is dat dus 20 km verderop. Als je op de platte grond staat dan kan een mens vanaf ooghoogte ongeveer 5 kilometer verderop de horizon zien. De defaultwaarde van star_distance zal meestal dus goed staan. Maar denk eraan: gaat PovRay raar doen (na parsing stoppen, gewoon wegbommen e.d. dan is er iets mis met de grootte van de afstanden. Hoger dan ongeveer 32.000 moeten ook tussenberekeningen van afstanden nooit worden! Een ander aspect waar we aandacht aan schenken is: de star_distribution. Bij een waarde van 1.0 is de ratio tussen dichtbije en verderopstaande sterren gelijk. (Een ster dichtbij is groot, eentje ver weg is klein) Waarden kleiner dan 1 geven meer kleine sterren, groter dan 1 meer grote. Alle sterren dezelfde kleur (zie daarnet) is natuurlijk saai (allemaal lichtgrijs bij default). Maar dat kan met star_color_turb=0. Een waarde van 0.2 geeft een goed effect en is dan ook default. Voor de volledigheid: niet alleen de kleur maar ook de helderheid van elke ster hoeft niet dezelfde zijn: star_brightness_turb = 0.5 geeft een goed effect. Ook hier weer is het net als bij het maken van de achtergrond: er wordt gewerkt met random getallen dus de beginwaarde maakt uit hoe het eindresultaat oogt. Je kunt dus spelen met galaxy_seed, galaxy_origin en galaxy_rotate. Wat heel lastig bij deze starfield file is dat je niet als het ware diverse pigments ter beschikking kan krijgen om eigen dingen mee te doen. Zo zij er drie typen sterren maar het is of de ene of de andere. Dit kan je omzeilen door elke keer eerst je parameters op te geven en dan een include te doen:

#declare star_type= 1
#include "GALAXY.SF"
  - andere zaken instellen--
#declare star_type = 2
#Include "GALAXY.SF"

Meer dan sterren

Toen we bezig waren met de background konden we niet alleen sterren op onze hemelbol krijgen maar ook nevels. Nu we werken met echte objecten willen we behalve de zojuist besproken sterren ook andere objecten vormgeven. Daarvoor is de file Galaxy.obj die je door een include te doen allerlei vormen kan laten maken. Op een rijtje zijn dit:

  • Star1 t/m 4
     
  • Nebula 1 t/m 6
     
  • Galaxy1 t/m 5
     
  • Comet1 t/m 3
     
  • Meteor 1 en 2
     

Hier wordt wat pionierswerk van de gebruiker verwacht want een duidelijke beschrijving van deze vormen is er niet (nog in de handleiding nog in de include zelf). Gelukkig helpt de demo-file allobjs.pov ons een stuk. Alle mogelijke objecten worden netjes gerangschikt vertoond. (red.: Piet laat een dia zien die ook helaas niet op papier reproduceerbaar is.) Ook hier is het weer van belang te noteren dat er per aanroep maar 1 soort object wordt gemaakt. Net zoals daarnet is gedaan met star_type moet je herhalend te werk gaan met de objectnaam gevolgd door een aanroep om de include te doen. Vanzelfsprekend is er ook hier weer een groot aantal zaken in te stellen. We kunnen wel aan ons water aanvoelen wat dat zal zijn: galaxy_object_scale, idem rotate, position en flatten. Ook hebben we natuurlijk de al eerder genoemde galaxy_seed enz. die versteld kunnen worden. Ik ga daar niet verder op in; als er vragen zijn dan hoor ik het wel. Een enkel object aanmaken in de gehele ruimte is natuurlijk niet veel: dat vult niet echt op. En om ze stuk voor stuk te laten maken is veel schrijfwerk. Vandaar dat er een mogelijkheid is om een cluster te maken van gelijksoortige objecttypen. De positionering, kleur, afmeting enz. heb je dan niet meer in de hand: het toeval beslist. Wat je wel kunt instellen met absolute zekerheid is het aantal objecten in een cluster: galaxy_cluster_object = 6 voor de defaultwaarde. Logischerwijze zijn natuurlijk de parameters die we aan een object gaven ook over te brengen op een cluster; zaken zoals galaxy_cluster_scale, rotate, position e.d. met natuurlijk (het kan niet op) nieuwe zaken zoals galaxy_cluster_spread en galaxy_scale_turb. Zo te zien zit niet iedereen te springen om een uitleg: het wordt echt weer tijd voor koffie om de bedompte geesten helder te krijgen.

Alles tegelijk

Wil je een achtergrond hebben met sterren e.d. en wil je ook in de scŠne gebruik maken van echte sterachtige objecten (dus gebruik van zowel galaxy.bg als galaxy.obj) dan zit je voor je het weet tot de oren in de moeilijkheden. In dit geval moet men gaan werken met een include van galaxy.inc die beide werkwijzen goed samenvoegt. In elk geval heb je minder instellingen om je zorgen over te maken. Ik zal er niet verder op ingaan want ondanks de koffie die zojuist gedronken is dreigen enkele toehoorders alweer glazig te gaan kijken. Dat brengt me op een volgend onderwerp.

Glas

Tot nu toe zijn we vanavond tamelijk specialistisch bezig geweest: de aandacht was er dan ook naar. Nu gaan we verder met iets waar jullie allemaal direct wat aan hebben: doorzichtige voorwerpen. Laten we beginnen met glas dat we halen uit de file glass.inc door middel van een include-statement in onze scŠnebeschrijving. Als eerste maken we een voorwerp waar we onze textures aan toewijzen. Laten we nog even goed voor de geest halen hoe het werkt. Een texture vult als het ware de gehele 3-D ruimte. Van elk punt in de ruimte kan bepaald worden hoe die eruit zal zien. Maken we een voorwerp, b.v. de simpele bol en geven we die een texture mee dan zal bij het raytracen een zichtstraal vanuit de camera die het oppervlak van de bol raakt tot gevolg hebben dat er gerekend gaat worden met behulp van het bijbehorende texture hoe dat stukje oppervlak er uitziet en wat die voor verdere eigenschappen heeft. Heel mooi vind ik zelf het T_Vicksbottle_Glass wat iedereen wel kent. De beschrijving ziet er als volgt uit:

// Vicks bottle, glass
#declare T_Vicksbottle_Glass=
texture {
    finish { F_Glass4 }
    pigment {
         color rgbf <0.1, 0.15, 0.5, 0.9> }
}

Kleuring

We gebruiken een pigmentje: een kleur zonder meer dus. Wat direct opvalt is de rgbf. Wat is dat nu? Die rgb kennen we best wel: hoeveelheid rood, groen en blauw. Het valt op dat er wel erg weinig kleur totaal gebruikt wordt. Dat is nodig omdat door de doorzichtigheid van glas je 'teveel' kleur krijgt wat zich uit in een fletsheid. Die 'f' geeft aan dat er nog een eigenschap is: de filtering. Om het precies te zeggen 'filtered transparancy'. We kunnen dus de helderheid of de doorzichtigheid is misschien een beter woord regelen. Een

rgbf { 1.0, 0.0, 0.0, 1.0}

geeft een rood cellofaan effect. Licht straalt erdoorheen en neemt de aanwezige kleur over. Ook is het zo: hoe minder filter hoe meer het oppervlak gaat meespelen.

Oppervlak

Voor de rest: er is een 'finish' aangebracht. Die kennen we al van vroeger maar laat ik het nog even kort herhalen. Finish geeft de eigenschappen van het oppervlak aan en is een gewoon onderdeel van de texture. We geven zo op hoe glad en glimmend het oppervlak is, of juist hoe dof het is en wat er met licht gebeurt dat naar binnen valt, er doorheen schijnt, wat en hoe gereflecteerd wordt enz. Als ik het goed geteld heb zijn er zo'n 12 verschillende eigenschappen bedacht. Daar moet je toch goed mee uit de voeten kunnen zou ik denken. Bekijk maar eens de finish {FGlass4} die goed inzetbaar is voor veel gebruikte glassoorten zoals daar zijn bierflessen, wijnflesssen, whiskeyflessen e.d.:

#declare F_Glass4 =
finish {
    ambient 0.1
    diffuse 0.1
    reflection .25
    refraction 1
    ior 1.5
    specular 1
    roughness 0.001
}

Laten wij eens kijken of we er met onze hersens bij komen: waarom ziet ons glas (Red.: dia wordt getoond tesamen met een echt Heineken flesje om het T_Beerbottle_Glass te kunnen vergelijken.) er zo uit? Ligt het glas in de schaduw dan moet het niet gelijk pikzwart zijn. Vandaar een beetje ambient licht dat uittreedt uit het oppervlak als het ware. Ook de diffuse is niet groot. Zou die hoger zijn dan zou een groter deel van het opvallend licht weerkaatst worden: de oppervlakte zou erg sterk aanwezig zijn (in het extreme als een spiegel) en het inwendige glas zou minder meespelen. Glas is over het algemeen glad dus je kan weerspiegeling verwachten. Vandaar de reflection met zijn waarde van 0.25. Geef niet teveel reflection want dan wordt de door het oppervlak weerkaatste omgeving te sterk overheersend en raakt het doorzichtig-zijn effect zoek. Om de zaak realistisch te houden moet het glas zich ook optisch juist gedragen voor doorvallend licht; het moet afgebogen worden. Vandaar dat refraction 1 is opgegeven. Dit effect kent maar twee standen 0=uit of 1 = aan. Zitten we nog met de vraag: hoe geven we de mate van lichtbuiging op? De refractie-index voor water is 1.33, voor glas ongeveer 1.45 (hier is 1.5 aangegeven met ior 1.5) en voor diamant 1.75. Ga je werken met b.v. een oliedruppel dan moet je maar eens een boek met fysische constanten opslaan om de brekingsindex van olie te weten te komen. We hebben een geringe ruigheid van het oppervlak opgegeven: een roughness 0.001 is echt niet veel (Plastic heeft 0.005 om maar eens een voorbeeld te geven) maar die heeft wel erg veel invloed op de manier waarop een 'highlight' er uitziet. Er zijn veel kleine puntjes op het oppervlak waarin lichtstippen verschijnen. Maar die moeten we elk voor zich wat fors maken want ze zijn niet krachtig: met de specular 1 zorgen we dat elke 'highlight' volledig verzadigd is qua helderheid. Ik kan niet genoeg benadrukken hoe belangrijk het is om glimlichtjes op het glas te hebben want zonder die is het moeilijk om het oppervlak te zien.

Slotwoord

Voor vanavond zullen we het hier bij laten. Ik wilde nog wat vertellen over doorzichtige pigmenten die je in lagen opbrengt, maar dat is stof voor de volgende keer. Moet er nog iemand koffie?

Piet Vogelaar


Copyright © Rein Bakhuizen van den Brink
Last updated on 1 september 1999
Home Creatief met POVRay Halo's en een wipkip Een zijpad, wat bomen en de radiosity