Z ungenau
-
Original erstellt von 0x00000001:
**Das ist mal wieder eine der Sachen, die in der SDK wirklich nicht ausreichend erklärt sind.
**Was genau meinst du, das in DWORD casten?! Da gibt's IMHO sogar ein Makro für.
-
@TGGC: Ne ich meinte das mit dem DepthBias. Es steht zwar eine Formel da, aber irgendwie blick ich die auch nur nachdem ich verstanden hab was das ganze eigentlich macht.
@rapso:
Ich hab für beide Durchgänge Vertexshader genommen, und die gleiche Matrix. ka.
Und durch den Z-Bias kann ich EQUAL garnicht mehr nehmen, sonst bleibt alles schwarz. Aber Danke für den HInweis mit der Geschwindigkeit.Ich glaube, diese Technik mit dem z vorberechnen lohnt sich in meinem Fall, hab nämlich überall dot3-bumpmaps drauf, viele Specularmaterialien und dazu noch in Echtzeit berechnete Punktlichter ( alles auf Per-Pixel Basis).
Und es läuft jetzt schon recht lahm, obwohl ich nur sehr wenige Polygone in meinem Testlevel hab.
-
Hi,
bei einigen Grafikkarten ist es eben problematisch, wenn man Vertex-Shader in Kombination mit der FF-Pipeline nimmt. Wenn Vertex-Shader dann besser auch Pixel-Shader.
Ciao,
Stefan
-
@0x00000001
wenn du aufmerksamm gelesen hättest, wüstest du, dass du eben nicht EQUAL nutzen sollst, falls es schnell sein soll...und wenn du zweilmal das selbe durch die shader gestopft hättest, wäre auch der zbuffer beide male gleich.. ich mach das zur zeit täglich und es ist bisher immer fehlerfrei gewesen. du müßtest irgendwo anders den fehler finden.
(getestet hab ich auf tnt,tnt2,rage 128,rage pro,geforce,geforceMX,radeon,radeon8500,radeon9000,gf3,gf4,ATI9500,GF5800U,GF5900 und bisher außer die TnL inkompatibilitäten mit den vertexshadern nicht einmal der fehler aufgetretten, dass die selben rechnungen verschiedene ergäbnisse im zbuffer führten)naja, falls es dir egal ist, kannste ja so machen wie's nun läuft, aber der fehler bleibt dann.
rapso->greets();
-
Stimmt, ihr habt recht.
Wenn man einen Pixel-Shader anstatt der Standard-Pipeline für den z-pass benutzt sind die z-Werte auch gleich. Ich wollte eigentlich keinen benutzen weil es ja Plicht ist, das Ausgaberegister mit irgendwas zu beschreiben. Und das brauche ich ja eigentlich garnicht.
Wird mal Zeit, dass ich eine Fps-Anzeige einbaue. Mal schauen, welche der beiden Möglichkeiten schneller ist...
-
Kann man das Programm auch mal testen oder nen bild davon sehen? Klingt alles nach toller Grafik ^^.
-
Original erstellt von 0x00000001:
**Stimmt, ihr habt recht.Wenn man einen Pixel-Shader anstatt der Standard-Pipeline für den z-pass benutzt sind die z-Werte auch gleich. Ich wollte eigentlich keinen benutzen weil es ja Plicht ist, das Ausgaberegister mit irgendwas zu beschreiben. Und das brauche ich ja eigentlich garnicht.
Wird mal Zeit, dass ich eine Fps-Anzeige einbaue. Mal schauen, welche der beiden Möglichkeiten schneller ist...**
das mit dem pixelwert schreiben macht nix, schreib einfach eine konstante da rein, das wird quasi nebenbei mitgeschleift und dürfte garkeinen negativen einfluss auf die performance haben.
ich hoffe du sortierst die objekte von vorne nach hiten, das bringt gegenüber dem umgekehrten rendern 10fache performance auf guten garkten (ATI8500,9500,9700,9800,gf3/4,gffx.. bringt leider nix auf den meißten anderen wie z.B. ATI9600.. also nicht wundern wenn's bei dir nix bringt und du hast so ne karte)rapso->greets();
-
@Tobiking:
OK, ich stelle ein Bild online.
LINK
Ich denke mal, hier wird jedem klar sein, dass das nur ein Testlevel mit Testtexturen ist.
In der Ecke ist ein rotes Licht, bei der Kamera nochmal ein weißes.
Eigentlich haben die ganzen Wände (bis auf den Rost) auch einen Specular-Wert, aber irgendwie funzt das z.Zt. nicht richtig bzw. zu schwach.@rapso:
Hm...Du meinst ich soll alles für den z-Pass sortieren? Für den richtigen Renderdurchgang mit Farbe macht es ja keinen Unterschied, weil der z-Buffer da ja schon voll ist und eh nur noch das Sichtbare gerendert wird.
Beim Z-Pass würde das Sortieren dann ein paar Schreibzugriffe auf den z_Buffer überflüssig machen, aber bringt das echt soviel? Ich mein das Sortieren braucht ja auch Zeit.P.S: Find ich gut, dass es hier jemanden gibt, der sich mit so vielen Grakas auskennt
-
wie du vielleicht gelesen hast, bringt das auf einigen karten was, auf einigen sogut wie nichts.
ATI hat einen ZBuffer schon auf dem chip, dieser hat blöcke die hierarchisch mehrere pixel abdecken.
also in der ersten ebene ist ein zbuffer für vielleicht 32*32pixel, wenn dein zwert kleiner ist, als der wert für diesen 32*32 block, dann der entsprechende block darunter geprüft (16*16pixel) usw.
das macht eine ATI in einem takt, das macht die aber auch nur, wenn du im pixelshader selber keinen z-wert schreibst und keinen texkill nutzt.
dirch diese optimierung braucht die karte keinen zbuffer read und weil die pipe 256bit hat, werden in einem takt 8pixel getestet und dadurch kommt der performance boost zum teil, denn mit dem zbuffer kann man das lesen nicht so schnell machen wie mit dem onchip zbuffer.leeider...
.. ist der zbuffer auf dem chip nicht so hoch aufgelöst wie im ram (wäre zu teuer), das meine ich sowohl für die z-genaugikeit (vielleicht 8-12 bit) und die pixelauflösung (also vielleicht 4*4 pixel bei 1600*1200)deswegen, falls der check im chip mekrt, dass der pixel nicht 100%ig hinter dem quantitisiertem zbuffer liegt, wird das standartverfahren benutzt.
aus diesem grund ist es wichtig von vorne nach hinten zu sortieren, insbesondere falls dein erster pass schon pixelshader instruktionen hätte, die ein wenig aufwendiger sind.
was noch wichtig ist, benutze _nie_ EQUAL compare, denn dann ist die zbuffer optimierung auch futsch.
hier sind ein paar benchmarks die die theorie beweisen:
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=44301rapso->greets();
-
Ich muß ehrlich sagen, dass ich das mit diesen z-Buffer Blöcken nicht so richtig verstanden habe (das Prinzip schon, die genaue Funktion nicht). Ist aber auch egal, einfach von vorn nach hinten rendern und alles ist gut
Danke nochmals!
