Hä wie jetzt. *bfg* [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : Hä wie jetzt. *bfg*

Labberlippe

2001-12-17, 13:51:33

http://216.234.188.13/main/article.php?sid=2173

Gruss Labberlippe

PS: Bin schon auf Deinen Test gespannt Leonadis.

Leonidas

2001-12-17, 14:00:49

Naja, ATi-TruForm gegen nVidia-NO-TruForm verglichen. Da ist es logisch, das Unterschiede herauskommen. Wenn die Unterschiede auch ohne TruForm vorhanden sind, reden wir weiter :-).

Andre

2001-12-17, 14:02:10

Versteh ich jetzt nicht ???
Das TruForm ein abrunden verursacht und dies besser als ohne TruForm ist, leuchtet doch wohl ein.
Was möchten die mir jetzt sagen ?

Andre

2001-12-17, 14:02:35

Oop, Leo, same idea :)

tikiman

2001-12-17, 14:14:47

Um´s Truform geht´s da doch gar net, sondern um die Textur-Qualität.

Aber es ist wieder mal so ein krampfhafter Vergleich, wo minimale Unterschiede mit der Lupe gesucht werden...wem fällt sowas in einem laufenden Spiel den tatsächlich auf?! Auch ob getruformt wird oder nicht ist doch letztlich völlig schnuppe, solche kleinen Details sieht man vielleicht hinterher mal auf einem Screenshot, aber doch nicht während der Action?! Und das sage ich als stolzer Besitzer einer R8500... ;)

Labberlippe

2001-12-17, 14:28:31

Wobei es bei den Bericht nicht um Truform geht, sondern darum das nVIDIA das Bild "unschärfer" stellt ums so schneller zu sein.

Wobei ich ehrlich sagen muss mir der ganze Artikel mehr spanisch vorkommt.

Aber zum genaueren Betrachten wäre der Bericht ohne TruForm sicher was wert.
Denn würde dieser Effekt auch ohne TruForm eintreten, dann könnte man dies als Cheat sehen.

Wobei die OpenGL immer eher abfragt wie die Treibersettings eingestellt sind.
Hat nVIDIA Standartmässig z.B. das Load schwächer eingestellt, dann kann man auch nicht von einen 100% Cheat sprechen.
Allerdings dürften dann die Benchergebnisse auch nicht mehr so gewichtet werden.

http://216.234.188.13/main/reviews.php?op=showcontent&id=25&page=9

Bei diesen Bild kommt mir die R8500 auch schärfer vor, das sieht man an den Gitterstäben.
Auch hatte Leonadis im damaligen Radeon Review gegen die GeForce2 im MDK2 festgestellt das die Radeon (Die Alte) je nach Game schärfer zeichnet.

Gruss Labberlippe

Razor

2001-12-17, 14:41:03

Also was ich an diesem 'Vergleich' vermisse sind:
- Game-Einstellungen
- Treiber-Einstellungen
- Feature-Einstellungen
oder besser überhaupt irgendwelche Angaben über die zugrunde liegenden Konditioen...

So sieht es so aus, als ob bei der Radeon anisotrope Filter zugeschaltet wurden, was man besonders an dem Gras erkennen kann, bei dem der Boden schon fast 'ünerschaft' dargestellt wird...
Hmmm...

Nicht sonderlich Aussagekräftig, dieser 'Vergleich'...
(ein gutes Beispiel, wie man es NICH machen sollte ;-)

Ach ja, Leo, wie steht's mit Deinem R8500 vs. gf3 Test ?
;-)

In diesem Sinne

Razor

Xmas

2001-12-17, 17:30:43

Toll, ich bekomm da nur "File not found" :(

aths

2001-12-17, 17:34:49

same here.

Labberlippe

2001-12-17, 17:39:31

Hmm ich jetzt auch.
:-( Komisch wobei 3dwin ja auf einen neuen Server umgezogen ist, da dürfte es noch troubles geben.

Gruss Labberlippe

Thowe

2001-12-17, 20:19:50

wart ... :(

Quasar

2001-12-17, 21:35:11

Geht jetzt beides wieder...

Was die Unterschiede in den Screens aus dem ersten Link angeht, so sehe ich bis auf das weiße Kästchen, was nVidia dreisterweise mit nem roten Kreuz darstellt, ehrlich gesagt, keine Unterschiede, bis auf die jedesmal leicht verschiedene Position von Mr. Sam Serious....

(ok, die zus. Polygone durch ATis n-patches seh' ich schon....aber sollte das Raumschiff überhaupt rund sein an dieser Stelle? nur eine Ecke ohne n-patches kommen mir doch etwas wenig vor, als das man hier von absichtlicher Rundung sprechen könnte...)

Was den Mast aus Max Payne angeht, so ist das ein bekanntes Feature des GF'schen Multisampling. Alpha-Texturen werden nicht ge-AA'ed...

Razor

2001-12-18, 02:58:35

Sind keine Alpha-Texturen, Quasar.

Also die MaxPayne Shots hatten wir doch schon mal in 'nem anderen Thread, oder ?
Hmmm...

Ich hab' damals einen 'Performance'-Shot (ohne aniso ;-) mit meiner gf3 gemacht und wohl doch gezeigt, daß das AA um einiges besser aussieht, als bei 3DWIN gezeigt und durchaus mit dem AA der Radeon zu vergleichen ist. Was die Schärfe der beiden Shot's angeht, nehmen sie sich nichts, außer natürlich der untere Teil des Mastes, der aufgrund des fehlerhaften AA's natürlich auch nicht sonderlich dolle aussieht.

In diesem Sinne

Razor

P.S.: Irgendwie gehört 3DWIN bei mir zu den 'weniger besuchten' Seiten, weil das gezeigte irgendwie kaum nachvollziehbar ist und meist auch wichtige Angaben fehlen... aber jedem das Seine, gell ?
;-)

aths

2001-12-18, 03:52:46

Ich habe dem Autor des Artikel auf 3dwin folgende Mail geschrieben:

Du schreibst in einem Artikel:

"Der GeForce 3 (TI500) als auch der Radeon 8500 verwenden Hardwareseitig das
Multi-Sampling Anti-Aliasing."

und

"Die von ATI "SmoothVision" getaufte Anti-Aliasing-Technologie setzt wie
auch NVidia's GeForce 3 auf Multisampling."

Nur GF3 verwendet Multisampling. Alle anderen Karten nutzen Supersampling.
Dabei nutzen Voodoo4/5 und Radeon8500 einen Multisample-Buffer. Das hat aber
nichts mit Multisampling zu tun. Man kann Supersampling mit einem größeren
Framebuffer oder mehreren normalen Framebuffern (Multisample-Buffer)
verwirklichen. Der Unterschied besteht eigentlich nur in der Adressierung
der Subpixel.

Supersampling geht auf die Füllrate (und damit auch Speicherbandbreite),
Multisampling jedoch nicht auf die Füllrate (und nur auf die
Speicherbandbreite). Je nach Implementation des Supersampling-Verfahrens
wird mehr oder weniger Speicherbandbreite gebraucht. Die Multisample-Buffer
Technik (bei Voodoo heißt dieser ja T-Buffer) bringt hier Vorteile. Für die
optische Qualität ist das nicht entscheidend.

Du testest bei Max Payne eine Szene, in der die GF3 die Kante nicht glättet.
Das liegt einfach daran, dass er Multisampling verwendet.

Multisampling glättet nur Polygonkanten, aber keine Texturen. Bei diesem
Gitter auf dem Screenshot handelt es sich um eine Alpha-Textur. Da eine
Textur nicht geglättet wird, bleiben die Treppen. Da kann der GF noch so
hoches FSAA bekommen. Um die Texturen zu verbessern, braucht er den
anisotropen Filter. Wie du bemerkt hast, sind die Treppen dann auch weg.

Hier ist auch der Grund zu suchen, dass der Radeon schärfere Bilder liefert.
Es liegt NICHT daran, dass der GF3 mit weniger hoch aufgelösten Texturen
Performance heraus schinden will. Sondern daran, dass Radeon Supersampling
verwendet. Durch diese Überabtastung, die auch die Texturen berücksichtig,
kann der LOD-Bias gesenkt werden. Das macht schärfere Texturen. Würde beim
GF3 der LOD-Bias gesenkt werden, käme es zu Texture Shimmering (auch bekannt
als Texture Aliasing).

mfg, aths

Razor

2001-12-18, 04:40:30

Da sollte aths seine Artikel-Mail vielleicht noch mal korrigieren !
Habe mir jetzt noch mal die Mühe gemacht, den gleiche Bildausschnitt auf meiner gf3 zu reproduzieren...
(das war hart, vor allem diese hoffnunglos überzogenen Gammawerte ;-)

Mein Shot ist, wie auch der von der R8500, in 1024x768x32 OHNE Aniso mit 4xFSAA, nicht Nouncunx !
- max Details
- 32-Bit Texturen / Trilineare Filterung
- InGame-Antialiasing Off / Fogging On

Möge mir doch jetzt bitte jemand sagen, wo hier die wahnsinnigen Unterscheide zu finden sind.

Vor allem aber bitte auch, wie es sein kann, daß die gf3 sehr wohl die 'Stufen' glättet, obwohl es ja Alpha-Texturen sein sollen. Entweder kann sie diese doch glätten (was ich eher nicht so sehe ;-) oder es sind schlicht keine...

Wie dem auch sei, die Herren Tester sollten lieber noch mal die Konfiguration Ihrer Rechner überprüfen, bevor sie irgendwelche abstrusen Rückschlüsse ziehen.

In diesem Sinne

Razor

Hier also der Shot, unkomprimiert:
(der ohne Kreis -unten- ist übrigens der von meiner gf3, wer's nicht erkennen sollte ;-)

Razor

2001-12-18, 17:55:22

Naaaaaa ?
Hat's Euch die Sprache verschlagen ?
;-)

Razor

aths

2001-12-18, 22:58:14

Razor,

hättest du dir vor dem Abschicken mal den Screenshot genau angesehen, hättest du mir nicht "empfohlen", die Mail zu korrigieren. Es ist ganz offensichtlich, dass diese Strebe *besser* geglättet ist, als die Kanten. Damit kann nicht das MSAA dafür verantwortlich sein. Demzufolge bleibt nur die andere Möglichkeit der Alpha-Textur.

Vermutlich hast du in der Registry oder sonstwo anisotropen Filter erzwungen. Vielleicht solltest du das mal überprüfen, bevor du irgendwelche abstrusen Rückschlüsse ziehst.

Xmas

2001-12-19, 00:31:26

Razor, es gibt einen Unterschied zwischen Alpha Test und Alpha Blending. Schon in dem Bild auf 3dwin sind die Gitterstäbe geglättet, nur nicht so gut wie auf deinem Shot, was wohl mit dem gewählten Texturfilter zusammenhängt.
Interessant ist es auch, dass die Gitterstäbe in der falschen Reihenfolge gerendert wurden (die vorderen zuerst), was hier aber kaum auffällt.

Razor

2001-12-19, 00:59:27

Also irgend jemand sollte aths mal...
;-)

Noch einmal: KEIN aniso !
(im Game Trilinar, was aniso automatisch ausschließt und in der Registery OFF)

Habe jetzt auch mal besagten Ausschnitt vergroßert und dieses unfairer weise gegen das komprimierte Bild der Radeon gesetzt. Die Vergrößerung ist dem orginalen Bitmap entnommen, aber man kann gut erkennen, daß die 'Kante' von der Radeon ein wenig besser AA't wird, die 'Textur' dagegen aber KEINEN Unterschied aufweist. Jeder mit 'ner gf3 kann das nachvollziehen...

Es gibt echt Leute, die nicht einmal ihren Augen trauen !
Und sich wohl lieber in der Theorie oder eigenen Vermutungen aalen...
(und das, wo doch die Wissenschaft nur 'glaubt', was sie 'sieht')
;-)

In diesem Sinne

Razor

P.S.: Vielleicht hat ja noch mal jemand anderes was dazu zu sagen, aber wenn außer aths keiner mehr was dazu sagt, dann ist das Thema für mich erledigt... ICH halte mich lieber an Fakten (zumindest in diesem Fall ;-)

Razor

2001-12-19, 01:07:16

@Xmas

Das mit dem Alpha Test und dem Alpha Blending mußt Du mir nochmal erklären, wenn es Dir nichts ausmacht...
Bitte !!!

Und inwiefern kann man einen Texturfilter wählen ?
Meinst Du die 'trilineare' und/oder die 'anisotrope' Filterung ?
Hmmm...

Könntest Du dazu nochmal etwas genauer werden ?
Würde mich ja gerne eines besseren belehren lassen, aber zur Zeit stehe ich irgendwie auf dem Schlauch...

Was ist jetzt genau anders, bzw. schlechter oder unschärfer, als bei der Radeon ?
???

Ratlos

Razor

aths

2001-12-19, 06:31:52

Razor,

ich wüßte gerne, die du den Screenshot auf 3dwin erklärst, der bei der GF3 eindeutig Treppen zeigt.

Des weiteren wäre ich verbunden, diesen Ausschnit von mir ein mal mit, und einmal ohne anisotropen Filter zu sehen.

Zu guter Letzt würde ich gerne wissen, wie du bei deinem Screenshot die sehr glatte Kante erklärst. Die Polygonkante in der Nähe ist deutlich schlechter geglättet.

Razor

2001-12-19, 15:51:45

Ich mag ja nun nicht DER '3D-Profi' sein.

Aber mir abzuerkennen, daß ich den Unterscheid zwischen aniso und nicht-aniso nicht kenne, ist schon hart...
Und wie, um himmels Willen, soll ich erklären, was 3DWIN da verbockt hat ?
Tut mir leid, aber diese Seite hat sich für mich eindeutig disqualifiziert !

Habe mir nochmals sehr viel Mühe gegeben und zwei weitere Vergleiche gemacht.
(diesmal reine intern-Vergleiche meiner gf3)

In diesem Sinne

Razor

Hier also ein Shot mit generellem aniso-Vergleich:
(links ohne aniso, rechts 64tap aniso)

Razor

2001-12-19, 15:54:48

Und nun noch DER entlarfende Detail-Vergleich:
(oben ohne aniso, nicht falsch verstehen ;-), unten 64tap aniso)
*hmpf*

Razor

2001-12-19, 20:58:58

Ooooch kommt doch Leute...
:-(

Hab' mir doch nun echte Mühe gegeben, oder ?

Razor

Quasar

2001-12-19, 22:02:08

Was sollen "die" denn noch groß sagen.... ;)

Razor

2001-12-20, 01:29:10

Tja, Quasar...
Vielen Dank, daß Du wenigstens was gepostet hast !

Da werden hier wilde Verdächtigungen und Ähnliches zum Bestem gegeben und wenn man dies als Nichtig 'entlarvt', dann herrscht Stille... Na ja, aber keine Antwort ist diesem Fall auch eine Antwort !

Aber ist schon interessant, daß es zumindest doch noch möglich ist, hier gewisse Leute 'zum Schweigen' zu bringen.
Hätte nicht gedacht, daß dies möglich ist !

Wie auch immer, DIESER Fall scheint somit geschlossen, gell ?
;-)

Bis denne

Razor

aths

2001-12-20, 01:41:24

Razor,

ich habe nicht so viel Zeit wie du für das Forum. "Nebenbei" studiere ich noch, und ausserdem habe ich ein neues Projekt in der Pipeline. Antworten kommen schon noch, wenn du etwas Geduld aufbringst.

aths

2001-12-20, 14:34:56

Razor,

anstatt eine Vergrößerung als verlustbehaftetet JPG anzuhängen, hättest du es besser in normaler Auflösung (man kann es ja selbst noch skalieren) verlustfrei komprimiert angefügt.

Das untere Bild hat 4x Anti-Aliasing, das obere 2x aus. Darf man nach dem Sinn fragen? Leider hast du aus dem Screenshot nicht die genau gleichen Teile ausgeschnitten. Also musste ich mir die Mühe machen und beide auf den gleichen Ausschnitt trimmen, um sie per Differenzbild direkt vergleichen zu können. Dabei fiel natürlich das eine vertikale lange Objekt im Hintergrund auf. Ansonsten waren nur einige Pixel an bestimmten Polygon-Kanten (und nur dort!) zu sehen. Das weist auf unterschiedliches MSAA hin und ist auch das einzig entlarvende (wird btw mit v geschrieben) an deinen Screenshots.

Zu dem Bild, was auf 3dwin gepostet wurde. Ungefähr diesen Winkel habe ich mal nachgestellt (siehe Anhang.) Man erkennt eine ähnlich schlechte Glättung, die der Screenshot auf 3dwin zeigt: Noch zwei Abstufungen pro Treppenstufen, das wars. Dieser unschöne Effekt verschwindet, wenn die Textur vergrößert wird. Es sind dabei etwa so viele Abstufungen zu sehen, wie die Strebe auf deinem Screenshot hat.

Der schlechte Glättungs-Effekt lässt sich auch dann erzeugen, wenn das LOD-Bias richtig eingestellt wurde. Mit einem trilinearen Filter sollte er vermieden werden. Es sei denn, der LOD-Bias ist zu gering.

Weiter oben fragst du: "Was ist jetzt genau anders, bzw. schlechter oder unschärfer, als bei der Radeon ?" Radeon macht Supersampling und passt das LOD-Bias entsprechend an. Daher werden niedrigere MIP-Stufen verwendet, was im Spiel auf schärfere und gleichzeitig glattere Texturen hinaus läuft. (Leser des letzten 3D Center Artikels hätten das gewusst.)

Deine Theorie bezüglich Alpha finde ich toll. Natürlich glättet MSAA die Texturen nicht, aber wozu ist bitte ein bi- oder trilinearer Filter da? Enhält eine Textur neben RGB noch A, kann Alpha Blending durchgeführt werden, was auf fein abgestufte Transparenz hinaus läuft. Witzig finde ich, wie du diese Streben der 4x Kantenglättung zuschustern willst - wo sich doch mindestens *sechs* Abstufungen ausmachen lassen, obwohl mit 4 Subpixeln natürlich nur fünf Abstufungen möglich sind.

Razor

2001-12-20, 14:47:38

:bounce::lol::rofl::lol::bounce:

aths begreifts einfach nicht und will mir jetzt soagr noch Fälschung unterjubeln...
Ein offensichtliches Silmittel von Leuten, die mit ihren eigenen Vorstellungen nicht mehr klar kommen.

JEDER der eine gf3 sein eigen nennt (und somit nicht auf die Entwicklung abstruser Theorien angewiesen ist ;-) kann dies selber in der Praxis nachvollziehen. Vielleicht ist der 'verwirrte' aths dann ja vom Gegenteil zu überzeugen, wenn's nicht vom Razor kommt.

In diesem Sinne

Razor

P.S.: Für mich hat sich das Thema nun endgültig erledigt, wenn nicht was von Leuten kommt, die etwas Vernünftiges zum Besten zu geben haben !
;-)

aths

2001-12-20, 16:41:19

Razor,

wenn du nicht in der Lage bist, meinen Ausführungen zu folgen, könntest du mich bitten, sie anders zu formulieren. Ich zeigte, dass du wohl unterschiedliche MSAA-Methoden in beiden Bildern genutzt hast und habe dir außer offensichtlichen Tatsachen nichts "unterstellt". Allerdings vergaß ich, das Bild anzufügen, was hier nun folgt. Darauf bist du gar nicht eingegangen. Hast du mein Posting überhaupt komplett durchgelesen?

Darin stellte ich eine These auf, wie der Shot auf 3dwin zu erklären ist. Etwas Theorie kann dabei nicht ausbleiben. Dabei richtete sich nichts gegen dich. Im Gegenteil, man konnte herauslesen, dass die Bildqualiät auf dem 3dwin-Screenshot einer falschen Grafikeinstellung des Testers angelastet wird.

Des weiteren erklärte ich dir einen Irrtum deinerseits und beantwortete eine deiner Fragen.

Vielleicht findest du die Ausführen etwas verwirrend, weil du bei den vielen Fachtermini keine Lust hast, dem Sinnzusammenhang zu folgen. Daraus zu schließen, ich sei verwirrt, nenne ich einfach nur überheblich. So schreibst du: "Vielleicht ist der 'verwirrte' aths dann ja vom Gegenteil zu überzeugen, [...]" Ist dir wenigstens selbst klar, von welcher Sache ich "vom Gegenteil" überzeugt werden sollte?

aths

2001-12-21, 17:50:31

Originally posted by Razor
Na ja, aber keine Antwort ist diesem Fall auch eine Antwort !

Aber ist schon interessant, daß es zumindest doch noch möglich ist, hier gewisse Leute 'zum Schweigen' zu bringen.
Hätte nicht gedacht, daß dies möglich ist !

Interessant.

Razor

2001-12-22, 12:45:36

"P.S.: Für mich hat sich das Thema nun endgültig erledigt, wenn nicht was von Leuten kommt, die etwas Vernünftiges zum Besten zu geben haben !"

tornado

2001-12-22, 20:04:39

ziemlich lächerlich Razor....

aths

2001-12-24, 15:18:32

Razor,

wo bleibt dein Elan? Erst provozierst du: "Aber ist schon interessant, daß es zumindest doch noch möglich ist, hier gewisse Leute 'zum Schweigen' zu bringen."

Als dann eine Antwort kommt, schreibst du: "aths begreifts einfach nicht und will mir jetzt soagr noch Fälschung unterjubeln..." Wo, bitte, soll ich das in dem entsprechendem Posting versucht haben? Zitat, bitte!

Du schreibst weiter: "Vielleicht ist der 'verwirrte' aths" Nun, du bist schon durch Begriffe wie "Detailtexturen" zu verwirren gewesen. Vielleicht häte man nicht erwarten sollen, dass du einer tiefer gehende Erörterung eines 3D-technischen Problemes folgen willst. Zumal du dich über Theorie erhebst ("abstruser Theorien", selber hattest du ja keine Erklärungen anzubieten.) Na jedenfalls schreibst du weiter: "dann ja vom Gegenteil zu überzeugen, wenn's nicht vom Razor kommt."

Ich weiss bis heute nicht, von welchem Gegenteil? Wenigstens kamen von mir überhaupt Argumente (ob nun gute oder schlechte, sei dahingestellt) während du nun schreibst: "Für mich hat sich das Thema nun endgültig erledigt, wenn nicht was von Leuten kommt, die etwas Vernünftiges zum Besten zu geben haben !"

Komisch. Wenn ich in der Tat unvernünfiges schriebe - übrigens siehst du schon viel geringere Unhöflichkeiten als Beleidigung an, und hast Zeit und Energie lange Traktate zu schreiben die nachzuweisen suchen, dass ich der provokante Bösewicht sei - sollte das Gegenteil doch sehr einfach belegbar sein. Wenn du wenigstens selbst wüsstest, welches Gegenteil überhaupt.

Razor, ich muss schon sagen, dass ich enttäuscht bin. Erst brichst du hier völlig ohne Not einen Streit vom Zaun, dann stiehlst du dich davon. Noch dazu begehst du den Fehler, mit grosskotzigen Sprüchen die Lage so gestalten zu wollen, dass ich hier ohne Gesichtsverlust nicht heraus komme. (Ich würde ja nichts vernünftiges beisteuern.)

In diesem Thread suchte ich eine Erklärung für den 3dwin-Screenshot, die ich nun auch anbieten konnte, und keinen Streit. Den du in deiner blinden aths-allergischen Art leider angefangen hast. (Es fing schon an mit dem naseweisen Spruch "Da sollte aths seine Artikel-Mail vielleicht noch mal korrigieren !" Obwohl die Streben eindeutig Alpha-Texturen sind, ob du das nun einsehen willst oder nicht.)

Zusammenfassend muss ich sagen, Razor, dass du es einem wirklich einfach machst. Doch erwarte nicht in Zukunft, dass ich mich auf infantile Einwände einlasse. Für mich ist das Forum eine Plattform, um ernsthafte 3D-technischen Fragen zu besprechen.

Razor

2001-12-24, 15:49:36

@aths

Schau doch mal bitte in Dein PM !

Razor

Pengo

2001-12-24, 16:04:13

Razor, diesmal verstehe ich wirklich deine Aufregung nicht.

Du schriebest:

Da werden hier wilde Verdächtigungen und Ähnliches zum Bestem gegeben und wenn man dies als Nichtig 'entlarvt', dann herrscht Stille... Na ja, aber keine Antwort ist diesem Fall auch eine Antwort !

Du kannst nicht erwarten das aths ganzen Tag im Forum hockt und auf deine Postings wartet. Du solltest ihm zumindestens 24h Zeit für die Antwort geben, du bist selbst oft zu beschäftigt um Zeit für das Forum zu finden, also kannst du es schlecht von anderen erwarten. Mir gefällt der Ton von aths auch oft nicht, aber ich finde du solltest ihn zumindestens ausreden lassen, auch wenn er dir was unterstellt hat, eine direkte Beleidigung habe ich nirgendwo gesehen.

Razor

2001-12-25, 10:26:29

@Pengo

Von 'Beleidigungen' hab' ich auch nichts geschrieben...
;-)

Aber hast' schon recht, ev war ich diesmal 'etwas' zu ungeduldig !
(kann schon mal passieren und werd' mich bessern ;-)

Bis denne

Razor

aths

2001-12-25, 15:23:30

Razor,

ich denke, wir können beide friedlich im Forum miteinander umgehen. Nach deiner PM bin ich überzeugt, dass du es ebensowenig wie ich auf Streit angelegt hast. Verbrauchen wir unsere Kräfte lieber, um das bekannte 3Dcenter-Forum-Niveau zu halten.

Es liegt mir viel daran, zu wissen, ob meine Erklärungsversuche verständlich sind. Daher würde es mich freuen, wenn du deine Meinung zu meinem 3dwin-Screenshot-Erklärungsversuch schreibst. Falls dieser Erklärungsversuch undurchsichtig ist, würde ich ihn neu formulieren.

Andre

2001-12-25, 16:04:24

Razor und aths:

Schön, dass ihr Euch einigen konntet - vorbildlich würde ich sagen.

Thowe

2001-12-25, 16:20:22

es freut :)

Razor

2001-12-25, 20:02:09

Hervorragend aths !
;-)

Finde ich sehr angenehm, wieder vernünftig miteinander umzugehen.
So ein dummer Streit belastet auch nur und Du hast völlig recht, daß wir unsere Kräfte lieber auf die wirklich hohe Qualität dieses Forums konzentrieren sollten.

Na, dann freue ich mich auf bereichernde Diskussionen !

-

Und nun zum Thema:

Ich denke nicht, daß Du Dich falsch oder unverständlich ausgedrückt hast. Aber wie ich Dir ja zeigen konnte hat bei 3DWin irgend etwas mit dem sonst guten (und der Radeon vergleichbaren) Qualität des Alpha-Blendings 'verbockt'. Habe nochmals versucht das selber nachzuvollziehen, bin aber irgendwie zu keinem Schluß gekommen.

Erst einmal habe ich festgestellt, daß es eine Möglichkeit gibt, daß Alpha-Blending komplett zu deaktivieren. Es gibt da den D3D-Parameter 'AnisotropicLevel' der eigentlich dafür zuständig ist, wie der Name ja schon sagt, den anisotropen Filter zu definieren. Per Default ist dieser auf '1' gesetzt und bedeutet so viel wie 'Application Controlled'. Werte größer als '1' bestimmen die drei möglichen Level 8/16tap, 16/32tap und 32/64tap (bilinear/trilinear). Wird dieser Wert aber auf '0' gesetzt, wird damit offensichtlich nicht nur das anisotrope Filtern per Applikation verhindert (habe ich mit MP ausprobiert), sondern auch das Alpha-Belnding deaktiviert.

Die Level 2,3 und 4 haben hingegen keine Auswirkung auf die 'Streben', somit konnte Deine Vermutung, dies auf das Alpha-Blending zurück zu führen durchaus richtig sein. Unverständlich ist hingegen, wie 3DWin diesen Shot zustande gebracht hat, dessen 'Streben'-Darstellung ich auch durch eine Justierung des LOD-Bias (D3D-Parameter 'LODBIASADJUST') nicht reproduzieren konnte.

Schon merkwürdig das Ganze, aber ev fällt Dir ja noch was dazu ein...

Bis denne

Razor

Zur Dokumentation dessen habe ich nun einen Shot-Vergleich dazu gestellt (JPEG95)

Gesamtshot: gf3 AnisotropicLevel = 0 (Alpha-Blending Aus ?)
Detail1: gf3 AnisotropicLevel = 0
Detail2: gf3 3DWIN
Detail3: gf3 AnisotropicLevel = 1
Detail4: r8500 3DWIN

aths

2001-12-25, 20:41:37

Razor,

jetzt sollte geklärt sein, dass die Streben tatsächlich eine Alpha-Textur sind. Weil diese bei aktivierter Kantenglättung nicht (unbedingt) geglättet werden.

Nun zeigt der 3dwin-Screenshot eine, wenn auch schlechte, Glättung. Offenbar wurde die Textur mindestens bilinear gefiltert. Deine GF3-Screenshots sehen anders aus als die auf 3dwin. Soweit die Fakten.

Nun die Vermutungen. Die gute Glättung der Streben wird, das scheint nun relativ sicher, durch den anisotropen Filter erreicht. (Diese Vermutung äußerte ich ja schon mal.) Dieser Filter kam beim 3dwin-Screenshot auf jeden Fall nicht zum Einsatz.

Dein Bild ohne dem AF zeigt auf einer Strebe eine miese, auf einer anderen gar keine Glättung. Das sollte dann entweder vom LOD-Bias abhängen, oder der Unterschied zwischen bi- und trilinearer Filterung darstellen.

Was kann man festhalten?

- Bei solchen Screenshot-Vergleichen sollte der Verfasser mit den genauen Einstellungen heraus rücken (wie du weiter oben schon gefordert hast.)

- Der Nachteil durch MSAA vs. SSAA ist mit dem AF einigermaßen, wenn auch nicht ganz, ausgleichbar.

- Ohne AF hat man mit der GF3 gegenüber dem SSAA-Verfahren dementsprechend das Nachsehen, sobald Alpha-Texturen ins Spiel kommen.

- Screenshot-Vergleiche sollten praxisnah geschossen werden. Wenn das Spiel mit AF eine vernünftige Performance bietet, sollte man die Bilder mit aktiviertem AF aufnehmen.

Ich halte meine Mail an den 3dwin-Artikel-Verfasser noch immer in allen Punkten für gerechtfertigt, auch wenn das rechthaberisch klingt. Leider erhielt ich bislang keine Antwort.

Jedenfalls ist die zweifelhafte Kantenglättung in einer Textur, wie von 3dwin dargestellt, kein Muss. Dass er dennoch gegenüber dem R8500 ein wenig im Nachteil ist, liegt am MSAA. MSAA bringt bei der Abwägung Textufilterung/Kantenglättung aber auch Vorteile. Somit gibt es hier in meinen Augen keinen "Sieger".

Razor

2001-12-26, 03:24:31

Und das ist genau das, was ich nicht verstehe, aths...

-

Du sagst, daß ein anisotroper Filter zum Einsatz kam. Wie ist das zu verstehen ?
AnisotropicLevel=1 bedeutet eigentlich KEINE bzw. eine durch die Applikation gesteuerte anisotrope Filterung. Somit dürften in dieser Einstellung lediglich die 'Standard'-Filter zum Einsatz kommen. Hmmm...

Hier noch mal die exakten Einstellungen für Detail1/3 (außer besagten AnisotropicLevel):

In Game: Trilinear (KEIN anisoFilter), 32Bit-Textures, Fogging On, DoubleBuffer, Antialiasing Off, MaxDetails
Treiber: 4xOGMS (Antialiasquality 3), BestImagequality (LODBiasAdjust 0)

Offenbar handelt es sich bei den 'Stufen' also tatsächlich um Alphatexturen, da ja, wie Du schon sagtest, die 6 Abstufungen dafür sprechen (wozu soll dann eigentlich noch AA sinnvoll sein ?). Warum oder besser wie soll dies auf den AnisotropicLevel 1 zurück zu führen sein ?

Wie ist es dann zu erklären, daß der AnisotropicLevel 0 auch den trilinearen Filter deaktivert und offenbar nur biliniear oder gar nicht gefiltert wird ?

Fragen über Fragen...

Persönlich bin ich der Meinung, daß hier keine anisotrope Filterung im Spiel ist.
Aber bitte korrigier mich, wenn ich da falsch liege !

Und eines konnte ich zum Schluß dann doch noch feststellen: Wenn AnisotropicLevel 1 (Treiber-Default) mit der InGame-Einstellung Biliniearer Filter kombiniert wird, dann kommen tatsächlich die 3 Abstufungen heraus, die bei 3DWIN gezeigt wurden.

So bin ich denn der Meinung, daß man bei 3DWIN schlicht mit biliniarem Filter 'verglichen' hat !

-

Bei der 'Kante' kann ich noch immer keinen Unterscheid zwischen dem MSAA der gf3 und dem SSAA der R8500 ausmachen. Habe dann auch noch mal 'nen Vergleich mit der AntialiasQuality 5 (4xOGSS) gemacht und konnte auch hier keinen Unterschied feststellen (in der obigen Detail-Betrachtung wohlgemerkt, in anderen Bildbereichen ist der Unterschied sehr deutlich !).

-

In dem Punkt der Parameterangabe für solche Bildvergleiche stimme ich Dir somit uneingeschränkt zu. Das ist dann ja tatsächlich nur ein Apfel/Birnen-Vergleich, der dort gemacht wurde und hat somit überhaupt keinen Aussagewert...

In dem Zusammenhang sollte man dann die SeriousSam-Screen-Vergleiche dann allerdings auch mit einem fettem Fragezeichen versehen, da dort sicher auch so einiges nicht ganz gestimmt hat.

-

Ob nun Deine Mail an 3DWIN gerechtfertigt war, oder eben nicht, mag ich nun nicht mehr beurteilen, denn es sind einfach zu viele Fragen offen, die 'Erhellung' benötigen. So langsam scheinen mir aber die Wechselwirkungen der einzelnen Einstellungen (InGame und Treiber) immer klarer, auch inwieweit sie tatsächlich die Gesamtqualität der 3D-Darstellung beeinflussen.

Wäre Dir aber sehr dankbar, aths, wenn Du hierauf noch einmal antworten könntest, wenn es Deine Zeit zuläßt.

Bis dann

Razor

Quasar

2001-12-26, 04:43:17

In einem von dir so wenig geliebten "tuner" sind die Bezeichnungen für die Werte des angewählten Texturfilters enthalten....

Da ich nicht ganz sicher bin, ob es nicht ein- und dasselbe ist, formuliere es ich mal als Frage:

Meinen die Optionen "Deaktiviertes Alpha Blending" und "nearest Point Filtering" das Gleiche?
Dies ist nämlich offenbar die Bezeichnung für die "0"-Einstellung der ANISOTROPICLEVEL 0.

P.S.: Schön, daß ihr euch wieder vertragt!

Razor

2001-12-26, 04:49:31

Kann nicht sein, Quasar...
(nun verwirr mich jetzt nicht völlig ;-)

LODBIASADJUST 0 ist die 'BestImageQuality'-Einstellung im Treiber unter 'MipMap Detail Level'...

Das Deaktivieren des Alpha-Blendings tritt nur mit dem ANISOTROPICLEVEL 0 auf...
(1 ist die Default-Einstellung nach Installation)

Hmmm...

Razor

P.S.: Insofern könnte Dein "nearest Point Filtering" mit dem AnisotropicLevel 0 gleichzusetzen sein, was dann auch erklären könnte, warum dann nicht mehr trilinear gefiltert wird...

Quasar

2001-12-26, 04:52:32

Hab ich doch geschrieben, was hast du nur mit deinen Augen?

Nee, kleiner Scherz....war'n Tippfehler von mir. Hab's jetz aber korrigiert.

Marry X-Mas....(kewles Wortspiel hier...)

Razor

2001-12-26, 04:57:22

Na dann...
;-)

Happy X-Mas auch Dir !

Razor

Quasar

2001-12-26, 05:00:42

Hier noch mal zur Verdeutlichung in Screenie....

Razor

2001-12-26, 05:22:27

Danke Quasar :-(
*grmpf*

Du hast mir gerade 'ne menge Arbeit beschert !
Wollte einfach mal das 'Application-Controlled' einstellen...
Und das hat gleich 'nen ganzen Satz an Registery-Settings hinzugefügt (10 Reg's ?) und noch einige andere geändert.

Jetzt darf ich mir den Treiber gleich wieder neu installieren.
DAS ist der Grund, warum ich diese Tools so HASSE !!!
*AAAAARRRRRRGGGGHHHHH*

Auch erklärt einem Niemand, was da alles und warum gesetzt wurde...
Da kann aths dann natürlich zu recht vermuten, daß da noch irgend etwas anderes 'verstellt' oder 'eingestellt' wurde. Ich habe lieber selber die Kontrolle darüber, was genau da verändert wird.

Was mich auch noch 'verwirrt' hat, ist, daß Du das Forum im Hintergrund hattest und ich zuerst dachte, daß det Forum 'ausgerastet' ist...

Aber zumindest meine eigene Dummheit, da ich solche Tools ja sonst nicht nutze, außer um zu überprüfen, wie sich Treibereinstellungen auf die Key's auswirken...

Na ja, werd' das schon wieder hinbekommen, aber schön isses net !
*schnüff*

Bis denne

Razor

P.S.: Ich hol mir jetzt noch 'nen Bier und richte das dann noch 'mal eben'
:bier:
;-)

Quasar

2001-12-26, 05:25:22

:bier:

Na denn! Prost!

Razor

2001-12-26, 06:12:51

So, hab's jetzt wieder so, wie's sein soll !
;-)

Der AnisotropicLevel ist per Default übrigens überhaupt nicht gesetzt !
(wird dann wohl mit dem RegSetting 'ffffffff' gelichzusetzten sein, den dieses 'Tool' angibt)

Was ich aber merkwürdig fand, daß nach diesem unglückseligem Tool der AnisotropicLevel 1 mit "off, use bilinear" bezeichnet wird, was ich natürlich auch gleich getestet hab'...

Und was soll ich sagen ?
Der Unterschied zwischen 'Bilinear' und 'Trilinear' ist deutlich zu sehen !
Auch hat die Option 'Anisotropic' die entsprechende Wirkung...
(getestet mit MP, InGame-Einstellungen)

Was soll man jetzt davon halten ?
???

Hmmm...
Ist vielleicht auch schon ein bissel spät... oder früh ?
;-)

Werde jetzt wohl mal mein Bierchen austrinken und dann mal in die Heia !

Bis morgääääähhhhnnn

Razor

Ach ja...
:bier:
;-)

aths

2001-12-26, 13:06:25

Razor,

Siehe das von mir weiter oben angehängte Bild - gute Kantenglättung innerhalb einer Textur kann es auch mit dem bilinearen Filter geben. Dazu darf die Textur-Auflösung nicht zu gering sein. Hier müsste sich über das LOD-Bias eine Änderung erzeugen lassen. Spätestens bei trilinarem Filter sollte es aber in jedem Fall eine vernünftige Kantenglättung innerhalb einer Textur geben.

AF sollte eine sehr gute Kantenglättung erzeugen, BF je nach Lage. TF sollte daher immer eine merkliche Glättung liefern.

Ich dachte, AnisotropicLevel=1 aktiviert den AF. Jedenfalls ist der Unterschied in der Kantenglättung zwischen AnisotropicLevel=0 und 1 ja erheblich.

Das AA ist für Polygonkanten sinnvoll, wo eine Texturfilterung ja keine Kanten glätten kann.

Da Radeon auch beim AF nicht trilinear filtert, war es insofern schon "gerecht", dass 3dwin den GF3-Screenshot ebenfalls bilinear geschossen hat.

Da müssten sich in der Texturqualität Unterschiede feststellen lassen. Bei der Einstellung für deinen obersten Detail-Ausschnitt kannst du ja mal ein bissel in der Gegend herum laufen und nachgucken, ob überhaupt ein bilinearer Filter zum Einsatz kommt. (Man kann ja auch MIP-Mapping und sogar MIP-Interpolation ohne bilinearen Filter machen. Das hat nicht viel Sinn, sollte aber einstellbar sein.) Ich durchdenk das alles noch mal, jetzt gibt's Essen.

GloomY

2001-12-26, 14:08:46

Originally posted by Razor
In dem Zusammenhang sollte man dann die SeriousSam-Screen-Vergleiche dann allerdings auch mit einem fettem Fragezeichen versehen, da dort sicher auch so einiges nicht ganz gestimmt hat.Öhm, ich konnte der Diskussion inhaltlich nicht ganz folgen, aber ich nehme mal an, daß damit meine SS-Screenshots gemeint waren. Und da würde mich dann doch mal interessieren, in wie fern da was nicht ganz stimmt...

Quasar

2001-12-26, 14:34:14

Originally posted by aths
Ich dachte, AnisotropicLevel=1 aktiviert den AF. Jedenfalls ist der Unterschied in der Kantenglättung zwischen AnisotropicLevel=0 und 1 ja erheblich.

In diesem Falle hat nVidia glaube ich aber mal den Wortsinn von "anisotropic" auf den Kopf getroffen

an·i·so·trop·ic (n-s-trpk, -trpk)
adj.
Not isotropic.
Physics. Having properties that differ according to the direction of measurement.

Und bei trilinearem Filter wird, zumindest an dem Mipmap-Übergängen doch in "z-Richtung" ein weiterer Filter eingesetzt....also nicht mehr nach allen Seiten gleich gefiltert...

Deswegen wohl auch "Trilinear" als niedrigste Stufe der Anisotropie..

aths

2001-12-26, 15:04:55

Lt. nVidia Nomenklatur könnte man wohl trilinear auch als "8 tap" AF bezeichnen, obwohl das mein ausdrückliches Missfallen finden würde.

Der trilineare Filter ist ein isotroper, da (unabhängig vom Blickwinkel) immer je zwei mal vier Texel gefiltert werden. Natürlich kommen dabei unterschiedliche Gewichte ins Spiel. Das ist aber auch beim bilinearen Filter der Fall, der eindeutig isotrop arbeitet.

Quasar

2001-12-26, 17:32:20

Probleme: Bei sehr schrägen Flächen fällt auf, dass die Textur je nach Lage entweder in X- oder in Y-Richtung überfiltert ist.

Dies ist aus deinem Artikel über Texturfilterung, aths.

Wenn trilineare Filterung isotrop ist, wie du schriebst, wieso ist dann entweder die X- oder die Y-Richtung überfiltert?

Das könnte doch nur funktionieren, wenn der trilineare Filter in Verbindung mit den unterschiedlichen MipMap-Leveln die X- bzw. Y-Werte anders behandelt, oder?

Razor

2001-12-26, 17:41:30

Hi aths,

hoffe, daß Du und Deine Leiben ein angenehmes Mahl genießen durftet !
Wird bei Euch auch immer so kräftig aufgetischt, daß einem der Gedanke in den Sinn kommt, nie wieder essen zu wollen ?
*ächts*
;-)

Zum Thema:

So langsam kommen wir uns näher, in der Interpretation der Shots...

Habe jetzt noch mal versucht, den Unterscheid zwischen bilinearem und triliniearem Filter zu dokumentieren. Dabei ist augefallen, daß sich meine Vermutung bezüglich der inkorrrekten Bezeichnung beim RivaTuner bestätigt hat. Die Filter (BL/TL/AN) bleiben also auch beim AnisotropicLevel 1 application-controlled. Insofern sind die Werte 'ffffff', '1' und '<nicht definiert>' identisch. Sollte mal 'ne Mail an den RivaTuner-Urhaber verfassen...
;-)

Wie dem auch sei, der Geschwindigkeitsverlust ist absolut unerheblich (gerade mal ein 1/4 Frame, was dann auch auf Messungsungenauigkeiten zurück zu führen sein könnte). Insofern stimme ich Deiner Ansicht, daß mit gleichen Mitteln hinsichtlich der Bildqualität verglichen werden soll, nicht zu ! Schließlich kann man auf die Unzulänglichkeit eines Grafik-Chips keine Rücksicht nehmen, nur weil diese dazu nicht in der lage ist. Anders ist dies natürlich bei Qualitätsmerkmalen die Performance kosten, so würde ich das Zuschalten von anisotropen Filtern bei nur einem Kandidaten als absolut unzulässig ansehen. Und ich bin der gleichen Meinung wie Du, aths, daß der trilinerae Filter niemals als 8tap-anisoFilter bezeichnet werden sollte...

Werde also diesem Post folgende Darstellungen beifügen:
(links immer bilinear, rechts immer trilinear gefiltert)

1) FPS-Vergleiche
2) Copter-Shot
3) Tower-Shot

Die Shots dürften sich von selbst erklären...

Interessant ist auf jeden Fall, daß die R8500 mit 4xSV und bilinearem Filter eine ebenso gute (aber keinesfalls bessere) Darstellung in den gezeigten Detail-Shots erreicht, wie die gf3 mit 4xOGMS und trilinearem Filter. Insofern kann man es nicht unbedingt als Nachteil ansehen, daß die R8500 das trilineare Filtern nicht beherrscht. Ein Nachteil bleibt allerdings, daß der Performanceverlust bei 4xSV (oder mehr) nicht akzeptabel ist. Aber ev werden es neue Treiber-Releases richten...

Somit bin ich denn nun gespannt, was Du und natürlich auch die anderen hier (Gruß an Quasar, Xmas, nggalai und co. !) dazu sagen.

IMHO ist der Bild-Vergleich, der da bei 3DWIN gemacht wurde, definitiv NICHT zulässig.

Na, dann bin ich mal gespannt !

Bis dann

Razor

Razor

2001-12-26, 17:42:08

Jetzt der Copter-Vergleich...

Razor

2001-12-26, 17:42:49

Und schlußendlich der Tower-Vergleich...

Razor

2001-12-26, 17:57:33

@Gloomy

Das Problem ist, daß 3DWIN leider keine detaillierten Parameter preis gibt, hinsichtlich der Treiber- und der InGame-Einstellungen bei den sog. 'Bildvergleichen'. Du bist ja sicherlich ein wenig dieser Diskussion gefolgt und dürftest dann mitbekommen haben, wie schwierig es ist, die Ursache für Bildunterschiede aufzuspüren. Ist sicher auch nicht für jedermann interessant, aber ich fand's spannend, zumal ich dabei viel über die Zusammenhänge gelernt habe.

Auf jeden fall dürfte zumindest belegt sein, daß der MP-Vergleich, den Laberlippe gepostet hat (ebenfalls von 3DWIN) als nicht zulässig angesehen werden darf. Und die SS-Vergleiche sind allein schon aufgrund der Tatsache der verwendeten Truform-Technologie nicht zulässig. Sicher kann man damit auf die leichten Bildverbesserungen hinweisen, aber um daraus zu schließen, daß die BQ der R8500 generell besser ist, oder nVidia gar 'tweakt' ist dann schon sehr an den Haaren herbei gezogen und somit ist diese Gegenüberstellung dann auch hinfällig.

Wenn also beim SS-Vergleich bei der R8500 dann Truform zugeschaltet, aber wegen dem Unvermögen der R8500, dann das trilineare Filtern der gf3 auf bilinear reduziert wurde, ist auch dieser Bildverglci absolut sinnlos und damit dann auch nichtig.

Hoffe, daß ich meinen kurzen Satz dann ein wenig mit Hintergrund füllen konnte !
;-)

@aths & Quasar

Schon interessant, das Ganze, gelle ?
;-)

Auch mich hat die Verwendung von AnisotropicLevel 0 und 1 sehr verwirrt, aber schlußendlich kann man ja doch noch dahinter kommen, wie das gemeint ist. Allerdings wäre ich sehr an einer Darstellung der RivaTuner-Macher interessiert, wie sie beim Level 1 dann auf 'off, bilinear' gekommen sind...

Wirklich interessant !
Und vielleicht helfen dann ja die Copter-Shot's ein wenig...

Bis dann

Razor

Quasar

2001-12-26, 18:49:48

Originally posted by Razor

Schon interessant, das Ganze, gelle ?
;-)

Auch mich hat die Verwendung von AnisotropicLevel 0 und 1 sehr verwirrt, aber schlußendlich kann man ja doch noch dahinter kommen, wie das gemeint ist. Allerdings wäre ich sehr an einer Darstellung der RivaTuner-Macher interessiert, wie sie beim Level 1 dann auf 'off, bilinear' gekommen sind...

Wirklich interessant !
Und vielleicht helfen dann ja die Copter-Shot's ein wenig...

Bis dann

Razor

Moin Razor!

Naja, was sich der Alex vom Rivatuner gedacht hat, schätze ich mal einfach so ein, daß auf diese Weise das Menu übersichtlicher bleibt...

Was deine Screenshots angeht, so sind die doch beide mit der GF3 aufgenommen, oder?

aths

2001-12-26, 18:55:46

Quasar,

du fragst: "Wenn trilineare Filterung isotrop ist, wie du schriebst, wieso ist dann entweder die X- oder die Y-Richtung überfiltert?"

Das hängt vom Blickwinkel ab. Je nach Blickwinkel guckt man mehr in X oder mehr in Y-Richtung. Das berücksichtigt der TF nicht.

"Das könnte doch nur funktionieren, wenn der trilineare Filter in Verbindung mit den unterschiedlichen MipMap-Leveln die X- bzw. Y-Werte anders behandelt, oder?"

Der TF führt zwei BF durch. Diese beiden Ergebnisse werden je nach Nachkomma-Stelle des MIP-Levels nochmal gemischt. X und Y werden völlig gleich, also isotrop behandelt. Anders beim AF, der je nach Blickwinkel keine Quadrate, sondern Rechtecke ausliest. Also X oder Y "bevorzugt".

Razor,

dass sich bei der Textur beim Helicopter genau dieses Bild ergeben muss, war schon vorher klar, aber die Strebe beim Turm liefert nun - endlich - die begehrte Erkenntnis: 3dwin filterte bilinear. Schon der TF bringt auch bei schwierigen Winkeln eine brauchbare Glättung. AF sorgt schlussendlich für richtig gute Qualität. Damit wären alle meine diesbezüglichen Fragen geklärt.

Den Vergleich von 3dwin halte ich schon für zulässig, nur etwas unfair. Zulässig, weil offenbar Radeon und GF3 beide mit BF antraten. Unfair, weil kein Mensch MP auf einer GF3 mit BF spielen wird. Ich unterstelle 3dwin keine böse Absichten. Sie waren etwas fahrlässig. Wenn man aber sieht, wie lange wir hier zur Klärung brauchen, kann man kaum verlangen, dass der Autor vom bewussten 3dwin Artikel alles weiss. Mir geht es um FSAA, da würde ich TruForm in der Diskussion ganz außen vor lassen.

Trotz der Schwächen beim AF kann eine R8500 dank SV eine bessere IQ als eine GF3 bringen. (kann != muss)

Zu SV: Der Performance-Einbruch wird bei 4x bestehen bleiben. Wenn SV aber erst mal richtig genutzt wird, sollten Hintergrund-Objekte stärker gefiltert werden als Vordergrund-Objekte. Dann wird im Gesamt-Bild vielleicht 2x - 6x AA gemacht. Der große Nachteil beim AA der GF3 ist ja, dass 4x nur ein klein bisschen besser als 2x ist. Der Qualitätszuwachs nimmt zwar grundsätzlich ab. Durch den Wechsel von RG auf OG ist das bei der GF3 allerdings besonders auffällig. Während man offenbar 2x oft ohne ernste Performance-Probleme zuschalten kann, haut 4x meistens deutlicher rein.

Pengo

2001-12-26, 19:09:27

Originally posted by aths
Der große Nachteil beim AA der GF3 ist ja, dass 4x nur ein klein bisschen besser als 2x ist. Der Qualitätszuwachs nimmt zwar grundsätzlich ab. Durch den Wechsel von RG auf OG ist das bei der GF3 allerdings besonders auffällig.

hierzu habe ich dies gefunden:

http://www.voodooextreme.com/3dpulpit/misc/maxpayneaafun/index.html

These three additional undocumented Direct3D-specific anti-aliasing implementations can be witnessed by simply changing the value of the relevant Windows9x registry key (under Direct3D) ANTIALIASQUALITY (HKLM/System/CurrentControlSet/Services/Class/Display/000x/NVidia/Direct3D). This (the three "secret and undocumented" Mystery AA Modes) is perhaps already known to a few of you folks - I sure didn't until recently, however. The values for the official No AA, 2xAA, Quincunx and 4xAA are 0, 1, 2 & 3 (DWORD values) respectively. The 3 undocumented anti-aliasing implementations can be seen by using DWORD values of :

"Mystery Mode 1" = 4
"Mystery Mode 2" = 5
"Mystery Mode 3" = 6

Note that I simply used these three registry values and added nothing else in terms of other tweaks (like perhaps anisotropic filtering or messing with the LOD bias). If by simply changing the registry values some sort of LOD biasing or anisotropic filtering is actually applied, well, I honestly don't know.

In OpenGL, there is one (and only one) additional unofficial anti-aliasing implementation, which is already widely known as "4xAA + 9-tap". That "9-tap", I believe, refers to a 3-by-3 averaging filter used for down-sampling. I think this 3-by-3 filter is used in one of the Direct3D undocumented anti-aliasing implementations above. Which one in particular, I'm not sure. Also, it is my suspicion that perhaps both "Mystery Mode 2" and "Mystery Mode 3" could possibly be 4xRotated-Grid - remember that officially the GeForce3 only performs Ordered-Grid for 4xAA. This is based solely on my observations of the two screenshots of Red Faction above (i.e. the "Mystery Mode 2" and "Mystery Mode 3" ones, particularly the anti-aliasing of the near-horizontal white door-frame.

aths

2001-12-26, 19:38:37

Pengo,

es nervt mich selbst, dir wieder mal den Vorwurf machen zu müssen, vorschnell zu posten. Der von dir angebrachte Link war für mich Grund genug, einen eigenen Thread aufzumachen, und das ist schon ein paar Tage her.

Dabei stellte sich heraus, dass alle Modi nach wie vor letztlich maxmimal nur 2x2 OGAA machen, die letzten beiden allerdings SSAA.

Es kommt mir so vor: Wenn du irgendwas gefunden hast, was du "gegen" mich posten kannst, tust du das sofort, ohne groß nachzudenken. Vielleicht kommt mir das nur so vor. Andererseits war das jetzt das x-te mal. Es würde uns beide Zeit sparen, wenn du deine Schnellschüsse reduzieren könntest.

Pengo

2001-12-26, 19:57:00

Ich habe vor mehreren Tagen über den GF2 Kompatilitätsmodus gelesen, allerdings wußte ich nicht daß sich die Beobachtungen von 3DPulpit darauf beziehen, da gesagt wurde daß dieser Kompatibilitätsmodus nicht so einfach einzuschalten ist, man mußte gar paar Tage auf eine extra Rivatuner Version warten die sowas ermöglicht.

Xmas

2001-12-26, 20:39:40

Razor, ne kleine Korrektur: AnisotropicLevel 0 schaltet nicht das Alpha-Blending, sondern die Texturfilterung ab, also werden nicht mehrere Texel gewichtet verwendet, sondern immer nur ein Texel. Bei den Streben gibt es einen scharfen Übergang zwischen Alpha 1.0 (deckend) und Alpha 0.0 (völlig transparent). Wird die Textur gefiltert, kommen natürlich auch Zwischenwerte zum Einsatz, wodurch die Kante glatt erscheint. Ohne Filterung gibt es diesen Übergang nicht.

Razor

2001-12-26, 22:33:15

@Quasar

Jep !
Die beiden Shots sind natürlich von der gf3...
Links bilinear, rechts eben trilinear (InGame) und beide mit AnisotropicLevel 1 im Treiber.

Die Aniso-Shots hab' ich nicht dazu getan, da dort nur zu sehen war, daß eben die weiter entfernten Texturen an Schärfe gewannen, allerdings nicht so erheblich wie bei 32tap-aniso über den Treiber...
(vermute da so 8-16tap)

Wie gesagt, schon sehr merkwürdig, das Ganze !
;-)

@aths

Na, dann scheint das mit den Filtern ja nun -endlich- geklärt !
;-)

Und klar, auch beim gf3 4xOGMS ist der Performanceverlust deutlich, aber verschmerzbar. Wenn man zudem noch eine Auflösungsstufe herunter geht (800x600) und dann 4xOGSS benutzt, ist das Ergbnis sogar durchaus akzeptabel, obwohl man dann natürlich auch schon in einer Auflösung von 1600x1200 spielen kann und dann ganz auf FSAA verzichtet, dem man allerdings dann eine sehr niedrige Bildwiederholung entgegen halten muß, denn bei 1600x1200 sind bei meinem Moni nur noch 85Hz drin, während 800x600 bei 144Hz liegt. Aber wie schon gesagt, selbst 4xOGSS ist bei 1024x768 spielbar, das 4xSV bei der R8500 jedoch nicht.

Mir ist auch nicht ganz klar, warum der Performance-Unterschied zwischen den beiden Karten dermaßen deutlich ist. Liegt dies an dem Multisampel-Buffer 4xRGSS ?
Hmmm...

Möchte an dieser Stelle noch einmal meine MP Ergebnisse bringen:
ABit BX6R2 mit PIII700@903 (129FSB)
256MB Infinion CL2 (2-2-2)
Elsa Gladiac 920 (gf3) @ 200/230 (default)
Win98SE mit Deto 21.88 (DX8.1)

Max Payne "PCGH's Final Scene No.1 (VGA-Demo)" @ 1024x768x32
-trilinear / 32Bit Textures / Fogging / Sound
-max Quality
max avg -AA % -ani%

0x 00ani -> 55.79 37.18 --- ---
2xrgms 00ani -> 53.99 31.22 16.03 ---
2xrgms 5tap 00ani -> 53.74 30.09 19.07 ---
4xogms 00ani -> 44.77 24.56 33.94 ---
4xogms 9tap 00ani -> 43.95 22.18* 40.34 ---
4xogss 00ani -> 44.75 22.34* 39.91 ---
4xogss 9tap 00ani -> 39.94 17.38* 53.25 ---

0x 32ani -> 54.38 33.30 --- 10.44
2xrgms 32ani -> 51.27 26.74 19.70 14.35
2xrgms 5tap 32ani -> 45.08 24.88 25.29 17.31
4xogms 32ani -> 44.42 22.06 33.75 10.18
4xogms 9tap 32ani -> 42.74 19.77* 40.63 10.87
4xogss 32ani -> 40.37 16.09* 51.68 27.98
4xogss 9tap 32ani -> 32.41 12.87* 61.35 25.95

(* = min FPS teilw. < 10 !)
was ich erst einmal so stehen lassen möchte.
Auch sollte an dieser Stelle erwähnt werden, daß dieser Bench sehr GraKa-Lastig ist.

Dem gegenüber sollten dann noch mal die Ergebnisse von dem neuen HardOCP-Test mit den neuen ATI-Treibern erwähnt werden:
([H]ardOCP: Radeon8500 Revisited (http://www.hardocp.com/reviews/vidcards/ati/8500_revisited/))
SeriousSam @ 1024x768x32

avg -AA %

0x -> 89.00 ---

2xSV Perf -> 55.40 37.75
4xSV Perf -> 28.30 68.20
6xSV Perf -> 14.40 83.82

2xSV Qual -> 48.50 45.51
4xSV Qual -> 22.00 75.28
6xSV Qual -> <nicht möglich>
Sicher ist es etws unfair, MP mit SS zu vergleichen, aber um zu verdeutlichen, was ich meine, dürfte das genügen.

Selbst die kleinste SV-Einstellung (2xSV Perf) kostet schon genau so viel Performance, wie das 4xOGSS bei der gf3 und ist qualitativ NICHT vergleichbar. Zumindest hier bei SS (vermutlich aber auch in vielen anderen aktuellen Titeln) ist 4xSV nicht mehr zu gebrauchen und selbst die 2x-Variante geht mit satten 40% (oder mehr) Performance-Verlust einher...

Pengo hat doch übrigens durchaus recht, mit dem Artikel bei 3DPulpit, insofern würde ich Ihm da nicht die Absicht unterstellen, nur etwas gegen Dich posten zu wollen. Du must doch zugeben, daß dieser Punkt sicher noch nicht eindeutig geklärt ist, oder ?

@Pengo

Diesen Artikel bei 3DPulpit hab' ich auch schon gelesen und fand ihn auch sehr interessant !

Der hat übrigens nichts mit dem 'gf2-Kompatibilitätsmodus' zu tun, sondern nutzt lediglich ein Registery-Setting für den Parameter 'AntialiasQuality', welcher neben den schon bekannten '2x2 OGMS 9-tap' noch zwei weitere beherbergt...
(wer weiß, was da noch so alles im Treiber 'vertsteckt' ist ;-)

Habe das natürlich auch gleich ausprobiert und möchte aufgrund dessen erst einmal aths und Xmas zustimmen, die auf 4xOGSS-AA (bzw. 4xODSS 9-tap) tippen. Leider gibt's dazu noch keine näheren Info's, wie das bewerkstelligt wird, denn der Performance-Verlust ist gegenüber dem 4xOGMS nur ca. 5%, sollte also auch über den Multisampling-Buffer der gf3 realisiert werden (analog der SV-Implementierung bei ATI). Ob es sich nun tatsächlich um 'ordered grid' oder 'rotated grid' handelt vermag ich noch nicht zu sagen, zumnal der BQ-Unterschied zur R8500 nicht auszumachen ist. Rein subjetiv sieht's, wie gesagt, nach 'ordered' aus, aber für mich sieht auch die ATI-Lösung danach aus...

Who know's ?

Wir werden in nächster Zeit sicher noch etwas dazu hören !
;-)

@Xmas

Wäre diese Aussage korrekt ?
"Ohne Texturfilterung ist kein Alpha-Blending möglich, bzw. hat dieses keinen Effekt."
???

Denn Transparenz-Effekte sind mit dem AnisotropicLevel 0 ja nichtr mehr auszumachen...
Hmmm...

Schon schwierig, diese Materie, aber sehr lohnenswert und vor allem interessant !
;-)

Bis dann

Razor

6xSV Qual ist natürlich nicht fehlerhaft, sondern bei 1024x768 schlicht nicht möglich

Xmas

2001-12-26, 23:02:05

Originally posted by Razor
Wäre diese Aussage korrekt ?
"Ohne Texturfilterung ist kein Alpha-Blending möglich, bzw. hat dieses keinen Effekt."
???
Nein. Alpha Blending ist auch ohne Texturfilterung problemlos möglich. Sogar ohne Texturen ;)

Razor

2001-12-26, 23:12:14

Hmmm...
Ich werd' dan noch mal in mich gehen, Xmas...
:-(

Hab's dann immer noch nicht verstanden, warum die 'Streben' (RGBA-Textuen ?) auch ohne FSAA 'geglättet' werden.
Somit ist also lediglich die Filterung für diesen sehr guten 'Übergang' zuständig ?
Hmmm...

Und warum braucht man dann für Alpha-Texturen überhaupt noch FSAA ?
Es wird der gf3 ja immer als Nachteil ausgelegt, daß diese keine Alpha-Texturen 'glättet', aber so gesehen, kann ich keinen Nachteil(bei minimal trilinearm Filter) fest stellen...

SEHR schwierig, das Ganze !
;-)

Razor

Xmas

2001-12-27, 01:38:43

Ok, Razor, dann will ich für dich erst mal auf den Unterschied zwischen Alpha Test und Alpha Blending eingehen (wollte ich eigentlich vorher schon machen...)

Beim Alpha Test wird der berechnete Alpha-Wert (s.u.) mit einem Referenzwert verglichen, der von der Anwendung festgelegt wird. Es wird auch der Vergleichsoperator festgelegt (=, >, <, >=, <=, <>).
Wenn der Vergleich mit dem Referenzwert wahr ist, dann wird der Pixel gerendert, ansonsten wird an dieser Stelle abgebrochen und mit dem nächsten Pixel fortgefahren.

Der Einsatz von Alpha Test sagt noch gar nichts darüber aus, wie der Alpha-Wert danach verwendet wird! Der Alpha-Wert kann auf vielfältige Weise verwendet werden, insbesondere beim Pixel Shader.

Der Alpha-Test gleicht dem Z-Test, nur dass dort der Referenzwert für jeden Pixel aus dem Z-Buffer gelesen, und evtl neu geschrieben wird.

Alpha Test wird meist dort verwendet, wo man Löcher Rendern will, aber keine "Halbtransparenz" braucht, also nur entweder durchsichtig oder deckend. Das ist bei Zäunen oder Gittern der Fall.
Dabei stellt man den Referenzwert auf 1.0 und den Operator auf "=". In der Textur gibt es nur 0.0 und 1.0 als Alpha-Wert, 1 Bit würde also ausreichen. Das hat zur Folge, dass nur Pixel mit Alpha = 1.0 auch gerendert werden. Das spart natürlich Speicherbandbreite.

Alpha Blending bedeutet, dass der Alpha-Wert dazu verwendet wird, die berechnete Farbe mit dem Hintergrundpixel zu vermischen. Dabei wird die berechnete Farbe mit (Alpha) gewichtet, die vorhandene Farbe mit (1 - Alpha). Oder andersrum, das ist einstellbar. Das Problem ist hier die Speicherbandbreite, der Hintergrundpixel muss ja erst mal gelesen werden.

Damit stellt man halbdurchsichtige Objekte, also Glas, Rauch und ähnliches dar. Dabei wird in der Textur die ganze Alpha-Breite von 0.0 bis 1.0 genutzt.

Wie der Alpha-Wert berechnet wird: Üblicherweise wird der Alpha-Wert zusammen mit einem Farbwert (RGBA) einer Textur entnommen. Dabei spielt natürlich der Texturfilter sowie das Texturformat eine entscheidende Rolle. Der Alpha-Wert kann aber auch pro Eckpunkt (Gouraud Shading) oder gar pro Dreieck (Flat Shading) angegeben werden. Kombinationen sind auch möglich, die lass ich hier mal außen vor. Alpha wird immer zwischen 0.0 und 1.0 betrachtet (was sich in Zukunft ändern könnte), bei 8 Bit entspricht das 0 und 255.

Und nun zu den Kanten innerhalb einer Textur. Wird beim Rendern eines Gitters nur Alpha Test wie oben beschrieben eingesetzt, so werden die Pixel entweder deckend oder gar nicht gerendert. Die Kanten der "Löcher" in der Textur sind somit erst mal stufig.
Was bewirkt AA hier? Supersampling glättet diese Kanten natürlich, da ja in einer höheren Auflösung gerendert wird und für jedes Sample ein neuer Alpha-Wert aus der Textur gelesen wird.
Bei Multisampling sieht es freilich anders aus: Ein Texturwert wird für alle Samples eines Pixels verwendet. Also auch ein Alpha-Wert. Multisampling wirkt sich hier also gar nicht aus!

Nun könnte man auf die Idee kommen, Alpha Test und Alpha Blending zusammen zu verwenden! Bei Alpha Test nimmt man nun als Referenzwert 0.0 und als Operator ">". Das hat zur Folge dass nun nur noch Pixel abgewiesen werden, die völlig transparent, also unsichtbar sind (spart wieder Bandbreite). Sämtliche Zwischenstufen werden gewichtet mit dem Hintergrund gemischt.

Doch wo kommen die Zwischenstufen her, wenn in der Textur doch nur Einsen und Nullen sind? Richtig, die Textur wird ja gefiltert! Je besser der Filter, desto besser das Ergebnis. Die Kanten innerhalb der Textur werden geglättet, obwohl kein AA zum Zuge kommt.
Das Multisampling-Ergebnis ist identisch, bei Supersampling werden die Kanten noch etwas glatter.

Würde die Textur nicht gefiltert (auch Point Sampling genannt) - was sich durch AnisotropicLevel 0 erreichen lässt - hätte man auch keine Zwischenstufen, weil diese ja nicht in der Textur vorhanden sind, sondern erst durch das Filtern entstehen! Wären in der Textur tatsächlich Zwischenstufen, wäre auch eine Glättung der Kanten zu beobachten. (Aber Zwischenstufen in die Textur zu integrieren würde völlig dem Sinn des Filterns widersprechen, keine gute Idee)

Die Kombination von Test und Blending schneidet auf den ersten Blick deutlich besser ab, doch es offenbaren sich Nachteile.

Der erste ist Performance. Alpha Test ist "umsonst", Alpha Blending erfordert aber pro Pixel das Auslesen eines Farbwertes aus dem Framebuffer.
(Anm.: Ich weiß nicht, inwiefern Grafikchips in der Lage sind zu erkennen, dass das Lesen eines Farbwerts nicht nötig ist (i.A. wenn Alpha = 1.0). Gerade beim Pixel Shader könnte dies sich aber als schlicht unmöglich erweisen. Ich gehe jetzt einmal davon aus dass sie es nicht erkennen können)
Die Bandbreitenerfordernisse steigen also deutlich. Ausnahme: Kyro.

Zweitens erfordert Alpha Blending generell, dass sämtliche halbtransparenten Flächen von hinten nach vorne gerendert werden. In Max Payne wird dies nicht getan, was deutliche Bildfehler zur Folge hat. Wenn du dir deine Screenshots genau anschaust, siehst du dass die Streben im Hintergrund dort "durchbrochen" erscheinen, wo die Streben im Vordergrund sind.
Back-To-Front Rendering ist so ziemlich das Schlechteste, was man einer Graka, insbesondere GF3 und R8500 antun kann. Ausnahme: Kyro. ;)

Und drittens ist die Darstellung bei manchen Überschneidungen unvermeidbar fehlerhaft. Ohne Ausnahme ;)

Ein ähnliches Prinzip findet auch beim sog. Edge- oder Wu-Antialiasing Verwendung, welches mit denselben Problemen (plus ein weiteres) zu kämpfen hat und deshalb kaum eingesetzt wird.

Puh, jetzt ist aber mal Schluss. Ich hoffe dass das wenigstens zum Teil verständlich formuliert ist :D

Mein bisher längstes Posting zum Goldenen...

Nr. 5

2001-12-27, 02:21:32

@Xmas

ja, das ist verständlich formuliert.
ich hatte mich auch schon die ganze zeit gefragt, woran du erkennst in welcher reihenfolge dort gerendert wurde. jetzt ists mir klar.
klasse erläuterung!

cu

aths

2001-12-27, 13:11:00

Razor,

du schreibst: "Ob es sich nun tatsächlich um 'ordered grid' oder 'rotated grid' handelt vermag ich noch nicht zu sagen"

Bei Kanten, die sehr horizontal bzw. sehr vertikal sind, zeigt sich 2x2 OG durch bestimmte Eigenschaften. Genau die sind dort zu sehen. Das Triangle Setup einer GF3 lässt bei 4x AA kein RG zu.

Weiterhin schreibst du: "Hab's dann immer noch nicht verstanden, warum die 'Streben' (RGBA-Textuen ?) auch ohne FSAA 'geglättet' werden.
Somit ist also lediglich die Filterung für diesen sehr guten 'Übergang' zuständig ?"

Löse dich doch mal von der Vorstellung, dass da eine Kante ist. Stelle dir einen einfachen, harten Farbübergang vor. Stell dir weiterhin vor, diese Textur wird um ihren Mittelpunkt gedreht.

Du würdest kaum auf die Idee kommen, dass die Grafikkarte dabei Treppenstufen beim harten Farbübergang zeichnet. Denn dank bilinearem Filter fliessen ja pro Pixel gleich vier Texel ein. Das erzeugt Übergänge.

Bei nur 4 Texel pro Pixel sind diese Übergänge zuweilen ziemlich hart. Der TF läuft auf 8 Texel hinaus, bessere AF lesen 16 oder mehr.

Texturfilterung kann man als Textur-Antialiasing verstehen.

Das ist überhaupt erst der Grund, warum Multisampling-AA erfunden wurde: Wenn die Texturen bereits (durch Filter) Anti-Aliasing bekommen, reicht es doch, dann nur noch die Kanten extra zu behandeln.

Xmas,

also ich konnte dein Posting gut verstehen :)

Razor

2001-12-27, 16:01:33

@Xmas

Erst einmal vielen herzlichen Dank, für diese sehr ausführliche Darstellung !
:loveya:
(nicht falsch verstehen ;-)

Dank Deiner sehr verständlichen Erklärung, denke ich nun den Sachverhalt begriffen zu haben...
Insbesndere die Begriffe Alpha Test und Alpha Belnding kann ich nun richtig zuordnen (Renderingsnotwendikeit vs. Hintergrundvermischung). Und das Multisampling AA auf die Glättung von Alpha-Texturen keinen Einfluß hat, ist auch klar geworden. Daß es Supersamling AA völlig egal ist, was dort 'geglättet' wird, ebenso. Somit ist es letztlich von der Textur und dem verwendeten Filter abhängig, ob SSAA dann nocht etwas bringen kann, oder eben nicht.

Habe zu diesem Zweck dann auch noch mal Shots von meiner gf3 angehängt, die den Unterschied zwischen 4xOGMS und 4xOGSS (Mystery Mode 5 ;-) dokuemntieren soll (nur der Vollständigkeit halber ;-).

Nochmals vielen Dank Xmas !

@aths

Das mit der Textur-'Glättung' habe ich jetzt verstanden. Auch wenn an dem angehängten Shot kein allzu großer Unterscheid zwischen SS und MS auszumachen ist und dies, wenn überhaupt, erst durch eine entsprechende Vergrößerung zum Tragen kommt...

Sehr interessant find ich in diesem Vergleich, daß die 'Kante' mit SuperSampling besser 'geglättet' zu sein scheint. Die (große) 'Strebe' hingegen keine Veränderung aufweist. An den anderen (ebenfalls schwarzen, aber kleineren) 'Streben' aber eine deutliche Veränderung sichtbar ist. Sie erscheinen nun deutlicher, aber weniger 'smooth' (i.e. härtere Übergänge von Textur zum Hintergrund). Wohl aber auf jeden Fall ein sehr gutes Beispiel, um die Unterschiede zwischen MultiSampling und SuperSampling zu verdeutlichen.

Wie dem auch sei, sehr interessant das Ganze !
;-)

Bis dann

Razor

Hier nun der Vergleich zwischen 4xOGMS und 4xOGSS:
(sonstige Parameter wie vorher, i.e. Trilinear, AnisotropicLevel 1)

2001-12-28, 11:41:25

Originally posted by Xmas

Alpha Test wird meist dort verwendet, wo man Löcher Rendern will, aber keine "Halbtransparenz" braucht, also nur entweder durchsichtig oder deckend. Das ist bei Zäunen oder Gittern der Fall.

Was machen in diesem Fall denn Chips, die kein Alpha-Test beherrschen, wie zB. der Permedia2 ??

Ich denke zum Rendern von Zäunen, Gittern etc.. wird derzeit zumeist color keying verwendet.

aths

2001-12-28, 13:21:58

ow,

du schreibst: "Ich denke zum Rendern von Zäunen, Gittern etc.. wird derzeit zumeist color keying verwendet."

Da frage ich mich, wo der Unterschied zum Alpha Test ist. Ob nun auf ein Alpha Bit oder auf eine bestimmte Farbe getestet wird, beides geht ohne (viel) zusätzliche Bandbreite zu realisieren.

Thowe

2001-12-28, 19:45:42

Originally posted by Xmas
Puh, jetzt ist aber mal Schluss. Ich hoffe dass das wenigstens zum Teil verständlich formuliert ist :D

Mein bisher längstes Posting zum Goldenen...

Sehr verständlich würde ich sagen, danke.

zu 2. Cool :D

aths

2001-12-29, 18:53:05

Razor,

das mit den Streben ist beim OG AA gar nicht so verwunderlich: Dieses AA glättet bekanntlich relativ vertikale bzw. horizontale Kanten ziemlich schlecht. Das heisst, zusätzliches Supersampling bringt da auch nicht mehr den entscheidenen Vorteil. Im Gegensatz zu Winkeln um 45°: Hier glättet 2x2 OG vorbildlich, und Supersampling macht sie dann (nach dem AF) seeehr glatt.

Das ist ja auch der Nachteil eines OG-Rasters: Die hässlichen langen Treppen werden kaum, die erträglichen kurzen Treppen um so mehr geglättet.

Genaueres sollte in ein paar Wochem im Netz zu lesen sein :)

Razor

2001-12-29, 18:59:37

Na dann hoffe ich mal, aths, daß es bald vielleicht doch so etwas wie 2xrgss/2xrgss 5-tap oder gar 4xrgss für die NV's geben wird...
;-)

Und wieso soll 4xrgss mit der gf3 nicht möglich sein ?
(hast Du zuvor schon mal irgendwo geschrieben)

Bis dann

Razor

aths

2001-12-29, 22:26:50

"Und wieso soll 4xrgss mit der gf3 nicht möglich sein ?
(hast Du zuvor schon mal irgendwo geschrieben)"

Dann könntest du es da ja auch heraus suchen. Es liegt am Triangle Setup der GF3.

Razor

2001-12-30, 09:39:54

Dort hast Du leider auch nur gesagt, daß es am T-Setup der gf3 Hardware liegen soll, nicht aber, wie sich dieses äussert.

Aber hat ja auch nicht unbedingt was mit dem Thema zu tun...
Wäre also 'schön', wenn's mal was von 2xrgss zu hören gibt !
;-)

Bis dann

Razor

aths

2001-12-30, 15:07:41

Razor,

um 4 Subpixel im RG-Verfahren zu berechnet, muss das Triangle Setup natürlich auch 4 (oder bei 45° eben 3) Zeilen pro Pixel liefern. GF3-Hardware verdoppelt (gegenüber NO-AA) aber nur die Zeilen. Damit ist nur OGAA möglich.

Razor

2001-12-31, 13:43:35

OK aths...
Dann nehme ich das erst einmal so hin !
;-)

Razor

Xmas

2001-12-31, 14:55:24

Originally posted by ow
Was machen in diesem Fall denn Chips, die kein Alpha-Test beherrschen, wie zB. der Permedia2 ??

Ich denke zum Rendern von Zäunen, Gittern etc.. wird derzeit zumeist color keying verwendet.

Auch wenn es früher vielleicht oft eingesetzt wurde, wirst du es bei neuen Spielen wohl nicht mehr finden ;). Denn weder OpenGL noch DirectX8 unterstützen Color bzw. Chroma Keying...

2001-12-31, 15:08:46

Originally posted by Xmas

Auch wenn es früher vielleicht oft eingesetzt wurde, wirst du es bei neuen Spielen wohl nicht mehr finden ;). Denn weder OpenGL noch DirectX8 unterstützen Color bzw. Chroma Keying...

Für DX8 zweifele ich das mal an, da DX7...3 als Untermenge von DX8 gesehen werden kann und es dort unterstützt wird.

s. auch Test39, 3dWinbench2k, DX7

Xmas

2001-12-31, 15:13:53

Deswegen schrieb ich ja auch DirectX8, nicht generell DirectX. Wenn du die Funktionen von Direct3D8 nutzen willst, musst du auf Chroma Keying verzichten.

Razor

2002-01-04, 13:15:17

DX7 ist keine 'echte' Untermenge von DX8...
Schau doch mal in Dein Systemverzeichnis...

Da gibt's:

D3D8.DLL = Version 4.08.01.0881 = DX 8.1 (über DX8 angesprochen)
-> insofern ist DX8.1 als Übermenge von DX8 anzusehen !

D3DIM.DLL = Version 4.07.00.0700 = DX 7.0 (als selbstständige Einheit)
-> insofern ist DX7 KEINE Untermenge von DX8, aber Bestandteil der Distribution

Nur weil DX7 eben auch mit DX8 geliefert wird, bedeutet dies noch lange nicht, daß DX8 dann auch genauso arbeitet, wie DX7... ganz im Gegenteil können hier völlig unterschiedliche Wege geangen werden, insofern sehe ich in der Aussage von Xmas keinen Wiederspruch...

Bis dann

Razor

2002-01-04, 13:39:24

Originally posted by Razor
DX7 ist keine 'echte' Untermenge von DX8...
Schau doch mal in Dein Systemverzeichnis...

Da gibt's:

D3D8.DLL = Version 4.08.01.0881 = DX 8.1 (über DX8 angesprochen)
-> insofern ist DX8.1 als Übermenge von DX8 anzusehen !

D3DIM.DLL = Version 4.07.00.0700 = DX 7.0 (als selbstständige Einheit)
-> insofern ist DX7 KEINE Untermenge von DX8, aber Bestandteil der Distribution

Nur weil DX7 eben auch mit DX8 geliefert wird, bedeutet dies noch lange nicht, daß DX8 dann auch genauso arbeitet, wie DX7... ganz im Gegenteil können hier völlig unterschiedliche Wege geangen werden, insofern sehe ich in der Aussage von Xmas keinen Wiederspruch...

Bis dann

Razor

Ich hab mir sogar alle importierten und exportierten Funktionen der DLLs angeschaut und habe doch extreme Zweifel, das die beiden Dlls für DX7 bzw. 8 "dasselbe" darstellen.

d3d8.dll:

Export Table

Name: d3d8.dll
Characteristics: 00000000
Time Date Stamp: 3bdf5e32
Version: 0.00
Base: 00000001
Number of Functions: 00000005
Number of Names: 00000005

Ordinal Entry Point Name
0002 0001dcb0 D3D8GetSWInfo
0003 0001f8c0 DebugSetMute
0004 0002beb0 Direct3DCreate8
0000 0004bd00 ValidatePixelShader
0001 00019c50 ValidateVertexShader

Import Table

USER32.dll
Ordinal Function Name

015d GetSystemMetrics
011a GetIconInfo
024f SetCursorPos
010b GetCursorPos
010e GetDesktopWindow
016c GetWindowDC
005a CreateIconIndirect
0108 GetCursor
024d SetCursor
0096 DestroyIcon
0299 SystemParametersInfoA
00ff GetClientRect
01ab IsWindow
0192 IntersectRect
02d8 wsprintfA
010c GetDC
022a ReleaseDC
01c8 LoadStringA

ADVAPI32.dll
Ordinal Function Name

01f8 RegSetValueExA
01cb RegCreateKeyA
01e1 RegOpenKeyExA
01e0 RegOpenKeyA
01d4 RegEnumKeyA
01eb RegQueryValueExA
01c8 RegCloseKey

VERSION.dll
Ordinal Function Name

0000 GetFileVersionInfoA
0001 GetFileVersionInfoSizeA
000a VerQueryValueA

GDI32.dll
Ordinal Function Name

00ab GetNearestColor
008e GetDeviceCaps
0020 CreateDCA
0046 DeleteObject
00ad GetObjectA
0025 CreateDIBitmap
001f CreateCompatibleDC
0043 DeleteDC
00be GetSystemPaletteEntries

DDRAW.dll
Ordinal Function Name

000b DdEntry12
000a DdEntry11
0016 DdEntry6
0011 DdEntry2
0013 DdEntry3
0009 DdEntry10
0019 DdEntry9
0012 DdEntry20
0017 DdEntry7
000e DdEntry17
0010 DdEntry19
000f DdEntry18
0008 DdEntry1
0018 DdEntry8
000d DdEntry16
000c DdEntry13

KERNEL32.dll
Ordinal Function Name

00e2 GetCurrentThreadId
005d DeleteCriticalSection
018f InitializeCriticalSection
0068 EnterCriticalSection
01ad LeaveCriticalSection
0106 GetLastError
0195 InterlockedIncrement
02d3 lstrcatA
0147 GetSystemDirectoryA
0128 GetProcAddress
0112 GetModuleHandleA
00ba FreeLibrary
01ae LoadLibraryA
02df lstrcpynA
01e5 OutputDebugStringA
00df GetCurrentProcess
0192 InterlockedDecrement
0027 CloseHandle
0048 CreateMutexA
0062 DisableThreadLibraryCalls
00e0 GetCurrentProcessId
01b4 LocalAlloc
01b8 LocalFree
02dc lstrcpyA
0040 CreateFileA
0252 SetFilePointer
0059 DebugBreak
01d0 MoveFileA
005f DeleteFileA
015b GetTickCount
00fc GetFileSize
024c SetErrorMode
02cb _lclose
01d9 OpenFile
02ad WideCharToMultiByte
01d5 MultiByteToWideChar
02e2 lstrlenA
02d9 lstrcmpiA
0182 HeapAlloc
012b GetProcessHeap
0249 SetEndOfFile
0162 GetVersionExA
0216 RtlUnwind
0186 HeapFree
0188 HeapReAlloc
007f ExitProcess
0255 SetHandleCount
0140 GetStdHandle
00fe GetFileType
013e GetStartupInfoA
0110 GetModuleFileNameA
0185 HeapDestroy
0184 HeapCreate
029d VirtualFree
00b7 FreeEnvironmentStringsA
00ef GetEnvironmentStrings
00b8 FreeEnvironmentStringsW
00f1 GetEnvironmentStringsW
02a0 VirtualProtect
029b VirtualAlloc
0149 GetSystemInfo
02a2 VirtualQuery
01ab LCMapStringA
01ac LCMapStringW
019d IsBadWritePtr
018a HeapSize
00bf GetACP
011b GetOEMCP
00c5 GetCPInfo
0141 GetStringTypeA
0144 GetStringTypeW
0108 GetLocaleInfoA
0270 SetUnhandledExceptionFilter
019a IsBadReadPtr
0197 IsBadCodePtr
0262 SetStdHandle
00af FlushFileBuffers
01f8 RaiseException
024d SetEvent
0296 UnmapViewOfFile
02b8 WriteFile
0203 ReadFile
00ce GetCommandLineA

d3d7im.dll:

Export Table

Name: d3dim700.dll
Characteristics: 00000000
Time Date Stamp: 3bcc7662
Version: 0.00
Base: 00000001
Number of Functions: 00000012
Number of Names: 00000012

Ordinal Entry Point Name
0004 0000e0f0 CreateTexture
0005 0000e0c0 D3DBreakVBLock
0000 0000e2a9 D3DFree
0001 00010f7c D3DMalloc
0002 000119c5 D3DRealloc
0006 00011d39 D3DTextureUpdate
0007 00011d19 DestroyTexture
0008 000119ae Direct3DCreate
0003 000124bf Direct3DCreateDevice
0009 0001275b Direct3D_HALCleanUp
000a 00011b6c FlushD3DDevices
000b 000114e3 GetLOD
000c 000114c3 GetPriority
000d 000123fa PaletteAssociateNotify
000e 00011c03 PaletteUpdateNotify
000f 000114d3 SetLOD
0010 000114b3 SetPriority
0011 00011c8a SurfaceFlipNotify

Import Table

USER32.dll
Ordinal Function Name

0192 IntersectRect
01a8 IsRectEmpty

ADVAPI32.dll
Ordinal Function Name

01f8 RegSetValueExA
01cb RegCreateKeyA
01e1 RegOpenKeyExA
01c8 RegCloseKey
01eb RegQueryValueExA
01e0 RegOpenKeyA

DDRAW.dll
Ordinal Function Name

0005 DDInternalLock
0006 DDInternalUnlock
0023 GetAliasedVidMem
0001 D3DParseUnknownCommand

KERNEL32.dll
Ordinal Function Name

01bb LocalReAlloc
029d VirtualFree
01b8 LocalFree
0068 EnterCriticalSection
01ad LeaveCriticalSection
0197 IsBadCodePtr
00ba FreeLibrary
019a IsBadReadPtr