Shader Model 3.0 besproken door HardOCP

Bij HardOCP is een artikel verschenen waarin wordt ingegaan op de mogelijkheden van versie 3.0 van het shader model. De GeForce 6800 Ultra van nVidia zal voorlopig de enige videokaart zijn die deze programmaatjes kan uitvoeren wat natuurlijk een goede reden is voor de PR-afdeling om hier de schijnwerper op te richten. Zo werd de media bijvoorbeeld enkele dagen geleden getrakteerd op Farcry-screenshots die zouden moeten demonstreren hoeveel de beeldkwaliteit er op vooruit gaat. Helaas werden hier shader model 1.0 screenshots tegenovergezet waardoor het verschil tussen model 2.0 en 3.0 onduidelijk bleef.

Na zelf een lading screenshots gemaakt te hebben met 2.0 pixel en vertex shaders ingeschakeld en de technische specificaties van shader model 3.0 door te hebben geplozen blijkt dat de verschillen in beeldkwaliteit tussen beide versies beperkt is. Met uitzondering van displacement mapping kunnen alle model 3.0 effecten ook tevoorschijn getoverd worden met behulp van model 2.0 shaders. In het shader model 3.0 zitten echter wel een flink aantal features die een positieve invloed kunnen hebben op de prestaties. Versie 3.0 shaders zijn zonder twijfel een vooruitgang ten opzichte van versie 2.0, maar het verschil is minder groot dan nVidia wil laten geloven.

Boedha-beeld met displacement mapping om textures met textuur te renderen

Reacties (33)

Jammer dat het toch weer met die ingewikkelde modellen moet. Een videokaart zou gewoon (deels) radiosity moeten renderen. Dus een scene waarvan de belichting gewoon volgens de natuurwetten verloopt en niet volgens proprietaire algortimen.

Volgens mij hebben de nieuwelingen als de FX6800 en de X800 best genoeg rekenkracht om dat (op een lage resolutie) te doen.

Radiosity rendering is net zo proprietair als al het andere. En het zou zeker helpen. Maar het vreemde is dat radiosity rendering eigenlijk al grotendeels pre-calculated kan (Max Payne) maar zelfs dat zie je zelden. Resultaat: leuke effectjes (water, muren met stenen, natte wegen) maar nog steeds een onrealistische belichting.

als je karakter bijvoorbeeld een groene broek zou dragen en vlakbij een muur komt te staan, dan zou je dus een groene waas op de muur krijgen, of er nou zonlicht (ook nog steeds moeilijk) of kaarslicht is. Dat lijkt me best te doen voor een kaart die vergelijkbaar is met een 20-30GHz P4.

pixel en vertexshader hebben echter niets met ingewikkelde models te maken. Als ik wil kan ik zelfs een normale 'sphere' zo'n displacement map geven dat 't op een aardbol lijkt..

Die ingewikkelde modellen worden gebruikt, omdat videokaarten bij lange na niet snel genoeg zijn om het 'correct' uit te rekenen.

Bijna helemaal niets wordt netjes berekend.
Vrijwel alles wordt vooraf uitgerekend. Er worden light maps gebruikt, om vooraf schaduwen uit te rekenen, zodat de videokaart ze alleen maar hoeft te laten zien, maar niet te berekenen. Niet voor niets dat schaduwen van dynamisch objecten pas NU een klein beetje in beeld komen. Het vergt veel en veel te van de videokaarten.

Je zou dat standbeeld in het voorbeeld 'correct' kunnen maken door gewoon meer polygonen te gebruiken. Dat zou dan bijvoorbeeld een miljoen polygonen vergen. Dat is niet acceptabel uit snelheids overwegingen.

Zit ook een technische kwestie achter. De geheugen bandbreedte is al jaren beperkend bij videokaarten. Daardoor dat meer polygonen of grotere textures een ernstig prestatie probleem opleveren. Maar rekenkracht (shaders!) is wel relatief simpel te vergroten. En dus mag je best een heel ingewikkelde rekenpartij doen, om op runtime diepte te creeeren, als je daarmee polygonen uitspaart.

Nette raytracing (want dat is eigenlijk wat je voorstelt) is volslagen onmogelijk met de huidige kaarten. En dan hebben we het nog niet eens over radiosity, hetgeen het zaakje nog eens tien keer zo ingewikkeld maakt.
Kom over 10 jaar nog eens kijken, misschien dat we dan zo ver zijn.

10 jaar wachten is wel een beetje erg lang. Real-time raytracing is al volop in ontwikkeling. Ok je hebt er vaak een aantal PC's tegelijk voor nodig of de scene is vrij eenvoudig, maar het kan al wel.

Zeker het werk wat in het OpenRT project gedaan wordt is indrukwekkend. Een scene met 37,5 miljoen polygonen die interactief met global illumination gerenderd wordt! Zie deze filmpjes:
http://www.openrt.de/Gallery/

Home: http://www.openrt.de/
Oude home: http://graphics.cs.uni-sb.de/RTRT/

Leuk wat ze daar gedaan hebben. Ik heb deze er even uitgepakt: http://graphics.cs.uni-sb.de/~wald/Publications/2002_IGI/

Maar ze gebruiken daar dus wel minimaal 16 Athlon MP 1600+ cpu's voor scenes die heel simpel zijn.
En compleet real-time is het dan nog niet eens. Na een 2 a 3 seconden krijg je het uiteindelijke plaatje.
Bovendien zie je dus ook aan die plaatjes dat er geen radiosity in zit. En waar normaal raytracing al veel performance vergt, is dat bij toevoeging van radiosity nog een paar factoren erger.

De inschatting van 10 jaar voor we dit in spellen op high end gamers machines zien lijkt me dus alleszins realistisch.

Die nieuwe kaarten hebben niet genoeg rekenkracht voor radiosity.

Voor Radiosity moet je raytracing doen. En dat is gewoon killing voor je prestaties.
Het is zo killing dat zelfs de meeste 3D renderers dat niet ondersteunen of standaard niet aan hebben staan. En die mogen minuten over 1 plaatje doen ipv 1/60 seconden.

Displacement mapping is gewoon een simpele methode om een veel gedetailleerder model te krijgen door meer polygonen te creeren met die map.
Dat is veeeeeel makkelijker dan deels radiosity doen, geeft veel mooiere resultaten dan al dat geklier met bumpmaps, en dat is iets waar die nieuwe videokaarten krachtig genoeg voor zijn.

Onderschrift pic:

Boedha-beeld met displacement mapping om textures met textuur te renderen

Kan iemand dat uitleggen.

edit: @reacties: tnx. ik dacht dat 'textures' en 'textuur' dezelfde woorden waren (maar dan in 'engels' en 'nederlands'). Niet dus. OK

Een texture om structuur te simuleren is 2D en reageert niet op licht veranderingen.

Bumpmapping Dot3/environmentmapped reageren wel op licht en/of omgevingsveranderingen. Maar als je een bol mapped is de rand nog steeds rond. De bumworden gesimuleerd.

Displavcement mapping veranderd het model, waardoor het " echt" een stuctuur krijgt. De omtrek van de eerder genoemde bol zal niet meer exact rond zijn.

Met displacament mapping gebruik je een texture als een soort dieptekaart welke je langs de omtrek van een object trekt om zo textuur te maken.

Ik moest er ook even over nadenken
(Boeddha, trouwens...)

"met textuur" betekent dus zo veel als met reliëf.

haal mijn post maar weg

Ik heb hier ook een boek liggen van microsoft betreffende de pixel en vertex shaders van directX 9. Ook in dat boek word verteld dat de verschillen tussen beide niet zo groot zijn, maar wel dat je meer features heb met de assembler code die je door de parser heen stuurt..

Het is de moeite waard om het te lezen, als je 'm kan vinden.

ISBN: 0-7356-1653-1

@ nl.bol.com:

DirectX 9 Graphics Programmers Guide

Hij heet alleen anders:

DirectX 9 Programmable Graphics Pipeline (wel dat linkje ja)

Is er eigenlijk een verschil tussen die displacement mapping in shader 3.0 en 'gewone' displacement mapping? Ik dacht dat DM gewoon in de feature lijst zit van DirectX9.0? De Matrox Parhelia ondersteunt al van in den beginne DM; of is dat een ander soort DM?

Dat is allemaal nogal vaag. Nvidia doet net alsof hun kaart de eerste is die DM ondersteund en dat het pas in SM3 zit.

Maar de Parhelia doet al DM, en de Radeon 9700 family doen ook al DM. Hoewel die twee technieken wel verschillend zijn. Je kan hier meer informatie over beide technieken vinden:
http://www.ati.com/developer/gdc/GDC2003-DisplacementMappingNotes.pdf

Verder heeft Valve in de HL2 demo's al displacement mapping in actie laten zien op een Radeon 9700.

Displacement mapping wordt belangrijk. Intressant.....
Nee, nu on-topic. Enkele jaren geleden voerde Matrox dit als 1 van de sterke punten van de Parhelia aan. En zoals nu blijkt draagt displacement mapping werkelijk bij tot het bevorderen van de 3D beeldkwaliteit.
Natuurlijk kan de Parhelia wat betreft prestaties niet mee met deze chip of het tegenhangende ATI geweld. Maar ik vind persoonlijk dat het wel iets zegt over het revolutionair en toekomst gericht denken van de mensen achter Matrox.

Vergeet environment mapped bump mapping van de G400 niet, hoewel ze die techniek ingekocht hebben. En de Parhelia heeft 30-bit kleur (Nee dat kan NVidia en ATi niet).

Probleem met Matrox is dat ze niet opkunnen tegen de marketing prietpraat van de grote jongens en de leuke 3DMark getalletjes. Zo zijn wel meer goede producten weggedrukt. (Gravis Ultrasound, Aureal)

Die bumpmapping van Matrox, DAT is pas marketing praat.

Matrox heeft simpelweg niet de snelheid die nodig is om dat soort grapjes uit te voeren in spellen die op meer dan 3fps moeten draaien. M.a.w. die feature is volstrekt nutteloos. checkbox feature. Pure PR, maar niets meer.

Dezelfde bumpmapping zit trouwens ook al tijden in de ATI's. Wordt om dezelfde reden niet gebruikt.

Alsof die 30bit kleur van Matrox geen marketing prietpraat is. (zeker voor games)

En dat EMBM van de G400 was ook te traag om veel te gebruiken in games.

...dat is bijna surrealistisch...incredible gewoon...maar wordt het nu ook lastiger om zulke objecten te renderen?

Het blijft gewoon een low-poly object, met een hoogte map. Het "nieuwe" is dat er een intelligente bumpmap wordt gebruikt, i.p.v. een simpele.

Niet zo bijzonder als je denkt. Kost natuurlijk wel rete veel GPU kracht, waardoor het tot nu toe niet werd gebruikt. Het kan echter al jaren.

Als ik het goed heb word dit displacement mapping gedaan in de vertex shader (3), met andere woorden het kan met snelheidsverlies gedaan worden op een ps2 of 1 kaart.

Pixelshader elementen zijn niet zo makkelijk te doen door de cpu.

Eerst maar eens afwachten welke spellen het gaan gebruiken en hoe.

Voorlopig is HL2 de enige waarvan ik weet dat ze het gebruiken. (zelfs heel veel gebruiken)
Maar hun versie werkt al uitstekend op de R300 serie.

Even een heel groot misverstand uit de weg ruimen:

Praten over ondersteuning van feature xx door shaders is onzin.

Shaders zijn stukjes software die door de GPU wordt uitgevoerd. In principe kun je in pixel shaders dus doen wat je wilt, en is er geen feature die wel of niet mogelijk is.

Uiteraard zijn er wel verschillen. Vanaf PS2 is alles floating point, en dat levert grote verschillen in beeld kwaliteit t.o.v. PS1.x
PS3 levert op dit punt niets extra's op. Er worden vooral extra programmeer technische delen toegevoegd, die vooral gebruikgemak opleveren. Misschien ook nog snelheids winst, maar dat moet nog aangetoond worden... Qua grafische mogelijkheden verandert er vrijwel niets.

Displacement mapping is al tijden geleden met DX9 en de ATI 9700 gedemonstreerd. Probleem is echter dat het een enorme rekenkracht vergt, omdat je de geometry van het object aanpast. Bumpmapping is daarom meestal een veel beter alternatief omdat dat alleen de pixels aanpast.

Met Vertex shader 3 wordt displacement mapping wel een stuk makkelijker voor de programmeur, en is er wellicht genoeg rekenkracht om het nuttig te maken. NB: VS3 zit vrijwel zeker ook in de R420!

Maar voorlopig nog maar afwachten. De nieuwe unreal engine die over 2 jaar moet uitkomen, gebruikt geen displacement maps, maar virtual displacement maps. Dat zijn eigenlijk gewoon super geavanceerde bumpmaps. Niks nieuws dus... alleen gebruikt maken van de hogere snelheid van de nieuwe grafische kaarten, waardoor je meer rekenkracht in je bumpmap berekeningen kunt zetten.

En het is vrijwel zeker dat het farcry plaatje dat hier getoond wordt, ook van virtual displacement mapping gebruik maakt, en niet echt de geometry aanpast.
M.a.w. we zien hier geen nieuwe mogelijkheden van shader model 3, maar gewoon beter gebruik maken van shader model 2. Hooguit dat het te zwaar is voor de huidige videokaarten die SM2 ondersteunen.

Volgens mij wordt er in de game "painkiller" al wel gebruik gemaakt van al dit grafisch geweld.
Hij maakt dan ook gebruik van dezelfde engine als HL2.

edit:
Ow, sorry, het was dus de physics-engine die hetzelfde is.

Volgens mij wordt er in de game "painkiller" al wel gebruik gemaakt van al dit grafisch geweld.
Hij maakt dan ook gebruik van dezelfde engine als HL2.

Hier klopt dus echt nix van he.

Painkiller maakt gebruik van een eigen engine, genaamd de PAIN Engine. Hier heeft HL2 of wat dan ook nix mee te maken. Deze engine is gewoon erg standaard. Geen bumpmaps e.d, maar wel een leuke Physics-engine van Havoc.

Radiosity is nix anders dan een betere verspreiding van licht, welke ook weerkaatsen kan. O.a HL2 gebruikt dit.

Maar in HL2 is radiosity echter wel pre-rendered. Realtime is dat namelijk niet te doen.