Archiv verlassen und diese Seite im Standarddesign anzeigen : 64Bit Farbtiefe
moin,
was einer was fGenaueres darüber, wann wir in Spielen endlich 64Bit Farbtiefe genießen dürfen? Sowas unterstützen GraKas schließlich schon ne ganze Weile, und die ersten "Techscreens" (weis net, ob's dazu auch Techdemos gab...?), die nVidia damals vorgestellt hat, sahen ja recht schmackhat aus. ;)
btw
unterstützt die Radeon 9800Pro eigentlich 64Bit Farbtiefe, oder sind's wie bei der 9700er "nur" 48Bit?
Greetz
Aqualon
2003-11-02, 00:31:18
64Bit Farbtiefe sind erst technisch möglich, wenn sowohl Grafikkarten als auch die Ausgabegeräte 64Bit anzeigen können. Davon ist aber in beiden Fällen nichts in Sicht.
Du darfst nämlich den Unterschied zwischen in 64Bit berechnen und in 64Bit anzeigen nicht vergessen. Dazu kannst ja mal folgenden Artikel lesen: http://www.3dcenter.de/artikel/2001/07-26a.php
Davon mal abgesehen dürften die zusätzlichen Farbabstufungen eh in Richtung nicht sehbar fallen. 24 Bit ergeben 16777216 Farben, 64Bit wären dann schon 18446744073709551616 mögliche Farben (bzw. ~280Mrd, wenn man die Alphakanäle ausklammert -> siehe Artikel)!
Ich weiß zwar nicht wieviele Farben unser Auge auflösen kann, aber ich glaube kaum, dass soviele Farben möglich sind.
Aqua
Crazytype
2003-11-02, 01:08:22
Das Auge kann auf jedenfall nicht mehr als 16,7 Millionen Farben unterscheiden(32 Bit)
Kenne mich mit Programmieren nicht aus, aber durch die erhöhte Anzahl an Farben dürften Rundungen hinter dem Komma nichtmehr so starkt ausfallen, richtig?
Original geschrieben von Gast
moin,
was einer was fGenaueres darüber, wann wir in Spielen endlich 64Bit Farbtiefe genießen dürfen? Sowas unterstützen GraKas schließlich schon ne ganze Weile, und die ersten "Techscreens" (weis net, ob's dazu auch Techdemos gab...?), die nVidia damals vorgestellt hat, sahen ja recht schmackhat aus. ;)
btw
unterstützt die Radeon 9800Pro eigentlich 64Bit Farbtiefe, oder sind's wie bei der 9700er "nur" 48Bit?
Greetz
Welche Farbtiefe meinst du denn genau? Die Präzision bei der Berechnung oder bei der Ausgabe?
R3x0-Karten rechnen intern mit 24bit Floating Point pro Kanal und können die Ergebnisse in den Formaten 32bit Float, 16bit Float, 10bit, 8bit oder 5/6bit Fixed Point pro Kanal speichern.
NV3x-Karten rechnen intern mit 32bit Float, 16bit Float oder 12Bit Fixed Point. Gespeichert werden kann das Ergebnis wie bei den Radeons, mit Ausnahme von 10bit Fixed Point pro Kanal.
Auf den Monitor ausgeben können die Karten aber nur 5/6bit pro Kanal (="16bit Farbtiefe") oder 8bit pro Kanal (="24/32bit Farbtiefe").
Es ist nicht sinnvoll, die Ausgabe mit wesentlich mehr Bits zu machen. Im Prinzip würde eine Aufteilung 11 Bit für Rot, 12 Bit für Grün, 9 Bit für Blau (insgesamt 32 Bit) der menschlichen Wahrnehmungsfähigkeit vollends genügen.
Zwischenergebnisse für Berechnungen müssen hingegen deutlich genauer sein, deswegen auch die Float-Formate.
betasilie
2003-11-02, 02:45:40
Intern reicht eine FP Genauigkeit von 24bit völlig aus. In der Filmbranche werden die Effekte mit FP32 berechnet, was dann wirklich als subjektives Optimum angesehen werden kann.
Der Mensch nimmt übrigens subjektiv schon eine 24bit Farbabstufung in den meisten Fällen als natürlich wahr.
mapel110
2003-11-02, 03:07:13
hm, hab mal was gelesen, dass das menschliche auge ca 300.000 farben unterscheiden kann.
betasilie
2003-11-02, 03:20:53
Original geschrieben von mapel110
hm, hab mal was gelesen, dass das menschliche auge ca 300.000 farben unterscheiden kann.
Deswegen ist 16bit auch zu wenig und 24bit meistens ausreichend. Der Punkt ist aber, dass das menschliche Auge nicht gleichmäßig über das ganze sichtbare Spektrum auflöst und daher gibt es Farbbereiche, die von mehr als 24bit profitieren können.
Ein Freund von mir ist Professor der Ophthalmologie und der hat mir mal vor ein paar Jahren mal die Infos gegeben, obwohl ich mich jetzt nicht 100%tig auf die Zahlen festnageln lassen möchte. :D
Gohma
2003-11-02, 04:14:25
Hi, ich bin's nochmal, hab mich nur mittlerweile gereggt ;p
Original geschrieben von Aqualon
64Bit Farbtiefe sind erst technisch möglich, wenn sowohl Grafikkarten als auch die Ausgabegeräte 64Bit anzeigen können. Davon ist aber in beiden Fällen nichts in Sicht.
Du darfst nämlich den Unterschied zwischen in 64Bit berechnen und in 64Bit anzeigen nicht vergessen. Dazu kannst ja mal folgenden Artikel lesen: http://www.3dcenter.de/artikel/2001/07-26a.php
Aqua
Hmm, also beziehen sich die 64Bit bei heutigen GPUs auch "nur" auf die Farbpräzision... (davon soll ja schon Doom³ ausgiebig Gebrauch machen :jump4: )
Also die "Ausgabegeräte" für 64Bit Farbtiefe hab ich dabei gar nicht bedacht :/
Was gehört denn alles so dazu? ich nehm mal an, GPU und Monitor sind Pflicht? ;D Und sonst, CPU? Athlon 64?!? :kratz2:
Aber dass 32Bit Farbtiefe "eigentlich" nur 24Bit entsprechen, war mir wirklich neu (thx für den Link dazu :-)).
@Xmas
Ich wusste gar nicht, dass das so stark variieren kann... ich dachte bislang, der R3x0 hätte nur 128:8 = 16Bit FP? :|
Wozu um alles in der Welt braucht man denn 5/6Bit PF?!
Also meint ihr, dass 32Bit (bzw. eben 24) Farbtiefe völlig ausreichen? Denn die 64Bit FarbtiefeScreens von nVidia (war zu einem dynamischer Rost auf einem Pick-up und frischgepflückte Früchte *g*... hab ich im Inet leider nicht auftreiben können, waren aber mal in der Gamestar (sorry für Schleichwerbung^^)) sahen dank der erhöten Farbtiefe sehr organisch aus... viel "praller", als alles andere, was ich bislang in 32Bit zu sehen bekam, meine ich.
Und afaik kann das menschl. Auge auch etwas mehr als 16,7 Mio. Farben erkennen. Auch wenn man also mit der Steigerung von 32Bit Farbtiefe zu 64Bit keinen ähnlichen "Quantensprung" wie von 16 zu 32 erwarten kann, dürfte es sich dennoch bei der Bildqualität bezahlt machen... na ja, wenn das so ist, dann hat das ja keine Eile. :D
Original geschrieben von Gohma
@Xmas
Ich wusste gar nicht, dass das so stark variieren kann... ich dachte bislang, der R3x0 hätte nur 128:8 = 16Bit FP? :|
Wozu um alles in der Welt braucht man denn 5/6Bit PF?!
5 bzw. 6 Bit pro Kanal. 5 Bit für Rot, 6 für Grün, 5 für Blau, insgesamt 16 Bit. Das was allgemein als "16 Bit Farbtiefe" bezeichnet wird, oder auch RGB565. Heute überflussig, aber vor ein paar Jahren noch Standard.
Wie kommst du denn bitte auf 128:8? Der R3x0 rechnet mit 24 Bit FP pro Kanal (in Teilen der Pipeline auch mit 32 Bit, aber das ist ein anderes Thema), also insgesamt 96 Bit (für Rot, Grün, Blau, Alpha)
Also meint ihr, dass 32Bit (bzw. eben 24) Farbtiefe völlig ausreichen? Denn die 64Bit FarbtiefeScreens von nVidia (war zu einem dynamischer Rost auf einem Pick-up und frischgepflückte Früchte *g*... hab ich im Inet leider nicht auftreiben können, waren aber mal in der Gamestar (sorry für Schleichwerbung^^)) sahen dank der erhöten Farbtiefe sehr organisch aus... viel "praller", als alles andere, was ich bislang in 32Bit zu sehen bekam, meine ich.
Es gibt hier zwei völlig verschiedene Dinge. Zum einen die Rechenpräzision und Speicherung von Zwischenergebnissen, und zum anderen die Speicherung/Ausgabe des berechneten Bildes. Am Ende hat man Bilddaten, also eine Farbe pro Pixel. Da ein Monitor eine maximale Helligkeit hat, und es schwärzer als Schwarz nicht gibt, hat man auch nur einen gewissen Ausgabebereich zur Verfügung, und um diesen in ausreichender Genauigkeit darzustellen reichen 8 Bit pro Kanal, also 24 Bit Farbtiefe bzw. RGB888 häufig aus. Um das menschliche Auge wirklich vollends auszureizen, wäre RGB_11_12_9 - wie oben beschrieben - ausreichend. Darüber sind keine Unterschiede mehr wahrnehmbar!
Grün braucht eine höhere Auflösung als Blau, weil das menschliche Auge Helligkeitsunterschiede viel feiner wahrnimmt als Farbtöne, und Grün hat einen etwa 6 mal so hohen Anteil an der Helligkeit als Blau.
Ganz anders sieht es dagegen bei der Berechnungspräzision aus. Denn hier wird eben nicht nur mit Farben gerechnet, sondern auch mit Positionen, Winkeln, Abständen und Texturkoordinaten. Dafür braucht man die Floating Point Formate, nur für Farben wären 16bit FP schon völlig übertrieben!
Von 64, 96 oder 128 Bit Farbtiefe zu sprechen ist deswegen auch eigentlich falsch, denn diese Wertebereiche werden von Farben gar nicht ausgenutzt.
Die Bilder/Demos die du als "64 Bit Farbtiefe" bezeichnest, haben in Wirklichkeit nur 32 Bit Farbtiefe (bzw. 24, RGB888 eben). Aber sie demonstrieren die Verwendung von PS2.0, und damit Floating Point Präzision bei der Berechnung (in diesem Fall FP16 und FP32).
Die NVidia-Demo mit dem Pickup gibts übrigens hier:
http://www.nvidia.com/object/demo_timemachine.html
Tigerchen
2003-11-02, 09:25:15
Original geschrieben von Gohma
Hi, ich bin's nochmal, hab mich nur mittlerweile gereggt ;p
Und afaik kann das menschl. Auge auch etwas mehr als 16,7 Mio. Farben erkennen. Auch wenn man also mit der Steigerung von 32Bit Farbtiefe zu 64Bit keinen ähnlichen "Quantensprung" wie von 16 zu 32 erwarten kann, dürfte es sich dennoch bei der Bildqualität bezahlt machen... na ja, wenn das so ist, dann hat das ja keine Eile. :D
Ich behaupte mal daß die meisten Menschen schon mit 16,7 Millionen Farben total überfordert sind.Für die paar Leute die sehen wirklich gelernt haben lohnt ein 64 Bit Modus einfach nicht.Beim sehen ist es halt wie beim schmecken.Man muß es lernen sonst schmeckt ein trockener Wein einfach nur sauer.
CrazyIvan
2003-11-02, 11:04:55
AFAIK kann der Mensch im dunken bis zu 25 Millionen Farben unterscheiden. Ich meine damitnatürlich nen abgedunkelten Raum, in dem ein Monitor o. ä. steht.
Wenn ich mich recht entsinne gabs doch von SGI vor so 10 Jahren sogar mal Workstations, die 25 Mio Fraben anzeigen konnten - damit meine ich sowohl die Monitore als auch die GraKas.
Hat sich aber scheinbar net gelohnt, wenn die jetzt sogar schon nVidias verbauen ;D
MarioK
2003-11-02, 11:09:15
Original geschrieben von Xmas
Auf den Monitor ausgeben können die Karten aber nur 5/6bit pro Kanal (="16bit Farbtiefe") oder 8bit pro Kanal (="24/32bit Farbtiefe").
Es ist nicht sinnvoll, die Ausgabe mit wesentlich mehr Bits zu machen. Im Prinzip würde eine Aufteilung 11 Bit für Rot, 12 Bit für Grün, 9 Bit für Blau (insgesamt 32 Bit) der menschlichen Wahrnehmungsfähigkeit vollends genügen.
wann die CRT's(da analog) locker 10 und mehr bits pro farbe schaffen warum macht man nicht RAMDAC's mit 11/12/9 (ist beim parhelia 10/10/10 ??)
Original geschrieben von Crazytype
Das Auge kann auf jedenfall nicht mehr als 16,7 Millionen Farben unterscheiden(32 Bit)*Wieder seufz*
Bitte keine vorschnellen Behauptungen. Der Mensch kann konkret nur einige hundert Farben trennen, aber Millionen von Helligkeitsstufen unterscheiden. Die 16,7 Millionen "Farben und Helligkeiten" sind ja gleichmäßig im RGB-Raum verteilt, obwohl der Mensch unterschiedliche Empfindlichkeiten hat. (Bei Tageslicht sind wir z.B. für Gelb am empfindlichesten, bei Nacht für Grün.) Zum Beispiel kann man, 16,7 Millionen Farben hin oder her, lediglich 255 Schattierungen von Grün darstellen. Das menschliche Auge kann jedoch mehr Stufen unterscheiden.
Original geschrieben von betareverse
Intern reicht eine FP Genauigkeit von 24bit völlig aus. Diese pauschale Aussage sollte ergänzt werden: Für Farbberechnungen sind 24 Bit FP eigentlich gut genug. Für Texture Ops, aber auch in schwierigen Bumpmapping-Fällen, liefert 32 Bit FP das genauere Ergebnis. Da man dann ohnehin FP32-Logik braucht, könnte man ruhig durchweg alles mit FP32 berechnen.
Original geschrieben von aths
Bitte keine vorschnellen Behauptungen. Der Mensch kann konkret nur einige hundert Farben trennen, aber Millionen von Helligkeitsstufen unterscheiden. Die 16,7 Millionen "Farben und Helligkeiten" sind ja gleichmäßig im RGB-Raum verteilt, obwohl der Mensch unterschiedliche Empfindlichkeiten hat. (Bei Tageslicht sind wir z.B. für Gelb am empfindlichesten, bei Nacht für Grün.) Zum Beispiel kann man, 16,7 Millionen Farben hin oder her, lediglich 255 Schattierungen von Grün darstellen. Das menschliche Auge kann jedoch mehr Stufen unterscheiden.
Genau. Wobei je nach Studie auch insgesamt mehr als 16,7 Millionen Farb+Helligkeitsabstufungen wahrgenommen werden könnten. Davon abgesehen ist die dargestellte Farbtiefe in diesem Zusammenhang aber doch von eher niedriger Priorität bei der "Problemlösung". Bis sich jemand bei Computerspielen an nur 255 verschiedenen Grünhelligkeiten auf dem Monitor anstösst, vergeht wohl noch eine Weile =).
Gohma
2003-11-02, 21:59:46
Original geschrieben von Xmas
Wie kommst du denn bitte auf 128:8? Der R3x0 rechnet mit 24 Bit FP pro Kanal (in Teilen der Pipeline auch mit 32 Bit, aber das ist ein anderes Thema), also insgesamt 96 Bit (für Rot, Grün, Blau, Alpha)
Mhh, hab ich mal bei PCTweaks aufgeschnappt... :D
Aber was du mit 96Bit meinst ist mir ein Rätsel?
R3x0-Karten rechnen intern mit 24bit Floating Point pro Kanal und können die Ergebnisse in den Formaten 32bit Float, 16bit Float, 10bit, 8bit oder 5/6bit Fixed Point pro Kanal speichern.
NV3x-Karten rechnen intern mit 32bit Float, 16bit Float oder 12Bit Fixed Point. Gespeichert werden kann das Ergebnis wie bei den Radeons, mit Ausnahme von 10bit Fixed Point pro Kanal.
Genau das war doch der Grund dafür, weshalb der NV3x so schlechte Shader und damit eine miese Performance in DX9-Spielen hatte, oder?
Denn bei 16Bit FP wird's auf DX8-Niveau "zurückgestuft", und bei 32Bit FP isser zu lahm...
ATi hat's hingegen beim R3x0 mit internen 24Bit genau richtig gemacht. Oder bring ich wieder was durcheinander?! :(
Eine Frage noch (hat zwar nicht direkt was mit dem Thema zu tun, aber wo wir eh schonmal alle hier versammelt sind... ;)):
Wie hoch können Texturen maximal aufgelöst sein, und wovon hängt das eigentlich ab (DX-Version, Fill Rate?)? DX6-Karten wie GeForce256 können afaik maximal 512*512px Texturen darstellen, aktuelle Engines wie Source, Cry oder Warfare gehen trotz DX9-GPUs noch gerade "nur" bis 2048*2048px... werden überhaupt sagen wir mal 8192*8192px hoch aufgelöste Texturen denn technisch überhaupt jemals möglich sein?
Original geschrieben von Gohma
Mhh, hab ich mal bei PCTweaks aufgeschnappt... :D
Aber was du mit 96Bit meinst ist mir ein Rätsel?
Schrieb ich doch schon: 24 Bit pro Kanal (mit 4 Kanälen, Rot, Grün, Blau, Alpha) sind insgesamt 96 Bit.
Genau das war doch der Grund dafür, weshalb der NV3x so schlechte Shader und damit eine miese Performance in DX9-Spielen hatte, oder?
Denn bei 16Bit FP wird's auf DX8-Niveau "zurückgestuft", und bei 32Bit FP isser zu lahm...
ATi hat's hingegen beim R3x0 mit internen 24Bit genau richtig gemacht. Oder bring ich wieder was durcheinander?! :(
16 Bit FP ist über DX8-Niveau, aber in PS2.0 Shadern nicht immer möglich. Die FP-Leistung der NV3x-Chips ist schwächer als die der R3x0 Chips.
Eine Frage noch (hat zwar nicht direkt was mit dem Thema zu tun, aber wo wir eh schonmal alle hier versammelt sind... ;)):
Wie hoch können Texturen maximal aufgelöst sein, und wovon hängt das eigentlich ab (DX-Version, Fill Rate?)? DX6-Karten wie GeForce256 können afaik maximal 512*512px Texturen darstellen, aktuelle Engines wie Source, Cry oder Warfare gehen trotz DX9-GPUs noch gerade "nur" bis 2048*2048px... werden überhaupt sagen wir mal 8192*8192px hoch aufgelöste Texturen denn technisch überhaupt jemals möglich sein?
Die maximale Texturgröße hängt nur von der Hardware ab, von der Speicherorganisation und der Breite der entsprechenden Register der TMUs.
256²: Voodoo1-3
1024²: Kyro1/2, Riva128, TNT1/2, alle Rage
2048²: alle Radeon, GeForce1/2/4MX, alle Matrox-Chips, Voodoo4/5
4096²: GeForce3/4Ti/FX
Ich zitiere mal aus dem oben genannten Artikel:
http://www.3dcenter.de/artikel/2001/07-26a.php
http://www.3dcenter.de/artikel/2001/07-26b.php
John Carmack wünscht sich nun aber bis zu 20 Texturen pro Pixel! Und wozu braucht er die? Da sollte man mal besser den Meister selber fragen :-). Ich kann mir vorstellen, eine Grundfarben-Textur, Material-Textur, Detail-Textur 1, Detail-Textur 2, Lightmap, Shadowmap, Enviromentmap und Bump-Map zu verwenden. Das wären trotz dezenter Übertreibung nur schlappe 8 Stück. Zumal Bumpmapping in Zukunft hoffentlich durch das deutlich schönere Displacement Mapping ersetzt werden wird.
Ich vermute daher, dass Carmack andere Dinge vor hat: Beim Einsatz von 8 farbigen Lichtquellen kann man kein Hardware-T&L mehr verwenden, denn keine für den Privatanwender erschwingliche Hardware bekommt das für "real world"-Umgebungen in Echtzeit gerendert. Die heutigen T&L Engines können zwar Lichtberechnungen in Hardware durchführen, stoßen dabei allerdings schon bei sehr wenigen Lichtern an ihre Limits, so daß diese Technik bisher nur in einzelnen Fällen benutzt wurde. Vielleicht erwägt Carmack, einfach 8 - oder sogar noch mehr - Lightmaps einzusetzen. Das ist sehr CPU-aufwändig, aber bei der momentanen CPU-Entwicklung vermutlich spätestens Mitte 2002 mit jedem ALDI-PC machbar. Vielleicht möchte er dies auch mit Shadowmaps kombinieren. Und vermutlich hat er genauso noch vor, mehr Transparenz zu verwenden, was ebenfalls die Zahl der Blend-Operationen erhöht.
Kurz: So viele Textur-Schichten für einen Pixel machen durchaus Sinn. Eine Grafikkarte mit 32-Bit-Rendering und -Framebuffer würde hier unansehliche Ergebnisse liefern. In der Tat sehen heutige Grafiken nicht gerade lebendig aus. Ob nun eine Steinwand, eine Tapete oder glänzendes Metall: Die Grafik ist zwar heute zwar schon viel schöner aus als vor 2 Jahren, kommt aber noch längst nicht an Fotorealismus heran.
Bei 64 Bit (16 Bit pro Kanal) sinkt der durchschnittliche Rundungsfehler auf gut 0,00076 % ab. Das ist (logischerweise) 256 mal weniger als beim bisherigem 32-Bit-Rendering. Man kann also sehr viel mehr Blend-Operationen und Transparenz-Berechnungen vornehmen, ehe sich der Rundungsfehler so weit aufschaukelt, dass er sichtbar werden würde. Wegen dem fehlenden grossen Qualitätsschub von 16 zu 32 Bit fehlt im Moment allerdings die Akzeptanz, dass 64 Bit über kurz oder lang unausweichlich sind. Das wird sich aber ändern, wenn die Zahl der Texturen pro Dreieck erheblich ansteigt. Bei 400% Vergrösserung kann man bei jedem Spiel die Unterschiede zwischen 16 und 32 Bit erkennen.
Da wurden schon die Frage beantwortet.
Ailuros
2003-11-03, 13:34:45
Also ich wuerde mal spekulieren dass sogar heutige high end Karten es ziemlich schwer haetten mit einem Spiel/Applikation, dass ausschliesslich 2048*2048 Texturen hat.
4096 waere wohl eine genauso tolle slideshow auf NV3x, wie 2048 auf TNT.
Hat Microsoft endlich mal vor einen neuen Kompressions-standard fuer Texturen zu akzeptieren? INTEL forscht(-e) mit LFM herum:
http://www.intel.com/research/mrl/research/lfm/index.htm
Ist das ueberhaupt der Rede wert?
Original geschrieben von Ailuros
Hat Microsoft endlich mal vor einen neuen Kompressions-standard fuer Texturen zu akzeptieren? INTEL forscht(-e) mit LFM herum:
http://www.intel.com/research/mrl/research/lfm/index.htm
Ist das ueberhaupt der Rede wert?
Wie kommst du von lfm auf Texture-Kompression?
Außerdem lassen sich doch gerade lfm mit DXTC und / oder VQ extrem gut komprimieren; so um den Faktor 3000 - 5000 wenn man VQ und DXTC zusammen benutzt. Siehe hier : ftp://download.intel.com/research/mrl/research/lfm/papers_0232_lowres.pdf Seite 10.
Spuckt dir da vielleicht der S5 im Kopf rum... ;)
Original geschrieben von ow
Korrektur:
TNT1/2: 2048²
Seltsam, Delphi3D (http://www.delphi3d.net/hardware/viewreport.php?report=34) listet bis Deto 6.50 noch 1024² für TNT1/2, bei neueren Treibern für beide 2048².
Ailuros
2003-11-03, 16:07:36
Auf die Kombination von DXTC und VQ wollte ich ja eigentlich hinaus, nur hab ich den falschen Link gepostet. Soweit ich weiss ist Microsoft nur an einer Methode interessiert der das Kompressions-ratio um sehr viel mehr erhoeht als bisher benutzte Methoden; da waere eine Kombination von DXTC und VQ in einem Algorithmus wohl ein guter Kandidat oder nicht?
Was hat S5 mit VQ zu tun?
Original geschrieben von Ailuros
Was hat S5 mit VQ zu tun?
Nichts, ich wollte eher auf lfm hinaus. Und hab dann auch noch an den Neon 250 / Dreamcast wegen des VQ gedacht.
Gibt es außer diesem lfm-pdf auch noch andere Info's die zeigen, das eine Kombination aus DXTC und VQ eine gute und schnelle Kompressionsmethode für Texturen ist ( Schnell wegen der Dekompression )?
Ich fand diese Methode hier immer ganz gut, da der Kompressionsgrad zwischen 8 (gute Qualität) und 12(mäßige Qualität) liegt (S3TC erreicht ja bei 24bit 6fach) : http://www.acm.org/sigmm/mm2000/ep/levkovich/
Ailuros
2003-11-03, 18:11:47
Ich frage ja selber ueber die Kombination von S3TC und VQ, da ich keine Ahnung hab ob es der Rede wert ist. Hoffentlich kann es jemand beantworten.
Ist VQ groesstes Problem dass es nicht leicht ist in HW zu implementieren und deshalb sahen oder sehen wir darauf basierende Methoden sehr selten?
Ich fand diese Methode hier immer ganz gut, da der Kompressionsgrad zwischen 8 (gute Qualität) und 12(mäßige Qualität) liegt (S3TC erreicht ja bei 24bit 6fach) : http://www.acm.org/sigmm/mm2000/ep/levkovich/
Nicht schlecht; nur will Microsoft eine Methode - wie gesagt - die erhebend hoehere ratios liefern kann als 8:1 oder 12:1. Deshalb wurde auch PVR-TC abgelehnt so wie ich das bei B3D verstanden habe.
Von allem abgesehen waere ein S3TC/VQ Kombo vom Kompressionsratio allein gesehen ein sehr potentieller Kandidat.
Demi:
:help:
Demirug
2003-11-03, 20:32:03
Ailuros, im Prinzip darf jeder IHV schon jetzt seine eigenen Kompresionsformate in DX einbringen. Diese werden dann allerdings nicht von Runtime unterstützt. Ohne diese Unterstützung ist die Begeisterung der Entwickler sowas auch zu benutzen natürlich nicht so hoch.
Was nun MS und das Kompressions von PowerVR angeht so sollte man PowerVR auch mal fragen was sie von MS wollten? Aber selbst wenn MS sich interesiert zeigt bringt es ja nichts wenn die anderen IHVs nicht mitziehen wollen. Jedes neue Verfahren kostet Transitoren und da man die alten ja weiterhin beibehalten muss sollte sich das ganze schon wirklich lohnen.
Mit LFM habe ich mich bisher wirklich nur am Rande beschäftigt da es derzeit ja die Grundvoraussetzung hat das der Gegenstand wirklich physikalisch vorhanden ist und sich noch eingermassen runherum Fotographieren lässt. Für die Spieleentwicklung daher eher nur begrenzt brauchbar. Das ganze eignet sich IMHO zum Beispiel eher für die digitale archivierung von Skulpturen.
Von den angegeben Kompresionraten sollte man sich allerdings nicht zu sehr täuschen lassen. Bei der Erzeugung der Rohdaten aus den Fotos erhält man relative viel redundante Material.
zeckensack
2003-11-03, 20:41:15
S3TC ist eine Form von Vektorquantisierung. Ich wüßte nicht, was man da noch groß kombinieren soll :|
Original geschrieben von ow
Die HW kann definitv 2048². Der 3DWinbench2000 prüft das. Irgendwo las ich mal, TNT1 hätte nur 1024²? 2048² wäre bei TNT imo ohnehin wenig sinnig (bei 32 Bit = 16 MB Speicherplatz.) Oder haben sie halt bei TNT1 erst mal nur 1024² freigeschaltet?
Original geschrieben von aths
Irgendwo las ich mal, TNT1 hätte nur 1024²? 2048² wäre bei TNT imo ohnehin wenig sinnig (bei 32 Bit = 16 MB Speicherplatz.) Oder haben sie halt bei TNT1 erst mal nur 1024² freigeschaltet?
So weit ich weiss, werden doch zukünftige Features zu Testzwecken eingebaut (wenn es nicht zu viele Transoistoren braucht) und nicht aktiviert bzw. deaktiviert. Das ist doch jetzt z.B. mit Yamhill so. Wenn nützt einem die Theorie, wenn es in der Praxis nicht funktioniert.
Ailuros
2003-11-03, 22:26:24
Jedes neue Verfahren kostet Transitoren und da man die alten ja weiterhin beibehalten muss sollte sich das ganze schon wirklich lohnen.
Ist mir auch klar und ich kann Microsoft's Standpunkt zum Thema auch voll verstehen.
Meine Frage konzentrierte sich eher in die Richtung ob wir bald (was heisst bald? errr...) eine Texturen-Kompressions Methode sehen werden mit hoeherem ratio, die auch von MS + IHVs akzeptiert und implementiert wird.
Fuer den Laien ist es irgendwie schwer sich vorzustellen dass framebuffers weiterhin mit jeder Generation verdoppeln werden. Nun gut naechste Generation kommt schon mit 256-512MB, aber fuer wie lange kann es so weitergehen, oder ist es eher unwahrscheinlich dass wir je zu einem Flaschenhals in der Abteilung kommen?
Demirug
2003-11-03, 23:00:36
Original geschrieben von Ailuros
Meine Frage konzentrierte sich eher in die Richtung ob wir bald (was heisst bald? errr...) eine Texturen-Kompressions Methode sehen werden mit hoeherem ratio, die auch von MS + IHVs akzeptiert und implementiert wird.
Da fragst du den falschen.
Fuer den Laien ist es irgendwie schwer sich vorzustellen dass framebuffers weiterhin mit jeder Generation verdoppeln werden. Nun gut naechste Generation kommt schon mit 256-512MB, aber fuer wie lange kann es so weitergehen, oder ist es eher unwahrscheinlich dass wir je zu einem Flaschenhals in der Abteilung kommen?
Texturen wie man sie im Moment kennt werden sowieso immer unwichtiger werden. Langfristig wird man dazu übergehen die Oberflächen mit Materialshader zu erzeugen. Die benötigen zwar auch noch Daten aus Texturen. Dabei handelt es sich dann aber mehr um Hilfstabellen für mathematischen Funktionen.
Ailuros
2003-11-03, 23:03:31
Texturen wie man sie im Moment kennt werden sowieso immer unwichtiger werden. Langfristig wird man dazu übergehen die Oberflächen mit Materialshader zu erzeugen. Die benötigen zwar auch noch Daten aus Texturen. Dabei handelt es sich dann aber mehr um Hilfstabellen für mathematischen Funktionen.
Ahhhh das hoert sich schon um einiges besser an. Danke :)
hier noch ein paar Links zum Thema Texture-Compression :
Wavelet-Compression : http://www.metavr.com/technology/texturecomp.html bis zu 75:1
nochmals Wavelet : http://www.viewpoint.com/developerzone/docs/whitepapers/texture_compression_vet_wp.pdf bis zu 100:1
Ich bezweifle aber sehr stark, das sich Wavelets zum Komprimieren von Texturen eignen, trotz der hier aufgeführten Beispiele, da bei diesen Beispielen ziemlich große Texturen/Bilder komprimiert werden, und damit Wavelets optimal funktionieren sollten.
Allgemeine Infos zu dem Thema :
http://www.fit.com.ru/Surveys/TextureCompression/
[VQ; TREC; S3TC; ... ]
Wavelets haben den Vorteil, dass sie sich eigentlich nur lokal auswirklen, während Fourier-Koeffizienten ja das Signal in der gesamten Ausdehnung beeinflussen.
Original geschrieben von Gast
hier noch ein paar Links zum Thema Texture-Compression :
Wavelet-Compression : http://www.metavr.com/technology/texturecomp.html bis zu 75:1
Nur dass 75:1 völlig unbrauchbar aussieht und 25:1 auch schon ziemlicher Mist ist. Andere Texturen können wohl besser komprimiert werden, aber 15:1 scheint mir schon eine optimistische Obergrenze für brauchbare Qualität zu sein.
Original geschrieben von aths
Wavelets haben den Vorteil, dass sie sich eigentlich nur lokal auswirklen, während Fourier-Koeffizienten ja das Signal in der gesamten Ausdehnung beeinflussen.
Wie kommst du denn darauf? Ob Wavelet oder Fourier, beides kann man lokal begrenzen oder über die gesamte Textur verwenden.
Original geschrieben von Xmas
Wie kommst du denn darauf? Ob Wavelet oder Fourier, beides kann man lokal begrenzen oder über die gesamte Textur verwenden. Fourier nur dann, wenn man (was bei TC allerdings ohnehin Standard ist) mit Tiles arbeitet. Für Wavelet lassen sich ja Funktionen nehmen, die weit vom Ursprung kaum noch Auswirkungen haben.
KM, dieser Artikel ist nicht so ganz aktuell. Die Sache ist doch deutlich komplizierter, als damals beim Schreiben angenommen.
LunaticLord
2003-11-08, 10:00:21
Original geschrieben von Crazytype
Das Auge kann auf jedenfall nicht mehr als 16,7 Millionen Farben unterscheiden(32 Bit)
Kenne mich mit Programmieren nicht aus, aber durch die erhöhte Anzahl an Farben dürften Rundungen hinter dem Komma nichtmehr so starkt ausfallen, richtig?
Das Auge kann 128Millionen Farben unterscheiden.
danke
Original geschrieben von LunaticLord
Das Auge kann 128Millionen Farben unterscheiden.
danke Farben nur einige hundert. Unterschiedliche Helligkeitsstufen in der Farbe allerdings einige Millionen.
Hallo, Monitore sind Analoggeräte, denen sind die Bits/Kanäle/Formate völlig Wurscht. Sie können jede beliebige Anzahl von Farben darstellen, die sich durch Rot/Gelb/Grün mischen lassen, sei es auch 100milliarden Farben. Natürlich spreche ich nur von den zukunftssicheren CRT Monitors :D denn TFT's müssen leider draussen warten :)
Da die TFT's digitaler Natur sind, müsste die maximale Farbenanzahl durch irgendein Faktor limitiert sein, weil jede Zahl endlich ist :) zumindest so verstehe ich das.
Original geschrieben von ow
es sind ja analoge Bauteile. <Klugscheiß> Quantentheoretisch heißt analog natürlich nicht, tatsächlich unendlich viele Zwischenstufen zu haben. Ein noch so analoges Stromsignal ist immer in ganzzahlige eV "digitalisiert" :D ;( ;( X-D
Höhnangst
2003-11-08, 14:04:43
Weil wir gerade beim Thema Farben und deren Darstellung sind:
Wie kommt es eigentlich, dass die Farben bei TVs, PC-Monitoren usw. immer aus Rot, Grün und Blau (RGB) gemischt werden?
Weil die natürlichen Grundfarben sind doch Rot, Gelb und Blau (RGB).
Aquaschaf
2003-11-08, 14:27:49
Bei Licht nicht. Magenta,Cyan,Gelb gilt nur für Farbpigmente, also quasi für Farben zum Malen. Das verhält sich ja sowieso anders, mischt man Farbpigmente nimmt die Helligkeit der resultierenden Farbe ab, Magenta+Cyan+Gelb=Schwarz während Rot+Grün+Blau=Weiß bei Licht gilt.
http://www.farbenlehre.com/
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.