Archiv verlassen und diese Seite im Standarddesign anzeigen : erstes Spiel mit 3DC-Support?
Monger
2004-07-17, 11:49:57
Bei der gesamten Diskussion über SM 3.0 kommt mir 3dc doch etwas zu kurz...
Bump Mapping ist ja nun wirklich nichts ungewöhnliches mehr in Spielen, und da würde sich doch 3dc mit Sicherheit lohnen, oder?
Ausserdem glaubte ich Demirug so verstanden zu haben, dass die Implementierung davon eigentlich kein großer Akt sein dürfte.
Gerade weil dieses Feature doch schnell Verbreitung finden sollte, würde mich mal interessieren was das für Auswirkungen auf die Performance wirklich hat.
Demirug
2004-07-17, 12:21:01
Die Performancen auswirkungen sind eigentlich recht einfach:
Bandbreite/speicherplatzlimitierung -> 3dc kann helfen
Pixel-Shaderlimitierung -> 3dc macht es noch langsamer.
Alle anderen Fällen -> 3dc hat keine Auswirkung auf die Performance. Man könnte aber höher aufgelöste Normalmaps 4free einsetzten.
Einbauen lässt es sich relative einfach wenn man es von Anfang an einplant. Nachträglich muss man eben jeden Shader nochmal anfassen der eine Normalmap benutzt. Das grössere Problem ist das man die Texturen prüfen und wandeln muss.
Das zweite Problem ist das sich 3dc nicht mit dem Offsetmapping verträgt. Dabei wird die Länge des Vektors in der 4 Komponete der Texture gespeichert. Bei 3dc wird diese aber verworfen.
Man könnte ja u. U. X und Y in eine 3Dc-Map packen, und Z und W in eine zweite 3Dc-Map. Die Komponenten müsste man dann im Pixelshader wieder zusammenfrickeln.
Aqualon
2004-07-17, 20:39:14
Zu den ersten Spielen mit 3DC-Unterstützung dürften wohl HL2 und Serious Sam 2 gehören.
Von ATI gibt es ein PDF zu 3DC: http://www.ati.com/products/radeonx800/3DcWhitePaper.pdf
Aqua
Original geschrieben von Demirug
Pixel-Shaderlimitierung -> 3dc macht es noch langsamer.
Wenn man eh normalisiert, ist es gleich schnell.
Original geschrieben von Aqualon
Zu den ersten Spielen mit 3DC-Unterstützung dürften wohl HL2 und Serious Sam 2 gehören.
Von ATI gibt es ein PDF zu 3DC: http://www.ati.com/products/radeonx800/3DcWhitePaper.pdf
Aqua Das PDF erzählt natürlich nicht die ganze Wahrheit. IIRC, wird verschwiegen
• dass sich auch mit DXT5 ganz passable Ergebnisse erzielen lassen, wenn man denn renormalisiert (das ist zusätzliche Pixelshaderarbeit, aber 3Dc verlangt für die Z-Rekonstruktion ja auch zusätzliche Arbeit)
• dass es speziell für Normalen im Tangent Space (3Dc ist darauf auch angewiesen) ein 2-Kanal-Texturformat gibt, so dass 3Dc in Wahrheit 2:1 komprimiert (und nicht 4:1.)
Original geschrieben von Xmas
Wenn man eh normalisiert, ist es gleich schnell. Auf 3Dc-fähiger HW, ja.
Beim NV40 gibts den NRM_PP ja "for free". FP16-Bumpmapping ist zwar viel teurer als FX8- oder 3Dc-basiertes, müsste aber auch viel schöner sein. Da NV40 FP16-Texturen auch noch nativ filtern kann, ist das wohl der erste Chip, der "echtes" FP16-Bumpmapping in Echtzeit ermöglicht ("echt" = Nutzung einer FP16-Textur als Normal Map.) Mindestens acht mal genauer als herkömmliche Verfahren.
Tigerchen
2004-07-18, 06:48:15
Original geschrieben von aths
Auf 3Dc-fähiger HW, ja.
Beim NV40 gibts den NRM_PP ja "for free". FP16-Bumpmapping ist zwar viel teurer als FX8- oder 3Dc-basiertes, müsste aber auch viel schöner sein. Da NV40 FP16-Texturen auch noch nativ filtern kann, ist das wohl der erste Chip, der "echtes" FP16-Bumpmapping in Echtzeit ermöglicht ("echt" = Nutzung einer FP16-Textur als Normal Map.) Mindestens acht mal genauer als herkömmliche Verfahren.
Hört sich gut an. Wann und wo wird das eingesetzt?
Original geschrieben von aths
Auf 3Dc-fähiger HW, ja.
Beim NV40 gibts den NRM_PP ja "for free". FP16-Bumpmapping ist zwar viel teurer als FX8- oder 3Dc-basiertes, müsste aber auch viel schöner sein. Da NV40 FP16-Texturen auch noch nativ filtern kann, ist das wohl der erste Chip, der "echtes" FP16-Bumpmapping in Echtzeit ermöglicht ("echt" = Nutzung einer FP16-Textur als Normal Map.) Mindestens acht mal genauer als herkömmliche Verfahren.
NRM_pp ist natürlich ein Argument.
Die Notwendigkeit für FP16 bei Bumpmaps sehe ich zur Zeit allerdings nicht. Hast du bei 8-bit/Kanal Normal Maps schon mal Banding gesehen (wenn normalisiert wurde)?
Original geschrieben von Tigerchen
Hört sich gut an. Wann und wo wird das eingesetzt?
Wenn passende Hardware genügend weit verbreitet ist, in zukünftigen Spielen, wo bisherige Genauigkeit nicht mehr ausreicht.
Original geschrieben von Xmas
NRM_pp ist natürlich ein Argument.
Die Notwendigkeit für FP16 bei Bumpmaps sehe ich zur Zeit allerdings nicht. Hast du bei 8-bit/Kanal Normal Maps schon mal Banding gesehen (wenn normalisiert wurde)? Nein, Bumpmapping-Banding sah ich bisher noch nicht. Das schiebe ich auf den "Content", Bumpmapping wird bislang nur so eingesetzt, dass FX8-Normalmap-Genauigkeit reicht. Der Wirkung wegen ist der Bumpmapping-Effekt ja oft vergleichsweise hochfrequent. Wenn man eine "sanfte" Normalmap über eine große Fläche interpoliert bzw. "sanftes" Bumpmapping appliziert, könnte ich mir vorstellen, dass 256 Stufen zu wenig sind. (Wenn ich das richtig sehe, macht eine Stufe nicht zwangsweise ein Bit Helligkeitsunterschied, sondern mal mehr, mal weniger.)
Wenn diese Normalmap-Genauigkeit noch auf längere Sicht ok ist, wird NRM_PP vermutlich trotzdem vorteilhaft sein: Ein oder zwei Bytes zusätzlich zu lesen und dafür ein kostenloses NRM zu haben ist vermutlich billiger, als diese Bytes zu sparen und Z zu rekonstruieren. Ich bin auch nicht überzeugt davon, dass das 2-Kanal-Verfahren genau so genau ist, wie eine 3-Kanal-Map zu renormalisieren. (Bei 2 Kanälen muss der Vektor normalisiert sein. Bei 3 Kanälen ist das nicht erforderlich, wenn sowieso normalisiert wird. Somit ließen sich mehr unterschiedliche Winkel darstellen, wenn man nicht auf den Betrag achten muss.)
Tigerchen
2004-07-18, 14:12:57
Original geschrieben von aths
Wenn passende Hardware genügend weit verbreitet ist, in zukünftigen Spielen, wo bisherige Genauigkeit nicht mehr ausreicht.
Hmm. 3DC-fähige Hardware ist ja momentan auch kaum verfügbar. Warum also wird 3DC schon jetzt aufgegriffen und dein Vorschlag nicht?
VooDoo7mx
2004-07-18, 15:28:01
Man könnte doch theoretisch einen NV40 Refresh, ziemlich schnell 3dc beibrigen?
Oder liege ich da falsch?
betasilie
2004-07-18, 15:39:37
Original geschrieben von aths
Man könnte ja u. U. X und Y in eine 3Dc-Map packen, und Z und W in eine zweite 3Dc-Map. Die Komponenten müsste man dann im Pixelshader wieder zusammenfrickeln.
Ist das nur so ein Gedanke oder tatsächlich machbar?
betasilie
2004-07-18, 15:59:01
Original geschrieben von aths
Nein, Bumpmapping-Banding sah ich bisher noch nicht. Das schiebe ich auf den "Content", Bumpmapping wird bislang nur so eingesetzt, dass FX8-Normalmap-Genauigkeit reicht. Der Wirkung wegen ist der Bumpmapping-Effekt ja oft vergleichsweise hochfrequent. Wenn man eine "sanfte" Normalmap über eine große Fläche interpoliert bzw. "sanftes" Bumpmapping appliziert, könnte ich mir vorstellen, dass 256 Stufen zu wenig sind. (Wenn ich das richtig sehe, macht eine Stufe nicht zwangsweise ein Bit Helligkeitsunterschied, sondern mal mehr, mal weniger.)
Gibte es dafür konkrete Anwendungsbsps.?
Original geschrieben von betareverse
Ist das nur so ein Gedanke oder tatsächlich machbar?
Sicher ist das machbar. Ist nur die Frage ob es auch was bringt.
betasilie
2004-07-18, 16:19:20
Original geschrieben von Xmas
Sicher ist das machbar. Ist nur die Frage ob es auch was bringt.
Nun, 50% Platzersparniss, oder nicht? Oder 50% mehr Details, ganz wie man es sehen will.
.... bei wieviel mehr Rechenaufwand?
betasilie
2004-07-18, 16:49:03
Original geschrieben von q@e
.... bei wieviel mehr Rechenaufwand?
Das ist die Frage.
Sinnvoll anwendbar oder nicht?
zeckensack
2004-07-18, 17:24:58
Original geschrieben von aths
<...>
Wenn diese Normalmap-Genauigkeit noch auf längere Sicht ok ist, wird NRM_PP vermutlich trotzdem vorteilhaft sein: Ein oder zwei Bytes zusätzlich zu lesen und dafür ein kostenloses NRM zu haben
<...>Dieser "Tausch" ist nicht zwingend notwendig.
NRM_PP kannst du nämlich -- wie jede andere Shader-Operation auch -- genausogut mit FX8-Texturen benutzen.
Original geschrieben von Tigerchen
[COLOR="#000088"]
Hmm. 3DC-fähige Hardware ist ja momentan auch kaum verfügbar. Warum also wird 3DC schon jetzt aufgegriffen und dein Vorschlag nicht?Weil ATIs Entwicklersupport einigen Entwicklern 3Dc schmackhaft gemacht hat, während sich Nvidia bislang zurückhielt, Entwickler von neuen Bumpmappingmöglichkeiten beim NV40 zu überzeugen (die pushen lieber erst mal ihr SM 3.0, weil das atm rein NV40-exklusiv ist.) Wenn auch 3Dc "aufgegriffen" wird wird, wage ich zu behaupten, das es "dem User" wenig bringt: ATI bietet das Feature im Moment nur in der Oberklasse an, wo doch gerade solche Karten genügend RAM haben, um auf 3Dc nicht angewiesen zu sein. Mangelt es wirklich am RAM, könnte man Normal Maps auch mit DXT5 komprimieren (was nicht ganz so gut ist, aber immerhin.) Ich sehe in 3Dc eher ein Bestreben, minimale HW-Erweiterungen als bahnbrechendes neues Feature zu verkaufen. Im Gegensatz zu TruForm halte ich in 3Dc zwar durchaus ein Feature was auch neue Generationen haben werden. Wie zukunftsträchtig es wirklich ist, werden wir sehen: 3Dc schränkt die damit noch möglich Bumpmappingverfahren auch ein.
Original geschrieben von betareverse
Gibte es dafür konkrete Anwendungsbsps.? Mir ist keins bekannt. Zu Zeiten des 16-Bit-Rendering gabs auch noch keine Beispiele, dass 32-Bit-Rendering mal an seine Grenzen stoßen könnte. Heute ist schon abzusehen, dass 96-Bit-Rendering nicht der Weisheit letzter Schluss ist.
betasilie
2004-07-18, 22:01:37
Original geschrieben von aths
Mir ist keins bekannt. Zu Zeiten des 16-Bit-Rendering gabs auch noch keine Beispiele, dass 32-Bit-Rendering mal an seine Grenzen stoßen könnte. Heute ist schon abzusehen, dass 96-Bit-Rendering nicht der Weisheit letzter Schluss ist.
ACK
Das sollte auch kein Gegenargument für dein Bsp. sein. Ich wollte halt nur wissen, ob man Du da schon Anwendungsbeispiele im Kopf hattest. ;)
Original geschrieben von betareverse
Das ist die Frage.
Sinnvoll anwendbar oder nicht?
Statt einem texld aus einer 4-Kanal-Textur (wobei u.U. ja auch DXTx ausreichen kann) hätte man 2 texld aus jeweils einer 2-Kanal-Textur (3Dc-komprimiert), sowie evtl. noch ein mov.
Das lesen der Textur braucht also gegenüber unkomprimiertem RGBA doppelt so lange, aber nur die halbe Bandbreite. Nehmen wir bei Normal Maps trilinear NoAF an, sind das 2 Takte mehr. Bei Bandbreitenlimitierung kann man sich das erlauben.
betasilie
2004-07-19, 01:16:06
Original geschrieben von Xmas
Statt einem texld aus einer 4-Kanal-Textur (wobei u.U. ja auch DXTx ausreichen kann) hätte man 2 texld aus jeweils einer 2-Kanal-Textur (3Dc-komprimiert), sowie evtl. noch ein mov.
Das lesen der Textur braucht also gegenüber unkomprimiertem RGBA doppelt so lange, aber nur die halbe Bandbreite. Nehmen wir bei Normal Maps trilinear NoAF an, sind das 2 Takte mehr. Bei Bandbreitenlimitierung kann man sich das erlauben.
Ok, dann müsste das bei den aktuellen Karten tendenziell Vorteile bringen, je nach Engine und Lastverteilung.
Original geschrieben von betareverse
Ok, dann müsste das bei den aktuellen Karten tendenziell Vorteile bringen, je nach Engine und Lastverteilung. Nein: Die Bandbreite wird ja nicht geschont, nur in Takten wo die Karte ansonsten auf die Daten wartet, wird noch etwas gerechnet.
Original geschrieben von betareverse
ACK
Das sollte auch kein Gegenargument für dein Bsp. sein. Ich wollte halt nur wissen, ob man Du da schon Anwendungsbeispiele im Kopf hattest. ;) Mögliche Einsatzgebiete hätte ich schon im Kopf: Das angesprochene "sanfte" Bumpmapping, aber auch hochwertiges Offset-Mapping.
Ganz abseits vom Bumpmapping wird FP16 (bzw. etwas besseres als FX8) stark an Bedeutung gewinnen, und zwar bei der Beleuchtung. Mit FP16 ist schon sehr schönes Overbrightlighting möglich, außerdem ist das Format in jedem Fall präziser als FX8. Erst recht löst man bei schwacher Beleuchtung (ggü. FX8) sehr fein auf.
Bumpmapping ansich steht hoffentlich eine große Zukunft bevor: Zwar nach wie vor eine "Fake-Technologie" (die Oberflächen bleiben ja glatt) aber mit Offset-Mapping und Self-Shadowing ist die Illusion in den meisten Fällen gut genug. Die Pixelshader-Power ist für solche Verfahren nun auch da.
ATIs 3Dc beschleunigt – nichts. Es werden ja zusätzliche Rechnungen nötig, dafür wird etwas Speicherbandbreite gespart. Im Endeffekt spart man für Normal Maps 50% des Speichers, wenn auch zweifach auf Kosten der Genauigkeit: Einmal, da komprimiert wird, andererseits da Z weggelassen wird, so dass X und Y bereits normalisiert vorliegen müssen. Nvidia bietet (ganz abseits vom SM 3.0) neue Features, welche sich beim Bumpmapping für "Zukunfts-Verfahren" positiv auswirken können. Bedenkt man, wie lange es dauerte ehe man überhaupt mal Bumpmapping sah (welches auch heute noch in nur wenigen Titeln zu sehen ist) kann man sich denken, dass es neuartige Verfahren nicht sofort geben wird. ATIs 3Dc, welches sich für hergebrachte Methoden einsetzen lässt, hat es da leichter.
Ailuros
2004-07-19, 10:24:02
Falls CroTeam wirklich nicht mit nennenswerten Verspaetungen konfrotiert wird, dann koennte SS2 tatsaechlich eines der erste Spiele sein mit 3dc-support. Das sich jetzt aber 3dc mit parallax mapping nicht vertraegt wusste ich nicht; komisch ist dass die SS2 engine beides unterstuetzen soll.
So wie ich CroTeam kenne, wird man wohl jedes X-beliebige Feature hoechstwahrscheinlich wieder ein- und ausschalten koennen, so dass man eigentlich sehr gut mit jedem einzelnen Feature experimentieren kann.
Ailuros
2004-07-19, 10:27:03
Original geschrieben von VooDoo7mx
Man könnte doch theoretisch einen NV40 Refresh, ziemlich schnell 3dc beibrigen?
Oder liege ich da falsch?
Ja und dazu ohne besondere Muehe AFAIK. Vorraussetzung dass man eine solche Notwendigkeit auch erkennen wird natuerlich.
Demirug
2004-07-19, 10:38:17
Original geschrieben von Ailuros
Falls CroTeam wirklich nicht mit nennenswerten Verspaetungen konfrotiert wird, dann koennte SS2 tatsaechlich eines der erste Spiele sein mit 3dc-support. Das sich jetzt aber 3dc mit parallax mapping nicht vertraegt wusste ich nicht; komisch ist dass die SS2 engine beides unterstuetzen soll.
Ist doch kein Problem beides zu unterstützen. Man darf eben nur in Verbindung Shader mit parallax mapping welche den höhenwert aus der Normalmap holen (Alphawert) kein 3Dc benutzten. Da man diese Shadervariante sowieso für nicht 3Dc fähige Karten braucht ist das also kein Problem.
Jesus
2004-07-19, 19:33:02
dazu am besten mal ins Benchmark forum kucken und tb´s DoubleCross Benchmark ohne 3dc laufen lassen ( mit DXTC1,3,5 );)
macht etwa 300% performance aus ;) lt. den leuten die da vorher nachher tests mit gemacht haben.
seahawk
2004-07-19, 19:59:15
Aber das Demo ist auf 3dc optimiert. Also höchst wahrscheinlich Bandbreiten limitiert.
Nicht Bandbreiten- sondern AGP-Geschwindigkeit. :-)
Ailuros
2004-07-20, 11:26:31
Original geschrieben von q@e
Nicht Bandbreiten- sondern AGP-Geschwindigkeit. :-)
Der weiteren Haarspalterei zuliebe: AGP-Bandbreite eigentlich... :D
Geschwindigkeit = trotz Latenz umgesetzte theoretische Bandbreite. ;)
Ich meinte nicht die AGP-Bezeichnungen AGPx4, 8X usw.
Jesus
2004-07-20, 13:58:53
Original geschrieben von seahawk
Aber das Demo ist auf 3dc optimiert. Also höchst wahrscheinlich Bandbreiten limitiert.
logisch, aber das ist ja auch der Sinn dabei, nicht über den AGP-Bus schauffeln zu müssen ;)
Original geschrieben von Jesus
logisch, aber das ist ja auch der Sinn dabei, nicht über den AGP-Bus schauffeln zu müssen ;)
Wieso nicht gleich mehr RAM auf die Graka draufpacken?
Ist das nicht sinnvoller?
StefanV
2004-07-20, 14:27:06
Original geschrieben von ow
Wieso nicht gleich mehr RAM auf die Graka draufpacken?
Ist das nicht sinnvoller?
Und wer soll das ganze Bezahlen??
Und gibts schon entsprechende Bausteine??
16 Chips auf die Platine zu löten ist ja anscheinend nicht soo schön...
Original geschrieben von Jesus
logisch, aber das ist ja auch der Sinn dabei, nicht über den AGP-Bus schauffeln zu müssen ;) In aktuellen Spielen oder Spielen in absehbarer Zukunft wirkt sich die 2:1-Kompression von 3Dc nicht so stark aus, dass es einen Unterschied in der Größenordnung von 300% macht.
betasilie
2004-07-20, 14:52:54
Original geschrieben von ow
Wieso nicht gleich mehr RAM auf die Graka draufpacken?
Ist das nicht sinnvoller?
Stell dir mal vor NV und ATI hätten überhaupt keine bandbreitenschohnende Techniken was für Speicher wir dann bräuchten.
Generell ist doch besser mit Tricks Bandbreite zu sparen, gerade wo der Speicher heutzutage garnicht mehr mit den GPUs mitkommt.
Original geschrieben von betareverse
Stell dir mal vor NV und ATI hätten überhaupt keine bandbreitenschohnende Techniken was für Speicher wir dann bräuchten.
Generell ist doch besser mit Tricks Bandbreite zu sparen, gerade wo der Speicher heutzutage garnicht mehr mit den GPUs mitkommt.
Es geht hier doch garnicht um Bandbreite sondern Platzbedarf.
StefanV
2004-07-20, 16:02:02
Original geschrieben von ow
Es geht hier doch garnicht um Bandbreite sondern Platzbedarf.
Kommt aufs gleiche raus...
Zumal mehr Speicher auch gleich teurer ist...
Einfach mehr Speicher draufzupappen ist natürlich nicht unbedingt die beste Lösung. Andererseits sollte man imo bedenken, dass 3Dc ohnehin nicht für jede Bumpmapping-Methode eingesetzt werden kann. Für "echtes" FP16-Bumpmapping (mit FP16-Normal Maps) braucht's ohnehin sehr viel Platz, da wäre man mit 128 MB nicht mehr gut bedient. Bei "herkömmlichem" BM sind auch Szenen denkbar, in denen man mit 128 MB auslagern müsste, was man der Performance wegen vermeiden sollte. Dann müsste Textur- und/oder Normalmap-Auflösung gesenkt werden.
Dass Karten mit 256 MB RAM in absehbarer Zeit ernsthaft Probleme bekommen, halte ich für sehr unwahrscheinlich. Diese Karten haben wahrscheinlich auch genug Reserve, um unkomprimierte Normal Maps verwenden zu können und trotzdem alle Texturen onboard zu haben.
Sofern Bandbreite eine Rolle spielt, dass die Pixelshader leer laufen, bringt 3Dc immerhin einen Performance-Vorteil.
betasilie
2004-07-20, 17:38:15
Original geschrieben von ow
Es geht hier doch garnicht um Bandbreite sondern Platzbedarf.
Ja aber weniger Datenmenge bedeutet auch weniger Bandbreite. ;)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.