Videokaarten zijn met afstand de meest besproken computercomponenten. Voor gamers is de videokaart dan ook het onderdeel dat de meeste invloed heeft op de prestaties, maar hoe werkt een videokaart eigenlijk? Vandaag nemen we een diepe duik in de moderne graphicspipeline, oftewel hoe jouw videokaart van 3d-modellen en textures razendsnel een compleet beeld maakt voor op je monitor.
Een korte geschiedenis van de videokaart
Als we het vandaag hebben over de prestaties van een videokaart, doelen we op de snelheid bij het renderen van 3d-beelden. Toch was dat oorspronkelijk helemaal niet de functie van een videokaart. De eerste videokaarten dienden om het 2d-beeld van de desktop te converteren van digitaal naar analoog; beeldschermen werden destijds immers met analoge interfaces als VGA aangesloten. Het belangrijkste onderdeel van een videokaart was dan ook de ramdac.
De eerste echte videokaart was de IBM Monochrome Display Adapter, zoals in 1981 gebruikt in de eerste IBM-pc's. Deze kaart kon nog geen losse pixels aansturen, maar alleen tekst weergeven in een vak van 80 kolommen en 25 rijen. Aangezien elk karakter bestond uit 9x14 pixels, was de resolutie van het complete scherm in theorie 720x350 pixels. In de jaren tachtig en negentig evolueerden zowel het aantal kleuren dat kon worden weergegeven, als de resolutie, totdat rond 2000 een combinatie van een 1600x1200-resolutie en het sRGB-kleurenpalet (16,7 miljoen kleuren) de standaard werd.
In de jaren negentig begon de 3d-game aan zijn opmars. De uiterst populaire shooter Doom maakte in 1993 nog volledig gebruik van de processor voor het berekenen van alle beelden, wat de mogelijkheden op het gebied van graphics enorm beperkte. Traditionele cpu's waren weliswaar inzetbaar voor allerlei verschillende taken, maar niet geoptimaliseerd om continu dezelfde taak uit te voeren. Een chip speciaal ontworpen voor dit specifieke, uiterst parallelle rekenwerk zou dat veel efficiënter en sneller kunnen doen.
Dankzij de dalende prijzen van dram slaagde het Amerikaanse 3dfx er in 1996 in om een 3d-acceleratiekaart op de markt te brengen die voor normale consumenten bereikbaar was: de Voodoo. Zo'n kaart kon zelf geen 2d-beelden genereren en moest dus worden gecombineerd met een traditionele 2d-videokaart. In 1997 wisten concurrenten als ATI en Nvidia beide functies op één kaart te combineren. 3dfx kwam pas in 1999 met een competitieve 2d/3d-kaart, maar zowel technische nadelen als marktomstandigheden luidden het einde van dit bedrijf in, waarna het voornamelijk voor zijn patentenportfolio werd ingelijfd door Nvidia.
Vanaf 2000 tot nu wordt de markt voor gpu's in pc's dus al gedomineerd door twee partijen: AMD (dat ATI in 2006 overnam) en Nvidia. Het basisprincipe van hoe een videokaart werkt, bestond toen al, maar in de afgelopen twee decennia heeft de videokaart er de nodige taken bijgekregen, taken die eerst bij de processor lagen, of geheel nieuwe functies, zoals tessellation en realtime raytracing.
In dit artikel zetten we uiteen hoe een gpu werkt, met de stappen van de graphicspipeline als leidraad. Kortom, zorg voor een verse kop koffie of thee en duik met ons mee in de wereld van de moderne videokaart.
De graphicspipeline
De graphicspipeline is het concept waarmee een gpu een 3d-scène omzet in een 2d-beeld dat op een monitor kan worden weergegeven. Waar de wereld waarin je in een moderne game beweegt, driedimensionaal is, net als onze echte wereld, geeft een beeldscherm slechts een tweedimensionale impressie van die wereld. De illusie van diepte kan hooguit worden opgewekt door lijnperspectief. Het doel van de graphicspipeline is dus om 2d-beelden te genereren op basis van een 3d-model, dat onder meer bestaat uit geometrie als afmetingen en plaats, en de eigenschappen van de oppervlakte.
Op hoofdlijnen bestaat de graphicspipeline uit drie stappen: de applicatie, geometrie en rastering.
Stap 1: Applicatie
De eerste stap van de graphicspipeline begint niet in de videokaart, maar in de processor. De game levert via een api als DirectX of OpenGL alle informatie aan die nodig is om de scène te renderen. De processor berekent op basis daarvan hoe de virtuele 3d-wereld eruit moet komen te zien: hoe groot hij moet zijn, welke objecten erin voorkomen, op welke plek die objecten moeten komen, hoe groot die objecten moeten zijn en ga zo maar door. Hieruit komt een lijst met 3d-coördinaten van alle punten die aanwezig zijn in de scène.
Een dergelijk punt wordt een vertex genoemd. Deze vertices zijn de hoekpunten van driehoeken, de geometrische figuur die aan de basis staat van alle 3d-objecten. Wellicht ben je in de wereld van 3d-modellen al eens tegen de term triangle of polygon count aangelopen, want het concept is simpel; hoe meer driehoeken waaruit het object bestaat, hoe gedetailleerder het eruit komt te zien. De lijst met primitives, een verzamelnaam voor driehoeken, lijnen en vertices, wordt uiteindelijk naar de videokaart gestuurd.
Elk 3d-object, zelfs deze bol, bestaat uit driehoeken (triangles) met punten (vertices) en lijnen, die samen primitives worden genoemd. Door P.-O. Persson onder GNU GPL
Draw calls
Het moment waarop een set instructies naar de videokaart wordt gestuurd, heet een drawcall. Zo'n drawcall kan instructies voor verschillende primitives bevatten en dat is maar goed ook, want een gpu kan vele malen meer primitives verwerken dan een processor drawcalls kan versturen. Opeenvolgende drawcalls worden letterlijk over elkaar heen getekend. De eerste drawcalls bevatten dus de vertices van objecten op de achtergrond, waarna steeds meer naar de voorgrond wordt toegewerkt. Ook als de manier verschilt waarop een object moet worden weergegeven, bijvoorbeeld als de materiaaleigenschappen veranderen, is er een nieuwe drawcall nodig.
Om het aantal drawcalls te optimaliseren, moeten slimme combinaties worden gemaakt van de opbouw van objecten die geen directe relatie met elkaar hebben. Zo kan tegelijk worden 'gebouwd' aan verschillende objecten zonder dat voor elke nieuwe laag van ieder object een losse drawcall nodig is. Een ander voordeel hiervan is dat de gpu-rekenkracht zo beter benut wordt. Een grotere drawcall houdt de gpu immers langer bezig, zodat er geen lange idle-tijd ontstaat waarin de gpu moet wachten op nieuwe instructies van de processor.
Camerastandpunt
Ook het camerastandpunt krijgt een plek in de gegenereerde 3d-wereld, want in feite is dat weinig anders dan een object, zij het onzichtbaar. In firstpersonspellen is het camerastandpunt gelijk aan de locatie van de speler, maar als je een derdepersoonsperspectief gebruikt, is dat natuurlijk niet zo. Op basis van deze informatie kan worden berekend welke delen van de 3d-wereld zichtbaar zullen zijn op het scherm. Alles vóór het near-clipplane en achter het far-clipplane wordt weggelaten. In de praktijk staat het far-clipplane vaak buiten de gevulde wereld, terwijl het near-clipplane voorkomt dat objecten het zicht vanuit het camerastandpunt blokkeren. Bovendien dienen deze planes als renderlimieten; de weergegeven wereld moet immers ergens beginnen en eindigen.
Het camerastandpunt met het near-clipplane (je scherm) en far-clipplane (achtergrond). Cosmo 3D Programmer's Guide
Buiten zijn taken in de graphicspipeline is de processor bij veel games overigens ook verantwoordelijk voor het berekenen van AI-gedrag en beweging, en het verwerken van de input die jij als gamer geeft.
Geometrie en shading
Waar stap 1 vooral op de processor wordt uitgevoerd, zijn de laatste twee stappen van de graphicspipeline de verantwoordelijkheid van de videokaart.
Geometrie en vertexshaders
In de geometriefase wordt het leeuwendeel van de berekeningen met driehoeken en de bijbehorende vertices gedaan. Dat gebeurt door de vertexshaders, als het ware kleine programmaatjes die op de shadercores van de gpu draaien. Vertexshaders kunnen de vertices aanpassen, waarmee ze in feite de vorm van het object manipuleren.
Het eerste deel van dit rekenwerk wordt gevormd door de transformaties, die alle objecten op de juiste manier in de virtuele wereld plaatsen. Cruciaal hierbij is de omzetting van de coördinaten in de losse 3d-modellen naar het coördinatensysteem van de virtuele wereld. De enige generieke voorwaarde is dat alle assen (lengte, breedte en diepte) in die virtuele wereld dezelfde schaal volgen. Of dat in microns of meters gebeurt, is niet zo relevant en kan per scenario verschillen.
De transformaties bestaan uit een aantal basisbewegingen: verplaatsing in een rechte lijn (translation), rotatie (op beide assen, dus draaien of kantelen) en schaling. Ze maken allemaal gebruik van matrixberekeningen, waarin een getallenmatrix wordt vermenigvuldigd met de oorspronkelijke coördinaten om de nieuwe positie vast te stellen.
In de begintijd van de videokaart werden hiervoor vaste matrices gebruikt, maar in de loop der tijd zijn de vertexshaders in toenemende mate programmeerbaar geworden. Er kunnen dus allerlei matrices worden ingeladen om bepaalde effecten te bereiken. Daarbij moet je vooral denken aan manieren om transities vorm te geven, bijvoorbeeld waar twee objecten elkaar raken, maar ook uitdagende oppervlakken als water, vacht en vuur kunnen met eigen vertexshaderprogramma's realistisch worden nagebootst.
Als de vertices zijn getransformeerd, worden ze op verschillende manieren belicht. De 3d-wereld kent verschillende soorten licht, zoals omgevingslicht en reflecterend licht. In moderne games worden vrijwel altijd lichtbronnen gecombineerd die op verschillende posities in de scène zijn geplaatst.
Als de zon een van de lichtbronnen is, wordt die doorgaans geïmplementeerd als directional light, oftewel een lichtbron die parallelle lichtstralen in een bepaalde richting uitstraalt. Een directional light is relatief makkelijk te berekenen in vergelijking met bijvoorbeeld een pointlight, een lichtbron die in alle richtingen schijnt binnen een bepaalde effectradius. Een spotlight is dan weer vergelijkbaar met een pointlight, maar heeft een afgekaderde hoek van effect.
Lichtbronnen kunnen verschillende eigenschappen hebben. Unity Technologies, bewerking door Tweakers
De berekende belichting van een vertex is de uitkomst van de geprogrammeerde materiaaleigenschappen, de gebruikte soorten licht en de positie van de vertex in de scène. Voor het uiteindelijke beeld is de hier berekende belichting overigens slechts een van de factoren bij het bepalen van de kleur van een vertex. Ook de gebruikte texture zal daar bijvoorbeeld nog invloed op hebben.
Rasterization: van 3d naar 2d
In de volgende stap wordt de 3d-wereld gerasterd en daarmee omgezet in het 2d-beeld dat op je monitor verschijnt. Hierop wordt eerst nog een aantal voorbereidingen getroffen. Een deel van de nu berekende vertices zal in het eindresultaat namelijk helemaal niet zichtbaar zijn en wordt daarom vóór de rasterization verwijderd uit de pipeline, om onnodig rekenwerk te voorkomen en zo de prestaties te verbeteren.
Backface- en frustumculling
Eerder in dit artikel, bij de eerste stap van de graphicspipeline, bespraken we al hoe clipping ervoor zorgt dat objecten niet onbedoeld het zicht vanuit het camerastandpunt blokkeren. Er zijn echter nog meer objecten in de 3d-wereld die in het uiteindelijke frame niet zichtbaar zullen zijn.
Backface-culling. A Survey of Visibility for Walkthrough Applications, door D. Cohen-Or, C.T. Silva en Y. Chrysanthou, via Researchgate
De twee meest tot de verbeelding sprekende voorbeelden zijn backface-culling, waarbij de achterkant van objecten wordt verwijderd, en frustumculling, oftewel het weggooien van alles wat zich buiten het zichtbare volume bevindt. Backface-culling verwijdert niet-zichtbare driehoeken, frustumculling is verantwoordelijk voor volledige objecten of meshes die buiten het frustum (de denkbeeldige piramide vanuit het camerastandpunt) vallen.
Een voorbeeld van frustumculling in de game Horizon Zero Dawn. 'All in the game', VPRO Tegenlicht
De viewport wordt vanaf hier gedefinieerd in 2d; diepteinformatie wordt opgeslagen in de z-buffer om te bepalen of een object voor of achter een ander object is gepositioneerd.
Triangleset-up en rastering
Bij het rasteren worden alle primitives - driehoeken, lijnen en punten - omgezet in fragmenten. Waar de virtuele 3d-wereld gebaseerd was op natuurkunde en daarmee doorlopend is, bestaan beeldschermen uit losse punten. Een lijn in de 3d-wereld is letterlijk een continue lijn van punt A naar punt B, een lijn op je monitor bestaat uit een rij punten (pixels). Elk fragment correspondeert met een punt in de framebuffer en daarmee met een pixel op je monitor.
De bij de vorige stap gegenereerde vertices worden omgezet in driehoeken, een proces dat triangleset-up wordt genoemd. Die driehoeken worden stuk voor stuk op het raster gelegd, waarbij het raster in feite de resolutie is. In de praktijk komen punten en lijnen vaak niet exact op de positie van een pixel terecht, waardoor er geïnterpoleerd wordt. Een lijn die een pixel slechts voor een deel doorkruist, zal die pixel ook maar voor een deel kleuren. Uiteindelijk kan een gerasterd beeld echter niet met grotere precisie dan de resolutie worden gevuld, waardoor schuine lijnen een gekartelde rand krijgen, wat met postprocessing zoals anti-aliasing kan worden opgelost. Dat volgt echter pas later.
De driehoeken van de triangleset-up worden gerasterd, oftewel omgezet in pixels. David van Dantzig, Hardware Info
Pixelshader en textures
Vervolgens komen we aan bij het tweede programmeerbare onderdeel van de graphics pipeline: de pixelshader. Net als bij de vertexshaders gaat het hier om miniprogramma's die op de gpu-cores draaien. Waar vertexshaders echter nog in de 3d-wereld actief waren en bewerkingen doorvoerden aan vertices, worden de pixelshaders pas na het rasteren uitgevoerd en vinden de bewerkingen plaats op pixelniveau. De prestaties van de pixelshaders schalen dan ook lineair met de resolutie waarop het beeld rendert.
Alle fragmenten hebben inmiddels een basiskleur en een lichteffect, doorgaans gegenereerd door middel van Phong-shading. De meeste objecten bevatten echter veel meer detail dan je alleen op basis van die twee zaken kunt genereren. Je zou meer detail kunnen toevoegen door meer geometrie toe te voegen, maar dat zou de hoeveelheid rekenwerk en de grootte van de modellen fors verhogen. De oplossing die hiervoor is bedacht, is het toepassen van een texture, simpel gezegd een plaatje dat op een object wordt gelijmd. Vergelijk het met een wereldkaart die op een globe wordt geplakt; de aanname dat de aarde een perfecte bol is klopt niet helemaal, maar voldoet voor de functie.
Textures zijn eenvoudige 2d-plaatjes; je kunt elke jpeg over een object heen plakken. De pixels van een texture worden texels genoemd. Omdat textures op allerlei verschillende manieren kunnen worden toegepast, al is het maar omdat je een object in een game van variabele afstanden kunt bekijken, hoeven de texels niet overeen te komen met de fragmenten. Er kan dan op verschillende manieren worden geïnterpoleerd, bijvoorbeeld op basis van de meest nabije texels.
Zoals gezegd is de pixelshader net als de vertexshader programmeerbaar, wat betekent dat gameontwikkelaars zelf kunnen bepalen hoe een texture precies wordt toegepast op een fragment. Nu de uiteindelijke kleur van de beeldpunt beschikbaar is, spreken we officieel van een pixel, vandaar de naam van deze rekeneenheid.
Verrijking met bump- en displacementmaps
Reguliere textures bevatten informatie over de kleur van de texels, maar er worden ook andere soorten textures gebruikt. Een frequent gebruikt voorbeeld is de bumpmap, waarbij de kleuren van de texture niet staan voor daadwerkelijk kleurgebruik, maar voor hobbels in het oppervlak. De lichteffecten houden hier rekening mee, waardoor de illusie van diepte wordt gecreëerd zonder dat die in de geometrie daadwerkelijk aanwezig was.
Dat laatste wordt alleen wel duidelijk zichtbaar als je in de game erg dichtbij komt of schuin naar het oppervlak kijkt. Een oplossing hiervoor is een displacementmap, een zwart-wittexture die structuurafwijkingen daadwerkelijk doorvoert in de geometrie. Ook schaduwen kunnen worden gegenereerd met een texture, door de z-buffer vanuit het perspectief van een lichtbron op te slaan als een shadowmap.
Een platte texture aangevuld met een displacementmap kan reliëf in het oppervlak genereren. Combining Texture-Derived Vibrotactile Feedback, Concatenative Synthesis and Photogrammetry for Virtual Reality Rendering, Magalhães et al, 2019 via Researchgate
Naast bump- en displacementmaps kunnen gameontwikkelaars nog diverse andere soorten textures gebruiken. Zo bepalen specular maps de hoeveelheid reflectie, bepalen emissive maps hoeveel en wat voor licht wordt uitgestraald, en voegen normal maps hobbels en deuken toe aan het oppervlak. Verdere optimalisatie hiervan is mogelijk door twee typen textures te combineren in één 32bit-texture. Dan wordt bijvoorbeeld een normal map opgeslagen als kleurinformatie, terwijl het alfakanaal (de transparantie) de bump- of roughnessmap bevat.
In onderstaand voorbeeld zie je een 3d-model van een Pegassi Zentorno uit GTA V met diverse soorten textures toegepast, tot aan het eindresultaat inclusief postprocessingeffecten.
Doordat licht- en schaduweffecten in het rasterproces met shaderprogramma's worden berekend, kun je stellen dat ze 'nep' zijn. Het resultaat geeft weliswaar een impressie van hoe een reflectie of schaduw eruit zou zien, maar neemt een loopje met de natuurkunde die daar in de echte wereld op van toepassing is. Dat is van oudsher een compromis, want het in real time berekenen van alle échte lichtstralen was lange tijd onmogelijk met de beschikbare hoeveelheid rekenkracht.
Schaduwen, reflecties en raytracing
Het primaire doel van waaruit de rastermethode is bedacht, is het zo beperkt mogelijk houden van de vereiste rekenkracht. Door alle vormen van culling, clipping en z-buffering hoeven alleen de onderdelen die daadwerkelijk in beeld zijn, te worden berekend en gerenderd. Dit is direct ook de zwakte van deze techniek; doordat er zoveel informatie wordt weggegooid, kunnen na het rasteren geen effecten meer worden toegevoegd die gebaseerd zijn op de virtuele 3d-wereld. Na het rasteren kan er immers alleen nog worden gewerkt met het gegenereerde 2d-beeld.
Voor het berekenen van de directe effecten van lichtbronnen zijn eerder in de pipeline mogelijkheden, maar voor het maken van de gevolgen, reflecties en schaduwen, moeten ontwikkelaars vertrouwen op trucs om ze zo goed mogelijk na te maken. Daarvoor bestaan allerlei technieken die door de jaren heen ontegenzeggelijk geavanceerder zijn geworden, maar als je goed kijkt, zul je zien dat schaduwen en reflecties in traditioneel gerasterde vorm nooit écht kloppen.
Een veel toegepaste techniek om ondanks de beperkingen enigszins realistische reflecties te berekenen is cubemapping, waarbij een denkbeeldige kubus om een reflecterend object wordt geplaatst. Vanuit het middelpunt van de kubus wordt het object opnieuw gerenderd, met de zes zijden als camerastandpunten. Het resultaat bestaat uit zes textures, die vervolgens nog eens boven op de bestaande textures van het object worden geplakt. Tenzij een object perfect vierkant is, past dat niet helemaal lekker, dus dat gaat zo goed als het gaat. Bovendien wordt er geen rekening gehouden met het oorspronkelijke camerastandpunt en andere reflecterende objecten in de omgeving.
Cubemapping is een veel toegepaste truc om enigszins, maar absoluut niet volledig realistische schaduwen te creëren. Panorama cube map door SharkD onder CC BY-SA 3.0
Raytracing to the rescue
De heilige graal is het volledig natuurgetrouw volgen van alle lichtstralen door de virtuele 3d-ruimte, zodat reflecties en schaduwen fotorealistisch kunnen worden gerenderd. De techniek die daarvoor wordt ingezet, is raytracing en wordt ondersteund in DirectX 12 en Vulkan.
Hoewel de vereiste berekeningen geen sinecure zijn, is het principe best simpel. In de echte wereld komen lichtstralen van allerlei bronnen - de zon, lampen, reflecterende voorwerpen - onze ogen binnen. Raytracing werkt exact andersom; er worden lichtstralen (rays) 'verstuurd' vanuit het camerastandpunt, feitelijk vanuit elke pixel van de beeldresolutie, die door de volledige virtuele 3d-wereld worden gevolgd. Als een lichtstraal een object raakt, wordt aan de hand van de bekende kenmerken daarvan berekend hoe en welk deel van het licht wordt gereflecteerd. Ook refractions zijn mogelijk, oftewel het breken van licht waarbij het (deels) door een object heen gaat, maar waarbij wel de hoek kan worden veranderd.
Zodra een lichtstraal met een object botst, wordt een ray richting elke lichtbron in de scène berekend. Als die ray een ander object raakt, wordt duidelijk dat dit andere object een schaduw werpt op het eerste object en de desbetreffende lichtbron dus geen invloed heeft. Afhankelijk van de materiaaleigenschappen van het object worden ook de reflectie en/of refractie doorgerekend. Dat gebeurt steeds opnieuw totdat alle stralen volledig zijn berekend en de uiteindelijke kleur van elke pixel duidelijk is.
Ten opzichte van hoe de natuur echt werkt, is raytracing een enorme simplificatie, maar gezien de beperkte resolutie van een monitor is meer dan één startray per pixel eigenlijk niet nodig om tot een fotorealistisch eindresultaat te komen. Toch kan ook raytracing een enorme hoeveelheid rekenwerk opleveren. Voor elk bereikt object moeten er rays naar elke lichtbron worden gestuurd en voor objecten die licht reflecteren of breken, neemt het aantal rays snel toe. Bedenk bovendien dat een lichtbron in de praktijk ook veel ingewikkelder is dan de aanname die we tot nu toe hebben gebruikt, die van een enkele lichtgevende punt. In de praktijk kan een volledig doorgerekende scène uit miljarden rays bestaan.
Raytracing is overigens geen nieuwe technologie. Hoe de wiskunde erachter zou moeten werken, werd al aan het einde van de jaren zeventig bedacht. Computers waren in de daaropvolgende decennia echter veel te langzaam om raytracing in real time uit te voeren. Voor 3d-animatiefilms werd al veelvuldig gebruikgemaakt van raytracing, maar daarmee gaan rendertijden van minuten of zelfs uren per frame gepaard.
Hoe raytracing nu toch in real time kan
Hoewel raytracing de ultieme opvolger van de rastertechniek zou kunnen zijn, is de hoeveelheid rekenkracht waarover een moderne videokaart beschikt, veel te klein om realtime raytracing toe te passen. Om eerlijk te zijn zien we dat ook niet snel veranderen. Videokaarten zijn in de voorbije jaren wel flink sneller geworden, maar games ook een stuk zwaarder, intrinsiek, maar ook doordat we ze op steeds hogere schermresoluties zijn gaan renderen. Netto levert dat dus geen winst op, laat staan de enorme winst die nodig zou zijn om in real time te raytracen.
Wat Nvidia en AMD in de afgelopen paar jaar hebben geïntroduceerd als realtime raytracing, betreft dan ook geen raytracing van de volledige scène, maar uitsluitend van de zaken waarvoor traditionele rastering zich het minst leent: schaduwen en reflecties. Daarnaast worden lang niet alle rays doorgerekend, maar krijgt een videokaart voor elk frame een 'tijdsbudget' waarbinnen hij zoveel mogelijk lichtstralen mag berekenen. Als dit tijdsbudget op is, wordt het proces afgekapt en wordt verder gerekend met het resultaat tot dan toe, eventueel verfijnd door denoising-algoritmes.
De zogenaamde raytracingcores nemen slechts een deel van het hierboven omschreven proces voor hun rekening: het berekenen van het pad van verstuurde rays tot aan het punt waar ze een ander object raken. Alle overige zaken, zoals het berekenen van de daadwerkelijke reflecties, blijven behoren tot het takenpakket van de reguliere pixelshaders. Door juist het rekenintensiefste en vaakst voorkomende deel van het raytracingproces hardwarematig te versnellen - de speciale cores doen dit werk ongeveer tien keer zo snel als normale shaders - wordt realtime raytracing mogelijk gemaakt.
De RT-cores nemen een zeer specifiek deel van de berekeningen over van de reguliere shaders, maar kunnen dat dan ook ongeveer tien keer zo snel.
Bovendien betekent het verplaatsen van het raytracen naar speciaal hiervoor bedoelde cores natuurlijk ook dat de pixelshaders tijd hebben voor ander werk. Als het raytracen gewoon door de pixelshaders zou gebeuren, zou dat ten koste gaan van de 'reguliere' kracht van deze rekeneenheden.
Bounding volume hierachy
Hoe kunnen die relatief kleine raytracingcores nu zoveel sneller raytracen dan conventionele shaders? Hiervoor passen AMD en Nvidia een bounding volume hierarchy-algoritme toe. In plaats van voor álle lichtstralen voor élke driehoek te berekenen of hij wordt geraakt, worden alle objecten opgedeeld in vrij grove blokken. Het algoritme bepaalt eerst in welk van de hoofdblokken een lichtstraal eindigt. Vervolgens wordt berekend in welk subblok dat dan het geval is, wat wordt herhaald totdat de kleinste blokgrootte wordt bereikt. Daarin zit een beperkt aantal objecten, waardoor de berekening naar het eindpunt van de lichtstraal relatief makkelijk is. Als dit eindpunt is gevonden, zit het werk van de RT-cores erop.
Het bvh-algoritme maakt het mogelijk om zeer efficiënt het eindpunt van een ray te achterhalen.
Inzet in moderne games
Zoals gezegd wordt realtime raytracing in de meeste games ingezet voor het berekenen van schaduwen en/of reflecties. Van die twee zijn schaduwen het minst ingewikkeld. Als je vanuit elke pixel berekent of er een directe straal is richting alle lichtbronnen of dat die straal wordt onderbroken door een object, kun je schaduwen al een heel stuk realistischer weergeven dan met conventionele technieken.
Reflecties zijn een stuk rekenintensiever, maar maken dan ook beelden mogelijk die met rastering niet haalbaar zijn. Natuurlijk worden er in games zonder raytracing trucs toegepast om reflecties na te maken, maar doorgaans hoef je niet bijzonder goed te kijken om op te merken dat wat er gebeurt, toch niet helemaal klopt.
Voor zowel reflecties als schaduwen geldt dat ze eventueel met een lagere nauwkeurigheid kunnen worden berekend dan de 'echte' beelden, omdat ze van nature vaak minder scherp zijn. Daarnaast heeft een gameontwikkelaar natuurlijk zelf in de hand hoeveel reflectieve objecten en lichtbronnen er aanwezig zijn. Bovendien komen er doorgaans nog de nodige effecten overheen, al dan niet met behulp van AI-algoritmes als denoising.
Filtering en anti-aliasing
Als je regelmatig te vinden bent in het instellingenmenu van je favoriete game, ben je ongetwijfeld de termen filtering en anti-aliasing tegengekomen. In veel games kun je van beide functies de hoeveelheid instellen, vaak uitgedrukt in 'aantal keer'. Beide technieken zijn oplossingen voor fundamentele problemen bij het renderen van een 3d-wereld op een 2d-monitor.
Filtering
Het probleem dat filtering tracht te verhelpen, is dat texels (de pixels van een texture) lang niet altijd overeenkomen met de pixels van je monitor. Textures zijn bovendien 2d-afbeeldingen, terwijl objecten in de virtuele wereld driedimensionaal zijn. Zoals we op de pagina over rasterization al bespraken, moet er worden geïnterpoleerd tussen texels om te bepalen welke kleur een pixel moet krijgen. Alleen zo kan een texture op realistische wijze op een 3d-object worden 'geplakt'.
Filtering is de naam voor dat bijrekenen. De basaalste vorm hiervan was van oudsher bilinear filtering, waarbij de vier pixels rondom een texel werden geïnterpoleerd als benadering van een 'cirkel' om de texel heen. Dat werkt prima als je in een game recht op het object met de texture kijkt, maar wordt problematisch als het object onder een hoek is geplaatst ten opzichte van de camerapositie, de vloer bijvoorbeeld. Als je een cirkel onder een hoek bekijkt, wordt het immers een ellips, waardoor de interpolatie op basis van een cirkelvorm niet langer het gewenste resultaat oplevert. Vooral objecten dieper in de 3d-scène worden op basis van traditionele filtering al gauw wazig.
Als je een cirkel onder een hoek bekijkt, wordt het een ellips en volstaat bilinear filtering niet meer. High quality elliptical texture filtering on GPU, P. Mavridis en G. Papaioannou, 2011 via Researchgate
In moderne games wordt daarom anisotropic filtering toegepast. Isotroop betekent dat de eigenschappen van een materiaal in alle richtingen gelijk zijn; dat is hierbij dus niet het geval. Eerst wordt namelijk de ellipsvorm berekend die door de kijkhoek gerechtvaardigd wordt, waardoor de toegepaste filtering per richting verschillend wordt. Zo kan ook een object dat relatief ver van de camerapositie is verwijderd, met scherpe textures worden ingevuld.
Anisotropic filtering houdt ook textures die dieper in de scène zijn geplaatst scherp. Cobblestones door THOMAS onder CC BY-SA 3.0
Het 'aantal keer' dat je instelt in je gamesettings, betreft overigens de mate van anisotropie, oftewel hoe groot de hoek ten opzichte van het camerastandpunt moet zijn voordat er niet langer filtering wordt toegepast. In de praktijk zijn textures onder een grote hoek, en vaak ook dieper in de scène, vaak slecht zichtbaar. Daardoor is het voor het complete plaatje niet de moeite waard om álles te filteren.
Anti-aliasing
Het tweede fundamentele probleem van een naar pixels gerenderd beeld is aliasing. Dit effect wordt veroorzaakt doordat de pixels op je monitor relatief grote vierkanten zijn, waarbij elk vierkant uitsluitend de kleur van het midden van die pixel heeft. Een horizontale of verticale lijn van een pixel breed weergeven is daardoor eenvoudig, maar een schuine lijn kan alleen bestaan uit blokjes die op een gegeven moment een kolom verspringen. Dit neem je waar als een kartelrand, bijvoorbeeld bij de rand van een object.
De oplossing voor aliasing is in de basis simpel; render het beeld groter dan het uiteindelijk moet worden, en verklein het daarna weer naar de bedoelde resolutie. Dit wordt supersampling of full-scene anti-aliasing genoemd. Op de hogere resolutie bevat de schuine lijn meer detail dan op de standaardresolutie het geval is, simpelweg omdat er meer rijen en kolommen pixels zijn. Bij het verkleinen wordt van vier pixels telkens één pixel gemaakt door de kleuren van de bronpixels te mengen. Hierdoor heeft het resultaat meer detail en kleurverloop in de rand tussen de schuine lijn en de achtergrond, wat de kartelrand wegpoetst.
Een lijn zonder (boven) en met anti-aliasing. Rechtsboven op honderd procent, onder ingezoomd zodat je duidelijk ziet wat er gebeurt.
Hetzelfde geldt overigens voor details die normaliter te klein zijn voor een pixel, zoals een grasspriet. Die zouden normaal verloren gaan, maar als de groene spriet het wel tot een van de vier subpixels schopt, kan hij toch terugkomen in het eindresultaat.
Het volledig supersamplen van het beeld zou bijvoorbeeld betekenen dat je op 4k-resolutie moet renderen om een full-hd-beeld uit te sturen naar je monitor. We hoeven je waarschijnlijk niet uit te leggen dat dat een enorm prestatieverlies zou geven. In de loop der tijd zijn er daarom tal van algoritmes ontwikkeld om anti-aliasing efficiënter te maken.
MSAA, FXAA en TAA
Tegenwoordig is multisample-anti-aliasing oftewel MSAA de meestgebruikte techniek. Hierbij wordt eerst gekeken of een pixel wel bestaat uit meer dan één driehoek. Dat is bij het grootste deel van de pixels niet het geval, waardoor er ook geen zichtbare aliasing kan optreden. Deze pixels worden zodoende op reguliere wijze gerenderd. Alleen als een pixel zich op de rand tussen verschillende driehoeken bevindt, en er dus storende aliasing kan ontstaan, worden er meer subpixels berekend om die later weer te mengen tot één pixel. Het resultaat is in principe hetzelfde als wanneer supersampling zou zijn toegepast.
Alternatieven voor MSAA zijn onder andere het snelle, maar minder nauwkeurige FXAA, dat randen van objecten probeert te herkennen en af te vlakken, en TAA, dat op basis van het huidige beeld en een aantal voorgaande frames de beeldkwaliteit probeert te verbeteren. Per beeld wordt maar één subpixel gerenderd, maar in elk frame wordt die iets verschoven. Als het beeld stilstaat, is de kwaliteit vergelijkbaar met MSAA, maar bij snelle bewegingen kan er ghosting ontstaan.
Ook voor anti-aliasing kun je vaak een ratio instellen, bijvoorbeeld 2x, 4x of 8x. In dit geval bepaalt de ratio hoe veel subpixels gebruikt worden voor het mengen. Een hogere ratio levert dus een hogere kwaliteit op, maar kost ook meer rekenkracht.
Upscaling met DLSS of FSR
Bij de RTX 2000-serie introduceerde Nvidia DLSS. Met behulp van de Tensor-cores en specifieke machinelearning wordt het beeld op een slimme manier opgeschaald. Het principe is gebaseerd op TAA, maar voor het detecteren van beweging wordt deep learning gebruikt, waardoor de achilleshiel van traditionele TAA wordt getackeld.
Het doel van DLSS is echter niet om het frame vervolgens terug te schalen naar de renderresolutie, maar om de upscaling te behouden en zo prestatiewinst te boeken ten opzichte van renderen op de native resolutie van je monitor. AMD's FSR, dat sinds 22 juni eindelijk beschikbaar is, heeft een soortgelijk doel, maar gebruikt daarvoor uitsluitend het huidige frame. Voor beide technieken geldt overigens dat een gameontwikkelaar er bewust ondersteuning voor moet inbouwen.
Api's: DirectX en Vulkan
De graphicspipeline is door de jaren heen steeds verfijnder en uitgebreider geworden. Gpu-ontwerpers werken daarvoor traditioneel nauw samen met Microsoft, dat met DirectX de belangrijkste api voor 3d-games levert. De api is als het ware de brug tussen de software (game) en de hardware (gpu), en biedt een instructieset die elke gpu met ondersteuning voor die api begrijpt. Zo kunnen gameontwikkelaars ervan op aan dat hun spel op elke pc werkt en eruitziet zoals bedoeld zonder dat ze voor elk type videokaart een aparte versie van hun game hoeven te maken.
DirectX is closed source en werkt uitsluitend op Windows en Xbox. Games voor macOS, Linux en mobiele besturingssystemen maken daarom vaak gebruik van OpenGL of Vulkan, de spirituele opvolger daarvan. Beide zijn opensource-api's ontwikkeld door de Khronos Group. Apple heeft ook een eigen api, Metal, die uitsluitend op macOS en iOS werkt.
Korte geschiedenis van de pipeline
De geschiedenis van DirectX biedt een mooi beeld van hoe deze api's de drijvende kracht zijn achter nieuwe technieken die in games worden toegepast. Zo waren de vertex- en pixelshaders tot en met DirectX 7 niet programmeerbaar. Gameontwikkelaars konden uitsluitend kiezen uit een beperkte reeks effecten die standaard aanwezig was. Bij DirectX 8 veranderde dat en kon er eigen code worden uitgevoerd, waarvan de maximale grootte en precisie bij latere versies werden opgeschroefd.
DirectX 10 en 11
Een voorbeeld van tessellation in Rise of the Tomb Raider
DirectX 10 introduceerde onder meer de geometrieshader, waardoor de gpu zelf nieuwe primitives kan genereren. Dat was een voorbode voor de toevoeging van tessellation in DirectX 11. Met tessellation kan de videokaart zelf het aantal driehoeken van een object verhogen om meer detail weer te geven, bijvoorbeeld aan de hand van de eerder behandelde displacementmap. Omdat dit pas relatief laat in de pipeline gebeurt, is tessellation veel efficiënter dan wanneer je al die details al in de oorspronkelijke geometrie zou opnemen. Dan zou dat veel complexere en dus grotere model ook al moeten worden opgeslagen en vervoerd door de PCIe- en geheugenbussen. Bovendien kan de mate waarin tessellation wordt toegepast, dynamisch worden aangepast, bijvoorbeeld aan de hand van hoe groot en dichtbij een object in beeld is. Zoveel detail toevoegen aan iets dat slechts een paar pixels groot is vanuit je huidige camerastandpunt, is immers niet erg nuttig. Voor de pipeline betekende tessellation overigens de toevoeging van de zogenaamde hullshader en domainshader, die respectievelijk driehoeken omzetten in vierkanten en andersom. De wiskunde achter tessellation werkt namelijk alleen met vierkanten.
Daarnaast maakte DirectX 11 de weg vrij om gpu's beter in te kunnen zetten voor computeworkloads oftewel gpgpu, een tak van sport die tot dan toe vrijwel volledig in handen was van merkspecifieke api's als Nvidia CUDA.
DirectX 12, Vulkan en Metal
DirectX 12, Vulkan en Metal vormden een breuk met de voorgaande api's, doordat ze het mogelijk maken om de onderliggende hardware veel directer aan te spreken. Een ontwikkelaar kan zo meer uit de gpu halen, maar moet daarvoor ook dichter programmeren op de taal die de gpu begrijpt. Het voornaamste voordeel hiervan is dat de hoeveelheid drawcalls, instructies van de cpu aan de gpu, drastisch omhoog kan. Dat komt onder meer doordat elke cpu-thread in theorie drawcalls kan genereren, waar de periodiek verstuurde centrale commandolijst voorheen op één thread moest worden verzameld.
Aan de andere kant leggen deze api's ook meer verantwoordelijkheid bij de ontwikkelaar, die vrijer is om te bepalen welke functies hij wel en niet gebruikt dan bij oudere api's. In de praktijk wordt het groots aangekondigde Explicit Multi-Adapter, wat de opvolger van SLI en CrossFire in DirectX 12 had moeten worden, bijvoorbeeld nauwelijks gebruikt in moderne games.
Zo deelt Microsoft de stappen van de moderne DirectX 12-pipeline in. Microsoft, bewerking door Tweakers
Zolang games niet fotorealistisch zijn, zal de graphicspipeline in ontwikkeling blijven om steeds dichter bij dat einddoel te komen. Vorig jaar kwam Microsoft bijvoorbeeld nog met DirectX 12 Ultimate, een soort DirectX 12.1, dat diverse nieuwe functies toevoegde. Noemenswaardig zijn onder meer variable rate shading, waarmee ontwikkelaars kunnen aangeven naar welke delen van het beeld de meeste gpu-rekenkracht moet gaan, en meshshaders, die de vertex-, geometrie- en tessellationshaders in theorie allemaal kunnen gaan vervangen. Zover is het nog niet; alleen de nieuwste videokaarten bieden hier al ondersteuning voor.
Eén ding is echter zeker: het meest besproken computeronderdeel is nog láng niet uitontwikkeld.
Het artikel kent een goede opbouw, maar een aantal zaken:
In het stukje van textures worden een aantal zaken door elkaar gehaald: bump en normalmaps worden doorgaans niet meer naast elkaar gebruikt. Daarnaast gebruiken de meeste moderne spellen geen specular (diffuse/normal/specular/glossiness) workflow meer. Tegenwoordig gebruiken spellen een combinatie van een diffuse/metalness/normal/roughness map, waarbij de roughness aan geeft hoezeer het oppervlak licht reflecteert en de combinatie van normal & metalness er voor zorgt hoe helder die reflectie is.
Het model dat gekozen is als illustratie is dan ook enigszins apart. Deze gebruikt verschillende methodes voor verschillende objecten. De wielen hebben een andere workflow dan het frame.
Wel is het zo dat verschillende kleurkanalen voor verschillende maps worden gebruikt, maar dat zijn dan bijvoorbeeld een combinatie van metal/roughness/height/ao, omdat deze enkel zwart/wit informatie gebruiken.
Daarnaast ontbreekt nog een uitleg over de methode hoe je alle driehoeken(vertices) omzet in een glad oppervlak: smooth shading.
[Reactie gewijzigd door Darf op 22 juli 2024 14:35]
Welke (combinaties van) textures worden gebruikt kan behoorlijk verschillen per game. Sommige soorten textures leveren wel een betere beeldkwaliteit op, maar zijn ook arbeidsintensief om te maken, waardoor ze in projecten met minder (tijds)budget niet worden gebruikt. Ik heb in het artikel dan ook meer geprobeerd om een idee te geven van wat voor soorten textures er allemaal zijn, dan één definitief antwoord te formuleren van welke textures in de games van dit moment worden gebruikt - dat definitieve antwoord is er namelijk niet.
Het voorbeeld van de gecombineerde maps in één texture is afkomstig van een gameontwikkelaar die bij de productie van dit artikel heeft meegekeken. Dat het wordt gebruikt is dus een feit, maar vanzelfsprekend zijn er diverse combinaties mogelijk en zal de 'beste' keuze per scenario verschillen. Naast dat de technisch beste keuze dus ook niet altijd de voorkeur krijgt in de praktijk.
Ik noem Phong-shading (een van de meest gebruikte vormen van smooth shading) wel in het artikel, maar heb de keuze gemaakt om dat concept niet volledig te beschrijven, omdat een complete uitleg daarvan al gauw erg complex wordt. Om te begrijpen hoe de graphics pipeline werkt, voldoet het om te weten dat het A: bestaat en B: dat het slechts een van de vele zaken is die bijdraagt aan de uiteindelijke kleuring van een pixel. Maar het is natuurlijk niet voor niets een hyperlink voor wie daar wel meer over wil weten.
[Reactie gewijzigd door Tomas Hochstenbach op 22 juli 2024 14:35]
Ik denk dat welk artikel je ook had geschreven er wel klachten geweest zouden zijn.
Ja we kunnen het hebben over dat men niet meer lighting doet in de geometry pass met Gouraud shading, Maar dat dat per pixel gebeurt via deferred rendering of forward+ of clustered.
En ja PBR is inmiddels practisch standaard true, maar laten we niet te kort door de bocht zijn hier.
Dit is gewoon een erg nette overview over 3d rendering en hoe het werkt dat lekker weg leest zonder in de vele super diepe rabbit-holes te gaan van pbr shading en waarom GGX beter is en metalness vs specular workflow (ja je kan ook een specular pbr workflow hebben)
Overall erg netjes en ga dit delen met collega’s die niet direct werken in rendering die er voordeel aan zouden hebben een klein beetje inzicht te hebben.
[Reactie gewijzigd door freaq op 22 juli 2024 14:35]
De oude blinn-phong workflow is juist veel arbeidsintensiever dan de huidige physically based workflow. Deze word echt niet meer breed gebruikt.
Alle tools zijn nu ook gemaakt voor PBR.
[Reactie gewijzigd door Wolfos op 22 juli 2024 14:35]
"Ik noem Phong-shading (een van de meest gebruikte vormen van smooth shading) wel in het artikel, maar heb de keuze gemaakt om dat concept niet volledig te beschrijven, omdat een complete uitleg daarvan al gauw erg complex wordt"
Maar er wordt een "Diepe duik" beloofd, en het is een Plus artikel waarvoor mensen betalen. Wat je nu hebt is slechts een (historisch) overzicht van een graphische kaart. Er wordt al jaren geklaagd dat het technische niveau van tweakers lager is dan voorheen. Zijn Plus artikelen dat niet het moment om dat weer een beetje omhoog te schroeven?
/Edit:
Mensen weten ook niet hoe te modereren. -1 bedoeld is voor "flamebait, troll, of belediging". Je kan het niet eens zijn met mijn reaktie, maar daar voorziet de moderatie optie niet in.
Maar er wordt een "Diepe duik" beloofd, en het is een Plus artikel waarvoor mensen betalen.
Ik vind het persoonlijk een goed gedetailleerd artikel, verwacht ook dat +-60% van de lezers halverwege het artikel af zou haken als er nog dieper op de materie zou worden ingegaan. (Mijzelf inbegrepen)
Natuurlijk voor de die-hard expert hierin zullen er wat items ontbreken/niet uitgebreid genoeg zijn, maar die hebben zelf meestal al de verdere kennis en dus niet zo'n artikel nodig om het uitgelegd te krijgen.
@Tomas Hochstenbach Goed artikel, heeft mij weer een beter inzicht gegeven op dit onderwerp.
[Reactie gewijzigd door kossie3 op 22 juli 2024 14:35]
Sowieso gebruik je geen bump maps in de huidige games zover ik weet, alleen normal maps.
Zoals in de Unreal engine is totaal niet gangbaar om daar mee te werken. Een normal map heeft veel meer informatie (RGB en Alpha channel)
Meestal converteer ik de bump map naar normal map in photoshop of nog makkelijker met substance designer e.d.
Combinatie van alle drie samen in 3DSmax als voorbeeld (bump,normal en displacement mapping) geeft mooie resultaten om bijvoorbeeld huid e.d. te maken.
Blijf wel alleen bij normal maps als je wilt animeren.
[Reactie gewijzigd door Davidoff1976 op 22 juli 2024 14:35]
Een normal map heeft veel meer informatie (RGB en Alpha channel)
Een tangent space normal map is RGB, waarvan de B maar half wordt gebruikt.
World space/object space normal maps zijn volledig RGB.
Ik ken geen normal maps die RGBA zijn.
Meestal converteer ik de bump map naar normal map in photoshop of nog makkelijker met substance designer e.d.
Combinatie van alle drie samen in 3DSmax als voorbeeld (bump,normal en displacement mapping) geeft mooie resultaten om bijvoorbeeld huid e.d. te maken.
Blijf wel bij normal maps als je wilt animeren.
Ik kan dit niet zo goed plaatsen.
Je maakt van grayscale afbeeldingen kleurige afbeeldingen met een geautomatiseerd proces, maar "Een normal map heeft veel meer informatie". Je zou dit prima in real-time via een shader kunnen doen met vergelijkbaar resultaat. Echter, echte normal maps passen de surface normal 3 assig aan waardoor je vervorming van de surface normal krijgt. Een bump map is 1 dimensionaal, en mist informatie op dat vlak.
Waarom je vervolgens bump, normal en displacement gelijktijdig zou willen gebruiken ontgaat me ook. Bump maps zijn gewoon een voorganger van normal maps, en displacement maps doen niets met de surface normal, maar alleen met vertices. Een normal map kan alles wat een bump map kan, én meer.
Waarom zou je overigens alleen normal maps moeten gebruiken als je gaat animeren?
Een tangent space normal map is RGB, waarvan de B maar half wordt gebruikt.
World space/object space normal maps zijn volledig RGB.
Ik ken geen normal maps die RGBA zijn.
[...]
[...]
[...]
Ik kan dit niet zo goed plaatsen.
Je maakt van grayscale afbeeldingen kleurige afbeeldingen met een geautomatiseerd proces, maar "Een normal map heeft veel meer informatie". Je zou dit prima in real-time via een shader kunnen doen met vergelijkbaar resultaat. Echter, echte normal maps passen de surface normal 3 assig aan waardoor je vervorming van de surface normal krijgt. Een bump map is 1 dimensionaal, en mist informatie op dat vlak.
Waarom je vervolgens bump, normal en displacement gelijktijdig zou willen gebruiken ontgaat me ook. Bump maps zijn gewoon een voorganger van normal maps, en displacement maps doen niets met de surface normal, maar alleen met vertices. Een normal map kan alles wat een bump map kan, én meer.
Waarom zou je overigens alleen normal maps moeten gebruiken als je gaat animeren?
Ten eerste bedoelde ik heightmap converteren naar normal map. Excuus Overigens kan het ook met een bump map.
Bump represents height differences in a surface. Bump maps generally encode finer / higher frequency detail, and should be used to enhance the look of high resolution models.
Normal maps gebruik je voornamelijk bij lage resolutie models.
Overigens kan je gewoon bump maps met height c.q. displacement mapping gebruiken? En is helemaal geen rare manier van werken. De displacement map voor grotere details en bump maps voor micro details.
Hier een zeemeermin waar ik mee bezig ben als voorbeeld.
Ten eerste bedoelde ik heightmap converteren naar normal map. Excuus Overigens kan het ook met een bump map.
Oh, wat is het verschil dan? Is dat niet hetzelfde?
Normal maps gebruik je voornamelijk bij lage resolutie models.
Dat klopt inderdaad wel aardig. Een aanvulling is wellicht dat het af hangt van je doel. Als je bv. photogrammetry scan data toe wil passen in je vray renders om die mooie IKEA catalogus plaatjes te krijgen, dan ben je blij met al die surface data die je uit je normal map krijgt, daarvoor hoeft je model nog niet per se low poly te zien. Maar goed, in de meeste real-time workflow worden normal maps inderdaad gebruikt ter compensatie van 'lage' polycount.
Oh, wat is het verschil dan? Is dat niet hetzelfde?
Helemaal gelijk in, maar het is afhankelijk van welke maps je tot je beschikking hebt natuurlijk. Ik zou in principe een high detail bump als height map kunnen gebruiken met een Vraydisplacement map/modifier (Even als uitgangspunt Vray render gebruiken https://docs.chaosgroup.com/display/VMAX/VRayDisplacementMod) wat nog meer detail geeft en geen gesimuleerde diepte en hoogte, maar dat kost wel een langere tijd renderen, en laten we het maar helemaal niet hebben over het geheugen gebruik.
Ik heb het op het model waar ik mee werk geprobeerd te gebruiken met een 8K bump map, maar ging al snel tegen de 24GB+ geheugen gebruik aan. (zeker met edge length op 2.0) en laten we het maar niet over de render tijd hebben. Niet echt slim omdat te doen dus, al is het zeker wel mogelijk.
Even de bij zeggend dat ook het haar gerenderd moest worden, en was wat overijverig om 400.000 haren te gebruiken in Ornatrix...zoveel heeft een mens nog geen eens op zijn hoofd
Dus ik gebruik eigenlijk nu alleen de displacement modifier voor het vissenhuid effect zoals ik je liet zien in het voorbeeld. De micro details heb ik bump maps voor.
Ben er nog mee bezig wat het beste is en allemaal moeilijk materie die ik nog moet leren om eerlijk te zijn. Maar goed...
[Reactie gewijzigd door Davidoff1976 op 22 juli 2024 14:35]
Je maakt van grayscale afbeeldingen kleurige afbeeldingen met een geautomatiseerd proces, maar "Een normal map heeft veel meer informatie".
Een zwart-wit plaatje hoeft niet 8 bits per kleurkanaal te zijn. Als ik een bumpmap in blender bak uit geometrie dan kan ik kiezen tussen 8, 16 of 32 bits per kleurkanaal.
[Reactie gewijzigd door koelpasta op 22 juli 2024 14:35]
Tja, maar 1x een 32-bit getal is meer informatie dan 3x een 8-bits getal.
In mijn geval zou ik dus informatieverlies leiden als ik mijn bumpmap zou omzetten naar een normal map.
Los van de hoeveelheid bits.
Als je het hebt over de hoeveelheid informatie dan kun je de bitdiepte niet los zien.
Een bump map is 1 dimensionaal, en mist informatie op dat vlak.
Dit is dus niet zomaar waar en hangt af van hoeveel bits aan informatie je hebt hebt opgeslagen. Sterker nog, je zou zelf een hoogte-formaat kunnen definieren waarbij je de hoogte verdeelt over 4x8 bits (RGBA) en dus meer infrormatie in je bumpmap hebt dan een typische normal map. Uiteindelijk maak je je eigen shader die die informatie interpreteert dus je kunt het opslaan hoe je wilt.
Tja, maar 1x een 32-bit getal is meer informatie dan 3x een 8-bits getal.
In mijn geval zou ik dus informatieverlies leiden als ik mijn bumpmap zou omzetten naar een normal map.
Als je het hebt over de hoeveelheid informatie dan kun je de bitdiepte niet los zien.
Dit is dus niet zomaar waar en hangt af van hoeveel bits aan informatie je hebt hebt opgeslagen. Sterker nog, je zou zelf een hoogte-formaat kunnen definieren waarbij je de hoogte verdeelt over 4x8 bits (RGBA) en dus meer infrormatie in je bumpmap hebt dan een typische normal map.
Klopt, je hebt dan héél nauwkeurig 1 assige diepte informatie met een custom shader. Maar je mist alleen altijd wel informatie over de 2 andere assen van al je surfaces. ;-)
Niet bepaald gangbaar, maar theoretisch zeker mogelijk.
Je kunt natuurlijk in principe zelfs meerdere 32-bits RGBA afbeeldingen gebruiken voor nóg accuratere data.
Klopt, je hebt dan héél nauwkeurig 1 assige diepte informatie met een custom shader. Maar je mist alleen altijd wel informatie over de 2 andere assen van al je surfaces. ;-)
Ja, en dan moet je dus een normal uitrekenen uit die heightmap. En andersom kun je een normalmap omzetten naar een heightmap.
En beide hebben voor en nadelen. Een heightmap kun je bijvoorbeeld gebruiken om efficient displacement te doen (kort gezegd kun je de waarde direct optellen bij de z as langs de normals van de surface) en een normalmap is juist weer handig geformateerd om het in je surface shaders op te tellen bij de surface normal.
Je kunt natuurlijk in principe zelfs meerdere 32-bits RGBA afbeeldingen gebruiken voor nóg accuratere data.
Ja klopt, maar goed, hoeveel hiervan is werkelijk zinnig in een game. Wat ik vooral wou zeggen is dat beide maps eigenlijk dezelfde informatie bevatten alleen in een andere representatie. En daarbij wou ik opmerken dat je dus ook heightmaps van een dusdanige hoge resolutie kunt hebben dat ze minstens gelijkwaardig zijn aan typische normal maps.
Het tweede fundamentele probleem van een naar pixels gerenderd beeld is aliasing. Dit effect wordt veroorzaakt doordat de pixels op je monitor vierkant zijn. Een horizontale of verticale lijn van een pixel breed weergeven is daardoor eenvoudig, maar een schuine lijn kan alleen bestaan uit blokjes die op een gegeven moment een kolom verspringen. Dit neem je waar als een kartelrand, bijvoorbeeld bij de rand van een object.
Dit is hoe het zich zichtbaar manifesteert, maar is niet waar het om draait. Je kunt namelijk ook met rechte lijnen aliasing hebben. Of met ronde pixels. Waarom? Hierom:
Het probleem is dat voor de oppervlakte van de gehele pixel de kleur bepaald wordt door maar 1 meetpunt; mamelijk het midden van die pixel.
Stel dat de oppervlakte van een pixel binnen de scene voor 80% wit is, maar precies in het midden ervan zit een zwart vlakje, dan zal zonder AA de pixel zwart worden. Terwijl met goede AA, zal er een eerder lichtgrijze kleur uitrollen. De oplossing die de auteur aandraagt is juist het probleem; er is niet genoeg gemeten om de juiste kleur van de pixel te bepalen.
Dus dit is inderdaad op te lossen met supersampling; de pixel opdelen in stukken en de kleur van elk van die subdelen bepalen; en daar dan het gemiddelde van nemen (of een andere functie dan gemiddelde naar gelang het algoritme van AA). Het gemiddelde nemen is wat er waarschijnlijk in de praktijk niet gebeurt, omdat je dan ook weer details kunt kwijtraken die je in principe wel weer zou kunnen geven. Denk aan een tralie met spijlen die zo smal zijn als een pixel. In het slechtste geval wordt dat gewoon een grijs egaal vlak.
Maar kortom: Het komt dus niet door de vorm van de pixels. Ook als je pixels rond waren, was er nog aliasing, zei het dat je minder kartelig en meer vloeiende vormen zou aantreffen. Maar feit blijft dat je door te weinig samples te nemen van je pixel je onrepresentatieve kleuren toont op je beeld.
Die tweede zin was inderdaad enigszins kort door de bocht - bij het schrijven van een achtergrondartikel als dit is het natuurlijk continu balanceren tussen het begrijpelijk houden en volledig zijn. Hoe de meest gebruikte anti-aliasingmethodes en subpixels werken leg ik verderop al wel uit, maar ik ben het met je eens dat het gegeven dat een pixel standaard geheel wordt gekleurd door het middelpunt cruciaal is om de oorsprong van het 'probleem' te snappen, dus dat heb ik nu ook al in de eerste alinea (die je citeerde) verwerkt.
Aliasing is natuurlijk ook niet alleen maar een rendering artefact dat de beeldkwaliteit van computer graphics vermindert, het is een fundementeel concept uit de signaal theorie. Als de 'sample rate' van een signaal te laag is om de benodigde 'hoge frequenties' zonder verlies van informatie weer te geven, dan gaan details verloren. Bij beeld signalen zijn de 'hoge frequenties' dingen als lijnen, contrast veranderingen etc, en de 'sample rate' is het aantal pixels dat gebruikt wordt om dit soort details te renderen.
Er zijn vuistdikke boekwerken over dit onderwerp geschreven en ik weet er zelf ook maar weinig van, dus waarschijnlijk zou het te ver gaan om te proberen dit in een toegankelijk artikel te proberen uit te leggen. Ik vind het sowieso dapper om een 'diepte-artikel' over graphics en rendering te proberen te schrijven, want het is een onderwerp dat enorm breed en enorm diep tegelijk is, dus niet iets wat je zomaar even samen kan vatten ;-)
[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 14:35]
1) SGI als in Silicon Graphics? In een uitgebreid geschiedenisboek over videokaarten vast wel, maar als ik een hoofdstukje 'een korte geschiedenis van de videokaart' van vijf alinea's schrijf is dat niet het eerste bedrijf waar ik aan zou denken. Heeft eigenlijk ook vooral techniek geleverd aan filmstudio's en niet zo zeer direct aan consumenten - alleen dat OpenGL daar z'n oorsprong heeft gevonden is wel leuk natuurlijk.
2) Ik neem inderdaad de geschiedenis van DirectX als leidraad daar, al komt die van OpenGL/Vulkan in grote lijnen overeen (steeds hogere mate van programmeerbaarheid, de weg die werd ingeslagen met DX12/Vulkan t.o.v. hun voorgangers, etc). Maar dat lijkt me niet meer dan logisch, omdat de relevantie van DirectX voor pc-gaming altijd groter is geweest.
3) Klopt dus fixed
1) SGI als in Silicon Graphics? In een uitgebreid geschiedenisboek over videokaarten vast wel, maar als ik een hoofdstukje 'een korte geschiedenis van de videokaart' van vijf alinea's schrijf is dat niet het eerste bedrijf waar ik aan zou denken. Heeft eigenlijk ook vooral techniek geleverd aan filmstudio's en niet zo zeer direct aan consumenten - alleen dat OpenGL daar z'n oorsprong heeft gevonden is wel leuk natuurlijk.
"Wel leuk" is een behoorlijk understatement. Direct3D was geheel niet relevant de eerste jaren. Het is juist OpenGL waardoor alles in een stroomversnelling kwam. 3DFX's Glide was ook gebaseerd op OpenGL. Dankzij SGI's stap om hun API open-source te maken en er een organisatie omheen te bouwen met andere hardware fabrikanten én software bedrijven was er ineens een mogelijkheid om een breed scala aan hardware aan te sturen zónder specifiek voor elk stuk hardware te schrijven.
Direct3D werd pas enigszins interessant met versie 6, maar het liep toen nog steeds dik achter. Versie 7 is waar D3D eindelijk serieus tegenstand kon bieden. Zelfs Microsoft zelf gebruikte vooral OpenGL voor hun games en andere 3D applicaties tot D3D bij 6 of 7 aan kwam. Dan heb je het echt over eind jaren '90 - en zelfs dan was OpenGL vaak sneller. Laat staan Glide, dat met z'n wrappers steevast de beste keus was.
OpenGL 1.0 kwam volledig uit de koker van SGI. Het ARB is pas bij release opgericht. 1.1 stamt dan ook pas uit '97, wat betekent dat 1.0 5 jaar lang is gebruikt. Als je het dan vooral op games wil betrekken, lijkt me dat id Tech 1 en 2 en hun respectievelijke games toch ook vrij belangrijk zijn geweest voor de verdere ontwikkeling van games en graphics
Ik ben het dus ook met @Sandor_Clegane eens. SGI dient in dit verhaal genoemd te worden, want wie weet hoe lang het zonder OpenGL nog geduurd zou hebben voordat er een betrouwbare, gedeelde 3D API was geweest.
Nou ja, als je het hebt over grafische adapters uit 1983 die alleen 2D konden pushen lijkt me het noemen SGI wel op zijn plek. Die hebben 3D voor computers, zowat, uitgevonden en zij hebben ook OpenGL ontwikkeld wat weer aan de basis van Vulkan staat; dat even later weer terug komt in jouw artikel.
Dus ja, het lijkt me heel logisch om ze te noemen.
Het leek me juist handiger om OpenGL en Vulkan als leidraad te nemen aangezien je die lijn zo van de jaren 80 in een keer door kunt trekken naar nu.
Maar ja, dat is aan de schrijver natuurlijk.
Edit: en dat NVidia allemaal ex-SGI lui zijn is ook wel een ding.
[Reactie gewijzigd door Sandor_Clegane op 22 juli 2024 14:35]
Hoe de meest gebruikte anti-aliasingmethodes en subpixels werken leg ik verderop al wel uit,
Je zegt daarbij dat MSAA de meestgebruikte vorm van AA is. Maar volgens mij is MSAA sinds het gebruik van deferred rendering (15 jaar geleden?) ernstig uit mode geraakt. Ik geloof dat het tegenwoordig geemuleerd wodt met shaders maar ik zie het niet veel terugkomen in moderne games.
De eerste drawcalls bevatten dus de vertices van objecten op de achtergrond, waarna steeds meer naar de voorgrond wordt toegewerkt.
Dat kan, maar vanwege performance is het andersom voor objecten die niet transparant zijn. Met behulp van de z-buffer kunnen dan zo veel mogelijk pixels worden overgeslagen op plaatsen waar al iets staat wat dichterbij is. De transparante delen worden vervolgens wel van achter naar voor getekend, zodat het visueel klopt. (Transparantie is een onderwerp op zich, veel lastiger dan het deel wat niet transparant is.)
Fake it till you make it
Een mooie quote hierbij vind ik:
Most of what you see in realtime computer graphics is smoke and mirrors. Including, but not limited to, the smoke and the mirrors.
[Reactie gewijzigd door jvo op 22 juli 2024 14:35]
Hoe toepasselijk dat t gaat over een artikel van hardware met zo'n mooie geschiedenis.
Het is bijzonder om te zien en om mee te hebben mogen maken hoe het landschap van de videokaarten is veranderd van een wild west aan grafische engines. S3, PowerVR, Matrox, 3Dfx, rendition, trident, nvidia, ati, intel. Wat een mooie tijden waren dat. Aan de ene kant wel jammer dat de markt zo klein geworden is.
Ondertussen zijn er veel functies toegevoegs aan de grafische kaarten, maar ook is het energieverbruik de lucht in geschoten. Was het destijds bijzonder dat een videokaart een fan nodig had omdat deze 40watt verbruikte.
Ook dit artikel is mooi opgezet, maar om hier geld voor te betalen is het veel te oppervlakkig, bevat onwaarheden. Namelijk:
Op dit artikel, de geschiedenis heb je verkeerd. 3dfx had de voodoo rush als 2d/3d kaart. Wat al voor de voodoo2 launch was. Alleen al bijv. ati had al eerder een betaalbare 3d kaart dan 3dfx. Het combineren van 2d op 3d kaarten is 3dfx niet fataal geworden.
Mede om dit soort plus artikelen door te drukken, heb ik besloten na goed 20 jaar een account te hebben gehad hier op de site, mijn account te verwijderen.
Tweakers is niet meer wat het was, zelfstandig, verfrissend en voor de echte tech fans "nerds". Het is te algemeen geworden, journalistieke kwaliteiten, geruchtberichten, hetverdienmodel bevalt me niet en zelfs het opzeggen van je account (wat vreemd genoeg via mail moet) gaat sinds de laatste jaren niet meer via tweakers (hebben ze misschien geen zeggenschap meer over?). Nee ook dit gaat via dpgmedia. Het is wachten op de wijziging naar dpgmedia.nl/tweakers.
Het waren 15 ish mooie jaren.
[Reactie gewijzigd door Anoniem: 50247 op 22 juli 2024 14:35]
Het is ondertussen 20 jaar geleden en niet iedereen heeft die tijd bewust meegemaakt. Wellicht dat Thomas in de veronderstelling was dat het combineren van 2d en 3d op een kaart 3dfx op achterstand zette, maar dat was inderdaad niet zo. De glide technologie was juist baanbrekend.
Het was inderdaad chip schaarste en problemen met de voodoo 5 serie wat 3dfx onder andere de das om deed. De verwachtingen waren hoog van die kaart. Nvidia timmerde in die tijd dan ook stevig aan de weg.
Je vermoeden dat ik toen nog niet veel meekreeg van wat er in videokaartenland gebeurde klopt . Maar dat hoeft geen probleem te zijn, Koen Crijns heeft bijvoorbeeld een naar mijn bescheiden mening heerlijkeseriegeschreven over de opkomst van de 3D-videokaart.
Achteraf zag je het vanaf de Voodoo3 eigenlijk al wel mis beginnen te gaan, inderdaad ook doordat Nvidia rake klappen uitdeelde met o.a. de Riva TNT2 en later de GeForce 256.
De voodoo 5 werd inderdaad voorbij gestreefd en de opvolger kwam er niet. Ik heb geprobeerd om een artikel van Tweakers uit de oude doos daarover te vinden, maar de meeste links naar resultaten lopen dood.
Het zou goed kunnen dat Tweakers toen helemaal nog geen reviews van gpu's deed - als je daadwerkelijk gaat zoeken blijkt 'vroeger was alles beter' toch vaak tegen te vallen . De Voodoo5-review van HWI doet het wel nog en de conclusie was (helaas) glashelder: "Over de gehele linie is de GeForce 2 zonder twijfel een veel betere videokaart."
bevat onwaarheden. Namelijk:
Op dit artikel, de geschiedenis heb je verkeerd. 3dfx had de voodoo rush als 2d/3d kaart. Wat al voor de voodoo2 launch was. Alleen al bijv. ati had al eerder een betaalbare 3d kaart dan 3dfx. Het combineren van 2d op 3d kaarten is 3dfx niet fataal geworden.
Je hebt het over "onwaarheden" (meervoud), noemt er één, die bovendien een gevolg is van selectieve interpretatie. Er staat zeker niet letterlijk dat 'het combineren van 2d op 3d kaarten is 3dfx fataal is geworden', en wat er wel wordt gezegd suggereert dat m.i. ook niet:
3dfx kwam pas in 1999 met een competitieve 2d/3d-kaart, maar zowel technische nadelen als marktomstandigheden luidden het einde van dit bedrijf in
Daar staat niet zozeer dat het feit dat ze überhaubt met een 2D/3D-kaart kwamen, maar meer specifiek een combinatie van het feit dat ze laat waren met een competitieve 2d/3d-kaart (Voodoo Rush was relatief traag, dus niet competitief), "technische nadelen" (oa geen 32bit kleur in 3D) én "marktomstandigheden", wat ze fataal is geworden.
Verder zijn er natuurlijk nog heel veel details mbt alleen al de geschiedenis van 3DFX/Voodoo, maar het artikel gaat niet over 3DFX maar over 3D pipelines in het algemeen, waarbij terzijde een stukje geschiedenis van diverse technologieën en producenten wordt genoemd.
[Reactie gewijzigd door BadRespawn op 22 juli 2024 14:35]
Kerel, je snapt toch dat websites tegenwoordig quasi equivalent staan aan winkels hè?
Ze moeten geld verdienen en hebben al het recht hierop.
Als ik zou uitrekenen wat Tweakers me bespaard heeft niet alleen aan direct geld maar ook aan tijd om zelf onderzoek te doen kom je toch op een aardig bedrag.
Het is voor mij ook nog raar om een artikel te "kopen" maar gast dit is deels om te rest re financieren.
Ik kan me nochtans volledig vinden bij aebtdom. Ik voel ook aan dat veel artikels, zeker de plus artikels, geschreven worden door personen met minder ervaring in IT dan mezelf.
De echte die-hard pc enthousiastelingen blijven maar op hun honger zitten. Alles wordt kort door de bocht uitgelegd, niet omdat het artikel dan door een breder publiek gelezen kan worden, maar vooral omdat de auteur in kwestie gewoon niet genoeg kaas heeft gegeten van de materie om zich er over uit te kunnen spreken, dit is toch hoe het bij mij over komt. Je vindt bijna evenveel uitleg bij een standaard review van een gpu @guru3d.com dan hier in dit special plus artikel.
Discmaimer: Ik heb het artikel niet gelezen. Alleen al de namen van de verschillende hoofdstukken houden me tegen.
Jij bent gewoon de doel groep niet.
Als je al diep in de branch zit dan ben je bekend met deze tech.
En is niet diep maar oppervlakkig.
Alleen tweakers is voor iedereen en dus voor iedereen die pc beginner fase meer of minder ontstegen is. En dan kan dit al aardig diepgaand overkomen.
Dit is topic dat boeken kan vullen.
Meerdere vakgebieden beslaat.
Mijn mening hoe videokaart werkelijk werkt is niet besteed aan leek een consument. Het is complexe PCB en grote complex chips dat mijn MTS electronica achtergrond ontstijgt.
En complexiteit van een API zoals Vulkan waar je toch aanzienlijk tijd moet in steken om te doorgronden. Nogal wat boilerplate setup code nodig heeft. Is iets waar je juist aktief veel tijd in moet steken. Daar helpt je zo opervlakkig artikel niet mee.
Op yt zijn er nodige vulkan tutorials om idee te krijgen.
Voor waarom heb boeken voor die ik ook heb die het in detail uitleggen.
Maar dat vergt ook heel veel tijd om dat eigen te maken.
Ben van hoger niveau of zit je in deze branch waar artikel overgaat dan zijn er specifieke forums voor deze doelgroep.
Zoals Gamasutra en Gamedeveloper.net of zo.
Voor PCB design zijn er elecronica forums.
En voor PC tech diepgang van g-kaart is er niet direct forum voor. Mogelijk te specifiek. En te kleine doelgroep.
Meer dit deden wij eens ook op Tweakers.net, al-hoe-wel meer in het forum. Echter door de keuze van Tweakers (DPGMedia) om tot voor anderhalf jaar geleden breeder publiek te willen trekken verdwijnt langzaam de techneut van de site en het forum.
Het is juist dat anderhalf jaar geleden de belofte is gedaan naar moderators (life) en community (via de site), dat Tweakers weer terug naar de kern zou gaan en weer meer diepgang in technisch artikelen zou terugbrengen en dat red je niet met dergelijke artikelen als deze.
Nu moet je en kun je nog de goede informatie uit de reactie halen, echter ik ontdek steeds meer dat techneuten, enthousiasten en professionals de frontpage en het forum steeds meer links laten liggen (in ieder geval steeds minder serieus nemen) en dat is spijtig.
Tweakers.net is weleenswaar in de breedte gegroeid, maar zeker niet (in de diepte) meegegroeid met de techniek(en), waar zij denken over te schrijven... zie ook weer dit artikele en de critische reacties.
[Reactie gewijzigd door _Dune_ op 22 juli 2024 14:35]
Ik ben al van men kinderjaren gafascineerd door computers. En toen ik in men late tienerjaren zat kon tweakers me echt bekoren met hun artikels. Toen waren ze boven men petje. Maar dat gaf me eens temeer interesse om het te willen kennen.
Nu moet het voor elke 15 jarige verstaanbaar zijn waardoor er imo maar weinig mensen iets aan hebben.
Het kan zijn dat ik de doelgroep niet ben. Maar dat maakt nog niet dat de persoon die schrijft meer ervaren mag zijn en hier en daar wat correcte achtergrond mee geeft. En niet wat ie op de eerste pagina van Google vindt.
Ik ben sowieso gegroeid. Maar tweakers is niet blijven stilstaan. Tweakers is achteruit gegaan.
Net even opgezocht. Ik bezoek tweakers nu 15 jaar. Sinds 11 jaar heb ik een account.
[Reactie gewijzigd door BlaDeKke op 22 juli 2024 14:35]
Natuurlijk, maar ik snap zijn sentiment weldegelijk. Men zou eigenlijk experts uit het veld moeten raadplegen en samen plus artikelen schrijven, de kennis bij de huidige journalisten is gewoon niet zo diepgaand als dit jaren geleden was, dat is vooral jammer.
Zeker, dat is ook de enige reden dat ik een abbonnement heb, support voor de site. Echter, ik hoop wel om daadwerkelijke diepgang al is dat dan zo nu en dan. Komt dat niet, dan zeg ik het ofwel op of ik verlaag mijn abbo naar de basis.
Een vriend van mij had een van de eerste 3d ATI kaarten (om te gamen). Ik weet het nog goed. Destijds besloot ik toen toch maar een Matrox Millenium to kopen, want die gaven een veel beter 2d beeld (de ATI had een soort licht blauwe waas in het midden van het beeld).
"Het combineren van 2d op 3d kaarten is 3dfx niet fataal geworden."
Hoewel dat dus niet specifiek de teloorgang van 3dfx betrof, was het in het begin wel degelijk een dingetje of je voor goede 2d versus gaming kaart ging.
Enige wat ik mij herinner uit die tijd is dat add-on gebeuren te duur vond.
En add-on in SLI al helemaal.
De enige 3DFX kaart die ik had was de banshee de 2d & 3d chip van hun.
Computers zijn niet meer wat het was, zelfstandig, verfrissend en voor de echte tech fans "nerds". Het is te algemeen geworden, iedereen werkt er mee, iedereen is tegenwoordig IT'er, er zit tegenwoordig overal een verdien model aan wat me niet bevalt en zelfs het maken van een website kan tegenwoordig iedereen. Het is wachten op een tijd dat een briefje schrijven in de toekomst als hi-tech gezien wordt.
Het is wellicht flauw om je quote op deze manier te verdraaien, maar het geeft wel aan wat het verschil tussen 'de markt' van 15/20 jaar geleden was en de markt nu. In de afgelopen 20 jaar is alles veel toegankelijker geworden op tech gebied voor de normale mens en spreken we niet meer van nerds als we het over computers hebben.
Dat betekent dat de markt voor Tweakers enorm is gegroeid met mensen die minder tech savvy zijn maar wel geinteresseerd. Het zou jammer zijn als deze mensen niet bediend worden. Wij als 'oude nerds' kunnen deze mensen helpen en zelfs 'opleiden'.
Tijden veranderen en hoe hard het ook klinkt: stil staan is dood gaan. Tweakers moet dus meebewegen. Nee ik ben ook geen voorstander van Plus artikelen, maar niemand houdt een mes tegen mijn keel om het te nemen. Heel veel zie ik commentaar dat een Plus artikel het betalen niet waard is: well then don't - ik doe het ook niet. Er zijn genoeg non-plus artikelen waar we ons in kunnen bewegen en stel - stel - dat Tweakers helemaal overboard gaat en in een jaar of twee 90% van de artikelen Plus artikelen zijn dan zien we dat dan wel weer.
Het is in ieder geval jammer om je te zien gaan. Ik heb je profiel een beetje doorlopen en je reacties en je bent gewoon een welkome aanvulling in de community. Laat je daarom niet gek maken door het Plus gebeuren en negeer het of omarm het. Je bent al zo veel jaren lid dat je als een kapitein ben. Welnu een kapitein verlaat zijn schip niet. Zelfs niet als het lijkt te zinken. En stel.. stel dat het onverhoopt tenonder gaat: dan hebben we juist kapiteins nodig om de boel te redden en het roer de juiste richting op te draaien.
Mooi artikel als je wil weten wat de videokaart doet in games en voor welke functies deze zich goed voor leent tov bijv processor (software kant). Maar hoe het bijv in het geheel van de pc exact werkt wordt niet uitgelegd (bijv geheugen, wattage, etc).
Misschien leuk voor een deel 2
... voor welke functies deze zich goed voor leent tov bijv processor (software kant)
Je moet weten dat tegenwoordig een GPU veel meer software cycles draait dan een CPU.
Die software heet een shader en draait voor elke pixel een set routines per frame. En dat in paralel, dus duizenden pixels tegelijk.
En beknopt. Je zou hier een heel boek over kunnen schrijven. Voor een gratis artikel is dit wel OK, maar voor een betaald artikel zou ik eigenlijk veel meer diepgang verwachten. Maar misschien is het niet voor de nerds onder ons bedoeld.
Dat is niet uit te leggen in artikeltje.
Ten 1st moet doel en waarom weten.
Dus de link de afhankelijkheid tov de andere industrie. OS API game development.
Daarnaast opleiding electronica.
PCB chip design. IC interne lowlevel logic hoe transistoren stucturen logic wordt gekoppeld. Zo heb ik ooit open collector uitgangen misbruikt van ramselectchip. Die uitgangen mag namelijk met mekaar kortsluiten. Dat wordt duidelijk als je de interne transistor interchip schema weet.
Alle soorten componenten van de BOM.
En dan uiteindelijk wat dat bakbeest van BGA chip doet van NV of AMD
Dat zijn aantal boeken
Kern wordt dan hoe hardware details belangrijk zijn voor de graphics pipeline.
En dan de graphics pipeline dus de dx en vulkan en metal API.
En dan ook de aplication module of layer die interfaced tussen game en hardware.
Eens, ik ben een leek, en na het lezen ben ik dat nog steeds. Ook voor iemand die wel een beetje thuis is in in- en uitvallend licht snapte ik helemaal niks van het raytracing verhaal. Maar wellicht is dat meer vanuit computer-oogpunt dan vanuit naatuurkundig-oogpunt geschreven.
Nope, het menselijk oog is verschrikkelijk gevoelig voor harde overgangen en de effecten die optreden wanneer een rand verplaatst op het scherm door veranderende camerapositie (net alsof de pixels lopen). Zonder AA blijft dat zichtbaar, zelfs op hogere ppi.
Ja toch wel je in de mode x tijdperk was AA zeer belangrijk.
In de SVGA ook.
Maar er is zoiets als klein 24” 4K scherm en dan is de meerwaarde laag.
Want er is. Zoiets als 24” 4K maar ook 42” 4K. Misschien dat sommige bij die 42” wel iets aan aa hebben.
Het wordt overbodig tenzij.
Elk 3d-object, zelfs deze bol, bestaat uit driehoeken (triangles) met punten (vertices) en lijnen, die samen primitives worden genoemd.
Ik vind dit heel moeilijk verwoord. Voor de anderen die dit niet snappen: een primitive is een bol, cube, cylinder, etc. Op papier is dat inderdaad een groep van vertices en points..
Ik vind dit net zoals zeggen dat een wagen uit chassis, wielen en motor bestaat die "samen een auto worden genoemd"
Ik bedoel daarmee dat vertices, triangles en lines samen ook wel primitives worden genoemd. Een primitive kan dus één van die drie zijn. Verwarrend is dat de term primitives blijkbaar ook wel eens voor complete objecten wordt gebruikt, maar dit is nog veel meer low-level.
Ik vind dit heel moeilijk verwoord. Voor de anderen die dit niet snappen: een primitive is een bol, cube, cylinder, etc.
Een primitive is een vrij bekend begrip in een building platform als bijvoorbeeld Second Life. Dat zijn inderdaad vierkanten, driehoeken, een torus, een bol, e.d. 'Primitive geometrical shapes', dus.
In een design platform als 3ds max, spreek je doorgaans van polygons. Je zult verbaasd staan dat je eigenlijk alle oppervlaktes met driehoeken kunt vullen! De hoekpunt coordinaten van een polygon noem je vertices.
https://en.m.wikipedia.org/wiki/Volume_ray_casting of "ray marching" is een vorm van ray tracing maar met een slimmere algoritme zwaar gebaseerd op simpele (lees; goedkope) goniometrische functies. Hier gaan we nu naar toe.
Dit artikel gaat inderdaad over de traditionele render technieken. Er is een hele andere wereld van non-traditionele technieken, met o.a. voxels, signed distance fields (SDFs) en betere data structuren, die veel potentie hebben en ook gewoon ontzettend vet zijn. Veel van deze technieken zijn ontstaan in de demoscene, en ze komen nu steeds meer tevoorschijn in games door snellere hardware, maar vooral ook door slimme optimalisaties.
Inigo Quilez is een van de pioniers met SDFs, en maakt ook videos waar hij uitlegt hoe dat te werk gaat. Hij zit ook achter de Shadertoy website.
Een van m'n favoriete talks in dit gebied is Learning From Failure, door Alex Evens, een ontwikkelaar van de PlayStation "game" Dreams, waar hij talloze van dit soort technieken uitprobeert om een techniek te vinden die aansluit op de gewenste art-style.
Nou slim. Het is meer kosten baten en wat wordt de standaard en waar gaat men hardware voor ontwikkelen. Rasterisation is toen de meest beste kosten baten voor 3d renderen en daarom de standaard , al dat andere mogelijk niet haalbaar of niet rendabel .
Toen is wat praktisch haalbaar en goed genoeg is goed genoeg.
Vooral de stap van 2d naar 3d is het sowieso een grote stap.
Nu wordt er 300+ watt verstook voor wat RT in de mix.
En uiteindelijk gaat het om de gameplay en dus game experience, en dat voor
Mainstream dus ook APU gebruikers.
Nostalgisch wordt ik er van. Ik weet nog dat ik begin jaren 90 in 3D Studio 4 onder Dos aan het werk was. 4 aanzichten in wireframe. Niks real time draaien met de muis, om over renderen nog maar te zwijgen. Alles instellen op gevoel, geen materiaal voorbeelden of iets en dan de 486DX2 aanslingeren met de turbo knop ingedrukt en soms wel een paar dagen wachten op een rendering. In de tussentijd kon je de computer niet gebruiken omdat werkelijk alle resources in gebruik waren. Soms ging de kast open met een ventilator er op voor extra koeling. Echt geweldig!
Ha, 3D Studio onder Dos herinner ik me ook nog... Dat was de tijd dat je zelf je routines moest schrijven voor Mode X, een niet-standaard ("geheime") grafische mode die met een speciale truc de verticale VGA-resolutie kon verdubbelen van 200 naar 400 (met 256 kleuren, als ik me goed herinner). Daarna kwam SVGA en de rest, en al je moeizaam geschreven routines mochten zo de prullebak in. Good old times...
[Reactie gewijzigd door Mr777 op 22 juli 2024 14:35]
:strip_exif()/i/2004395016.jpeg?f=imagegallery)
:strip_exif()/i/2004395042.jpeg?f=imagegallery)
/i/2004395076.png?f=imagegallery)
/i/2004455710.png?f=imagegallery)
/i/2004395120.png?f=imagegallery)
:strip_exif()/i/2004395128.jpeg?f=imagenormal)
/i/2004395132.png?f=imagegallery)
/i/2004395134.png?f=imagegallery)
:strip_exif()/i/2004395136.jpeg?f=imagegallery)
:strip_exif()/i/2004395138.jpeg?f=imagegallery)
/i/2004395142.png?f=imagegallery)
/i/2004395146.png?f=imagegallery)
/i/2004395148.png?f=imagegallery)
:strip_icc():strip_exif()/i/2004987872.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/u/287731/crop6270fa65746ea_cropped.jpg?f=community){kind=small}
/u/381607/have%2520a%2520nice%2520day%2520-%2520small.png?f=community){kind=small}
/u/3842/w55.JPG?f=community){kind=small}
/u/299583/crop653571b2c0f08.png?f=community){kind=small}
:strip_icc():strip_exif()/u/338167/Spiralboxes_60x60.jpg?f=community){kind=small}
👍
:strip_icc():strip_exif()/u/439769/crop5a510243ea2e3_cropped.jpeg?f=community){kind=small}
/u/226258/tweakersavatar.png?f=community){kind=avatar}
:strip_exif()/u/33201/yoshi_ie_ff_small.gif?f=community){kind=small}
/u/42776/crop6501d346786db_cropped.png?f=community){kind=small}
. De :strip_exif()/u/47900/baph.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/225731/crop5ed89a79424f7_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/846529/crop586d231b983b6_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/92085/crop5aa165833d640_cropped.jpeg?f=community){kind=small}
/u/151149/crop5fde11d32f663_cropped.png?f=community){kind=small}
:strip_exif()/u/18479/crop5dc6a5310ec8f_cropped.gif?f=community){kind=small}
:strip_exif()/u/489640/crop67cc85cb59455_cropped.gif?f=community){kind=small}
/u/62384/crop61891f444d6e9.png?f=community){kind=small}
/u/317612/icon.png?f=community){kind=icon}
/u/161146/crop59d7c7d153cce.png?f=community){kind=small}
/u/727812/crop5c893c9ed11f9.png?f=community){kind=small}
/u/181435/palmpje.png?f=community){kind=small}
