PROCEDURAL TEXTURING

Published
oktober 12, 2020

Procedural texturing is het procedureel genereren van textures: men stelt een serie regels op die een generator volgt om een eindresultaat te verkijgen, in dit geval een 2D texture. In procedural texturing gebruiken we vooral noise(ruis) generators, wiskundige functies, en blend operaties met maskeer lagen. Verder kunnen we ook 3D model informatie gebruiken om generators te sturen om zo bijvoorbeeld meer vuil te krijgen in hoeken, of beginnen van foto’s, vector data of andere textures.

Procedurele generatie van textures bestaat al lang, maar in de laatste 10 jaar is er enorme push gebeurd om volledige materialen procedureel te generen van start tot eind punt. Voorheen werd procedurele generatie gebruikt om een handmatige workflow bij te staan. 

De basis

Tijdens zijn werk aan TRON, ontwikkelde Ken Perlin het Perlin Noise algoritme. Hiervoor was procedural texturing vooral beperkt tot mathematische patronen, en Perlin zijn doel was om de machine-achtige uitzicht van computer graphics destijds te breken. Met zijn noise algoritmes kon hij controleerbare willekeurige ruis in beeld brengen. Zo legde hij de bouwstenen van procedural texturing workflows door het combineren van noise en patronen generators om zo textures te verkrijgen. De basistechnieken en algoritmes die hij destijds ontwikkelde worden nog steeds toegepast, en zijn over de jaren heen enkel nog maar verfijnt.

Tron (1982) © Disney

State of the art

Momenteel is er één dominante speler op de markt van procedural texture generation software, en dat is Adobe’s Substance Designer. De software is expliciet ontworpen om procedurele textures te creëren, met een enorme hoeveelheid aan kant-en-klare functies om het proces te vergemakkelijken. Verder kan men ook eigen generators en functies uitbouwen. Daarnaast heeft Allegorithmic verschillende integratiebruggen voorzien naar andere 3D software en real-time engines. Verder is het ook mogelijk om generators te bouwen die de modelinformatie gebruikt als basis om zo bijvoorbeeld automatisch roest, vuil of natheid toe te voegen aan een object.

In theorie kan men gelijkaardige resultaten bereiken in andere software, zoals Blender, 3dsmax, Houdini, etc. Dit is een goede oplossing als u niet buiten deze softwarepakketten werkt, maar vereist extra stappen om deze materialen buiten deze software te verkrijgen. In die software bouwt men vooral materialen, of shaders, die ontworpen zijn enkel gebruikt te worden door de gekozen render engine. Om het materiaal te exporteren naar andere software, rendert men de materiaal kanalen naar individuele textures, die u dan importeert in de andere 3D applicatie. Als u daarna de parameters van uw materiaal wil aanpassen, dan moet men de textures opnieuw renderen.

Parametric Fabrics © Adobe Substance

Real-time procedural materials

Maar hoe verkrijgen games dan al die dynamische materialen? Met shaders. Shaders zijn kleine programma’s die pixels renderen of vertices van een model manipuleren. Men kan enorm veel doen met shaders, zelfs real-time generatie van materialen.

Maar alles procedureel genereren in shaders is niet performant. Textures laden van de harde schijf is meestal nog steeds sneller dan procedurele generatie. Er zijn daarnaast nog veel andere processen in een game, en meestal is er geen ruimte in het performance budget om dit real-time te doen.

Een texture moet namelijk maar één keer geladen worden, terwijl operaties in een shader vaak elke frame worden uitgevoerd. Als oplossing gebruikt men een mix van beide methodes: textures worden één keer gegenereerd, en opgeslagen in een cache op de harde schijf, en worden dan opnieuw geladen uit deze cache. Hierdoor kan men ook de materialen dynamisch aanpassen tijdens minder intensieve delen van het spel.

Zo kan een game ontwikkelaar de memory footprint van zijn applicatie enorm verminderen omdat deze textures pas gegenereerd worden wanneer de eindgebruiker de output gaat zien. Textures nemen vaak het meeste data in beslag (ongeveer 30-35% van een modern AAA-game), en procedurele materialen zijn gemiddeld 45 keer kleiner. Procedurele materialen zijn ook onafhankelijk van de resolutie, ze kunnen op elke moment worden geschaald naar een hogere resolutie, zelfs in relatie tot de gebruiker zijn hardware. Het nadeel aan deze techniek is dat dit laadtijden meestal verhoogt, en omdat nog steeds veel games uitkomen met gigantische werelden, zonder laadtijden, opteren game ontwikkelaars nog steeds om zelf deze textures te exporteren vanuit hun procedural texturing software.

Rival Wheels © Gameloft

Maar deze techniek is wel zeer interessant voor mobile developers. Gameloft heeft zo enorm uitgebreide games kunnen lanceren met groottes van minder dan 30 Mb, maar op een gelijkaardig visueel niveau als moderne AAA titels.

Een nog extremer voorbeeld van deze techniek is het spel .kkrieger (2004) waarbij alles procedureel gegenereerd wordt tijdens de laadtijd van het spel. De totale grootte van de applicatie is slechts 96 kB. Ter referentie: Half life 2 (2004) was 4 GB groot, en de PC-cd-versie installatie was verspreid over 5 cd’s. 

Met de transitie naar online distributie zijn file groottes geëxplodeerd. Zo zijn de laatste AAA-games gemakkelijk 100 GB groot, en dit is nog een groter probleem voor console games die nog steeds deels gebonden zijn aan de beperkte grootte van een Blu-ray disc. Het besparen van geheugen is daarom een enorm voordeel voor ontwikkelaars en spelers.

Conclusie

Procedurele materialen zijn de standaard geworden in computer graphics wegens de enorme productiewinst. Er zijn nog voordelen aan semi real-time generatie, maar deze zijn nog niet de norm omdat applicatie grootte nog niet een hoge prioriteit is in vergelijking met laadtijden en real-time performance. Met continue evoluerende hardware en streaming komt hier verandering in.