|
|
Een zijpad, wat bomen en de radiosityIn deze aflevering van de cursus zal ik het hebben over mijn belevenissen met een versie van PovRay voor DOS, het maken van bomen en andere botanische vormen en het verschijnsel van de radiosity dat zeker nader belicht moet worden. Versie 3.1 Minoes belde mij laatst op want ze had van haar broer de oude computer gekregen. Hij had haar gezegd dat PovRay er ook op kan draaien. Heel benieuwd ging ik kijken, maar helaas het was geen Atari maar een oude 486/50 computer in een tower met een heel simpel en klein VGA-schermpje eraan. Er zat een floppydrive in en een harddisk. Ja, inmiddels is in Windhoos kringen zo'n computer onbruikbaar, maar voor PovRay rekenwerk misschien best inzetbaar, zeker aangezien er 8 Mb aan intern geheugen in zit. Bij het opstarten kwam gewoon MS-DOS op en daarmee is te werken. Ook bleek er nog Windows 3.1 op te zitten maar daar wilde ik niets mee te maken hebben: dat slurpt rekentijd, veel geheugen en is nergens goed voor als je al het voorbereidende werk op een Atari kan doen. Om Minoes verder te helpen ben ik het net opgegaan opzoek naar spul voor MS-DOS en tot mijn grote vreugde was er bij www.povray.org een download versie 3.1 van september 1998 te halen. Zo gezegd zo gedaan en een 1,6 Mb executable werd via twee HD-floppies in MS-DOS format ingespeeld in de DOS-doos. Na het installeren had ik een herkenbare configuratie van files en folders. Snel wat benodigde include files en scenes bijgeladen, de .ini files goed gezet en raytracen maar! Dat lukte vlot en ik was zelfs verbaasd van de hoge snelheid die dit ouderwetse DOS-doosje haalde. Meer dan mijn trouwe TT. Dus Minoes was zeker blij want haar scenes met mist en veel vaagheid (dat spaart een hoop detailwerk ook nog trouwens) rekenen nogal traag door. De werkwijze van Minoes is nu: op de Falcon worden de .pov files gemaakt en de bijbehorende .ini files, die worden op flop gezet, de DOS-doos staat op a:\ en alleen het simpele tekstje 'povray inifilenaam' moet worden ingetypt. Na afloop moet van ergens op de harddisk wel eventjes de .tga beeldfile op een floppy worden gezet. Op de Falcon kan dan in veel kleuren en pixels de scene bekeken worden. Nieuwere versie Een paar dagen later werd ik gebeld door Minoes of ik even langs wilde komen want er waren opeens allerlei PovRay fouten gemeld. Opeens was 'atmosphere' niet meer bekend. Na een halve avond zoeken en proberen was de fout nog niet gevonden. Dan ga je maar eens de handleiding lezen. Dat is simpeler gezegd dan gedaan want de handleiding bij de DOS-versie is maar liefst 850 Kb groot! Met een teksteditor maar eens gezocht en 'atmosphere' wordt nog gewoon vermeld. Maar gelukkig wordt er bij het hoofdstukje 'nieuwe dingen' vermeld dat nu 'media' moet worden gebruikt voor atmosferische effecten zoals fog, halo, haze, mist, rainbows en skies. Na rijp beraad hadden de makers deze oplossing gekozen die totaal niet backwards compatibel is met onze Atari versie 3.01. Het scheelt maar 1 cijfertje (0.09 om precies te zijn) en toch is het verschil groot. Bij commerciële software worden dat soort ingrijpende veranderingen aangebracht als een versie een heel nummer omhoog gaat maar bij software gemaakt door vrijwilligers kan dat anders gaan. Doordat de meeste aanwezigen op deze cursusavond op een Atari-computer werken hoeft ik natuurlijk niet uit te weiden over verschillen met versie 3.1 maar wie weet, volgende maand kan die versie ook geimplementeerd worden voor onze computers. Heb dus even geduld met mij tot aan de koffie. Dat duurt niet lang. Media Laten we eerlijk zijn: er is een vreemde splitsing tussen zaken als halo en atmosfeer. In het eerste geval hang je als het ware een texture in een doorzichtig voorwerp in het tweede geval speelt alles zich juist buiten voorwerpen af. Terwijl het toch om fysisch gelijke zaken gaat, nl. stofdeeltjes in een gas (of vloeistof) moet je toch heel anders handelen om de effecten te beschrijven. Daar is men nu vanaf gestapt. De werkmethode is: er wordt gekeken naar de dichtheid van deeltjes die de zichtstraal ontmoet. Bij atmosferische effecten wordt vanaf de camera tot het eerste object langs een aantal punten onderweg de dichtheid gemeten en dan het effect berekend dat over die weglengte zou optreden. Om effecten binnen een doorzichtig object te hebben moet het woord 'interior' gebruikt worden op de volgende manier:
object
{ Myobj
pigment {rgbf 1.0}
interior { media {Mymed}}
}
Natuurlijk zijn er allemaal statistische bewerkingen om te zorgen dat je met het sampelen niet teveel afwijkt van de 'echte' situatie. De volgende zaken zijn van belang geworden: absorption emission scattering density Met deze natuurkundige eigenschappen kan je elk effect bereiken dat je maar wilt. Absorption geeft aan wat er overblijft aan licht als het door het medium gaat. Emission rgb <0.25, 0.25,0.25> laat dus driekwart van het licht door en kleurt de zaak niet bij. Geef je niets op dan wordt rgb<0,0,0> gebruikt: al het licht wordt doorgelaten. Emission geeft aan hoeveel licht en van wat voor kleur de deeltjes van zichzelf (zonder belicht te worden) uitzenden. Dat komt overeen met het 'ambient' effect van voorwerpen. Normaal staat het op nul maar wil je vuur enzo dan moet je dit verhogen. Bedenk wel dat uittredend licht straalt niet af op omringende voorwerpen. Vervolgens komen we bij de scattering. Dat is een heel ingewikkeld natuurkundig proces maar het lijkt wel wat op de diffuse reflectie die een voorwerp kan hebben: er is scattering als er licht op de deeltjes valt en anders niet. En we moeten niet vergeten: dit verspreide licht wordt weer door deeltjes geabsorbeerd. Dit noemen we extinction. Afhankelijk van het type medium kan de scattering heel verschillend zijn. De simpelste is isotropic: het doet er niet hoe het licht op de deeltjes valt en onder welke hoek we er naar kijken want het effect is altijd hetzelfde. Wil je het effect van gasmoleculen nadoen dan is het niet zo simpel: wat je aan scattered light ziet hangt af van de hoek waarmee het licht invalt ten opzichte van je kijkrichting. Er wordt een andere berekeningsmethode toegepast. Heb je te maken met kleine waterdruppels in de vorm van mist of wolken (en ook luchtvervuiling) dan is de richting van de scattering heel richtinggevoelig. Een speciale berekenwijze is nodig. Ten slotte kan je nog uit een manier kiezen die alle andere dekt maar wat meer rekenintensief is. In de vaktaal heet het de Henyey-Greenstein modellering. Dit is de meest natuurkundige van alle mogelijke rekenkeuzes want nu wordt er gewerkt met een soort ruimtelijke ellips om de scattering zijn intensiteit en richting aan te geven. Dichtheid Maar het allerbelangrijkste wat wij vorm moeten geven is de dichtheid. Hoeveel deeltjes hangen er in een stukje ruimte? Nu komen we bij iets heel fraais: die density kunnen we op dezelfde manier modelleren als textures. Dus meerdere densities zijn mogelijk met verschillende patronen zoals bozo, wood, gradient, waves enz. Toen we in ons voorbeeld de halo gebruikten gaven we een spherical mapping voor de kleuren op. Dit kunnen we gewoon blijven doen, we zijn alleen wat vrijer in de keuze van de structuur dan vroeger. Mogelijk is b.v.: density {checker rgb<1.0.0>, rgb<0,0,0>} Al met al: het is wat logischer geworden. Neem nu de mogelijkheid om een object twee densities te geven:
object {Myobj
pigment (rgbf 1}
interior{
media{
density {een_of_ander} density {wat anders}
}
}
}
Voor een punt in de ruimte wordt nu gekeken naar twee densities. Die worden met elkaar vermenigvuldigd. Het effect is dus alleen een density overblijft op plekken waar ze beide aanwezig zijn. Dit lijkt logisch bekeken op wat we krijgen als we twee objecten hebben die stukken gemeenschappelijk hebben. Maar geven we twee media's op dan gaat het anders:
object {Myobj
pigment{rgbf 1}
media {density{iets}
}
media {density{ietsanders}
}
}
Nu worden eerst de beide media's berekend en de resulterende kleuren hiervan worden bij elkaar opgeteld. Dat lijkt wat op een CSG-union: in dit geval is het overlappende gebied extra helder. Een nadeel van onze gewone 'fog' is dat spotlights geen nette lichtbundels in de mist geven en dat voorwerpen geen schaduwen kunnen werpen op mist. Met de 'media' is dit effect voorbij. Een straatlantaarn kan nu de mist echt verlichten. Wil je toch niet dat lichten bemerkbaar worden dan moet je iets aan de lichtbron doen; er is een nieuw keyword voor. Ik stop er mee, het is tijd voor koffie. Zo meteen gaan we verder met bomen. Bomen Op dit moment zijn buiten alle bomen kaal, bladeren en bloemen zijn afgeworpen en we zien de kale structuur. Alle bomen hebben iets gemeenschappelijk: een tak heeft een zijtak die op zijn beurt een zijtak heeft enz. Het uiterlijk van bomen hangt af van de verhoudingen tussen de lengtes van de tussentakjes, de manier waarop zijtakken te voorschijn komen en dergelijke. Van die regelmatigheden kunnen we dus gebruik maken om als het ware automatisch bomen te laten bouwen voor ons. Het zal iedereen duidelijk zijn dat een boom met duidelijke echte details samengesteld moeten gaan worden uit erg veel objecten. Een beetje grote boom kan een miljoen bladeren hebben en daar valt niet tegenop te rekenen voor de computer! We moeten ons dus beperken. Is detail of realisme niet gevraagd dan kunnen we ons er heel makkelijk vanaf maken: een cylinder als stam en een bol als bladerkroon zijn zo gemaakt en snel doorgerekend. We kunnen de stam en het oppervlak van de groene bol wat opsieren met textures om een vlekkerig uiterlijk te krijgen; we kunnen het oppervlak wat onregelmatig maken en door af te wijken van de bol (maak een blob b.v.) lijkt op afstand de boom redelijk. Het is nog zeer stylistisch. Laat ik het maar een 'architecten-boom' noemen. Je vind ze vaak op perpectivische 3-D bouwtekeningen voor gebouwen. Betere boom Natuurlijk zijn wij niet de enigen die moeite hebben met het maken van bomen. Op het net waren diverse methodes te vinden die gebaseerd waren op 'recursie'. De eerste manier om een boom recursief op te bouwen komt van Stephan Kuhagen. Die vroeg zich af: als ik met commando's vanuit een PovRay scene beschrijving allerlei debug informatie (regels tekst) kan wegschrijven in een file, kan ik dan op die manier met behulp van programmalusjes niet een hele beschrijving van een boom, bestaande uit vele honderden aaneengeschakelde objecten te maken? En die later importeren in de scenebeschrijving? Dat kan. Laat ik eens een voorbeeld geven: #declare stapje=5
#while (stapje>0)
#debug "een tekst\n"
#debug "nog een regel tekst\n"
#declare stapje = stapje-1
#end
Het gevolg is dat er in de debug-file vijf keer de regels
een tekst nog een regel tekst
herhaald verschijnen. Met wat zorg kan je zo een hele nieuwe scene-file (of een include file) maken. Normaal gebruik je dergelijke lus constructies als je b.v. 20 telefoonpalen op regelmatige afstand op een rij wil plaatsen in de scene. Je bent dan wel gek als je twintig maal een copie van de paal op een andere plek gaat zetten als je de plek als het ware kan uitrekenen. Om het de gebruiker makkelijk te maken heeft Stephan zich wat moeite genomen. Je moet wat variabelen declareren en ze een waarde geven, dan de file selftree.inc includen, dan verder gaan met je scene beschrijving en als de boom nodig is de geproduceerde file via een tweede 'include' statement binnen halen en de boom laten maken met
object {Objectname}
Dat lijkt simpel, maar de praktijk is anders. Er zijn zoveel parameters in te stellen dat je geen echte greep hebt op de boomvorm. Er wordt gebruik gemaakt van random getallen en natuurlijk zullen die invloed hebben op het resultaat. Maar een andere startwaarde van de generator voor random getallen moet niet uitmonden in erg verschillend uitziende bomen. En dat is hier een beetje het geval. Vandaar het gevoel dat je de boomvorming niet echt in de hand hebt. Een paar experimenten leerden mij dat de bomen wel wat beter lijken dan de 'architecten-boompjes' maar nog verre van echt zijn. Laat ik de kwaliteit van deze boompjes maar met 'trein-modelbouw bomen' aangeven. Hier moet gezegd worden dat het uiterlijk van een bebladerde boom heel erg wordt bepaald door de bladeren. Wat mij ook tegen viel was de rekentijd: het parsen van grote lappen tekst kost tijd en ook het renderen gaat niet echt vlot. En dit blijft bij alle methoden een probleem: een beetje boom moet uit vele honderden en soms duizenden objecten worden samengesteld. En dat geeft langer rekentijden! Dat geldt vooral voor bladeren waarvan er vele aan een boom kunnen zitten. Een blad-object moet niet al te ingewikkeld zijn want dan vliegt de rekentijd explosief omhoog!
(!B)Tweede manier(!b)
Van Sonya Roberts komt een andere (meer normale) manier om een boom op te zetten. Maar ook hier: de vorm blijft sterk beinvloed worden door de startwaarden van randomgetalreeksen. Hoe dan ook: er zijn heel wat experimenten nodig om tot een gewenst
resultaat te komen. Heel fraai is dat er een ruime keuze is in bladvormen en dat je zelf makkelijk andere vormen kan maken. Er is zelfs gerekend op de aanwezigheid van fruit (bessen b.v.) aan de boom! Een ander groot pluspunt is dat de gebruikte variabelen allemaal intuitief juiste namen hebben. Aangezien we ondertussen bij versie 3 van dit bouwpakket zijn aangekomen zijn de meeste bugs wel verwijderd en is het aangepast aan redelijke wensen van gebruikers. Het is de moeite waard om aan de hand van dit pakket het 'boompje maken' nader onder de loep te nemen. Om de Engelse terminologie te gebruiken: er zijn 5 structuur niveaus te weten trunk, limbs, boughs, branches en twigs. Alleen de laatste kunnen bladeren, bloemen of fruit bevatten. Deze indeling klopt voor de meeste soorten loofbomen. Een vertakking heet een 'split'. Er zijn drie getallen om verschillende random reeksen te starten. Het zijn SD1 voor de 'splits', SD2 voor de distributie van bladeren en SD3 voor de rest. Ook hier weer: ziet een boom er vreemd uit dan verander je de SD1 waarde en probeert het nog een keer. Vooral de eerste splits bij de hoofdtakken hebben veel invloed op de algemene verschijningsvorm van de boom. De volgende belangrijke vormfactor is de hoek waaronder zijtakken zich afsplitsen. Voor alle drie de richtingen moet je een maximale en een minimaal toegestane hoek opgeven. Dat wordt dus goed kijken naar echte bomen om zinnige waarden in te kunnen vullen! Het eerste dat je bij observatie van dit aspect aan echte bomen opvalt is dat die hoek waaronder afgetakt wordt aardig kan verschillen dichtbij de stam en in vergelijking met de uiteinden van de boom. Ook voor dit effect is een instelling. Vaak splitsen takken zich ook een beetje om-en-om. Ook hier is in het model op gerekend. Verder zitten de uiteinden (de twijgen, twigs) anders aan het hout dan de andere takken. Ook hier is weer een aparte instelling voor. De opbouw van de diverse objecten waaruit onze boom bestaat gaat als volgt: eerst de stam. Dan wordt een random beslissing genomen over de zijtak. Dat gaat door totdat de twig bereikt is. Nu wordt in omgekeerde volgorde gewerkt en elke keer als er een split plaats vindt wordt die tot zijn eind vervolgd enz. Onder welke hoek wordt afgesplitst en in welke richting is allemaal instelbaar aan de hand van talrijke variabelen zoals ik al eerder heb gezegd. Ik ga de mensen er niet mee vermoeien want ik ruik al koffie. Maar nog even verder met de boom. Van groot belang is de mate van uitsplitsing: sommige bomen hebben veel takken en andere weinig. Er zijn hiervoor de MaxSplits en de MinSplits. Die geven aan hoeveel twijgen er aan een tak kunen zitten enz. Hoge waarden geven een warrelige boom. En bovendien: als je niet oppast maak je zoveel takken (dat aantal stijgt exponentieel) dat je nooit klaarkomt met rendering! Bij waarden van 3 en 4 krijg je al (gemiddeld natuurlijk) zo'n 1300 objecten. Er is wat op te bedenken. Meestal is het zo dat het aantal zijtakken in een boom niet zo groot is: het zijn de twijgen die in grote aantallen aan de tak zitten. Het is mogelijk om dit effect na te bootsen. Maar ook opgepast: een waarde van 1.25 maal voor de takdichtheid toename per niveau is te doen maar hoger resulteert in erg veel twigs! Heb je diverse exemplaren van een boom nodig die verschillen in grootte ga dan niet de boom na afloop schalen op de gebruikelijke manier: er zijn zoveel objecten die dan geschaald moeten worden dat het te lang duurt om door te rekenen. Je kunt beter bij het maken van de boom de grootte opgeven. Ook is het mogelijk de boom simpelweg meer of minder dicht te maken. Dan ziet het er ook gauw anders uit en de rendering tijd blijft binnen de perken.
(!B)Bladeren(!b)
Het leuke aan deze bouwdoos is dat er veel variatie is in bladvormen. Om te beginnen is er een ovaaltje dat snel verwerkt kan worden. Vervolgens is er een pijlvormig blad bestaande uit driehoeken (rekent ook snel). Deze bladvormen zijn alleen 'op afstand' te bekijken. Wat reëler en tevens wat langzamer zijn de vormen die ook wat volume hebben: Teardrop, Pine Needle, Bent Leaf. Komen de bladeren echt inzicht en zijn details belangrijk dan is Oak, Gingo en Palmetto bruikbaar. Ze zijn gemaakt met 'material maps'. Helemaal vrij ben je als je een eigen 'Leave' declareert met texture-beschrijving. De kleur en glans van het bladoppervlak zijn instelbaar: Yellow Green, Lime Green, Pale Green enz.
(!B)Vruchten en bloemen(!b)
Zijn er maar weinig vruchten die van dichtbij bekeken worden, b.v. een paar druiventrossen, dan kan je die zelf maken. Een aantal standaard fruitsoorten zijn beschikbaar: Lemon, Banana, Tripe Berry, Large Sphere, Small Sphere, Peach, Black Berry, Orange. Wat betreft bloemen is er niet veel keus. De basisvormen zijn er: Cup, Trumpet, Spiky met bijbehorende kleurverdelingen in de trant van oranje-geel, wit-rood en purple-violet.
(!B)De bast(!b)
Zeker bij een winterse boom is het uiterlijk van de bast belangrijk: wat voor kleur heeft die, is het ruw, glanzend enz? Een paar standaards textures zijn aanwezig: Birch Bark, Poplar, Pine, Bumpy Brown. Ook hier weer: men kan eigen textures maken. Nog even iets over het aantal objecten dat een blad samenstelt: ga niet hoger dan 3. Voor vruchten of bloemen waarvan er niet zoveel aan een boom zitten is de top wel bereikt met 5 tot 8 objecten.
(!B)Twijg met blad(!b)
Zeg je niets dan worden bladeren spiraalsgewijs om de twijg heen gezet. Hoeveel bladeren dat zijn leg je vast met LeafNum. Is het uiterlijk van de takjes een beetje te mathematisch dan kunnen de bladeren ook onregelmatiger geplaatst worden. Zet LeafRandRot aan en het het lijkt natuurlijker. Vaak zitten de bladeren met plukjes aan het takje. Zet dan
LeafRosette=true
en aan deze wens wordt voldaan. Dan is er nog de kestie: wat zit er aan het eind van een twijg? Bij default altijd een blad, maar wil je dat niet, geef dan het percentage met blad op: TipPercent. Soms wil je fruit of bloem aan het eind hebben zitten. Geef dan TipOther op (in procenten).
(!B)Bouwdoos nummer 3(!b)
De volgende bomenbouwdoos heet PTD-tree en is afkomstig van Paul T. Dawson. Het gebruik is simpel: doe een
#include "ptd_tree.inc"
gevolgd door
object {Complete_Tree rotate y*180}
om maar iets te noemen. De boom wordt wat anders bekenen dan in de methode van daarnet. Zijtakken worden op regelmatige afstanden langs de hoofdtak geplaatst. Bij 4 takken is de onderlinge hoek 90 graden, bij 6 takken 60 graden. Maar vaak gaat een zijtak verder aan het eind van een tak. Er is een switch om te zorgen dat zijtakken aan het eind ontspruiten. Voor de eenvoud is er maar een random-seed dus zoals ik al eerder gezegd heb: je kan weinig bijsturen. Lijkt de boom niet op wat je wil, probeer eens een andere startwaarde voor de random reeks met getallen. Er worden drie niveaus van vertakking onderscheiden. Voor elk niveau kan je het (gemiddelde) aantal zijtakken vaststellen
#declare Number_Of_Large_Branches = 5
idem dito voor Medium en Small. De hoek waaronder een zijtak van zijn hoofdtak afbuigt wordt random bepaald en ligt altijd tussen een maximum en een minimum hoek. Voor elk vertakkingsniveau is er een bijbehorende
#declare
Large_Branch_Minimum_angle = 30
en een maximum hoek. Wat betreft de manier waarop de lengte van de takken wordt bepaald is er gekozen voor een maximum/minimum begrenzing van de lengte per vertakkingsniveau.
#declare Small_Brach_Size_Max = 4
En zo ben je klaar met de beschrijving van de vertakking van de boom. Een heleboel details zoals de dikte van takken is ingebouwd. Het vergt studie van de include file om daar veranderingen in aan te brengen. Ik raad het niemand aan. Is er behoefte dan kan ik er wel privéles over geven. De dames kunnen zich na afloop bij mij melden voor persoonlijk onderricht. Ik zou het bijna vergeten, maar er moet natuurlijk ook even gepraat worden over de bladeren. Er zijn zes genummerde types blad. Ze variëren van platgeslagen bollen tot structuren die opgemaakt zijn uit driehoeken. In het laatste geval zijn zelfs bladsteeltjes mogelijk. Ook bij deze methode is het grote probleem: al die objecten moeten in het geheugen plaats kunnen vinden tijdens het renderen. En natuurlijk: zoveel objecten vergen ook veel rekentijd. Hou dit dus in de gaten. Als tip: begin eerst met weinig takken en voeg er langzaam wat meer aan toe totdat je geheugen overloopt of de raytracing-tijd uit de klauw loopt.
(!B)Planten(!b)
Hebben we bomen dan willen we meestal ook nog wel wat meer groene dingen in de scene hebben. Het eenvoudigste is het natuurlijk om een glad grasveld neer te leggen. Zolang het gras van afstand bekeken wordt hoef je niet elk grassprietje apart te maken. Een oppervlak van de juiste kleur met wat ruwheid enz, eventueel een soort wolkenpatroontje erin voor bruine platgetreden stukjes en het lijkt wel wat. Ik zou de cursisten willen voorstellen: op de volgende avondbijeenkomst komen we allemaal met een scene met gras erin. Wie maakt het mooiste gras? De hoofdprijs is een koffiezetapparaat en de troostprijzen moet ik nog bedenken. Iets heel anders zijn kruidige planten. Die zijn zo divers van uiterlijk dat je ze per soort moet maken. Haal je maar eens een narcis, een tulp, een ananasplant, een bereklauw, een guiehelheil, een stokroos en een zonnebloem voor ogen. Je kan die vormenrijkdom niet simpel met 1 model vangen, daar is het te divers voor. Ik heb op het net gekeken of er veel objecten zijn die op planten lijken. Wat ik kon vinden was een cactus en een beperkte include file voor 'kruidachtige groeisels' zal ik ze maar noemen. Het wordt tijd de onze verenigde bloemenindustrie maar eens met wat virtuele bloemen het Internet op gaat. Dat brengt me op een idee: Wilma zocht een leuk kado voor haar vriendje die diep in de bloembollenbusiness zit. Een virtuele tulp?
(!B)Botanie(!b)
Er is afschrikwekkend weinig materiaal te vinden over botanische zaken voor PovRay. Ik weet niet hoe het komt: het kan natuurlijk altijd zijn dat ik een site boordevol virtuele planten heb overgeslagen. Weet iemand iets, laat het mij weten want deze club hier heeft toch wel, als ik om mij heen kijk, een hoog groengehalte.
(!B)Radiosity(!b)
Zolang we met scenes werken die zich in de open lucht afspelen is er geen probleem maar zodra we binnenskamers gaan dan klopt het niet meer met de kleuren. De oorzaak is heel simpel voor te stellen met een volgende scene: in een kamer staat een gele lederen stoel op een blauw hoogpolig tapijt. De wanden zijn neutraal 90 procent grijs evenals het plafond en licht valt binnen via een raam. Licht dat teruggekaatst wordt door het tapijt kleurt de gele stoel en ook is de blauwe weerschijn op de muren bij de vloer bemerkbaar. We noemen dit verschijnsel 'radiosity'. Samenvattend kan je zeggen: elke plek op een voorwerp ontvangt licht van alle andere plekken via alle voorwerpen. Al het licht hangt dus samen. Heel holistisch maar wat kunnen we er in de praktijk mee aan? Versimpelen dus. Nu hebben we allemaal wel de 'ambient' gebruikt. Om te zorgen dat in donkere hoekjes niet alles pikzwart is kon je de global_ambient gebruiken zodat alle oppervlakten van voorwerpen wel een beetje licht als het ware uitstralen. We kunnen een ambient ook vastzetten aan het oppervlak van voorwerpen. Je kunt dit zien als een heel grove radiosity. Maar ambient is echte nep: het lijkt wel of het oppervlak licht uistraalt maar dat licht kan geen andere delen van de scene belichten! Dus met het ophogen van de blauwe ambient van het tapijt in ons voorbeeld schieten we niets op: er komt geen blauwe schijn op de muren en de stoel! De werkwijze kan als volgt: we gaan een beperkt aantal proef- zichtstralen, zeg 200, uitzenden vanuit het punt dat berekend moet worden. We gaan zien wat dat voor licht oplevert totaal. En we hopen maar dat we de zaak goed benaderen met zo'n steekproef.
Heeft zo'n zichtstraal een voorwerp getroffen dan wordt niet verder gekeken. Dus licht via via doet niet meer. Ook dit is een versimpeling die meestal goed uitpakt, behalve met kamers vol spiegels. Maar spiegels zijn een probleem op zich waar ik het misschien de volgende keer over zal hebben. Een verdere vereenvoudiging is mogelijk als we ons realiseren dat radiosity een diffuus lichtspel is. Een naastliggend punt op het oppervlak van een voorwerp zal niet een radikaal verschillende radiosity belichting kunnen hebben. Een gedeelte van de berekende resultaten kunnen dus voor naastliggende punten hergebruikt worden. Jullie snappen het wel: het is en blijft rekenintensief. Zo erg dat men heeft besloten dat een speciale opdracht in de ini-file nodig is (Radiosity=On) om het aan te zetten. Een ander probleem is dat met het gebruik van benaderingen er ook heel wat parameters opduiken die het rekenproces in goede banen moeten leiden.
(!B)Opzet (!b)
Ik zou zeggen: probeer eerst eens de default die als volgt is:
|
|
|