Anisotrope Filterung @ VSA-100 - ja oder nein?

  • In diesen Artikel wird vom "Vertexbasierenden anisotropen Filtering" gequatscht. Aber wenn das möglich ist, warum findet sich das in keinem Treiber? Wenn man das so liest, dann scheint es per T-Buffer möglich zu sein und ist nur noch eine Treibersache. Es gingen ja auch schon Bilder mit "64 tap"-AF herum - das dürfte nur die V5 6000 beherrschen. Existiert denn ein Treiber, der AF auswerfen kann? Und warum greift z.B. SFFT das Konzept nicht auf? Gibt es Probleme bei der LOA-Berechnung?

    MfG,
    Raff

  • Meines Erachten ist dieser Teil des Artikels schlichtweg Unsinn.

    Offensichtlich hat der Autor irgendwelchen Kram abgeschrieben und kombiniert, ohne die Hintergründe der Texturfilterung wirklich durchdrungen zu haben. Er bringt hier vieles durcheinander und kombiniert es unsinnigerweise.

    Und selbst wenn das funktionieren sollte, ist Vertexbasierte LOD/LOA Berechnung immer sehr ungenau (der G200 berechnet das LOD ja noch über die Geometrie statt über das Trisetup ...furchtbar!). Das würde in Bewegung wohl unbrauchbar sein. Das ist wohl auch der Grund, warum es nie umgesetzt wurde.

    AthlonXP 1700+ JIUHB @1,35V
    EPOX 8K3A+
    SBLive!
    2x80er WD800BB
    WaKü

    SEIJIN.DE Redakteur

  • Ich würd's trotzdem gerne mal sehen. Mit negativem LOD kann man schon sehr viel erreichen. Wenn man dann mit etwas AF - und sei es noch so ungenau - noch den letzten Matsch-Rest am Horizont weitgehend plattmachen kann und das wirklich nicht extrem viel Leistung kostet, dann wäre das schon geil. :)

    MfG,
    Raff

  • Zitat

    Original von Robbitop
    Meines Erachten ist dieser Teil des Artikels schlichtweg Unsinn.

    Offensichtlich hat der Autor irgendwelchen Kram abgeschrieben und kombiniert, ohne die Hintergründe der Texturfilterung wirklich durchdrungen zu haben. Er bringt hier vieles durcheinander und kombiniert es unsinnigerweise.

    Und selbst wenn das funktionieren sollte, ist Vertexbasierte LOD/LOA Berechnung immer sehr ungenau (der G200 berechnet das LOD ja noch über die Geometrie statt über das Trisetup ...furchtbar!). Das würde in Bewegung wohl unbrauchbar sein. Das ist wohl auch der Grund, warum es nie umgesetzt wurde.

    Das der Artikel inhaltlich nicht ganz korrekt ist, hatte ich bereits geahnt. Vielen Dank für die Bestätigung.

    Wir würden uns natürlich über eine Korrektur deinerseits (wenn überhaupt möglich) sehr freuen.
    Bis dein(e) Artikel auf 3dcenter.de steht/stehen, wäre das Update sicherlich fertig. ;)
    Du würdest uns jedenfalls einen großen Gefallen tun.
    Ich werde jedenfalls schon einmal veranlassen, dass diese Peinlichkeit verschwindet.


    t.b.d

    TRADEMARK INFORMATION
    3DFX, 3DFX INTERACTIVE, the 3dfx Logo, STB, STB Systems and Design, the STB Logo, VOODOO, VOODOO GRAPHICS, Glide, M-BUFFER, T-BUFFER are registered trademarks or trademarks of NVIDIA Corporation in the United States and/or other countries.

    Mein System (mit Final-Update =))

  • Das korrigieren?
    Dazu müßte man ersteinmal Informationen haben, woher das Ganze kommt, wie es wirklich umgesetzt ist, wer es umgesetzt hat und wie er es genau umgesetzt hat. Ich bezweifle ganz ehrlich, dass das so gehen soll...wenn es überhaupt geht.
    Verstehen konnten weder Arne noch ich viele Zusammenhänge, da sie unkorrekt/verwirrend sind.
    Das Elipsenmodell ist ein theoretischer mathematischer Ansatz für die Winkelabhängige (also An-isotrope) Texturfilterung. Funktioniert in Hardware natürlich ganz anders und vereinfacht.
    Ein Problem ist immer die Berechnung der Line-of-Anisotropy. Vertexbasierend könnte man lediglich für ~90° Winkel eine korrekte Berechnung durchführen, alle anderen Winkel bekäme die falsche Sampleanzahl und würde über- oder unterfiltert werden.
    Um die Verzerrung und damit die nötigen Samples auszurechnen ist Berechnung auf Pixelebene in HW nötig oder so genanntes RIP-Mapping (ist aber viel zu aufwändig).

    Mein Tipp: nimm den Kram einfach raus. Soweit ich weiß, ist es nirgends implementiert. Wenn man etwas zu einem vertexbasierendem AF schreibt, dann lieber einen seperaten Techartikel, der das ganze richtig erklärt.
    Alles andere verwirrt die Leser nur.

    AthlonXP 1700+ JIUHB @1,35V
    EPOX 8K3A+
    SBLive!
    2x80er WD800BB
    WaKü

    SEIJIN.DE Redakteur

    Einmal editiert, zuletzt von Robbitop (26. September 2006 um 13:28)

  • Hallo!
    --
    Also ich gehöre zu den unwissenden durch diesen Artikel verwirrten Lesern. Ich hab da mal eine Frage. Nur so rein prinzipiell.
    --
    Anisotropisches Filtern is doch mit einem extremen Rechenaufwand verbunden, oder net? Oder gibts da auch wieder verschiedene - wie soll man sagen - Rechenmodelle mit unterschiedlichen Komplexitäten?
    --
    Ich weiß noch damals zu TnT2-Zeiten wo jeder Dreckschip anisotropisch filtern konnte aber jeder normale Mensch diese Funktion ausgeschaltet hatte weils nur zu Standbildern führte...

    cu

    It's nice to be a Preiß - but it's higher to be a Bayer.

  • Also wir haben zum Thema Texturfilterung ein paar lesenswerte Artikel- Vor allem den hier: http://www.3dcenter.de/artikel/grafikfilter/

    Die TNT konnte noch gar kein richtiges AF. Damals war AF nicht wirklich festgelegt und jeder konnte für Erreichung dieses Checklist Features machen was er wollte. Die PVR Serie2 war IIRC die erste GPU, welche richtige anisotrope Texturfilterung beherrscht. Danach erst NV10.

    Mathematisch anspruchsvoll ist die Berechnung der Line-of-Anisotropy. Hier wird die Anzahl der nötigen Samples abhängig vom Blickwinkel ermittelt. Aber das geht in Hardware in einem Takt (dank dedizierter HW). Das kostet aber Transistoren (deswegen ist es ja auch so teuer für ein breites Spektrum an Winkeln um die Z Achse eine brauchbare Rechnung für LOA zu bekommen...daraus resultiert die winkelabhängige anisotrope Filterung bei NV40/G70/R3xx/R2xx/R4xx).
    Außerdem kostet AF abhängig von der verwendeten Sampleanzahl pro Texel Füllrate.

    AthlonXP 1700+ JIUHB @1,35V
    EPOX 8K3A+
    SBLive!
    2x80er WD800BB
    WaKü

    SEIJIN.DE Redakteur

  • ernesto.che 22. Oktober 2018 um 10:17

    Hat den Titel des Themas von „Anisotrope Filterung @ VSA-100 – ja oder nein?“ zu „Anisotrope Filterung @ VSA-100 - ja oder nein?“ geändert.