Creative-patent vertraagt vrijgave broncode Doom 3-engine

Klopt, stencilshadows hebben zo hun problemen. De voornaamste is dat een object 'waterdicht' moet zijn, of een "closed manifold" of "gesloten variëteit" in geometrische termen. Dat wil zeggen het oppervlak geen randen kent, of specifieker in 3D modeling, elke edge moet gedeeld worden door precies 2 polygonen.

Dit geldt natuurlijk wel voor simpele objecten zoals kubussen en bollen, maar lang niet altijd voor objecten die gemaakt worden door grafici. Neem bijvoorbeeld een boom met een tak. Gebruikelijk is om de polygonen van de tak iets door de boomstam heen te laten steken in plaats van ze perfect aan te sluiten op de stam en het "gat" dat de tak vormt in de stam uit de stam te knippen. Als je het rendert zie je dat soort dingen toch niet, maar dit geeft hele rare schaduweffecten als je stencil shadow technieken gebruikt. Het kost dus de nodige moeite om te zorgen dat al je content inderdaad waterdicht is als het schaduws moet werpen.

Een ander probleem is dat stencil shadows nogal hard zijn. Je ziet duidelijk de grens tussen een pixel die wel in de schaduw ligt en eentje die niet in de schaduw ligt, terwijl daar in de praktijk een wat breder verloop in zit.

Een derde probleem is dat het niet werkt met "gaten" in textures. Neem een hekwerk. Vaak is dat gewoon een enkele polygoon met een texture erop met een alpha kanaal, dat bepaalt welke pixels transparant zijn. Een stencil volume heeft daar geen weet van, en dus kan een dergelijk hekwerk nooit een schaduw werpen zonder de ijzerdraadjes in het hekwerk expliciet te modelleren.

Huidige technieken zijn gebaseerd op shadow buffers - feitelijk gewoon een diepteplaatje gerenderd vanuit het oogpunt van het ligt. Die dieptewaarden geven in feite de afstand tot het ligt. Door die shadow texture te projecteren op de omliggende geometrie en te controleren of de afstand van de pixel tot het licht kleiner of groter is dan de waarde in de shadowbuffer kun je bepalen of iets wel of niet in de schaduw valt. Die hebben geen last van bovenstaande problemen, maar die hebben weer hun eigen problemen ("surface acne" door precisieproblemen waarbij iets dat in het licht valt toch af en toe in de schaduw lijkt te vallen, en sowieso het geringe aantal pixels in een shadow buffer, helemaal bij zoiets als een laaghangende zon waar feitelijk de gehele scenery in de buffer gerenderd moet worden)

[Reactie gewijzigd door .oisyn op 16 november 2011 16:16]

Dan heb jij blijkbaar een ander artikel gelezen dan ik. "Carmack's reverse" is namelijk precies het algoritme dat gepatenteerd is door de mannen van Creative Labs.

Stencil shadows werken door een object te 'extruden' in de richting van het licht. Dit gehele volume beschrijft in feite de schaduw van het object in de 3D ruimte. Als er een te renderen pixel in dat volume valt, dan ligt het dus in de schaduw. Om alle pixels in de renderbuffer te markeren die in de schaduw liggen wordt de stenilbuffer gebruikt - dit zijn extra bits aan informatie die per pixel worden opgeslagen.

Nadat je de depth buffer hebt gevuld met alle geometrie in de scene, teken je de shadowvolumes van een licht, een volume per object waar het licht op valt. Dat volume is zoals gezegd opgebouwd uit een geëxtrude versie van het object, en bestaat dus uit polygonen. Je hebt front-facing polygonen, die naar de camera toe zijn gericht, en back-facing polygonen die van de camera af wijzen. Als je begint met een leeg stencilbuffer, en je verhoogt bij elke front-facing polygoon de waarde in de stencilbuffer en je verlaagt deze weer bij elke back-facing polygoon, dan hebben uiteindelijk alleen die pixels die in de schaduw vallen een stencilwaarde ongelijk aan 0. Dit komt omdat de depth test ervoor zorgt dat pixels die achter een al bestaande pixel ligt niet worden getekend. Als een dergelijke schaduw op de muur valt, dan vallen de front-facing polygonen van het volume vóór de muur (+1), en de backfacing polygonen áchter de muur (-1). Die laatste worden dus niet getekend, en dus houden de muurpixels in de schaduw een waarde van +1 in de stencilbuffer.

Dit werkt allemaal op zich prima, ware het niet dat het ook kan gebeuren dat de camera zich zelf ook in het volume kan bevinden. Op dat moment zie je feitelijk alleen nog maar backfacing polygonen van het volume (want de "front" facing polygonen, al kun je ze dan niet meer zo noemen, liggen achter je). Als je bovenstaande techniek gewoon hanteert, dan betekent dat dat ineens alle pixels op het scherm in de schaduw liggen.

De oplossing, die zowel John Carmack als de twee meneren van Creative Labs onafhankelijk van elkaar (volgens JC dan) hebben bedacht, is om de depth test juist om te draaien - render het schaduwvolume alleen als de pixels van het volume áchter de pixels van je geometrie liggen. Als de camera zich dan in het volume bevindt, dan zullen alleen die pixels in de schaduw komen waarbij de backfacing schaduwpolygonen zich áchter de muur bevinden. Bevinden ze zich voor de muur, dan worden ze niet gerenderd en wordt de stencilbuffer dus ook niet aangepast. Tevens werkt deze techniek ook als de camera zich niet in het volume bevindt. Ga maar na: als het volume volledig voor de muur ligt worden zowel de front- als backfacing polygonen niet getekend. Valt de muur in het volume dan worden alleen de backfacing polygonen getekent en krijgen de pixels een stencilwaarde hoger dan 0. Ligt het volume volledig achter de muur dan zullen zowel de front-facing als de back-facing polygonen worden getekent, en krijg je dus +1 en -1 en eindigt de stencilwaarde op 0.

[Reactie gewijzigd door .oisyn op 16 november 2011 16:02]