AA-Probs mit geforce3 bei serioussam2

[the_ENIAC]

Schaut Euch bitte mal die screenshots aus serious sam 2 an, und sagt mir, ob das an meinem 23.11er detonator liegt.

Der erste Screenshot mit 4xAnti-Aliasing (http://www.christian-blechschmidt.de/stuff/01ssam_AAon.JPG)

Der zweite Screenshot ohne Anti-Aliasing (http://www.christian-blechschmidt.de/stuff/01ssam_AAoff.JPG)

Beides wurde unter opengl und 32bit Farbtiefe aufgenommen. Anisop.Filter waren AUS! OS ist Win98SE...

Witzig: Wenn ich bei serious sam 2 AA unter direct3D aktiviere, passiert das NICHT!!

???

[BlackArchon]

Also ich weiß ja nicht, was du mit Anti-Aliasing bei Serious Sam willst - ich spiele es in der 1152x864 Auflösung bei alles Max (Script Extreme Quality), bis auf deaktiviertes anisotropisches Filtern. Und selbst da ist es nicht immer ruckelfrei auf einer GeForce3.

Was hast du für eine Auflösung, um dir AA zu leisten?!?

[Quasar]

Sieht wie ein HSR-Fehler aus.

[the_ENIAC]

Originally posted by BlackArchon
Was hast du für eine Auflösung, um dir AA zu leisten?!?

Die, die auch die screenshots haben, 1024x768 :D

Aber Du hast scho recht, ich zock's momentan ohne AA mit 1280x1024.
Ich find's nur ärgerlich, dass bei ner Aktivierung von 2xAA oder 4xAA solche Grafikfehler auftauchen ;)

Dass das mit HSR zusammenhängt würde mich wundern; würde es dann nicht auch unter direct3D auftauchen? Und müsste ich HSR nicht extra aktivieren, oder ist das bei serious sam automatisch aktiviert?

[Quasar]

bei ner GF3 ist das HSR quasi im Treiber bzw. in der Hardware integriert.

Es kann durchaus sein, daß dabei in D3D und OpenGL leicht unterschiedlich aggressive Settings zum Einsatz kommen, was den Unterschied erklärte.

[Razor]

Hatte nggalai nicht mal fest gestellt, daß zocc (Z Occulsion Culling) unter AA nicht aktiviert wird ?

Dann hätte das Problem nichts mit dem HSR zu tun, oder ?
Sieht wirklich nach 'nem Bug aus , den ich allerdings nicht feststellen konnte (trotz längerer Zeit des Testweisen-Festure- Daddelns ;-)...

Bis denne

Razor

[the_ENIAC]

Originally posted by Razor
Sieht wirklich nach 'nem Bug aus , den ich allerdings nicht feststellen konnte (trotz längerer Zeit des Testweisen-Festure- Daddelns)

Du musst dazu weit genug von dem Objekt (in meinem screenshot der Baum) entfernt sein (also nen recht grossen Level wählen), so, dass Du ihn noch nicht siehst (Stück zurückgehen; bei ssam "faden" die entfernten Objekte irgendwann aus). Dann nimmst Du die sniperrifle und zoomst an das Objekt, und Bingo!

Das Phänomen tritt dann am besten sichtbar auf; man sieht es aber auch sonst bei weiter entfernten Gebäuden. Sieht aus wie eine durchscheinende, über das Gebäude gelegte "Hülle".

[MadManniMan]

@razor:

jup, auf ner gf3 funzt die LMA nicht zusammen mit AA

[Razor]

@[KKKK]the_ENIAC

Hab's jetzt selber mal versuch, nachzustellen, aber noch immer nichts...
:-(

Kann es sein, daß es daran liegt, daß ich die 27.70 einsetze ?
Hab' den Demo-Level in der Vollversion benutzt (sollte groß genug sein ;-) und bin dann so verfahren, wie Du sagtest, ausgefadete Objekte herangezoomt und unter 4xAA dann betrachtet... alles OK !
Hmmm...

MadManniMan

"jup, auf ner gf3 funzt die LMA nicht zusammen mit AA"

Falsch !
Lediglich das Zooc (als Teil der LMA) funzt net mit AA...
;-)

Razor

[the_ENIAC]

@Razor

OpenGL benutzt? (nicht schlagen, ich weiss, dass man ssam nicht unter direct3D zockt ;), aber nur unter OpenGL tritt das bei mir auf!)
Wie erwähnt habe ich das unter dem 23.11er festgestellt; Hatte bisher mit dieser detonator-version aber keine Probleme.
Vielleicht probier ich doch mal den 27.42er, der wird ja wohl auch von vielen erfolgreich eingesetzt (siehe Kai's detonator-Umfrage http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=12463 )
Wär je ein Ding, wenn's am detonator liegt...

Btw: thanks for testing, razor ;)

[MadManniMan]

@razor:

scheiße, mußt du ubedingt genau hinlesen und mich als dau hinstellen :D

[the_ENIAC]

Hab das Problem mal im serious sam forum (http://dynamic3.gamespy.com/~serioussam/forums/index.php?s=) gepostet, und von Alen Ladavac von Croteam folgende Antwort erhalten:

"It looks like the driver is turning off 32-bit z-buffer when you turn AA on. Possibly trying to conserve memory. The shots you posted look like effects of reduced depht precision (i.e. 16 bit z-buffer).

Alen"

Leider hab ich keine Ahnung, wie ich den Z-Buffer in den (render-)Optionen in serious sam beeinflussen kann bzw. beeinflussen muss. Oder geht das über die Konsole?
Orwieorwhat...?

[the_ENIAC]

Also, das ganze scheint tatsächlich mit dem z-buffer zusammenzuhängen. Wenn man an der Konsole

'/gap_iDepthBits=n' (wobei n 16, 24 or 32 sein kann)

eingibt und das Spiel neu startet, verschwinden die Artefakte (bei mir bei n=24).

[the_ENIAC]

Well then, hier noch ein das Problem endgültig bereinigender Tipp:

Wer auch auf dieses Problem der Artefakte-Bildung in serious sam 2 bei eingeschaltetem FSAA gestossen sein sollte, möge einen Blick in seine SERIOUSSAM.log file-Datei werfen.
Dort sollte dann mit grosser Wahrscheinlichkeit die folgende Textzeile auftauchen (fett gemarkert):

code:
Pixel Format Description:
Number: 4 (TYPE_RGBA)
Flags: DRAW_TO_WINDOW SUPPORT_OPENGL DOUBLEBUFFER SWAP_EXCHANGE
Color bits: 32 (8:8:8:0)
Depth bits: 16 (0 for stencil)

Es gibt ein script mit dem Namen PersistentSymbols.ini im Scripts-Ordner. Diese Datei mit notepad (o.ä.) öffnen, und nach den Zeilen

gap_iDepthBits=0;
gap_iStencilBits=0;

suchen.
Die Parameter sind momentan noch auf 0 gesetzt, weil das die default-Werte sind.
Wenn man nun depth bits auf 24, und stencil auf 8 setzt, sollte das den korrekten video-mode wieder herstellen, und die Artefakte beim Spiel mit FSAA sollten nicht mehr vorhanden sein.
Kann im Übrigen sein, dass bei Einigen vielleicht statt gap_i dort ogl_i steht, das hängt wohl mit der version des games zusammen, ändert aber nichts an den Einträgen.

[Unregistered]

Trifft das auf alle Detos zu?
Cheatet nVIDIA auch hier oder nur ein Bug.?

[the_ENIAC]

Hab das ganze selber beim 23.11er festgestellt.
Auf einem System mit ner geforce2MX und dem 21.83er ist das auch aufgetreten, also hänge ich mit der Beurteilung etwas in der Luft, ob das nun ein Problem einiger Versionen der detonator-Treiber im Zusammenspiel mit der engine von serious sam ist, oder ob das Spiel ganz einfach nen Bug hat.
Offensichtich stellen sich ja die o.g. Parameter automatisch auf 0 zurück, wenn FSAA aktiviert ist.

[ow]

Vermutlich weder Treiber- noch Game-Bug.

Die GFs ab GF2 koennen entweder 16 oder 24 Bit Z-Buffer bei 32Bit FB verwenden.
Ein Standard hierfuer ist AFAIK nicht definiert. Eineige Detos nutzten default wohl 16Bit waehrend andere 24Bit nutzen.
Muesste man halt mal ausprobieren.

[MadManniMan]

richtig, kein bug, sondern cheat.

wenn der deto auch für ne gf3 ist, die ja auf 32bit ausgelegt ist, kann das nicht angehen.

mich würden mal benches mit 16/24/32bit interessieren...

[ow]

Originally posted by MadManniMan
richtig, kein bug, sondern cheat.

wenn der deto auch für ne gf3 ist, die ja auf 32bit ausgelegt ist, kann das nicht angehen.

mich würden mal benches mit 16/24/32bit interessieren...


Was ist denn das schon wieder fuer ein dummes Gespraech von dir?

[the_ENIAC]

Originally posted by ow

Was ist denn das schon wieder fuer ein dummes Gespraech von dir?

Full ACK !
Versaut den ganzen schönen thread... ;D
V.a. kann er doch selbern benchen, wenn's ihn interessiert...

[MadManniMan]

sorry, wollte eigentlich geflame im nv-forum lassen, das gehört ins pro und contra...

mich interessiern halt nur die ergebnisse der unterschiedlichen einstellungen, denn so performance zu erkaufen, halte ich für nicht besonders sinnig bzw fair.

wer schonmal embm/dot3 auf 16 UND 32bit gesehen hat, weiß was ich meine!

aber wie gesagt, is ein nv-forum, ergo verlange ich keine antwort!

[Razor]

Du bekleckerst Dich aber wirklich nicht gerade mit Ruhm, MadManniMan...
;-)

Es geht hier nicht um Farbtiefe (16- oder 32-Bit), sondern um den Z-Buffer. Und der ist bei einer GeForce (bis 3 weiß ich's genau ;-) eben 16-Bit Z und 0-Bit Stecil, bzw. 24-Bit Z und 8-Bit Stencil. Es gab wohl mal 'nen Treiber der auch die Auswahl von 32-Bit Z-Buffer erlaubte, was aber nachweislich nicht funktionierte (war dann eben 24- oder 16-Bit ;-). Weiß nun wirklich nicht, ob der 23.11 das war, aber die jetzigen 27'er haben det Prob' sicher net...

Wie dem auch sei, stimme da eher mit ow überein, denn auch ich vermute, daß es kein Bug und schon gar kein Cheat ist.

Aber eines konnte the_ENIAC sehr gut zeigen: Wenn's 'komisch' aussieht, dann erst mal in die Einstellungen schaun' (Game UND Treiber ;-).

Bis denne

Razor

P.S.: Nich wundern, daß ich plötzlich so unvermutet wieder Poste, aber der Thread war auf der Startseite von 3DConcept und da konnte ich einfach nicht wiederstehen... habe leider unglaublich wenig Zeit, momentan...
*schnüff*
:-(

[Andre]

Originally posted by Razor
P.S.: Nich wundern, daß ich plötzlich so unvermutet wieder Poste, aber der Thread war auf der Startseite von 3DConcept und da konnte ich einfach nicht wiederstehen...

Grmpf, wie oft noch?

WIR SIND HIER BEI 3DCENTER UND NICHT BEI 3DCONCEPT!!!

[Razor]

Originally posted by Andre


Grmpf, wie oft noch?

WIR SIND HIER BEI 3DCENTER UND NICHT BEI 3DCONCEPT!!!
Sorrrrrrrryyyyyyyyy !
*knie nieder*
:-(

Bin irgendwie nicht so ganz bei mir !
Aber mal ganz ehrlich, ist doch wohl sogar ein Kompliment, oder ?
;-)

Bis denne

Razor

[MadManniMan]

och menno, razorle...

ich hatte eigentlich vorausgesetzt, daß klar ist, daß ich von z-buffer und nicht farbtiefe spreche...

dir is schon bewußt, daß dieser durchaus heftig an der performance saugen kann?

[Xmas]

Originally posted by MadManniMan
dir is schon bewußt, daß dieser durchaus heftig an der performance saugen kann?
Klar, nur wie kommst du auf den "Cheat"?

[ow]

Originally posted by MadManniMan
och menno, razorle...

ich hatte eigentlich vorausgesetzt, daß klar ist, daß ich von z-buffer und nicht farbtiefe spreche...

dir is schon bewußt, daß dieser durchaus heftig an der performance saugen kann?


Poste doch mal deine Messwerte mit 16/24 Bit Z bevor du hier solche Toene spuckst.

Ausserdem darfst du uns jetzt erklaeren, wer denn wie unter OGL den benutzten PFD festlegt.

[MadManniMan]

nun, recht eindeutig ist zu erkennen, daß er 32bit farbtiefe gewählt hatte, somit ;-) sollte eigentlich standartmäßig zumindest ein 24-bittiger zbuffer standart sein.

ich vermute jetzt mal, mit pfd(wasauchimmer) meinst du die einstellung und ic ;-) h gebe dir insofern recht - nein, ich bin mir insofern nicht sicher, daß ich nicht weiß, wer denn nun für diese standarteinstellungen verantwortlich

wenn nv, dann performance-cheat(wir hatten diese standarteinstellungen und benches diskussion schon mal...)
;-)


wenn das croteam, so entschuldige ich mich
;-)

zu zbuffer benches:

aus ermangelung eines funktionstüchtigen gaming pc in diesem moment(ich kann mir im mom kein neues netzteil leisten... die liebe weiblichkeit braucht mehr finanzielle bezüge, als sich in den ersten monaten unserer frischen liebe angedeutet hatte :D) schreibe ich von der schule aus, ergo hab ich keine frischen benches parat

ich erinnere mich jedoch dunkel daran, daß mit meiner k2 beim EMBM test im 3dmurks beim umstellen von 16 auf 32bit zbuffer so um die hälfte der einst 70(?) fps mal eben abhandengekommen waren
;-)

PS ich will jetz keine neue standarteinstellungen diskussion anzetteln(was ich in diesem moment tue)
;-)

aber wenn ich 32 bite farbtiefe einstelle möchte ich bitte auch 32bit zbuffer
;-)


@razor: bitte nich böse sein ;-) wolltes nur mal ausprobieren ;-)

[Xmas]

Originally posted by MadManniMan
nun, recht eindeutig ist zu erkennen, daß er 32bit farbtiefe gewählt hatte, somit ;-) sollte eigentlich standartmäßig zumindest ein 24-bittiger zbuffer standart sein.
Was hat das eine mit dem andern zu tun?

ich vermute jetzt mal, mit pfd(wasauchimmer) meinst du die einstellung und ic ;-) h gebe dir insofern recht - nein, ich bin mir insofern nicht sicher, daß ich nicht weiß, wer denn nun für diese standarteinstellungen verantwortlich

wenn nv, dann performance-cheat(wir hatten diese standarteinstellungen und benches diskussion schon mal...)
;-)

wenn das croteam, so entschuldige ich mich
;-)
PFD = Pixel Format Descriptor
Offensichtlich ist die Standardeinstellung 0. Das lässt dem Treiber eigentlich völlige Freiheit, welches Z-Buffer-Format gewählt wird. Würde das Spiel explizit ein bestimmtes Format fordern, der Treiber aber, obwohl unterstützt, ein anderes wählt, dann ist das kritikwürdig.

aber wenn ich 32 bite farbtiefe einstelle möchte ich bitte auch 32bit zbuffer
;-)
s.o.
Übrigens bekommst du auch keine 32 Bit Farbtiefe... Waaahh! Cheat!! ;)

[the_ENIAC]

Hat denn inzwischen einer von Euch Buben bei ser_sam2 auch mal ein büschen mit den o.g. Einstellungen und Parametern rumexperimentiert?
Razor hatte ja beim 27.70 detonator keine Probs festgestellt...
Irgendwer vielleicht auch noch mit dem 23.11er, der die Darstellungsfehler reproduzieren konnte?

[nggalai]

Hi [KKKK]the_ENIAC,

mit

gap_iDepthBits=24;
gap_iStencilBits=8;

konnte ich das Problem bei aktiviertem FSAA lösen. GF3, 23.11.

hope this helps,
-Sascha.rb

[MadManniMan hat Info]

herrjeminee! bei "ausländern" wird im nv-forum auch echt jedes wort auseinandergenommen... :D

also gut:

frag mich nich warum, aber ich meine ein auge für alles zu haben, was höher als 16bittig ist. ich mag mich irren, aber imho gibt es deutliche unterschiede bei bumpmap methoden jedwelcher art im vergleich zwischen 16 und was weiß ich wieviel bit

nebenbei erinnere ich mich an 1998, wo nv den tnt vorstellte und den 32bittigen zbuffer als notwendigkeit darstellte. wieauchimmer, ich habe gewisse hohe(!) qualitätsansprüche und finds blöde, wenn auch noch mit solchen ungleichen einstellungen gebencht wird

achja: ich weiß... 8bit für jeden farbkanal, 8bit für den alphakanal... 32bit farbtiefe waren für mich jetzt nur eine andere nomenklatur der guten alten "allgemeinen" 32bit, um den unterschied zwischen zbuffer und dem anderen krams zu verdeutlichen

[ow]

Originally posted by MadManniMan hat Info
herrjeminee! bei "ausländern" wird im nv-forum auch echt jedes wort auseinandergenommen... :D

also gut:

frag mich nich warum, aber ich meine ein auge für alles zu haben, was höher als 16bittig ist. ich mag mich irren, aber imho gibt es deutliche unterschiede bei bumpmap methoden jedwelcher art im vergleich zwischen 16 und was weiß ich wieviel bit



Von was redest du da???


nebenbei erinnere ich mich an 1998, wo nv den tnt vorstellte und den 32bittigen zbuffer als notwendigkeit darstellte.



Da keiner der NV Chips bis heute einen 32Bit Z-Buffer hat dürfte es dir schwer fallen, diese Aussage zu belegen.

[MadManniMan]

ach menno, ihr wißt doch, wie ich das mit den 32bit meine ;)

gut... sagen wirs so, wenn ich von 32bit zbuffer spreche, meine ich 24bit +8bit stencil, ok?

wieauchimmer, sogar nv selbst behauptete bei der tnt2(also doch die zweite auflage) vorstellung, ein 24bit zbuffer wäre unabdingbar für eine annehmbare tiefenkomplexität...

achja, zur bump-optik:

is dir noch nich aufgefallen, daß bei 24 respektive 32bit zbuffer(letzteres ist ja nv-usern nicht sooo wirklich möglcih :D ) der dot3 test im murks 2k1 irgendwie... sauberer aussieht?

wenn nicht, war ich wahrscheinlich betrunken, als ich ihn mir angesehen hatte :D

[ow]

Originally posted by MadManniMan
ach menno, ihr wißt doch, wie ich das mit den 32bit meine ;)

gut... sagen wirs so, wenn ich von 32bit zbuffer spreche, meine ich 24bit +8bit stencil, ok?




Warum benutuzt du dann nicht die korrekte Form?
Der Stencil Buffer ist kein Z-Buffer. Es gibt auch Chips, die 32Bit Z +8 Bit STencil Buffer beherrschen, die sind aber nur in der OGL-Profi-Liga zu finden


wieauchimmer, sogar nv selbst behauptete bei der tnt2(also doch die zweite auflage) vorstellung, ein 24bit zbuffer wäre unabdingbar für eine annehmbare tiefenkomplexität...



Das ist er auch. Für Profi OGL Applikationen mit ihren äusserst komplexen 3D Modellen ist ein 16Bit Z-Buffer einfach absolut unbrauchbar.

Und selbst Spiele 3D Engines wie die von Q3/Unreal mit recht geringer Komplexität zeigen unter 16Bit Z teilweise starke Z-Fehler.



achja, zur bump-optik:

is dir noch nich aufgefallen, daß bei 24 respektive 32bit zbuffer(letzteres ist ja nv-usern nicht sooo wirklich möglcih :D ) der dot3 test im murks 2k1 irgendwie... sauberer aussieht?

wenn nicht, war ich wahrscheinlich betrunken, als ich ihn mir angesehen hatte :D


Hab ich mir noch nicht in 16Bit Z genau angeschaut. Glaub das aber eher nicht.

[Xmas]

Originally posted by MadManniMan
is dir noch nich aufgefallen, daß bei 24 respektive 32bit zbuffer(letzteres ist ja nv-usern nicht sooo wirklich möglcih :D ) der dot3 test im murks 2k1 irgendwie... sauberer aussieht?

wenn nicht, war ich wahrscheinlich betrunken, als ich ihn mir angesehen hatte :D
Bump Mapping hat (bisher) nichts mit dem Z-Buffer zu tun. Wenn bei der Demo Z-Fehler auftreten, dann ist sie grottig programmiert.

Aber wie gesagt, die Verantwortlichkeit, einen 24Bit Z-Buffer anzufordern liegt beim Spiel, nicht beim Treiber.

[aths]

ow,

UT zeigt in Glide beim 16-Bit-Z-Buffer keine Fehler. (Vielleicht verwendet die Engine dann FP statt Integer? Das weiss ich jetzt leider auch nicht.)

In CS hab ich sie aber definitiv und werde dadurch "gezwungen", es in 32 Bit Farbe (Xmas: 24 Bit Farbe + 8 Bit Destination Alpha :)) zu spielen...

[MadManniMan]

hab jetzt endlich nochmal den 3dquark rausgekramt und muß sagen, daß die zbuffer tiefe NULL einfluß auf BM performance hat und auch keine optischen unterschiede entstehen...

sorry @all, war wohl doch betrunken!

[Quasar]

Originally posted by MadManniMan
[Bwieauchimmer, sogar nv selbst behauptete bei der tnt2(also doch die zweite auflage) vorstellung, ein 24bit zbuffer wäre unabdingbar für eine annehmbare tiefenkomplexität...
[/B]

War das nicht eher Matrox, die mit der G400 einen funktionierenden 32Bit Z-Buffer vorstellen wollten, der aber nur analog zur gewählten Farbtiefe funktioniert hat und unter 16Bit gar grausliches in Quake3 ergab?

[ow]

Spielt doch keine Rolle


Wer mal den Image Quality Test aus Indy3D oder den DRV-06 aus Viewperf6.1.1 gesehen hat, der weiss, wozu min. 24Bit Z ein absolutes MUSS ist.