In OpenGL renderstijl van een spel nabootsen

[Rygir]

Momenteel ben ik bezig met wat OpenGL experimenten, ik ben het een beetje aan het oefenen zeg maar. Nu wil ik er een kleine demo mee bouwen (door middel van QT, waarvan ik overigens heb opgegeven om de laatste nieuwe versie in Visual Studio 10 aan de praat te krijgen waardoor ik een beetje tegen mijn zin de QT SDK creator IDE moet gebruiken nu) en voor die demo wil ik een beetje aantrekkelijke graphics creeëren. Aantrekkelijk niet door polycount en complexe modellen maar door processing en rendertechnieken vermits dat hetgene is dat ik wil oefenen.

Wat ik nu wens te bekomen is de look van het spel RUSH, een prima voorbeeld van mijn wensen want het is ook niets dan cubussen en ziet er toch blits uit (naar mijn bescheiden mening dan toch).

Om jullie een klik te sparen, hier een illustratief beeldje van de beoogde stijl :


De vraag die ik nu heb is...wat moet ik nu eigenlijk allemaal hebben om deze look te verkrijgen? Wat voor effecten zijn hier toegepast, kan iemand dat zo op het oog herkennen?

Die zachte gloed rond alles lijkt mij iets wat simpel te bekomen moet zijn, maar ik heb geen idee waar ik moet zoeken. Is dit iets dat ik zelf moet schrijven, zo ja, in wat voor vorm (is dat een shader?), zo nee, kan ik zoiets vinden in kant en klare openGL functies? Ik hoop dit omdat ik denk aan Z-Buffering, daarvoor wordt ook niet verlangd dat je alles zelf doet, misschien dat de nieuwere openGL versies ook leukere high-level effecten bevatten? Ook de belichtingsstijl zou ik willen nabootsen.

Kortom... een zet in de goeie richting om effecten zoals die van RUSH te implementeren is wat ik verlang.

Ik heb een vijftal dagen uitgetrokken voor te spelen met OpenGL, gaat dit te ver gaan qua complexiteit?

[RobIII]

Waar hoort mijn topic?
SEA >> PRG

[Rygir]

RobIII schreef op donderdag 28 juli 2011 @ 03:34:
Waar hoort mijn topic?
SEA >> PRG

Dankuwel voor het verplaatsen. In eerste instantie wou ik het daar plaatsen maar had toen gezocht op "OpenGL" en de eerste resultaten stonden in SEA waardoor ik begon te twijfelen...

[ Voor 6% gewijzigd door Rygir op 28-07-2011 03:49 ]

[R4gnax]

De subtiele fuzzy gloed die alles heeft zou je wss. wel middels bloom kunnen benaderen. De plastic uitziende belichting is een kwestie van juist ingestelde Phong shading: een gemiddelde ambient factor, een wat lagere diffuse factor en een hoge specular factor gebruiken.

Verder is het natuurlijk wel zaak dat je de surface normals van de kubussen juist berekent: per inviduele zijde, anders zul je geen nette scherpe scheiding tussen (en egale kleuring van) de vlakken krijgen.

[ Voor 26% gewijzigd door R4gnax op 28-07-2011 08:27 ]

[ZaPPZion]

Zo te zien zijn de kubussen ook langs de randen ge-chamferd, dat is wel vrij essentieel als je die mooie highlights op de randjes van de kubussen wilt krijgen, op een harde rand lukt dat natuurlijk nooit.

[CR35]

Als ik zo kijk lijken de schaduwen meegerenderd te zijn met de maps(mooie soft shadows op lichte ondergronden) Daarnaast zijn de randen afgerond, anders bereik je dat effect niet met een simpele specular shader. Of je zou een eigen specular shader moeten schrijven die aan de randen de surface normals aanpast(over korte afstand interpoleren met de aanliggende normal van de aanliggende surface).

Succes!

[PrisonerOfPain]

- Phong shading met hoge specular voor de cubes
- Prerendered lightmaps
- Redelijk wat bloom op de cubes in de achtergrond

Voor de rest zit 't 'm vooral in het kleurenpallet dat ze gebruikt hebben voor de cubes / achtergrond.

Edit: is blijkbaar allemaal al gezegt. Nu ja, veel plezier er mee

[ Voor 13% gewijzigd door PrisonerOfPain op 28-07-2011 11:29 ]

[CR35]

@PrisonerOfPain, je zegt het iets mooier

[PrisonerOfPain]

Verder de anti-aliassing niet vergeten, een omgeving als hoeft niet deferred gerendered te worden en kan prima met MSAA uit de voeten.

CR35 schreef op donderdag 28 juli 2011 @ 12:13:
@PrisonerOfPain, je zegt het iets mooier

[NC83]

ZaPPZion schreef op donderdag 28 juli 2011 @ 11:17:
Zo te zien zijn de kubussen ook langs de randen ge-chamferd, dat is wel vrij essentieel als je die mooie highlights op de randjes van de kubussen wilt krijgen, op een harde rand lukt dat natuurlijk nooit.

Op een harde rand lukt dat ook gewoon hoor alleen moet je een normal map op iedere kubus zijde zetten die het chamfered effect nabootst.

De soft shadows zijn waarschijnlijk een ambient oclusion blob, aangezien de hoeveelheid occlusion verandert met de view angle van de camera. Als je dit zelf snel wil doen kun je ze ook prerenderen zoals de anderen zeggen. Alleen krijg je dan geen verloop als de camera angle verandert.

Je zou al deze effecten zelf moeten schrijven in CG of GLSL (shaders) en ik dnek dat je met 5 dagen niet helemaal redt om al deze effecten op het niveau te krijgen dat je wil hebben.

[ Voor 13% gewijzigd door NC83 op 29-07-2011 18:16 ]

[PrisonerOfPain]

NC83 schreef op vrijdag 29 juli 2011 @ 18:12:
De soft shadows zijn waarschijnlijk een ambient oclusion blob, aangezien de hoeveelheid occlusion verandert met de view angle van de camera. Als je dit zelf snel wil doen kun je ze ook prerenderen zoals de anderen zeggen. Alleen krijg je dan geen verloop als de camera angle verandert.

SSAO is het sowieso niet dus dan zit je al snel naar een Radiosity oplossing te kijken als het realtime moet. En dan kun je wss net zo makkelijk een lightmap oplossing pakken omdat die een overhead en complexity van praktisch nul hebben.

[Rygir]

R4gnax schreef op donderdag 28 juli 2011 @ 08:23:
De subtiele fuzzy gloed die alles heeft zou je wss. wel middels bloom kunnen benaderen. De plastic uitziende belichting is een kwestie van juist ingestelde Phong shading: een gemiddelde ambient factor, een wat lagere diffuse factor en een hoge specular factor gebruiken.

Verder is het natuurlijk wel zaak dat je de surface normals van de kubussen juist berekent: per inviduele zijde, anders zul je geen nette scherpe scheiding tussen (en egale kleuring van) de vlakken krijgen.

En heeft openGL daar ingebouwde voorzieningen voor want ik heb, in mijn Comp.Graph. opleiding wel een formule gezien (of de formule, weet niet of daar varianten op bestaan) en zou die prima kunnen implementeren maar dan moet ik per pixel die berekening doen (of mits de optimalisaties zoals interpolatie tussenvertices of tussen normalen) en ik weet niet hoe ik dat moet aanpakken. Ik werk momenteel met Qt en daar is alles zo netjes afgeschermd dat ik eigenlijk niet wat waar gebeurt, je hebt je paint functie en je zet daar wat 3D punten in om te tekenen en voila je krijgt een driehoekje of zo op 't scherm...maar buiten gouraud shading heb ik geen idee hoe ik binnen dat driehoekje iets anders dan een effen kleur krijg...

ZaPPZion schreef op donderdag 28 juli 2011 @ 11:17:
Zo te zien zijn de kubussen ook langs de randen ge-chamferd, dat is wel vrij essentieel als je die mooie highlights op de randjes van de kubussen wilt krijgen, op een harde rand lukt dat natuurlijk nooit.

Dat heb ik tot nu toe gewoon aangepakt door zelf mijn kubus punten te berekenen in een eigen-gemaakt cube object. Feitelijk gewoon eenmaal een rib lengte opgeven en daarna met een 2e parameter bepalen hoeveel je afsnijd van elke rib om af te schuinen. Handwerk, maar puntjes berekenen is leuk .

CR35 schreef op donderdag 28 juli 2011 @ 11:24:
Als ik zo kijk lijken de schaduwen meegerenderd te zijn met de maps(mooie soft shadows op lichte ondergronden) Daarnaast zijn de randen afgerond, anders bereik je dat effect niet met een simpele specular shader. Of je zou een eigen specular shader moeten schrijven die aan de randen de surface normals aanpast(over korte afstand interpoleren met de aanliggende normal van de aanliggende surface).

Succes!

Dat was ik dus ook aan't denken... moet ik dat dan op voorhand renderen naar textures? Of kan ik dat realtime klaarkrijgen, die schaduwen? En in geval van op voorhand... tips voor hoe je zo iets moet aanpakken? Gaat mijn petje momenteel te boven om naar iets anders dan het scherm te renderen. @randen : normals interpoleren... idd leuk gedacht.

PrisonerOfPain schreef op donderdag 28 juli 2011 @ 11:28:
- Phong shading met hoge specular voor de cubes
- Prerendered lightmaps
- Redelijk wat bloom op de cubes in de achtergrond

Voor de rest zit 't 'm vooral in het kleurenpallet dat ze gebruikt hebben voor de cubes / achtergrond.

Edit: is blijkbaar allemaal al gezegt. Nu ja, veel plezier er mee

Niettemin mooi samengevat , bedankt

PrisonerOfPain schreef op donderdag 28 juli 2011 @ 12:30:
Verder de anti-aliassing niet vergeten, een omgeving als hoeft niet deferred gerendered te worden en kan prima met MSAA uit de voeten.


[...]

Oei... moeilijk woord... deferred? Zie niet in wat afleiden of uitstellen te maken heeft met AA...kennelijk nog iets wat ik moet gaan opzoeken...

NC83 schreef op vrijdag 29 juli 2011 @ 18:12:
De soft shadows zijn waarschijnlijk een ambient oclusion blob, aangezien de hoeveelheid occlusion verandert met de view angle van de camera. Als je dit zelf snel wil doen kun je ze ook prerenderen zoals de anderen zeggen. Alleen krijg je dan geen verloop als de camera angle verandert.

Je zou al deze effecten zelf moeten schrijven in CG of GLSL (shaders) en ik dnek dat je met 5 dagen niet helemaal redt om al deze effecten op het niveau te krijgen dat je wil hebben.

Klinkt interessant die ambient occlusion blob.

En zoals ik al vreesde, shaders dus... een tip waar ik goeie "tutorials" of beginners hulp met shaders kan vinden? Als ik de lighting oversla valt er misschien nog wel wat interessants te maken op de beschikbare tijd.

PrisonerOfPain schreef op vrijdag 29 juli 2011 @ 18:24:
[...]


SSAO is het sowieso niet dus dan zit je al snel naar een Radiosity oplossing te kijken als het realtime moet. En dan kun je wss net zo makkelijk een lightmap oplossing pakken omdat die een overhead en complexity van praktisch nul hebben.

Heb snel over SSAO gelezen, maar kan niet eens goed opmaken wat het doet. Berekent het, uit alle richtingen, hoe veel iets "omsloten" is? Dus alsof er licht van overal komt (ambient licht dus) en alle richtingen even belangrijk zijn?

En radiosity werkt toch op basis van raytracing dacht ik he? Lijkt me in ieder geval overkill. Lightmaps lijken mij ook de meest logische aanpak maar de theorie omzetten in praktijk middels openGL weet ik dus nog niet waar te beginnen.

[Orwell]

Rygir schreef op zaterdag 30 juli 2011 @ 18:24:
En heeft openGL daar ingebouwde voorzieningen voor want ik heb, in mijn Comp.Graph. opleiding wel een formule gezien (of de formule, weet niet of daar varianten op bestaan) en zou die prima kunnen implementeren maar dan moet ik per pixel die berekening doen (of mits de optimalisaties zoals interpolatie tussenvertices of tussen normalen) en ik weet niet hoe ik dat moet aanpakken. Ik werk momenteel met Qt en daar is alles zo netjes afgeschermd dat ik eigenlijk niet wat waar gebeurt, je hebt je paint functie en je zet daar wat 3D punten in om te tekenen en voila je krijgt een driehoekje of zo op 't scherm...maar buiten gouraud shading heb ik geen idee hoe ik binnen dat driehoekje iets anders dan een effen kleur krijg...

Ik weet niet of OpenGL een Fixed Function Pipeline heeft en of je die wel wilt gebruiken, maar als die er is (Google het eens), zal je met een regeltje of 20 (resources en states setten) wel een render pass kunnen maken. Daarmee kan je zonder shaders je model op het beeld krijgen. Dan moet je uiteraard wel weten hoe je een window maakt, OpenGL opstart en hoe je met de videokaart kan verbinden.

Maar als je zelf wilt bepalen hoe je objecten op licht reageren kun je beter aan shaders (.fx) beginnen. Ik weet weer niet hoe OpenGL dat doet (of beter: hoe OpenGL met GLSL praat), maar je zult twee functies moeten maken:

• Eentje die elke vertexpositie van relatief-aan-nulpunt-object (Object Space) naar pixelcoordinaten converteert (Clip Space e.d.). Noemt men een Vertex Shader.
• En eentje die elke resulterende pixel die niet achter andere pixels zit een kleur geven. Di's een Pixel Shader.

En uhm, dat normalen zelf maken is echt pestwerk. Ben zelf ook jaartje geleden met een 3D-prog begonnen, en zat toen met hetzelfde probleem: "waar haal ik de modellen vandaan?". Heb dus tijdje later een .obj-lezer gemaakt (kun je vast nog ergens vinden op m'n GoT-profiel): dan hoef je alleen nog maar voor een (gratis) editor te zorgen: Wings3D of Blender ofzo.

Dat heb ik tot nu toe gewoon aangepakt door zelf mijn kubus punten te berekenen in een eigen-gemaakt cube object. Feitelijk gewoon eenmaal een rib lengte opgeven en daarna met een 2e parameter bepalen hoeveel je afsnijd van elke rib om af te schuinen. Handwerk, maar puntjes berekenen is leuk .

Probeer daar is een theepot mee te maken.

Dat was ik dus ook aan't denken... moet ik dat dan op voorhand renderen naar textures? Of kan ik dat realtime klaarkrijgen, die schaduwen? En in geval van op voorhand... tips voor hoe je zo iets moet aanpakken? Gaat mijn petje momenteel te boven om naar iets anders dan het scherm te renderen. @randen : normals interpoleren... idd leuk gedacht.

Ik weet niet hoe ze die schaduwen gedaan hebben, maar gelukkig lijkt het geen SSAO (dan zou er op veel meer plekken schaduw te zien moeten zijn, zoals de onderkant van de doosjes). Grote kans dat het gewoon ambient maps zijn.

Oei... moeilijk woord... deferred? Zie niet in wat afleiden of uitstellen te maken heeft met AA...kennelijk nog iets wat ik moet gaan opzoeken...

De 'normale' manier van alle objecten naar kleurenpixels converteren gaat zo (noemen ze Forward Rendering):

• Per object elke vertex een pixelcoordinaat (x,y,diepte) geven. (Vertex Shader)
• Bepalen welke pixels het model inneemt (interpolate).
• Over elke pixel die niet achter een bestaande pixel ligt de Pixel Shader (kleur geven) gooien.
• En tot hier dus per object.

Dat kan helaas erg zwaar zijn als er bijvoorbeeld veel lichten nodig zijn, want de 'zwaarheid' van een level is dan grofweg zo te berekenen:

aantalmodellen*aantallichten

Niet altijd handig, want modellen die achteraf ergens achter blijken te staan hebben wel tijd gekost om een kleur te geven (met een licht). dus daarom is er Deferred Rendering. Dat gaat zo:

• Van alle objecten elke vertex een pixelcoordinaat (x,y,diepte) geven. (Vertex Shader)
• Bepalen welke pixels er bovenaan zitten (in het zicht).
• Nu staan alle objecten op het scherm (wel zonder kleur).
• Over elke overgebleven pixel die niet achter een bestaande pixel ligt de Pixel Shader gooien.

Hiermee hoef je maximaal bijv. 1920x1080 maal de pixel shader uit te voeren.

Klinkt interessant die ambient occlusion blob.

Shame on me voor het niet kennen van die term, maar uh, is dat gewoon een sphere die je elke pixel op intersect test en if(intersect) dan de pixel donkerder maakt?

En zoals ik al vreesde, shaders dus... een tip waar ik goeie "tutorials" of beginners hulp met shaders kan vinden? Als ik de lighting oversla valt er misschien nog wel wat interessants te maken op de beschikbare tijd.

Jep, eerst is een model op zijn plek krijgen en gewoon de kleur op 1,1,1 zetten (outPS.color.rgba = float4(1,1,1,1);)..

Heb snel over SSAO gelezen, maar kan niet eens goed opmaken wat het doet. Berekent het, uit alle richtingen, hoe veel iets "omsloten" is? Dus alsof er licht van overal komt (ambient licht dus) en alle richtingen even belangrijk zijn?

Ik ben er maanden mee bezig geweest en heb het tweemaal opgegeven, maar nu werkt het eindelijk. Kijk, ehm, in geval van een werkende Deferred Renderer is het niet lastig, maar het doet eigenlijk dit:

• Sla van elke pixel de diepte op.
• Kijk bij elke pixel bij een random paar omliggende pixels of die buren toevallig niet minder diepte hebben (dus schuin ervoor zitten). Als er van dit soort pixels gevonden zijn, maak de pixel die getest wordt donkerder.

Ik zou er voorlopig nog niet aan beginnen, maar het ziet er zo uit (effect is even overdreven gemaakt):


Ziedaar mijn creatie waar ik een jaar geleden met hetzelfde idee aan begon!

Dit doe je trouwens ook met Rendering 'passes'. Twee stuks in dit geval.

En radiosity werkt toch op basis van raytracing dacht ik he? Lijkt me in ieder geval overkill. Lightmaps lijken mij ook de meest logische aanpak maar de theorie omzetten in praktijk middels openGL weet ik dus nog niet waar te beginnen.

Raytracing moet je niet aan beginnen nee.

Waar te beginnen he? Zat ik ook mee. Nou, in ieder geval, wat je eerst is moet doen is een Win32-window (HWND noemen ze dat) maken en OpenGL opstarten en met de videokaart verbinden.

Oh, enne, ik heb nog nooit van m'n leven iets aan wikipedia gehad als het over dit soort onderwerpen gaat. Goeie sites zijn bijvoorbeeld gamedev.net en msdn als je voor D3D gaat.

Over D3D vs OpenGL (héél simpel gezegd): D3D heeft de betere documentatie, maar draait uiteraard alleen op Windows en Wine.

Oh, en uh, zoek is een leuk boek op. Veel nuttiger dan internet.

Ik wilde nog wel meer typen, maar het is helaas even etenstijd enzo.

Edit: sorry voor het haastige getyp, maar ik kon het niet laten om te reageren op vragen over m'n favo onderwerp: 3D.

[PrisonerOfPain]

Rygir schreef op zaterdag 30 juli 2011 @ 18:24:
En radiosity werkt toch op basis van raytracing dacht ik he? Lijkt me in ieder geval overkill.

Nee.

Lightmaps lijken mij ook de meest logische aanpak maar de theorie omzetten in praktijk middels openGL weet ik dus nog niet waar te beginnen.

Lightmaps zijn raytraced over het algemeen maar dat doe je offline.

Verder als je net begint kun je een hoop van de genoemde dingen overslaan en je het beste gewoon aan het lijstje houden wat ik postte, daar zul je al genoeg problemen aan ondervinden om te implementeren. Zeker als je nog OpenGL / shaders moet leren

[ Voor 22% gewijzigd door PrisonerOfPain op 31-07-2011 16:45 ]

[NC83]

Pixel shaders heten fragment shaders in OpenGL dus daar zou je genoeg info over moeten vinden op google.

Shaders zijn doorgaands makkelijker om mee te programmeren dan de Fixed Function pipeline, minder renderstates om te beheren. Daarnaast bijna niemand gebruikt nog de Fixed Function pipeline dus om die aan te leren kost enkel meer tijd die je beter in shaders kunt steken.

Orwell schreef op zondag 31 juli 2011 @ 14:31:
.fx

Dat zijn trouwens effect files en niet losse shaders, effect files kunnen naast shaders ook renderstate setup bevaten. Shaders zelf kunnen iedere extensie hebben die je wil, het zijn immers gewoon text files, en in OpenGL moet je eerst die files in lezen en dan compilen alvorens je ze kunt gebruiken.

Goeie sites zijn idd gamedev.net en MSDN voor WIN32 en D3D maar ook codesampler.com als je simpele tutorials wil volgen voor D3D9 of OpenGL.

Zowel deferred shading als het bloom effect vereisen meerdere render passes per frame helaas en dus Frame buffer objects in OpenGL.

[Orwell]

PrisonerOfPain schreef op zondag 31 juli 2011 @ 16:42:
Verder als je net begint kun je een hoop van de genoemde dingen overslaan en je het beste gewoon aan het lijstje houden wat ik postte, daar zul je al genoeg problemen aan ondervinden om te implementeren. Zeker als je nog OpenGL / shaders moet leren

Jep, SSAO en Ambient Lighting bla zijn ook niet bepaald nodig enzo.

En idd, eerst is simpel beginnen, window maken en OpenGL opstarten. Kan idd al genoeg problemen opleveren.

NC83 schreef op zondag 31 juli 2011 @ 17:24:
Pixel shaders heten fragment shaders in OpenGL dus daar zou je genoeg info over moeten vinden op google.

Da's waar, vergeten.

Dat zijn trouwens effect files en niet losse shaders, effect files kunnen naast shaders ook renderstate setup bevaten. Shaders zelf kunnen iedere extensie hebben die je wil, het zijn immers gewoon text files, en in OpenGL moet je eerst die files in lezen en dan compilen alvorens je ze kunt gebruiken.

Hm, in D3D(X) schelen ze erg veel tijd. Je hoeft bijvoorbeeld de registers en samplerslots niet meer zelf bij te houden. Zeker als het in vijf dagen moet, kun je iig in D3D niet zonder: compilen is toch met 1 functie gebeurd. Dan hoef je alleen nog maar van de vars en techniques de pointers te maken en klaar is kees.

Oh, ik kende codesampler.com nog niet! Laat ik er dan is mynameismjp.wordpress.com aan toevoegen.

En jeh, eerst is OpenGL opstarten.

[ZaPPZion]

Orwell schreef op zondag 31 juli 2011 @ 14:31:
[...]
Ik weet niet of OpenGL een Fixed Function Pipeline heeft en of je die wel wilt gebruiken, maar als die er is (Google het eens), zal je met een regeltje of 20 (resources en states setten) wel een render pass kunnen maken. Daarmee kan je zonder shaders je model op het beeld krijgen. Dan moet je uiteraard wel weten hoe je een window maakt, OpenGL opstart en hoe je met de videokaart kan verbinden.

OpenGL kan natuurlijk ook gebruik maken van de FFP, aangezien dit (een) hardware onderde(e)l(en) is(/zijn). Het is zeker aan te raden om mee te beginnen als je nog nooit iets met 3D gedaan hebt, anders krijg je wel echt een gigantische brok informatie in een keer. Gelukkig maken de meeste tutorials gebruik van de FFP, dus komen shaders pas op een later moment.

Als je gemakkelijk een window wilt maken en daar OpenGL in wilt zetten en wilt 'verbinden' met de videokaart (als je daar van kunt spreken), zijn er verschillende standaard libraries die het je erg gemakkelijk kunnen maken. Denk hierbij aan bijvoorbeeld GLUT, freeGLUT, SDL en QT (van klein naar groot qua omvang en standaard mogelijkheden).

[NC83]

ZaPPZion schreef op maandag 01 augustus 2011 @ 16:21:
[...]


OpenGL kan natuurlijk ook gebruik maken van de FFP, aangezien dit (een) hardware onderde(e)l(en) is(/zijn). Het is zeker aan te raden om mee te beginnen als je nog nooit iets met 3D gedaan hebt, anders krijg je wel echt een gigantische brok informatie in een keer. Gelukkig maken de meeste tutorials gebruik van de FFP, dus komen shaders pas op een later moment.

Als je gemakkelijk een window wilt maken en daar OpenGL in wilt zetten en wilt 'verbinden' met de videokaart (als je daar van kunt spreken), zijn er verschillende standaard libraries die het je erg gemakkelijk kunnen maken. Denk hierbij aan bijvoorbeeld GLUT, freeGLUT, SDL en QT (van klein naar groot qua omvang en standaard mogelijkheden).

Sinds DX10 hardware is de Fixed Function pipeline niet meer in hardware ter beschiking er draaien conversie shaders die de fixed function pipeline omzet naar shaders. De driver voor de GPU regelt de translatie van FF naar shaders.
Als je een D3D9 app draait op DX 10 hardware met debug dlls enabled is dit de traces die je ziet die je vertellen dat dit gebeurt:

code:

Direct3D9: (INFO) :======================= Hal HWVP device selected

Direct3D9: (INFO) :HalDevice Driver Style b

Direct3D9: (INFO) :Using FF to VS converter

Direct3D9: (INFO) :Using FF to PS converter

D3D9 Helper: Warning: Default value for D3DRS_POINTSIZE_MAX is 2.19902e+012f, not 3.89256e-316f.  This is ok.

[ZaPPZion]

Ah, cool, thanks dat wist ik niet Natuurlijk maakt dit voor de TS niet echt uit, je kunt het dus alsnog gebruiken