Share
Rørledninger med fast funksjon har ikke mer virksomhet på våre skjermkort. Her er hva du trenger å vite om dem - og hvordan du gjør bryteren vekk fra dem, hvis du fortsatt ikke har gjort det ennå.
En gang i gang, når spillutvikling (eller koding av noe som har å gjøre med sanntidsgrafik, egentlig), var det begrenset til å skrive til en relativt liten matrise av fargeintensiteter (den ramme buffer) og sende den til maskinvare, kan du gjøre alt du ville ha med det. Du kan tegne på bildet ett, ti eller hundre ganger. Du kan passere over rammebufferen igjen for å gjøre noe pent. Kort sagt, hva prosessoren din var i stand til å gjøre, kan du gjøre det til bildet som blir sendt til skjermen. Dette tillot deg å gjøre noen virkelig flotte og kreative ting, men folk brukte aldri (eller sjelden) det i den grad. Men hvorfor?
Svaret: fordi det var tregt. Et 640 × 480px-bilde (en felles oppløsning på den tiden) inneholder 307.200 piksler. Og CPUene var så mye tregere da at du ikke kunne gjøre mye på kort tid gitt til deg for å tegne den rammen. Tross alt, hvis du vil fortsette å tegne på 30FPS, har du bare rundt 30ms for å oppdatere spilllogikken din og gjøre det til skjermen, og det må inkludere overhead av kommunikasjon med maskinvaren. Det var ikke mye.
Så kom de kule GPUene med rendering rørledninger. Du, utvikleren, ville ta vare på å oppdatere spilllogikken og sende teksturer og triangler til GPU, og det ville gjøre tunge løft og nummer knase på dem. De var Rørledninger med fast funksjon (FFP): betyr at du ikke kunne konfigurere funksjoner de utførte. Du kan fortelle dem "gjør tåken mørk grå" eller "ikke gjør belysningen for meg!" og du kan konfigurere mye av det andre parametere, men funksjoner selv ble igjen.
Maskinvaren var kablet og smalt spesialisert slik at den utførte noen standardoperasjoner på dataene dine. Og fordi det var koblet på den måten, var det så mye raskere enn å gjøre dem på prosessoren din. Men en ulempe var at du betalte mye for den hastigheten: du betalte i fleksibilitet. Men hvis du noen gang ønsket å tegne noe komplisert, var CPUen ganske enkelt ikke rask nok, og det var det eneste valget du sendte inn til din GPU..
Dette er omtrent hvordan fastrørsledningen fungerte. Bildet er ikke ment som en nøyaktig representasjon, men for å gi deg en anelse om hvordan alt utført.Grafikkverdenen endret seg fortsatt raskt. Som alle kreative og talentfulle mennesker, elsker spillutviklere utfordringer, og en av de Utfordringene for dem var (og vil forbli!), for lenge siden, for å gjengi stadig bedre og realistiske bilder.
Rørledningen med fast funksjon ga noen fine funksjoner, som for eksempel flere blandemoduser, Gearaud-skygging, tåkeffekter, stencilbuffere (for skyggevolumer) og slik at utviklerne brukte det de kunne. Snart var det noen virkelig imponerende effekter på gang, alt i kraft av virkelige fenomener simulert ved hjelp av noen billige triks (vel, billig etter dagens standarder).
Dette gikk alt bra, men det var fortsatt begrenset av hvor mange funksjoner den faste rørledningen kunne gjøre. Tross alt har den virkelige verden så mange forskjellige materialer, og for å simulere dem var den eneste variasjonen de fikk lov til å endre noen blandemoduser, legge til flere teksturer eller justere lysrefleksjonsfarger.
Så skjedde det: de første programmerbare GPUene kom sammen. De kom ikke over natten, selvfølgelig, og de var bundet til å komme fram en dag, men dette skapte fortsatt spenning. Disse GPUene hadde det som ble kalt a programmerbar rendering rørledning: Du kan nå skrive programmer, kalt shaders, i et begrenset samlingssprog, og få dem til å utføre for hvert toppunkt eller fragment, på skjermkortet. Dette var et stort sprang fremover, og det ble bare bedre.
Snart økte samlingssprogene i kompleksitet og uttrykksfullhet, og språk på høyt nivå for GPU-programmering dukket opp, for eksempel HLSL, GLSL og senere Cg. I dag har vi geometriske shaders som kan til og med streame ut nye krysser eller shaders som dynamisk styrer tessellasjon og tessellated trekanter, og i dem kan vi prøve en forferdelig masse teksturer, dynamisk grenen og gjøre alle slags gal matematikk på inngangsverdiene.
Når du gir utviklere disse fordelene, går de vilt; snart skrev de shaders for alle slags ting: parallax kartlegging, egendefinerte lysmodeller, brytning, du nevner det. Senere kom selv helt tilpassede belysningssystemer fram, for eksempel utsatt skyggelegging og lys pre-pass, og du kunne se komplekse etterbehandlingseffekter som for eksempel skjermrommet omgivende okklusjon og horisontbasert ambient okklusjon. Noen var til og med "misbruke" shaders å gjøre repeterende, matte-tunge oppgaver, som statistisk behandling eller ødeleggelse av strømparasjer. (Dette var før generell bruk av databehandling på GPUer har vanlig støtte.)
Kort sagt, datagrafikk eksploderte med innføring av shaders, og med god grunn: evnen til å programmere hva som skjedde med vertices, fragmenter, teksturer og så videre og å gjøre det rask, ga nesten uendelige muligheter.
En forenklet representasjon av den programmerbare rørledningen. Legg merke til hvordan de spesifikke transformasjons-, skygge- eller teksturstadiene ble erstattet av spesialiserte shaders. (Tessellasjon utelatt for klarhet.)Snart var faste rørledninger utelatt, i hvert fall for spillutviklere. Tross alt, hvorfor bry deg med slike walled hager når du kan programmere nøyaktig hva som skjer med dataene dine? De ble brukt mye lenger i enkelte applikasjoner der realisme ikke var et problem, for eksempel for CAD. Men stort sett ble de ignorert.
OpenGL ES 2.0, utgitt i 2007, avviklet eller fjernet sin fastfunksjonsrørledning til fordel for en programmerbar en. OpenGL 3.2, tilbake i 2009, fjernet endelig all begrepet fast-funksjon vertex og fragmentbehandling (det er imidlertid fortsatt tilgjengelig for eldre bruk via en kompatibilitetsprofil). Det er klart at det i dag er svært lite fornuftig å jobbe med den begrensede rørledningen når du har kraftige GPUer som er i stand til å gjøre fantastiske ting til din disposisjon.
Fordi disse APIene tvinger deg til å bruke shaders (og dette inkluderer DirectX, som, mens ikke eksplisitt fjerning av funksjonaliteten, inneholder verktøy for å hjelpe migrere fra den gamle tilnærmingen, og har nesten ingen ny dokumentasjon angående FFP), er de vanskelig å få riktig for en nybegynner. Hvis du bare starter som en 3D-programmeringsvinne, er det mye enklere å bare fortelle APIen dine matriser, lysparametere og hva som ikke, og få det til å gjøre alt for deg.
Men i det lange løp vil det gi deg mye mer hvis du lærer å skrive programmer som nettopp beskriver prosessen. Du forstår hva som foregår under hetten, forstår noen svært viktige begreper som FFP ikke krever deg, og du kan tilpasse materialene dine veldig enkelt for å gjøre noe komplisert, fastfunksjonen kan aldri gjøre for deg (og det er nyttig for debugging, også!).
Jeg har nevnt OpenGL ES, og la meg bygge opp på det mer detaljert. Siden spill på mobil blir mer og mer populært, er det fornuftig å skape virtuelle verdener stadig økende i kompleksitet. De fleste av fastfunksjonssamtalene ble fjernet i ES 2.0 (som, selvfølgelig, betyr at de er fraværende fra senere versjoner også). Dette innebærer i hovedsak at for å kunne bruke noen av funksjonene etter ES 1.1, må du bruke shaders.
ES 2.0 støttes av iPhones siden 3GS, iPads siden den første versjonen, og iPod Touch-enheter av generasjon 3 og høyere. Qualcomm Snapdragon, en chip som brukes mye i Android-telefonproduksjon, støtter også OpenGL ES 2.0. Det er veldig vid støtte, fordi ES 2.0 ikke er akkurat "nytt": det er over 7 år nå. Å få mest mulig ut av disse arkitekturene, du må slippe av rørledningen med fast funksjon.
Jeg antar at de fleste av dere har gjort det lenge siden, men det er ikke så vanskelig for meg å forestille seg noen 2D-grafikkmotorer eller eldre spill som fortsatt bruker faste funksjoner (fordi det ikke er behov for mer). Dette er bra, men å bruke det til nye prosjekter, eller treningsprogrammerere i dem, virker som en sløsing med tid. Dette forsterkes av det faktum at mange opplæringsprogrammer du finner på Internett, er grovt utdaterte og vil lære deg hvordan du bruker FFP fra begynnelsen - og før du selv innser hva som skjer, vil du være dypt inne.
Min første børste med 3D-grafikk var en gammel DirectX 7-opplæring skrevet i Visual Basic. På den tiden var det vanlig å bruke rørledningen med fast funksjon, fordi maskinvaren ikke var avansert nok til å oppnå samme funksjonalitet med shaders i samme hastighet. Men i dag ser vi grafikk-APIer som begynner å falle eller sterkt deprecere støtte for det, og det blir egentlig bare en gjenstand fra fortiden. Det er en god og nyttig artefakt som gjør oss nostalgiske, men vi skal holde seg borte fra det. Det er gammelt og ikke lenger brukt.
Disse søte fresnelrefleksjonene og refraksjonene, generert av en demo fra OGRE (Open Source Graphics Rendering Engine), kunne aldri vært gjort hvis du stakk på måtene som gamle DirectX 8 eller OpenGL 1.1 opplæringsprogrammer anbefaler.Hvis du er i seriøs spillutvikling, holder du fast på fastrørledningen en relikvie av fortløpende dager. Hvis du tenker på å komme inn i 3D-grafikk, er mitt råd (og råd fra mange, mange utviklere der ute) å bare unngå det.
Hvis du ser overføring av lysposisjoner til grafikk-API-en (ikke som en shader-parameter), eller API-funksjonssamtaler som glFogv, løp som vinden og ikke se tilbake. Det er en modig ny verden med programmerbare GPUer der ute, og det har eksistert lenge. Alt annet sannsynligvis bare kaster bort tiden din.
Selv om du bare er inn i 2D-grafikk, er det fortsatt en klok idé å ikke stole på FFP lenger. (Selvfølgelig er det så lenge du har det bra med ikke å støtte noen gammel maskinvare.) Shaders kan gi deg flotte, lynraske effekter. Bildeskarphet, skarphet, kjernefelt, vektorgengivelse og storskala partikkel- eller fysikkimulering kan alle gjøres på GPU, og de kan alle ha nytte av både 2D og 3D-spill.
Så, igjen, mitt råd, selv om du ikke eksplisitt skal lære om 3D-spillutvikling, er å lære å skrive shaders. De er morsomme å jobbe med, og jeg garanterer at du skal tilbringe mange morsomme timer som gir en fin skyggeeffekt: en dynamisk skytehytte, bilmaling eller parallell splitt skyggekartlegging, eller hva hjertet ditt ønsker. I det minste har det skjedd meg: Når du er vant til å jobbe med den faste rørledningen på grunn av en begrensning (som jeg var tvunget til, tilbake på dagen, for å få akseptabel ytelse på min 5200FX), er programmeringen av GPUen en blast og massevis av moro.
Jeg håper jeg har forklart dem for hvem det var uklart, hvordan 3D-grafikk pleide å fungere lenge siden, og hvordan det fungerer nå, og jeg håper jeg har overbevist de få av dere som var på randen av å følge NeHe eller Swiftless-opplæringer å gjøre ellers og gå og se på noe mer moderne. Som alltid kan jeg ha gjort noen feil, så vær så snill å peke på dem i kommentarene. Til neste gang!
Accentsconagua