[OpenGL] dichterbij komend object "hikt", anti-aliasing?

[TheWickedD]

Voor psychologische experiment (waarnemingspsychologie) zetten wij 3D werelden in elkaar waar je doorheen kunt lopen (perspective projection natuurlijk).
Stel ik render een paal met gluCylinder (en daar 90° draaien zodat hij rechtop staat). Als je dichterbij de paal komt wordt hij langzaamaan groter. Met andere camerabewegingen beweegt de paal naar links of naar rechts op het scherm. Laten we het dichterbij komen en daarmee groter worden van het object (looming) als voorbeeld nemen, hoewel vergelijkebare problemen zich voordoen met andere bewegingen. Mijn probleem is dat het groter worden per pixel gebeurt, wat betekend dat het object lijkt te pulseren terwijl het beweegt. In plaats van dat de pixels aan de rand van het object langzaamaan meer de kleur van het object krijgen, springen die pixels op een gegeven moment van 100% achtergrond naar 100% objectkleur, dit geeft het pulserende effect.

Hoe los ik dit op (met mijn Nvidia GTX 240 kaart)? Allerlei multisampling settings lijken niets uit te halen, supersampling AA lijkt een beetje te helpen maar haalt de performance zwaar onderuit op de benodigde resolutie van 1600x1200, zelfs voor de heel simpele werelden die wij gebruiken.

Denk ik verkeerd dat ik dit met anti-aliasing wil oplossen (en klopt het dat multisampling AA hier niets bij helpt)? Op welke andere manieren kan ik hier iets aan doen?

Bedankt!

[Ventieldopje]

Multisampling zou opzich wel moeten helpen, ik werk zelf nooit met OpenGL maar kan het zijn dat je nog wat aanpassingen in de code wil maken wil je ondersteuning voor Anti-Aliasing bieden? Op die manier zou je een slider in kunnen bouwen met verschillende AA levels en realtime de AA aan kunnen passen zodat je beter het verschil tussen de levels ziet

Ook vreemd dat supersampling zo'n grote performance hit geeft op zo'n simpele omgeving, het is normaal dat het trager is maar in deze omgeving zou het weinig uit moeten maken

[MLM]

MSAA is specifiek ontworpen om dit soort problemen op te lossen
Heb je wel een achtergrond achter je cylinder, zodat je daadwerkelijk meerdere samples in 1 pixel kan nemen? (dus, een 3D object, niet een clear op de buffer)

SSAA kan je vergelijken met een "naieve" implementatie van MSAA, en zou marginaal betere resultaten kunnen opleveren, maar je zit dan wel met de kosten van een enorme rendertarget (1600x1200x4 bytes per sample)

OpenGL heb ik nooit gebruikt icm AA, dus verder dan dit kan ik je niet helpen

[Soultaker]

Weet je zeker dat er niet iets anders mis gaat? Het lijkt me dat je op 1600x1200 nauwelijks individuele pixels kan onderscheiden toch, zeker als de camera een beetje beweegt? Of heb je een heel speciaal soort animatie waarbij elke pixel die verandert extreem goed zichtbaar is?

[TheWickedD]

Bedankt voor de antwoorden!
Voordat ik specifiek reageer, eerst even wat extra informatie:
Ik draai op windows 7, 64 bit (hoewel mijn programma in 32 bit's modus is gecompileerd), gebruik makend van FreeGLUT als window manager. Aero schakel ik programmatisch uit (DwmEnableComposition(0);) zodat die niet alles omver kan halen hier. Aan of uit maakt voor dit niet uit trouwens, maar display timing wil er wel eens onder lijden.
Onze wereld wordt op een groot scherm geprojecteerd (ongeveer 1 bij 1.3 m) en de respondent ziet hier op 56 cm vanaf. Beeld bestrijkt dus 94°x110°, ongeveer geheel beeldvullend. De projector is enigszins gedefocused zodat je de inidividuele pixels niet kunt zien.

Mijn scene heeft trouwens geen belichting ingesteld, weet niet of dat iets uitmaakt.

@ Allen. Goed om te horen dat MSAA wel zou moeten werken, dat kan ik tenminste enigszins vanuit mijn programma besturen. Alleen verhelpt het mijn probleem nog niet...
@ Phas0r. Ik vond het ook maf dat supersampling niet goed vooruit te branden is. Ik heb net even op 16X MSAA gedraaid, maar ook dan is het allemaal nog duidelijk te zien, geen verschil met MSAA uit eigenlijk. Op windows is het sowieso niet aan te passen zonder opnieuw je window te creeeren, toch? dus zo'n slider zou niet makkelijk zijn.
@MLM. Interessant punt. Ik heb even een testcase gemaakt waarin de grond uit een solide gekleurde quad bestaat, terwijl de lucht gewoon de geclearde buffer is. De paal overlapt beiden. Helaas is het pulseren exact hetzelfde met de quad of het geclearde buffer op de achtergrond.
@Soultaker. Zie mijn omschrijving van de setup boven. Pixels zijn behoorlijk groot op zo'n scherm

Bedankt voor de hulp!

[PrisonerOfPain]

Hoe enable je de MSAA en weet je zeker dat je geen naive FSAA aan hebt gezet? Met FSAA render je immers naar een N keer zo grote rendertarget die vervolgens met een specifieke filter gedownscaled word. Stel je enabled 16xFSAA dan zit je al snel op een 30400x19200 rendertarget te renderen (dat is een krappe 140Mb). Iets wat absoluut funest is voor je fillrate.

@MLM die extra 8.6Mb rendertarget zal op die kaart niet veel uitmaken, zeker niet aangezien je 'm ook nog kunt recyclen voor andere post effecten.

[MLM]

PrisonerOfPain schreef op woensdag 22 december 2010 @ 10:32:
Hoe enable je de MSAA en weet je zeker dat je geen naive FSAA aan hebt gezet? Met FSAA render je immers naar een N keer zo grote rendertarget die vervolgens met een specifieke filter gedownscaled word. Stel je enabled 16xFSAA dan zit je al snel op een 30400x19200 rendertarget te renderen (dat is een krappe 140Mb). Iets wat absoluut funest is voor je fillrate.

@MLM die extra 8.6Mb rendertarget zal op die kaart niet veel uitmaken, zeker niet aangezien je 'm ook nog kunt recyclen voor andere post effecten.

Je bedoelt denk ik exact hetzelfde als mij
Die 1600x1200x4 is >per sample< als je SSAA gebruikt, bij 16 samples zit je dan dus op de door jou gequote 140 MB

Daarnaast, 16xAA is een 16x grotere target, dus dimensies zullen 16=4*4 groter zijn, en je rendertarget is dan ook 1600*4 bij 1200*4. Jouw 30400x19200 rendertarget is prolly niet supported (high-end GPU's eten al niet meer dan 16k in een dimensie), en zou niet 140, maar 1494MB groot zijn (uitgaande van 32bit kleurdiepte)

Maar goed, MSAA zou ook gewoon moeten werken, maar ik gok dat het iets OpenGL specifieks gaat zijn. Desondanks, met een 240GTX kan je prolly nog wel genoeg fillrate scoren om 140MB te renderen als je geen dure pixelshaders hebt rondlopen.

[ Voor 13% gewijzigd door MLM op 22-12-2010 13:46 ]

[PrisonerOfPain]

MLM schreef op woensdag 22 december 2010 @ 13:39:
[...]


Je bedoelt denk ik exact hetzelfde als mij
Die 1600x1200x4 is >per sample< als je SSAA gebruikt, bij 16 samples zit je dan dus op de door jou gequote 140 MB

Errr. SSAA is toch gewoon een simpele edge detection shader + blur?

[MLM]

SS = super-sampling AA
Ik ken geen afkorting voor SSAA waar dat ergens anders voor staat
FSAA = full-scene AA, en omvat afaik alle AA methoden (onder andere SSAA en MSAA), en gebruik ik als een soort groepeer-term voor een ongedefinieerde AA methode.

Met SSAA bedoelde ik dus de methode, net als MSAA een methode is voor AA. Sorry als dat niet duidelijk was

[ Voor 36% gewijzigd door MLM op 22-12-2010 15:35 ]

[PrisonerOfPain]

MLM schreef op woensdag 22 december 2010 @ 15:33:
SS = super-sampling AA
Ik ken geen afkorting voor SSAA waar dat ergens anders voor staat

Ah. Er bestaat dus ook een screen-space AA . OpenGL heeft een beetje een brakke geschiedenis mbt AA verder aangezien de spec het een tijd (misschien nog steeds) niet toe stond om shortcuts te nemen met AA. Ergo, de AA moest altijd een grotere buffer gebruiken om naar te renderen in plaats van wat GPU bakkers heden ten dagen doen, namelijk de scene door een fancy filter heen halen om te besparen om geheugengebruik. Nadeel daarvan is dat die over het algemeen wat slechter de temporal aliassing tegen gaan maar daar lijkt het in dit geval niet over te gaan.

[ Voor 50% gewijzigd door PrisonerOfPain op 22-12-2010 15:41 ]

[MLM]

Mja, in dat geval is het waarschijnlijk dus iets wat te maken heeft met OpenGL waardoor het niet helemaal lekker werkt in het geval van de TS.

Misschien zijn er meerdere MSAA extensions voor OGL, daar ben ik echt niet in thuis. In dat geval kan je misschien daar een andere voor kiezen Wat ook een mogelijkheid is, om met de control panel van je GPU jouw app te forceren op AA, en dan in OGL gewoon renderen zonder AA. Best kans dat het werkt

[The Flying Dutchman]

Weet je zeker dat je OpenGL code om multisampling aan te zetten correct is?


Aangezien je Glut gebruikt:

code:

glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB | GLUT_DEPTH | GLUT_MULTISAMPLE);

En verder natuurlijk:

code:

glEnable(GL_MULTISAMPLE);

Zie ook hier:
http://www.opengl.org/dis...bb=showflat&Number=270360

Heb je de nieuwste versie van Freeglut?

[TheWickedD]

Hoi PrisonerOfPain, MLM en The Flying Dutchman,

Bedankt voor de verdere discussie. Ik gebruik inderdaad de nieuwste FreeGLUT, vers uit SVN getrokken en gecompileerd (heb net nog wat nieuwe VS2008 en VS2010 project files aan ze gestuurd, de huidige steup van deze is wat brak).

Ik open mijn window met glutInitDisplayMode( GLUT_RGBA | GLUT_DOUBLE | GLUT_MULTISAMPLE); Heb ik een Depth buffer nodig om dit te gaan laten werken? Eens proberen... Verder daarna natuurlijk glEnable(GL_MULTISAMPLE);

Ik heb het zowel in de driver geforceerd (de benaming van de verschillende methoden in the NVidia driver laat niet weten welke methode gebruikt wordt voor de AA, maar naar wat ik online kan achterhalen zijn de standen 2x, 4x, 8x, 16x, MSAA en de standen zoals 8xQ een mix van MSAA en SSAA) als simpelweg in mijn applicate geforceerd. Als ik dit draai in mijn code:

C++:

GLint buf = 0;
glGetIntegerv(GL_SAMPLES,&buf);
cout << "Multisampling sample buffers: " << buf << endl;

Krijg ik ook netjes het aantal samples terug dat ik verwacht (en glGetIntegerv(GL_SAMPLE_BUFFERS,&buf) geef ook true terug). Dat duid er allemaal op dat de MSAA juist is aangezet. Ik ga het depth buffer even proberen. Ben geen OpenGL/graphics expert (psychologie achtergrond tenslotte, hoewel ik al vele jaren prog), dus weet niet wat het nut daarvan is

Bedankt!

[MLM]

Hoe render jij een 3D scene zonder depthbuffer
Zodra de scene enigzins complex word, gaat dat lastig worden

Mogelijk gaat dat wel helpen, depthbuffers kunnen ook MSAA hebben, proberen in elk geval

[The Flying Dutchman]

TheWickedD schreef op vrijdag 24 december 2010 @ 01:25:
Ben geen OpenGL/graphics expert (psychologie achtergrond tenslotte, hoewel ik al vele jaren prog), dus weet niet wat het nut daarvan is

Een depth buffer zorgt ervoor dat objecten die vooraan staan in de 3d scene ook daadwerkelijk over objecten die verder naar achter staan gerenderd worden (ook als het voorste object eerst gerenderd wordt en daarna pas het achterste object).

Zonder depth buffer kun je ook geen MSAA doen volgens mij... om de juiste AA toe te passen wordt (meen ik) de depth uit de depth buffer ook gebruikt. Moeite van het proberen waard iig.

Vergeet dan niet:

code:

// in de initialisatie
glEnable(GL_DEPTH_TEST);

// vooraan in je render loop
glClear(GL_DEPTH_BUFFER_BIT);  // waarschijnlijk heb je al een glClear(COLOR_BUFFER_BIT), dan wordt het glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);

[TheWickedD]

Sorry voor de lange stilte, ben een paar dagen niet in het lab geweest.

@MLM: Het zijn heel simpele 3D werelden en toevallig tekende ik ze in de juiste volgorde. Depth_test kan zeker geen kwaad en heb ik dus ook maar aangezet (en ik vraag natuurlijk ook om een depth buffer). Dankje ook Flying Dutchman voor de voorbeeld code

Helaas lijkt ook dit het verschil niet te maken. Op een AMD kaart thuis heb ik zelfs op 16x nog duidelijk pulseren (als je goed kijkt, thuis heb ik niet zo'n groot scherm natuurlijk). De 16x and 16xQ standen van Nvidia lijken het redelijk te doen gelukkig en performance is prima. Het is nog niet helemaal weg, maar het is allemaal een stuk beter. Depth buffer is dus toch belangrijk, ondanks dat ik in de juiste volgorde inteken. Bedankt voor de tip! Ik ga toch eens kijken of ik een nieuwere kaart kan kopen, dan kan ik er zelfs 32x tegenaan gooien

Dank!