unerfreuliche Half-Life 2 News: Eventuelles Anti-Aliasing Problem

[LovesuckZ]

Ich habe im Halflife2.net/Forum (http://www.halflife2.net/forums/index.php?) dies gefunden:

qckbeam (http://www.halflife2.net/forums/showthread.php?threadid=2622&perpage=15&pagenumber=1):

I wrote an e-mail to Valve asking why they decided to keep AA off for the videos and here is what they had to say:
There are problems with the way that current hardware implements FSAA. If you enable it, you will see a lot of artifacts on polygon boundaries due to the way that they sample texture subrects with FSAA enabled. We are working with the harware companies and the DirectX team to make sure that future hardware doesn't have this problem.
Gary .

Für ATi User gibt es dagegen eine (erfreuliche) Information, die sie ein wenig beruhigen koennte:

qckbeam (http://www.halflife2.net/forums/showthread.php?threadid=2622&perpage=15&pagenumber=4):

Sorry to have to report this to you:

1) Is this a problem that can be fixed with new drivers, or would we have to buy a whole new card to recitify it? If so, are there any cards on the horizon that would offer it?

Drivers aren't likely to fix the problem, with the exception of the ATI 9500-9800. There's hope there for being able to use FSAA properly. You are out of luck on NVidia unless either NVidia or us come up with some clever way of solving this problem.

2) Is this a problem unique to hardware + Source?

It's a problem for any app that packs small textures into larger textures. The small textures will bleed into each other if you have multisample FSAA enabled. The best thing to do right now is either buy an ATI card in the hopes that it will be solved there, or wait until the next generation of cards come out.

Für Nvidiauser bleibt anscheinend nur die Hoffnung, dass Nvidia einen weiteren AA "Hack" einbauen koennte, der wie bei Splintercell richtiges AA darstellen wuerde.
Valve hat ja noch bis zum 30.9 alle zeit der Welt und hoffen wir, dass sie dieses Problem loesen werden.

[AlexanderBehm]

OBwohl ich eh nicht glaube das man bei der grafik mit AA noch flüssig spielen kann.

[Raff]

Original geschrieben von AlexanderBehm
OBwohl ich eh nicht glaube das man bei der grafik mit AA noch flüssig spielen kann.

Doch, mit derzeitigen High-End-Karten sicher.

Meine Meinung: AA hin oder her, das Game wird übelst rocken. Außerdem möchte ich mal Leute sehen, die beim Anblick von HL2 in 1600x1200 + 8xAF nach Anti-Aliasing schreien...

MfG
Raff

[Demirug]

Solche Sachen ärgern mich doch ganz ehrheblich. Die eigene Dämlichkeit den IHVs anlasten.

Das MSAA am Polygonenrand Probleme mit Texturkoordinaten macht sollte eigentlich jeder der ein Spiel in dieser Klasse entwickelt wissen. Aber das ist mal wieder der typische Fall von "Ums AA kümmern wir uns nicht das geht ja alles von aleine" Und während der Entwicklung kommt auch keiner mal auf die Idee das ganze mit aktiviertem AA durchlaufen zu lassen. So stellt man dann am Ende fest (am besten noch durch die QA des Publischers) das es am Polyrand flimmert aber dann ist es zu spät.

Dabei sind die Lösungen mit denen man dieses Problem minimieren bzw ganz beseitigen kann bekannt nur muss man das von Anfang an berücksichtigen weil es Auswirkungen auf das erstellen von Texturen und der Geometrie (Texturekoordinaten) hat.

[Hellspawn]

Original geschrieben von Demirug
Solche Sachen ärgern mich doch ganz ehrheblich. Die eigene Dämlichkeit den IHVs anlasten.

Das MSAA am Polygonenrand Probleme mit Texturkoordinaten macht sollte eigentlich jeder der ein Spiel in dieser Klasse entwickelt wissen. Aber das ist mal wieder der typische Fall von "Ums AA kümmern wir uns nicht das geht ja alles von aleine" Und während der Entwicklung kommt auch keiner mal auf die Idee das ganze mit aktiviertem AA durchlaufen zu lassen. So stellt man dann am Ende fest (am besten noch durch die QA des Publischers) das es am Polyrand flimmert aber dann ist es zu spät.

Dabei sind die Lösungen mit denen man dieses Problem minimieren bzw ganz beseitigen kann bekannt nur muss man das von Anfang an berücksichtigen weil es Auswirkungen auf das erstellen von Texturen und der Geometrie (Texturekoordinaten) hat.

ich hab ne frage: vielleicht haben sie das ja gewusst, aber trotzdem ignoriert um die "normale" bildqualität zu steigern.. oder ist durch die verwendete technik KEINE verbesserung der grafik zu sehn?

[ravage]

Original geschrieben von Raff
Außerdem möchte ich mal Leute sehen, die beim Anblick von HL2 in 1600x1200 + 8xAF nach Anti-Aliasing schreien...

Es soll aber auch leute geben, die nen TFT zuhause haben. Und mit einer Auflösung von max 1024 schrei ich ganz laut nach AA ;)

[Exxtreme]

MUAHAHAHA!!11!!1

Typisch Spiele-Entwickler. Wohl ausschliesslich auf ATi-HW entwickelt und unbewusst diverse "Eigenheiten" der ATi-Hardware im Code ausgeglichen.

[Demirug]

Original geschrieben von Exxtreme
MUAHAHAHA!!11!!1

Typisch Spiele-Entwickler. Wohl ausschliesslich auf ATi-HW entwickelt und unbewusst diverse "Eigenheiten" der ATi-Hardware im Code ausgeglichen.

Jaein. Ich behaupte jetzt mal das sie AA vor ein paar Wochen zum ersten mal überhaupt eingeschaltet haben und dann gemerkt haben das es flimmiert wie die Hölle und da ATI ja ihr Technologie Partner ist hat man den schwarzen Peter erst mal an ATI weitergeschoben die natürlich gleich versprochen haben sich darum zu kümmern.

[Demirug]

Original geschrieben von Hellspawn
ich hab ne frage: vielleicht haben sie das ja gewusst, aber trotzdem ignoriert um die "normale" bildqualität zu steigern.. oder ist durch die verwendete technik KEINE verbesserung der grafik zu sehn?

Die Tricks welche man zum lösen des MSAA Problems benutzt haben wenn man es richtig macht keine Auswirkung auf die bildqualität ohne AA.

[Exxtreme]

Hmm, aber SSAA ist davon theroretisch NICHT betroffen, oder?

[Demirug]

Original geschrieben von Exxtreme
Hmm, aber SSAA ist davon theroretisch NICHT betroffen, oder?

Mit SSAA gibt es diese "Polyrand flimmer Problem" nicht da ja die Sampleposition mit der Prüfposition identisch ist. Gibt es denoch ein Pixelflimmern am Rand dann hat jemand bei den Texturekoordinaten mist gebaut aber das ist dann unabhängig vom AA ein Problem.

Ein AA Fullscreen Effekt Problem (von dem aber hier wohl nicht die Rede ist) kann es aber auch mit SSAA geben.

[Hellspawn]

hey demirug schreib doch ne email mit diesen kleinen einfach tricks um das flimmern zu beheben ;) wenns so leicht ist, schaffen sie es sicher noch bis zum rls hehe

[nggalai]

Hi Hellspawn,

das Problem ist, dass man da schon gaaaaaanz am Anfang hätte dran denken müssen. Das mal kurz zu "reparieren" dürfte einen enormen Aufwand bedeuten.

93,
-Sascha.rb

[Demirug]

Original geschrieben von Hellspawn
hey demirug schreib doch ne email mit diesen kleinen einfach tricks um das flimmern zu beheben ;) wenns so leicht ist, schaffen sie es sicher noch bis zum rls hehe

Das Problem ist das man das von Anfang an bei erzeugen der Texturen berücksichtigen muss. Nachträglich mal schnell einbauen ist da leider nicht drin.

PS: Und warum sollte ich eigentlich Valve helfen?

[Hellspawn]

Original geschrieben von Demirug
Das Problem ist das man das von Anfang an bei erzeugen der Texturen berücksichtigen muss. Nachträglich mal schnell einbauen ist da leider nicht drin.

PS: Und warum sollte ich eigentlich Valve helfen?

ähm wieso nicht?

[Desti]

Wenn die den HL2 Code unter GPL stellen, findet sich bestimmt ein freiwilliger. :)

[Demirug]

Original geschrieben von Hellspawn
ähm wieso nicht?

Weil Valve für das lösen der Probleme bezahlt wird und ich nicht.

[Demirug]

Original geschrieben von Desti
Wenn die den HL2 Code unter GPL stellen, findet sich bestimmt ein freiwilliger. :)

Das Problem liegt aber eher im Bereich des Content und nicht im Code.

[Gast]

Wieso sind Spiele-Entwickler für die Unzulänglichkeiten von Hardware-Hersteller verantwortlich? Deren Aufgabe ist es, Spiele zu machen. Die Aufgabe von Nvidia und Ati ist, fehlerfreie Hardware herzustellen. Valve muss sich meines Erachtens nicht darum kümmern, von vornherein krude Lösungswege für ein offensichtlich verbuggtes Hardware-Feature zu finden. Vor allem dann nicht, wenn der Entwicklungszyklus eines Spiels irgendwo zwischen 2-5 Jahren liegt und in dieser Zeit Trillionen von Grafikchips mit brandheißen Features auf den Markt geschissen werden, die in der Praxis erst 4 Generationen später einwandfrei funktionieren. Irgendwie werden hier gerade die Zuständigkeiten vertauscht.

und fangt bloß nicht an mit parolen wie "es ist Valves verdammte pflicht, dass AA auf jder Karte läuft." Das ist es nicht. Es ist die Pflicht der Hardwarehersteller, Features wie AA so umzusetzen, dass sie so funktionieren, wie man es von ihnen erwartet.

[betasilie]

Ich hatte da gestern übrigens schon mal ein Thread zu aufgemacht.
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=83002

[Becks]

Original geschrieben von betareverse
Ich hatte da gestern übrigens schon mal ein Thread zu aufgemacht.
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=83002

:|

ich werd so und so ohne AA und AF spielen, also ist´s mir eh egal!

wenn die grafik gut genug ist, für was AA u. AF???

[Iceman346]

Original geschrieben von Beckham
wenn die grafik gut genug ist, für was AA u. AF???

Damit die Grafik besser aussieht?

AA/AF ist imo eim Muss, egal bei welchem Spiel.

[nggalai]

Hi Gast,
Original geschrieben von Gast
Wieso sind Spiele-Entwickler für die Unzulänglichkeiten von Hardware-Hersteller verantwortlich? Deren Aufgabe ist es, Spiele zu machen. Die Aufgabe von Nvidia und Ati ist, fehlerfreie Hardware herzustellen. Valve muss sich meines Erachtens nicht darum kümmern, von vornherein krude Lösungswege für ein offensichtlich verbuggtes Hardware-Feature zu finden. Vor allem dann nicht, wenn der Entwicklungszyklus eines Spiels irgendwo zwischen 2-5 Jahren liegt und in dieser Zeit Trillionen von Grafikchips mit brandheißen Features auf den Markt geschissen werden, die in der Praxis erst 4 Generationen später einwandfrei funktionieren. Irgendwie werden hier gerade die Zuständigkeiten vertauscht.

und fangt bloß nicht an mit parolen wie "es ist Valves verdammte pflicht, dass AA auf jder Karte läuft." Das ist es nicht. Es ist die Pflicht der Hardwarehersteller, Features wie AA so umzusetzen, dass sie so funktionieren, wie man es von ihnen erwartet. Bitte lies den Thread nochmals durch, besonders das Original-Posting SEHR aufmerksam, und Demiurgs Kommentare. Betas Thread hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=83002) ist auch interessant. Auszug:Half-Life2 soll ja mit allen aktuellen GraKas kein FSAA nutzen können, da sie kein Centroid-Sampling können. Dies soll erst mit PS3.0-tauglichen GraKas gehen.Valve hat es offenbar versäumt, die nötigen Vorsichtsmassnahmen für MSAA zu beachten. Hat also einen "Fehler" gemacht. Wie kann sowas ein Versäumnis der IHV sein? MSAA funktioniert halt so, und hat die entsprechenden "Nachteile", wenn man eher exotische Verfahren anwenden möchte--was Valve hier offensichtlich nicht interessiert oder zu spät bemerkt hat. Was beides traurig ist.

Selbst bei ATI steht erst ein "hoffentlich fixbar" da. Weshalb steht da explizit ATI und nicht NV? Weil ATI Technologiepartner von Valve ist, Valve also direkt mit ATI an einer Treiberlösung arbeitet (arbeiten kann). Ob's hinhauen wird wissen wir dann später.

93,
-Sascha.rb

[Xmas]

Original geschrieben von Gast
und fangt bloß nicht an mit parolen wie "es ist Valves verdammte pflicht, dass AA auf jder Karte läuft." Das ist es nicht. Es ist die Pflicht der Hardwarehersteller, Features wie AA so umzusetzen, dass sie so funktionieren, wie man es von ihnen erwartet.
Das AA funktioniert genau so wie man es erwarten könnte.

[KiBa]

Aus technischer Sicht, welche Vorteile hat man eigentlich, wenn man mehrere kleine Texturen zu einer großen zusammenfasst? Klar, man spart ab und zu einen Texturwechsel und muss nur die Texturkoordinaten anpassen. Imo sollte das aber nicht mehr allzu viel Performance bringen, gegenüber mehreren "richtigen" Texturen... oder hat das Verfahren noch andere Vorteile?
Würde es nicht reichen, die Texturkoordinaten minimal anzupassen, dass sie auch mit AA innerhalb des Polygons liegen, oder gibt es dann bei den MipMaps Probleme?

[nggalai]

Hi KiBa,

Valve bewirbt ihre Engine und HL2 auch damit, dass "grosse" Oberflächen viel Variation zeigen werden. Dass also das bekannte Grass-Textur-bis-zum-Horizont Pattern nicht mehr sichtbar sein soll. Man braucht dafür entweder sehr sehr viele verschiedene "grosse" Texturen wie von dir vorgeschlagen oder man setzt die halt (bei Valve per Zufallsgenerator) "dynamisch" aus vielen kleinen zusammen. Vorteil: Man spart Speicherplatz (für 50 verschiedene Variationen von "Grass" braucht man nicht 50 grosse Grasstexturen, sondern es reichen eine handvoll kleine), man spart Zeit bei der Contenterstellung, und man kann bei den Spieleoptionen feiner auf die verschiedenen Grafikkarten und Speicherausstattungen eingehen.

Aber Hauptgrund ist eben, die Eintönigkeit zu reduzieren und mehr Abwechslung reinzubringen. Eigentlich ein guter Ansatz, zumindest, bis gutaussehende prozedurale Texturen "billig" zu haben sind. ;)

93,
-Sascha.rb

[Demirug]

btw: dieses Texturen zusammenkacheln kann auch zu Problemen beim AF führen.

Das AA Problem sollte aber auch noch jetzt auf jeder PS 2.0 fähigen Karten lösbar sein (mit einem NV3X Chip auf jeden Fall). Dafür muss man im Pixelshader die Texturekoordinaten entsprechend an den Grenzen kappen. Die Grenzen müssten im Vertexshader ermittelt werden. Das ganze kostet aber zusätzliche Rechenleistung.

[betasilie]

Original geschrieben von Iceman346
AA/AF ist imo eim Muss, egal bei welchem Spiel.
Also auf AA kann ich in 1280*1024 gerade so verzichten. Ohne AF könnte ich hingegen nicht. ;)

[Aquaschaf]

Original geschrieben von Gast
Wieso sind Spiele-Entwickler für die Unzulänglichkeiten von Hardware-Hersteller verantwortlich? Deren Aufgabe ist es, Spiele zu machen. Die Aufgabe von Nvidia und Ati ist, fehlerfreie Hardware herzustellen. Valve muss sich meines Erachtens nicht darum kümmern, von vornherein krude Lösungswege für ein offensichtlich verbuggtes Hardware-Feature zu finden. Vor allem dann nicht, wenn der Entwicklungszyklus eines Spiels irgendwo zwischen 2-5 Jahren liegt und in dieser Zeit Trillionen von Grafikchips mit brandheißen Features auf den Markt geschissen werden, die in der Praxis erst 4 Generationen später einwandfrei funktionieren. Irgendwie werden hier gerade die Zuständigkeiten vertauscht.

und fangt bloß nicht an mit parolen wie "es ist Valves verdammte pflicht, dass AA auf jder Karte läuft." Das ist es nicht. Es ist die Pflicht der Hardwarehersteller, Features wie AA so umzusetzen, dass sie so funktionieren, wie man es von ihnen erwartet.

Wie bereits geschrieben wurde besteht dieses Problem nicht, wenn man ein paar Dinge beim Erstellen der Texturen und der Texturkoordinaten beachtet, ist im übrigen bekannt und liegt in der Natur von MSAA.
Es ist also sehr wohl Valve´s "Schuld", wenn AA nicht funktioniert.

[tEd]

Ein paar Worte zum Problem/Lösung von "Sireric" ATi Hardware Engineer

It's not a special mode of AA. It has to do with the method used to sample textures. If you render a partial pixel, you need to sample the texture at that pixel to get a color for the fragment. What texture coordinate do you use for a partially covered pixel? You can use the pixel center (which is what is done in current drivers/specs), or, the R3xx allows you to sample at the centroid of the fragment.

Both systems have problems. Center of pixel can lead to sampling outside the texture, and then the application has to create a buffer region outside to compensate (but that buffer region can be unlimited, depending on the pixel/texel ratio). If you use centroid, you avoid that problem, but can create new ones in cases where you only want to sample a texel once (i.e. menus and text). We would need to way to allow the application to specify the kind of sampling wanted on each texture. That's not in the API now. However, the HW can do it. We might be able to do something in the control panel.

[egdusp]

@ Demi
Wenn das Problem eher in der Kontenerstellung liegt, warum können die dann nicht ein kleines Programm schreiben,was einfach alle Texturen analysiert und entsprechend anpasst?

mfg
egdusp

[betasilie]

Original geschrieben von Xmas
Das AA funktioniert genau so wie man es erwarten könnte.
Obwohl ich sicherlich nicht wirklich viel Ahnung habe von 3D-Technik habe, habe ich bei dem G-Man-Video schon geahnt, dass sich irgendwas beißt mit den PS-Techniken von HL2 und AA.

Ich habe es nicht gepostet, obwohl ich sowas erwartet habe, da ich kein Windei legen wollte. ;)

[Demirug]

Original geschrieben von egdusp
@ Demi
Wenn das Problem eher in der Kontenerstellung liegt, warum können die dann nicht ein kleines Programm schreiben,was einfach alle Texturen analysiert und entsprechend anpasst?

mfg
egdusp

Die Texturekoordinaten müssten auch angepasst werden. Das Problem dabei ist das durch eine solche nachträgliche Anpassung sich zu viel verschieben könnte als das man das Blind automatisch machen könnte. Es müsste also ein Grafiker am Ende nochmal über alles darüber schauen und von Hand korregieren. Das kostet Zeit die man bei Valve wohl nicht mehr investieren will.

[Demirug]

Original geschrieben von betareverse
Obwohl ich sicherlich nicht wirklich viel Ahnung habe von 3D-Technik habe, habe ich bei dem G-Man-Video schon geahnt, dass sich irgendwas beißt mit den PS-Techniken von HL2 und AA.

Ich habe es nicht gepostet, obwohl ich sowas erwartet habe, da ich kein Windei legen wollte. ;)

An den Pixelshader liegt das nicht. Diese sind da vollkommen neutral. Es liegt wirklich nur daran wie MSAA im Moment in den Karten implementiert ist.

[Becks]

Original geschrieben von Iceman346


AA/AF ist imo eim Muss, egal bei welchem Spiel.

wieso ein muss! bei 1280x1024 brauch ich kein AA und AF!:o

(ausser bei älteren spielen)

[Iceman346]

Original geschrieben von Beckham
wieso ein muss! bei 1280x1024 brauch ich kein AA und AF!:o

(ausser bei älteren spielen)

Das manche Leute auf AA verzichten können kann ich ja vielleicht noch einsehen (auch wenn ichs nicht möchte. AA beruhigt das Bild einfach) aber AF hat mit der Auflösung nichts zu tun sondern schärft die Texturen in jeder Auflösung gleich. Das sollte man eigentlich immer aktivieren ;)

[cyjoe]

Auf meinem TFT sehe ich bei 1280x1024 ohne AA aber ziemlich hefig die Treppeneffekte.

[aths]

Original geschrieben von cyjoe
Auf meinem TFT sehe ich bei 1280x1024 ohne AA aber ziemlich hefig die Treppeneffekte. ... genau wie ich mit meinem 19" Röhrenmoni. Selbst 1600x1200 würde ich da nur höchst ungerne ohne AA spielen.

[Craft]

Original geschrieben von Exxtreme
MUAHAHAHA!!11!!1

Typisch Spiele-Entwickler. Wohl ausschliesslich auf ATi-HW entwickelt und unbewusst diverse "Eigenheiten" der ATi-Hardware im Code ausgeglichen.


Jo finde ich auch scheisse.
Ist aber gerecht denn was macht EA ??
Da rennen die spiele mit einer ATI-Karte recht bescheiden.

EA ist wie eine fahne im Wind.
Die drehen sich immer in die einfachste(scheinbar Markbestimmende)Richtung.
Damals zu TNT2 Zeiten rannten deren Games nur auf Voodookarten gut.

[Kai]

Da bin ich froh, das ich mich lange noch nicht an AA gewöhnt habe und es mir ehrlich gesagt schnurz ist ob Half-Life 2 dazu kompatibel sein wird, alldiweil ich's eh nicht nutze. AF ist da was anderes, aber AA kann mir gestohlen bleiben (zumindest bis ich ein neues Graka-Beast im Rechner hab, dann gewöhn ich mich mal dran).

Also vermisse ich's auch nicht. Allerdings bin ich auch nicht unempfindlich. Schonmal PS1 oder PS2-Games gesehen? Die sehen total ÜBEL aus im verglichen zu heutigen PC-Games auf anständigen Auflösungen.

[Radeonator]

Das ist jawohl der Gipfel : Faule Programmierer bauen mist und die Graka Hersteller sollen es ausbaden ??? :crazy:

[reunion]

Binjetzt irgendwie nicht ganz mitgekommen...
Soll das heißen das man bei HL2 nur mit einer ATI Karte AA einschalten kann???

[Crazy_Bon]

Wo bleibt die Fraktion, die immer behauptet in Egoshooter würde eh nie vom AA proftieren, da man in actiongeladenen und schnellen Spielen eh nie darauf achten täte? :D

[LovesuckZ]

Original geschrieben von reunion
Binjetzt irgendwie nicht ganz mitgekommen...
Soll das heißen das man bei HL2 nur mit einer ATI Karte AA einschalten kann???

Valve hat Mist bei der Programmierung der Engine gebaut. Jez hat sich herausgestellt, dass es zu Problemen kommt, wenn man AA einschaltet. Da sie mit ATi zusammenarbeiten, meinen sie, dass sie das Problem eventuell in den griff bekommen koennten, bei Nvidia man sich aber keine Hoffnung machen braeuchte...

[reunion]

Original geschrieben von LovesuckZ
Valve hat Mist bei der Programmierung der Engine gebaut. Jez hat sich herausgestellt, dass es zu Problemen kommt, wenn man AA einschaltet. Da sie mit ATi zusammenarbeiten, meinen sie, dass sie das Problem eventuell in den griff bekommen koennten, bei Nvidia man sich aber keine Hoffnung machen braeuchte...

Das heißt das man nur "glaubt" es in den Griff zu bekommen un es selbst bei ATI Karten noch nicht fix ist ???
Wie kann man ein Spiel programmieren bei dem man AA nicht einschalten kann (ich dacht immer das ist unabhängig von den verwendeten Software)???

[dildo4u]

Original geschrieben von Crazy_Bon
Wo bleibt die Fraktion, die immer behauptet in Egoshooter würde eh nie vom AA proftieren, da man in actiongeladenen und schnellen Spielen eh nie darauf achten täte? :D
naja Q3 oder Ut2003 sind so schnell das man sagen könnte man kann auch AA verzichten aber HL2 is ein ziehmlich langsammer Schooter im vergleich ausserdem wenn die fps in ordnung sind zock ich immer mit 4XAA und wenns mal ruckelt zoch ich halt nur 1024*768 mit 4XAA andere games immer 1280*1024 4XAA ich wenns wirklich dabei bleibt das Hl2 kein AA bieten ist es für mich jedefalls nicht mehr die Engine die 2003 und 2004 Marktführer sein wird ich sag nur ein glück is Doom3 opengl das wird die sache mit den AA hoffentlich nicht so das Prob sein die ganze sache hat mit schon bei Splinter Cell angekotzt wegen irgendwelche nachtsicht gerät effekte musste man AA komplett auschalten

[the_MAD_one]

Original geschrieben von reunion
Das heißt das man nur "glaubt" es in den Griff zu bekommen un es selbst bei ATI Karten noch nicht fix ist ???
Wie kann man ein Spiel programmieren bei dem man AA nicht einschalten kann (ich dacht immer das ist unabhängig von den verwendeten Software)???

Es gibt doch afaik schon mehrere Spiele bei denen man aufgrund bestimmter Ingame Effekte kein AA benutzen kann.(z.B. DTMRD, Collin3, MotoGP2, Splinter Cell)

[Kai]

Original geschrieben von Crazy_Bon
Wo bleibt die Fraktion, die immer behauptet in Egoshooter würde eh nie vom AA proftieren, da man in actiongeladenen und schnellen Spielen eh nie darauf achten täte? :D

*meld* Ich emfpinde es zumindest so ... wobei ich mir noch nicht sicher bin, ob HL2 wirklich ein schneller und Actiongeladener Shooter wird.

[LovesuckZ]

Oh, ging ja schnell. Wohl einer daneben geklickt...

[Kai]

Original geschrieben von LovesuckZ
Oh, ging ja schnell. Wohl einer daneben geklickt...

Siehe PM. Ist mir unbegreiflich warum der Thread zu war ...

[LovesuckZ]

Original geschrieben von reunion
Das heißt das man nur "glaubt" es in den Griff zu bekommen un es selbst bei ATI Karten noch nicht fix ist ???


jap. Ob sie es bis zum Relase beheben koennen, ist ungewiss.

[dildo4u]

Original geschrieben von Kai
Da bin ich froh, das ich mich lange noch nicht an AA gewöhnt habe und es mir ehrlich gesagt schnurz ist ob Half-Life 2 dazu kompatibel sein wird, alldiweil ich's eh nicht nutze. AF ist da was anderes, aber AA kann mir gestohlen bleiben (zumindest bis ich ein neues Graka-Beast im Rechner hab, dann gewöhn ich mich mal dran).

Also vermisse ich's auch nicht. Allerdings bin ich auch nicht unempfindlich. Schonmal PS1 oder PS2-Games gesehen? Die sehen total ÜBEL aus im verglichen zu heutigen PC-Games auf anständigen Auflösungen.

1 hör auf immer die konsolen zu Baschen ;-) und naja ich denk schon das es ne DX9 karte bei HL2 bringt schlieslich fehlen z.B Bump Mapping auf den figuren bei na DX8 karte von daher wer alle Efekkte sehn will braucht ne DX9 karte

@ lovesuck ich kann die seite nicht mehr finden kannste die noch mal posten da war ein bericht aus na PC zeitung der zeiget welche Effekte man mit DX6.7.8.9 zu sehen bekommt bei HL2

[Kai]

Original geschrieben von dildo4u
1 hör auf immer die konsolen zu Baschen ;-) und naja ich denk schon das es ne DX9 karte bei HL2 bringt schlieslich fehlen z.B Bump Mapping auf den figuren bei na DX8 karte

Gibt's dafür ne Quelle? Technisch gesehen ist das absoluter Nonsens, weil sowas natürlich mit einer DX8 Karte geht - aber wenn die sich dafür entscheiden BM für Figuren bei DX8 Karten abzuschalten ...

Mir isses eigentlich Worscht. Bis dahin hab ich wohl mein neues Sys und muss mir über sowas keinen Kopf mehr tun. Wobei ich allerdings wie bei Doom3 keine Wunder erwarte was die Performance bei HL2 angeht - selbst bei einem High-End Gerät.

[dildo4u]

Original geschrieben von Kai
Gibt's dafür ne Quelle? Technisch gesehen ist das absoluter Nonsens, weil sowas natürlich mit einer DX8 Karte geht - aber wenn die sich dafür entscheiden BM für Figuren bei DX8 Karten abzuschalten ...

Mir isses eigentlich Worscht. Bis dahin hab ich wohl mein neues Sys und muss mir über sowas keinen Kopf mehr tun. Wobei ich allerdings wie bei Doom3 keine Wunder erwarte was die Performance bei HL2 angeht - selbst bei einem High-End Gerät.

http://www.hanners.nildram.co.uk/hl2/maxhl26.jpg

http://www.hanners.nildram.co.uk/hl2/maxhl25.jpg

http://www.hanners.nildram.co.uk/hl2/

irgendwie wird für das bumpmapping auf na DX9 karte Displacement mapping genutzt daher funzt das nich auf den figuren
axo ich seh grad das mit den Bumpmapping auf die figuren gilt nur fürs specular Bumpmapping aber egal mir gehts halt nur darum das halt Efekkte fehlen mit na DX8 karte wer damit leben kann ok ich kanns nich ick will alles sehn ;-)

[liquid]

Hmm, für mich wird das wohl keine große Rolle spielen, da ich wie Kai fast überhaupt kein AA benutze. Aber wenn sich das Zusammenpacken von vielen kleinen Texturen mit MSAA beißt, dann gibt es das Problem nicht nur bei HL2.

Ich meine mich erinnern zu können, dass die Quake-Engine (entweder 1 oder 2) auch viele kleine Texturen in eine große packt, um mehr Performance zu erreichen und (aber da bin ich mir nicht ganz sicher) um Probleme mit GraKa-Treibern aus dem Weg zu gehen.

cya
liquid

EDIT:
Es war die Quake2-Engine. In ref_gl/gl_image.c findet man folgenden Kommentar:
/*
================================================

scrap allocation

Allocate all the little status bar obejcts into a single texture
to crutch up inefficient hardware / drivers

================================================*/


Line gekürzt, um die Breite nicht überbordend werden zu lassen - aths

[Exxtreme]

Naja, für die NV-Fraktion ist noch nichts verloren.

Supersampling hat derartige Probleme nicht. Wenn Nvidia sich entschliessen sollte, reines SSAA anzubieten in den Treibern dann wäre das Problem auch aus der Welt.

[LovesuckZ]

Original geschrieben von Exxtreme
Supersampling hat derartige Probleme nicht. Wenn Nvidia sich entschliessen sollte, reines SSAA anzubieten in den Treibern dann wäre das Problem auch aus der Welt.

Unter D3D gibt es 4SSAA, doch war es nicht so, dass dies selbst in MotoGP2 nicht funktionierte?

[Demirug]

Original geschrieben von LovesuckZ
Unter D3D gibt es 4SSAA, doch war es nicht so, dass dies selbst in MotoGP2 nicht funktionierte?

Bei MotoGP2 hat das andere Gründe: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=80688

[silverhawk]

wie unterscheidet sich denn eigentlcih genau das reine supersampling vom quincuix verfahren?

[mapel110]

Original geschrieben von silverhawk
wie unterscheidet sich denn eigentlcih genau das reine supersampling vom quincuix verfahren?

http://www.3dcenter.de/artikel/anti-aliasing/
da mehr zu dem thema.

http://www.computerbase.de/news.php?id=5727&sid=e70956633c99262b6bdc3ef5f84c1f8b
computerbase news dazu. würd mich mal interessieren, wie die das mit ATI in den griff bekommen wollen. hoffentlich wirds nicht so ne lösung, die so lahm ist, dass es sinnvoller ist, ne höhere auflösung zu wählen.

[zeckensack]

Vielen Dank Valve, jetzt wissen wir endlich daß ihr im Grunde auch nur ganz normale Deppen seid.

Nochmal zum Mitdenken:
Texturen und Mipmaps werden gefiltert, um bei optimaler Qualität Aliasing zu vermeiden. "Bessere" Filter benutzen dafür mehr Informationen aus der Textur und erhöhen somit die Schärfe, auch diese müssen sich aber an Onkel Nyquist (http://www.google.com/search?q=nyquist+theorem&sourceid=opera&num=0&ie=utf-8&oe=utf-8) orientieren. Die höchstmögliche 'Frequenz' der aufgelegten Textur wird durch den Abstand des Pixelrasters vorgegeben, der Filter hat lediglich die Aufgabe, aus dem gegebenen Material so auszuwählen, daß dieser Frequenzspielraum möglichst genau ausgenutzt wird.

Erhöht man beispielsweise die Maximalfrequenz (indem man ganz mundän die Auflösung heraufsetzt), so verändert dies die Filter-Regeln.

Damit der Filter seine Funktion überhaupt erfüllen kann, ist jedweder Eingriff der Applikation verboten. Punkt, Ende, aus. Wer sich da einmischt, der darf dies nur unter strengen Voraussetzungen tun. Dafür muß natürlich erstmal wissen was man da überhaupt macht :eyes:

Wenn man nicht wild herumdoktort, dann erkennt man auch die Vorteile des stinknormalen Texturfilters: man kann Objekte drehen und wenden wie man will, man kann die Auflösung nach Belieben verändern, und ohne sich um irgendwas kümmern zu müssen sieht es nie scheiße aus.

Bei Texturen, die nur senkrecht betrachtet werden (eben die erwähnte Overlay-Grafik und Billboards) lässt sich einigermaßen sicher voraussagen, wieviel Information (=Texel) einfließt. Bei Texturen, die generell im Bild zum Einsatz kommen können, geht das eben nicht. Jedweder Sicherheitsabstand, den man in Texturen einfügt, kann nur grob geraten sein. Raten reicht nicht.

Epic hat versagt, Valve folgt, einige beliebte Rennspiele, etc, und die Grafikindustrie darf's ausbaden. Ganz tolle Idee.

Das ist nicht nur ein Problem mit AA. Das für die Machbarkeit von Valve's unglaublich schlauer Idee - ohne AA - nötige "Fummeln" an den Texturkoordinaten, das wissen die die oben mitgelesen haben, ist auch auflösungsabhängig. Will uns Valve vielleicht auch vorschreiben, daß HL2 nur in 800x600 gespielt werden darf, weil "Laut Umfragen 92% aller Amerikaner mit der Default-Einstellung zufrieden sind"?

Wird uns Valve auch davon abhalten, AF zu aktivieren? Oder dürfen wir auf die ganz harte Tour rausbekommen, daß sie nicht verstanden haben, was Texturfilter sind (so wie zB bei DeusEx)?

Und überhaupt, die angebliche Lösung "centroid sampling" ist ja wohl ein schlechter Scherz. Dann kriegen zwei benachbarte Pixel halt die gleiche Texturfarbe ab, echt riesig. Das ist doch totaler Blödsinn ...
Die Übertragungsfunktion "Texturfrequenz" zu "Bildschirmfrequenz" ist bei MSAA sowieso schon perfekt. Durch centroid sampling wird nichts besser, im Gegenteil. Der einzige "Vorteil" ist, daß sich Valve weiterhin ungestraft ins Knie schießen kann, und darauf kann ich verzichten.

[zeckensack]

Original geschrieben von Exxtreme
Naja, für die NV-Fraktion ist noch nichts verloren.

Supersampling hat derartige Probleme nicht. Wenn Nvidia sich entschliessen sollte, reines SSAA anzubieten in den Treibern dann wäre das Problem auch aus der Welt. Das bezweifle ich, ehrlich gesagt.
Das was Valve da macht (mehrere Texturen zusammenbacken) kann überhaupt nicht funktionieren. Stell dir mal die kleinste Mipmap aus einer solchen Back-Textur vor, da sind dann Farben aus allen 'gewollten' Texturen zu einem einzigen Texel zusammengemischt. Wie soll das richtig aussehen. Da kann ich 'Sicherheitsabstände' einbacken so viel ich will, da kann ich "centroid sampling" machen bis ich schwarz werde, das Ergebnis wird immer falsch sein.

Die einzige Hoffnung die man da haben kann, ist daß sich die zusammengewuselten Texturen farblich ähnlich sind, und somit die Fehler nicht so stark sichtbar sind.

Ad SS: IMO hat das mit AA ja nicht das geringste zu tun, aber sei's drum ...
Wenn Valve Sicherheitsbänder in die Texturen setzt, und die Texturkoordinaten anpaßt, dann müssen für diese Anpassung die Bildschirmauflösung, und der Abstand der Textur von der Kamera bekannt sein.

Erstere Möglichkeit existiert bei per Panel erzwungenem SS nicht, weil die 'echte', interne Auflösung der App nicht bekannt ist.

Btw, zweiteres funktioniert sowieso nie richtig, weil man das nur per Vertex sinnvoll berechnen kann (es sei denn, man benutzt einen Software-Renderer ...).

[zeckensack]

Sascha,
Original geschrieben von nggalai
Hi KiBa,

Valve bewirbt ihre Engine und HL2 auch damit, dass "grosse" Oberflächen viel Variation zeigen werden. Dass also das bekannte Grass-Textur-bis-zum-Horizont Pattern nicht mehr sichtbar sein soll. Man braucht dafür entweder sehr sehr viele verschiedene "grosse" Texturen wie von dir vorgeschlagen oder man setzt die halt (bei Valve per Zufallsgenerator) "dynamisch" aus vielen kleinen zusammen. Vorteil: Man spart Speicherplatz (für 50 verschiedene Variationen von "Grass" braucht man nicht 50 grosse Grasstexturen, sondern es reichen eine handvoll kleine), man spart Zeit bei der Contenterstellung, und man kann bei den Spieleoptionen feiner auf die verschiedenen Grafikkarten und Speicherausstattungen eingehen.

Aber Hauptgrund ist eben, die Eintönigkeit zu reduzieren und mehr Abwechslung reinzubringen. Eigentlich ein guter Ansatz, zumindest, bis gutaussehende prozedurale Texturen "billig" zu haben sind. ;)

93,
-Sascha.rb Mir ist nicht ganz klar, wie das Kacheln von Texturen die Variationsmöglichkeiten erhöht :|
Man braucht den gleichen Speicherplatz, und die gleiche Menge an 'Rohmaterial' (eben Grafiker-Output). Ob man das ganze dann kachelt oder nicht, spielt dabei keine Rolle (für die Performance möglicherweise schon, aber eben nicht für die Varianz).

[Demirug]

Original geschrieben von zeckensack
Sascha,
Mir ist nicht ganz klar, wie das Kacheln von Texturen die Variationsmöglichkeiten erhöht :|
Man braucht den gleichen Speicherplatz, und die gleiche Menge an 'Rohmaterial' (eben Grafiker-Output). Ob man das ganze dann kachelt oder nicht, spielt dabei keine Rolle (für die Performance möglicherweise schon, aber eben nicht für die Varianz).

ja es ist eine reine performance Geschichte.

Das Kacheln von Texturen funktioniert im Prinzip schon. Aaber man muss dabei sehr viel beachten. Man darf zum Beispiel nicht blind bis zur 1 Pixel Mip-Map durchfiltern sondern muss dann aufhören wenn die einzelnen Kacheln sonst vermischt würden. Die Sicherheitsrändern zwichen den Kacehln müssen auch noch in der kleinsten Auflösung der Textur ausreichend sein.

Deine bedenken wegen SSAA und centroid kann ich nicht ganz teilen. Das Problem mit dem Pixelflimmern am Rand und MSAA kommt ja daher das die Texturekoordinate aus der richtigen Kachel hinausrutsch. Das Problem gibt es ja auch ohne gekachelte Texturen wenn man sich am Rand einer Texture bewegt und MSAA benutzt und vergessen hat den texture-addressing mode von Wrap (default bei DX) auf Clamp oder auch mirror. Bei SSAA und centroid ist es aber unmöglich das durch das AA ein hinausrutschen der Texturekoordinate passieren kann. Bei SSAA würden Samples bei denen das der Fall ist ja verworfen werden weil sie ausserhalb der Dreiecksgrenze liegen. Bei centriod wird eine Anpassung der Texturekoordinaten vorgenommen das diese wieder einer Koordinate innerhalb der Dreiecksgrenze entspricht. Dabei kann es übrigens nicht passieren das zwei benachtbarte Pixel die exact gleiche Koordinaten bekommen (ausnahme: Wenn auch ohne AA zwei benachtbarte Pixel die gleichen Korrdinaten haben kann centriod daran auch nichts ändern). Ob diese Koordinaten dann auf die gleichen Texels verweisen ist natürlich eine andere Sache aber durch die unterschiedlichen Koordinaten wird sich ja auch die gewichtung im Filter ändern womit das ganze wieder passt.

Das mit der Auflösung sehe ich eigentlich auch nicht als Problem weil die Karte/Chip die Auflösung kennt und dieses beim Texturefiltern berücksichtigen sollte. Allerdings sollte man von Bias besser die Finger lassen.

Das Problem liegt IMHO wirklich nur an den Texturekoordinaten die aus der Kachelgrenze herauswandern können. Bei den PS >= 2.0 besteht ja die möglichkeit die Koordinaten vor dem Samplen wieder in den gültigen Bereich zurückzuholen (Mit Min, Max). Für Karten mit PS < 2.0 und MSAA habe ich aber bis jetzt noch keine Lösung gefunden die sich nachträglich einbauen lassen würde.

[nggalai]

Hi ZBag,
Original geschrieben von zeckensack
Sascha,
Mir ist nicht ganz klar, wie das Kacheln von Texturen die Variationsmöglichkeiten erhöht :|
Man braucht den gleichen Speicherplatz, und die gleiche Menge an 'Rohmaterial' (eben Grafiker-Output). Ob man das ganze dann kachelt oder nicht, spielt dabei keine Rolle (für die Performance möglicherweise schon, aber eben nicht für die Varianz). Ich hab's mir so erklären lassen:

Ziel: Du willst eine 1024x1024 Fläche mit 4 verschiedenen Quadraten belegen, sagen wir Rot, Grün, Gelb, Blau, und zwar je oben links, oben rechts, unten links und unten rechts. Du möchtest alle möglichen Variationen davon anbieten können. Das wären dann 4 verschiedene Teiltexturen pro "Ecke", also 4x4x4x4 = 256 Variationen. Wenn Du alle 256 Variationen als "grosse" Textur anbieten möchtest, brauchst Du 256 1024x1024 Texturen. Mit Valves Ansatz sind's nur 4 Texturen à 512x512.

Statt krass verschiedene Texturen (im einfachen Beispiel oben was Rotes, Grünes, Gelbes, Rotes) geht's nun hier darum, dass Du z.B. von einer Grasoberfläche 4 leicht unterschiedliche Versionen machst. Der Grafiker muss also im Beispiel nicht ein Set von 1024x1024er Texturen machen (sagen wir mal 50 Variationen davon), sondern nur 4 Variationen à 512x512 bereitstellen. z.B. einmal Grass "ohne alles", einmal "etwas dunkleres Gras" (natürlich nicht die ganze Fläche, sonst hast Du Quadrate auf der Oberfläche ;) ), einmal "etwas helleres Gras" und einmal "Gras mit Dreck". Valve denkt offenbar, dass die "Grundkachel" nicht zu auffällig, well, kacheln. Ob das hinhauen wird und wirklich "variantenreicher" aussieht als einfach eine grosse Basistextur und ein set von Detailtexturen sehen wir dann im September. ;)

93,
-Sascha.rb

[zeckensack]

Original geschrieben von nggalai
Hi ZBag,
Ich hab's mir so erklären lassen:

Ziel: Du willst eine 1024x1024 Fläche mit 4 verschiedenen Quadraten belegen, sagen wir Rot, Grün, Gelb, Blau, und zwar je oben links, oben rechts, unten links und unten rechts. Du möchtest alle möglichen Variationen davon anbieten können. Das wären dann 4 verschiedene Teiltexturen pro "Ecke", also 4x4x4x4 = 256 Variationen. Wenn Du alle 256 Variationen als "grosse" Textur anbieten möchtest, brauchst Du 256 1024x1024 Texturen. Mit Valves Ansatz sind's nur 4 Texturen à 512x512.Man kann die Einzelstücke doch viel bequemer mit Multitexturing kombinieren :|

... und hat dabei noch die freie Auswahl an Clamp-Modi, gerade für Landschaftstexturen bieten sich sich doch GL_REPEAT oder GL_MIRRORED_REPEAT (ich hoffe du kannst mir folgen ;)) an. Bei Kacheln kann man das vergessen, da man ja eben auf die 'Subtextur' 'clampen' muß.

[aths]

Original geschrieben von Exxtreme
Naja, für die NV-Fraktion ist noch nichts verloren.

Supersampling hat derartige Probleme nicht. Wenn Nvidia sich entschliessen sollte, reines SSAA anzubieten in den Treibern dann wäre das Problem auch aus der Welt. Wie Lovesucks schon erwähnte, NV _bietet_ für D3D reines OGSSAA an. Diesen Modus würde ich aber nie im Leben benutzen, wegen des grauenhaften Leistungseinbruchs im Vergleich mit dem Qualitätsgewinn.
Original geschrieben von silverhawk
wie unterscheidet sich denn eigentlcih genau das reine supersampling vom quincuix verfahren? Quincunx hat mit Supersampling nichts zu tun, es handelt sich um Multisampling und einem Unschärfefilter.

[zeckensack]

Original geschrieben von Demirug
ja es ist eine reine performance Geschichte.

Das Kacheln von Texturen funktioniert im Prinzip schon. Aaber man muss dabei sehr viel beachten. Man darf zum Beispiel nicht blind bis zur 1 Pixel Mip-Map durchfiltern sondern muss dann aufhören wenn die einzelnen Kacheln sonst vermischt würden. Die Sicherheitsrändern zwichen den Kacehln müssen auch noch in der kleinsten Auflösung der Textur ausreichend sein.LOD-clamp, also. Kenn ich. Mag ich nicht :bäh:
Hier paßt wieder die Signaltheorie nicht, unterhalb der 'kleinsten sinnvollen' Mip-Stufe kriege ich dann den gleichen Effekt wie ganz ohne Mipmapping: massives Aliasing. Sieht besonders gut aus, wenn es großflächig nahe am Horizont auftritt (Aliasing ist bei langsamer Bewegung sowieso auffälliger) :krank:
Deine bedenken wegen SSAA und centroid kann ich nicht ganz teilen.Ich zitier mich mal selbst:
Originally posted by zeckensack:
From a signal theory pov (which is the only way to go for texture filtering), "centroid sampling" or whatever they like to call it is pure nonsense.

Q: My audio samples exhibit an annoying click at the end. What can I do?
A: Duplicate and repeat the last sample.

*shudder*
Um das weiter zu generalisieren, anstatt daß nun die Kacheln 'ineinanderbluten', wird am Rand einfach irgendein nicht näher bestimmbares Texel genommen. Das einzige was man mit Sicherheit über die Sampleposition sagen kann, ist daß sie innerhalb der Kachel liegt :bonk:

Der ist neu:
Q: What's centroid sampling.
A: It's a novel technique that pads texture borders with random garbage. Valve thinks it's pretty cool.
Das Problem mit dem Pixelflimmern am Rand und MSAA kommt ja daher das die Texturekoordinate aus der richtigen Kachel hinausrutsch. Das Problem gibt es ja auch ohne gekachelte Texturen wenn man sich am Rand einer Texture bewegt und MSAA benutzt und vergessen hat den texture-addressing mode von Wrap (default bei DX) auf Clamp oder auch mirror. Bei SSAA und centroid ist es aber unmöglich das durch das AA ein hinausrutschen der Texturekoordinate passieren kann.Mooooment.
Es geht nicht um 'die' Texturkoordinate, sondern um die daraus resultierenden Filterpositionen, die sich um die Texturkoordinate herum gesellen. Der Abstand der Samplepositionen ist sehr wohl eine Funktion der (internen) Auflösung. Der beträgt bei 'normalem' bilinearem Filter maximal ein halbes Texel in jede Richtung. Die Größe eines Texel in Texturkoordinaten gemessen ist aber eine Funktion des Mipmap-Levels, dieser wiederum ist abhängig von der internen Raster-Auflösung.
Daraus schließe ich, daß die Auflösung bekannt sein muß, um die Texturkoordinaten halbwegs korrekt anpassen zu können. Ganz davon abgesehen, daß ich niemals auf die Idee käme, so etwas zu implementieren (wozu auch?), halte ich nämlich eine adaptive 'Verschiebung' der Texcoords - eben abhängig vom hoffentlich bekannten Mipmap-Level - für erforderlich.

Die komplette Idee fängt nun leider schon bei Trilinear an auseinanderzubröseln, bei AF kann man's gleich vergessen.

Man stelle sich ferner vor, ein Grafikchip würde einen ganz besonders hochwertigen Tri-Filter implementieren, der die 'hintere' Mipmap-Stufe abhängig von der Pixel-'Neigung' seitlich verschiebt. Semi-AF sozusagen :|

Bei SSAA würden Samples bei denen das der Fall ist ja verworfen werden weil sie ausserhalb der Dreiecksgrenze liegen. Bei centriod wird eine Anpassung der Texturekoordinaten vorgenommen das diese wieder einer Koordinate innerhalb der Dreiecksgrenze entspricht.Das ist signaltheoretisch trotzdem schreiender Unsinn, weil das AA-Subpixel eben einen festen, nicht veränderbaren Raum belegt. Ganz genauso wie ein 'vollwertiger' Pixel ohne AA. Ich will garnicht erst wissen, wie das in kleiner Auflösung mit hoher AA-Stufe aussieht. Die Kante ist dann zwar schön glatt, aber einfarbig, kennt man ja aus der Filmindustrie. Dort sagt man dann "Aha, Bluescreen! Ich seh's ganz genau!".
Dabei kann es übrigens nicht passieren das zwei benachtbarte Pixel die exact gleiche Koordinaten bekommenIst klar, trotzdem wird die Signalfrequenz punktuell verringert (Kanten), und woanders überhöht (kleine Mipmaps, siehe oben). Die ganzen Workarounds machen das Bild nicht "gut", nur "anders schlimm".
Das mit der Auflösung sehe ich eigentlich auch nicht als Problem weil die Karte/Chip die Auflösung kennt und dieses beim Texturefiltern berücksichtigen sollte. Allerdings sollte man von Bias besser die Finger lassen.S.o. Ich hätte die Anpassung (ohne centroid) eben gerne adaptiv, und das muß dann doch die App machen. Und (adaptiven) Bias hat's dann ja sowieso, wenn du einräumst daß man die kleinsten Mipmap-Stufen wegclampen muß.
Das Problem liegt IMHO wirklich nur an den Texturekoordinaten die aus der Kachelgrenze herauswandern können. Bei den PS >= 2.0 besteht ja die möglichkeit die Koordinaten vor dem Samplen wieder in den gültigen Bereich zurückzuholen (Mit Min, Max). Für Karten mit PS < 2.0 und MSAA habe ich aber bis jetzt noch keine Lösung gefunden die sich nachträglich einbauen lassen würde. Es existiert noch eine ganz andere Möglichkeit, dieses hausgemachte Problem zu lösen:
Man benutzt einfach eine Textur pro Textur; und lässt seine Pfoten aus Sachen heraus, die man nicht sinnvoll kontrollieren kann.

[Demirug]

Original geschrieben von zeckensack
Man kann die Einzelstücke doch viel bequemer mit Multitexturing kombinieren :|

... und hat dabei noch die freie Auswahl an Clamp-Modi, gerade für Landschaftstexturen bieten sich sich doch GL_REPEAT oder GL_MIRRORED_REPEAT (ich hoffe du kannst mir folgen ;)) an. Bei Kacheln kann man das vergessen, da man ja eben auf die 'Subtextur' 'clampen' muß.

Ja und Nein. Das Kacheln hat mehrer Vorteile.

1. Reduzieren der Drawcalls. Wenn man 4 Texturen zusammenfasst braucht man für das Rendern des Geländes nur noch ein viertel der Calls gegenüber einzelnen Texturen. Die 4 Texturen auf 4 Sampler zu setzten und dann via Multitexturing jeweils den gewüschten teil aus jeder Texture zu nehmen ist auch keine Alternative weil das zuviel Füllrate kostet.

2. Viel mehr Kombinationsmöglichkeiten von Base und Detailmap ohne die Drawcalls in die höhe zu treiben. Wenn man die Base und Detailmap für jweils 4 Kacheln auslegt so gibt es 4*4 = 16 Kombinationsmöglichkeiten. Hat man die Texturen einzeln müsste man 16 DrawCalls benutzten um alle kombinationen abzudecken.

3. Die Vertexdaten können zum Teil Neutral gespeichert werden. Die Grunddaten für eine Geländetile sind ja immer gleich. Die veränderlichen Daten (Höhe, Basekachel, Detailkachel) können dann über einen zweiten Vertexstream kommen welcher sich pro Tile ändert. Das ganze spart auch wieder etwas Speicher.

[zeckensack]

Original geschrieben von Demirug
Ja und Nein. Das Kacheln hat mehrer Vorteile.

1. Reduzieren der Drawcalls. Wenn man 4 Texturen zusammenfasst braucht man für das Rendern des Geländes nur noch ein viertel der Calls gegenüber einzelnen Texturen. Die 4 Texturen auf 4 Sampler zu setzten und dann via Multitexturing jeweils den gewüschten teil aus jeder Texture zu nehmen ist auch keine Alternative weil das zuviel Füllrate kostet.

2. Viel mehr Kombinationsmöglichkeiten von Base und Detailmap ohne die Drawcalls in die höhe zu treiben. Wenn man die Base und Detailmap für jweils 4 Kacheln auslegt so gibt es 4*4 = 16 Kombinationsmöglichkeiten. Hat man die Texturen einzeln müsste man 16 DrawCalls benutzten um alle kombinationen abzudecken.

3. Die Vertexdaten können zum Teil Neutral gespeichert werden. Die Grunddaten für eine Geländetile sind ja immer gleich. Die veränderlichen Daten (Höhe, Basekachel, Detailkachel) können dann über einen zweiten Vertexstream kommen welcher sich pro Tile ändert. Das ganze spart auch wieder etwas Speicher. Man muß beim Kacheln die Kachel-Texturen auch an alle Sampler binden :|

Aber ich weiß, worauf du hinauswillst. Nun, 4x4x4x4 mögliche Variationen pro Frame macht im worst case 256 draw calls pro Frame für's Terrain. Pah! Peanuts ...

Und wenn draw calls das Problem sind, würde ich vorschlagen daß man das Problem eventuell gleich an der Wurzel anpackt. Merke: wenn zwei Lösungen für ein Problem unter den aktuellen Anforderungen gleichwertig sind, wähle diejenige, die besser skaliert :stareup:


Das Kacheln hat auch noch einen weiteren Nachteil, den wir hier nicht verschweigen wollen ;)

Man kann keine automatische Textur-Wiederholung nutzen. Man kann bestenfalls 'mirrored repeat' emulieren. Ob man sich dafür entscheidet, oder nicht, behebt aber nicht das folgende:
Man braucht ein 'regular grid', ie viele, dicht aneinanderliegende Vertices. Für statisches Terrain ohne dynamisches, nicht-HW-realisiertes Displacement (~99% aller Terrain-Renderer) kann man das mit den üblichen Verfahren wegoptimieren, und spart schonmal vorneweg massiv Geometrie.

[MadManniMan]

Eieieieieieii...

Ich habs gewußt! Ich habs gewußt... "irgendein Mist erwartet uns mit der Source-Engine noch, Jungens!" - und man lachte über mich. "Mach du doch deine Schattenspielchen in 800 mit Jaggies! Wir üben uns mit echter Physik in schön realen Szenarien..."

...tönten meine Kumpels und wollten darauf anspielen, daß D3 eh nur ein plastilliner HW-Fresser würde, während HL2 endlich mal Realismus ( :crazy: ) auf den Schirm zaubern würde.

Tja, PGH, würde ich sagen. Ich persönlich bekomme Anfälle, wenn ich Spiele zcoke, die Wert auf korrekte Umgebungssimulation legen (Rennspiele, BF42-Landschaft) und ich aber AA auslassen muß.

Nun, danke Valve! :up: Danke, daß ich mir keine Gedanken darüber machen werden muß, ob ich lieber doch 1280 nehme oder AA mit 800 genieße! Juhu!
...aber das alles wird mir natürlich kaum auffallen, weil ich mich eh schon zu sehr darüber freue, daß dank des AF-Probs alles so wie in meinen guten alten VooDoo1-Ich-Liebe-640-Zeiten aussieht.


:w00t:

[Demirug]

Original geschrieben von zeckensack
LOD-clamp, also. Kenn ich. Mag ich nicht :bäh:
Hier paßt wieder die Signaltheorie nicht, unterhalb der 'kleinsten sinnvollen' Mip-Stufe kriege ich dann den gleichen Effekt wie ganz ohne Mipmapping: massives Aliasing. Sieht besonders gut aus, wenn es großflächig nahe am Horizont auftritt (Aliasing ist bei langsamer Bewegung sowieso auffälliger) :krank:

Bei reiner bi und tri filterung ist das alles nicht kritisch weil ja nur um die Texturekoordinate herungesampelt wird. Dazu muss der Clamp auf der Ebene statfindet in der pro Kachel nur 4 Texel + Sicherheitsrand vorhanden sind. Beim AF könnte es aber durchaus dumm laufen.

Um das weiter zu generalisieren, anstatt daß nun die Kacheln 'ineinanderbluten', wird am Rand einfach irgendein nicht näher bestimmbares Texel genommen. Das einzige was man mit Sicherheit über die Sampleposition sagen kann, ist daß sie innerhalb der Kachel liegt :bonk:

Der ist neu:
Q: What's centroid sampling.
A: It's a novel technique that pads texture borders with random garbage. Valve thinks it's pretty cool.

Nicht irgendeine Position. Das wäre ja nun wirklich blöd. Die Position bleibt schon noch innerhalb des Pixels wird aber dort in den Bereich geschoben wo auch noch wirklich das Dreieck den Pixel bedeckt.

Mooooment.
Es geht nicht um 'die' Texturkoordinate, sondern um die daraus resultierenden Filterpositionen, die sich um die Texturkoordinate herum gesellen. Der Abstand der Samplepositionen ist sehr wohl eine Funktion der (internen) Auflösung, und beträgt bei 'normalem' bilinearem Filter maximal ein halbes Texel in jede Richtung. Die Größe eines Texel in Texturkoordinaten gemessen ist aber eine Funktion des Mipmap-Levels, dieser wiederum ist abhängig von der internen Raster-Auflösung.
Daraus schließe ich, daß die Auflösung bekannt sein muß, um die Texturkoordinaten halbwegs korrekt anpassen zu können. Ganz davon abgesehen, daß ich niemals auf die Idee käme, so etwas zu implementieren (wozu auch?), halte ich nämlich eine adaptive 'Verschiebung' der Texcoords - eben abhängig vom hoffentlich bekannten Mipmap-Level - für erforderlich.

Wenn die Texturekoordinaten so sind das sie immer bis maximal zum Rand der Kachel gehen dann kann der bi/tri Filter maximal ein Texel über den Rand hinausgehen. Das dumme ist eben nur das man diesen Texel auf der kleinsten Mip-Map braucht und auf der grössten werden da dann ganz schnell sehr viele Texel daraus und man hat dann mehr Texel für den Rand als für die eigentliche Texture. Dadurch wird das ganze natürlich irgendwie schon etwas blöd.

Die komplette Idee fängt nun leider schon bei Trilinear an auseinanderzubröseln, bei AF kann man's gleich vergessen.

Bei Tri geht es noch aber beim AF gebe ich dir recht da wird das alles sehr kritisch. Aber das ist wieder mal das typische Problem das man sich eben um AF keine Gedanken macht weil man es ja einfach nur einschaltet oder das sowieso dem Treiber überlässt.

Man stelle sich ferner vor, ein Grafikchip würde einen ganz besonders hochwertigen Tri-Filter implementieren, der die 'hintere' Mipmap-Stufe abhängig von der Projektionsmatrix und der Pixel-Position seitlich verschiebt :|

hehe ja dann wird es lustig.

Das ist signaltheoretisch trotzdem schreiender Unsinn, weil das AA-Subpixel eben einen festen, nicht veränderbaren Raum belegt. Ganz genauso wie ein 'vollwertiger' Pixel ohne AA. Ich will garnicht erst wissen, wie das in kleiner Auflösung mit hoher AA-Stufe aussieht.

Also an diesem Punkt kann ich nach wie vor kein Problem erkennen. Solange die Texturekoordinaten innerhalb der eigentlichen Kacel liegen wird das ganze nicht schlechter als es auch ohne AA ist.

Ist klar, trotzdem wird die Signalfrequenz punktuell verringert (Kanten), und woanders überhöht (kleine Mipmaps, siehe oben). Die ganzen Workarounds machen das Bild nicht "gut", nur "anders schlimm".
S.o. Ich hätte die Anpassung (ohne centroid) eben gerne adaptiv, und das muß dann doch die App machen. Und (adaptiven) Bias hat's dann ja sowieso, wenn du einräumst daß man die kleinsten Mipmap-Stufen wegclampen muß.

Wie zur Hölle willst du den Bias da adaptiv einstellen? Das kann IMHO irgendwie nicht funktionieren. Vorallem wenn man grosse Jobs durchjagt.

Es existiert noch eine ganz andere Möglichkeit, dieses hausgemachte Problem zu lösen:
Man benutzt einfach eine Textur pro Textur; und lässt seine Pfoten aus Sachen heraus, die man nicht sinnvoll kontrollieren kann.

Ja klar aber das kostet eben mehr Leistung.

[Demirug]

Original geschrieben von zeckensack
Man muß beim Kacheln die Kachel-Texturen auch an alle Sampler binden :|

Aber ich weiß, worauf du hinauswillst. Nun, 4x4x4x4 mögliche Variationen pro Frame macht im worst case 256 draw calls pro Frame für's Terrain. Pah! Peanuts ...

Ich vermute mal das es 256 Variationen pro Tile sind. Mann müsste aber wissen wie viele Tiles pro Frame gebraucht werden.

Und wenn draw calls das Problem sind, würde ich vorschlagen daß man das Problem eventuell gleich an der Wurzel anpackt. Merke: wenn zwei Lösungen für ein Problem unter den aktuellen Anforderungen gleichwertig sind, wähle diejenige, die besser skaliert :stareup:

Was willst du machen wenn du zu viele Drawcalls hast? Die einzige Lösung die ich dafür kenne ist eine stärke CPU.

Das Kacheln hat auch noch einen weiteren Nachteil, den wir hier nicht verschweigen wollen ;)

Man kann keine automatische Textur-Wiederholung nutzen. Man kann bestenfalls 'mirrored repeat' emulieren. Ob man sich dafür entscheidet, oder nicht, behebt aber nicht das folgende:
Man braucht ein 'regular grid', ie viele, dicht aneinanderliegende Vertices. Für statisches Terrain ohne dynamisches, nicht-HW-realisiertes Displacement (~99% aller Terrain-Renderer) kann man das mit den üblichen Verfahren wegoptimieren, und spart schonmal vorneweg massiv Geometrie.

Ja wobei das bei der hohen Vertexleistung erst mal weniger ein Problem ist. Aber die Bandbreite tut doch schon etwas weh.


Nicht das du mich jetzt falsch verstehst ich bin kein wirklicher freund von dieser Kachel geschichte ich versuche nur zu verstehen was die beweggründen von Valve waren und überlege eben wie man da jetzt noch etwas retten kann.

[zeckensack]

Original geschrieben von Demirug
Bei reiner bi und tri filterung ist das alles nicht kritisch weil ja nur um die Texturekoordinate herungesampelt wird. Dazu muss der Clamp auf der Ebene statfindet in der pro Kachel nur 4 Texel + Sicherheitsrand vorhanden sind. Beim AF könnte es aber durchaus dumm laufen.Ehrm, ich meinte, daß du ab einer bestimmten Verkleinerung praktisch kein Mipmapping hast. Daß Mipmapping für ein Aliasing-freies Bild notwendig ist, darüber sind wir uns doch hoffentlich einig? ;)

Nicht irgendeine Position. Das wäre ja nun wirklich blöd. Die Position bleibt schon noch innerhalb des Pixels wird aber dort in den Bereich geschoben wo auch noch wirklich das Dreieck den Pixel bedeckt.Nun ja, irgendwie schon 'irgendeine'. Was mache ich mit feiner Geometrie, die ab einer bestimmten Entfernung überhaupt kein vollständiges Pixel mehr bedeckt, sondern nur einzelne Subpixel? ZB dieser Baukran am Strand. Nehme ich dann ein Texel von links, oder von rechts, oder aus der Mitte ...?


Also an diesem Punkt kann ich nach wie vor kein Problem erkennen. Solange die Texturekoordinaten innerhalb der eigentlichen Kacel liegen wird das ganze nicht schlechter als es auch ohne AA ist.Ich hab's oben zwischendrin editiert, vielleicht wird's so klarer:Ich
Ich will garnicht erst wissen, wie das in kleiner Auflösung mit hoher AA-Stufe aussieht. Die Kante ist dann zwar schön glatt, aber einfarbig, kennt man ja aus der Filmindustrie. Dort sagt man dann "Aha, Bluescreen! Ich seh's ganz genau!".


Wie zur Hölle willst du den Bias da adaptiv einstellen? Das kann IMHO irgendwie nicht funktionieren. Vorallem wenn man grosse Jobs durchjagt.Ich will garnichts, mir gefällt die gesamte Idee nicht. Nur wenn man schon unbedingt sowas machen will, dann bitte auch richtig (ie die zwangsläufigen Artefakte so gut wie möglich unterdrücken).
Das was ich am Ende als 'adaptiven Bias' bezeichnete war übrigens Mipmap-LOD, womit ich das clamping meinte. Wenn's oberhalb einer gewissen Stufe nicht mehr wie üblich weitergeht, dann kann ich das als spät einsetzendes adaptives LOD umdeuten. So hatte ich mir das gedacht :)

Ja klar aber das kostet eben mehr Leistung. Und sieht dafür vernünftig aus, und macht keine Kopfschmerzen ;)

[Demirug]

Original geschrieben von zeckensack
Ehrm, ich meinte, daß du ab einer bestimmten Verkleinerung praktisch kein Mipmapping hast. Daß Mipmapping für ein Aliasing-freies Bild notwendig ist, darüber sind wir uns doch hoffentlich einig? ;)

Ja, Mipmapping braucht man. Aber in dem besagten Fall sollte das Clampen nicht zum einem Aliasing führen weil ja in einem Pixel gar nicht die gesammte Fläche der Texture zum liegen kommen darf. Auf der unteresten Ebene setzt man dann am besten für alle Texel die gleiche Farbe dann gibt es defintive kein Problem solange das AF nicht über die grenze hinaus geht.

Nun ja, irgendwie schon 'irgendeine'. Was mache ich mit feiner Geometrie, die ab einer bestimmten Entfernung überhaupt kein vollständiges Pixel mehr bedeckt, sondern nur einzelne Subpixel? ZB dieser Baukran am Strand. Nehme ich dann ein Texel von links, oder von rechts, oder aus der Mitte ...?

Wenn nur ein Subpixel anspringt dann muss die Koordinate eben auf dieses Subpixel geschoben werden. Letzten Endes ergibt sich die Sampleposition aus der Maske der bedeckten Subpixel. (ich kann dir da gerne ein Bild machen) Und es wird ja nur auf das Interpolieren der Werte eingewirkt. Dadurch soll nur sichergestellt werden das eben diese MSAA Interpolationsproblem weg ist. Benutzt man reines SSAA oder gar kein AA hat das alles überhaupt keinen Einfluss.

[zeckensack]

Original geschrieben von Demirug
Ja, Mipmapping braucht man. Aber in dem besagten Fall sollte das Clampen nicht zum einem Aliasing führen weil ja in einem Pixel gar nicht die gesammte Fläche der Texture zum liegen kommen darf. Auf der unteresten Ebene setzt man dann am besten für alle Texel die gleiche Farbe dann gibt es defintive kein Problem solange das AF nicht über die grenze hinaus geht.Yay, überhaupt keine Texturen mehr ab einer bestimmten Verkleinerung.
Doppel-:krank:

Wenn nur ein Subpixel anspringt dann muss die Koordinate eben auf dieses Subpixel geschoben werden. Letzten Endes ergibt sich die Sampleposition aus der Maske der bedeckten Subpixel. (ich kann dir da gerne ein Bild machen)Das Problem ist aber, daß der Subpixel logisch wie praktisch gesehen seine Positionsinformation beim Downfilter verliert. Die Mitte des Bildschirmpixels ist signaltheoretisch der einzig richtige Weg bei MSAA. Bei SSAA ergibt der Downfilter btw das gleiche (bei senkrechter Ansicht), respektive einen höherwertigeren Filter, der aber auf der gleichen Position zentriert ist.
Und es wird ja nur auf das Interpolieren der Werte eingewirkt. Dadurch soll nur sichergestellt werden das eben diese MSAA Interpolationsproblem weg ist. Benutzt man reines SSAA oder gar kein AA hat das alles überhaupt keinen Einfluss.Es gibt kein MSAA-Interpolationsproblem. Die Zentren der Final-Pixel liegen auf einem gleichmäßigen, rechteckigen Raster. Entsprechend erfolgt die Parameter-Interpolation anhand eines geordneten Rasters. Alles richtig.
Das einzige was es hier gibt ist ein Valve-Problem.

[zeckensack]

Original geschrieben von Demirug
Was willst du machen wenn du zu viele Drawcalls hast? Die einzige Lösung die ich dafür kenne ist eine stärke CPU.*hust*
Durch weise Wahl der API kann man in absolut draw call-limitierten Fällen ca 125% Mehrleistung schinden.
*doppelhust*

[Demirug]

Original geschrieben von zeckensack
Yay, überhaupt keine Texturen mehr ab einer bestimmten Verkleinerung.
Doppel-:krank:

Ja, aber alles was man rund ums Texturefiltern macht ist irgendwie krank.

Das Problem ist aber, daß der Subpixel logisch wie praktisch gesehen seine Positionsinformation beim Downfilter verliert. Die Mitte des Bildschirmpixels ist signaltheoretisch der einzig richtige Weg bei MSAA. Bei SSAA ergibt der Downfilter btw das gleiche (bei senkrechter Ansicht), respektive einen höherwertigeren Filter, der aber auf der gleichen Position zentriert ist.

Hier wiederspreche ich aber mal. Die beste Position für die Interpolatoren ist die welche zu allen Subpixelpositionen den geringsten Fehler aufweist. Haben wir also den fall das sich beim 4xAA in einem Pixel 4 Dreiecke treffen und jedes davon genau ein Subpixel belegt dann sollten die Interpolatoren jeweils genau auf diesen Subpixel sampeln. Den gleichen Fall bei nur zwei Dreiecken die jweils 2 Subpixel belegen. Zur Anschaung mal die beiden rechten und die biden Linken in einen 4xOG. Dann will ich die Position für die Interpolatoren jeweils genau zwischen den beiden betroffenen Subpixel. Nur so bekomme ich den minimalsten Fehler.

Es gibt kein MSAA-Interpolationsproblem. Die Zentren der Final-Pixel liegen auf einem gleichmäßigen, rechteckigen Raster. Entsprechend erfolgt die Parameter-Interpolation anhand eines geordneten Rasters. Alles richtig.
Das einzige was es hier gibt ist ein Valve-Problem.

Natürlich gibt es ein MSAA-Interpolationsproblem. Es kommt auch zum Tragen wenn man nicht kachelt und sich am Rand der Texture bewegt. Nur sind dabei die Auswirkungen meist nicht so dramatisch.

[Demirug]

Original geschrieben von zeckensack
*hust*
Durch weise Wahl der API kann man in absolut draw call-limitierten Fällen ca 125% Mehrleistung schinden.
*doppelhust*

Durch eine schlechte Wahl der API kann ich mir beim programmieren von per Pixel Effekten locker mehr als 500% mehraufwand einhandeln.

Irgendwie hat eben alles sein vor und Nachteile. ;)

[zeckensack]

Original geschrieben von Demirug
Ja, aber alles was man rund ums Texturefiltern macht ist irgendwie krank.Richtig. Am besten macht man einfach garnichts, und lässt der Natur ihren Lauf :D

Hier wiederspreche ich aber mal. Die beste Position für die Interpolatoren ist die welche zu allen Subpixelpositionen den geringsten Fehler aufweist. Haben wir also den fall das sich beim 4xAA in einem Pixel 4 Dreiecke treffen und jedes davon genau ein Subpixel belegt dann sollten die Interpolatoren jeweils genau auf diesen Subpixel sampeln. Den gleichen Fall bei nur zwei Dreiecken die jweils 2 Subpixel belegen. Zur Anschaung mal die beiden rechten und die biden Linken in einen 4xOG. Dann will ich die Position für die Interpolatoren jeweils genau zwischen den beiden betroffenen Subpixel. Nur so bekomme ich den minimalsten Fehler.Ich widerspreche zurück ;)
Die endgültig sichtbaren Pixel haben, auf dem rechteckigen Raster, auf dem sie dann liegen, einen konstanten Abstand zueinander. Die Information, daß Subpixel A weiter links liegt als Subpixel B existiert in der Ausgabe überhaupt nicht mehr.

Innerhalb eines Polygons will ich die Sample-Position in der Pixel-Mitte, sonst funktioniert AA nicht mehr transparent (zB werden Text-Overlays unscharf, etc). Klar.

Wenn ich an Polygonkanten nun die Sample-Positionen nach innen ziehe, verforme ich das Raster. Das Pixel-Raster ist aber überhaupt nicht anders, als im Polygon-Inneren.

Plan B:
Was passiert mit zwei benachbarten Kanten des gleichen Objekts? Die Interpolation muß, dort wo sie aufeinandertreffen, doch linear fortgeführt werden, non? "Centroid" erzeugt dort einen Bruch, aka Aliasing.

[Demirug]

Original geschrieben von zeckensack
Ich widerspreche zurück ;)
Die endgültig sichtbaren Pixel haben, auf dem rechteckigen Raster, auf dem sie dann liegen, einen konstanten Abstand zueinander. Die Information, daß Subpixel A weiter links liegt als Subpixel B existiert in der Ausgabe überhaupt nicht mehr.

Und was hat das mit der Wahl der Position für das Interpolieren zu tun?

Innerhalb eines Polygons will ich die Sample-Position in der Pixel-Mitte, sonst funktioniert AA nicht mehr transparent (zB werden Text-Overlays unscharf, etc). Klar.

Deswegen kann man centroid ja pro Sampler festlegen.

Wenn ich an Polygonkanten nun die Sample-Positionen nach innen ziehe, verforme ich das Raster. Das Pixel-Raster ist aber überhaupt nicht anders, als im Polygon-Inneren.

Nochmal was hat das mit der Wahl der Position für das Interpolieren zu tun?

Plan B:
Was passiert mit zwei benachbarten Kanten des gleichen Objekts? Die Interpolation muß, dort wo sie aufeinandertreffen, doch linear fortgeführt werden, non? "Centroid" erzeugt dort einen Bruch, aka Aliasing.

Wenn der Chip solche Sitationen nicht erkennen kann bekommt man an den Kanten etwas Supersampling anteil. Denn Bruch sehe ich da eigentlich nicht da die beiden Positionen ja nahe zusammenliegen.

Das ganze Spiel hat doch 3dlabs auch schon betrieben in dem sie adaptives Supersampling betrieben haben und den Supersampling anteil pro Pixel variert haben.

Es ist und bleibt nun mal blöd wenn sich Aufgrund von MSAA Texturkorrdinaten plötzlich in einem Bereich befinden wo sie nicht sein sollten. Das Problem kann zum Beispiel auch auftreten wenn man in einer Texture viele einzelne Teile mit abgeschlossene Kanten sind. Sowas kommt bei Personen aber auch bei Farzeuegen immer wieder vor. Da hat man zwar auch ein Sicherheitsband um die Kanten aber beim MSAA besteht da immer die Gefahr das man in den Bereich hinter diesem Band rutscht.

[Hellspawn]

poa ihr redets ja wirklich interessantes zeugs, aber ich frage mich eins: Die Leute bei Valve können eine Engine schreiben die wirklich super aussieht, gibts echt keinen Grund wieso die eine Technik benutzen die die jetzigen AA-Verfahren ausschliessen? Könnte Parhelia FSAA funktionieren? Ich würd einfach nur gern verstehen wieso das entweder passiert ist, oder sie es vielleicht einfach so wollten.. Das sind doch PROFFESSIONELLE Engine-Schreiber und Grafiker, die müsste man doch alle gleich feuern wenn das ein Versehen wäre oder?

mfg

[Kai]

Original geschrieben von Hellspawn
poa ihr redets ja wirklich interessantes zeugs, aber ich frage mich eins: Die Leute bei Valve können eine Engine schreiben die wirklich super aussieht, gibts echt keinen Grund wieso die eine Technik benutzen die die jetzigen AA-Verfahren ausschliessen? Könnte Parhelia FSAA funktionieren? Ich würd einfach nur gern verstehen wieso das entweder passiert ist, oder sie es vielleicht einfach so wollten.. Das sind doch PROFFESSIONELLE Engine-Schreiber und Grafiker, die müsste man doch alle gleich feuern wenn das ein Versehen wäre oder?

mfg

Soweit genau mein Gedankengang.

[Demirug]

Matrox sollte das gleiche Problem haben.

Und was den unterschied zwischen einen PROFFESSIONELLE Entwickler/Grafiker und jemadem der das ganze nur so nebenbei betreibt angeht so gibt es da nur einen. Die einen werden dafür bezahlt und die anderen nicht.

Letzten Endes bleiben Valve nur wenige Alternativen.

- Es einfach so zu verkaufen wie es ist und hoffen das die IHVs das problem irgendwie lösen.

- Nach ein bischen herumdoktern und hoffen das damit das Problem verschwindet.

- Ein zusätzliche Verfahren für die betroffenen Stellen entwickeln welches auch mit MSAA richtig funktioniert und zwischen den beiden Verfahren umschalten.

Ich habe da aber schon eine Befürchtung für was sich Valve entscheidet.

[Hellspawn]

könntest du trotzdem meine fragen beantworten? Ich wär dir echt dankbar!

[Demirug]

Original geschrieben von Hellspawn
könntest du trotzdem meine fragen beantworten? Ich wär dir echt dankbar!

Welche habe ich den noch nicht beantwortet ???

[Hellspawn]

Q1:Die Leute bei Valve können eine Engine schreiben die wirklich super aussieht, gibts echt keinen Grund wieso die eine Technik benutzen die die jetzigen AA-Verfahren ausschliessen?

Q2:Könnte Parhelia FSAA funktionieren? Danke für die Antwort ;)

Q3:Ich würd einfach nur gern verstehen wieso das entweder passiert ist, oder sie es vielleicht einfach so wollten..

Q4:Das sind doch PROFFESSIONELLE Engine-Schreiber und Grafiker, die müsste man doch alle gleich feuern wenn das ein Versehen wäre oder?
Besser: Wie kann das ein Versehen sein wenn da Profis am Werk sein? Valve würde das doch nicht zulassen oder?

[Demirug]

Q1: Die Leute bei Valve können eine Engine schreiben die wirklich super aussieht, gibts echt keinen Grund wieso die eine Technik benutzen die die jetzigen AA-Verfahren ausschliessen?

Das man dieses Technik benutzt wurde ja damit begründet das man damit mehr Abwechselung bei grossen Flächen erreichen wollte. Die bekanten Alternativen benötigen entweder mehr Texturspeicher oder mehr Leistung. Für Valve hat das wohl als Grund gereicht dieses Verfahren zu benutzten.

Q3:Ich würd einfach nur gern verstehen wieso das entweder passiert ist, oder sie es vielleicht einfach so wollten../SIZE]

Da musst du Valve fragen. Entweder es war eine bewusste Entscheidung was ich aber aufgrund der Aussage das man jetzt eine Lösung sucht nicht glaube. Die Alternative ist das es bei Valve keine Sicherungen gegen solche Probleme gibt oder sie in diesem Fall oder generell nicht funktionieren.

[SIZE=1]Q4:Das sind doch PROFFESSIONELLE Engine-Schreiber und Grafiker, die müsste man doch alle gleich feuern wenn das ein Versehen wäre oder?

Besser: Wie kann das ein Versehen sein wenn da Profis am Werk sein? Valve würde das doch nicht zulassen oder?

Du scheinst eine hohe Meinung von Valve zu haben. Tatsache ist das es Valve ja zugelassen hat. Wie es dazu gekommen sein könnte habe ich ja schon bei Frage 3 zu ergründen versucht.

Und zu dem Thema Profis und Unfehlbarkeit wurde doch schon genügend gesagt, oder?

Und die Personalpolitischen Fragen musst du auch Valve stellen. Ich würde wegen sowas keinen rauswerfen. Man hat einen Fehler gemacht. Na und? Zumindestens weiss man jetzt wie es nicht funktioniert. Es kommt nur noch darauf an was man mit dieser Erkenntniss bei Valve macht.

[Hellspawn]

Original geschrieben von Demirug
Das man dieses Technik benutzt wurde ja damit begründet das man damit mehr Abwechselung bei grossen Flächen erreichen wollte. Die bekanten Alternativen benötigen entweder mehr Texturspeicher oder mehr Leistung. Für Valve hat das wohl als Grund gereicht dieses Verfahren zu benutzten.


ja aber was ist dann das problem? wenn sie aus aus performance technischen gründen gemacht haben ist es ja gut! Wenn mans schon nicht ohne AA ruckelfrei spielen könnte was brächte mir die MÖGLICHKEIT?
Vielleicht wollen sie jetzt halt nur noch schauen dass es dann auf zukünftigen schnelleren Karten funktioniert und das hätte dann wieder sinn oder?

[Demirug]

Original geschrieben von Hellspawn
ja aber was ist dann das problem? wenn sie aus aus performance technischen gründen gemacht haben ist es ja gut! Wenn mans schon nicht ohne AA ruckelfrei spielen könnte was brächte mir die MÖGLICHKEIT?

Jetzige Highendkarte dürfte auch mit einem alternativen Verfahren schnell genug für AA sein. Deswegen schrieb ich das man eben noch eine alternative Technik einbauen sollte die auch mit AA funktioniert.

Vielleicht wollen sie jetzt halt nur noch schauen dass es dann auf zukünftigen schnelleren Karten funktioniert und das hätte dann wieder sinn oder?

Valve geht ja davon aus das sie mit PS 3.0 fähigen Karten das Problem nicht mehr haben werden.

[unwissend!]

Original geschrieben von Hellspawn
ja aber was ist dann das problem? wenn sie aus aus performance technischen gründen gemacht haben ist es ja gut! Wenn mans schon nicht ohne AA ruckelfrei spielen könnte was brächte mir die MÖGLICHKEIT?
Vielleicht wollen sie jetzt halt nur noch schauen dass es dann auf zukünftigen schnelleren Karten funktioniert und das hätte dann wieder sinn oder?

Wenn ich die ganze Problematik richtig verstanden habe wäre dieses Problem nicht aufgetaucht wenn Valve sich an ein paar algemeingültige Regeln gehalten hätte.

Korrigiert mich wenn ich falsch liege!

cu unwissend!

[Hellspawn]

Original geschrieben von Demirug
Jetzige Highendkarte dürfte auch mit einem alternativen Verfahren schnell genug für AA sein. Deswegen schrieb ich das man eben noch eine alternative Technik einbauen sollte die auch mit AA funktioniert.


naja also dann würd ich sagen ihr 2(du und z-bag) spekuliert nur, weil ja keiner von uns weiß wie hardwarelastig das spiel sein wird und wir ja deswegen auch nicht sagen könnten ob es mit AA auf irgendeiner aktuellen graka flüssig laufen würde.. es wird sicher noch das eine oder andere statement zu diesem thema geben, vielleicht sollten wir mal abwarten was die leute von valve noch zu sagen haben ;)

[Demirug]

Original geschrieben von unwissend!
Wenn ich die ganze Problematik richtig verstanden habe wäre dieses Problem nicht aufgetaucht wenn Valve sich an ein paar algemeingültige Regeln gehalten hätte.

Korrigiert mich wenn ich falsch liege!

cu unwissend!

Allgemeingültig ist relative. Da vor Valve noch keiner auf genau diese Idee gekommen ist würde ich nicht davon sprechen das es jeder hätte wissen müssen. Nachdem man nun weiss das es nicht funktioniert ist es auch recht einfach die Gründe dafür zu finden ob man daran aber auch schon im Vorfeld gedacht hätte ist jetzt schwer zu sagen.

Zudem hätte das berücksichtigen der ganze Dinge durchaus auch wieder etwas von dem Nutzen zunichte gemacht.

Das primäre Ziel dieser ganzen Geschichte war es ja wohl auch schwächere Rechner in die Lage zu versetzen diesen Effekt noch zu nutzen und dort ist an AA wohl sowieso nicht zu denken.

Aber von dem Vorwurf das ganze zu spät in Verbindung mit AA getestet hat kann man Valve nicht freisprechen.

[Demirug]

Original geschrieben von Hellspawn
naja also dann würd ich sagen ihr 2(du und z-bag) spekuliert nur, weil ja keiner von uns weiß wie hardwarelastig das spiel sein wird und wir ja deswegen auch nicht sagen könnten ob es mit AA auf irgendeiner aktuellen graka flüssig laufen würde.. es wird sicher noch das eine oder andere statement zu diesem thema geben, vielleicht sollten wir mal abwarten was die leute von valve noch zu sagen haben ;)


Ich habe nicht gesagt wie viele Effekte man abschalten muss um AA einschalten zu können. ;)

Aber im Moment hätte man die Wahl ja sowieso nicht.

[unwissend!]

Original geschrieben von Demirug
Allgemeingültig ist relative. Da vor Valve noch keiner auf genau diese Idee gekommen ist würde ich nicht davon sprechen das es jeder hätte wissen müssen. Nachdem man nun weiss das es nicht funktioniert ist es auch recht einfach die Gründe dafür zu finden ob man daran aber auch schon im Vorfeld gedacht hätte ist jetzt schwer zu sagen.

Erst einmal, ich hab nicht viel Ahnung von der Technik.
Aber die Vor- und Nachteile heutiger AA Techniken sollten den Programmierern doch bekannt sein, oder? Hätte einem das Problem dann nicht auffallen müssen?

cu unwissend!

[Kai]

Original geschrieben von unwissend!
Erst einmal, ich hab nicht viel Ahnung von der Technik.
Aber die Vor- und Nachteile heutiger AA Techniken sollten den Programmierern doch bekannt sein, oder? Hätte einem das Problem dann nicht auffallen müssen?

cu unwissend!

Das ist jetzt schon mehr als hinreichend besprochen worden, lies einfach Demi's Posts.

[0711]

Original geschrieben von Crazy_Bon
Wo bleibt die Fraktion, die immer behauptet in Egoshooter würde eh nie vom AA proftieren, da man in actiongeladenen und schnellen Spielen eh nie darauf achten täte? :D weil viele (so wie ich) es wohl gerade nicht als das ansehen.. (schnell+actiongeladen)

ist keine abwertung...

[Demirug]

Original geschrieben von unwissend!
Erst einmal, ich hab nicht viel Ahnung von der Technik.
Aber die Vor- und Nachteile heutiger AA Techniken sollten den Programmierern doch bekannt sein, oder? Hätte einem das Problem dann nicht auffallen müssen?

cu unwissend!

AA ist für viele Programmierer immer noch etwas um das sich der Treiber kümmern soll. Ergo macht man sich wenig Gedanken darum.

Aber selbst wenn man sich damit auseinader gesetzt hat muss man nicht zwangsläufig bei jedem neuen Verfahren sofort erkennen in wie fern es mit einem AA-Verfahren Probleme geben wird. Wenn man auch gerade eine neue Technik entwickelt hat die einen ehrheblichen Performance Gewinn verspricht will man auch keine Probleme sehen was unbewusst dazu führen kann das man es einfach verdrängt.

Aus diesem Grund gibt es als Sicherheitsnetz das Mittel des Testes. Aber gerade beim Thema AA verzichtet man oft auf dieses Netz und testet einfach nicht.

[Crazy_Bon]

Ich wollte nur darauf hinweisen, womit die
Jaggie-Verfechter immer argumentieren.

Mal´ne Frage, gibt es ein Leben nach Multi- und Supersampling? Vielleicht möchte sich Valve vorbereiten, was ATi neu an AA-Technik einführen will oder sowas. *spekulier*

[unwissend!]

@ Demirug
Thx for the Info :)

cu unwissend!

[Demirug]

Original geschrieben von Crazy_Bon
Mal´ne Frage, gibt es ein Leben nach Multi- und Supersampling? Vielleicht möchte sich Valve vorbereiten, was ATi neu an AA-Technik einführen will oder sowas. *spekulier*

Supersampling stellt ja schon (fast) das optimum da was man mit der AA-Technik erreichen kann. Alles was danach gekommen ist versucht irgendwie mit den gewaltigen Anforderungen an Resourcen klar zu gekommen. Dafür müssen aber Kompromisse eingegangen werden. Wir werden woll noch mehr solcher Kompromisse sehen die es aber auch nicht einfacher machen werden. Perfektes AA erwarte ich erst wenn die IHVs irgendwann nichts mehr einfällt was man sonst noch in einen Chip packen könnte.

Und was Valve angeht so sage ich ganz einfach nur. Die sollen schauen das sie mit dem klar kommen was es jetzt an AA-Technik gibt. Denn auf der einen Seite noch TNT Chips zu unterstützen aber auf der anderen fürs AA Chips zu brauchen die es eigentlich noch gar nicht gibt ist doch wohl etwas zu heftig für meinen Geschmack.

[Morbid Angel]

Boah darüber mach ich mir imho nicht im leben gedanken
Ich bin froh wenn das überhaupt auf schön flüssig lüft (1024x768)

[Karümel]

Auch wenn ich so gut wie kaum was verstanden habe was auf den letzten Seiten geschrieben wurde, wundert es mich doch das dieser Fehler erst jetzt zu Tage gekommen ist. Hieß es nicht die Engine wäre seit über einem Jahr fertig??
Jetzt "rächt" es sich wohl das Valve nix an Vorab-Infos rausgebracht hat, sonst wäre ja der Fehler früher aufgefallen, oder?

[reunion]

Original geschrieben von Exxtreme
Naja, für die NV-Fraktion ist noch nichts verloren.

Supersampling hat derartige Probleme nicht. Wenn Nvidia sich entschliessen sollte, reines SSAA anzubieten in den Treibern dann wäre das Problem auch aus der Welt.

Ich glaube nicht das irgendeine Karte die in nächster Zeit erscheind HL2 mit SSAA(!) flüssig darstellen kann. (in voller Qualität und nicht in 640x480 :))

[Demirug]

Original geschrieben von Karümel
Auch wenn ich so gut wie kaum was verstanden habe was auf den letzten Seiten geschrieben wurde, wundert es mich doch das dieser Fehler erst jetzt zu Tage gekommen ist. Hieß es nicht die Engine wäre seit über einem Jahr fertig??

Was ist schon fertig!?

Jetzt "rächt" es sich wohl das Valve nix an Vorab-Infos rausgebracht hat, sonst wäre ja der Fehler früher aufgefallen, oder?

Was hätten Infos gebracht? Die Jungs hätte einfach mal das AA auf einer Karte mit MSAA austesten müssen.

[Karümel]

Das meinte ich ja, hätten die schon vorher ein paar Screenshots herausgegeben, (da hätten die doch bestimmt AA angesteltt, so wäre der Fehler schon früher aufgefallen

[Demirug]

Original geschrieben von Karümel
Das meinte ich ja, hätten die schon vorher ein paar Screenshots herausgegeben, (da hätten die doch bestimmt AA angesteltt, so wäre der Fehler schon früher aufgefallen

Wenn man bei Valve Presse-"Screenshots" so macht wie es in meinen Anweisungen für solche Fälle steht dann hätte man es nicht gesehen. ;) :D

[Karümel]

Original geschrieben von Demirug
Wenn man bei Valve Presse-"Screenshots" so macht wie es in meinen Anweisungen für solche Fälle steht dann hätte man es nicht gesehen. ;) :D


Screenshot machen dann mit Photoshop "rüberbügeln" ?

[Demirug]

Original geschrieben von Karümel
Screenshot machen dann mit Photoshop "rüberbügeln" ?

Nein mit 64xSSAA.

[Riptor]

Wurde schon gesagt, dass das FSAA-Problem bei HL2 durch DX9.0b gefixt werden soll? Deswegen erübrigt sich eigentlich die Frage, ob nVidia dadurch einen Nachteil hat! ;)

[tEd]

Original geschrieben von Riptor
Wurde schon gesagt, dass das FSAA-Problem bei HL2 durch DX9.0b gefixt werden soll? Deswegen erübrigt sich eigentlich die Frage, ob nVidia dadurch einen Nachteil hat! ;)

Es kann eigentlich nur für ati karten gefixt werden weil diese die nötige harwdareunterstützung haben. Nvidia karten wird eine dx9b update wenns das überhaupt gibt nichts nützen , nvidia fehlt die hardware unerstützung um das fsaa problem in hl2 zu lösen

[Demirug]

Original geschrieben von Riptor
Wurde schon gesagt, dass das FSAA-Problem bei HL2 durch DX9.0b gefixt werden soll? Deswegen erübrigt sich eigentlich die Frage, ob nVidia dadurch einen Nachteil hat! ;)

ich würde gerne wissen wie das gehen soll. Ich habe hier die 9b + passendes SDK (als Beta) hier. Dort gibt es nichts neues in dem Bereich welcher mit dem Problem in verbidnung steht

[Crazy_Bon]

Es gibt auch Heinis, die behaupten, es gäbe ein geleakte E3-Demo von HL2, damit soll dann FSAA funzen mit DX9.0b. ;D

[dildo4u]

[QUOTE][SIZE=1]Original geschrieben von Demirug
Was ist schon fertig!?



Im Interview das mal auf der PCGAMES DVD war sagte der Boss
von Valve die Enigne is seit November 2002 fertig
aber das mit den AA kann ich nicht glauben ich hab mal das 600MB
Quicktime movie von der HL2 präsentation von der E3 geladen das hat so ne Quali das ich schwören könnte AA wäre an und auch sonst wenn sie wirklich ATI als Technologie Partner haben kann das einfach nicht sein
ich meine sobald ATI an ne Beta version von dem game kommt werden sie dafür Optimieren genau wie bei Doom3 und das werden sie ja wohl auch das AA getestet haben bin mal wirklich gespannt ob wir AA nur auf na ATI sehen und obs dann auch performant ist.

[Birdman]

in der heutigen (Spiele)Welt wo sich alles nur ums Geld dreht, verwette ich meinen Arsch darauf, dass FSAA auf keiner Karte laufen wird...man kann imho froh sein, wenn das überhaupt auf einer Karte laufen wird ohne die ganze Zeit abzuschmieren.
Aber was solls, der dritte Patch wirds dann schon richten ;)

[seahawk]

Kann die gewählte Form des Texturhandlings der HL2-Engine (PS. ich möchte die Basistexturen nicht zeichnen müssen) eine Zusammenhang zu deren Plan das Spiel auch auf alter Hardware lauffähig zu machen - zusammenhängen.

Dieses Verfahren müßte doch eigentlich Leistung sparen.

[Demirug]

Original geschrieben von seahawk
Kann die gewählte Form des Texturhandlings der HL2-Engine (PS. ich möchte die Basistexturen nicht zeichnen müssen) eine Zusammenhang zu deren Plan das Spiel auch auf alter Hardware lauffähig zu machen - zusammenhängen.

Dieses Verfahren müßte doch eigentlich Leistung sparen.

Ja es spart Leistung. Allerdings auf der Grafikkarte nur im begrenzten Umfang weil ja immer noch die gleiche Anzahl von Pixel gerendert werden müssen. Die Einsparungen auf der CPU Seite sollten sich bei den schwachen rechnern wesentlich stärker auswirken.

[seahawk]

Daran ahbe ich gedacht. HL2 soll ja auf einer TNT2 mit einem PIII 550 laufen.

Grafikkarte kann man über Auflösung + Detailgrad ganz gut skalieren.

Wenn ich mir aber die Physik- und Ki-Emgine ansehe, dann müssen die eigentlich versuchen die Belastung der CPU durch die Grafik zu reduzieren, um auch bei schwacher CPU noch ein ausreichendes Spielgefühl zu erreichen.

So würde sich die Entscheidung für diese Art der Texturen erklären.

[MadManniMan]

Original geschrieben von seahawk
So würde sich die Entscheidung für diese Art der Texturen erklären.

...somit würde HL2 erstmal von vielen Stellen Lobpreisungen ob der niederen HW-Anforderungen erhalten.

:eyes:

Die meisten "Review"-Quellen werden davon mit Sicherheit mehr zu berichten haben!

[][immy]

Original geschrieben von dildo4u
[QUOTE][SIZE=1]Original geschrieben von Demirug
Was ist schon fertig!?



Im Interview das mal auf der PCGAMES DVD war sagte der Boss
von Valve die Enigne is seit November 2002 fertig
aber das mit den AA kann ich nicht glauben ich hab mal das 600MB
Quicktime movie von der HL2 präsentation von der E3 geladen das hat so ne Quali das ich schwören könnte AA wäre an und auch sonst wenn sie wirklich ATI als Technologie Partner haben kann das einfach nicht sein
ich meine sobald ATI an ne Beta version von dem game kommt werden sie dafür Optimieren genau wie bei Doom3 und das werden sie ja wohl auch das AA getestet haben bin mal wirklich gespannt ob wir AA nur auf na ATI sehen und obs dann auch performant ist.

das du in dem video kein Aliasing siehst ist normal.
1. videofilter
2. wahrscheinlich in einer hohen auflösung aufgenommen
3. ein video ist ansich ja schon so unscharf das dir das Aliasing schon nicht mehr auffällt
siehe konsolen auf dem fernseher, so viel aliasing sieht man da auch nicht unbedingt (also nicht soviel wie man ansich sehen müsste) allein schon weil der fernseher so unscharf ist, das es nicht mehr auffällt

[Sumpfmolch]

Original geschrieben von ][immy
das du in dem video kein Aliasing siehst ist normal.
1. videofilter
2. wahrscheinlich in einer hohen auflösung aufgenommen
3. ein video ist ansich ja schon so unscharf das dir das Aliasing schon nicht mehr auffällt
siehe konsolen auf dem fernseher, so viel aliasing sieht man da auch nicht unbedingt (also nicht soviel wie man ansich sehen müsste) allein schon weil der fernseher so unscharf ist, das es nicht mehr auffällt

hoffentlich liegts an einer sehr hohen auflösung...


...lief nämlich äußerst flüssig --> HL2 ich kommääää

[Winter[Raven]]

Nunja, ich will nicht zu Valve und deren KLEINEM Problem sagen, nur finde ich es richtig blöd was die abziehen, die sollen sich John Carmack als beispiel nehmen und eine SOFTWARE Lösungen hinprogen als es dann den anderen in die Schuhe zuschieben.

[Raymond]

Kommentar von Gabe Newell zum Anti Aliasing Problem
http://www.warp2search.net/modules.php?name=News&file=article&sid=13384
Dazu sag ich nur, kein Kommentar.

[betasilie]

Original geschrieben von Raymond
Kommentar von Gabe Newell zum Anti Aliasing Problem
http://www.warp2search.net/modules.php?name=News&file=article&sid=13384
Dazu sag ich nur, kein Kommentar.
Ist doch interessant. ... ´Bin mal auf die Movies gespannt.

[mapel110]

Original geschrieben von betareverse
Ist doch interessant. ... ´Bin mal auf die Movies gespannt.

jup, hört sich irgendwie nach nem halben anti-aliasing an.

[BigBen]

Grafikfehler bei HL 2: Newell spricht

"Die News, dass Half-Life 2 wegen Grafikfehlern derzeit kein Anti-Aliasing unterstützt, sorgte für große Unruhe in der Spielergemeinde (wir berichteten). Jetzt versucht Valves Software-Chef Gabe Newell in einem Forenbeitrag (http://www.halflife2.net/forums/showthread.php?s=&threadid=3071) die Gemüter zu beruhigen: Er betont, dass dieses Problem auch schon bei anderen Spielen aufgetreten sei und sich eigentlich gar nicht großartig auf die Grafikqualität auswirke. Man könne an Polygonecken dunkle oder helle Linien sehen. Allerdings kommt dies bei Half-Life 2 öfters vor, da die Entwickler häufig mit unterschiedlichen Ausleuchtungen in den Räumen arbeiten.

Lösungsvorschläge hat Newell auch schon im Petto: Ati-Karten unterstützen außerhalb der DirectX-Spezifikationen eine andere Rendering-Methode (Centroid Sampling). Bei Nvidia-Boards müssen die Programmierer Pixel Shader einsetzen. Damit sich jeder ein Bild von der Qualitätssteigerung gegenüber der Version ohne Anti-Aliasing machen kann, möchte Valve in den nächsten Tagen ein Vergleichsvideo veröffentlichen."

Gruß
BigBen

[MadManniMan]

Das ist SO EIN STUSS, was der Typ da schreibt! Von wegen "Q3 und co. fehlern ja auch!" ... :crazy:

Außerdem gefällt denen der schwarze Peter anscheinend gar nicht - die Schuld wird aufs Prinzip von gepackten LMs geschoben.

:lol:

[Hellspawn]

Original geschrieben von MadManniMan
Das ist SO EIN STUSS, was der Typ da schreibt! Von wegen "Q3 und co. fehlern ja auch!" ... :crazy:

Außerdem gefällt denen der schwarze Peter anscheinend gar nicht - die Schuld wird aufs Prinzip von gepackten LMs geschoben.

:lol:

bist du grafiker oder programierer? Dass du keinen Fehler siehst, heißt noch lange nicht dass auch keiner vorhanden ist! Solang du nicht IRGENDWAS mit HINTERGRUNDWISSEN zu sagen hast behalts für dich.. ich glaub gabe newell kennt sich besser aus als du, und dürfte sowas garnicht öffentlich behaupten wenns nicht stimmt! Stell dir vor er würde lügen, was John Carmack mit ihm machen würde lol

[Gastuser]

boah

es gibt ja wohl nix unwichtigeres wie aa
habe das in keinem spiel aktiviert, auch wenn es mein rechner locker schafft
bei 3d shotern im multiplayer hat man auch das problem, das es zwar mit aa sehr gut läuft, aber in extremsituationen durch aa zu ruklern kommt oder kommen kann
und das kann tödlich sein
wie kann man sich nur über so eine kleinigkeit so aufregen, ist mir absolut unverständlich
bei 90% der leute die hier sowas schreiben wird das spiel mit aa sowieso nicht flüssig laufen
also wayne

[Kai]

Original geschrieben von Gastuser
wie kann man sich nur über so eine kleinigkeit so aufregen, ist mir absolut unverständlich
bei 90% der leute die hier sowas schreiben wird das spiel mit aa sowieso nicht flüssig laufen
also wayne

Ich stimme einmal in meinem Leben mit nem Gast überein ;) Selbst mit den fettesten Systemen hab ich zum Bleistift in Spielen wie UT2003 oder sogar schon Eliteforce2 die ein oder andere Stelle gesehen die zuckt.

AA schalt ich grundsätzlich nicht ein, nicht nur weil ich nicht die Hardware dazu hab, sondern weil ich's echt nicht benötige. Ich will natürlich keinem hier der nicht mehr drauf verzichten will lange Reden halten, jeder wie er will - aber mir isses definitiv Jacke wie Hose. Schön die Auflösung hochdonnern und abhotten. Ich käm in einem Spiel wie EF2 oder UT2K3 sicher net dazu das AA zu bewundern, lol.

Iss schon lustig, in Games wird AA immer eingeschaltet, da ist es vielen wurscht ob es jetzt 80 oder 60 fps sind. Aber im 3DMurks und anderen Proggis bleibt's aus ;)

[MadManniMan]

Original geschrieben von Gastuser
boah

es gibt ja wohl nix unwichtigeres wie aa


Schonmal was von persönlichen Präferenzen gehört? :|

:no:

[MuLuNGuS]

aa ist nett muß aber in der heutigen zeit (noch) nicht immer sein und wie einige es sich anmaßen über die entwickler zu urteilen ist schon echt witzig..

machs besser kann ich da nur sagen und wem ein produkt nicht gefällt braucht es nicht zu kaufen oder sich dreisterweise eine raubkopie davon zu ziehen, so einfach ist das.

InFiNiTe

[MadManniMan]

Original geschrieben von InFiNiTeDiViNe
aa ist nett muß aber in der heutigen zeit (noch) nicht immer sein

Da darfst du nicht pauschalisieren. Für mich ist eine moderate Auflösung mit AA und AF wichtiger, als eine hohe ohne. Auch schon, weils mit nem 17"er nicht viel mehr bringt.

Original geschrieben von InFiNiTeDiViNe und wie einige es sich anmaßen über die entwickler zu urteilen ist schon echt witzig..

Nun, so gesehen scheint deine Anmerkung ja im Prinzip richtig, nur entwickelt sich FSAA langsam aber sicher zu einem Feature, das man auch in den Ingame-Optionen verstellen kann. Und wenn man GERADE Valve ist und derart eng mit den IHVs werkelt und wenn man sich dann vor Augen hält, daß das Problem einfach nur durch lückenhafte Organisation geschah, ja spätestens dann möchte ich Valve den Gott-Status absprechen.

Original geschrieben von InFiNiTeDiViNe
machs besser kann ich da nur sagen und wem ein produkt nicht gefällt braucht es nicht zu kaufen oder sich dreisterweise eine raubkopie davon zu ziehen, so einfach ist das.


Nicht ich will mit der Software Geld verdienen, sondern Valve will das - ergo haben sie sich auch darum zu kümmern! Sonst könnte ja auch der Postbote dauernd zu spät kommen und Sachen verschlampen und wenn ich mich dann beschwere, sagen "Machs doch besser!" ... es ist doch SEIN Job!

[MuLuNGuS]

nun,

im gegensatz zum Postman der zweimal klingelt, sagt VALVE dir von vornherein was an ihrem produkt scheiße ist und du dich damit gar nicht erst herumärgern brauchst...

klingt doch ziemlich fair oder etwa nicht??

[dildo4u]

Original geschrieben von InFiNiTeDiViNe
nun,

im gegensatz zum Postman der zweimal klingelt, sagt VALVE dir von vornherein was an ihrem produkt scheiße ist und du dich damit gar nicht erst herumärgern brauchst...

klingt doch ziemlich fair oder etwa nicht??

naja Valve hat immer gesagt der PC sei die beste plattform für ihre games aber warum sind sie dann nicht in der lage das auch zu nutzen gerade hohe AA stufen heben den PC von der konsole ab so is mir auch egal am besten es kommt nur für XBox raus da müsse sie nur für eine Maschiene entwicklen und kriegen vielicht sogar AA hin

[LovesuckZ]

http://www.nvidia.com/nzone

Hehe...

[Abe Ghiran]

Original geschrieben von LovesuckZ
http://www.nvidia.com/nzone

Hehe...
"You don't have the latest version of Macromedia Flash Player".
Und ich werde ihn mir für Leute, die keine Webseiten in html erstellen können bestimmt auch nicht ziehen...
Also was habe ich da verpasst? Ist jetzt auf einmal nvidia Partner von Valve geworden?

Grüße, Jan

[LovesuckZ]

Original geschrieben von Abe Ghiran
Also was habe ich da verpasst? Ist jetzt auf einmal nvidia Partner von Valve geworden?

Grüße, Jan

Ja, dort steht Half Life 2 unter dem "Spielelabel" von Nvidia.

[FatalError]

Original geschrieben von LovesuckZ
http://www.nvidia.com/nzone

Hehe...


selten so eine überfrachtete schnickschnack Seite gesehen... Wers mag...
cya
FatalError

[HellHorse]

Soll mittlerweile schon gefixt sein (irgendwie):


@valve-gary: "What about FSAA?" - Anti-aliased has been fixed on all cards.

Vielleicht war alles auch nur ein weiterer Marketing Gag damit die Leute noch mehr über HL2 sprechen.

typo

[the_MAD_one]

Original geschrieben von HellHorse

Vielleicht war alles auch nur ein weiterer Marketing Gag damit die Leute noch mehr über HL2 sprechen.

Das glaub ich auch bald.

[carcass]

Joa, scheint gefixt zu sein.

"Laut einem Bericht der Fansite HL2Central bestätigt Valve, dass die derzeit aktuelle Version von Half-Life 2 keine Probleme mehr mit der Kantenglättung bei Nvidia-Karten habe. Auch ansonsten scheint es mit dem Grafikkarten-Hersteller zu klappen. So gehört Nvidia zu den offiziellen Streaming-Partnern bei Valves Internet-Lieferdienst Steam."

Bis das Spiel fertig ist, sind solche Meldungen eh was für Mr.:arsch2:

[Gast]

vieleicht war auch alles von ati organiesiert :D

[Leonidas]

:)


Das Half-Life 2 Multisampling Anti-Aliasing Problem
http://www.3dcenter.org/artikel/2003/08-06_a.php

[Gast]

Ich kann nur sagen: Ich brauch kein Anti-Aliasing. Das kostet Leistung und die ist bei meinem 1700+ sowieso knapp bemessen,abgesehen davon, das HL2 auf meiner M&uuml;hle sicher eh nicht gscheit laufen wird.
Selbst wenn ich denn mal nen Athlon64 oder &auml;hnliches besitze, setz ich lieber auf hohe Aufl&ouml;sungen und stabil hohe FPS Werte.
Denn ich sch&auml;tze, das Half-Life2 auch ohne AA High-End Rechner in die Knie zwingt. Und nicht jeder hat nen 3000er P4, gell? ;)

[Alexander]

Original geschrieben von Gast
Ich kann nur sagen: Ich brauch kein Anti-Aliasing. Das kostet Leistung und die ist bei meinem 1700+ sowieso knapp bemessen,abgesehen davon, das HL2 auf meiner M&uuml;hle sicher eh nicht gscheit laufen wird.
Selbst wenn ich denn mal nen Athlon64 oder &auml;hnliches besitze, setz ich lieber auf hohe Aufl&ouml;sungen und stabil hohe FPS Werte.
Denn ich sch&auml;tze, das Half-Life2 auch ohne AA High-End Rechner in die Knie zwingt. Und nicht jeder hat nen 3000er P4, gell? ;)

Nur um das mal klarzustellen: AA hat nichts mit der Prozessorleistung zu tun. Die ganze Arbeit, die AA macht, muss von der Grafikkarte geleistet werden...da wird Dir der schnellste Prozessor nichts nützen, wenn Du nur eine TNT2 hast...

Alexander

[dildo4u]

@valve-gary: "What about FSAA?" - Anti-aliased has been fixed on all cards.!!!!
Quelle interview mit Gary von valve

http://features.moddb.com/interview/52/?page=0