nieuws

Technische geek blabla, meer technische geek blabla, kortom: de beelden zijn opgepoetst naar 720p.

Ergo 20-04-10 | 13:55

Geloof dat het erop neer komt dat bepaalde dingen in verschillende resoluties worden gerenderd. Dus die vuurtoren in de verte kan best in 540p, terwijl dat ene detailtje op de voorgrond in 720p gaat. Collage-achtig dus.
Kan prima werken, als het maar in de juiste verhoudingen gebeurt. Time will tell.

Joris von Loghausen 20-04-10 | 14:03

Volgens mij is het dikke peop wat ze praten. De uiteindelijke resolutie is 540p. Dat ze er wel 720p beelden voor hebben gebruikt en die fantastisch hebben gerendered blablabla. Ze kunnen praten als brugman maar een resolutie van 540p is gewoon geen 720p. Door de rendering LIJKT het misschien 720p, maar het is het niet.

Al interesseert het mij zeer weinig. Als het resultaat er maar knap uit ziet. Dat hadden zij ook gewoon moeten zeggen "het ziet er grafisch goed uit... who cares wat de resolutie is"

Aad Teïst 20-04-10 | 14:04

@Aad: Jij begrijp optimalisatie niet echt. Waarom zou je intern een factor X moeilijker gaan rekenen dan dat je uiteindelijk output. Het is juist andersom.

Joris von Loghausen 20-04-10 | 14:07

*Mompelt iets over miereneuken*

GhostDieM 20-04-10 | 14:40

Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!
Ik ben een fanboy!

EisQonijn 20-04-10 | 15:08

@EisQonijn
Het vmbo weer vroeg klaar vandaag?
Jij hebt thuis een NASA-pc die alles in UHD 7680 × 4320 draait?

Alfred E. Neuman 20-04-10 | 15:13

@Joris von Loghausen 20-04-10 | 14:07
Andersom kan niet? je kunt niet makkelijker rekenen dan de output, toch? Maar door je opmerking begrijp ik nu wat er bedoeld wordt.

Maar is nu het werkelijke signaal richting scherm 720p of 540p? daar hoeft geen vraag over te bestaand. Het is de vraag als het wel 720p is of het gebruikte beeldmateriaal ook daadwerkelijk 720p resolutie ondersteund. Als het niet zo is lijkt dit me niks nieuws. Achtergronden, ontoegankelijke gebieden ect zijn al jaren van peop kwaliteit t.b.v. de performance.

Wat is nu precies de schande?

Aad Teïst 20-04-10 | 15:14

@EisQonijn 20-04-10 | 15:08
Ze vertelde mij in de winkel dat ik de enige in NL was met zo'n pc! :-(

Aad Teïst 20-04-10 | 15:16

Oh, ik begrijp het.
Het is dikke bullshit.

De renderer werkt inderdaad in verschillende stadia, dat is overigens helemaal niet voorbehouden aan een "modern renderer" maar dat is al decennia het geval in software renderers. Sommigen werken via "tiles" anderen simpelweg via scanline en allerlei varianten hierop die een compositie renderen van de uiteindelijke frame. Die frame komt inderdaad in "delen" tot stand om logische optimalisatie en multithreading redenen.

Echter, als de renderer klaar is en de frame komt in de FRAMEBUFFER dan is dat de resolutie. klaar. verder niks meer. Het hele verhaal in dit artikel staat dan ook in een verkeerde context. Het is bullshit.
Het verzenden van beelden kan indien nodig nog wel INTERLACED. Maar dat heeft met de besparing van bandbreedte voor de te versturen beelden te maken en niets met bovenstaande.

Het zou me niets verbazen als resoluties naar beneden gaan. De console zit op z´n tandvlees m.b.t. content van nu.
De resolutie van Modern Warfare 2 op de consoles was ook nog maar 600p ipv 720p om een framerate van 60fps te kunnen bewerkstelligen.
Hallo ! 600 pixels verticaal ! Dat is gewoon evenveel als die goede oude 800x600 4:3 resolutie die PC gamers zich wellicht nog kunnen herinneren uit een ver, ver, verleden.

Daarbij....1280x720 is al matig op al die full HD tv´s die mensen tegenwoordig hebben.
Ik speel hier op 1920x1200 (PC) en de 16:9 variant op deze resolutie (1920x1080, ofwel full HD) is amper in gebruik op de console... nagenoeg alle games zijn 720p.

Triestig.

nenny 20-04-10 | 15:22

Pixels tellen... Get a life!

dennieboy 20-04-10 | 15:33

EisQonijn
Moeilijk he, beschaafd zijn?

dennieboy 20-04-10 | 15:48

@Neuman,
Ach, Xbox eigenaar op de teentjes getrapt?

Een console kost hoeveel ongeveer? 300 als ie net uit is, en nu nog 200 euro. Iets in die geest toch? En dan verwachten dat je 5 jaar na de hardware release de boel nog up to date is en de top-lijn software op hoge resolutie kan draaien is gewoon naief.

PC gamers weten dit al langer en vervangen hun 500-800 euro gamePC (excl. monitor) eens in de 2 a 3 jaar. Die trekken 1920x1200 op goeie frame rates met de moderne games (mijn 2008 PC, nog een jaartje en dan moet deze vervangen).

Vandaar dat ik zeg dat het een pauperbox is. Het was al goedkoop en onder de maat vergeleken met PC van toen (1280x1024 rendering op mijn 2005 PC, 850 euro incl monitor). En dat is het nu helemaal. Kan je gaan lopen schuimbekken over NASA computers, maar je kan gewoon niet verwachten dat je voor een kwartje 5 jaar lang op de eerste rang kan zitten. Voor dat kwartje start je op 3e rang en eindig je na 5 jaar op een koud plein, starend naar een soort van big-screen 100 meter verderop.

EisQonijn 20-04-10 | 15:53

Ik raakte ze kwijt bij Modern renderers

Shrubbery! 20-04-10 | 15:55

er wordt iets gerenderd volgens mij

Johnny de Baas 20-04-10 | 16:28

Het komt er op neer dat voor de video's een resolutie van 520p gebruikt werd maar dat het eindproduct een hogere resolutie krijgt. Waarschijnlijk om tijd van rendering te besparen.

wacom 20-04-10 | 16:40

Framerate, belichtingskwaliteit, materiaal uitdrukking & special effects > 720p.

Juiste beslissing zou ik zeggen.

@Nenny

Er zijn wel degelijk verschillende stadia - zeker als het een deferred renderer is.
(Wat ze waarschijnlijk bedoelen met "moder renderer". Killzone 2 en Uncharted 2 renderen via deze methode)

Daarnaast heb je aparte buffers voor dingen als particles, motion blur en blooming.

De huidige consoles komen gewoon niet hoger, en that's the way it is.
Dat wil niet zeggen dat spellen daarom lelijk zijn. Helaas zijn er mensen die na het tellen van pixels opeens besluiten dat een spel dus niet voldoet aan denkbeeldige benchmarks voor een modern console spel...

PanadolPlus 20-04-10 | 16:43

EisQonijn lijkt een gefrustreerd pubertje te zijn die in 2005 heel graag een xbox360 had willen hebben maar deze nooit mocht hebben van mammie en pappie

szixxx 20-04-10 | 17:01

/me gaat gewoon lol hebben met dit spel.
Wat zijn er toch enorme zeikerds onder jullie.

Appelflap 20-04-10 | 17:04

eisqonijn heeft een spraakgebrek in lettervorm, ik heb zijn uiting even vertaald.

Joris von Loghausen 20-04-10 | 17:10

@ PanadolPlus
.
Ook ergens klokken horen luiden.
.
"Deferred rendering" slaat op shading, of preciezer: Het moment van lichtcalculatie binnen een scene. Traditioneel ging dat per polygon tijdens het renderen, bij Deferred shading gaat dit achteraf in een enkele geometrie iteratie waarbij alleen de g-buffer diepte informatie per pixel gebruikt is. Dit i.p.v. een een lichtcalc iteratie per polygon.
Deferred rendering is al oud binnen software rendering (lightscape versie 1 kon dit al), maar redelijk nieuw als HW implementatie binnen een GPU. Het is zeker niet de heilige graal daar belichting per polygon preciezer is en deferred shading heeft legio beperkingen die alsnog via belichting per polygon moeten.. (hoofdzakelijk m.b.t. transparante shaders). Het is WEL erg snel en daarom aantrekkelijk.
.
Deferred shading heeft helemaal niets te maken met de resolutie zoals deze in de framebuffer komt. Zoals ik al zei:
.
ALLE zaken m.b.t. rendering hebben betrekking op het proces VOORDAT een frame gekopieerd zal worden naar de framebuffer.
Screenshots komen OF van een optische ontvanger (camera, etc) OF (meestal) uit de framebuffer.
.
Een verhaal over dat een SCREENSHOT van een bepaalde resolutie daarom maar een DEEL is van het GEHEEL (waarbij het GEHEEL een hogere resolutie is dan het screenshot in kwestie) is per definitie onzin. Het verhaal van hoe de renderer werkt slaat daarbij nergens op.

nenny 20-04-10 | 17:10

wat Joris von Loghausen 20-04-10 | 14:03 zegt, enkel is het voorbeeld van de vuurtoren niet juist.
Een shadowmap kan op een lagere resolutie gerenderd worden dan de rest van het beeld en opgeschaald worden tot hetzelfde formaat. Door technieken zie je het verschil nauwelijks. Hetzelfde gebeurd bijvoorbeeld bij een textuur. De kleur informatie kan 512x512 zijn en de normalmap (suggestie van diepte) bijvoorbeeld 128x128 (opgeschaald naar 512), terwijl je het verschil niet of nauwelijks ziet. Wel is het zo dat op het moment dat je beeldpunten gaat tellen je de daadwerkelijke resolutie kan meten. Als het 3d gerenderde beeld 540p is, dan kan dat enkel door opschalen als meer ervaren worden.

doubledope 20-04-10 | 17:18

@nenny
Alles wat je zegt klinkt interessant!
Waarom weet je meer dan ik?

Bobsen 20-04-10 | 17:22

@ Bobsen
LOL, dat moet haast wel sarcasme zijn. In dat geval heb je wel humor.
En zo niet dan ben je gewoon aardig. Ieder z´n ding.

nenny 20-04-10 | 17:33

EisQonijn
Gast, echt. Zoek een leven maar ga niet hier zielig zitten te doen.

dennieboy 20-04-10 | 17:55

Redelijk vaag als je weet hoe lang ze aan die game hebben zitten sleutelen.. Ach, gameplay > graphics, is het niet?

Phyla 20-04-10 | 18:00

Beetje goedkoop rookgordijn dit verhaal. Deze beelden zijn natuurlijk gewoon final framebuffer outputs, en niet intermediate AO of shadowmap passes. Best kans dat ze nog aan het optimizen zijn en tbv de framerate nu nog op een lagere res outputten, maar zeg dat dan gewoon ipv een of ander kulverhaal op te hangen waar alleen een leek niet onmiddellijk doorheen prikt.

kentika 20-04-10 | 18:55

@EisQonijn
Niet op m'n teentjes getrapt maar reageer wel op je nogal domme comment...fanboy toevallig?

Wat is nu eigenlijk het punt dat je wil maken? Dat een pc beter is dan een xbox? Dat weet ik al zolang als ik beide platformen in huis heb. (vrij lang)
Beetje kinderachtig om telkens maar te gaan schreeuwen dat de jouwe beter en groter is....vind je niet?

Alfred E. Neuman 20-04-10 | 20:08

Komt erop neer dat pixels tellen dom is en dat het er wrs gwn mooi uitziet al wat een nerd gaat doen. En 1000 pixels tellen is ziek...

MikoB 20-04-10 | 20:38

Het eindbeeld bestaat uit 720p, maar dat betekent niet dat elk grafisch element ook echt in 720p is. Volgens mij gewoon een goede beslissing. Afwegingen maken doe je altijd, dan is dit de meest elegante oplossing op de 360.

spoorsel 20-04-10 | 22:13

Hier op de wereld hebben wij daar een woord voor:
up-scaling.

RadioKies{~} 20-04-10 | 22:32

@ Nenny

Ten eerste niet alle shading is deferred. En deferred rendering is relatief nieuw voor videogames.

Ten tweede "belichting per polygoon is preciezer dan per pixel?
Als je meer polygonen dan pixels hebt mischien, Lijkt me niet van toepassing op videogames. Hiervoor is dus normal mapping uitgevonden.

Transparantie is een probleem voor IEDERE game renderer omdat je transparante objecten niet naar je depth-buffer wil schrijven. Daarom worden pixels van particles en transparante objecten in een afzonderlijke pass geschreven. Deferred renderering of niet heeft hier niks mee te maken.

Maar om op het originele debat uit te komen:

"In computer graphics, deferred shading is a three dimensional shading technique in which the result of a shading algorithm is calculated by dividing it into smaller parts that are written to intermediate buffer storage to be combined later."

Waar denk je dat dat intermediate buffer word opgeslagen beste vriend?
Inderdaad - in het videogeheugen. Resultaat: tekort aan video geheugen.

Oplossing: minder pixels schrijven om geheugen te besparen.
Resultaat: MINDER RESOLUTIE.

Beetje jammer dat je zo'n grote bek opentrekt. Ik hoop dat ik het een beetje begrijpelijk voor je heb utigelegd. Het klinkt alsof je ervaring met software rendering hebt maar van hardware rendering snap je blijkbaar niet zoveel.

PanadolPlus 20-04-10 | 23:39

@Joris,

Beetje jammer. Het was toch een on-topic commentaar dacht ik. Of mag je hier geen Xbox afzeiken? Staat dat ergens in de comment-regels?

@Neuman,

Het punt dat ik wil maken is dat een console per definitie op de dag dat hij uitgegeven wordt op zijn best sub-top hardware heeft. Dat is logisch, gezien de prijs. Ik snap ook niet waarom mensen een console kopen, als ze grafische performance (pixels tellen, hallo!) belangrijk vinden. Daarnaast snap ik het economisch ook niet. Want een console is wel goedkoper dan een PC, maar naast dat het een sub-topper kwa performance is, moet je ook 5-10 jaar met die hardware doen, voordat er een nieuwe console komt met hardware upgrade. Dus je zakt van sub-top naar zwaar achterhaald. Dan heb je nog de controls die vaak zwaar zuigen voor games. De games zijn gigantisch overprijst, hoger dan een PC versie bij release, en een PC game daalt doorgaans in prijs binnen een jaar na release, terwijl 3 jaar oude console-games vaak nog maar amper goedkoper zijn geworden.

Kortom, je betaalt veel meer aan je spellen, die op mindere performance draaien dan de PC versie. Enige reden om een console te kopen zou dan zijn voor een van de schaarse unieke titels die alleen voor de cosnole uitkomen. En hoeveel Xbox360-only games van echt vette kwaliteit zijn er nou helemaal uitgekomen? Het enige waarvan ik jammer vindt dat het niet op PC is uitgekomen is Gears of War 2 en Halo3, had me leuk geleken. Maar dat is een povere basis voor de aanschaf van een console, of niet soms?

EisQonijn 21-04-10 | 08:49

Eerlijk gezegd schaar ik me achter Joris zijn verklaring. Aangezien niemand weet hoe die engine er technisch gezien uit ziet kan ik me best voorstellen dat het zo zou kunnen werken. Er zijn meerdere wegen die naar Rome leiden. Een 3d game engine is geen full-radiosity-raytracer, als dat het wel zou zijn zou je 185 consoles aan elkaar moet plakken om tot hetzelfde resultaat te komen.

Hellsmurfje 21-04-10 | 11:23

@ EisQonijn
Wat een onzin, ik wil gewoon als ik thuis kom van mijn werk op de bank neerploffen, en dan ff een potje CoD doen.. das toch 1000x chiller dan in je eentje in je kamerer achter je pc zitten! dat is echt meer iets voor pubertjes(deed ik ook toen ik zo oud was). En wat controls betreft, valt best wel mee hoor.. Iedereen heeft dezelfde handicap op een console, dus dan boeit het verder toch niet zo? Ik was vrij goed op de pc, en nu ook op de ps3:) Dus ik merk het verschil niet zo.

Je bent een btje de stereotiepe nerd aan het uithangen :)

denman 21-04-10 | 11:24

@denman
Dat vind ik nu onzin. Dan kom ik thuis en dan moet het hele gezin in de woonkamer meedelen in mijn ontspanning. Als ik wil gamen (een solo-activiteit), doe ik dat zonder de rest lastig te vallen.

De verdere kwalificaties van nerd, pubertje, vmbo'er zijn overigens voor rekening van een stel commenters hier die niet over de inhoud willen gaan, maar vooral pissed off zijn dat ik de Xbox afzeik.

EisQonijn 21-04-10 | 11:32

De Xbox360 doet toch al jaren aan upscalen? Niets nieuws onder de zon dus.

Framoes 21-04-10 | 11:50

@ PanadolPlus
.
"Ten eerste niet alle shading is deferred. En deferred rendering is relatief nieuw voor videogames."
.
(A) Dat beweer ik ook niet. en (B) Ik zeg precies dat: deferred shading is relatief nieuw voor videogames. (en niet in renderers in het algemeen)
.
Belichting per polygon is per definitie preciezer. Ik weet wat jij denkt... jij denkt een pixel is meestal (vaak ook niet trouwens) kleiner of gelijk aan een polygon element dus Nenny praat poep. Maar je denkt te kort door de bocht, het gaat om de "sampling" binnen een polygon voor een shader en die kan veel kleiner zijn dan een pixel. (behalve bij ruwe vormen van shading zoals gouraud shading, daarbij is dat bijna nooit het geval). Uiteindelijk is het kleinste *OUTPUT* element een pixel, maar maak niet de fout te denken dat per-pixel belichting daarom preciezer is dan per polygon belichting, dat is een denkfout. Belichting per pixel is vooral _sneller_, maar heeft legio nadelen t.o.v. per polygon belichting.
Lichtcalculatie per polygon kan heel precies (helemaal afhankelijk van het shading algoritme), echter voor ELKE polygon is er een render pass nodig. Deferred shading wil dit voorkomen door de licht calculatie (in delen) uit te stellen en op basis van diepte informatie uit de geometrie buffer (een pixelbuffer) achteraf belichting te berekenen. Wat je dus in feite doet is geometrie en belichting berekening uit elkaar trekken zodat je grotere brokken geometrie informatie (opgeslagen in het geheugen) kan aanbieden voor lichtcalculatie in de vorm van pixels met diepte informatie. Dat is zo en zo minder informatie dan je op basis van geometrie zou kunnen berekenen.
Dit `scheiden´ van berekenen heeft nadelen t.o.v. transparante shading en dat is logisch, want transparante oppervlakken kan je niet renderen met enkel diepte informatie per pixel, het gaat tenslotte dan ook om de geometrie (en dus de shading) achter het object in kwestie, ook heeft deferred lichting nadelen t.o.v. aliasing en raytracing, alhoewel dat laatste voor games niet zo´n probleem is, dat is eerder een software rendering probleem. (raytracing is zo goed als afwezig in games)
.
Met deferred lighting zijn per definitie minder render passes nodig dan per polygon. Omdat geometrie berekening al gedaan is moet men nog ergens diepte informatie vandaan halen. Dat is de G-buffer. Dit lijkt op een Z-buffer maar daarbij bevat elke pixel ook diepte informatie.
De input voor de uiteindelijke belichting is dus een pixelbuffer, een "aftreksel" van de daadwerkelijke geometrie. Het oplossend vermogen van die pixelbuffer is dan ook nooit hoger dan een pixel. Een shading die op geometrie werkt kan een oplossend vermogen (sampling rate) hebben die veel hoger is. Zo resulteren bij klassieke rendering vaker wel dan niet meerdere "light samples" in 1 pixel. Dat lijkt overhead, maar is het niet: de belichting zal gemiddeld preciezer zijn met name bij bewegende beelden.
.
Het "intermediate buffer storage" waar jij het over hebt, is inderdaad een plekje in het video geheugen voor de g-buffer. Die moet tijdelijk opgeslagen worden. Heeft niets met het FRAMEBUFFER te maken waar die screenshots uit komen, want DAAR had ik het over...niet over het videogeheugen. (LEZEN !)
En.. minder pixels schrijven om geheugen te besparen? Wat een onzin.
Frames die worden geschreven naar de framebuffer worden ook meteen weer verwijderd nadat ze zijn afgegeven, het is niks anders dan een doorgeefluik.
.
Tot slot de reden waarom deferred lighting in games er juist MOOIER uitziet dan voorbeelden met per polygon lighting.... simpel: De sampling rate is in games (per polygon) niet zo hoog puur vanwege performance redenen. Deferred lighting is veel sneller te berekenen dan per polygon lighting en daarom kan het oplossend vermogen steeds hoger zijn. De negatieve eigenschappen van deferred lighting neemt men dan voor lief. Probleem gevallen (transparantie) worden alsnog met per polygon lighting gedaan.
.
Echter.... in een software renderer (die kwalitatief beter zijn dan een HW renderer op een GPU) is lichtberekening vanuit een pixelbuffer met diepte informatie nagenoeg altijd MINDER in kwaliteit dan per polygon belichting. Een goed voorbeeld is de IPR renderer uit Maya, dit is een lichtrenderer die een pixelbuffer gebruikt om "interactief" te kunnen renderen bedoeld om snel een preview te krijgen van de uiteindelijke render.
.
Dus, samengevat: per polygon lighting is preciezer dan deferred lighting. PER DEFINITIE preciezer. per polygon lighting is (behoorlijk) rekenintensiever waardoor met de performance van nu binnen GPU´s de sampling rate dusdanig laag is dat in bijna alle gevallen deferred lighting met dezelfde of lagere performance een beter resultaat zal geven.
.
Ik hoop dat je het een beetje begrijpt zo.
.
vriend.

nenny 21-04-10 | 11:52

Hé waarom snap ik dit wel, en mijn leraar 3D Max niet?
Misschien moet u eens gast-les komen geven op ons ROC?

Djézus 21-04-10 | 12:24

ijskonijn en andere verkapte "ik heb een monster PC" posters:
-
Waar jullie even aan voorbij gaan is dat het normale mensen met een leven niet interesseert of het 720p of 1080i (of p) is. Zij willen na een lange dag werk, of op een leuk avondje met een vriend gewoon ff lekker een spelletje spelen op de bank, en hebben geen zin om op een bureaustoel achter de compu te gaan zitten. Ze gaan dus ook niet elke drie jaar 800 euro neertellen voor een betere, snellere bak, omdat ze hier het nut niet van inzien. Met full HD op 16:9 krijg je namelijk niet meer vriendinnetjes die hun billetjes gewillig voor je openspreiden. Maar goed, dat wist jij inmiddels al neem ik aan?
-
Nee, de echte fanboy, dat ben jij, jaloers en zuur op andere mensen die je niet begrijpen.

Kas 21-04-10 | 12:37

Djézus
.
haha, hou eens op met je "u". :D
Voel me gelijk oud.
.
3DSmax is voor mij alweer een (heel) tijdje geleden, (uit de tijd dat Kinetix -divisie van autodesk - nog verantwoordelijk was voor 3dstudiomax)
Heb voornamelijk met Maya gewerkt (vanaf versie 1) tijdens mijn studie op de filmacademie en nu nog. Dus daar kan ik je meer over vertellen. ;) (en niks ten nadele van 3dsmax)
.
Maar leuke studie doe je waarschijnlijk !

nenny 21-04-10 | 12:47

Nenny heeft gelijk.
Tegenwoordig is een frame een verzameling composites op creatieve manieren. Doe je bv een bloompass, dan is je bloombuffer vast niet 720p maar kleiner. Aangezien je laagfrequent (weinig verandering in licht per pixel) werkt maakt dat ook niet zoveel uit, tenzij je de resolutie teveel verlaagt.

Uiteindelijk scale je alles naar een eindresolutie van 720p; een bloomtexture van 256x256 zal je dan niet snel opmerken.

Er schijnen ook games te zijn die in bv 512x512 renderen, en dat dan upscalen zodat ze 720p outputten.

Ten eerste: geef mij liever zwaar geanti-aliased 512p dan aliased 1080p.
Ten tweede: goede gameplay doet alle resolutie vergeten. ;-)

Stradorvski 21-04-10 | 17:30

@nenny

Belichting per polygoon preciezer of niet, het is informatie relevant op software rendering, niet op de huidige manier van hardware rendering, waar de hoeveelheid polygons voor een daadwerkelik beter eindresultaat gewoon niet haalbaar zijn.
Ik heb overigens nooit gezegd dat het niet waar is, het is gewoonweg irrelevante informatie voor dit topic.

Het" transparantie probleem" is ook alleen een deferred rendering probleem in software.

Niet omdat wat je zegt niet waar is, maar simpel weg omdat *iedere* hardware renderer problemen heeft met transparantie, deferred en forward renderers.
De Z-Buffer / Depth-Buffer word namelijk gebruikt word voor optimalisatie.
Pixels die "achter" een andere pixel terecht zouden komen worden simpelweg niet getekend door de hardware. Daarom zullen transparante pixels altijd in een aparte pass geschreven worden zolang hardware rendering werkt zoals het nu doet, ongeacht of de rendering methode forward of deferred is.

Dit is echter *wel* relevant op dit topic.

het is namelijk 1 van de "tijdelijke" buffers waar jij het over hebt.
Er zijn geen "tijdelijke" buffers, ze zijn alleen" tijdelijk" omdat de data in de buffer constant overschreven word door de data van de volgende frame. "tijdelijke buffers" nemen dus "constant" video geheugen in.

Je G-Buffer is gewoon je video-geheugen (Graphics Buffer)
En word ingedeeld zoals de developer dat wil. Lees voor de grap de Guerrilla paper op deferred rendering even na en je ziet dat je G-Buffer al opgedeeld word in 11 buffers om deferred te kunnen renderen.

www.guerrilla-games.com...

Deferred rendering kost meer video geheugen dan forward rendering, dat is gewoon een feit. De keuze voor deferred rendering heeft dus effect op het maximaal beschikbare video-geheugen en daarom vermelde ik het in mijn post.

Dit zijn dus alleen de buffers die nodig zijn voor deferred rendering.
Het zijn niet de enige buffers die ruimte in nemen, Je hebt dus ook een buffer nodig voor de particles en andere transparante pixels en weet ik nog wat meer wat Remedy allemaal verzonnen heeft aan visuele trucs.

Het eindresultaat, de frame buffer (ook gewoon 1 van de vele buffers in de G-Buffer).
Is afhankelijk van de input van al die andere buffers - die dus opzettelijk kleiner zijn gehouden om video-geheugen te besparen, ALLES wat nodig is om de frame-buffer te creeren moet namelijk in het videoheugen passen anders gaat je frame-rate zwaar omlaag.

Het eindresultaat word ge-upscaled door de X-Box360, maar een memory capture van het frame-buffer zal de werkelijke hoeveelheid pixels laten zien - en laten de meeste developers dat nou gebruiken voor de hoogste kwaliteit screenshots die ze kunnen maken...

Ik hoop dat je het een beetje begrijpt zo. ;)

PanadolPlus 21-04-10 | 18:15

Excuses voor de woordenbrei maar ik kan blijkbaar niet terug om te editen.

Enneh Stradorvski je bedoelt PanadolPlus heeft gelijk denk ik?

PanadolPlus 21-04-10 | 18:18

Fuck wat een verkwisting van tijd.

Als de "screenshots" direct uit de screenbuffer komen en de developer is vergeten ze te upscalen in Photoshop (wat de Xbox360 doet bij output) dan kun je inderdaad de pixels "tellen"... WTF voor een omschrijving is dat - gewoon een plaatje openen in Photoshop en naar de image size kijken dus.

In ieder geval een leuk Nerd-fight gehad Gamertjes...

PanadolPlus 21-04-10 | 20:49

@ PanadolPlus
.
"Belichting per polygoon preciezer of niet, het is informatie relevant op software rendering, niet op de huidige manier van hardware rendering, waar de hoeveelheid polygons voor een daadwerkelik beter eindresultaat gewoon niet haalbaar zijn."
.
Heeft niets met HW of Software rendering te maken. De hoeveelheid polygons heeft er helemaal niets mee te maken: Er zijn niet `meer´ polygons nodig voor per polygon lighting. Het gaat om het belichtingsmodel en de precisie van de shader.
.
"Het" transparantie probleem" is ook alleen een deferred rendering probleem in software. "
.
Niet waar helaas. Het is een inherent probleem aan deferred lighting.
.
"Daarom zullen transparante pixels altijd in een aparte pass geschreven worden"
.
Absoluut onwaar. Er is geen enkele reden waarom transparancy bij procedurele rendering een 2e pass nodig zou hebben. Dit is bij deferred rendering het geval.
.
"Er zijn geen "tijdelijke" buffers, ze zijn alleen" tijdelijk" omdat de data in de buffer constant overschreven word door de data van de volgende frame. "tijdelijke buffers" nemen dus "constant" video geheugen in."
.
Geen tijdelijke buffer....een tijdelijke opslagplaats. Een doorgeefluik dus. De grootte van de framebuffer is met een bepaalde resolutie een CONSTANTE.
Uw plempsel : "Waar denk je dat dat intermediate buffer word opgeslagen beste vriend? Inderdaad - in het videogeheugen. Resultaat: tekort aan video geheugen"
.
"Je G-Buffer is gewoon je video-geheugen (Graphics Buffer)"
.
Maar het is niet `gewoon´ je video geheugen. De G-buffer iets iets speciaals, ik ken het uit de software rendering en de toepassing is hier exact dezelfde: achteraf in meerdere render passes effecten toevoegen op basis van abstractie van diepte informatie per pixel. Strikt gezien is het een render kanaal, zoals een alpha kanaal, maar dan met diepte informatie per pixel. In het geval van deferred rendering is de HELE SCENE een g-buffer render kanaal.
Die diepte informatie kan vervolgens voor een veelvoud aan dingen gebruikt worden: effecten, belichting etc. Het gaat erom dat die diepte informatie per pixel gebruikt wordt IN PLAATS VAN die informatie per polygon of UV sample te verkrijgen. (sneller)
.
"Deferred rendering kost meer video geheugen dan forward rendering, dat is gewoon een feit."
.
Klopt. (beweer ik anders dan?)
.
"De keuze voor deferred rendering heeft dus effect op het maximaal beschikbare video-geheugen."
.
klopt ook.
.
"Het eindresultaat, de frame buffer (ook gewoon 1 van de vele buffers in de G-Buffer)."
.
Haha, je weet het leuk te verzinnen.
De FRAME BUFFER is niets meer dan een stukje video geheugen (en video geheugen is absoluut niet hetzelfde als G-buffer) om gerenderde frames (die dus klaar zijn: de OUTPUT van de renderer) tijdelijk in op te slaan. Dat is het. Dat is alles wat een framebuffer is. De G-buffer is een renderkanaal. (en een `buffer´ is niks anders dan ´stukje geheugen gereserveerd voor......´)
.
De G-buffer slaat geometrie EN diepte informatie in een pixelmap op om tijdens het renderproces te gebruiken en maakt dus altijd gebruik van meerdere render passes.
.
Ik snap wat je wil zeggen, die verschillende render passes (de input van al die "buffers" zoals jij het -incorrect overigens- noemt) komen los in de framebuffer en worden daar samengesmolten tot een eindresultaat.
.
Helaas werkt het niet zo. Het spijt me zeer, het is leuk verzonnen maar in de framebuffer(s) komt alleen de output van de renderer, het is het beeld wat je op dat moment op het beeldscherm ziet. Alles wat je tracht te beschrijven zijn processen BINNEN de renderer en zijn zaken die zich afspelen ver VOOR de framebuffer.
.
"ALLES wat nodig is om de frame-buffer te creeren..."
.
Is dus de output van de renderer. in een vaste resolutie. En die gaat naar 1 of meerdere framebuffers. En daarom is de ruimte die een framebuffer in zal nemen dus een CONSTANTE. (los van de variabele resolutie natuurlijk)
.
Heb je linkje nog niet gelezen. Wel even onder de favorieten gezet. Misschien straks eens kijken.
.
Begrijpelijk zo? :P

nenny 21-04-10 | 21:44

Waarom beweren posters hier dat men met een PC automatisch geisoleerd in een hoekje moet gaan zitten? Ik speel gewoon op mijn laptop in de woonkamer, en als het even kan ook nog eens op de TV.

Of wordt hier nadrukkelijk onderscheid gemaakt tussen PC en laptop, en valt de laptop niet meer onder de ''computers'' in de ''Computer vs console'' fanboy oorlog? :')

[Alpha]-0mega- 22-04-10 | 02:13

@nenny

Belichting precieser - maakt eigenlijk niet uit voor de discussie.
Nooit beweerd dat het niet zo is. Meer uitleg *hoe* de belichting precieser is zou interesant zijn.

Transparantie als een deferred rendering probleem.
Staat netjes uitgelegd op wiki, ik beweerde ook weer niet dat het niet zo is.
Aangezien je je transparante geometry niet naar de depth buffer schrijft kun je er ook niks mee in deferred rendering. Particles en dergelijke worden dan ook los afgehandeld door een forward renderer. Het punt wat ik maakte is het volgende:

Voor videogames render je transparante objecten altijd in een aparte pass.
Je rendered eerst alle geometry die je wel in de depth buffer wil hebben.
(De niet transparante objecten). Daarna render je de transparante geometry.
Ook als de graphics engine volledig forward is.
Ook dit doet er niet echt toe in deze discussie.

Waar ik op doelde met het noemen van deferred rendering is dat het meer video geheugen kost dan forward rendering. En daar had ik gelijk in - ik heb niet "ergens klokken horen luiden" dus.

De Xbox360 heeft maar 10MB video-memory en om alles passend (en daarmee snel) te houden is het heel goed mogelijk dat de targets een lagere resolutie dan 720p hebben.

Zelfs als het niet passend te krijgen is en je gedwongen bent om data in het langzame geheugen op te slaan is het verstandig om de hoeveelheid data zo klein mogelijk te houden zodat je zoveel mogelijk in 1x naar het snelle geheugen kan overhevelen met de beschikbare bandbreedte.

Halo 3 is een voorbeeld waar de render targets niet 720p waren bijvoorbeeld.
Deze werden later gewoon ge-upscaled van 640 naar 720 door de Xbox360.

Een linkje hoe ze de pixels tellen

www.gamerawr.com...

PanadolPlus 22-04-10 | 06:18

@ PanadolPlus
.
Laat ik eerst even wat wat uitspraken van uzelf herhalen...
.
"Belichting precieser - maakt eigenlijk niet uit voor de discussie.
Nooit beweerd dat het niet zo is"
.
Ik zal even uw plempsel herhalen:
"Ten tweede "belichting per polygoon is preciezer dan per pixel? Als je meer polygonen dan pixels hebt mischien, Lijkt me niet van toepassing op videogames."
.
Hier trek je het toch in twijfel? ..oh.
(Daarbij doen het aantal polygons er niet toe en is het gewoon van toepassing op games)
.
"Voor videogames render je transparante objecten altijd in een aparte pass."
.
Vaak wel, maar niet altijd. Bij point based rendering hoeft dat bijvoorbeeld niet. Point based rendering heeft een hardware implementatie binnen moderne GPU´s.
Transparancy Blending binnen PBR gebruikt een single pass om transparantie te renderen: Het gebruikt de Z-buffer niet.
Leuk weetje: Ik ken point based rendering uit de software rendering. (Renderman)
.
"Waar ik op doelde met het noemen van deferred rendering is dat het meer video geheugen kost dan forward rendering. En daar had ik gelijk in"
.
"Deferred rendering (en met name deferred lighting) neemt meer videogeheugen in" Klopt helemaal. Maar dat was niet helemaal je punt:
.
Waar jij op inhaakte was mijn verhaal over de FRAMEBUFFER. (20-04-10 | 15:22)
Daar komt de screenshot namelijk uit en die framebuffer heeft helemaal niets te maken met die "verschillende stadia" (m.b.t. deferred rendering) in jouw antwoord op mij .(20-04-10 | 16:43). En ik quote nog maar even 2 zinnen: "een memory capture van het frame-buffer zal de werkelijke hoeveelheid pixels laten zien" en "Het eindresultaat, de frame buffer (ook gewoon 1 van de vele buffers in de G-Buffer)" waaruit blijkt dat je die framebuffer niet kan plaatsen. Grappig dat je dat dan opeens "vergeet" en het alleen over het extra videogeheugen hebt die nodig is voor deferred rendering. Dat is nooit een discussie geweest.
.
Modern Warfare 2. Een voorbeeld waarin frames 600p zijn ipv 720p.
Wat is je punt? Dat zijn beslissingen op basis van performance. MW2 wilde IW bijvoorbeeld op 60fps hebben draaien en dat trok de PS3 en Xbox360 simpelweg niet op 720p. Dat is de reden. En dat is eigenlijk altijd de reden.
.
"is het heel goed mogelijk dat de targets een lagere resolutie dan 720p"
.
Wat wil je nu impliceren? Dat men op een lagere resolutie gaat renderen dan 1280x720 en het dan oprekken (upscalen is oprekken MET filter) om *geheugen* te besparen?
Nee. Geheugen besparen doet men met: (tromgeroffel) COMPRESSIE. 9 van de 10 games renderen op 720p. Indien lager is dat om performance redenen, upscalen is simpelweg beeldprocessing tussen een bron en een doel...De ps3 kan bijvoorbeeld "upscalen" van de output van de PS3 naar de output resolutie van de TV (die bijvoorbeeld vaak 1080p is ipv 720p tegenwoordig). En "upscalen" is niets anders dan op een luxe manier de boel oprekken.
.
En dan nog iets....
.
"Het klinkt alsof je ervaring met software rendering hebt maar van hardware rendering snap je blijkbaar niet zoveel."
.
Er is niet een soort "wereld van verschil" tussen software rendering en een hardware implementatie op een GPU hoor... Waar denk jij dat het leeuwendeel van die algoritmen die een hardware implementatie hebben binnen een GPU van Nvidia en Ati (amd) over het algemeen vandaan komen? Die zijn soms echt letterlijk al decennia terug bedacht door universiteiten, hebben daarna een implementatie in SOFTWARE gekregen door bijvoorbeeld partijen als sillicon graphics of vandaag de dag: mental images (de mental ray renderer) en krijgen dan een keer een hardware implementatie.
Ik heb al vaak `nieuwe dingen´ in GPU land langs zien komen die al jaren bestonden binnen software rendering en op dat moment (als de tijd er rijp voor was in "gaming land") een hardware implementatie kregen. Wat natuurlijk een prestatie op zich is, maar waarbij het concept an sich vaak helemaal niet nieuw was.
Uiteraard zijn er ook unieke technieken in GPU land die niet uit de software rendering komen en uiteraard hebben amd en nvidia eigen ontwikkel afdelingen die daarvoor verantwoordelijk zijn.
Maar bedenk: Die lezen vooral whitepapers die al bestaan...en waarom het wiel opnieuw uitvinden?
.
Sorry vriend, ik blijf toch bij mijn standpunt: "ergens klokken horen luiden".

nenny 22-04-10 | 11:57

Wat betreft die preciesie:

Leg mij maar uit hoe het precieser is, dan kan ik voor mezelf wel uitmaken of het van toepassing is. Het lijkt mij dat je vooral loopt te pochen met kennis van software rendering die totaal niet van toepassing is op wat momenteel reeel mogelijk is.

"Klokken horen luiden"
Daarbij was mijn enige opmerking die de "klokken horen luiden" opmerking nodig maakten, het FEIT dat deferred rendering meer video geheugen kost. En daarom een reden zou kunnen zijn om de frames op een lagere resolutie te rederen, zodat het naast alle andere frames in het videogeheugen past OM PERFORMANCE REDENEN zoals ik al uitleg in mijn vorige reply.

Wat betreft het schrijven van transparante pixels in games.
JA het gaat ALTIJD op deze manier. Laat mij een GRAPHICS ENGINE zien van een Triple A Developper die op deze manier zijn particles en transparante objecten handled.
Dat het ergens in obscure white paper beschreven is en dat er ergens mischien een leuke demo draait wil niet zeggen dat het van toepassing is in de praktijk.

"Wat wil je nu impliceren? Dat men op een lagere resolutie gaat renderen dan 1280x720 en het dan oprekken (upscalen is oprekken MET filter) om *geheugen* te besparen?
Nee. Geheugen besparen doet men met: (tromgeroffel) COMPRESSIE. 9 van de 10 games renderen op 720p. Indien lager is dat om performance redenen, upscalen is simpelweg beeldprocessing tussen een bron en een doel...De ps3 kan bijvoorbeeld "upscalen" van de output van de PS3 naar de output resolutie van de TV (die bijvoorbeeld vaak 1080p is ipv 720p tegenwoordig). En "upscalen" is niets anders dan op een luxe manier de boel oprekken."

Ja dat wil ik impliceren. Je zegt zelf dat het toegepast word op Modern Warfare, hoe dik is dat bord voor je kop precies?
En heb ik ERGENS beweerd dat er een andere reden is dan performance??
Er is maar 1 reden om je kwaliteit omlaag te schroeven en dat IS performance.
De DXT compressie is overigens van toepassing op textures niet op de framebuffers.

Je wil al je data in je video geheugen als je optimale performance wil hebben, als dat niet het geval is dan zul je data uit je gewone geheugen moeten halen, wat langzamer is.
Door de hoeveelheid data minder te maken hoeft de GPU minder lang te wachten zo moelijk is het toch niet om dat te begrijpen? Er zijn zat voorbeelden van low-res bloom buffers, half res particle buffers etcetera

En last but not least:

Als jij vind dat 30 tot 60 frames per seconde versus 1 frame per 60 minuten tot dagen geen wereld van verschil is, dan is dat bord voor je kop dikker dan ik dacht.

De informatie waar jij hier mee loopt te brallen is niet van nut of van toepassing in de praktijk. NIET met de huidige hardware - NIET op een andere manier dan een mooie tech-demo.

Ik zal mijn standpunt aanpassen:
Je hebt mischien verstand van software rendering, maar hoe het in de video-game praktijk werkt, daar heb je weinig kaas van gegeten.

PanadolPlus 22-04-10 | 17:41

"Leg mij maar uit hoe het precieser is"
.
Heb ik al gedaan. Maar dan nog een keer: deferred lighting werkt met een pixelmap dieptemap die gelijk is aan de te renderen resolutie. Per-polygon lighting gebruikt sampling, het oplossend vermogen daarvan is theoretisch oneindig. (lees a.u.b. even wat over sampling en iteratie)
.
"pochen met kennis van software rendering die totaal niet van toepassing is op wat momenteel reeel mogelijk is."
.
Software rendering loopt in kwaliteit en mogelijkheden altijd voor op een hardware implementatie. Veel hardware "oplossingen" zijn namelijk workarounds op technieken die bijna allemaal hun introductie deden in een software renderer.
.
"En daarom een reden zou kunnen zijn om de frames op een lagere resolutie te rederen, zodat het naast alle andere frames in het videogeheugen past OM PERFORMANCE REDENEN"
.
Ja, en dat is dus onzin.
Gerenderde frames gaan in hun geheel naar de framebuffer (meestal 2, soms 3)
waarna ze meteen weer uit het geheugen worden verwijderd om plaats te maken voor de volgende set. Dat is absoluut geen probleem m.b.t. het videogeheugen, sterker nog...de grootte van de framebuffer is constant. Wat jij wil suggereren....dat men de uiteindelijike OUTPUT resolutie gaat VERLAGEN om videogeheugen te besparen is.....nouja bijna zondig...
.
"JA het gaat ALTIJD op deze manier. Laat mij een GRAPHICS ENGINE zien van een Triple A Developper"....."Dat het ergens in obscure white paper beschreven is... "
.
Transparancy rendering binnen een single pass is mogelijk binnen Direct3D (sinds versie 10)
Een implementatie binnen een graphics engine is dus niet nodig, de sample is binnen Direct3D te abstracten.
Hier, kan je het zien (filmpje!): developer.download.nvidia.com...
.
"This sample illustrates a method for capturing 8 layers of fragments with a single geometry pass. "
.
De wens om transparantie in een single pass te kunnen renderen komt uitdrukkelijk uit de hardware rendering hoek.

"Ja dat wil ik impliceren. Je zegt zelf dat het toegepast word op Modern Warfare, hoe dik is dat bord voor je kop precies?"
.
Nee vriend, wederom: goed LEZEN.
Ik heb het over op een lagere ouput resolutie renderen. Minder pixels renderen = meer performance overhouden.
JIJ daarentegen, hebt het over "op een lagere resolutie te renderen, zodat het in het videogeheugen past"...maar daar hebben we het al over gehad. Dat verhaal is onzin.
.
"De DXT compressie is overigens niet van toepassing op de framebuffers."
.
Nee, natuurlijk niet. Het heeft er zelfs niets mee te maken.
"Framebuffer compression" ZAT AL in video hardware (volgens mij introductie door Intel) voordat DirectX zelfs maar bestond. Het is natuurlijk geen DX feature en heeft helemaal niets te maken texture compressie of zelfs maar 3D versnelling.
.
"Je wil al je data in je video geheugen als je optimale performance wil hebben, als dat niet het geval is dan zul je data uit je gewone geheugen moeten halen, wat langzamer is. Door de hoeveelheid data minder te maken hoeft de GPU minder lang te wachten zo moelijk is het toch niet om dat te begrijpen?"
.
Correct. Dat is heel makkelijk te begrijpen inderdaad. Uw punt ontgaat me wel een beetje.
.
"Als jij vind dat 30 tot 60 frames per seconde versus 1 frame per 60 minuten tot dagen geen wereld van verschil is, dan is dat bord voor je kop dikker dan ik dacht"
.
Appels met peren vriend, wat jij hier roept is niet wat ik bedoel.
U wil hier misschien doelen op Software rendering waarbij rendertijden veel tijd in beslag kunnen nemen? Ik doel op de concepten binnen software rendering vs hardware rendering. Daarin zit geen wereld van verschil. Dat suggereer jij namelijk door te roepen dat ik misschien iets weet van software rendering maar van hardware rendering geen kaas heb gegeten.
De snelheid waarmee een beeld tot stand komt staat los van het concept.
Een shader die een implementatie heeft als programma (sample) binnen 3D hardware zal vele malen sneller gerenderd worden dan datzelfde shader programma wat in software bestaat en uiteindelijk door de processor moet worden gerenderd.
Het concept achter die shader blijft echter (vaak) dezelfde.
.
En dan nog wat. De kwaliteit die een software renderer kan verkrijgen is VELE malen hoger dan een GPU kan bewerkstelligen en vele male complexer. Om o.a. die reden ook moeilijk binnen hardware te versnellen. (dat probleem is inherent aan de vooruitgang) Rendering zal daarom plaatsvinden op een rekeneenheid die voor de meeste zaken geen hardware versnelling heeft: De processor(s).
Het DOEL van een software renderer is kwaliteit te geven. Performance is van belang maar ondergeschikt. Bij een GPU liggen die verhoudingen anders, kwaliteit is ondergeschikt aan performance. Daarom hebben we nagenoeg (nog) geen raytracing, geen global illumination, geen hogere shaders, geen NURBS of subdivs, geen ware volumetrische lichten binnen games. Wat we WEL hebben zijn LEGIO aan "workarounds", of "trucjes" om met een fractie van de performance-kosten die effecten te BENADEREN via D3D of OGL samples en/of shaders.
.
Oh en "pochen", "hoe dik is dat bord voor je kop" en "brallen".. ?
.
Goed, ik hou de eer aan mezelf en blijf wel gewoon beleefd.

nenny 22-04-10 | 22:10

Mooi dan kan ik nu ook beleefd blijven.

Je utileg klinkt logisch, zeg maar het verschil tussen vector graphics en bitmaps.
Maar deferred rendering geeft dus per pixel belichting, en je kleinste beeld element is een pixel...

Het begint er op te lijken dat je iets verkeerd geinterpreteerd hebt...
Of dat ik ergens in mijn Jip & Janneke uitleg iets verkeerd verwoord heb.

Ik zeg niet dat er naar een lagere resolutie gerenderd word om geheugen te besparen, dat is inderdaad onzinnig. Ik zeg dat er vanaf het begin af aan met minder resolutie gewerkt word, waarschjinlijk omdat deferred rendering zoveel ruimte in neemt in het video geheugen. Het eindresultaat wordt opgeschaald naar 720p.

Dat software rendering aan de grond ligt van alles wat met hardware rendering gedaan word betwist ik niet. Maar een hoop van de whitepapers zijn niet practisch als het om video-games gaat - real-time demo's mischien, maar in Modern Warfare 2 zul je het niet terugvinden.

Dus...
Als ik het goed heb is er een encyclopedie aan geirriteerde replies getikt omdat ik per ongeluk de suggestie heb gewekt dat ik denk dat alles op volledige resolutie wordt berekend om vervolgens het eindresultaat - 1 24 bits framebuffer - iets kleiner te scalen om "ruimte" te maken in het videogeheugen...

Afgezien dat ik er nog steeds van overtuigd ben dat je eerst alle "solid" geometry schrijft en daarna alle "transparant" geometry in 99% van alle praktijk gevallen zijn we het dus redelijk eens. Oh - en het gedeelte dat ik totaal niet weet wat deferred rendering inhoud, ook al zijn er natuurlijk gradaties in die kennis...

PanadolPlus 23-04-10 | 03:05

"zeg maar het verschil tussen vector graphics en bitmaps."
.
Ja, ja...je gaat het snappen. Dat is inderdaad een aardige analogie, vectoren hebben (in theorie) oneindige resolutie. Echter neemt bij sampling de hoeveelheid rekenkracht om het oplossend vermogen te verhogen exponentiëel toe. Iets wat bij vectoren niet het geval is.
.
Maar deferred rendering geeft dus per pixel belichting, en je kleinste beeld element is een pixel...
.
Klopt. Dit is wat lastiger te begrijpen.
Het oplossend vermogen is dus gelijk aan de te renderen resolutie.
Bij per polygon lighting is dat niet het geval. Daar kan het bijvoorbeeld zijn dat op 1 plekje 3 samples resulteren in 1 pixel en even verderop 4 samples resulteren in 1 pixel.
De samples hebben een relatie tot elkaar voor de lichtberekening. De lichtcalculatie kan dus veel preciezer en dat de te renderen resolutie uiteindelijk lager is dan het oplossend vermogen van de sampling maakt dat er een zekere mate van overhead is in die berekening, echter doordat samples onderling een relatie hebben is de uiteindelijke belichting preciezer. Dit is vooral aan de orde bij randen van objecten, waar anti-aliasing plaats moet vinden, daar zijn pixels vaak transparant en zijn meerdere lighting samples per pixel aan te bevelen.
Het kan echter OOK zo zijn dat het oplossend vermogen van de light samples LAGER is dan de te renderen resolutie. En dat is bij games -tot nu toe- eigenlijk steevast het geval, vanwege performance redenen. Deferred lighting is dus op dit moment in de praktijk, in games, vaak preciezer echter per polygon lighting is per definitie preciezer.
.
"Het begint er op te lijken dat je iets verkeerd geinterpreteerd hebt... "
"Ik zeg niet dat er naar een lagere resolutie gerenderd word om geheugen te besparen"
.
Zal ik het bewuste stukje er even bijpakken?
.
Maar om op het originele debat uit te komen:
"In computer graphics, deferred shading is a three dimensional shading technique in which the result of a shading algorithm is calculated by dividing it into smaller parts that are written to intermediate buffer storage to be combined later."
Waar denk je dat dat intermediate buffer word opgeslagen beste vriend?
Inderdaad - in het videogeheugen.
Resultaat: tekort aan video geheugen.
Oplossing: minder pixels schrijven om geheugen te besparen.
Resultaat: MINDER RESOLUTIE.
.
Lees vooral die laatste 3 zinnen nog even.
.
"Maar een hoop van de whitepapers zijn niet practisch als het om video-games gaat"
.
Een WHITEPAPER is een document hoe (meestal vaak voorkomende en bekende) problemen op te lossen met de oplossing in kwestie beschreven in die whitepaper.
Kijk ook even hier in het dev hoekje van de nvidia site.....elke feature heeft een whitepaper. Ze zijn voor ontwikkelaars enorm praktisch, het zijn tegelijk product omschrijvingen en (soms zeer beknopte, maar dat loopt sterk uiteen) handleidingen.
.
"Afgezien dat ik er nog steeds van overtuigd ben dat je eerst alle "solid" geometry schrijft en daarna alle "transparant" geometry in 99%"
.
Dat percentage weet ik niet, en ik denk jij ook niet.
Ook ik denk dat op dit moment transparantie in de meeste gevallen met meerdere passes zal gebeuren, echter het is wel iets wat waar mogelijk aan het verdwijnen is. Alles wat in een single pass kan heeft immers de voorkeur. Zo weet ik bijvoorbeeld dat Battlefield Bad Company 2 single pass transparantie gebruikt. (Zo blijkt overigens ook uit deze bugfix: "MP - Window on static guns is now transparent on DirectX 9 systems" deze kan je googlelen)
.
enneuh..zit jij om 3 uur in de nacht nog te posten? moet je niet werken....??

nenny 23-04-10 | 13:43

Ik werk in San Francisco, 9 uur tijdsverschil.
Vandaar dat mijn posts soms nogal groggy kunnen zijn - nog geen koffie gehad.
(7:30 hier nu)

De uitleg is duidelijk nu overigens. Er zijn al wat experimenten aan de gang met edge detection om vervolgens via een masker blurren (soort van toon-shader die als masker word gebruikt), maar volgens mij is het eindresultaat nog steeds lelijk

Ik weet wat whitepapers zijn - ook al gebruik ik ze zelf niet afgezien van het linkje doorsturen naar een van de software engineers als ik iets leuks vind.
De beschreven oplossingen werken natuurlijk wel, en die van nvidia draaien over het algemeen ook op hardware. Maar in de meeste gevallen is het een mooie tech-demo en komt de hardware die het daadwerkelijk bruikbaar maakt in een video-game jaren later. Zelfs als de tech demo 60 fps draait dan is dat nog steeds veel te traag om practisch te zijn, aangezien je zoveel meer hebt om te berekenen. Vaak wordt de oplossing dan dingen wegkappen totdat de "oude truuk" visueel beter blijkt te zijn.

Deze zul je overigens wel al gelezen hebben, in de drang naar rendertijd optimalisatie zie je steeds vaker dat real-time/hardware white-papers voor software rendering gebruikt worden.

features.cgsociety.org...

Heb je ergens een link met info over single-pass transparency?
Ik kan me namelijk geen andere manier voorstellen. Het klinkt alsof er verwarring is over wat ik bedoel namelijk...

PanadolPlus 23-04-10 | 17:13