Archiv verlassen und diese Seite im Standarddesign anzeigen : Ruby Wrapper ist da
Original geschrieben von Mr. Lolman
Auch unter OpenGL? Sicher. (Warum sollte das bei OpenGL auch anders sein?)
Original geschrieben von ShadowXX
Naja...da sthet indirekt schon, das SS2 3dc Normalmaps benutzt....
Der erste Screen zeigt ein Modell von SS2 einmal mit "normalen" Normalmaps und einmal mit 3dc Normalmaps....
Daraus kann man durchaus schliessen, das bei SS2 3dc Normalmaps benutzt werden...Nein.
Ich verstehe die 'collage' eher so:
Auf dem ersten Shot wird die Scene ohne Normalmaps dargestellt, auf dem zweiten dann mit.
Das ist ja gerade dieses 'nette' Verwirrspielchen.
Man braucht kein 3Dc, um Normalmaps (egal in welcher Qualität) nutzen zu können.
Original geschrieben von ShadowXX
AFAIK hat ATI neben HL2 auch SS2 genannt, als Beispiele für Games, welche 3dc einsetzen werden...Mag sein...
Wäre ja nicht das erstel mal, dass ein IHV (ich nenne hier bewußt keinen speziellen) ein Entwickler-Studio dafür 'bezahlt', eine bestimmte Technologie einzusetzen. On sie allerdings nötig sein wird, mag mal dahin gestellt sein...
Original geschrieben von ShadowXX
Bevor jetzt allerdings ein aufschrei durch die Gegend hallt....auch ich bin mir nicht sicher ob 3dc der Bringer vor dem Herrn ist...das mit dem Momentan verbrachten VidMem ist übrigens das besten "Gegenbeispiel"..
Egal....IMHO ist das SM3.0 wesentlich brauchbarer als das 3dc..3dc ist Nett und könnte sich "vielleicht" durchsetzen...
SM3.0 dagegen wird sich definitiv durchsetzen, vielleicht noch nicht über den nv40, aber alle nachfolgenden Chips (r500 von ATI,XGI etc.) beherschen dies und es ist dazu ein jetzt schon vorhandener Standard ("dank" M$).
Die Frage ist auch weniger, ob dem nv40 SM3.0 auch wirklich noch was zu Lebzeiten bringt (von Developerseite aus), sondern ob nV die Möglichkeuiten von SM3.0 innerhalb Ihrer Treiber so einsetzen kann, das es PS2.0 Games etwas "boost" bringt und so die Taktnachteile gegenüber der x800XT ausgleichen kann...Das ist tatsächlich die Frage aller Fragen.
Der CEO meinte ja, dass der Compiler der Version 1.0 noch nicht die finale Antort auf diese Frage ist (wohl aber schon zu einem Teil !), insofern man (auch ohne DX9c) von Performance-Zuwächsen ausgehen kann... wie hoch diese allerdings ausfallen werden, ist ein Punkt der wohl noch einige Zeit offen bleiben wird.
Original geschrieben von ShadowXX
Je länger ich darüber nachdenke, desto wiedersinniger wird es eine x800xt zu kaufen...zumindest für den Speed-Vorteil der meist Marginal ausfällt...
(Und jetzt kommt bitte nicht mit den 1600x1200 Benchamrks, die für die Mehrzahl der Anwender wohl irrrelevanzt ist) Auf jeden Fall zieht eine X800XT jetzt gleich (oder ist unter bestimmten Voraussetzungen sogar etwas schneller). Und wieviel die Performance beider IHV's bei den jetzt diskutierten Produkten in einem Jahr noch 'wert' sein wird, ist heute wohl von niemanden zu beantworten...
Na ja, schaun' wir mal... es bleibt auf jeden Fall spannend !
:D
Razor
Original geschrieben von InsaneDruid
Hm "times".. kann das nicht auch bedeuten das 2.x Shader 252MAL eingesetzt werden, ohne auf die eigentlich Anzahl der Shader zu deuten? Nein.
Dies ist eine eigene (automatisierte) Auswertung und fußt auf der Ausgabe des 3DA (shader.out).
Razor
Original geschrieben von Aquaschaf
Zum einen arbeitet es sich angenehmer bei einer höher aufgelösten Textur - zeichnet man mit nem Stylus geht das bei einer Bildgröße von 1024² viel angenehmer als bei 512² z.B.. Benutzt man prozeduale Effekte oder Filter wie Noise hat man auch bei höheren Auflösungen bessere Ergebnisse.Du weißt aber schon, dass 3Dc 'nur' ein Kompressions-Algo ist, der auf Normalmaps zielt ?
Und Du willst die Auflösung aller Texturen gleich vervierfachen ?
:???:
Hmmm...
Original geschrieben von Aquaschaf
Abgesehen davon, Texture-Artists sind auch faule Menschen ;) Man weiß nie ob man nicht eine Textur oder Teile daraus später noch recyclen will, auch dafür ist es praktisch höhere Auflösungen zu benutzen.
Last but not least: Es ist viel weniger Arbeit von vorneherein eine größere Textur zu machen als man glaubt zu brauchen als wenn man später eine zu niedrig aufgelöste Textur hat und die vergrößern muss. Mag ja alles sein, die Arbeit haben dann die Entwickler, die diese Technik dann gleich von Anfang an in ihre Engine einbauen müssen. Und ob eine Texturauflösungs-'Verbesserung' von 512x512 auf 1024x512 oder 512x1024 (jetzt nur auf die Normalmaps bezogen !) wirklich für die 'Artists' sinnvoller (oder gar bequemer) ist, mag ebenfalls mal dahin gestellt sein.
Mehr Quali ist auf jeden Fall immer besser, aber der Aufwand muss dem Ertrag gerecht werden und da sieht's bei der ATI-Lösung eben leider nicht so dolle aus...
Razor
Lokadamus
2004-05-10, 12:37:40
Original geschrieben von r@w
Nein.
Ich verstehe die 'collage' eher so:
Auf dem ersten Shot wird die Scene ohne Normalmaps dargestellt, auf dem zweiten dann mit.
Das ist ja gerade dieses 'nette' Verwirrspielchen.
Man braucht kein 3Dc, um Normalmaps (egal in welcher Qualität) nutzen zu können.
Mag sein...mmm...
Ich kenne nur ein Dateiformat, wo der Detailgrad egal ist und die Bandbreite konstant bleibt => Bitmap, .bmp ... bei jedem anderen Format gibt es aufgrund von Kompressionen unterschiedliche Grössen. Man braucht nur ein schwarz/ weiß- Bild im BMP- Format nehmen und dieses in JPG und PNG speichern, PNG erlaubt einen höheren Detailgrad bei kleinerer Grösse als JPG. Baut man aber nur einen roten Kreis mit ca. 1 cm Durchmesser dort rein, ist PNG ein ganzes Stück grösser als JPG, was immernoch relativ gleich gross bleibt ... wenn 3DC so arbeitet, wie PNG komprimiert, nur bei einer kleineren Bandbreite, hat man viel gewonnen => höherer Detailgrad bei guter Qualität und geringerer Bandbreite => man hat mehr Luft bei der Bandbreite und kann grössere/ detailreichere Grafiken verwenden ... wenn ich gerade Blödsinn geschrieben habe, korrigiert mich ...
Original geschrieben von Lokadamus
Du bist mein Held... Danke, danke...
:loveya:
Razor
P.S.: dieser Post ist sarkastisch und ohne jeglichen Inhalt *eg*
Lokadamus
2004-05-10, 12:40:25
mmm...
Keine Angst, nicht ohne Grund ist unter dem Begriff Held ein Link ;D ... dieser Beitrag entspricht dem Niveau von r@h ...
Original geschrieben von Mr. Lolman
Nicht die Normalmaps müssen neu generiert werden, sondern die Shader neu geschrieben... (@Demi: Die PS2.0 müsste man doch auch wrappen können?) Damit willst die 'richtigen' Texturen auch gleich mit vergrößern ?
Na dann zeig mir mal, wie Du das dann in den Video-Speicher bekommen willst...
:kratz:
Razor
Original geschrieben von Mr. Lolman
Es müsste doch mittels einer externen Kompressionsroutine, und ATis treiberinternem Shadercompiler möglich sein, völlig unabhängig von der Spieleunterstützung, bei PS2.0 Shader, einen Geschwindigkeitsvorteil für 3dc kompatible HW rauszuschlagen... Genau das ist das Problem...
Nein, es geht (wohl) nicht !
Original geschrieben von Gfraast
Ob das der Shadercompiler könnte, weiss ich nicht. Aber ähnliche wie bei Metabytes WickedGL (für 3dfx KArten), muss es dich möglich sein, dass eine kleine externe (Kompressions)Routine, beim Spielstart alle momentan benötigten Normalmaps zu 3dc komprimiert, während der Shadercompiler die PS2.0 umschreibt..Meinst Du Treiber-seitig ?
Schließlich kommen dort die Shader ja im Assembler-Format an und müssten erst einmal disassembliert werden. Dann muss der Compiler auch darauf 'achten', dass etwaig vorhandene Optimierungen durch die Eingriffe nicht gleich wieder dahin sind oder den Shader anderweitig 'blockieren'.
Also da müsste ATI aber einiges an Arbeit (und auch an Unsicherheit hinsichtlich der Kompatibilität) hinein stecken, um dies zumindest ansatzweise zum Laufen zu bringen.
Original geschrieben von Mr. Lolman
Natürlich müsste man dann noch auf Feinheiten achten, wie, dass Normalmaps für PS1.1-PS1.4 Shader unbehandelt bleiben. .. "Weiß" denn der Treiber, welche Textur (mit Normalmap), die in den Video-Speicher gleaden wird, mit welchem Pixel-Shader-Typ 'bedacht' wird.
Also ich stelle mir diesen Treiber-Automatismus nicht nur als sehr schwer, sondern schon fast als unmöglich vor...
Razor
@Moderatoren
Kann hier nicht jemand mal persönliche Beleidungen eines gewissen Posters hier entfernen ?
Danke !
Razor
Original geschrieben von ow
:???: http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1797125#post1797125
Original geschrieben von Lokadamus
mmm...
Keine Angst, nicht ohne Grund ist unter dem Begriff Held ein Link ;D ... dieser Beitrag entspricht dem Niveau von r@h ... http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1795105#post1795105
Original geschrieben von Lokadamus
@r@h
Du bist mein Held (http://www.lokadamus.de.vu/3dc/held.PNG), niemand anderes schafft es, auf den selben Satz 2x zu quoten :bonk: ... und blind bist du auch, <snap> http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1793483#post1793483
Original geschrieben von Lokadamus
@r@h
Das mit den sachlichen Posts halte ich für ein Widerspruch in sich ... dieses Topic wäre um die Hälfte kleiner, wenn du entweder "sinnvoll" antworten würdest (technische Erklärungen liefern, anstatt Behauptungen aufzustellen und nicht dauernd alles einzeln quoten. Du hast hier wieder 3 Antworten nacheinander gepackt, anstatt sie in einem Rutsch zu beantworten) oder einfach gar nix sagen würdest ... Na ja... vielleicht ist 'Beleidigung' etwas zu hoch gegriffen... aber zumindest ist es Spam (mit ein bissel Beleidigung ;-).
Razor
Original geschrieben von r@w
Mehr Quali ist auf jeden Fall immer besser, aber der Aufwand muss dem Ertrag gerecht werden und da sieht's bei der ATI-Lösung eben leider nicht so dolle aus... 3Dc zu haben ist besser, als es nicht zu haben.
Original geschrieben von r@w
Nein.
Ich verstehe die 'collage' eher so:
Auf dem ersten Shot wird die Scene ohne Normalmaps dargestellt, auf dem zweiten dann mit.Na dann erkläre doch mal, wie im Bild links Bumpmapping realisiert wurde ...
Original geschrieben von r@w
Damit willst die 'richtigen' Texturen auch gleich mit vergrößern ?
Na dann zeig mir mal, wie Du das dann in den Video-Speicher bekommen willst...
:kratz: Von Texturen hat Lolman in dem Zusammenhang doch gar nichts geschrieben.
Zudem erhöht eine feinere Normal Map auch dann das Detail, wenn die Base Map unverändert bleibt.
Lokadamus
2004-05-10, 13:41:20
mmm...
@r@h
Ich hab nix dagegen, wenn gewisse Sachen von mir wieder entfernt werden (mach ich auch selber, wenn es sein muss), nur setzt das vorraus, das du aufhörst, immer wieder alles einzelne zu quoten. Das du es auch schaffst, alle Sachen in einem Beitrag reinzuschreiben, hast du eben doch gezeigt und das ist es, was ich dir die ganze Zeit ankreidet habe. Zuerst hab ich versucht, dich höfflich darauf aufmerksam zu machen, danach eben "direkt", was nicht unbedingt höfflich geht, aber immerhin hast du mir dann wenigstens zugehört.
Achja, "guter" Spam zeichnet sich dadurch aus, das es als Randbemerkung in einem Beitrag steht und nicht ein einzelner Beitrag ist und du bist in einigen Beiträgen auch nicht gerade so höflich mit den Leuten umgegangen ;) ...
Dieser Beitrag ist kompletter Spam und kann gekickt werden ...
Original geschrieben von aths
3Dc zu haben ist besser, als es nicht zu haben.Aber nicht um jeden Preis !
Und darum geht es hier...
Original geschrieben von aths
3Dc zu haben ist besser, als es nicht zu haben.
Na dann erkläre doch mal, wie im Bild links Bumpmapping realisiert wurde ... OK, dann wurde eben links eine (zu) niedrig aufgelöste Normalmap benutzt und rechts eine höher aufgelöste...
Nur wo steht geschrieben, dass in SS2 der Video-Speicher eines NV40 z.Bsp. nicht auch für die höher aufgelösten Normalmaps (unkomprimiert) ausreichen wird (so, wie es die Ruby-Demo suggeriert)? Und wo steht, dass diese Scene nur mit 3Dc realisiert werden kann?
Ist halt eine typische Marketing-Unterlage ohne irgendwelche Hintergrund-Informationen und damit ohne Gehalt. Sie stellt lediglich den Vorteil von höher aufgelösten Normalmaps heraus und suggeriert die Notwendigkeit von 3Dc... mehr nicht.
Original geschrieben von aths
Von Texturen hat Lolman in dem Zusammenhang doch gar nichts geschrieben.Lolman hat von einem Treiber-Automatismus gesprochen, der eingreifen soll, ohne dass die Spiele-Engine dies 'weiß'. Sollte dies also einen Vorteil bringen, müssten die originalen Texturen den originalen Normalmaps entsprechen (die ja wohl i.d.R. gleich groß sein dürften). Somit müssen die originalen Texturen dann auch gleich größer sein, was dann den benötigten Video-Speicher massiv erhöht und allen anderen Karten (ohne 3Dc) Probleme bereiten könnte, würde dies nicht berücksichtigt werden.
Sonst bliebe nur der geringe (weil nur Normalmaps betreffend) Bandbreitenvorteil zur Ladezeit einer Scene und dass kann dem Aufwand ja wohl kaum gerecht werden.
Von dem zu befürchteten Kompatibilitätsproblem ganz zu schweigen...
Original geschrieben von aths
Zudem erhöht eine feinere Normal Map auch dann das Detail, wenn die Base Map unverändert bleibt.Klar...
Und ?
:???:
Razor
P.S.: Die Fragezeichen extra für Dich direkt ans Ende der Sätze gerückt... ;)
@Lokadamus
Warum sollte ich mir von Dir (oder irgend jemand anderen) vorschreiben lassen, wie ich was quote ?
:???:
EOD.
Razor
StefanV
2004-05-10, 13:49:31
Original geschrieben von r@w
Aber nicht um jeden Preis !
Und darum geht es hier...
OK, dann wurde eben links eine (zu) niedrig aufgelöste Normalmap benutzt und rechts eine höher aufgelöste...
1. den Link, den aths hier gepostet hätte, erspar ich mir, da klar sein sollte, welcher gemeint ist :eyes:
2. öhm, dann erkläre uns mal, wieviel 3dc kostet, wir sind alle gespannt darauf...
3. ja und durch 3dc kann die Performance bei beiden etwa gleich bleiben...
Oder wäre das Internet mit Bitmap Dateien denkbar?!
TheGood
2004-05-10, 13:52:12
Original geschrieben von r@w
@Lokadamus
Warum sollte ich mir von Dir (oder irgend jemand anderen) vorschreiben lassen, wie ich was quote ?
:???:
EOD.
Razor
damit auch andere Leute deine Beiträge lesen. Ich habs schon lange aufgegeben, weil mich deine Art zu qouten tierisch nervt :) ABer das ist meine Meinung.
Ioch wollts nur mal gesagt haben, weil du ja in deinem Posting drum gebeten hast.
Original geschrieben von Mr. Lolman
Es müsste doch mittels einer externen Kompressionsroutine, und ATis treiberinternem Shadercompiler möglich sein, völlig unabhängig von der Spieleunterstützung, bei PS2.0 Shader, einen Geschwindigkeitsvorteil für 3dc kompatible HW rauszuschlagen...
...indem du den Pixelshadern zusätzliche Arbeit aufbürdest?
Die einzige Situation, die m.E. davon profitieren könnte, wäre die, wenn ständig über den AGP ausgelagert würde - und das sollte bei einem Game eigentlich nicht vorkommen, wenn man eine Graka der entsprechenden Generation benutzt (i.e. die eine zeitgemäße Ausstattung mit VRAM hat), außer es ist reichlich unüberlegt designed bzw. eine Techdemo, die die Vorteile von 3dc aufzeigen soll.
;Q
Original geschrieben von Stefan Payne
3. ja und durch 3dc kann die Performance bei beiden etwa gleich bleiben...
Jein.
In Normalfall kann man vielleicht eher davon ausgehen, daß der Speicherbedarf gleichbleiben könnte. Es sei denn, ATi hat eine dedizierte Hardware eingebaut, um die fehlenden Z-Werte zu rekonstruieren. Ansonsten dürfte die "3dc-Füllrate" ggü. der non-3dc-Füllrate mehr oder minder stark abfallen.
Aber ich ahne schon, worauf es hinauslaufen wird. Ein paar wenige prominente Stellen auf den Hauptcharakteren werden per 3dc höher aufgelöst normal-mapped und auf diese darf dann in Screenies gezoomed werden und eine unübertroffene Bildquallität attestiert werden. ;D
;Q
Original geschrieben von r@w
Aber nicht um jeden Preis !
Und darum geht es hier...Imo geht es darum, dass einige Leute 3Dc zu sehr in den Himmel reden, und andere dieses Feature ungerechtfertigt runter machen.
Original geschrieben von r@w
Nur wo steht geschrieben, dass in SS2 der Video-Speicher eines NV40 z.Bsp. nicht auch für die höher aufgelösten Normalmaps (unkomprimiert) ausreichen wird (so, wie es die Ruby-Demo suggeriert)? Und wo steht, dass diese Scene nur mit 3Dc realisiert werden kann?Warum sollte das da stehen? Mit 3Dc kann man mit gleichem Speicherplatz feinere Normalmaps haben als ohne. Speicherplatz auf der Graka ist per se eine begrenzte Ressource.
Original geschrieben von r@w
Sollte dies also einen Vorteil bringen, müssten die originalen Texturen den originalen Normalmaps entsprechen (die ja wohl i.d.R. gleich groß sein dürften). Somit müssen die originalen Texturen dann auch gleich größer sein, was dann den benötigten Video-Speicher massiv erhöht und allen anderen Karten (ohne 3Dc) Probleme bereiten könnte, würde dies nicht berücksichtigt werden.Der Sinn von Bumpmapping scheint dir bisher entgangen zu sein? Macht aber auch nichts – einfach die nächste "PC Intern" kaufen :)
Original geschrieben von r@w
Von dem zu befürchteten Kompatibilitätsproblem ganz zu schweigen...
Klar...
Und ?
:???:Nein. Mir ist ehrlich gesagt weder klar, was die letzten Zeilen sollen, noch, wo du das Kompatibilitätsproblem siehst. Sollte man z. B. auf SM 3.0 verzichten, weil das derzeit inkompatibel mit Radeon-Hardware ist?
Original geschrieben von r@w
P.S.: Die Fragezeichen extra für Dich direkt ans Ende der Sätze gerückt... ;) Würdest du auch die Ausrufezeichen ohne Leerzeichen direkt ans Wort setzen, wären deine Postings noch besser zu lesen :)
Original geschrieben von r@w
@Lokadamus
Warum sollte ich mir von Dir (oder irgend jemand anderen) vorschreiben lassen, wie ich was quote ?
:???: Warum kannst du nicht mal Anregungen anderer aufgreifen :???:
Original geschrieben von q@w
...indem du den Pixelshadern zusätzliche Arbeit aufbürdest?Wenn die arithmetischen Einheiten unterausgelastet sind, macht das nichts. Gerade auf Mittelklasse-HW mit vergleichweise wenig RAM (128 MB) und begrenzter Bandbreite (Interface mit 128 Bit) könnte 3Dc zu einem Speedup führen.
ATI wird angesichts des R420 kaum die Transistoren für 3Dc aufgewendet haben, wenn das Feature wirklich nichts brächte.
Original geschrieben von q@w
Aber ich ahne schon, worauf es hinauslaufen wird. Ein paar wenige prominente Stellen auf den Hauptcharakteren werden per 3dc höher aufgelöst normal-mapped und auf diese darf dann in Screenies gezoomed werden und eine unübertroffene Bildquallität attestiert werden. ;DDie 3Dc-Werbung halte ich für ehrlicher, als die PS 3.0-Werbung mit Far Cry.
S3TC ist seit Jahren breit akzeptiert. Auch Normal Maps (verlustbehaftet) zu komprimieren ist eine Sache, die schon lange hätte kommen sollen.
Gas3t
2004-05-10, 14:43:14
Original geschrieben von r@w
@Lokadamus
Warum sollte ich mir von Dir (oder irgend jemand anderen) vorschreiben lassen, wie ich was quote ?
:???:
EOD.
Razor
Meines Erachtens ist 3Dc ein nettes Feature und sollte nicht per se als unnütz abgetan werden. Es stellt eine Kompressionstechnik dar, die Vor- und Nachteile bietet. Dies ist aber bei jeder Technik der Fall. Außerdem werden Techniken auch weiterentwickelt. Vielleicht ist bei einer Akzeptanz (auch seitens Nvidia) die Chance gegeben, dass wir in Zukunft noch schönere Spiele sehen werden, als wenn die Entwicklung von 3Dc nicht stattgefunden hätte.
PS:
Ein kleiner Tipp:
Du solltest vielleicht ein wenig an deinem Diskussionsstil arbeiten und die anderen Threadteilnehmer mit etwas mehr Respekt behandeln. Dies würde die Diskussion um einiges erleichtern und den Erkenntnisgewinn gleichzeitig erhöhen.
Original geschrieben von ow
Zaehlt da Marketing auch dazu? Nur indirekt. Im Gegensatz zu R100 und R200 und R300 sehe ich beim R420 keinen Anspruch auf technologische Führerschaft. Jetzt wird jeder Transistor gespart, wo es nur geht.
Original geschrieben von ow
Welche PS3 Werbung mit Far Cry? Dieser Vergleich mit low detail (angeblich 2.0) und high detail (angeblich 3.0)
betasilie
2004-05-10, 14:59:23
Original geschrieben von aths
Die 3Dc-Werbung halte ich für ehrlicher, als die PS 3.0-Werbung mit Far Cry.
S3TC ist seit Jahren breit akzeptiert. Auch Normal Maps (verlustbehaftet) zu komprimieren ist eine Sache, die schon lange hätte kommen sollen.
Full Ack. Technologisch ist SM3.0 sicherlich interessanter, aber 3Dc ist sicherlich etwas, was im Gegensatz zu SM3.0, schnell und relativ unkompliziert bei neuen Titeln für sichtbare Vorzüge sorgen wird.
Original geschrieben von ow
Welche PS3 Werbung mit Far Cry?
Dieser Vergleich, der dem Betrachter suggerieren sollte, dass sich die Vergleichsshots mit PS2.0 gemacht wurden, obwohl es PS1.1 Shots waren.
Sehr unfein.
betasilie
2004-05-10, 15:04:35
Original geschrieben von ow
Auf mich macht 3DC irgendwie den Eindruck als haette ATi unbedingt etwas gebraucht, das sonst keiner hat um ueberhaupt irgendwas neues fuer das Marketing zu haben.
Und wenn es so wäre, macht das 3Dc schlechter?
Original geschrieben von ow
AFAIK zaehlt das aber nicht zum offiziellen NV-Marketing oder irre ich da?
:spock: Wie kommst Du darauf?
Original geschrieben von Stefan Payne
1. den Link, den aths hier gepostet hätte, erspar ich mir, da klar sein sollte, welcher gemeint ist :eyes:Soweit ich erinnere war es Sphinx, der den Link postete...
Original geschrieben von Stefan Payne
2. öhm, dann erkläre uns mal, wieviel 3dc kostet, wir sind alle gespannt darauf...Dazu ist hier schon genug gesagt worden...
Original geschrieben von Stefan Payne
3. ja und durch 3dc kann die Performance bei beiden etwa gleich bleiben...
Oder wäre das Internet mit Bitmap Dateien denkbar?! :???:
Und ähh... ja... klar.
Razor
betasilie
2004-05-10, 15:18:09
Die FarCry Bilder kommen vom offiziellen Launchevent, ow.
Sean Pelletier:
For the screenshot examples shown at the launch event, why was PS 1.1 used to contrast PS 3.0? Why wasn’t a PS 2.0 screenshot compared to PS 3.0 instead?
Mr. Yerli:
On the event PS1.1 was compared with PS2.0/PS3.0. We don’t use PS3.0 everywhere. The general rule is to use as lower shader version as possible. So PS3.0 could be used only in several critical places where it gives performance boost.
http://www.pcper.com/article.php?aid=36&type=expert
... Das sie auch die Geometriedetail, Texturdetails, etc. auf low hatten, wird natürlich auch unter den Tisch gekehrt. Nun, da sieht man deutlich, dass PS3.0 derzeit absolut keine Vorzüge in realen Anwendungen haben, außer halt ein bissl Geschwindigkeit. Wenn es anders wäre, müssten sie nicht so eine Kundenverarschung machen. ... Schau dir mal die ersten Reaktionen auf die Bilder.
Und ow, kannst Du mir mal sagen woher die Bilder sonst hätten kommen sollen? Ich finde sinnige Fragen ja gut, aber wer sollte sonst solche Bilder in Umlauf bringen? ATI? CryTek? :|
Original geschrieben von betareverse
Full Ack. Technologisch ist SM3.0 sicherlich interessanter, aber 3Dc ist sicherlich etwas, was im Gegensatz zu SM3.0, schnell und relativ unkompliziert bei neuen Titeln für sichtbare Vorzüge sorgen wird.Das habe ich weder gesagt, noch gemeint :)
Anbetrachts der langen Zeit ehe S3TC wirklich mal in mehr als nur einem Titel eingesetzt wird, erwarte ich nicht so schnell sichtbare Vorteile die man nur mit 3Dc haben kann.
betasilie
2004-05-10, 15:35:01
Original geschrieben von aths
Das habe ich weder gesagt, noch gemeint :)
Anbetrachts der langen Zeit ehe S3TC wirklich mal in mehr als nur einem Titel eingesetzt wird, erwarte ich nicht so schnell sichtbare Vorteile die man nur mit 3Dc haben kann.
Nun, S3TC musste auch erstmal in DX fest integriert werden und DXTC genannt werden, denn S3 hatte wohl niemals die Kraft sowas alleine durchzuboxen.
ATI ist da wohl ein anderes Kaliber und hinzu ist es opensource. Daher werden wohl fast alle NextGen Titel 3Dc unterstützen.
LovesuckZ
2004-05-10, 15:47:35
Original geschrieben von aths
Dieser Vergleich mit low detail (angeblich 2.0) und high detail (angeblich 3.0)
Und worin Unterscheidet sich das vom 3Dc Marketing?
Ob ich nun SM1.1 mit dem SM3.0 Vergleiche und das SM2.0 einfach "vergesse" oder ob ich hochaufgeloeste 3Dc Normalmaps gegen standardaufgeloeste Normalmaps vergleiche.
Ich sehe deutige Parallelen...
Original geschrieben von aths
Imo geht es darum, dass einige Leute 3Dc zu sehr in den Himmel reden, und andere dieses Feature ungerechtfertigt runter machen.Den Eindruck hatte ich eigentlich weniger...
Aber klar, das hier ist nicht das Technik-Forum.
Original geschrieben von aths
Warum sollte das da stehen? Mit 3Dc kann man mit gleichem Speicherplatz feinere Normalmaps haben als ohne. Speicherplatz auf der Graka ist per se eine begrenzte Ressource.Wird denn der Speicherplatz bei heutigen 128MB-Karten überhaupt ausgenutzt ?
Und bitte nicht vergessen, dass nicht alle Karten dieses 'Feature' nutzen können werden. Insofern der DEV sowieso darauf achten muss, mit dem vorhandenen Speicher so oder so auszukommen.
Es geht hier darum, festzustellen, ob der Aufwand für eine verschwindend geringe Hardwarebasis überhaupt sinnvoll erscheint. Klar, wenn die Hardware-Basis groß genug wäre, dann...
Insofern ich vermute, dass sich die DEV's damit erst einmal zurück halten werden.
Original geschrieben von aths
Der Sinn von Bumpmapping scheint dir bisher entgangen zu sein? Macht aber auch nichts – einfach die nächste "PC Intern" kaufen :)Nein.
:D
Original geschrieben von aths
Nein. Mir ist ehrlich gesagt weder klar, was die letzten Zeilen sollen, noch, wo du das Kompatibilitätsproblem siehst. Sollte man z. B. auf SM 3.0 verzichten, weil das derzeit inkompatibel mit Radeon-Hardware ist?Du hast leider falsch gequotet und offenbar Deinen eigenen Post vergessen...
(vermute ich ;-)
Zur Kompatibilität:
Was passiert, wenn die Normalmap von der Auflösung her nicht zur Textur paßt ?
:???:
Original geschrieben von aths
Würdest du auch die Ausrufezeichen ohne Leerzeichen direkt ans Wort setzen, wären deine Postings noch besser zu lesen :) Selbst schuld.
Ich mach' das mit den Fragezeichen jetzt wieder so, wie ich das will !
:D
Razor
Original geschrieben von aths
Dieser Vergleich mit low detail (angeblich 2.0) und high detail (angeblich 3.0) Und wer soll damit geworben haben ?
:???:
Razor
LovesuckZ
2004-05-10, 15:51:26
Original geschrieben von betareverse
Full Ack. Technologisch ist SM3.0 sicherlich interessanter, aber 3Dc ist sicherlich etwas, was im Gegensatz zu SM3.0, schnell und relativ unkompliziert bei neuen Titeln für sichtbare Vorzüge sorgen wird.
Liest du überhaupt alles?
3Dc führt zu keinem "sichtbaren Vorzügen". Dazu müssen erst Anpassungen an der Engine bzw. an den Normalmaps durchgeführt werden. Und die seien nach einigen nicht gerade unbedeutend.
Dieser Vergleich, der dem Betrachter suggerieren sollte, dass sich die Vergleichsshots mit PS2.0 gemacht wurden, obwohl es PS1.1 Shots waren.
Sehr unfein.
Siehe 3Dc Marketing. Unfein dem Leser zu suggerieren, dass 3Dc bessere Qualitaet biete als nicht komprimierte Normalmaps.
Original geschrieben von ow
Auf mich macht 3DC irgendwie den Eindruck als haette ATi unbedingt etwas gebraucht, das sonst keiner hat um ueberhaupt irgendwas neues fuer das Marketing zu haben. Haben sie auch so: Die Karte für High Definition Experience :)
Ups, ist ja gar nichts neues bei. Egal.
Nüchtern betrachtet nützt eine Normalen-Komprimierung der Komprimierung willen nur, wenn man so gut wie möglich komprimiert. Dass man dann Z rekonstrieren muss, ist eine notwendige Folge.
LovesuckZ
2004-05-10, 15:53:16
Original geschrieben von betareverse
ATI ist da wohl ein anderes Kaliber und hinzu ist es opensource. Daher werden wohl fast alle NextGen Titel 3Dc unterstützen.
Erklaere das doch mal unter der Beruecksichtigung, dass das SM3.0, wie von dir suggeriert, in naher Zukunft keine Bedeutung haette.
Original geschrieben von ow
Auf mich macht 3DC irgendwie den Eindruck als haette ATi unbedingt etwas gebraucht, das sonst keiner hat um ueberhaupt irgendwas neues fuer das Marketing zu haben. (Wenn ich mich nicht irre kann ein NV40 ja alles was ein R420 auch kann (6xMSAA mal ausgenommen))Genau diesen Eindruck habe ich derzeit auch.
Ähnlich diesem Trueform (wahrscheinlich wieder falsch geschrieben ;-) und dem Dolphin-Demo.
(war wohl beim R200, wenn ich recht entsinne)
Razor
Original geschrieben von LovesuckZ
Siehe 3Dc Marketing. Unfein dem Leser zu suggerieren, dass 3Dc bessere Qualitaet biete als nicht komprimierte Normalmaps. Auf gleichen Speicherverbrauch bezogen wird mit 3Dc schon das feinere Detail ermöglicht.
Original geschrieben von betareverse
Und wenn es so wäre, macht das 3Dc schlechter?Ja.
Razor
LovesuckZ
2004-05-10, 15:55:53
Original geschrieben von aths
Auf gleichen Speicherverbrauch bezogen wird mit 3Dc schon das feinere Detail ermöglicht.
Das zeigt das ATi Markteing aber nicht.
Original geschrieben von betareverse
Nun, S3TC musste auch erstmal in DX fest integriert werden und DXTC genannt werden, denn S3 hatte wohl niemals die Kraft sowas alleine durchzuboxen.
ATI ist da wohl ein anderes Kaliber und hinzu ist es opensource. Daher werden wohl fast alle NextGen Titel 3Dc unterstützen. So wie bei Treuform ?
:D
Razor
Original geschrieben von r@w
Wird denn der Speicherplatz bei heutigen 128MB-Karten überhaupt ausgenutzt ?Hängt vom Spiel ab.
Original geschrieben von r@w
Und bitte nicht vergessen, dass nicht alle Karten dieses 'Feature' nutzen können werden. Insofern der DEV sowieso darauf achten muss, mit dem vorhandenen Speicher so oder so auszukommen.... umso besser, wenn er Normal Maps mit 3Dc komprimieren kann, gell?
Original geschrieben von r@w
Es geht hier darum, festzustellen, ob der Aufwand für eine verschwindend geringe Hardwarebasis überhaupt sinnvoll erscheint. Klar, wenn die Hardware-Basis groß genug wäre, dann...Ginge es danach, dürften wir auf lange Zeit nichts von SM 3.0 sehen.
Original geschrieben von r@w
Insofern ich vermute, dass sich die DEV's damit erst einmal zurück halten werden.Viele haben schon zugesagt. Ok, erst mal zusagen ist auch kein Ding. Ich denke aber schon, dass ATI die nötigen Anreize bieten kann, einige von den 3Dc-Vorteilen zu überzeugen.
Original geschrieben von r@w
Du hast leider falsch gequotet und offenbar Deinen eigenen Post vergessen...
(vermute ich ;-)Vermute ich nicht.
Original geschrieben von r@w
Zur Kompatibilität:
Was passiert, wenn die Normalmap von der Auflösung her nicht zur Textur paßt ?Was passiert, wenn man über Bumpmapping redet und gar nicht weiß, wie es funktioniert? Zum Beispiel, dass man solche Fragen stellt.
Original geschrieben von r@w
Ja.
Razor Nein.
aths
Original geschrieben von aths
Auf gleichen Speicherverbrauch bezogen wird mit 3Dc schon das feinere Detail ermöglicht. Und da liegt der Hase im Pfeffer...
Deswegen ja auch das Ruby-Demo.
Razor
P.S.: Ich mach' jetzt Feierabend !
(wenn ich heut' überhaupt was Vernünftiges getan hätt' ;-)
Wishnu
2004-05-10, 16:13:38
Original geschrieben von r@w
Und da liegt der Hase im Pfeffer...
Deswegen ja auch das Ruby-Demo.
Meiomei, ein bissl arg einseitig bist Du ja schon.
In meinen Augen macht es keinen Sinn, einen derart einseitigen Vorwurf in Richtung ATI aufzufahren (bei Nvidia siehst Du das Problem ja nicht), der besagt, dass sie in Technologiedemos die speziellen Fähigkeiten ihrer Hardware nicht deswegen nutzen würden, weil sich damit mehr realisieren ließe, sondern alleine aus Boshaftigkeit den Mitkonkurrenten gegenüber.
Genausowenig Sinn machte Deine anfängliche Frage, warum Ati die Richtlinien für das Demo nicht am Technologielvel des R3x0 festgemacht hat...
Es wäre echt schön, wenn Du Dich wenigstens einmal ein klein wenig um Objektivität bemühen würdest, denn so wirken Deine Statements allesamt unglaubwürdig.
P.S.
StefanV
2004-05-10, 16:14:02
Original geschrieben von r@w
Soweit ich erinnere war es Sphinx, der den Link postete...
Nein, diesen (http://www.aktiv-gegen-plenken.de/) Link postet meist aths...
Original geschrieben von r@w
Dazu ist hier schon genug gesagt worden...
:???:
Ich will von dir wissen wieviel 3dc deiner Meinung nach kostet.
Was diverse andere dazu sagten, ist mir bekannt, dennoch ist es hier irrelevant, was sie sagten, hier interessiert nur das, was du dazu sagst, bin schon sehr gespannt, warum deiner Meinung nach 3dc teuer ist...
Original geschrieben von r@w
Und ähh... ja... klar.
Razor
Natürlich, ohne Bilder sicher, aber dann hätte man unter anderem keine Buttons unter anderem :eyes:
Und modernes Internet ohne Buttons, naja, ich weiß nicht...
deekey777
2004-05-10, 16:17:17
Original geschrieben von r@w
Und da liegt der Hase im Pfeffer...
Deswegen ja auch das Ruby-Demo.
Razor
P.S.: Ich mach' jetzt Feierabend !
(wenn ich heut' überhaupt was Vernünftiges getan hätt' ;-)
:wayne:
Entweder bin ich zu blöd es zu verstehen, aber spätestens mit dem DX9.0c Release&FC 1.1 wird ein Spiel auf dem Markt sein, welches das SM 3.0 der NV40 unterstützt, oder liege ich wirklich daneben. Aber was soll dieser Vergleich zw. SM 3.0 der NV40 <->3Dc<-> SM 3.0 allg.? Und wieso hacken einige so auf 3Dc herum? Der Sinn davon ist entweder mit 3Dc die Ressourcen zu schonen bei gleicher Qualität oder bessere Qualität mit 3Dc bei gleicher Ressourcenauslastung als ohne 3Dc. Mir als Enduser ist doch egal, ob die (Spiele-)Programmiere damit einige Sonderschichten anlegen müssen. Das gleiche ist auch bei der SM 3.0 Unterstützung der NV 40 (mit etwas weniger Aufwand).
Zu der Sache in Genf: Ich sehe da keine einzige Parallele zu 3Dc.
StefanV
2004-05-10, 16:19:31
Original geschrieben von r@w
Wird denn der Speicherplatz bei heutigen 128MB-Karten überhaupt ausgenutzt ?
Razor
Nein, deswegen sind die 256MB Karten unter diversen, mysteriösen Umständen auch nicht schneller :eyes:
Aber heutzutage langen ja auch 64MB Karten noch locker aus, Unterschiede von bis zu 50% sind auch eigentlich nicht zu sehen, besonders nicht bei UT2003...
Original geschrieben von aths
Wenn die arithmetischen Einheiten unterausgelastet sind, macht das nichts. Gerade auf Mittelklasse-HW mit vergleichweise wenig RAM (128 MB) und begrenzter Bandbreite (Interface mit 128 Bit) könnte 3Dc zu einem Speedup führen.
ATI wird angesichts des R420 kaum die Transistoren für 3Dc aufgewendet haben, wenn das Feature wirklich nichts brächte.
Natürlich "macht" das nichts, wenn genug Ressourcen zur Verfügung stehen - andererseits: Ist das nicht bei jedem Feature so?
Gerade Mittelklasse Hardware hat in der momentanen Situation sowohl bei ATi als auch bei nVidia eigentlich eher wenig zu lachen, wenn es, wie in dem Quote auf das sich mein von dir gequotetes Posting bezog, um Pixelshader 2.0-Spiele geht.
Insbesondere bei ATi soll es ja, so die landläufige Meinung, relativ wenig Leerlauf in der Pipeline geben, so daß sich hier die Extra-Zyklen für die Z-Rekonstruktion noch weniger "for free" ergeben sollten, als bei einer Pipeline, die sowieo Däumchen dreht.
Im Gegenteil denke ich, daß ATi _gerade_ angesichts des R420 die Transistoren für _irgendwas_ aufbringen musste, das die Konkurrenz (noch?) nicht hat. Wie Demirug irgendwo mal erläuterte, scheinen sich ja einige Einheiten, die sowieso schon für DXTC benötigt werden, für 3dc "mißbrauchen" zu lassen, was zweierlei Fragen aufwirft (wenn es denn stimmt):
- Wieviele Transistoren kostet 3dc wirklich und
- Wie gut verträgt sich gleichzeitige DXTC/S3TC mit 3dc?
Wenn ich mir Ruby so anschaue, könnte man fast auf den Eindruck kommen, die ~220 MB Texturen (die's inkl. 3dc-Normals wohl auf R420-Chips sind) bzw. die ~280MB auf anderen Karten, enthielten überhaupt keine anderweitig komprimierten Texturen, außer den Normals.
;Q
betasilie
2004-05-10, 16:46:27
Original geschrieben von LovesuckZ
Und worin Unterscheidet sich das vom 3Dc Marketing?
Ob ich nun SM1.1 mit dem SM3.0 Vergleiche und das SM2.0 einfach "vergesse" oder ob ich hochaufgeloeste 3Dc Normalmaps gegen standardaufgeloeste Normalmaps vergleiche.
Ich sehe deutige Parallelen...
*zonk* ... und Du bist der einzige, bis zu deinem Bann. ;)
Demirug
2004-05-10, 17:24:06
Original geschrieben von q@w
Im Gegenteil denke ich, daß ATi _gerade_ angesichts des R420 die Transistoren für _irgendwas_ aufbringen musste, das die Konkurrenz (noch?) nicht hat. Wie Demirug irgendwo mal erläuterte, scheinen sich ja einige Einheiten, die sowieso schon für DXTC benötigt werden, für 3dc "mißbrauchen" zu lassen, was zweierlei Fragen aufwirft (wenn es denn stimmt):
- Wieviele Transistoren kostet 3dc wirklich und
- Wie gut verträgt sich gleichzeitige DXTC/S3TC mit 3dc?
;Q
3dc benutzt für beide Kanäle das Kompressionverfahren das DXTC für Alpha einsetzt. Ergo kann man für den einen Kanal schonmal direkt die DXTC-Einheit für Alpha benutzten.
Die zweite DXTC-Einheit ist für die Farbe zuständig. Die muss man ein wenig erweitern. Standardmässig kann diese Einheit zwischen zwei 16 BIT RGB (5:6:5) Werten interpolieren. Pro Texel stehen 2 Bit zur verfügung. Erhöht man jetzt den Kanal für Grün auf 8 Bit und die Interpolationsgenauigkeit auf 3 Bit kann man diese Einheit ohne Probleme für den zweiten 3dc Kanal benutzen.
Da pro Takt und TMU ja immer nur ein Kompressionverfahren benutzt werden kann sind keine Probleme bei gleichzeitiger Verwendung von 3dc und DXTC zu erwarten.
Original geschrieben von ow
Bei dann schlechterer Performance. Das wird sich zeigen.
Original geschrieben von q@w
Gerade Mittelklasse Hardware hat in der momentanen Situation sowohl bei ATi als auch bei nVidia eigentlich eher wenig zu lachen, wenn es, wie in dem Quote auf das sich mein von dir gequotetes Posting bezog, um Pixelshader 2.0-Spiele geht.Farcry läuft bei mir mit der Radeon 9600 erschreckend gut. Pixelshader-Power ist offenbar genug da.
Quasar
2004-05-10, 19:18:37
Original geschrieben von aths
Farcry läuft bei mir mit der Radeon 9600 erschreckend gut. Pixelshader-Power ist offenbar genug da.
Wieviele der Pixelshader in Far Cry beanspruchen eine Radeon wirklich? Und wieviele Pixel werden damit pro Bild im Schnitt gerendert?
tokugawa
2004-05-10, 20:34:05
Original geschrieben von aths
Imo geht es darum, dass einige Leute 3Dc zu sehr in den Himmel reden, und andere dieses Feature ungerechtfertigt runter machen.
Genau! Full ACK.
Ich hab auch nur versucht, die Probleme von 3Dc zu erleuchten (die Vorteile liegen auf der Hand). Dass mich einige dafür angreifen bzw einer mich sogar auf Ignore setzt... naja, selber schult. Ich fand die Diskussion, solang sie sachlich war, ziemlich gut.
Original geschrieben von aths
Warum sollte das da stehen? Mit 3Dc kann man mit gleichem Speicherplatz feinere Normalmaps haben als ohne. Speicherplatz auf der Graka ist per se eine begrenzte Ressource.
Der Sinn von Bumpmapping scheint dir bisher entgangen zu sein? Macht aber auch nichts – einfach die nächste "PC Intern" kaufen :)
Nein. Mir ist ehrlich gesagt weder klar, was die letzten Zeilen sollen, noch, wo du das Kompatibilitätsproblem siehst. Sollte man z. B. auf SM 3.0 verzichten, weil das derzeit inkompatibel mit Radeon-Hardware ist?
Würdest du auch die Ausrufezeichen ohne Leerzeichen direkt ans Wort setzen, wären deine Postings noch besser zu lesen :)
tokugawa
2004-05-10, 20:42:12
Original geschrieben von betareverse
Nun, S3TC musste auch erstmal in DX fest integriert werden und DXTC genannt werden, denn S3 hatte wohl niemals die Kraft sowas alleine durchzuboxen.
ATI ist da wohl ein anderes Kaliber und hinzu ist es opensource. Daher werden wohl fast alle NextGen Titel 3Dc unterstützen.
Man muß allerdings immer den Aufwand miteinberechnen. 3Dc selbst zu implementieren ist nicht sooo schwer (wenn auch nicht so angenehm wie etwa SM 3.0).
Aber das Problem ist ja: Um den Vorteil von 3Dc auszunutzen (und der liegt daran, höherauflösende Normalmaps verwenden zu können zu den gleichen Kosten wie niedriger aufgelöste - würden die Normalmaps einfach die gleiche Größe haben, und nur Platz gespart werden, wäre der Vorteil geringer - der Ersparnisfaktor bei reichlich vorhandenem Speicher wäre wohl... sinnlos), müsste man die Normalmaps eben in der höheren Auflösung bereitstellen.
Im Endeffekt würde ich hier folgende Ausführungsweise dann am effektivsten halten:
- hochauflösende Normalmaps in 3Dc komprimiert als Assets im Spiel
Wenn jetzt die Hardware 3Dc unterstützt:
- werden diese 3Dc maps geladen
Wenn nicht:
- werden die 3Dc Maps in niedrigerauflösende unkomprimierte Normalmaps konvertiert.
Ist die Frage ob sich das auszahlt wenn 3Dc nicht weitflächig von anderen Grafikchipherstellern unterstützt wird (wie etwa DXTC).
Und irgendwie müssen die Spielehersteller auch mit dem (Festplatten/DVD/CD) Speicherplatz auskommen...
tokugawa
2004-05-10, 20:57:06
Original geschrieben von betareverse
Full Ack. Technologisch ist SM3.0 sicherlich interessanter, aber 3Dc ist sicherlich etwas, was im Gegensatz zu SM3.0, schnell und relativ unkompliziert bei neuen Titeln für sichtbare Vorzüge sorgen wird.
Eben nicht.
SM 3.0 ist einfacher zu integrieren als 3Dc in eine Engine, die bereits Shader unterstützt (und das sind alle aktuellen und neue Titel).
Bei 3Dc muß man jeden Normalmap-verwendenden Shader umschreiben (mal abgesehen von den Änderungen beim Laden, dem Aufwand die Normalmaps für 3Dc zu erstellen (in höherer Auflösung als für andere Karten), bzw. vorhandene neu zu generieren), bei SM 3.0 müsste man eben nur 3.0er-Shader entwickeln (oder downloaden von der NVIDIA Developer Seite :D ), und einfach nur laden (mit HLSL ist der Aufwand dann nur eine Rekompilation).
Shader können außerdem heutzutage unabhängig von der Engine entwickelt werden, während bei 3Dc eine Abhängigkeit von der Engine besteht (d.h. die Engine muß da sein, um 3Dc einzubauen).
Wer schon mal Projektmanagement betrieben hat, wird die Parallelität von Shader- und Engine-Entwicklung zu schätzen wissen - auch die Entwickler neuer Titel. Einfach ausgedrückt: Entwickler können bei neuen Titeln bereits an den Shadern arbeiten, wenn die Engine noch nicht mal steht. Folglich werden auch (3.0er) Shader entwickelt werden, die dann auch einfach downgeloadet und genutzt werden kann.
Die Unabhängigkeit von Shadern und Engine geht so weit, dass es heute bereits eine Shader-Entwickler-Szene gibt, die eifrig Shader programmiert und austauscht, und die man dann einfach nur mehr laden muß (keine Änderung an der Engine).
Und das war ja eigentlich der Hauptgrund, warum man von der Shader-als-Register-Combiner-Semantik auf Shader-in-Programmcode-Form umgestiegen ist - Shading-Algorithmen in "modularer" Form in Form eines Shaders.
MadMan2k
2004-05-11, 00:03:14
Original geschrieben von tokugawa
Eben nicht.
SM 3.0 ist einfacher zu integrieren als 3Dc
jo, aber nur das letztere bietet einen sichtbaren Vorteil.
(und damit meine ich nicht das Suchen mit eingefärbten Mips ;) )
Demirug
2004-05-11, 06:55:05
Original geschrieben von MadMan2k
jo, aber nur das letztere bietet einen sichtbaren Vorteil.
(und damit meine ich nicht das Suchen mit eingefärbten Mips ;) )
Nicht automatisch. Nur weil man eine Bumpmap mit 3dc komprimiert sieht davon kein Spiel besser aus. Duch die Kompression werden lediglich Resourcen frei die man dann anderweitig einsetzten kann.
SM3 hat genau das gleiche Ziel. Bisher verschwendete Resourcen für andere Zwecke zur Verfügung zu stellen.
betasilie
2004-05-11, 13:32:04
Original geschrieben von Demirug
Nicht automatisch. Nur weil man eine Bumpmap mit 3dc komprimiert sieht davon kein Spiel besser aus. Duch die Kompression werden lediglich Resourcen frei die man dann anderweitig einsetzten kann.
Ich hoffe doch mal, dass die Toptitel 3Dc nicht nur benutzen um Resourcen frei zu machen, sondern um die Bumbmaps nochauflösender zu machen.
Sphinx
2004-05-11, 13:38:50
,) ich sehe Half-Live2 auf einer FX
in den höchsten Details.
- Plz Wait Loading Data -.....- Loaded - play 5 Mins - - Plz Wait Loading Data -.....-...
^^ Nur ein scherz am Rande - plz
MadMan2k
2004-05-11, 15:08:48
Original geschrieben von Demirug
Nicht automatisch. Nur weil man eine Bumpmap mit 3dc komprimiert sieht davon kein Spiel besser aus. Duch die Kompression werden lediglich Resourcen frei die man dann anderweitig einsetzten kann.
SM3 hat genau das gleiche Ziel. Bisher verschwendete Resourcen für andere Zwecke zur Verfügung zu stellen.
ok, dann lässt sich IMO per 3dc leichter ein sichtbarer Vorteil erreichen, nämlich eine höhere Texturauflösung bei gleichem Speicherbedarf - die höhere PS Belastung ist dabei meiner Meinung nach vernachlässigbar, da sie heute noch nicht den Flaschenhals spielt.
Oder andersherum:
Branching kostet auf dem NV40 noch zu viel und die Shader bei denen sich Branching trotzdem noch lohnen würde sind insgesamt zu langsam, als dass man heute einen Vorteil daraus ziehen könnte. (nur auf Spiele bezongen)
Original geschrieben von aths
Hängt vom Spiel ab.Zum Beispiel ?
Tät mich halt interessieren...
Original geschrieben von aths
... umso besser, wenn er Normal Maps mit 3Dc komprimieren kann, gell?Wenn er das nicht in jedem Fall machen kann... eher nicht.
Original geschrieben von aths
Ginge es danach, dürften wir auf lange Zeit nichts von SM 3.0 sehen.Ähmm...
Shader unverändert einfach nochmal durch den Compiler jagen ?
Oder noch besser einfach die Runtime dazu geben und gar nichts tun ?
:???:
Der Aufwand geht nahe gegen Null.
Original geschrieben von aths
Viele haben schon zugesagt. Ok, erst mal zusagen ist auch kein Ding. Ich denke aber schon, dass ATI die nötigen Anreize bieten kann, einige von den 3Dc-Vorteilen zu überzeugen.Das würde letztlich auf den (kaum vorhandenen) Bandbreitenvorteil deuten, den 3Dc bringen kann... nicht unbedingt auf eine bessere Auflösung der Normalmaps...
-
Den Rest schenke ich mir mal...
;-)
Razor
Original geschrieben von Stefan Payne
Nein, deswegen sind die 256MB Karten unter diversen, mysteriösen Umständen auch nicht schnellerVergleiche FX5600/5700 128MB gegen 256MB und wiederhole das noch mal...
Original geschrieben von Stefan Payne
Aber heutzutage langen ja auch 64MB Karten noch locker aus, Unterschiede von bis zu 50% sind auch eigentlich nicht zu sehen, besonders nicht bei UT2003... Und was hat jetzt das wieder miteinander zu tun ?
:???:
"Mehr ist immer besser !"
Oder was ?
Razor
Original geschrieben von ow
Also da sehe ich jetzt keinen Vergleich zu frueher.
Ein R200 hat ja wesentlich mehr zu bieten als nur Truform (jeweils verglichen mit seiner Vorgaengergeneration (R100) und dem NV2x).Ich meinte nicht den ganzen Chip, sondern speziell dieses Feature (Treuform ;-).
Bandbreitenschonung, bessere Optik (da mehr Polys ohne Polys ;-)...
...aber eben auch nicht ganz untrivial zu implementieren.
Und eben 'Single-Feature' eines einzigen Herstellers (und wie sich heraus stellte... eines einzigen Chips ;-). OK, Treuform (tm@Razor ;-) wird sicherlich sehr viel komplexer zu implementieren gewesen sein, als es 3Dc ist (hoffe ich doch), aber eine gewisse Ähnlichkeit ist unverkennbar.
Razor
Original geschrieben von MadMan2k
ok, dann lässt sich IMO per 3dc leichter ein sichtbarer Vorteil erreichen, nämlich eine höhere Texturauflösung bei gleichem Speicherbedarf - die höhere PS Belastung ist dabei meiner Meinung nach vernachlässigbar, da sie heute noch nicht den Flaschenhals spielt.Mit den Texturen hat das schon mal gar nichts zu tun. 3Dc komprimiert ausschließlich Normalmaps...
Original geschrieben von MadMan2k
Oder andersherum:
Branching kostet auf dem NV40 noch zu viel und die Shader bei denen sich Branching trotzdem noch lohnen würde sind insgesamt zu langsam, als dass man heute einen Vorteil daraus ziehen könnte. (nur auf Spiele bezongen) Ein Hellseher ja ? Wieso sollte Branching (noch) zu viel kosten ? Gibt es DX9c etwa schon ?
Oder gar irgendwelche Anwendungen, die die "Langsamkeit" des Branchings auf dem NV40 zeigen ?
:???:
Hmmm...
Razor
DrumDub
2004-05-12, 15:55:56
kannst du uns zur abwechslung auch mal was neues erzählen, razor? deine meinung zu features die ati mit neuen produkten bringt, kennen wir ja mittlerweile zu genüge.
und was der seitenhieb auf den einwand stefan paynes bezüglich 256mb karten soll, versteh ich auch nicht. das bei den midrange/lowend-karten 256mb nix bringen, da man eh nicht halbwegs aktuelle spiele mit vollen details in hohen auflösungen bei aa/af mit eben solchen karten spielen kann, sollte dir doch mittlerweile auch bekannt sein.
StefanV
2004-05-12, 16:03:43
Original geschrieben von r@w
Vergleiche FX5600/5700 128MB gegen 256MB und wiederhole das noch mal...
Von dem Schrott sprichst du, das 'high End' Karten gemeint sein könnten und eher weniger die kleineren, dürfte auch klar sein, nicht wahr, Razor?
Original geschrieben von r@w
Und was hat jetzt das wieder miteinander zu tun ?
:???:
"Mehr ist immer besser !"
Oder was ?
Razor
Denk mal haarscharf nach, viellecht kommst ja drauf...
ironMonkey
2004-05-12, 16:04:27
Original geschrieben von r@w
Vergleiche FX5600/5700 128MB gegen 256MB und wiederhole das noch mal...
Und was hat jetzt das wieder miteinander zu tun ?
:???:
"Mehr ist immer besser !"
Oder was ?
Razor
Grad UT03/04( 04 auch bei Arbeitsspeicher) haut bei 128mb Karten rein, bei NV wie bei ATI, allerdings so lange keine Filter an sind und nicht höher als 1280er Auflösung gespielt wird schnenken sich 128 und 256mb karten nix.
Auf der einen Seite hast du recht, auf der anderen( bei schnellen Karten) wieder nicht da hier AA+AF meist zugeschaltet wird und somit hier und da die 256mb Karten Vorteile haben.
Gruß
MadManniMan
2004-05-12, 17:22:13
Original geschrieben von r@w
Mit den Texturen hat das schon mal gar nichts zu tun. 3Dc komprimiert ausschließlich Normalmaps...
Nay, es komprimiert alle Formate, die mit dem Algo klarkommen.
Original geschrieben von Stefan Payne
Von dem Schrott sprichst du, das 'high End' Karten gemeint sein könnten und eher weniger die kleineren, dürfte auch klar sein, nicht wahr, Razor?Soll ich Dich zitieren, oder bekommst Du das selber hin ?
:D
Original geschrieben von Stefan Payne
Denk mal haarscharf nach, viellecht kommst ja drauf... Nö.
Warum sollte ich über so etwas nachdenken wollen ?
Razor
Original geschrieben von ironMonkey
Grad UT03/04( 04 auch bei Arbeitsspeicher) haut bei 128mb Karten rein, bei NV wie bei ATI, allerdings so lange keine Filter an sind und nicht höher als 1280er Auflösung gespielt wird schnenken sich 128 und 256mb karten nix.Auch mit aktivierten Filtern kann ich ohne größeren Verlust (mit 'ner 128MB Karte) keinen größeren Verlust feststellen, ob ich nun in 1280 oder in 800 spiele (gilt für UT3/4). Ab 1600 wird's 'etwas' dünn, aber wer spielt schon, um Augenkrebs zu bekommen... ;)
Nein, im ernst... ich würde 1600 oder höher in Betracht ziehen, wenn der Moni da 100Hz mitmachen würde und dann mag es auch sein, dass 256MB (zumindest bei dieser Engine) etwas bringen.
Original geschrieben von ironMonkey
Auf der einen Seite hast du recht, auf der anderen( bei schnellen Karten) wieder nicht da hier AA+AF meist zugeschaltet wird und somit hier und da die 256mb Karten Vorteile haben.Kann ich nun wirklich nicht nachvollziehen (ausser UT3/4 unter 1600 vielleicht). Auf FX5950 geflasht verliert meine gute FX5900 (128MB ;-) kaum mehr, als vergleichbare 'originale'.
Razor
Original geschrieben von MadManniMan
Nay, es komprimiert alle Formate, die mit dem Algo klarkommen. Seit wann muss ein Format mit irgendetwas 'klar kommen' ?
:???:
Und wenn mich nicht alle Sinne täuschen, sprach ATI in der Präsentation eindeutig (und ausschließlich) von Normalmaps und nicht von den Basis-Texturen o.ä.
Razor
MadManniMan
2004-05-12, 18:28:34
Original geschrieben von r@h
Seit wann muss ein Format mit irgendetwas 'klar kommen' ?
:???:
Und wenn mich nicht alle Sinne täuschen, sprach ATI in der Präsentation eindeutig (und ausschließlich) von Normalmaps und nicht von den Basis-Texturen o.ä.
Razor
Wenn Xmas, zecki oder Demi was dazu sagen könnten? Ich weiß nur, daß es natürlich auch anderen Kram komprimieren kann. Auch wenn es natürlich für den möglichst Verlustfreien Einsatz von Normals gedacht ist.
Aquaschaf
2004-05-12, 18:44:15
Original geschrieben von r@w
Mit den Texturen hat das schon mal gar nichts zu tun. 3Dc komprimiert ausschließlich Normalmaps...
Und was ist eine Normalmap? Normalen in einer Textur gespeichert. Für die 3DC Dekompression dürften die selben Einheiten im Chip verwendet werden wie für DXT Dekompression.
ironMonkey
2004-05-12, 19:05:28
mal wieder was zum Thema, gibts da jetzt was neues schon das die R3XX Karten die Ruby Demo in voller Pracht zeigen.
Gruß
Original geschrieben von MadManniMan
Wenn Xmas, zecki oder Demi was dazu sagen könnten? Ich weiß nur, daß es natürlich auch anderen Kram komprimieren kann. Auch wenn es natürlich für den möglichst Verlustfreien Einsatz von Normals gedacht ist. Also ich kenne zu diesem Thema nur die ATI-Präsentation... und die kennt keinen "anderen Kram". Könntest Du das vielleicht mal etwas präzisieren ?
Thx
Razor
InsaneDruid
2004-05-12, 19:21:03
@ironMonkey: Noch nicht, Colourless scheint hart am werkeln zu sein :)
Original geschrieben von Aquaschaf
Und was ist eine Normalmap? Normalen in einer Textur gespeichert. Für die 3DC Dekompression dürften die selben Einheiten im Chip verwendet werden wie für DXT Dekompression. Ist das so ?
Wenn ich das richtig verstanden habe (was lange nicht der Fall sein muss), dann wird auch die DXT-Einheit für die 3Dc-Kompression benötigt. Aber da ist mehr... (oder auch nicht ;-)
Wenn ich das also richtig sehe, dann baut 3Dc sozusagen auf der DXT-Kompression auf, geht aber weiter (zumindest bei Normalmaps ;-).
Razor
MadManniMan
2004-05-12, 19:35:16
Original geschrieben von r@h
Also ich kenne zu diesem Thema nur die ATI-Präsentation... und die kennt keinen "anderen Kram". Könntest Du das vielleicht mal etwas präzisieren ?
Thx
Razor
Würde ich gern, aber ich erinner mich selbst nur dunkel an die Einzelheiten. Wird dir nur wer sagen können, der wirklich Ahnung von sowas hat.
Aquaschaf
2004-05-12, 20:11:57
Original geschrieben von r@h
Wenn ich das also richtig sehe, dann baut 3Dc sozusagen auf der DXT-Kompression auf, geht aber weiter (zumindest bei Normalmaps ;-).
Razor
Ja, irgendwo wurde das hier schon gepostet. Für 3DC braucht man eine DXT-Einheit, die um ein paar Funktionalitäten erweitert ist.
Original geschrieben von r@w
Zum Beispiel ?
Tät mich halt interessieren...Dass der Flaschenhals je nach Spiel woanders zu suchen ist, sollte keine Neuheit sein.
Original geschrieben von r@w
Wenn er das nicht in jedem Fall machen kann... eher nicht.Wo man es machen kann, ist es ein Vorteil, nicht?
Analogie mit SM 3.0: Nicht in jedem Fall bringt es irgendeinen Vorteil. Aber dort, wo es Vorteile bringt, sollte man es anwenden – genau so 3Dc.
Original geschrieben von r@w
Ähmm...
Shader unverändert einfach nochmal durch den Compiler jagen ?
Oder noch besser einfach die Runtime dazu geben und gar nichts tun ?Redeten wir vom Aufwand? Nein. Redeten wir (bzw. redetest du) von der Kompatibilität? Ja.
Original geschrieben von r@w
Den Rest schenke ich mir mal...Vielleicht bleibt dir dann die Zeit, die Postings auf die du antwortest im Zusammenhang zu lesen.
Demirug
2004-05-12, 20:23:14
Nochmal für alle:
- 3dc komprimiert nur zwei Kanäle einer Textur. Also Rot und Grün oder eben X und Y. Man kann es also immer dann einsetzten wenn man nur zwei Kanäle braucht.
- Die Kompression entspricht dabei einem Verfahren das DXT für den Alphawert einer Textur einsetzt.
- Da eine Textur aber nur einen Alphawert hat gibt es in einem Chip der DXT unterstützt nur eine entsprechende Dekompressioneinheit.
- Die zweite Einheit ist für den kompletten Farbwert verantwortlich. Diese kann man aber relative einfach so erweitern das sie ebenfalls auch einen Farbkanal nach dem Alphaverfahren dekomprimieren kann.
Vielleicht sollte mal jemand was zum Thema Texturkompression schreiben.
Original geschrieben von Demirug
Vielleicht sollte mal jemand was zum Thema Texturkompression schreiben. Würde ich liebend gern :) im Moment bin ich allerdings wirklich ausgelastet. Vor allem könnte man schön zeigen, dass es in der Regel nützt, 4:1 zu komprimieren und den Platz für (in beide Achsen) doppelt so hoch aufgelöste Texturen zu nutzen.
Sag mal aths, kann es sein, dass Du Dich irgendwie um konkrete Antworten drückst ?
:???:
Original geschrieben von aths
Dass der Flaschenhals je nach Spiel woanders zu suchen ist, sollte keine Neuheit sein.Vielleicht sollte ich die Frage klarer stellen:"In welchem Spiel limitieren 128MB Video-RAM ?"Schließlich verlief der Thread diesbezüglich so:
Razor: Wird denn der Speicherplatz bei heutigen 128MB-Karten überhaupt ausgenutzt ?
aths: Hängt vom Spiel ab.
Razor: Zum Beispiel ? Tät mich halt interessieren...
aths: Dass der Flaschenhals je nach Spiel woanders zu suchen ist, sollte keine Neuheit sein.Und fällt Dir was auf ?
Also, was ist nun ?
:???:
Original geschrieben von aths
Wo man es machen kann, ist es ein Vorteil, nicht?Für die paar 420'er ?
Nein.
Nicht für einen DEV, der für den breiten Markt entwickeln soll/muss.
Original geschrieben von aths
Analogie mit SM 3.0: Nicht in jedem Fall bringt es irgendeinen Vorteil.Natürlich nicht. Aber bei Effekten, die auf dutzende Shader setzen, die je nach Situation von der CPU (!) ausgewält werden müssen (wie z.Bsp. bei HL2 oder anderen Games mit komplexen Effekten) wird es wohl was bringe, oder ?
Und wenn nVidia für HL2 'handoptimieren' muss...
:DOriginal geschrieben von aths
Redeten wir vom Aufwand? Nein. Redeten wir (bzw. redetest du) von der Kompatibilität? Ja.Ich/wir (Du offenbar nicht) reden hier vom Aufwand und der Kompatibilität, bzw. wie man das eine in Grenzen und das andere möglich machen kann.
Razor
Erst einmal danke für die Erklärung, demirug.
Original geschrieben von Demirug
Nochmal für alle:
- 3dc komprimiert nur zwei Kanäle einer Textur. Also Rot und Grün oder eben X und Y. Man kann es also immer dann einsetzten wenn man nur zwei Kanäle braucht.
- Die Kompression entspricht dabei einem Verfahren das DXT für den Alphawert einer Textur einsetzt.
- Da eine Textur aber nur einen Alphawert hat gibt es in einem Chip der DXT unterstützt nur eine entsprechende Dekompressioneinheit.
- Die zweite Einheit ist für den kompletten Farbwert verantwortlich. Diese kann man aber relative einfach so erweitern das sie ebenfalls auch einen Farbkanal nach dem Alphaverfahren dekomprimieren kann.
Vielleicht sollte mal jemand was zum Thema Texturkompression schreiben. Leider habe ich (natürlich) den Inhalt (wohl wieder) nicht aufnehmen können, was sicherlich an meinem technischen Unverständnis in dieser Hinsicht liegt.
Aber mich würde trotzdem interessieren:
Kann man mit 3Dc auch was anderes als Normalmaps komprimieren ?
Wenn ja, was ?
Oder ist die Frage schon falsch gestellt ?
(weil 3Dc im Prinzip 'nur' eine Ergänzung für Normalmaps auf Basis von DXT ist)
Danke schon mal im voraus und sorry, wenn ich vielleicht dumme Fragen stelle.
Razor
Gasttt
2004-05-12, 21:02:56
Original geschrieben von r@h
Erst einmal danke für die Erklärung, demirug.
Leider habe ich (natürlich) den Inhalt (wohl wieder) nicht aufnehmen können, was sicherlich an meinem technischen Unverständnis in dieser Hinsicht liegt.
Aber mich würde trotzdem interessieren:
Kann man mit 3Dc auch was anderes als Normalmaps komprimieren ?
Wenn ja, was ?
Oder ist die Frage schon falsch gestellt ?
(weil 3Dc im Prinzip 'nur' eine Ergänzung für Normalmaps auf Basis von DXT ist)
Danke schon mal im voraus und sorry, wenn ich vielleicht dumme Fragen stelle.
Razor
Hi,
NATÜRLICH kann 3DC mehr,
3DC kann mit jedem 2-Kanal Format auch arbeiten und dieses OPTIMIEREN.
Weiterhin kannst du dir 3DC in der HL2-Demo anschauen.
Game-Developer wie, Croteam, Irrational Games, Tribes, Valve, darkSector, Firaxis, Pirates, ritual, digital extremes und pseudo interactive haben bereits bestätigt 3DC in Ihre Games einzubauen.
Grüsse
Demirug
2004-05-12, 21:08:23
Original geschrieben von r@h
Erst einmal danke für die Erklärung, demirug.
Leider habe ich (natürlich) den Inhalt (wohl wieder) nicht aufnehmen können, was sicherlich an meinem technischen Unverständnis in dieser Hinsicht liegt.
Aber mich würde trotzdem interessieren:
Kann man mit 3Dc auch was anderes als Normalmaps komprimieren ?
Wenn ja, was ?
Oder ist die Frage schon falsch gestellt ?
(weil 3Dc im Prinzip 'nur' eine Ergänzung für Normalmaps auf Basis von DXT ist)
Danke schon mal im voraus und sorry, wenn ich vielleicht dumme Fragen stelle.
Razor
3dc kann alles komprimieren was nur maximal 2 Kanäle enthält. Die standard DXTC Formate sind für 4 Kanäle gedacht.
Gasttt
2004-05-12, 21:10:03
Original geschrieben von Demirug
Nochmal für alle:
- 3dc komprimiert nur zwei Kanäle einer Textur. Also Rot und Grün oder eben X und Y. Man kann es also immer dann einsetzten wenn man nur zwei Kanäle braucht.
- Die Kompression entspricht dabei einem Verfahren das DXT für den Alphawert einer Textur einsetzt.
- Da eine Textur aber nur einen Alphawert hat gibt es in einem Chip der DXT unterstützt nur eine entsprechende Dekompressioneinheit.
- Die zweite Einheit ist für den kompletten Farbwert verantwortlich. Diese kann man aber relative einfach so erweitern das sie ebenfalls auch einen Farbkanal nach dem Alphaverfahren dekomprimieren kann.
Vielleicht sollte mal jemand was zum Thema Texturkompression schreiben.
Demi,
würde 3DC mehr als 2 Kanäle verwenden würde die Belastungen auf den Shader auch zu hoch werden, dafür hast du aber vergessen zu ERWÄHNEN das es mit AA, AF, shadows, HDR und psot-processing 100% kompatibel ist.
Wichtiger Aspekt wenn mann bedenkt das völlig HARDWARE-BASIEREND ist und rein gar nix mit irgendwelches Treiber-Einstellungen zu tun hat, das ist ja gerade der ENTSCHEIDENE Vorteil gegenüber der alten Matrox-Leier, wenn du verstehst !!!
Grüsse
Original geschrieben von r@h
Sag mal aths, kann es sein, dass Du Dich irgendwie um konkrete Antworten drückst ?
:???:
Vielleicht sollte ich die Frage klarer stellen:"In welchem Spiel limitieren 128MB Video-RAM ?"Läl. Darum ging es gar nicht. Aber ich gebe die Antwort gerne: Beispielsweise in UT 2003 und UT 2004. Nur nutzen diese Spiele kein Bumpmapping.
3Dc wird vor allem in zukünftigen Spielen eingesetzt. Deine Kristallkugel sagt, dass die auf keinen Fall von 256 oder 3Dc-Vorteile profitieren können oder was?!
Gerne würde ich dir konkrete Antworten geben, wenn du dich nicht immer winden und mit neuen Fragen, die eigentlich am Thema vorbei gehen, ausweichen würdest. Ob heute Spiele von 128 MB RAM profitieren ist eine komische Frage, da die 256-MB-Karten wenig verbreitet sind, und das 3Dc-Feauture momentan noch weniger.
Da wir nun 3Dc haben, wird es damit eher möglich, weiterhin (kostensparend) mit 128 MB auszukommen, als ohne 3Dc. Das sollte so schwer eigentlich nicht zu verstehen sein :kratz: Einige wichtige Entwickler jedenfalls scheinen 3Dc (genau wie ich) gut zu finden. Sicher nicht grundlos :)
LovesuckZ
2004-05-12, 21:16:35
Original geschrieben von Gasttt
Demi,
würde 3DC mehr als 2 Kanäle verwenden würde die Belastungen auf den Shader auch zu hoch werden, dafür hast du aber vergessen zu ERWÄHNEN das es mit AA, AF, shadows, HDR und psot-processing 100% kompatibel ist.
ehm welchen Einfluss hat AA/AF/Shadows/HDR/"psot-processing" auf die Normalmaps?
:???:
Gasttt
2004-05-12, 21:19:20
Original geschrieben von Demirug
3dc kann alles komprimieren was nur maximal 2 Kanäle enthält. Die standard DXTC Formate sind für 4 Kanäle gedacht.
Jetzt gehen wir mal ein Beispiel durch:
4x4 Operationen / Integer Data
Beispiel:
Uncompressed 32bpp normal map block!!!!!!!
- Jedes Element beinhaltet: 8bit (x, y & z Koordinaten)
für einen NORMALEN Vector !!
Enkodierung in Rot, Blau & Grün - Kanäle
Summe 512bits für einen Block
Da kommt dann satte Darstellung bei raus und bessere Details!!!!
Gasttt
2004-05-12, 21:21:54
Original geschrieben von aths
Läl. Darum ging es gar nicht. Aber ich gebe die Antwort gerne: Beispielsweise in UT 2003 und UT 2004. Nur nutzen diese Spiele kein Bumpmapping.
3Dc wird vor allem in zukünftigen Spielen eingesetzt. Deine Kristallkugel sagt, dass die auf keinen Fall von 256 oder 3Dc-Vorteile profitieren können oder was?!
Gerne würde ich dir konkrete Antworten geben, wenn du dich nicht immer winden und mit neuen Fragen, die eigentlich am Thema vorbei gehen, ausweichen würdest. Ob heute Spiele von 128 MB RAM profitieren ist eine komische Frage, da die 256-MB-Karten wenig verbreitet sind, und das 3Dc-Feauture momentan noch weniger.
Aths,
3DC kann sofort eingesetzt werden, siehe hierzu auch die Serios Sam 2 Demo!!!
Demirug
2004-05-12, 21:27:56
Original geschrieben von Gasttt
Demi,
würde 3DC mehr als 2 Kanäle verwenden würde die Belastungen auf den Shader auch zu hoch werden, dafür hast du aber vergessen zu ERWÄHNEN das es mit AA, AF, shadows, HDR und psot-processing 100% kompatibel ist.
Wenn 3dc alle 3 Kanäle (XYZ) komprimieren könnte hätte man überhaupt keine Zusatz-Belastung im Shader mehr. Aus diesem Grund kann ich den Einwand hier nicht verstehen.
Warum soll ich etwas erwähnen was selbstverständlich ist? Eine Texturkompression ist immer neutral was den Einsatz von Rendertechniken angeht.
Ich persönlich hätte die DXTC Alphakompression gerne für jede beliebige Anzahl von Kanälen von 1 - 4. Hätte ATI sowas eingebaut würde ich Jubbeln den dann hätte sich das einzige wirkliche Argument gegen 3dc erledigt.
Wichtiger Aspekt wenn mann bedenkt das völlig HARDWARE-BASIEREND ist und rein gar nix mit irgendwelches Treiber-Einstellungen zu tun hat, das ist ja gerade der ENTSCHEIDENE Vorteil gegenüber der alten Matrox-Leier, wenn du verstehst !!!
Grüsse
Um ehrlich zu sein weiss ich jetzt nicht auf welchen Aspekt bei Matrox du anspielst.
Original geschrieben von Gasttt
Aths,
3DC kann sofort eingesetzt werden, siehe hierzu auch die Serios Sam 2 Demo!!! Sofern man die Shader etwas erweitert und das Kompressions-Tool hat, kann man 3Dc natürlich sofort einsetzen, ja. ATI hat mir erzählt, dass der 3Dc-Support bei SeSam2 eine Sache weniger Stunden gewesen sei.
Gasttt
2004-05-12, 21:30:16
Original geschrieben von LovesuckZ
ehm welchen Einfluss hat AA/AF/Shadows/HDR/"post-processing" auf die Normalmaps?
:???:
Keine, es bedeutet nur das 3DC auch mit AA und AF etc. pepe zusammen bestens funktioniert.
Grüsse
Gasttt
2004-05-12, 21:32:29
Original geschrieben von aths
Sofern man die Shader etwas erweitert und das Kompressions-Tool hat, kann man 3Dc natürlich sofort einsetzen, ja. ATI hat mir erzählt, dass der 3Dc-Support bei SeSam2 eine Sache weniger Stunden gewesen sei.
Aths,
nein es werdern nur ein paar Shader benötigt!
Ausserdem wird der Speicherbus eher entlastet als belsatet das Bandbreite eingespart werden kann bzw. 100% wird!!!!!!!!
Demirug
2004-05-12, 21:32:42
Original geschrieben von Gasttt
Jetzt gehen wir mal ein Beispiel durch:
4x4 Operationen / Integer Data
Beispiel:
Uncompressed 32bpp normal map block!!!!!!!
- Jedes Element beinhaltet: 8bit (x, y & z Koordinaten)
für einen NORMALEN Vector !!
Enkodierung in Rot, Blau & Grün - Kanäle
Summe 512bits für einen Block
Da kommt dann satte Darstellung bei raus und bessere Details!!!!
4*4*3*8 sind aber nur 384 Bit pro Block. ;)
Man sollte nicht alles glauben was ATI im Zusammenhang mit 3dc so schreibt.
Gasttt
2004-05-12, 21:33:40
Das könnte zukünftlich gerade bei den 64_bit Karten ein sehr interessanter Aspekt werden da diese ja bekanntlich momentan sehr langsam laufen.
Aber was sage ich da!! Bis dahin müssen noch viele Kölsch runter!
Gasttt
2004-05-12, 21:38:27
Original geschrieben von Demirug
4*4*3*8 sind aber nur 384 Bit pro Block. ;)
Man sollte nicht alles glauben was ATI im Zusammenhang mit 3dc so schreibt.
Du brauchst Details, ich merke schon, aber okay.
Machen wir den Sendung mit der Maus Styl.
Ein Element besteht aus 8bit (zB. Rot X oder Grün Y)
Wieviele Elemnte haben wir denn bei meinem Beispiel?
8 * 8 = 64 * 8 = ????
Bingo 512!!!
Demirug
2004-05-12, 21:51:41
Original geschrieben von Gasttt
Du brauchst Details, ich merke schon, aber okay.
Machen wir den Sendung mit der Maus Styl.
Ein Element besteht aus 8bit (zB. Rot X oder Grün Y)
Wieviele Elemnte haben wir denn bei meinem Beispiel?
8 * 8 = 64 * 8 = ????
Bingo 512!!!
Falsch. Nur weil ATI die 512 Bit pro Block angibt um am Ende auf eine Kompression von 4:1 zu kommen stimmt es trotzdem nicht.
Es werden immer Blöcke mit 4*4 Normalen verarbeitet. Jede Normale besteht aus x,y und z. Für jedes dieser Elemente braucht man 8 Bit.
Ergo 4*4*3*8 = 384 Bit pro Block.
Da man bei 3dc aber vor der Kompression auch noch den Z Anteil der Normale entfernt ist der Block vor der Kompression nur 4*4*2*8 = 256 Bit gross. Nach der Kompression sind es dann noch 128 Bit.
Gastt
2004-05-12, 22:09:49
Original geschrieben von Demirug
Falsch. Nur weil ATI die 512 Bit pro Block angibt um am Ende auf eine Kompression von 4:1 zu kommen stimmt es trotzdem nicht.
Es werden immer Blöcke mit 4*4 Normalen verarbeitet. Jede Normale besteht aus x,y und z. Für jedes dieser Elemente braucht man 8 Bit.
Ergo 4*4*3*8 = 384 Bit pro Block.
Da man bei 3dc aber vor der Kompression auch noch den Z Anteil der Normale entfernt ist der Block vor der Kompression nur 4*4*2*8 = 256 Bit gross. Nach der Kompression sind es dann noch 128 Bit.
Du hast Lückenhafet Info's :
Es ist RICHTIG das ein Block aus 4 Elementen besteht, aber jewiels einmal 8 für Y und etc. pepe und wenn wir wir uns erinnern das eine Reihe auch 8 Blöcken besteht komme ich nicht auf 384Bit!
Möchtest du ein Schaubild qausi ein grafische Darstekkung als Beweis ????
Gasttt
2004-05-12, 22:12:47
4:1 Kompression = 128Bit Ausgangssituation = 4*128 = 512
Brillus
2004-05-12, 22:49:03
Maximal kann man von einer 3:1 Kompresion sprechen da das eine in keiner weise komprimiert wird sonder einfach(da umbraucherbar) weggeworfen wird. Ob man den Z-Kanal nun als komprienert ansehen soll ist ansichtssache. Zum einen ist er nun mal in den andern Werten enthalten zum andern aber nicht wegen 3Dc sondern weil er es einfach sein muss, aufgrund der Art wie sie zusamenhängen.
Demirug
2004-05-12, 22:54:09
Gasttt, meine Informationen sind keineswegs lückenhaft stammen sie doch direkt von ATI. Einmal über die Presseabteilung und einmal über den Devsupport.
Ich kenne auch das Schaubild mit dem ATI die 4:1 kompression "beweist". Es ist auch psychologisch sehr gut gemacht und ich habe vollstest Verständniss dafür wenn man es glaubt.
ATI rechnet dabei wie folgt:
Der Block besteht aus 4*4 XYZW Elementen. Jedes Element hat 8 Bit. Das ergibt dann 4*4*4 (für XYZW) * 8 Bit = 512 Bit.
Nach der Kompression hat man nun:
X-Min 8 Bit
X-Max 8 Bit
Y-Min 8 Bit
Y-Max 8 Bit
X-Factor 3 Bit pro Blockelement = 48 Bit für den ganzen 4*4 Block
Y-Factor 3 Bit pro Blockelement = 48 Bit für den ganzen 4*4 Block
Macht zusammen 8+8+8+8+48+48 = 128 Bit
512:128 = 4:1 und ATI ist glücklich das sie die gleiche Kompressionrate wie DXTC bei weniger Verlust erreichen wie man dann auch gleich auf einer anderen Folie demonstriert.
So weit so gut doch die Tatsachen sehen aber anders aus.
Die Grundidee hinter 3dc ist das man sich bestimmte Eigenschaften einer Normalmap zu nutzen macht:
1. Der W Kanal einer Normalmap wird in der Regel beim Pixelshading nicht benutzt.
2. Der Z Kanal entspricht normalerweise dem Ergebniss der Formel sqrt (1-x*x-y*y)
Ausgerüstet mit diesen Erkenntnisse stelt man nun ein Verfahren vor das es erlaubt Bumpmapping mit einer 2 Komponeten (XY) Normalmap zu rendern. Gleichzeitig hat man auch ein neues Texturformat (3Dc) das es erlaubt genau solche 2 Komponeten Normalmaps zu komprimieren.
Wenn die Normalmap aber jetzt nur noch zwei Komponenten hat stimmt die bisherige Rechnung nicht mehr. Das Ausgangsmaterial hat jetzt nur noch 4*4*2 (nur noch X und Y) * 8 Bit = 256 Bit.
Da der komprimierte Block aber immer noch 128 Bit hat ergibt sich eine Kompresion von 256:128 = 2:1
ATI hat schlicht und ergreifend den Speicherplatz und Bandbreitengewinn den man durch das Bumpmapping verfahren mit einer 2 Komponenten Normalmap erreicht 3Dc zugeschrieben. Mit der echten 2:1 Kompression die 3Dc zu leisten im standen ist ergibt sich dadurch eine virtuelle 4:1 Ersparniss. Dumm dabei ist nur das man das entsprechenden Bumpmapping verfahren auch völlig unabhängig von 3dc nutzen kann. Alles was man dazu braucht ist ein PS 2.0 fähiger Chip. Deswegen ist sogar davon auszugehen das wenn sich ein Entwickler die Mühe macht seine Shader auf das entsprechende Verfahren umzuprogrammieren diese dann auf allen PS 2.0 fähigen Chips nutzt. Dadurch ist der reale Vorteil von 3dc eben nur noch eine Ersparniss von 2:1 gegenüber einem Chip welcher 3dc nicht unterstützt.
Original geschrieben von Gastt
Du hast Lückenhafet Info's :Ich hoffe, alle Infos im Artikel zu haben:
Etwas seltsam mutet uns an, wie ATI auf die Komprimierungsrate von 4:1 kommt. Eine Kachel von 4 x 4 = 16 Werten wird mit 3Dc auf 16 Byte komprimiert. Eine Normal Map muss nicht zwingend Alpha speichernn, und kostet pro 16 Werten dann 48 Byte. Das tatsächliche Ratio wäre demnach 3:1. Da man den Trick mit der Rekonstruierung von Z auch unabhängig von 3Dc nutzen kann, reduziert sich die effektive Komprimierung auf 2:1. DirectX definiert jedenfalls Zwei-Kanal-Texturformate, die für Normalen genutzt werden können. (von http://www.3dcenter.org/artikel/r420_technik/)
edit: Demirug war nicht nur schneller :devil: sondern auch viel ausführlicher. Dank Demirugs Posting dürfte es nun jeder verstanden haben :)
Gasttt
2004-05-12, 23:32:40
Original geschrieben von aths
Ich hoffe, alle Infos im Artikel zu haben:
Etwas seltsam mutet uns an, wie ATI auf die Komprimierungsrate von 4:1 kommt. Eine Kachel von 4 x 4 = 16 Werten wird mit 3Dc auf 16 Byte komprimiert. Eine Normal Map muss nicht zwingend Alpha speichernn, und kostet pro 16 Werten dann 48 Byte. Das tatsächliche Ratio wäre demnach 3:1. Da man den Trick mit der Rekonstruierung von Z auch unabhängig von 3Dc nutzen kann, reduziert sich die effektive Komprimierung auf 2:1. DirectX definiert jedenfalls Zwei-Kanal-Texturformate, die für Normalen genutzt werden können. (von http://www.3dcenter.org/artikel/r420_technik/)
edit: Demirug war nicht nur schneller :devil: sondern auch viel ausführlicher. Dank Demirugs Posting dürfte es nun jeder verstanden haben :)
Leider NEIN,
da es mathematisch falsch ist !!!!
Leute 8*8 = 64
4:1 bei 128 = 512bit
Original geschrieben von Gasttt
Leider NEIN,
da es mathematisch falsch ist !!!!
Leute 8*8 = 64
4:1 bei 128 = 512bit Was ist wo falsch?
ATI sagt richtigerweise, dass eine Kachel von 4x4 = 16 Werten mit 3Dc nur 128 Bit einnimmt. Würde 3Dc 4:1 komprimieren, wäre die entpackte Kachel 512 Bit groß. Man kann die mit 3Dc komprimierte Information aber auch (völlig verlustfrei) in 256 Bit speichern. Demzufolge liegt 2:1-Komprimierung vor.
Crushinator
2004-05-12, 23:55:33
Original geschrieben von Demirug
(...) ATI hat schlicht und ergreifend den Speicherplatz und Bandbreitengewinn den man durch das Bumpmapping verfahren mit einer 2 Komponenten Normalmap erreicht 3Dc zugeschrieben. Mit der echten 2:1 Kompression die 3Dc zu leisten im standen ist ergibt sich dadurch eine virtuelle 4:1 Ersparniss. Dumm dabei ist nur das man das entsprechenden Bumpmapping verfahren auch völlig unabhängig von 3dc nutzen kann. Alles was man dazu braucht ist ein PS 2.0 fähiger Chip. Deswegen ist sogar davon auszugehen das wenn sich ein Entwickler die Mühe macht seine Shader auf das entsprechende Verfahren umzuprogrammieren diese dann auf allen PS 2.0 fähigen Chips nutzt. Dadurch ist der reale Vorteil von 3dc eben nur noch eine Ersparniss von 2:1 gegenüber einem Chip welcher 3dc nicht unterstützt.
a) Klasse Erklärung :up:
b) Frage dazu: Wäre es dann richtig, wenn man daraus schließen würde, daß ein Nicht-3Dc-unterstützender Chip die Normalmap durch die Rekonstruktion der W- und Z-Werte per geschriebenem Shader zwar auch 2:1 komprimiert bekommt, dafür aber länger braucht als ein Chip, der die gesamte 3DC-Geschichte "hardwareverdrahtet" durchführt?
Gasttt
2004-05-12, 23:59:09
Original geschrieben von aths
Was ist wo falsch?
ATI sagt richtigerweise, dass eine Kachel von 4x4 = 16 Werten mit 3Dc nur 128 Bit einnimmt. Würde 3Dc 4:1 komprimieren, wäre die entpackte Kachel 512 Bit groß. Man kann die mit 3Dc komprimierte Information aber auch (völlig verlustfrei) in 256 Bit speichern. Demzufolge liegt 2:1-Komprimierung vor.
Ja wunderbar, wir sind auf einer Linie, 128 BIIIIIIIIITTTT
4:1 ist auch RICHTIG !!!
Die entpacckte Kachel ist tatsächlich 51Bit groß
wir habens, das stimmt doch zuträflich!!
Aber dein demzufolge ist unlogisch und ergibt keinen Sinn da wir immer bei 3DC eine 4:1 Konpression zugrunde legen aufgrund der def. von 3DC!!!!!!
Mit 2:1 würde der Bildunterschied minimal sein!!!!
Demirug
2004-05-13, 00:13:04
Original geschrieben von Gasttt
Ja wunderbar, wir sind auf einer Linie, 128 BIIIIIIIIITTTT
4:1 ist auch RICHTIG !!!
Die entpacckte Kachel ist tatsächlich 51Bit groß
wir habens, das stimmt doch zuträflich!!
Aber dein demzufolge ist unlogisch und ergibt keinen Sinn da wir immer bei 3DC eine 4:1 Konpression zugrunde legen aufgrund der def. von 3DC!!!!!!
Mit 2:1 würde der Bildunterschied minimal sein!!!!
Die entpackte Kachel ist nur 256 Bit gross weil sie nur eine X sowie eine Y Komponete enthält. Um auf 512 Bit zu kommen müsste da auch noch eine Z und W Komponete sein.
Und wer ist eigentlich "wir"? Ich lege bei 3dc eine 2:1 Kompression zugrunden weil aufgrund des technischen Verfahrens eben genau auf 50% durch das 3dc Texturformat reduziert wird.
Demirug
2004-05-13, 00:21:00
Original geschrieben von crushinator
a) Klasse Erklärung :up:
b) Frage dazu: Wäre es dann richtig, wenn man daraus schließen würde, daß ein Nicht-3Dc-unterstützender Chip die Normalmap durch die Rekonstruktion der W- und Z-Werte per geschriebenem Shader zwar auch 2:1 komprimiert bekommt, dafür aber länger braucht als ein Chip, der die gesamte 3DC-Geschichte "hardwareverdrahtet" durchführt?
Ein nicht 3dc Chip komprimiert die Normalmap ja überhaupt nicht. Er würde einfach eine unkomprimierte Textur mit 2 Elementen benutzten. Die braucht nur 50% des Speicherplatzes und der Bandbreite gegenüber einer "normalen" XYZW Textur. Das ist aber wie gesagt keine Kompression.
Ein 3dc fähiger Chip komprimiert diese Textur dann auf die Hälfte.
Der W Wert wird nicht rekonstruiert. Z muss jeder Chip im Pixelshader rekonstruieren. Die Z Rekonstruktion wird also nicht bei der Dekomprimierung mit erledigt sondern ist ein eigenständiger Arbeitsschritt. Wie schnell das geht hängt vom jeweiligen Pixelprozessor ab.
Der einzige unterschied zwischen einem Chip mit 3dc Unterstützung und einem ohne wäre also das der Chip mit 3dc Unterstützung nur 50% der Bandbreite und des Speicherplatzes für die Normalmap braucht.
q ohne Keks
2004-05-13, 00:25:06
Original geschrieben von Gasttt
Aber dein demzufolge ist unlogisch und ergibt keinen Sinn da wir immer bei 3DC eine 4:1 Konpression zugrunde legen aufgrund der def. von 3DC!
Wäre dir wohler, wenn man 3dc mit 4:1-Compression beschreibt, bei der die eine Hälfte der ursprünglichen Information weggelassen wird und die andere Hälfte um 50% komprimiert?
ShadowXX
2004-05-13, 08:15:23
Original geschrieben von q ohne Keks
Wäre dir wohler, wenn man 3dc mit 4:1-Compression beschreibt, bei der die eine Hälfte der ursprünglichen Information weggelassen wird und die andere Hälfte um 50% komprimiert?
Das ist wohl die "schnellversion" von Demis Erklärung *g*
@Demi: super Erklärung, jetzt müssten es alle verstanden haben (unter anderem auch ich)
Man kann das Verfahren also zumindetest Teilweise (den Shaderanteil) auf allen mind. PS2.0 fähigen Chips einsetzen....
Dann könnte sich 3Dc tatsächlich etwas schneller durchsetzen, als ich erwartet habe...
Wie wahrscheinlich ist es, das nV dies für den Refresh des nv40 mit einbaut??? (kann wohl keiner Beantworten, oder??)
Es sind ja nur kleine Änderungen an der DXTC-Einheit notwendig...
Quasar
2004-05-13, 09:35:19
Klar funktioniert weglassen auch ohne 3dc. "Weglassen" ist m.W. noch nichtmal patentiert... X-D
Trotzdem kommt man am Ende auf eine viermal geringere Datenmenge...
:gruebel:
(Vielleicht sollte ich mir eine neue Kompression patentieren lassen, bei der ich einfach ALLE Kanäle weglasse und sie hinterher aus Random-Noise zufällig regeneriere? Das wäre doch mal ein toller Kompressionfaktor und der durchschnittliche Fehler ist immerhin nicht 100% ;) )
ShadowXX
2004-05-13, 11:02:19
Original geschrieben von ow
Schlechtere Bildqualitaet bei einem nur 2:1 Kompressionsverhaeltnis stellen fuer mich keine wegweisende Neuerung dar. Die Zukunft wird zeigen wie es mit 3DC weitergeht.
Durchsetzen war das falsche Wort...
Ich meinte mehr, dass es dadurch eher mal benutzt werden wird...
Crushinator
2004-05-13, 11:22:43
Original geschrieben von Demirug
(...) Der W Wert wird nicht rekonstruiert. Z muss jeder Chip im Pixelshader rekonstruieren. Die Z Rekonstruktion wird also nicht bei der Dekomprimierung mit erledigt sondern ist ein eigenständiger Arbeitsschritt. Wie schnell das geht hängt vom jeweiligen Pixelprozessor ab. (...) Ja, ich hab' mich unglücklich formuliert. Ich meinte auch "Rek. der Z.." und "weglassen der W-Werte". Jetzt noch 'ne präzisere Frage zu meinem besseren Verständnis: Müssen die Z-Werte bei 3DC auch in einem selbstgeschriebenen Shader rekonstruiert werden, oder macht es der Chip selbst (sei's auch durch den selben Pixelprozessor) sobald man 3DC-Texturen verwendet?
Crushinator
2004-05-13, 12:25:28
Danke Euch allen,
mir fiel eben erst ein, daß Lesen schlau macht. ;D Wenn man das Whitepaper (http://mirror.ati.com/products/radeonx800/3DcWhitePaper.pdf) dazu liest, werden alle Fragen dazu von allein beantwortet:
How 3Dc Works
3Dc is a block-based compression technique. It breaks a texture map up into 4x4 blocks containing 16 values each. These values must consist of two components. Each component is compressed separately. A maximum and minimum value is determined for each block, and these are stored as 8-bit values. A set of six intermediate values are then calculated, spaced equally between the minimum and the maximum. This gives a total of eight values that each component can take within a block.
Each component is assigned a 3-bit index corresponding to whichever of these values is closest to its original value. The resulting compressed blocks consist of four 8-bit values and thirty-two 3-bit values, for a total of 128 bits. Since the original blocks consisted of sixteen 32-bit values, for a total of 512 bits, this represents a compression ratio of 4:1. If the original values were 16-bit rather than 32-bit, then a compression ratio of 2:1 can still be achieved.
Using 3Dc to compress normal maps requires an additional step. This is because each value in a normal map is actually a 3D vector, consisting of 3 components (x, y & z). These values must be reduced to 2-component values in order to work with 3Dc. Fortunately, this can be handled in a simple way by assuming that all of the normal vectors have a length of 1. Given the values of two components of a vector, the value of the third component can be found using the following mathematical relationship: z = sqrt (1 - (X² + Y²)). This formula can be implemented using just a couple of pixel shader instructions.
MadMan2k
2004-05-16, 16:10:31
gibts eigentlich schon ne neue Version des Wrappers mit mehr Effekten für den R300?
Mr. Lolman
2004-05-16, 16:43:40
Original geschrieben von MadMan2k
gibts eigentlich schon ne neue Version des Wrappers mit mehr Effekten für den R300?
Nö, soll aber angeblich dieses WE erscheinen...
misterh
2004-05-16, 17:57:39
Sieht doch gut aus unter 5900XT und LOD auf -15 (per Riva Tuner)
misterh
2004-05-16, 17:58:33
sry doppel post
misterh
2004-05-16, 17:59:33
hier noch eins :D
misterh
2004-05-16, 18:07:21
da
misterh
2004-05-16, 22:50:57
hier weitere :D
http://www.forumdeluxx.de/gallery/data/500/8671SushiDX3.JPG
http://www.forumdeluxx.de/gallery/data/500/8671SushiDX4.JPG
http://www.forumdeluxx.de/gallery/data/500/8671SushiDX5.JPG
http://www.forumdeluxx.de/gallery/data/500/8671SushiDX6.JPG
http://www.forumdeluxx.de/gallery/data/500/8671SushiDX7.JPG
MadManniMan
2004-05-16, 23:46:02
Auch auf der FX wirds falsch gerendert :|
Original geschrieben von Gasttt
Ja wunderbar, wir sind auf einer Linie, 128 BIIIIIIIIITTTT
4:1 ist auch RICHTIG !!!
Die entpacckte Kachel ist tatsächlich 51Bit großNein, 256 Bit, nämlich 16 Werte mit je X und Y in 8 Bit. 16*2*8 = 256.
Weitere 128 Bit werden im Pixelshader rekonstruiert. Das mit der Rekonstruierung geht auch ohne 3Dc.
neue Version des Wrappers:
http://www.users.on.net/triforce/ruby/r300rubyrap2.zip
InsaneDruid
2004-05-17, 20:36:42
Yeah.. sieht coool aus.
LovesuckZ
2004-05-17, 20:37:13
Wie groß ist der Leistungsverlust?
InsaneDruid
2004-05-17, 20:56:49
um die 50%:
Fraps auf ner 9800pro 128MB, 2100MHz Athlon XP, 1024*768, FSAA OFF.
Neuer Wrapper:
2004-05-17 20:46:29 - SushiDX
Frames: 1651 - Time: 101026ms - Avg: 16.342 - Min: 10 - Max: 40
Alter Wrapper:
2004-05-17 20:51:50 - SushiDX
Frames: 3418 - Time: 101324ms - Avg: 33.733 - Min: 19 - Max: 101
InsaneDruid
2004-05-17, 21:04:14
Das Ganze in 640, da fällts nicht ganz so extrem aus:
Neu:
2004-05-17 20:59:27 - SushiDX
Frames: 2459 - Time: 101217ms - Avg: 24.294 - Min: 13 - Max: 131
Alt:
2004-05-17 21:02:03 - SushiDX
Frames: 4560 - Time: 101049ms - Avg: 45.127 - Min: 25 - Max: 148
deekey777
2004-05-17, 22:52:56
Hm, ich hab den neuen ausprobiert. Unglücklicherweise habe ich vorher die AGP Aperture Size auf 32 MB heruntergesetzt. Die Ruby Demo "startete" mit einer Fehlermeldung. Da die Sushi Engine sehr empfindlich ist, will jetzt gar keine Sushi-Demo starten. :...(
[dzp]Viper
2004-05-17, 23:02:57
Also bei mir lief sie mit dem neuen Wrapper durch - ohne probleme und sieht sehr sehr gut aus - kann fast keinen unterschied zu den screens der x800er sehen :D
Iceman346
2004-05-17, 23:33:04
Original geschrieben von [dzp]Viper
Also bei mir lief sie mit dem neuen Wrapper durch - ohne probleme und sieht sehr sehr gut aus - kann fast keinen unterschied zu den screens der x800er sehen :D
Wobei ich meine am Anfang als man Rubys Gesicht von vorne sieht um im Hintergrund dieser Zeppelin oder so ist leichtes Banding auf dem Zeppelin zu erkennen.
Aber ansonsten sieht das Ding sehr schön aus, läuft nur etwas rucklig *gg*
ShadowXX
2004-05-18, 08:01:52
Hmmm...bis auf zwei stellen (da limitiert aber wohl eher, dass ich zu faul war den AGP-Size von 128 auf 256 zu stellen) läuft es bei mir relativ smooth...
Auf 640x480 ohne AA/AF wohlgemerkt...(9800Pro@420/340)
Mr. Lolman
2004-05-18, 13:02:33
Original geschrieben von ShadowXX
Hmmm...bis auf zwei stellen (da limitiert aber wohl eher, dass ich zu faul war den AGP-Size von 128 auf 256 zu stellen) läuft es bei mir relativ smooth...
Auf 640x480 ohne AA/AF wohlgemerkt...(9800Pro@420/340)
Du kannst 4xAA fast ohne Leistungsverlust dazuschalten.
Auf 800x600 mit 4xAA 4xpAF ists von der Performance gerade noch ertragbar. Ca. 20fps erreicht meine Karte mit den Einstellungen durchschnittlich...
InsaneDruid
2004-05-18, 14:08:23
Stimmt, FSAA ist fast "for free", und sieht mit 4x einfach nur hammermäßig aus.
qman1
2004-05-19, 23:20:48
gibt ne neue version von gestern! :)
http://www.users.on.net/triforce/ruby/
dildo4u
2004-05-19, 23:43:57
http://people.freenet.de/Dildo4u/RubyR300.JPG
Ruby Demo mit dem neuste wapper mit allen effekten der R420
auf meiner 9700pro ohne oc mit 1024*768mit 4XAA und 8XAniso
BvB123
2004-08-25, 13:52:18
Läuft das auch auf nem NV40?
Gruß
DrumDub
2004-08-25, 14:46:21
Läuft das auch auf nem NV40?
Gruß
mit diesem wrapper auf jeden fall:
http://www.users.on.net/~triforce/ruby/NV3xRuby.zip
obs auch ohen wrapper geht, weiß ich nicht.
BvB123
2004-08-25, 17:33:22
Läuft nicht :(
Musst doch nur die sachen in den ordner kopieren oder?
Gibt schwarzen Bildschirm und ende
Gruß
Darkman.X
2004-08-25, 18:22:31
Kann ich bestätigen, ich hab die Ruby Demo v1.0 und 1.2 zusammen mit dem NV3x-Warpper benutzt. Mit meiner GF6800U + v61.77-Treiber kommt immer ein schwarzes Bild und ein paar Fehlermeldungen mit Vertex-blabla, man hört nur den Sound. Beim Beenden wird eine TXT-Datei mit vielen Fehlermeldungen wegen falscher Pixelshader-Version usw. geöffnet.
betasilie
2004-08-25, 20:41:56
Ich will auch nen Wrapper für meine 6800er. ;( Da muss es doch was geben.
BvB123
2004-08-25, 21:08:24
Kann ich bestätigen, ich hab die Ruby Demo v1.0 und 1.2 zusammen mit dem NV3x-Warpper benutzt. Mit meiner GF6800U + v61.77-Treiber kommt immer ein schwarzes Bild und ein paar Fehlermeldungen mit Vertex-blabla, man hört nur den Sound. Beim Beenden wird eine TXT-Datei mit vielen Fehlermeldungen wegen falscher Pixelshader-Version usw. geöffnet.
Genau das habe ich auch
Gruß
Darkman.X
2004-08-25, 22:28:34
So, ich hab es gerade mit 3DAnalyze getestet. Damit funktioniert es. Hammer, wie gut die Demo läuft. Ich hatte sie mal mit einer GF5900U gesehen, das war noch eine DIA-Show, aber mit meiner 6800U einigermaßen flüssig :)
BvB123
2004-08-25, 22:58:30
Also ich habe ruby von ati runtergeladen. mit 3danalize exe rausgesucht nv40 fix und run Bildschrim bleibt Schwarz wie machst du das denn?
Gruß
Darkman.X
2004-08-25, 23:13:57
Du brauchst eine 256MB-Grafikkarte + 256MB AGP Aperture Size (vielleicht reichen auch 128MB, meine eingestellten 64MB waren zu wenig), wegen den 3Dc-Texturen. Danach...
1. 3DAnalyze starten
2. Button "Select" anklicken
3. Die EXE-Datei von der Demo auswählen.
4. "NV40-Fix for R420-Demos" (oder so ähnlich) auswählen.
5. Button "Run" anklicken und glücklich werden :)
Ich hab das ganze nur mit der Rube-Demo v1.0 ausprobiert, einen Link gibt es ziemlich weit am Anfang diesen Threads. Ob es auch mit v1.2 (aktuell auf der ATI-Seite) funktioniert, weiß ich nicht.
EDIT: Mit der 1.2er Demo funktioniert es auch.
BvB123
2004-08-25, 23:26:29
Hi
habs so gemacht wie beschrieben Bildschrim bleibt schwarz :(
Habe 1024MB ram
Gruß
Darkman.X
2004-08-25, 23:30:07
hmm.....dann weiß ich auch nicht weiter, vielleicht kann dir irgendein 3D-Guru weiterhelfen.
Noch ein paar Infos:
WinXP + SP2
DirectX 9.0c (ich weiß gar nicht, ob die Demo mit OpenGL oder DirectX läuft)
ForceWare v61.77
3D-Analyze v2.34
BvB123
2004-08-25, 23:31:40
Hmm hab den 66.00 Drauf werde mal testen ob es daran liegt
Gruß
ShadowXX
2004-08-26, 08:08:13
Du brauchst eine 256MB-Grafikkarte + 256MB AGP Aperture Size (vielleicht reichen auch 128MB, meine eingestellten 64MB waren zu wenig), wegen den 3Dc-Texturen. Danach...
1. 3DAnalyze starten
2. Button "Select" anklicken
3. Die EXE-Datei von der Demo auswählen.
4. "NV40-Fix for R420-Demos" (oder so ähnlich) auswählen.
5. Button "Run" anklicken und glücklich werden :)
Ich hab das ganze nur mit der Rube-Demo v1.0 ausprobiert, einen Link gibt es ziemlich weit am Anfang diesen Threads. Ob es auch mit v1.2 (aktuell auf der ATI-Seite) funktioniert, weiß ich nicht.
EDIT: Mit der 1.2er Demo funktioniert es auch.
Dito...ich kann bestätigen, das es so läuft (wie du ebenfalls schon anmerktest, auch mit der V1.2).
System ist:
WinXP SP1 + DX90c, 61.77 Treiber, Analyse 2.34, 1GB Ram, GF68Ultra....
Läuft übrigens Butterweich mit den Standardeinstellungen der Demo (1024x768 + 4xAA + 8xAF (AA per App, AF per CP)).
Werds heute abend mal durch den Rubybench laufen lassen....aber es lief wirklich sehr geschmeidig (und da ich V-Sync aus hatte, konnte ich auch sehen das es mehr als 60FPS waren (Tearing sichtbar, TFT mit 60Hz))
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.