Archiv verlassen und diese Seite im Standarddesign anzeigen : was kommt nach AF?
mapel110
2003-12-03, 16:32:35
es gibt ja nun bilinear, trilinear und anisotope filterung.
was wird danach kommen?
mag sein, dass AF derzeit noch verbesserungswürdig und ausbaufähig ist, aber was soll danach kommen, um texturqualität zu verbessern?
Matti
2003-12-03, 16:38:43
ich denke, irgendwann wird man auf Mip-Mapping verzichten, und alle relevanten Texel direkt aus der Haupt-Textur holen. Das ergibt dann wirklich optimale Filterung.
Aqualon
2003-12-03, 16:58:38
Theoretisch wäre es doch bei entsprechender Leistungsfähigkeit der PixelShader möglich Texturen on the fly rein durch Shader zu erzeugen.
Könnte man sich da die Nachbearbeitung mit Filter-Verfahren nicht komplett sparen?
Aqua
http://www.dgm.informatik.tu-darmstadt.de/research/texsynth.html
Das könnte eine andere Methode sein, die Texturqualität zu verbessern.
Original geschrieben von mapel110
es gibt ja nun bilinear, trilinear und anisotope filterung.
was wird danach kommen?
mag sein, dass AF derzeit noch verbesserungswürdig und ausbaufähig ist, aber was soll danach kommen, um texturqualität zu verbessern? Lange Zeit wird es wohl noch bei guten AF-Verfahren bleiben. AF ist so ziemlich das beste was man auf der Grundlage von BF/TF machen kann. Solange es bei BF/TF als Grundlage bleibt, wird es auch AF geben.
Matti
2003-12-07, 15:25:48
Original geschrieben von Aqualon
Theoretisch wäre es doch bei entsprechender Leistungsfähigkeit der PixelShader möglich Texturen on the fly rein durch Shader zu erzeugen.
Könnte man sich da die Nachbearbeitung mit Filter-Verfahren nicht komplett sparen?
Aqua
Wo eine Textur ist, muß auch gefiltert werden!
Aber in Zukunft wird man viele Effekte mit Shadern machen, wo man heute noch den Umweg über die Textur gehen muß (z.B. Reflexionen). Und was direkt mit Shadern (ohne Texturen) gemacht wird, braucht auch nicht gefiltert werden.
Original geschrieben von Matti
Und was direkt mit Shadern (ohne Texturen) gemacht wird, braucht auch nicht gefiltert werden. Doch :) Zunächst, ohne Texturen wird kaum ein Shader auskommen. Der Shader erzeugt so oder so auf einer gewissen Fläche ein gewisses Bild. Auch hier muss das Nyquist-Theorem eingehalten werden, sonst http://www.aths.net/files/smilies/devil.gif wegen Texture- äh, Shader-Shimmering (sprich Aliasing.)
Matti
2003-12-07, 16:29:24
wenn man aber z.B. Ray-Tracing über die Shader macht, gibts keine Textur.
...und ich hoffe ja, daß ich Echtzeit-Raytracing in Games noch miterleben darf...
Aquaschaf
2003-12-07, 18:40:24
Ganz ohne Texturen wird auch bei weitem nicht jeder Shader auskommen. Wenn man z.B. eine Metaloberfläche mit Kratzern hat, wird man die Kratzer wohl immer über eine Textur realisieren da es vom Aufwand her unsinnig wäre das mit einem Shader zu realisieren. Also ich glaube nicht, dass Texturen jemals unbedeutend werden oder ganz verschwinden.
Original geschrieben von Matti
wenn man aber z.B. Ray-Tracing über die Shader macht, gibts keine Textur.
...und ich hoffe ja, daß ich Echtzeit-Raytracing in Games noch miterleben darf... Spätestens für Material Shader musst du wieder auf Texturen zurück greifen.
Original geschrieben von Matti
wenn man aber z.B. Ray-Tracing über die Shader macht, gibts keine Textur.
Wenn man nicht zu 100% auf Procedural Textures setzt bei denen man Aliasing schon bei der Generierung teilweise unterdrücken kann, muss man die Texturen immer Filtern. Egal ob Raytracing oder Rasterizing
Antialiasing ist eigentlich bei RT ein noch grösseres Thema, weil auf noch höhere Qualität wert gelegt wird :)
...und ich hoffe ja, daß ich Echtzeit-Raytracing in Games noch miterleben darf...
gibts doch schon...
wirf einfach mal google dafür an :)
Matti
2003-12-08, 10:37:50
aber nur in geometrisch ziemlich einfachen Grafikdemos. In Games gibt's noch kein Echtzeit-Raytracing.
Such mal nach "realtime raytracing game oasen"
Ist zwar kein kommerzielles Produkt sieht aber ganz nett aus für ein Freizeitprojekt finde ich. Zumal die Bilder alles andere als aktuell sind :D
Ich denk mal bei der Art des AF kann man noch Verbesserungen vornehmen. Gibt dort ja zahlreiche Algorithmen, welche derzeit noch nicht in 3D-Karten Verwendung finden.
http://www-users.itlabs.umn.edu/classes/Fall-2001/csci5980/notes/Texture_Mapping2.ppt
http://research.microsoft.com/asia/dload_files/group/IG/2002p/Pacific_Graphics.pdf
http://online.cs.nps.navy.mil/DistanceEducation/online.siggraph.org/2001/Papers/10_Point-BasedRenderingAndShadows/zwicker.ppt
In diesem Zusammenhang sei natürlich auch Shader AntiAliasing erwähnt, was mit steigender Leistungsfähigkeit der VPU's verwendet werden kann.
http://graphics.stanford.edu/lab/soft/prman/Toolkit/AppNotes/appnote.25.html
Thomas
mapel110
2007-04-24, 00:20:00
*push*
irgendwie ist nicht so richtig was passiert in fast 4 Jahren. Gerade mal gutes AF haben wir endlich erhalten. Und gemessen am Geforce3-AF sinds wirklich Peanuts, was hinzugekommen ist.
Daher imo nochmal interessant nachzufragen, was derzeit noch so vor der Tür steht bzw stehen könnte.
*push*
irgendwie ist nicht so richtig was passiert in fast 4 Jahren. Gerade mal gutes AF haben wir endlich erhalten. Und gemessen am Geforce3-AF sinds wirklich Peanuts, was hinzugekommen ist.
Daher imo nochmal interessant nachzufragen, was derzeit noch so vor der Tür steht bzw stehen könnte.Jede nichtlineare isotrope Texturfilterung bringt mehr Probleme, als sie löst. Gutes AF liefert bei verzerrten Texturen gute Samples.
Theoretisch wäre es doch bei entsprechender Leistungsfähigkeit der PixelShader möglich Texturen on the fly rein durch Shader zu erzeugen.
Könnte man sich da die Nachbearbeitung mit Filter-Verfahren nicht komplett sparen?
Aqua
prozedurale Texturen neigen dazu stark "mechanisch" zu sein.
Soll eine Textur "organisch", chaotisch und wild aussehen, ohne regelmäßige Muster,
dann sind prozedurale Texturen der falsche Weg.
Ein richtiges Foto als Textur oder von einem Zeichner der sie mit Hand erstellt bringt hier bessere Ergebnisse.
Daher werden richtige Texturen nie aussterben.
prozedurale Texturen neigen dazu stark "mechanisch" zu sein.
Soll eine Textur "organisch", chaotisch und wild aussehen, ohne regelmäßige Muster,
dann sind prozedurale Texturen der falsche WegFraktale?
Sieht auch blöd aus. Reine Materialerzeugung im Shader ist auch für die Artists ziemlich doof und neigt zum Flimmern, weil man nicht automatisch Nyquist einhält, im Gegensatz zum Texturfilter.
micki
2007-05-01, 23:09:58
Daher imo nochmal interessant nachzufragen, was derzeit noch so vor der Tür steht bzw stehen könnte.ich glaube die besten resultate gebe es, wenn man in z.b. 16facher (vermutlich weit mehr) aufloesung rendern wuerde, dann mit simplem point-filtering (eventuell mit simplem dithering) die texturen samplen wuerde bzw prozedurale materialien fuer die pixel erstellt und am ende alles auf die normale aufloesung runterrechnet.
natuerlich ist das zZ noch ne krank erscheinende idee. aber als man gerade 16 vs 32bit flamewars fuehrte und carmack von 64bit sprach, haben viele "fachleute" das auch als unsinn vertan, was ja heute standardist :)
DaEmpty
2007-05-01, 23:22:59
AF dient ja zur exakteren Bestimmung des Integrals über die Pixelfläche.
In der Richtung wird wohl kaum noch was kommen, da hochwertiges AF schon gute Ergebnisse liefert.
Was imo noch mittelfristig gute Chancen hat sich durchzusetzen ist Textursynthese.
http://research.microsoft.com/projects/AppTexSyn/
Wesentlich mehr Kontrolle als reine prozedurale Texturen, aber die Möglichkeit die Texturqualität extrem zu steigern. Eignet sich zwar nicht für alles, aber gerade Texturen, die durch Wiederholungen negativ auffallen (Landschaft, Mauern, ...) kriegt man damit sehr gut in den Griff.
Hier noch eine Idee, die zumindest das Modelling weiter beschleunigen kann:
http://www1.cs.columbia.edu/~ravir/papers/tsvbrdf/index.html
Könnte ich mir auch gut vorstellen, so etwas zur Texturveränderung zur Laufzeit zu sehen.
So könnten Designer einfach einen Parameter zum Zustand des Objekts angeben.
http://www1.cs.columbia.edu/~ravir/papers/tsvbrdf/img/main.png
Fraktale?
Erstelle mal solche Bodentexturen, wie auf diesem Screenshot zu sehen sind, mit Fraktalen, dann wirst du schnell merken, wie schnell du an die Grenzen bei prozeduralen Texturen kommst.
[img]http://flyawaysimulation.com/modules/My_eGallery/gallery/FSX/grab_387.jpg[Img]
Sorry, ging nicht richtig, hier nochmal das Bild:
http://flyawaysimulation.com/modules/My_eGallery/gallery/FSX/grab_387.jpg
peanball
2007-05-02, 07:51:10
natuerlich ist das zZ noch ne krank erscheinende idee. aber als man gerade 16 vs 32bit flamewars fuehrte und carmack von 64bit sprach, haben viele "fachleute" das auch als unsinn vertan, was ja heute standardist :)
Da gings auch um Farbtiefen, bzw. die Anzahl der verfügbaren Bits pro Farbkanal und Pixel. Soweit ich weiß sind wir jetzt gerade bei 32 bit FP.
Was du meinst sind CPUs. Der Umstieg von 16 auf 32 bit war da schon beim Intel i386. Das war ende der 80er, Anfang der 90er. Bezogen auf Carmack wars zwischen Wolf3d und Doom.
micki
2007-05-02, 09:14:03
Erazor;5455066']Da gings auch um Farbtiefen, bzw. die Anzahl der verfügbaren Bits pro Farbkanal und Pixel. Soweit ich weiß sind wir jetzt gerade bei 32 bit FP.nein, es ging nicht um die farbtiefe pro kanal, sondern die gesammt farbtiefe, voodoo konnte nur 16bit was ja "superschlecht ist" weil spiele nur wirklich gut mit 32bit aussehen wie es die rivaTNT bot. heute ist 64bit (also 4* 16bit-float) standard bei spielen.
Was du meinst sind CPUs. Der Umstieg von 16 auf 32 bit war da schon beim Intel i386. Das war ende der 80er, Anfang der 90er. Bezogen auf Carmack wars zwischen Wolf3d und Doom.emm... nein.
san.salvador
2007-05-02, 09:20:50
Die Farbtiefe ist heute bei 32Bit, nicht bei 64Bit. :D
Zu erwähnen wären noch die 22Bit der Voodoos, war damals ein anständiger Kompromiss.
micki
2007-05-02, 09:22:53
Die Farbtiefe ist heute bei 32Bit, nicht bei 64Bit. nur auf der xbox360, ansonsten rendert man auf allen anderen systemen in 64bit.
Zu erwähnen wären noch die 22Bit der Voodoos, war damals ein anständiger Kompromiss.
Das sind geblurrte 16-Bit und alles andere als ein anständiger Kompromiss.
nur auf der xbox360, ansonsten rendert man auf allen anderen systemen in 64bit.
Es gibt keine 64Bit Ausgabe auf dem PC. Nur maximal 32Bit als 8-8-8-8 oder 10-10-10-2 Format. Ist auch nicht wichtig, da das mehr ist, da das menschliche Auge eh nicht mehr Farben unterscheiden kann. Nur beim Rechnen muss man möglichst genau sein, um die Ergebnisse optimal zu halten, deshalb haben wir intern 128Bit FP Rendergenauigkeit.
micki
2007-05-02, 14:01:56
Es gibt keine 64Bit Ausgabe auf dem PC. Nur maximal 32Bit als 8-8-8-8 oder 10-10-10-2 Format.es geht hier um rendering, da braucht man 64bit damit HDR einigermassen laeuft.
Dafür dass FP16 Standard wäre wird es aber noch ziemlich selten eingesetzt. Und mit D3D10 gibt es ja neue interessante 32-Bit-Formate.
micki
2007-05-02, 15:25:17
Dafür dass FP16 Standard wäre wird es aber noch ziemlich selten eingesetzt. Und mit D3D10 gibt es ja neue interessante 32-Bit-Formate.
welches aktuelle gut aussehende spiel hat es nicht?
Tigerchen
2007-05-02, 15:36:19
welches aktuelle gut aussehende spiel hat es nicht?
HDR hat das selbe Problem wie SSAA. Es frißt für das Gros der Spieler zuviel Leistung. Und die Verbesserungen die es bisher zustande brachte sind nicht für jeden Anwender optisch überzeugend.
micki
2007-05-02, 15:42:12
HDR hat das selbe Problem wie SSAA. Es frißt für das Gros der Spieler zuviel Leistung. Und die Verbesserungen die es bisher zustande brachte sind nicht für jeden Anwender optisch überzeugend.
ja.. emm... was hat dein text mit der frage nach einem spiel dass das nicht hat zu tun?
deekey777
2007-05-02, 16:01:48
HDR hat das selbe Problem wie SSAA. Es frißt für das Gros der Spieler zuviel Leistung. Und die Verbesserungen die es bisher zustande brachte sind nicht für jeden Anwender optisch überzeugend.
Mach mal ein Beispiel.
Ich weiß nicht, ob das noch stimmt:
OpenEXR ist abseits der Spiele/Computergrafik kein vorherrschendes Format, sondern die 10-bit-Formate (DPX/Cineon).
Mr. Lolman
2007-05-02, 16:16:04
Das sind geblurrte 16-Bit und alles andere als ein anständiger Kompromiss.
Schon mal selbst gesehen? ow?
Spätestens mit 4xAA stands ECHTE 22bit gegen 24bit...
Tigerchen
2007-05-02, 18:57:23
Mach mal ein Beispiel.
Stalker. Das Spiel wird quälend langsam durch HDR. Gibt ja kaum einen der das nicht bemerkt. Und nicht jeder ist ein Tombman. Und unterm Strich siehts trotzdem nich besser aus als HL². Die CT`ist immerhin auch dieser Meinung.
Das SSAA dasselbe Problem hat ist ja wohl auch bekannt. Oder?
....aber nun ja, wir werden wieder off-topic. Und du wirst sowieso anderer Meinung sein.
Stalker. Das Spiel wird quälend langsam durch HDR
Da wird aber neben HDR noch ganz nebenbei die komplette Schattenberechnung und deferred shading aktiviert. Ein blöderes Beispiel hättest du nicht nennen können.
Die CT`ist immerhin auch dieser Meinung.
Alles was recht ist, aber bei 3D-Grafik hat die CT überhaupt keine Kompetenz.
Mackg
2007-05-02, 19:19:49
Gibts eigentlich Pläne, dass die Textureinheiten der Grafikkarte in nächster Zeit auch bikubisch filtern können? Sieht imho deutlich besser aus, verglichen mit bilinearer Filterung.
welches aktuelle gut aussehende spiel hat es nicht?
Es gibt wahrscheinlich hunderte aktuelle Spiele die kein HDR verwenden. Es mag vielleicht in einigen "großen" Titeln verwendet werden, nur ist es damit noch lange nicht "Standard".
Gibts eigentlich Pläne, dass die Textureinheiten der Grafikkarte in nächster Zeit auch bikubisch filtern können? Sieht imho deutlich besser aus, verglichen mit bilinearer Filterung.
Unwahrscheinlich, denn das bekommt man auch einfach genug im Shader hin, mit Bilinear als Grundfilter.
nein, es ging nicht um die farbtiefe pro kanal, sondern die gesammt farbtiefe, voodoo konnte nur 16bit was ja "superschlecht ist" weil spiele nur wirklich gut mit 32bit aussehen wie es die rivaTNT bot. heute ist 64bit (also 4* 16bit-float) standard bei spielen.
emm... nein.
Falsch!
Die Voodoo hatte einen 22 Bit Postfilterer, was fast so gut aussah wie 32 Bit
aber wenigstens benutzbar und schnell war.
Den 32 Bit Modus der rivaTNT konnte man im Prinzip mit ihr gar nicht nutzen, da sie zu langsam für 32 Bit war.
Der 22 Bit Postfilterer sorgte jedenfalls dafür, daß die Bildqualität näher an einem 32 Bit Bild war als an einem 16 Bit Bild.
Das sind geblurrte 16-Bit und alles andere als ein anständiger Kompromiss.
Falsch, es ist ein guter Kompromiss, da 32 Bit Performancemäßig damals gar nicht benutzbar war, wie man bis einschließlich der TNT 2 sehen konnte.
Erst die Geforce 1 oder Voodoo 5 änderte daran etwas.
Vorher war 32 Bit Farbtiefe praktisch nicht zu gebrauchen, da man ja auch noch wenigstens ne Auflösung von 1024*768 BIldpunkten haben wollte und beides, 32 Bit und 1024er Auflösung war unmöglich.
micki
2007-05-02, 23:46:08
Es gibt wahrscheinlich hunderte aktuelle Spiele die kein HDR verwenden. Es mag vielleicht in einigen "großen" Titeln verwendet werden, nur ist es damit noch lange nicht "Standard".immer noch kein beispiel.
micki
2007-05-02, 23:47:50
Falsch!
Die Voodoo hatte einen 22 Bit Postfilterer, was fast so gut aussah wie 32 Bit
aber wenigstens benutzbar und schnell war.
Den 32 Bit Modus der rivaTNT konnte man im Prinzip mit ihr gar nicht nutzen, da sie zu langsam für 32 Bit war.
Der 22 Bit Postfilterer sorgte jedenfalls dafür, daß die Bildqualität näher an einem 32 Bit Bild war als an einem 16 Bit Bild.
ja genau diesen invantilen flamewar von damals meinte ich, danke dass du dir die muehe gemacht hast es uns hier in erinnerung zu rufen. nun sollte es jedem klar sein, dass es nicht um pro kanal 16bit oder 16bit auf cpus ging.
Gibts eigentlich Pläne, dass die Textureinheiten der Grafikkarte in nächster Zeit auch bikubisch filtern können? Sieht imho deutlich besser aus, verglichen mit bilinearer Filterung.
Nichtlineare Filter haben diverse Nachteile. Bikubische Filterung sorgt z. B. für "Überschwinger" und es gibt Probleme bei der Erhaltung der Flächenhelligkeit.
immer noch kein beispiel.
Was willst du da jetzt mit Einzelbeispielen? Es geht mir um die Gesamtsituation, und wenn ich mir z.B. bei Gamespot die PC-Releases der letzten Zeit anschaue habe ich nicht den Eindruck dass sich dort FP16 HDR-Rendering schon komplett durchgesetzt hat. Und selbst dort wo es unterstützt wird heißt das noch nicht dass die Mehrheit der Spieler es auch nutzt.
Standard sind heute immer noch 32 Bit, bisher bekommt lediglich eine Minderheit tatsächlich HDR-Rendering zu sehen.
micki
2007-05-03, 15:39:04
Was willst du da jetzt mit Einzelbeispielen? ja, darum hatte ich mehrmals gebeten.
Es geht mir um die Gesamtsituation,und mir um die gesamtsituation bei spielen die auf graphik setzen. ansonsten wuerde es wegen dem Wii in 5jahren noch nicht zum standard.
Und selbst dort wo es unterstützt wird heißt das noch nicht dass die Mehrheit der Spieler es auch nutzt.bei den spielen die auf graphik setzen schon, dass WoW komplett ohne shader auskommt, genau wie sims usw. und diese spiele nen grossen teil des marktes ausmachen (stueckzahlen!) heisst ja auch nicht dass shader nicht standard waeren.
=Floi=
2007-05-03, 17:00:09
mal ne dumme frage 16XAF stellt ja mitlerweile sowieso das optimum dar was soll man da noch groß verbessen und was soll es da noch groß bringen wenn immer mehr hersteller dazu übergehen alles mit blur zu verwischen?
rennspiele, egoshooter, strategiespiele und wirtschaftssimulationen
tolle grafik und blurr dass einem das kotzen kommt...
da kann ich ja gleich auf 2XAF lassen....
was soll da eine verbesserung beim AF noch bringen?
Gibts eigentlich Pläne, dass die Textureinheiten der Grafikkarte in nächster Zeit auch bikubisch filtern können? Sieht imho deutlich besser aus, verglichen mit bilinearer Filterung.
Bei Fotobearbeitungsprogrammen habe ich den Eindruck, daß bikubisches Filtering nur bei Vergrößerungen besser aussehen als bilinear, bei Verkleinerungen ist's imho genau umgekehrt. Gleichwohl (vorausgesetzt, ich habe damit recht, womit ich mir keineswegs sicher bin), theoretisch ist es natürlich möglich, dies zu implementieren, also in Spielen einen bikubischen Algorithmus bei Texturvergrößerung und bilinear bei Texturverkleinerung einzusetzen, aber bikubisch ist auch immens mehr Rechenaufwand, als bilinear. Sowas liegt also in weiter Ferne. Und es ersetzt trilineares AF für Texturfilterung in der Tiefe sowieso nicht.
micki
2007-05-03, 18:40:27
mal ne dumme frage 16XAF stellt ja mitlerweile sowieso das optimum ...
With 4x anti-aliasing the Ti 4600 is 58 percent faster, while with 4x anti-aliasing and 64-tap anisotropic filtering turned on, the Ti 4600 is 39 percent faster.
http://news.zdnet.co.uk/hardware/0,1000000091,2103855,00.htm
also optimum ist was anderes ;)
je besser das filtering, desto besser erkennt man wie eine textur eigentlich sein sollte.
mal ne dumme frage 16XAF stellt ja mitlerweile sowieso das optimum dar was soll man da noch groß verbessen und was soll es da noch groß bringen wenn immer mehr hersteller dazu übergehen alles mit blur zu verwischen?
rennspiele, egoshooter, strategiespiele und wirtschaftssimulationen
tolle grafik und blurr dass einem das kotzen kommt...
da kann ich ja gleich auf 2XAF lassen....
was soll da eine verbesserung beim AF noch bringen?
Es gibt durchaus Extremwinkel, wo 16x AF nicht rattenscharf ist. Das liegt nicht nur an der dezenten Winkelabhängigkeit von R5x0- und G8x-AF, sondern einfach daran, dass man 32x AF für "perfekte" Schärfe braucht. Das kann man mit sensiblen Glubschern oftmals an Schrägen erkennen. 16x HQ-AF plus 4x Supersampling (=> 32x fast-winkelunabhängiges AF) bügelt alles. Ich kenne keinen Fall, wo die Texturen damit noch irgendwo leicht unscharf sind.
MfG,
Raff
ja, darum hatte ich mehrmals gebeten.
Dann lass uns doch mal eine Liste beginnen.
FP16-HDR nutzen/können:
AoE3 (Nvidia-Karten)
AoE3 The Warchiefs (Nvidia-Karten)
SeSAM 2 (IIRC)
Far Cry (mit Patch)
Source-Engine (mit CMD-Line-Parameter)
Call of Juarez (IIRC)
Bitte fortsetzen...
Q
deekey777
2007-05-03, 21:54:13
Dann lass uns doch mal eine Liste beginnen.
FP16-HDR nutzen/können:
AoE3 (Nvidia-Karten)
AoE3 The Warchiefs (Nvidia-Karten)
SeSAM 2 (IIRC)
Far Cry (mit Patch)
Source-Engine (mit CMD-Line-Parameter)
Call of Juarez (IIRC)
Bitte fortsetzen...
Q
Splinter Cell 3 und DA.
NFSC wird zwar nicht in HDR gerendert, aber für Depth of Field wird ein 64-bit-Buffer genutzt (A16B16G16R16F).
AnarchX
2007-05-03, 21:55:54
ES4: Oblivion + Addons
Rainbow6: Vegas (das war doch FP16-HDR?)
Neverwinter Nights 2
Stalker ?(bot das nicht neben dem Deferred Renderer auch FP16-HDR?)
ja, darum hatte ich mehrmals gebeten.
Mit "kein FP16-HDR-Rendering" wird ja nun mal leider selten beworben, aber schau dir z.B. mal hier (http://uk.gamespot.com/reviews.html?type=reviews&platform=5&tag=subnav;reviews) die Liste der letzten Reviews an. Da scheint mir vom letzten Dutzend nicht unbedingt die Mehrheit HDR-Rendering zu nutzen.
und mir um die gesamtsituation bei spielen die auf graphik setzen. ansonsten wuerde es wegen dem Wii in 5jahren noch nicht zum standard.
Dann haben wir wohl eine unterschiedliche Vorstellung von "Standard".
deekey777
2007-05-04, 00:47:56
Stalker? (bot das nicht neben dem Deferred Renderer auch FP16-HDR?)
Deferred Rendering und dazu noch ein FP16-Buffer. Mehr geht nicht. :uup:
Die Aussagen der Entwickler sind, dass das Spiel seit 2004 FP16-HDRR verwendet.
StefanV
2007-05-04, 02:48:59
Dann lass uns doch mal eine Liste beginnen.
FP16-HDR nutzen/können:
AoE3 (Nvidia-Karten)
AoE3 The Warchiefs (Nvidia-Karten)
SeSAM 2 (IIRC)
Far Cry (mit Patch)
Source-Engine (mit CMD-Line-Parameter)
Call of Juarez (IIRC)
Bitte fortsetzen...
Q
Splinter Cell 3 und DA.
NFSC wird zwar nicht in HDR gerendert, aber für Depth of Field wird ein 64-bit-Buffer genutzt (A16B16G16R16F).
ES4: Oblivion + Addons
Rainbow6: Vegas (das war doch FP16-HDR?)
Neverwinter Nights 2
Stalker ?(bot das nicht neben dem Deferred Renderer auch FP16-HDR?)
Warum habt ihr Anno1701 vergessen? :|
CnC3 nutzt ja nur Bloom, AFAIK
Blaze
2007-05-04, 09:34:49
TDU nicht zu vergessen, nutzt afaik auch FP16-HDR.
mickii
2007-05-04, 09:35:00
mehrheitlich auch nonames die nicht auf graphik setzen. da muessten wir handygames dazuzaehlen und dann waere heute noch 2D standard.
[quote]Dann haben wir wohl eine unterschiedliche Vorstellung von "Standard".scheint so, ich zaehle noise nicht mit ein.
NFSC wird zwar nicht in HDR gerendert, aber für Depth of Field wird ein 64-bit-Buffer genutzt (A16B16G16R16F).
NFSC und DOF?
deekey777
2007-05-04, 10:46:19
NFSC und DOF?
Nicht während man Rennen fährt. :smile:
http://img142.imageshack.us/img142/9924/nfscppdof1vz4.th.jpg (http://img142.imageshack.us/my.php?image=nfscppdof1vz4.jpg)
Bei Fotobearbeitungsprogrammen habe ich den Eindruck, daß bikubisches Filtering nur bei Vergrößerungen besser aussehen als bilinear, bei Verkleinerungen ist's imho genau umgekehrt. Gleichwohl (vorausgesetzt, ich habe damit recht, womit ich mir keineswegs sicher bin), theoretisch ist es natürlich möglich, dies zu implementieren, also in Spielen einen bikubischen Algorithmus bei Texturvergrößerung und bilinear bei Texturverkleinerung einzusetzen, aber bikubisch ist auch immens mehr Rechenaufwand, als bilinear. Sowas liegt also in weiter Ferne. Und es ersetzt trilineares AF für Texturfilterung in der Tiefe sowieso nicht.Für Verzerrungen. AF filtert verzerrte Texturen besser als IF.
Sowohl bei Vergrößerung als auch bei Verkleinerung können größere Filterkernel sinnvoll sein. Bei Texturfilterung gibt es allerdings zusätzliche Kriterien, die nichtlineare Filterung ungünstig machen.
mehrheitlich auch nonames die nicht auf graphik setzen. da muessten wir handygames dazuzaehlen und dann waere heute noch 2D standard.
Warum sollten wir Handyspiele zählen müssen? Ich rede lediglich von aktuellen PC-Spielen (auch wenn deine Aussage sich auf "alle anderen Systeme außer Xbox360" bezog, womit du eigentlich auch nur PC und PS3 gemeint haben kannst).
Und wenn nur ein paar Blockbuster FP16-HDR einsetzen, dann ist das eben für mich noch lange nicht Standard.
mickii
2007-05-04, 17:13:22
Warum sollten wir Handyspiele zählen müssen? Ich rede lediglich von aktuellen PC-Spielen (auch wenn deine Aussage sich auf "alle anderen Systeme außer Xbox360" bezog, womit du eigentlich auch nur PC und PS3 gemeint haben kannst).
Und wenn nur ein paar Blockbuster FP16-HDR einsetzen, dann ist das eben für mich noch lange nicht Standard.ich bezog mich ebenfalls auf spiele die auf graphik setzen. das nimmt z.b. Wow heraus, auch wenn es auf _deiner_ liste waere.
um noch mal auf den ursprünglichen Thread zurückzukommen:
Ich hoffe immer noch das es besseres geben wird als AF. Der einzige Kandidat der mir aber dazu einfällt ist FAST bzw. Footprint Area Sampled Texturing. Das ganze ist auch nicht mehr ganz neu, es wurde so ca. 2001 - 2002 entwickelt. Link:
http://www-users.cs.umn.edu/~baoquan/pubs.html
bzw.
http://www-users.cs.umn.edu/~baoquan/papers/fast.pdf [ 6MB]
ich bezog mich ebenfalls auf spiele die auf graphik setzen. das nimmt z.b. Wow heraus, auch wenn es auf _deiner_ liste waere.Der Spielemarkt besteht nicht nur aus den großen Blockbustern. Viele Spiele zielen eher auf den "Casual Gamer" und da ist HDR-Rendering noch lange nicht Standard. Ihr redet also aneinander vorbei. Xmas betrachtet den kompletten Spielemarkt, du nur die Grafikknaller.
mickii
2007-05-05, 09:17:27
Der Spielemarkt besteht nicht nur aus den großen Blockbustern. Viele Spiele zielen eher auf den "Casual Gamer" und da ist HDR-Rendering noch lange nicht Standard. Ihr redet also aneinander vorbei. Xmas betrachtet den kompletten Spielemarkt, du nur die Grafikknaller.
der markt besteht aus sovielen spielen dass du in dem fall nichtmal shader als standard sehen duerftest, da die meisten causal/shareware games ohne auskommen. aber es waere eben "bloedsinn" spiele als referenz zu nehmen die garnicht mit graphik beeindrucken wollen.
G.A.S.T.
2007-05-06, 23:17:47
Da es ja hier darum geht, wie man die Bildqualität noch weiter verbessern könnte, als durch AF, habe ich mal eine Frage zu Level of Detail:
Warum kann man nicht immer eine Detailstufe von Texturen einsetzen, die schon fast der Auflösung auf dem Bildschirm entspricht (ausser es steht keine höhere mehr zur Verfügung)?
Mit dem Auswählen einer höheren Bildschirmauflösung versucht man doch im Grunde genommen ähnliches zu erreichen.
Die Füllrate und Speicherbandbreite von GraKas müsste ja langsam mal dafür ausreichen. Ist ne Verständnisfrage, da ich davon nicht viel Ahnung hab.
mfG
mickii
2007-05-07, 11:45:41
Warum kann man nicht immer eine Detailstufe von Texturen einsetzen, die schon fast der Auflösung auf dem Bildschirm entspricht (ausser es steht keine höhere mehr zur Verfügung)?das macht man auch.
die frage ist, was soll man machen wenn man gerade zwischen zweif aufloesungen ist? wenn man zu sehr in die kleinere interpoliert, dann sieht man matsch, zu sehr in die grosse, dann flimmert es. AF ist eine moeglichkeit, weil es eben die grosse nimmt, aber soviele samples macht, dass das flimmern sich abglaettet. je mehr samples AF macht, desto groesser kann man die textur eigentlich waehlen.
Warum kann man nicht immer eine Detailstufe von Texturen einsetzen, die schon fast der Auflösung auf dem Bildschirm entspricht (ausser es steht keine höhere mehr zur Verfügung)?
LoD für Texturen ist im Grunde nichts anderes als vorberechnetes SSAA.
FlashBFE
2007-05-07, 12:59:33
Da ja der trilineare und anisotrope Filter im Prinzip nur dafür da ist, die Probleme auszubügeln, die man sich durch das Mip-Mapping eingehandelt hat, wird wohl sinnvollerweise die nächste Filterung nicht oben drauf ansetzen, sondern wieder ganz unten anfangen und das Mip-Mapping abschaffen, so wie das:
ich denke, irgendwann wird man auf Mip-Mapping verzichten, und alle relevanten Texel direkt aus der Haupt-Textur holen. Das ergibt dann wirklich optimale Filterung.
Da ja Mip-Mapping + Bilinearer Filter nicht anders wirkt als ein adaptiver Unschärfefilter, kann man das auch gleich durch einen solchen ersetzen. Allgemeiner gesagt: man haut stattdessen mit irgendeiner Form von Antialiasing drauf, bis alles Texturflimmern der Vergangenheit angehört.
Allgemeiner gesagt: man haut stattdessen mit irgendeiner Form von Antialiasing drauf, bis alles Texturflimmern der Vergangenheit angehört.
Wenn du noch verrätst wie man das mit realisierbarem Aufwand implementieren kann wär das eine interessante Idee.
micki
2007-05-07, 15:08:24
Allgemeiner gesagt: man haut stattdessen mit irgendeiner Form von Antialiasing drauf, bis alles Texturflimmern der Vergangenheit angehört.das hatte ich hier auch vorgeschlagen *hehe* ist sicherlich in zukunft ein nettes feature
G.A.S.T.
2007-05-07, 15:26:58
das macht man auch.
die frage ist, was soll man machen wenn man gerade zwischen zwei aufloesungen ist? wenn man zu sehr in die kleinere interpoliert, dann sieht man matsch, zu sehr in die grosse, dann flimmert es. AF ist eine moeglichkeit, weil es eben die grosse nimmt, aber soviele samples macht, dass das flimmern sich abglaettet. je mehr samples AF macht, desto groesser kann man die textur eigentlich waehlen.Wenn das so ist, wozu braucht man dann immernoch mindestens 4xMSAA um die Kanten geglättet zu bekommen? Wieso sind selbst dann die Kanten noch nicht richtig glatt?
Eigentlich müsste sonst ja selbst bei 2facher Kantenglättung keine weitere Verbesserung mehr möglich sein, ausser wenn man an eine Textur ganz nah ran geht und es keine höhere Detailstufe mehr gibt.
Texturen haben nichts mit Geometriekanten zu tun.
G.A.S.T.
2007-05-07, 18:01:04
Texturen haben nichts mit Geometriekanten zu tun.
Und woraus bestehen diese Kanten dann?
Dachte eigentlich, es sei der Rand einer Textur.
Es sind die Kanten von Polygonen, die durch ihre Eckpunkte angegeben werden. Solche Geometriedaten definieren die Form und Lage der Objekte in einer 3D-Szene. Texturen (bzw. der Pixelshader der jene Texturen verwendet) beschreiben dann Oberflächendetails.
FlashBFE
2007-05-07, 18:11:14
Wenn du noch verrätst wie man das mit realisierbarem Aufwand implementieren kann wär das eine interessante Idee.
Aufwand? Es ging doch hier um zukünftige mögliche Techniken, oder? ;)
Die Hardcoremethode wäre genug SSAA. Aber ich weiß nicht, wieviel genug ist. Idealerweise natürlich alle Texel pro Pixel.
Die zweite Möglichkeit wie schon angesprochen ein adaptiver Unschärfefilter auf der Textur, der mit zunehmender Z-Tiefe stärker wird. Ein Hochpassfilter wäre da das Optimum und man könnte ihn perfekt an die Bildschirmauflösung anpassen. Also je höher aufgelöst der Bildschirm, desto höher kann der Hochpass gelegt werden und man gewinnt real an Schärfe.
In der Zukunft wird die Rechenleistung schon irgendwann für sowas dasein. Aber es gibt bestimmt auch genug kluge Mathematiker, die sich was effizienteres ausdenken.
G.A.S.T.
2007-05-07, 21:17:18
Es sind die Kanten von Polygonen, die durch ihre Eckpunkte angegeben werden. Solche Geometriedaten definieren die Form und Lage der Objekte in einer 3D-Szene. Texturen (bzw. der Pixelshader der jene Texturen verwendet) beschreiben dann Oberflächendetails.
Komisch, ich hätte gedacht, die Polygone selbst sind unsichtbar und was man sehen kann sind nur die Texturen, die auf den Polygonen drauf sind.
Wobei aber dann die Frage offen bleibt, warum denn die Polygonenkanten noch grobpixeliger als die Texturen selber sind. :confused:
DerRob
2007-05-08, 00:55:57
Komisch, ich hätte gedacht, die Polygone selbst sind unsichtbar und was man sehen kann sind nur die Texturen, die auf den Polygonen drauf sind.
ja, das ist ja auch richtig
Wobei aber dann die Frage offen bleibt, warum denn die Polygonenkanten noch grobpixeliger als die Texturen selber sind. :confused:
weil innerhalb einer textur kaum starke farbunterschiede auftreten, meistens ist das z.b. bei einer sand-textur ein brauner pixelbrei. wenn also nicht gerade ein schachbrett-muster auf dem poygon liegt, fällt das grobpixelige also nicht so sehr auf, wie z.b. ein dunkler laternenpfahl gegenüber einem hellen himmel.
Neomi
2007-05-08, 02:24:52
ja, das ist ja auch richtig
Nein, ganz und gar nicht.
Komisch, ich hätte gedacht, die Polygone selbst sind unsichtbar und was man sehen kann sind nur die Texturen, die auf den Polygonen drauf sind.
Sichtbar (je nach Alphawert und Blendstates auch teilweise oder gar nicht) sind die Dreiecke mit einem pro Pixel bestimmten Farbwert. Wie dieser Farbwert bestimmt wird, entscheidet das Programm bzw. der Programmierer. Und wenn der sich dazu entscheidet, ganz auf Texturen zu verzichten, dann wird eben ein Bild ganz ohne Texturen erzeugt.
G.A.S.T.
2007-05-08, 10:42:19
Sichtbar (je nach Alphawert und Blendstates auch teilweise oder gar nicht) sind die Dreiecke mit einem pro Pixel bestimmten Farbwert. Wie dieser Farbwert bestimmt wird, entscheidet das Programm bzw. der Programmierer. Und wenn der sich dazu entscheidet, ganz auf Texturen zu verzichten, dann wird eben ein Bild ganz ohne Texturen erzeugt.
Gut, also kann man es so verstehen, dass die Textur das Polygon nur überschreibt.
Wobei aber dann die Frage offen bleibt, warum denn die Polygonenkanten noch grobpixeliger als die Texturen selber sind.Warum kann man denn nicht für die Polygone das gleiche LoD verwenden, wie für die Textur, die da drauf gepflastert wird?
Oder würde das zu sehr auf die Performance gehen?
Neomi
2007-05-08, 11:15:28
Gut, also kann man es so verstehen, dass die Textur das Polygon nur überschreibt.
Nein, definitiv nicht. Texturen überschreiben nichts, sie sind passive Ressourcen. Sie können (müssen aber nicht) dazu genutzt werden, die Farbe von Pixeln innerhalb eines Dreiecks zu bestimmen.
Warum kann man denn nicht für die Polygone das gleiche LoD verwenden, wie für die Textur, die da drauf gepflastert wird?
Oder würde das zu sehr auf die Performance gehen?
Texturen sind Rasterdaten, Geometrie nicht. In der Regel werden sie gemeinsam benutzt, deshalb sind sie aber noch lange nicht gleich zu behandeln.
Da ja Mip-Mapping + Bilinearer Filter nicht anders wirkt als ein adaptiver Unschärfefilter, kann man das auch gleich durch einen solchen ersetzen. Allgemeiner gesagt: man haut stattdessen mit irgendeiner Form von Antialiasing drauf, bis alles Texturflimmern der Vergangenheit angehört.Na dann hau mal bei 16-facher Verkleinerung pro Achse "irgendeine Form von Antialiasing" drauf. Um die Datenrate bei Texturverkleinerung konstant zu halten, sind MIP-Maps notwendig. Die Daten immer aus der Basis-Textur zu holen steht in keinem Aufwand zum Verhältnis.
G.A.S.T.
2007-05-08, 13:38:24
Texturen sind Rasterdaten, Geometrie nicht. In der Regel werden sie gemeinsam benutzt, deshalb sind sie aber noch lange nicht gleich zu behandeln.
Naja, auf meine Frage, warum denn die Polygonenkanten in Spielen so grobpixelig sind, hab ich immernoch keine Antwort.
Hängt es nun nur mit Performance zusammen, oder hat es andere Gründe?
Naja, auf meine Frage, warum denn die Polygonenkanten in Spielen so grobpixelig sind, hab ich immernoch keine Antwort.
Weil das mit den Texturen nichts zu tun hat. Es werden Dreiecke gerastert und ohne Multisampling wird eben pro Pixel nur ein Sample genommen und damit gibt es an den Ecken harte Kanten.
Naja, auf meine Frage, warum denn die Polygonenkanten in Spielen so grobpixelig sind, hab ich immernoch keine Antwort.
Hängt es nun nur mit Performance zusammen, oder hat es andere Gründe?
Weil polygonkanten eben kanten sind, da entstehen meist hohe kontraste zwischen dem was sich auf der einen, bzw. anderen seite der kante befindet, und das fällt eben sehr stark auf. Wenn du zum beispiel eine textur nehmen würdest welche einzelne schwarze und weiße linien hat und diese textur auf eine fläche legst und sie ohne filterung (bzw. mit point filtering) zeichnen lässt, dann würden die übergänge zwischen den schwarzen und weißen bereichen genause schlecht aussehen wie polygonkanten der fläche auf welcher diese textur angewendet wird. Da solche extremfälle (schwarz-weiße texturen) aber meistens nicht auftauchen und texturen innerhalb einer fläche meistens recht änhliche farben (mehr oder weniger) haben da sie ein bestimmtes material simulieren sollen (haut, textil, dreck, beton, metall, was auch immer), ensteht der eindruck das kanten-aliasing stärker ist als textur aliasing. Das ganze wird allerdings am meistens dadurch hervorgerufen das defaultmässig auch heute noch keine kanten-antialiasing methoden aktiv sind, texturen werden aber default mindestens bilinear gefiltert, auch im miserabelsten spiel welches auf den markt kommt. Stell dir vor alles hätte mindestens 2x kanten-antialiasing, dann würden dir die polygonkanten nicht mehr so sehr ins auge stechen
Naja, auf meine Frage, warum denn die Polygonenkanten in Spielen so grobpixelig sind, hab ich immernoch keine Antwort.
Hängt es nun nur mit Performance zusammen, oder hat es andere Gründe?
Wie schon von anderen ausgeführt: Kontrast!
Es gibt ja auch viele Polygonkanten die du gar nicht richtig siehst. Wenn du eine große Textur über mehrere Polygone drüber legst siehst du die vielen Polygonkanten gar nicht. Vor allem bei aufwendigen Polygonmodellen ist das sehr schön zu sehen. Erst da wo er Kontrast zwischen Polygonen höher wird siehst du dann auch das Aliasing sehr gut.
Außerdem sind polygonkanten immer genauso fein aufgelöst, wie die auflösung hergibt, würde man aber bei texturen standardmässig auf point sampling setzen, hättest du da dauernd texel welche mehrere pixel belegen würden (d.h. du hättest einzelne bunte rechtecke welche schon mal hunderte von pixeln groß sind - DA kannst du dich dann über grobe auflösung beklagen ;)
Um das in aktion zu sehen kannst du irgendwelche alten spiele anwerfen welche noch aus zeiten ohne 3D hardware mit bilinearer filterung stammen.
(bzgl. auflösung der polygonkante spreche ich hier nicht von den sonderfällen wo irgendwelche idiotischen developer meinen das bild wegen irgendwelcher schlecht gemachten post-processing effekten in kleiner auflösung zu berechnen, und es dann auf die eigentliche auflösung hochzuskalieren, das verstärkt natürlich den aliasing effekt, verwischt auch noch zusätzlich das bild, und sieht total beschissen aus - da kann man gleich die high-end grafikkarte sparen, die auflösung auf 1024x768 oder niedriger setzen und den LCD hochskalieren lassen; aktuell zu bestaunen bei Stalker, screens findest du zur genüge im screenshot thread - trotzdem sind die leutchen da hin und weg von der ach so tollen grafik).
Schimi1983
2007-05-08, 16:22:39
Naja, auf meine Frage, warum denn die Polygonenkanten in Spielen so grobpixelig sind, hab ich immernoch keine Antwort.
Hängt es nun nur mit Performance zusammen, oder hat es andere Gründe?
vielleicht hilft die was davon weiter um es zu verstehen:
Link1: http://www.3dconcept.ch/artikel/filtering/index.html
Link2: http://www.3dconcept.ch/artikel/3dhow/index.html
G.A.S.T.
2007-05-08, 17:35:26
Außerdem sind polygonkanten immer genauso fein aufgelöst, wie die auflösung hergibt
Also doch?
Ist es dann etwa doch nicht falsch, dass die Auflösung von Polygonenkanten durch die Auflösung von Texturen (und dem verwendeten LoD) limitiert wird?
Wenn man nur einfarbige Polygone und keine Texturen verwenden würde, dann bräuchte man also theoritisch auch kein FSAA, oder etwa doch?
würde man aber bei texturen standardmässig auf point sampling setzen, hättest du da dauernd texel welche mehrere pixel belegen würden (d.h. du hättest einzelne bunte rechtecke welche schon mal hunderte von pixeln groß sind - DA kannst du dich dann über grobe auflösung beklagen ;)
Also wird dann aus diesem Grund das LoD nicht so hoch gewählt bzw. ist es aus genau diesem Grund nicht möglich, mehr Bildschärfe zu erzeugen, indem man immer ein möglichst hohes LoD verwendet?
Ich hatte nämlich eine Seite vorher danach gefragt.
Nein, definitiv nicht. Texturen überschreiben nichts, sie sind passive Ressourcen. die Texturen an und für sich vielleicht nicht, aber das Aufbringen der Texturen auf die Polygone, auch Textur-Mapping genannt.
Sie können (müssen aber nicht) dazu genutzt werden, die Farbe von Pixeln innerhalb eines Dreiecks zu bestimmen.ganz recht, und wenn sie hierzu benutzt werden, indem Textur-Mapping durchgeführt wird, dann überschreiben sie die Farbinformation des Dreiecks :)
Also doch?
Ist es dann etwa doch nicht falsch, dass die Auflösung von Polygonenkanten durch die Auflösung von Texturen (und dem verwendeten LoD) limitiert wird?
Wenn man nur einfarbige Polygone und keine Texturen verwenden würde, dann bräuchte man also theoritisch auch kein FSAA, oder etwa doch?ich glaube du verwechselst Bildschirmauflösung und Texturauflösung.
Bei einfarbigen Polygonen ist Texturauflösung nicht definiert - man könnte das auch als Grenzfall sehr schlechter Texturauflösung betrachten - wohl aber eine Bildschirmauflösung: das einfarbige Polygon nimmt eine begrenzte Zahl an Bildschirmpixeln ein, was ohne AA-Verfahren zu einer Treppenförmigkeit der Polygonkanten führt.
Wobei aber dann die Frage offen bleibt, warum denn die Polygonenkanten noch grobpixeliger als die Texturen selber sind. :confused:sie sind es gar nicht :)
Die Texturen sind immer mindestens genauso grobpixelig wie die Polygonkanten. Pro Pixel (bei eingeschaltetem AA pro Subpixel) kann ja höchstens ein einziger Texturwert vorhanden sein.
Nur die Grobpixeligkeit an den Kanten i.d.R. sehr viel auffälliger, aus Gründen die dir schon genannt wurden, Stichwort Kontrast.
sie sind es gar nicht :)
Die Texturen sind immer mindestens genauso grobpixelig wie die Polygonkanten. Pro Pixel (bei eingeschaltetem AA pro Subpixel) kann ja höchstens ein einziger Texturwert vorhanden sein.
Nur die Grobpixeligkeit an den Kanten i.d.R. sehr viel auffälliger, aus Gründen die dir schon genannt wurden, Stichwort Kontrast.Was ist jetzt der Unterschied von Textur- zu Polygonkanten? Was man bei 3D-Grafik sieht, sind immer Polygone – meistens mit Texturen tapeziert. Die Texturen ansich sieht man aber nicht (jedenfalls nicht 1:1) da ein Resampling auf das entsprechende Polygon stattfindet.
Was ist jetzt der Unterschied von Textur- zu Polygonkanten? Was man bei 3D-Grafik sieht, sind immer Polygone – meistens mit Texturen tapeziert. Die Texturen ansich sieht man aber nicht (jedenfalls nicht 1:1) da ein Resampling auf das entsprechende Polygon stattfindet.soll das im Widerspruch zu dem von mir geschriebenen stehen? Ich jedenfalls sehe keinen Widerspruch.
Ich jetzt auch nicht mehr – brauche ich im Internet schon eine Brille?
Ist es dann etwa doch nicht falsch, dass die Auflösung von Polygonenkanten durch die Auflösung von Texturen (und dem verwendeten LoD) limitiert wird?
Doch das ist absolut falsch.
Wenn man nur einfarbige Polygone und keine Texturen verwenden würde, dann bräuchte man also theoritisch auch kein FSAA, oder etwa doch?
Natürlich braucht man weiterhin AA. Die Texturlosigkeit ändert doch an der Rasterung nichts. Du hast da echt irgendwo ne ziemlich falsche Vorstellung.
Ok G.A.S.T... versuch zu verstehen daß polygone eigentlich nichts mit texturen zu tun haben, idealerweise könnte man jedes beliebige objekt aus milliarden von farbigen polys modellieren, um so jede kleine unebenheit der oberflächenstruktur wiederzugeben, ohne irgendeine textur zu verwenden (daß das nicht praktikabel ist erkennst du warscheinlich selber). Texturen sind so gesehen nur eine notlösung, ein billiger, rechenpowerschonender trick um auf einer detaillosen, glatten fläche den eindruck zu erzeugen daß da realistische details, unebenheiten, verschmutzungen, strukturelle imperfektionen, usw. vorhanden wären. Texturen können und machen nichts an der struktur welche von den einzelnen flächen (polygonen) definiert wird*, es ist egal ob eine textur 1x1 texel groß ist oder 100000x100000 texel, es ist egal welche lod-stufen für die texturen benutzt werden oder ob überhaupt textur lod zum einsatz kommt oder nicht, deine polygonkanten werden genauso auschauen und immer hässlich auffallen wenn der kontrast einen gewissen wert überschreitet. Polygonkanten werden auf deinem (im verhältnis zu deinen augen) niedrig aufgelösten bildschirm immer zackig erscheinen solange man keine methoden gegen kanten-aliasing einsetzt, oder solange man keine bildschirme entwickelt welche eine zig- bis hunderte male höhere auflösung bieten.
*bevor hier ein experte auf die idee kommt von echtem displacement mapping loszuquatschen, das ist hier nicht gemeint, ist hoffentlich klar ;)
Neomi
2007-05-08, 23:52:16
die Texturen an und für sich vielleicht nicht, aber das Aufbringen der Texturen auf die Polygone, auch Textur-Mapping genannt.
Ach echt, das wird Texture-Mapping genannt? Das hätte ich ja jetzt gaaar nicht gedacht... :rolleyes:
ganz recht, und wenn sie hierzu benutzt werden, indem Textur-Mapping durchgeführt wird, dann überschreiben sie die Farbinformation des Dreiecks :)
Denk darüber lieber nochmal genau nach. Die Textur überschreibt nicht die Farbinformationen, sie liefert die Farbinformationen.
del_4901
2007-05-09, 00:09:48
Ach echt, das wird Texture-Mapping genannt? Das hätte ich ja jetzt gaaar nicht gedacht... :rolleyes:
Ist das ganz neu oder was? Höhr ich auch zum ersten mal .... man man muss mir doch mal VISTA und D10 installiern.
Ist das ganz neu oder was? Höhr ich auch zum ersten mal .... man man muss mir doch mal VISTA und D10 installiern.
nö, das gab es auch schon in software-2D-engines.
1. du weisst wohl nicht was ironie ist
2. du meinst vielleicht software 3D-engines, weil texture mapping und 2D beisst sich doch etwas, meinst du nicht ?
Gemeint ist wohl "unechtes" 3D wie bei Doom oder Duke 3D, wobei hier von texture mapping eigentlich auch nicht wirklich zu reden ist...
del_4901
2007-05-10, 17:05:15
Gemeint ist wohl "unechtes" 3D wie bei Doom oder Duke 3D, wobei hier von texture mapping eigentlich auch nicht wirklich zu reden ist...
Unechtes 3d gibt nicht.
Es gibt nur affines und perspektivisches TM.
Projective gibt es auch, das hab ich aber bewust weggelassen.
Gemeint ist wohl "unechtes" 3D wie bei Doom oder Duke 3D, wobei hier von texture mapping eigentlich auch nicht wirklich zu reden ist...
Sowohl Doom wie auch Duke Nukem 3D haben "echte" 3D engines mit echtem texture mapping auf echten polygonen.
Wenn du mit "unechtem" 3D vielleicht die sprites meinst welche zur darstellung der objekte und kreaturen in diesen engines verwendet werden, dann könnte man deine aussage von unechtem 3D insofern als richtig hinnehmen daß die dargestellten objekte (waffe, monster) tatsächlich nicht in 3D modelliert sind, aber technisch gesehen sind diese sprites trotzdem vollwertige, "echte", texturierte 3D objekte: ein sprite ist nämlich nichts anderes als ein rechteck bestehend aus 2 dreiecken, mit einer textur drauf, wobei die (meistens animierte) textur das gewünschte monster oder was auch immer darstellt. Sprites werden übrigens auch heute noch vewendet um rauch, feuer, explosionen, vegetation, usw. darzustellen
2. du meinst vielleicht software 3D-engines, weil texture mapping und 2D beisst sich doch etwas, meinst du nicht ?
Nö, tut's nicht.
http://www.theinquirer.net/default.aspx?article=39101
BTW ... und wann kommt Echtzeit-Raytracing?
5Jahre? 10? egal: es kommt! :wink:
Sowohl Doom wie auch Duke Nukem 3D haben "echte" 3D engines mit echtem texture mapping auf echten polygonen.
Nöp, Doom und ähnliches sind Raycaster.
StefanV
2007-05-11, 03:54:25
5Jahre? 10? egal: es kommt! :wink:
...nicht...
Beschäftige dich damit mal und du wirst feststellen, das es garnicht so toll ist, wie es von einigen geredet wird...
del_4901
2007-05-11, 06:38:44
Nöp, Doom und ähnliches sind Raycaster.
"Da hab ich ihn erschossen, Herr Richter"
Liszca
2007-05-11, 12:52:39
Da wird aber neben HDR noch ganz nebenbei die komplette Schattenberechnung und deferred shading aktiviert. Ein blöderes Beispiel hättest du nicht nennen können.
Alles was recht ist, aber bei 3D-Grafik hat die CT überhaupt keine Kompetenz.
ein tolles beispiel ist far cry, am anfang wow...
...ist das lahm/schick nun.
sieht auch wirklich schick aus im ersten moment, später stört eigentlich nur dass es zu langsam ist, und der unterschied der dargestellt werden soll ist mir dann auch nicht mehr so klar, bis sonne kommt *eg*
Der Content von Far Cry war auch nie auf HDR ausgelegt. Auch kein gutes Beispiel.
Schaut euch z.B. mal das HDR in Cell Factor an. Das ist echt super gemacht.
Denk darüber lieber nochmal genau nach. Die Textur überschreibt nicht die Farbinformationen, sie liefert die Farbinformationen.sie liefert nicht die Farbinformation, liefert eine Farbinformation. Und diese von der Textur gelieferte Farbinformation überschreibt diejenige Farbinformation, die das Polygon ohne die aufgetragene Textur hätte. I.d.R. wäre das einfach monochromes Weiß.
Nein. Texturen sind eine Resource die vom Shaderprogramm beliebig gelesen werden können. Es wird überhaupt nichts "überschrieben". Texturen sind einfach ein 2D-Array an Informationen. Polygone sind auch nicht "weiß" ohne Textur. Genauer gesagt kann man sogar ohne Texturen schöne Muster erzeugen (Stichwort prozedurale Materialien).
Der Rasterizer erzeugt ein Pixelmuster dass das Dreieck auf dem Bildschirm abdeckt und interpoliert die von den Vertexshadern ausgegebenen Informationen über die Fläche. Für jeden Pixel wird dann ein Pixelshader ausgeführt, der machen kann was ihm beliebt. Unter anderem auch Texturen samplen.
Ein simpler Pixelshader kann auch einfach "return float4(1.0f,0.0f,0.0f,0.0f);" lauten, was das Dreieck einfach rot füllen würde.
Eine Textur ist nichts weiter als eine passive Resource. Noemi weiß von was er redet, glaub ihm einfach.
Neomi
2007-05-14, 01:48:45
sie liefert nicht die Farbinformation, liefert eine Farbinformation. Und diese von der Textur gelieferte Farbinformation überschreibt diejenige Farbinformation, die das Polygon ohne die aufgetragene Textur hätte. I.d.R. wäre das einfach monochromes Weiß.
Wenn du Haare spalten willst, bitte sehr, das kann ich auch. Und ich brauche, anders als du, keine 5 Tage für 3 Sätze. Also dann, auf zur Haarspalterei...
1. Wenn eine Textur das Ergebnis überschreiben würde, das ohne die Textur vorhanden wäre, dann wäre es die einzig verbleibende Farbinformation. Nicht eine (einfließende) Farbinformation, sondern die (einzige) Farbinformation. Simpelstes Texturemapping war nicht mein Beispiel.
2. Die Textur bzw. genauer ausgedrückt das Sampling der Textur liefert einen Farbwert, der nichts anderes überschreibt. Entweder wird mit anderen Werten verrechnet, oder das Ergebnis unverändert genommen, aber kein vorher im Shader berechneter Wert wird überschrieben. Der Shadercompiler optimiert diese anderen Berechnungen in dem Fall nämlich raus, so daß nichts zum überschreiben übrig bleibt. Und komm jetzt nicht mit Fixed Function Setups, absichtlich schlecht geschriebenen Assembler-Shadern oder mit per Compilerflags deaktivierten Optimierungen für den Shadercompiler daher. Da kein Technologielevel spezifiziert wurde, gilt der aktuelle Stand der Dinge.
3. Ja, es gibt eine Defaultfarbe für den Fall, daß keine Textur an einen Sampler gebunden ist. Nein, diese Defaultfarbe wird bei vorhandener Textur beim Sampling nicht überschrieben. Wenn eine Textur gesetzt ist, wird gesampelt, andernfalls die Defaultfarbe zurückgeliefert. Die Defaultfarbe wird in dem Fall einer gesetzten Textur einfach nicht herangezogen, weshalb sie auch nicht überschrieben werden kann.
4. Die Defaultfarbe gilt auch nur dann als alternative Farbe, wenn keine Textur gesetzt ist, nicht wenn keine Textur gesampelt wird. Es gibt keine Defaultfarbe für den Pixelshaderoutput.
5. "Monochromes Weiß" klingt doch ein wenig sehr redundant, meinst du nicht auch? Oder hast du schonmal ein Weiß gesehen, das nicht monochrom ist?
Wie du siehst, kann ich besser Haare spalten als du. Aber ehrlich gesagt habe ich auf sowas keine Lust, zumindest nicht mit einem anonymen Gast. Wenn du lieber an deine Farb(überschreibungs)theorie glauben willst, mach das und werde glücklich damit, ich verlasse mich lieber auf Tatsachen.
Nein. Texturen sind eine Resource die vom Shaderprogramm beliebig gelesen werden können. Es wird überhaupt nichts "überschrieben". Texturen sind einfach ein 2D-Array an Informationen. Polygone sind auch nicht "weiß" ohne Textur. Genauer gesagt kann man sogar ohne Texturen schöne Muster erzeugen (Stichwort prozedurale Materialien).ganz recht: man kann. Tut man es aber nicht, ist das Polygon per default weiß.
Allerdings habe ich mich tatsächlich geirrt: stellt man z.B. unter OpenGL mit glColor() eine Farbe ein, wird beim Textur-Mapping diese mit der Texturfarbe gemischt, statt einfach von dieser überschrieben.
Allerdings hat Neomi dann auch unrecht, wenn er sagt die Textur würde die Farbinformationen liefern. Sie liefert demnach nämlich nur einen Beitrag zu den Farbinformationen, der mit anderen Beiträgen vermischt wird.
In den Spezialfällen, in denen die sichtbare Farbe allein durch die Textur bestimmt wird, ist es tatsächlich legitim zu sagen, das Textur-Mapping würde die Default-Farbe (monochromes Weiß) überschreiben.
Wenn du Haare spalten willst, bitte sehr, das kann ich auch. Und ich brauche, anders als du, keine 5 Tage für 3 Sätze.eine Anspielung auf die Zeit, die zwischen meinen Postings vergangen ist? Die könnte auch einfach darin begründet liegen, daß ich nicht jeden Tag in diesem Forum zubringe und daher deine Antwort nicht sofort lesen konnte.
1. Wenn eine Textur das Ergebnis überschreiben würde, das ohne die Textur vorhanden wäre, dann wäre es die einzig verbleibende Farbinformation. Nicht eine (einfließende) Farbinformation, sondern die (einzige) Farbinformation. Simpelstes Texturemapping war nicht mein Beispiel.wie schon gesagt ist dann auch dein Statement aus Posting #100:Die Textur überschreibt nicht die Farbinformationen, sie liefert die Farbinformationenfalsch.
2. Die Textur bzw. genauer ausgedrückt das Sampling der Textur liefert einen Farbwert, der nichts anderes überschreibt. Entweder wird mit anderen Werten verrechnet, oder das Ergebnis unverändert genommen, aber kein vorher im Shader berechneter Wert wird überschrieben. Der Shadercompiler optimiert diese anderen Berechnungen in dem Fall nämlich raus, so daß nichts zum überschreiben übrig bleibt.autsch, da hast du dir jetzt ein Eigentor geschossen. Wenn da Berechnungen herausoptimiert werden, ist das gleichbedeutend damit, daß deren Resultat überschrieben wird. Um die konkrete technische Realisierung geht es hier nicht, nur um das Prinzip des Textur-Mappings. Daß bestimmte Berechnungen gar nicht erst durchgeführt werden, weil vorher erkannt wird, daß deren Resultate ohnehin nicht verwendet würden, ist daher ohne Belang.
Und komm jetzt nicht mit Fixed Function Setups, absichtlich schlecht geschriebenen Assembler-Shadern oder mit per Compilerflags deaktivierten Optimierungen für den Shadercompiler daher. nicht doch, derartiges wäre mir nie in den Sinn gekommen.
5. "Monochromes Weiß" klingt doch ein wenig sehr redundant, meinst du nicht auch? Oder hast du schonmal ein Weiß gesehen, das nicht monochrom ist?eine Himmeltextur ist i.d.R. blau, aber eher nicht monochrom blau.
Wie du siehst, kann ich besser Haare spalten als du. nee, seh ich nicht. Allerdings sehe ich, daß du gut Eigentore schießen kannst.
ganz recht: man kann. Tut man es aber nicht, ist das Polygon per default weiß.
NEIN. Es hat die Farbe die der Shader ausgibt. Und die kann von mir aus auch Lillablassblau oder ein Moire-Muster sein indem du vpos%2 rechnest.
Du hast keine Ahnung von was du redest. Du hast irgendeine Vorstellung der Fixed-Function Pipeline die einfach nicht zutrifft. Schreib mal nen Shader oder schau dir welche an und lass uns in Ruhe.
Allerdings hat Neomi dann auch unrecht, wenn er sagt die Textur würde die Farbinformationen liefern. Sie liefert demnach nämlich nur einen Beitrag zu den Farbinformationen, der mit anderen Beiträgen vermischt wird.
Er hat die Farbinformationen geschrieben. Und tatsächlich kommen diese entweder aus Texturen oder Shaderkonstanten.
In den Spezialfällen, in denen die sichtbare Farbe allein durch die Textur bestimmt wird, ist es tatsächlich legitim zu sagen, das Textur-Mapping würde die Default-Farbe (monochromes Weiß) überschreiben.
Nein... Und man wird es auch nie können. Es gibt keine "Polygondefaultfarbe".
Hier mal ein D3D10-Shader, der Texturen sampled:
float4 QuxPixelShader(QuxPixelShaderInput input) : SV_Target
{
float3 texcoord;
float4 color;
float4 light = skylight * dot(skylight_direction,normalize(input.normal));
texcoord = mul(layer_matrices[0],input.terrain_position);
color = TerrainTextures[0].Sample(TerrainSampler,texcoord); // Sample Textur an Position texcoord
texcoord = mul(layer_matrices[1],input.terrain_position);
color = lerp(color,TerrainTextures[1].Sample(TerrainSampler,texcoord),input.layer_alphas1.x);
texcoord = mul(layer_matrices[2],input.terrain_position);
return lerp(color,TerrainTextures[2].Sample(TerrainSampler,texcoord),input.layer_alphas1.y) * light;
}
Wo wird da irgendwas von den Texturen "überschrieben"? Sie werden ausgelesen vom Shader. Mehr nicht.
Und hier zum vergleich mal einer der gar keine Texturen verwendet:
float4 FoobarPixelShader(FoobarPixelShaderInput input) : SV_Target
{
return float4(1.0f,0.5f,0.0f,0.0f);
}
Haarspaltereien bitte hier beenden.
mapel110
2008-07-19, 11:38:21
Wieder ein Jahr mehr und es ist nichts passiert. Man weiß nicht mehr wohin mit der Leistung (außer bei Crysis) und die GPU-Hersteller juckts offenbar nicht.
Vielleicht sind die Absatz-Zahlen von GPUs auch einfach zu groß geworden in den letzten Jahren, dass man nicht mehr auf die Geeks angewiesen ist(die sich mit der Technik und Bildqualität befassen und überhaupt wissen, was AA und AF ist) und nun nur noch die high-fps-junkies bedienen muss. :uponder:
Der_Donnervogel
2008-07-19, 14:04:31
Mit mehr FPS gewinnt man Benchmarks, steht gut in der Presse da und verkauft dann mehr Grafikkarten. Neue Features zur Bildverbesserung durchsetzen ist da viel mühsamer zu argumentieren. Vor allem sollte es dann auch noch etwas sein, das nicht erst von den Spielen unterstützt werden muss. Ansonsten ist die Gefahr groß, dass es wie Truform von ATI sang und klanglos wieder untergeht und die Entwicklungskosten für die Tonne waren. Außerdem fressen solche Features womöglich indirekt Leistung, da man dafür extra Transistoren aufwenden muss, die man auch für andere Sachen brauchen kann. Zusätzlich kommt noch das Problem dazu dass womöglich die Treiberentwicklung aufwändiger wird, falls nicht jedes Spiel problemlos damit funktionieren sollte. Zudem kann man Kunden einmal eingeführte Features nur schwer wieder abgewöhnen, sollte da also vorsichtig sein. Nicht zuletzt kommt noch dazu dass sich solche neuen Features unter Umständen nur sehr zäh durchsetzen und bis es sich allgemein durchgesetzt hat, hat die Konkurrenz es womöglich auch schon oder sogar noch besser umgesetzt. Man erinnere sich nur daran wie schwer sich 3dfx damals getan hat zu kommunizieren dass Antialiasing ein Vorteil sein soll. Aus diesen und vermutlich noch einigen anderen Gründe haben die Hersteller vermutlich wenig Motivation etwas in diesem Bereich zu machen.
Spätestens in 5 Jahren wird sich was tun. Denn was die Hersteller da effekte-mäßig vorgenommen haben kann man nur mit viel und zwar meine ich VIEL Antialiasing auf dem Bildschirm richtig sehen. Filmreife Effekte (im Film) sind ja bekanntlich auch nicht mit lauter Polygonkanten übersäht.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.