[DX9] Texture interpolatieprobleem

[Adion]

Ik heb sinds kort een nieuwe laptop met zowel een ingebouwde videokaart van intel in de i5 processor, en een aparte Geforce 420M.
Als ik hier mijn DirectX programma op start, zien de textures er vrij slecht uit, het lijkt erop alsof er geen interpolatie word toegepast.
Als ik een extern scherm aansluit ziet het er echter vrij goed uit, op z'n minst bilineair gefilterd.


Ik vermoed dat door het aansluiten van het scherm de nVidia gebruikt word, terwijl anders de Intel aan het werk is.
Instellen dat voor mijn programma de nVidia gebruikt moet worden maakte echter geen verschil (al weet ik niet zeker of deze instelling ook gelukt was)

Ik wil uiteraard dat mijn programma er overal goed uit ziet.

Bij het tekenen van de textures heb ik al SetSamplerState toegevoegd, maar dat heeft helaas geen effect:

C++:

HRESULT res = dstPic->d3ddev->SetSamplerState(0, D3DSAMP_MAGFILTER, D3DTEXF_LINEAR);
res = dstPic->d3ddev->SetSamplerState(0, D3DSAMP_MINFILTER, D3DTEXF_LINEAR);
res = dstPic->d3ddev->SetSamplerState(0, D3DSAMP_MIPFILTER, D3DTEXF_LINEAR);

//Draw image
dstPic->d3ddev->DrawPrimitive (D3DPT_TRIANGLEFAN, 0, 2);

Ook in zowel de nVidia als Intel instellingen de interpolatiekwaliteit aanpassen heeft geen effect.
Ik weet eigenlijk niet wat ik nog kan proberen of waar ik naar moet zoeken.

[MLM]

Lijkt inderdaad op point-sampling ipv trilinear (zoals in jouw code staat, check je wel de teruggegeven code?)

Indien je UI een vaste grootte heeft in pixels, zou je er voor kunnen zorgen dat de textures pixel-per-pixel overeenkomen op je scherm, dan ziet het er wel goed uit waarschijnlijk. Maar volgens mij kunnen alle GPU's wel overweg met bilinear of trilinear filtering.

Je zou een keer kunnen draaien met reference device en debug runtime, zien of dat wat oplevert, of met PIX een framedump maken en kijken wat de daadwerkelijke sampler-settings zijn op je texture unit.

[ Voor 10% gewijzigd door MLM op 24-11-2010 19:04 ]

[NC83]

Debug runtime is sowieso goed om aan te hebben staan als je DX applicaties aan het ontwikkelen bent, aangezien je dan tenminste je D3D errors in the console kan bekijken.
Pix is de volgende stap en pas als dat niks op levert zou ik op een ref device overgaan.

[Killemov]

Je kunt een enumeratie van GPU's opvragen en er vervolgens een expliciet aansturen. Waarschijnlijk moet je eerst even filteren op naam waarbij je "integrated" o.i.d. uitsluit. En alleen als je dan geen resultaat hebt alsnog genoegen nemen met de geintegreerde gpu. Dit is echt even behoorlijk spitten in de DX documentatie.

[Adion]

De return values van SetSamplerState geven aan dat het gelukt is. Met PIX lijkt ook de status van het device op LINEAR te staan, dus dat lijkt wel in orde.
Debug runtime heb ik nog niet geprobeerd. Als ik d3d initialiseerde met reference device leek mijn applicatie niet meer te starten, dat moet ik nog eens verder bekijken.

Expliciet een bepaalde gpu kiezen is geen optie, ook op pc's met enkel geintegreerde kaart moet het uiteraard goed gaan, en ik kan me moeilijk voorstellen dat die in 2010 niet eens eenvoudige texture-interpolatie kunnen.

Zou de manier van initializeren van de textures er iets mee te maken kunnen hebben?

[NC83]

Met een REF device wordt alles door software gedaan en is daarom ook heel erg langzaam.

[MLM]

Maar als de REF device het doet, weet je dat jouw code het goed doet.
Dat PIX aangeeft dat filtering wel op linear staat doet mij vermoeden dat het niet ondersteund word door je hardware/driver voor dat device. Je kan proberen je driver up te daten.

Met DXCapsViewer (zit in je SDK) kan je eventueel kijken welke filter methodes ondersteund worden en op welke formaten. Oudere devices kunnen soms niet (goed) omgaan met niet-vierkante textures (maar dat is echt wel antiek)

[Adion]

Niet-vierkante textures lijkt me idd een behoorlijk antiek probleem ondertussen (bovendien worden de textures blijkbaar wel correct geladen zoals je ziet).
De gpu in kwestie is de gpu van de Intel Core i5 processor, dus niet bepaald oud. Driver is ook up-to-date.

Bij DXCapsViewer staat D3DPTFILTERCAPS_MAGFLINEAR op Yes (en zelfs Anisotropic is ondersteund)
Ik zal dus eerst nog eens proberen of ik het REF device aan het werk krijg.

[MLM]

Mja, als PIX aangeeft dat je settings goed zijn, en dat het dan niet werkt, is wel opvallend. Het is zeg maar dan niet meer iets waar je zelf nog bij kan nadat DX het geaccepteerd heeft.

Gebruik je shaders om dat te tekenen, of is het fixed-function? In geval van shaders kan het zijn dat 1 of andere lookup zich anders gedraagd, maar dat is nog steeds raar. In effect-files kan je ook je texture-filtering settings overschrijven in de shader-file, en dan worden je (eerdere C++) settings genegeerd.

In PIX playback heb je ook hetzelfde texture-filtering probleem?

[ Voor 3% gewijzigd door MLM op 28-11-2010 13:34 ]

[NC83]

MLM schreef op zaterdag 27 november 2010 @ 19:07:
Maar als de REF device het doet, weet je dat jouw code het goed doet.
Dat PIX aangeeft dat filtering wel op linear staat doet mij vermoeden dat het niet ondersteund word door je hardware/driver voor dat device. Je kan proberen je driver up te daten.

Met DXCapsViewer (zit in je SDK) kan je eventueel kijken welke filter methodes ondersteund worden en op welke formaten. Oudere devices kunnen soms niet (goed) omgaan met niet-vierkante textures (maar dat is echt wel antiek)

Je bedoelt non-power of two texture, vierkant heeft hier niks mee te maken omdat de GPU een texture slechts als een stuk geheugen ziet. En dat geheugen is nou eenmaal makkelijker te benaderen als het een 2 macht is in beide directies.

[MLM]

NC83 schreef op zondag 28 november 2010 @ 17:56:
[...]

Je bedoelt non-power of two texture, vierkant heeft hier niks mee te maken omdat de GPU een texture slechts als een stuk geheugen ziet. En dat geheugen is nou eenmaal makkelijker te benaderen als het een 2 macht is in beide directies.

Compleet correct, ik denk over dit soort dingen in het engels, en de vertaling was krom
Maar hoe dan ook, dat is echt een antieke requirement, en de i5 is niet antiek, het lijkt me sterk dat er zo'n restrictie is...

[.oisyn]

Offset je de polygonen wel met een halve pixel?

[ Voor 22% gewijzigd door .oisyn op 29-11-2010 15:29 ]

[Adion]

Ja, zolang de afbeeldingen niet geresized moeten worden klopt het perfect tot op de pixel.

[.oisyn]

Maar je zegt dat er bilinear gefilterd wordt. Als je een halve pixel offset dan krijg je een 1:1 mapping en hoeft er niets gefilterd te worden (want elke fetch valt precies op het middel van een texel)

[MLM]

Volgens mij gaat die vlieger niet op, ik zie in de "foute" afbeelding behoorlijk wat problemen.
Kijk bijvoorbeeld naar de horizontale lijn onder de titel, in beide afbeeldingen. (Tip, vergroot even flink zodat je de pixels goed ziet zitten)

In de goede afbeelding zie je een zwarte lijn, een grijze lijn (of achtergrond) en een witte lijn, onder elkaar, elke van ongeveer 1 pixel.
In de foute afbeelding zien we echter een zwarte lijn, GEEN grijze lijn, en 2 witte lijnen.

Uitgaande van een 1:1 mapping (zoals .oisyn hierboven), zou je dan nooit 2x een witte lijn krijgen, gezien op de texture maar 1 witte lijn zit. Mist de linker texture misschien alpha-blending (en was de middelste lijn dus FFFFFF00 (RGBA)

Als ik kijk naar letters op de achterste window (specifiek, die 112 tekst), dan zie ik ook links blauw en rechts rode pixels, terwijl je bij een wit font op zwarte achtergrond niets anders dan grijstinten zou verwachten, in beide afbeeldingen. Is er wellicht over jouw voorbeeld een texturecompressie heengeweest (JPG ofzo?)

Wat ook zou kunnen is dat de linkse consequent een te lage kwaliteit mip pakt, en daardoor dus faalt, of je GUI's zijn gestretchde rendertargets, die je later als texture (met een niet 1:1 mapping) op je app rendert?

Dat komt in elk geval zo snel bij me op, maar het kan vast nog meer zijn

[.oisyn]

Post je vertices eens.

MLM schreef op woensdag 01 december 2010 @ 12:52:
Als ik kijk naar letters op de achterste window (specifiek, die 112 tekst), dan zie ik ook links blauw en rechts rode pixels, terwijl je bij een wit font op zwarte achtergrond niets anders dan grijstinten zou verwachten, in beide afbeeldingen. Is er wellicht over jouw voorbeeld een texturecompressie heengeweest (JPG ofzo?)

Dat is cleartype.

[ Voor 91% gewijzigd door .oisyn op 01-12-2010 13:37 ]

[Adion]

.oisyn schreef op woensdag 01 december 2010 @ 11:03:
Maar je zegt dat er bilinear gefilterd wordt. Als je een halve pixel offset dan krijg je een 1:1 mapping en hoeft er niets gefilterd te worden (want elke fetch valt precies op het middel van een texel)

In het geval waarbij mijn applicatie niet geresized word klopt dat inderdaad ook, de pixel-mapping is perfect, er word niet gefilterd en alles ziet er scherp uit.

Het probleem zoals in mijn voorbeeldafbeelding doet zich enkel voor als het venster waarop getekend word groter is dan de oorspronkelijke afbeeldingen.

Door het nog eens verder te bekijken zie ik trouwens een andere mogelijke reden voor dit gedrag:
Ik maak per venster een swapchain aan met de breedte en hoogte van het venster in niet-resized toestand (300x300).
Normaal gebruik ik deze op een venster dat ook 300x300 groot is, en in dit geval komen de pixels perfect uit.

Indien de applicatie echter vergroot word behoud ik de swapchain van 300x300, maar vergroot het venster tot 400x400.
Op deze manier kon mijn applicatie gewoon blijven tekenen zonder aanpassingen aan de code en zag alles er toch groter uit.
Wat ik nu vermoed is dat in dit geval de window-manager voor het resizen zorgt, en dat dit dus mogelijk buiten mijn applicatie om gebeurd.

Ondertussen heb ik mijn probleem al bij de bron aangepakt door de skin tijdens het laden al te resizen. Op die manier moeten enkel de graphics op voorhand geresized worden, maar word tekst wel op de correcte grootte gerenderd waardoor dat er ook veel scherper uit ziet. (zoals al opgemerkt klopt idd cleartype niet helemaal meer als het achteraf geresized word)

[.oisyn]

Adion schreef op woensdag 01 december 2010 @ 15:35:
Wat ik nu vermoed is dat in dit geval de window-manager voor het resizen zorgt, en dat dit dus mogelijk buiten mijn applicatie om gebeurd.

Dit klopt idd. Als je je venster resized zonder je rendertarget mee te resizen dan krijg je een relatief lelijke stretch.

[Adion]

Maar hoe lelijk hangt dus blijkbaar af van je videokaart, waarbij het bij losse videokaarten blijkbaar prima aanvaardbaar is maar bij geintegreerde niet.

Ik vermoed dat er dan wel een manier is om de rendertarget wel te resizen, maar de ViewPort of projectie anders in te stellen waardoor vermoedelijk wel mijn sampler state instellingen gebruikt worden?

[MLM]

je samplers doen het waarschijnlijk prima, maar het uiteindelijke resultaat word op je rendertarget (backbuffer van de swapchain, in dit geval) gezet, met de resolutie van de rendertarget (de swapchain resolutie, in dit geval). windows moet daarna jouw resultaat van 300x300 over de hele window stretchen, en dat gebeurt dus lelijk, en daar heb je geen invloed op via DX voor zover ik weet.

de beste oplossing is gewoon je rendertarget resizen naar de size van de window na een resize van de window, danwel resizen verbieden. vergeet niet dat je in DX9 om een target te resizen je je device moet resetten (en dus al je textures etc opnieuw moet laden). voor 1:1 pixel mapping moet je dan ook je vertices gaan herpositioneren en wat met de projection matrix rommelen waarschijnlijk (ie, je GUI windows houden hun vaste grootte)

voor gedetailleerde informatie, zie http://msdn.microsoft.com...ry/bb174425(v=VS.85).aspx

[ Voor 28% gewijzigd door MLM op 01-12-2010 17:49 ]

[.oisyn]

vergeet niet dat je in DX9 om een target te resizen je je device moet resetten

Nonsens . Gewoon niet de default swapchain gebruiken maar een zelfgemaakte. Die kun je gewoon on the fly wisselen. Is natuurlijk voornamelijk van toepassing op windowed mode, in fullscreen mode zul je wel moeten resetten (omdat je dan in feite ook een andere frontbuffer resolutie kiest).

Zou wel heel suf zijn als een CAD/CAM tool bij elke viewport resize het hele device zou moeten resetten.

[ Voor 41% gewijzigd door .oisyn op 01-12-2010 18:05 ]