PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Ruby Wrapper ist da


Seiten : [1] 2

Radeonfreak
2004-05-07, 16:02:31
Sieht zwar nicht so toll aus aber es läuft....

eine von beiden DX9.dll aus den Zips in den Demo Ordner kopieren...

http://www.users.on.net/triforce/ruby/

funktioniert auch mit der Subsurface DEMO

Scoty
2004-05-07, 16:25:55
habe ich auch schon gepostet gehabt aber egal. mit meiner 9800 Pro läuft es aber extrem langsam und es fehlen einige Texturen.

Radeonfreak
2004-05-07, 16:29:49
das mit deinem Post hab ich erst hinterher gesehen...


Langsam läufts...schätze mal 3-5 fps auf meiner 9700pro aber die Subsurface Demo scheint qualitativ
völlig in Ordnung zu sein...wie kommt das ??

BUG
2004-05-07, 17:58:42
..auf meiner FX5900 läuft Ruby nich. :(


[AwFn.cpp] (line 3402): D3DAw Error: AwCreateRenderableTexture - Unable to create color texture object
[StartEnd.cpp] (line 2044): Error creating color buffer "cBlurPingBuffer"!
[Main.cpp] (line 880): Normal Application Exit

Edit:
...die SubSurface Demo läuft, aber nur mit ein paar Grafikfehlern und einigen Error Medlungen.

http://home.arcor.de/xbugx/Download/nvidia/sushi_nv01.jpg

cu
BUG

betasilie
2004-05-07, 18:27:03
Also die Rubywrapper sind ja schonmal ein Anfang. Wenn man beide Wrapper kombnieren könnte ware es schon richtig nett. :)

Flüssig läufts jedenfalls.

MegaManX4
2004-05-07, 18:52:41
Kennt irgendwer 'nen Mirror für die Subsurface Scattering Demo? Irgendwie ist bei ATI.com nix zu holen.

4Fighting
2004-05-07, 18:54:22
http://www2.ati.com/misc/demos/ATI-X800-Subsurface-Demo-v1.0.exe

hier die andere demo


http://www2.ati.com/misc/demos/ATI-X800-DoubleCross-Demo-v1.0.exe

Mr. Lolman
2004-05-07, 19:08:04
Bei mir funktioniert die Someruby dll mit der Doublecross Demo überhaupt nicht, und bei Subsurface Scattering gibts anfangs ein paar Fehlermeldungen, wie bei Bugs Screenshot.

Nur mit der Wrongruby.dll ring ich die Rubydemo zum laufen, und die sogar ziemlich flüssig, wahrscheinlich aber nur, weil noch diverse Shader fehlen. Ob bei der subsurface Demo Shader fehlen, weiss ich nicht, auf jedenfall siehts goil aus:

http://img32.photobucket.com/albums/v95/franz/SushiDX-2004-05-07-18-48-23.jpg

http://img32.photobucket.com/albums/v95/franz/SushiDX-2004-05-07-18-48-55.jpg

Quasar
2004-05-07, 19:10:50
SomeRuby soll für die nV3x sein, allerdings dort wohl ziemlich lahm. :D
WrongRuby ist für ATiler mit ATis.

betasilie
2004-05-07, 19:12:48
Original geschrieben von Quasar
SomeRuby soll für die nV3x sein, allerdings dort wohl ziemlich lahm. :D
WrongRuby ist für ATiler mit ATis.
Also bei mir gehen beide und beide stellen unterschiedlich Sachen dar.

Quasar
2004-05-07, 19:25:33
Ja, weil Colourless die 2.b-Shader wohl auseinanderpfriemeln musste.

MegaManX4
2004-05-07, 19:28:07
Original geschrieben von 4Fighting
http://www2.ati.com/misc/demos/ATI-X800-Subsurface-Demo-v1.0.exe

hier die andere demo


http://www2.ati.com/misc/demos/ATI-X800-DoubleCross-Demo-v1.0.exe


Dank Dir. Irgendwie hab ich Probleme mit deren Java Aplett. So gehts aber:).

R300
2004-05-07, 20:18:29
Bei mir laufen beide Demos ohne Grafikfehler.
Ruby ruckelt nur an ein paar wenigen stellen.
Sonst läufts flüssig.
Und das mit meiner 1,5 Jahre alten Radeon 9700Pro!

InsaneDruid
2004-05-07, 20:37:37
Laufen hier auch recht ok.. Subsurface sieht einfach nur genial aus.. wirklich cool.

anorakker
2004-05-07, 20:42:24
Original geschrieben von R300
Bei mir laufen beide Demos ohne Grafikfehler.
Ruby ruckelt nur an ein paar wenigen stellen.
Sonst läufts flüssig.
Und das mit meiner 1,5 Jahre alten Radeon 9700Pro!

dafür fehlen auch die interessanten effekte...

R300
2004-05-07, 21:03:25
Welche denn?

So sieht das bei mir aus: http://r300.funpic.de/ruby.htm

MegaManX4
2004-05-07, 21:18:52
Original geschrieben von R300
Welche denn?

So sieht das bei mir aus: http://r300.funpic.de/ruby.htm

Bei mir siehts ganz anders aus. Ich hab eher so einen Metal Effekt auf Rubys Haut.

Mr. Lolman
2004-05-07, 21:23:55
Original geschrieben von R300
Welche denn?

So sieht das bei mir aus: http://r300.funpic.de/ruby.htm
Welche dll, DirectX Version, und welchen Catalyst verwendest du?

edit: Bei mir hat Ruby blaue Haare, die manchmal richtig leuchten ;D

cfg
2004-05-07, 22:33:55
Die AGP Aperture Size hat bei mir ausserordentlich viel Einfluss auf die Performance. Mit 256 MB hab ich doppelt soviel fps als bei 128 MB. Merkt man vor allem am Anfang.

GraKa: Radeon 9800 PRO

Radeonfreak
2004-05-07, 22:35:37
Ok es gibt eine überarbeitete Version mit der Ruby jetzt Normal aussieht weil die Shader gegen eine R300 version getauscht wurden.

http://www.users.on.net/triforce/ruby/r300rubyrap.zip

Dr.Dirt
2004-05-07, 22:54:06
Bei mir bricht das LAden mit folgender Fehlermeldung (Error.txt) ab:

//=====================================================
// ATI Sushi Error Log Created 5/7/2004 10:53 pm
//=====================================================
[Main.cpp] (line 894): Exception caught - BAD NEWS!

EDIT:
Die Fehlermeldung kam mit Catalyst 4.3, mit 4.4 läuft's.

deekey777
2004-05-07, 23:10:55
Original geschrieben von cfg
Die AGP Aperture Size hat bei mir ausserordentlich viel Einfluss auf die Performance. Mit 256 MB hab ich doppelt soviel fps als bei 128 MB. Merkt man vor allem am Anfang.

GraKa: Radeon 9800 PRO

Bei mir führte die Verdopplung der AGP Aperture Grösse zum gleichen Effekt. Danke für den Tip.
(9800 Pro)

Bakunin3
2004-05-07, 23:44:44
Hey das klappt ja prima: Bei mir sind auch alle Texturen vorhanden... und zum Teil läuft es halbwegs flüssig. Aber dazwischen stockt es ganz unglaublich, um dann wieder flüssig weiterzulaufen.
Sieht ganz cool aus... ;)

B3

Mr. Lolman
2004-05-08, 00:49:53
Original geschrieben von Bakunin3
Hey das klappt ja prima: Bei mir sind auch alle Texturen vorhanden... und zum Teil läuft es halbwegs flüssig. Aber dazwischen stockt es ganz unglaublich, um dann wieder flüssig weiterzulaufen.
Sieht ganz cool aus... ;)

B3

Hast du auch AGP Aparture size auf 256MB? Bei mir läufts eigentlich immer ziemlich gleichmässig 'flott':


Fraps2.0:
Time: 101187ms - Avg: 26.050 - Min: 13 - Max: 79


(von Anfang bis zum ATi Logo, in 1024x768, 4xAA/4xpAF)

Korak
2004-05-08, 02:36:52
:up: nett :D

Ruckelt zwar alles, sieht aber dafür fast fehlerfrei aus (die Schatten in der Ruby-Demo sind imo etwas *zerfranselt*)

Jetzt das ganze noch ver 100fachen und wir haben ein klasse Game ;D

AlfredENeumann
2004-05-08, 03:16:16
Hey das mit der Aperdingsbums Size bringt tatsächlich so einiges.

r00t
2004-05-08, 09:06:01
bin mal gspannt wies bei mir @ 9700pro läuft ^^


und nächste woche mal @ amd 2300mhz testn

*gespanntsei*

Akira20
2004-05-08, 10:10:00
Hallo,

auf meiner 9700 n/p @ 345/300 läuft die Demo in 800x600 fast perfekt, nur am Ende ruckelts etwas.

Ich bin echt überrascht, was die 9700 noch leisten kann.

MfG
Akira20

Hartogh
2004-05-08, 11:11:49
Bei mir läuft die ruby demo auf einer 9800 pro selbst in 640x480 total kacke. AGP dingens steht auf 256, trotzdem leuchtet meine Festplatte konstant über die ganze länge der Demo, da wird ständig gecached :(

R300
2004-05-08, 11:27:01
Wieviel Ram hast du?

Hartogh
2004-05-08, 12:36:47
Original geschrieben von R300
Wieviel Ram hast du?

512Mb

ironMonkey
2004-05-08, 12:44:12
Les mal die Readme, min 512mb aber damits gut läöuft sollten es min 768mb Ram sein und am besten auch ne 256mb Karte.


Gruß

[MK2]Mythos
2004-05-08, 12:46:33
Wenn du dann noch die AGP Size auf 256 MB stellst und sich damit die Graka auch noch 256 MB von deinem Hauptspeicher reserviert ist das klar das sich die Demo aufgrund von ständigem Nachladen von Festplatte einen abruckelt.

Bakunin3
2004-05-08, 12:50:25
Original geschrieben von Mr. Lolman
Hast du auch AGP Aparture size auf 256MB? Bei mir läufts eigentlich immer ziemlich gleichmässig 'flott':

...in 1024x768, 4xAA/2xpAF)

Wow! Mit der Aperture Size auf 256MB bringt tatsächlich irre viel. Dann noch der große Speicher (1024MB) und auch bei mir läuft es jetzt durchgehend flüssig!

Sieht auch - m.E. - absolut korrekt dargestellt aus.

Und das Schönste: Die 9800SE, die mit freigeschalteten Pipelines bspw. in FarCry doch einige Grafikfehler (kein Schachbrett, aber hier und da Pixelfehler) macht, stellt das Ganze absolut fehlerfrei dar (so wie eigentlich die meisten Spiele).
War vielleicht doch kein Fehler, die zu behalten. :)

B3

PS: Lolman, wie hast Du denn gemessen. Hat FRAPS eine Benchmarkfunktion?

r@h
2004-05-08, 12:55:19
Hi folks !

Möget Ihr Euch bitte mal folgenden Thread auf B3D anschaun':
http://www.beyond3d.com/forum/viewtopic.php?t=12141&start=14

Da gibt's folgende ZIP's von Colourless, die Ihr Euch mal anschaun' solltet:

- für NV3x: NV3xRuby (http://www.users.on.net/triforce/ruby/NV3xRuby.zip)
- Für R3x00: r300rubyrap (http://www.users.on.net/triforce/ruby/r300rubyrap.zip)

Einfach die Dateien ins Zeilverzeichnis entpacken und gut !

Ruby, at it's best !
(na ja... fast ;-)

Bei ATI-Karten mussten Shader ersetzt werden, weil diese die vielen Instruktionen pro Shader nicht abkönnen, bei nVidia hingegen ein paar Skripte.

Thx @ Colourless !
:up:

Razor

P.S.: Ach ja, die originale Demo von ATI braucht Ihr dafür natürlich.

P.P.S.: Der 3DA läuft damit leider nicht, da dies über einen D3D9-Wrapper realisiert wird... :-(

P.P.P.S.: Läuft dank der ersetzten Shader auf ATI-Karten wesentlich besser, als auf den nVidia's... wenn auch dafür einige Effekte fehlen. Und 'laufen' heißt auch bei den NV35 gerade mal 3fps... dafür aber in 10x7 mit 2xAA... ;)

dildo4u
2004-05-08, 12:58:32
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=141476

r@h
2004-05-08, 13:00:05
Hier mal ein Bilchen von Ante P, der gerade ein paar NV40'er in der Mangel' hat...
:D

http://www.nordichardware.se/UndaC/AtiSushi00.jpg

Razor

r@h
2004-05-08, 13:01:44
Original geschrieben von dildo4u
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=141476 Hast Du mein "For All" ignoriert ?
Schließlich läuft es auf den nVidia's sogar hübscher !
:D

Und hier ist es doch wohl wesentlich besser aufgehoben, oder was soll das jetzt noch im ATI-Hilfe-Forum ?

Razor

Hartogh
2004-05-08, 13:01:51
Original geschrieben von [MK2]Mythos
Wenn du dann noch die AGP Size auf 256 MB stellst und sich damit die Graka auch noch 256 MB von deinem Hauptspeicher reserviert ist das klar das sich die Demo aufgrund von ständigem Nachladen von Festplatte einen abruckelt.

Das ist mir schon bewusst, mit 128MB läuft es aber schlechter und die zugriffe bleiben auch gleich... anscheinend braucht man wohl wirklich 1024MB ram (oder eine 256MB Graka) um die Demo flüssig zu sehen...

dildo4u
2004-05-08, 13:06:25
Original geschrieben von r@h
Hast Du mein "For All" ignoriert ?
Schließlich läuft es auf den nVidia's sogar hübscher !
:D

Und hier ist es doch wohl wesentlich besser aufgehoben, oder was soll das jetzt noch im ATI-Hilfe-Forum ?

Razor hm glaub auf der X800 siehts am besten aus wegen 3Dc die shader sind in der demo whol deutlich zu lang für den R300 also gibts mit dem X800 doch nicht nur den doppelten R3XX

http://www.ati-news.de/Bilder/ATI/R420/3dc/2.jpg

Hellfire-Torrod
2004-05-08, 13:12:09
Also, auf meinem R350er leufts sehr schlecht. Die ablaufende demo selbst is für`n ar***, da ich alle 5 sekunden mal ein bild bekomme. Nur im 3dmodus beim umsehen leufts so mit 8-15 fps sichtbar. Aber trotzdem, sehr detailiert das ganze! X800, ich kommeeeeeeeeee *keingeld:(*

Mr. Lolman
2004-05-08, 13:20:19
Original geschrieben von r@h
Hast Du mein "For All" ignoriert ?
Schließlich läuft es auf den nVidia's sogar hübscher !
:D


Aber langsamer:

(1024x768, 4xAA 4xAF)
http://img32.photobucket.com/albums/v95/franz/SushiDX-2004-05-08-13-11-55.jpg

Iceman346
2004-05-08, 13:27:32
Original geschrieben von Hellfire-Torrod
Also, auf meinem R350er leufts sehr schlecht. Die ablaufende demo selbst is für`n ar***, da ich alle 5 sekunden mal ein bild bekomme. Nur im 3dmodus beim umsehen leufts so mit 8-15 fps sichtbar. Aber trotzdem, sehr detailiert das ganze! X800, ich kommeeeeeeeeee *keingeld:(*

Hast du noch AA oder AF an? Ich hab die komplette Demo grad mal mit Fraps durchgebencht:
Frames: 2315 - Time: 101157ms - Avg: 22.885 - Min: 9 - Max: 62

Alles auf dem System aus meiner Signatur. Merklich ruckeln tuts vor allem in den Szenen mit den Ninjas.

ironMonkey
2004-05-08, 13:28:03
Original geschrieben von Hellfire-Torrod
Also, auf meinem R350er leufts sehr schlecht. Die ablaufende demo selbst is für`n ar***, da ich alle 5 sekunden mal ein bild bekomme. Nur im 3dmodus beim umsehen leufts so mit 8-15 fps sichtbar. Aber trotzdem, sehr detailiert das ganze! X800, ich kommeeeeeeeeee *keingeld:(*

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=141476

Ganz unten auf der 1 Seite, den Link anklicken dann läufts auch auf einer R300 gut sofern du 1gig Ram hast.


Gruß

Edit: Schreibfehler;D

Quasar
2004-05-08, 13:28:43
Original geschrieben von Mr. Lolman
Aber langsamer:

(1024x768, 4xAA 4xAF)
http://img32.photobucket.com/albums/v95/franz/SushiDX-2004-05-08-13-11-55.jpg

Kein Wunder, wenn die Hälfte der Effekte fehlt.

"To decrease the size of the shaders so they would work on R300 class card, certain effects are now gone.
These include Depth of Field and many specular highlights. A future version may attempt to put these back in."

Aber schon klar - Hauptsache schnell. Dafür empfehle ich mal das "disable rendering" via 3DA. X-D

Mr. Lolman
2004-05-08, 13:32:45
Original geschrieben von Quasar
Kein Wunder, wenn die Hälfte der Effekte fehlt.

"To decrease the size of the shaders so they would work on R300 class card, certain effects are now gone.
These include Depth of Field and many specular highlights. A future version may attempt to put these back in."

Aber schon klar - Hauptsache schnell. Dafür empfehle ich mal das "disable rendering" via 3DA. X-D


Nanana, fühlt sich da wer auf den Schlips getreten? ;)

Zur Beruhigung ein Screenshot, ohne "R300 Powah" Schriftzug (aber mit den gleichen Einstellungen ;)):

http://img32.photobucket.com/albums/v95/franz/SushiDX-2004-05-08-00-33-56.jpg

Hellfire-Torrod
2004-05-08, 13:35:41
Original geschrieben von Iceman346
Hast du noch AA oder AF an? Ich hab die komplette Demo grad mal mit Fraps durchgebencht:
Frames: 2315 - Time: 101157ms - Avg: 22.885 - Min: 9 - Max: 62

Alles auf dem System aus meiner Signatur. Merklich ruckeln tuts vor allem in den Szenen mit den Ninjas.


Ja, hatte ich noch an , und dan ausgemacht :idea:
Nun leufts stellenweise ganz normal. Merke aber, das ich keinen GB Arbeitsspeicher habe, denn ich mus es erst einmal durchlaufen lasssen, bis es "Normal" leuft.

Quasar
2004-05-08, 13:48:53
Original geschrieben von Mr. Lolman
Nanana, fühlt sich da wer auf den Schlips getreten? ;)
Nööö, wieso auch?
Ich brauche ja nicht auf irgendwelche Effekte zu verzichten. ;D

Gas3t
2004-05-08, 14:02:59
Original geschrieben von Quasar
Nööö, wieso auch?
Ich brauche ja nicht auf irgendwelche Effekte zu verzichten. ;D

Na ja, auf 3Dc-Effekte musst du wohl auch verzichten. Und eine Dia-Show ist wohl auch nicht besonders gut fürs Ego. Also bitte nicht schon wieder ATI vs. NV. Bitte! Es ist nur eine Techdemo des r420!

Mr. Lolman
2004-05-08, 14:05:42
Original geschrieben von Bakunin3
Hat FRAPS eine Benchmarkfunktion?

Jo, schon länger. IMO default mit F11 aktivierbar. Wenns funzt sieht man kruz die fps gürn unterlegt, beim Stoppen vorm ATi Logo am Ende, ists dann kurz rot, und die Werte findet man in der log Datei...

Quasar
2004-05-08, 14:08:10
Original geschrieben von Gas3t
Na ja, auf 3Dc-Effekte musst du wohl auch verzichten. Und eine Dia-Show ist wohl auch nicht besonders gut fürs Ego. Also bitte nicht schon wieder ATI vs. NV. Bitte! Es ist nur eine Techdemo des r420!

Ich hab sowieso eine Dia-Show, da ich dank i815-Chipsatz nicht mehr als 64MB AGP-Aperture einstellen kann und grade keine 256MB-Karte zur Hand habe.

Und keine Sorge um mein Ego - das wird von anderen Dingen als TechDemos beeinflusst. :)

Bakunin3
2004-05-08, 14:18:09
Danke, Mr.

Also mit 4xAA und 2xAF und 1024x768 komme ich vom Anfang bis zum ATi Logo auf Folgendes:

2004-05-08 14:14:41 - SushiDX
Frames: 2890 - Time: 102109ms - Avg: 28.303 - Min: 13 - Max: 75

Geht eigentlich für so 'ne "last generation" Karte... :D

Gruß,
B3

PS: Ist deine Grafikkarte übertaktet oder alles auf default?

Edit: Schon gesehen, übertaktet. :)

Edit2: Auf meiner 9500@9700, selbe Einstellungen wie oben: 2004-05-08 16:17:34 - SushiDX
Frames: 2090 - Time: 101626ms - Avg: 20.565 - Min: 7 - Max: 71

Korak
2004-05-08, 14:25:10
Original geschrieben von dildo4u
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=141476

Zusammen geklebt.

r@h
2004-05-08, 14:33:40
Original geschrieben von Korak
Zusammen geklebt. Oder so...
:D

Razor

r@h
2004-05-08, 14:42:16
Original geschrieben von dildo4u
hm glaub auf der X800 siehts am besten aus wegen 3Dc die shader sind in der demo whol deutlich zu lang für den R300 also gibts mit dem X800 doch nicht nur den doppelten R3XX

http://www.ati-news.de/Bilder/ATI/R420/3dc/2.jpg Das hoffe ich doch stark, dass ein ATI-Demo, welches exklusive ATI-Features benutzt, auf ATI-Karten (der neuesten generation) wenigstens ein bissel besser aussieht...
:D

Allerdings haben die NV3x im Vergleich zu den R3x0 einen erheblichen BQ-Vorteil (wenn auch einen ebenso erheblichen Performance-Nachteil ;-). Sehr interessant fand ich aber den Ansatz, dieses Demo auf die NV3x-Familie umzusetzen, denn schließlich mussten dafür die Shader NICHT angepaßt werden. Also bedeutet dies, dass selbst die NV3x technologisch (!) dem R420 überlegen sind... wenn man mal von dem explizit zu unterstützenden 3Dc absieht.

Dass aber solch ein Demo (mit absolut gleicher BQ !) nicht auf einem NV40 möglich sein soll, wage ich doch stark zu bezweifeln...

Schließlich sagt ATI selbst, dass ein Redesign dieses Demo's für die R3x0 sehr, sehr aufwändig ist... was mit diesen 'profan-Wrappern' wiederlegt worden sein dürfte.

Razor

r@h
2004-05-08, 14:46:37
Original geschrieben von Mr. Lolman
Aber langsamer:

(1024x768, 4xAA 4xAF)
http://img32.photobucket.com/albums/v95/franz/SushiDX-2004-05-08-13-11-55.jpg Mann ist das bei Dir dunkel... und irgendetwas scheint da auch zu fehlen.

Und klar, dass es (wesentlich) langsamer auf den nVidia's läuft, habe ich ja schon ganz zu anfang geschrieben... mal davon abgesehen, dass der gros der Shader auf ATI (R3x0 und damit auch auf die R420 ;-) optimiert wurde und die lieben FX'en daran sicher knabbern müssen.

Was allerdings passiert, wenn man die Shader komplett auf die NV3x hin optimiert, kannst Du Dir ja vielleicht vorstellen, oder ?
:D

Razor

deekey777
2004-05-08, 14:46:46
Die Shader der NV3x sind ja "etwas" fortschrittlicher als die der R420.

r@h
2004-05-08, 14:47:50
Und nur, damit dies nicht untergeht (des Mergens wegen ;-) :
Original geschrieben von r@h
Hi folks !

Möget Ihr Euch bitte mal folgenden Thread auf B3D anschaun':
http://www.beyond3d.com/forum/viewtopic.php?t=12141&start=14

Da gibt's folgende ZIP's von Colourless, die Ihr Euch mal anschaun' solltet:

- für NV3x: NV3xRuby (http://www.users.on.net/triforce/ruby/NV3xRuby.zip)
- Für R3x00: r300rubyrap (http://www.users.on.net/triforce/ruby/r300rubyrap.zip)

Einfach die Dateien ins Zeilverzeichnis entpacken und gut !

Ruby, at it's best !
(na ja... fast ;-)

Bei ATI-Karten mussten Shader ersetzt werden, weil diese die vielen Instruktionen pro Shader nicht abkönnen, bei nVidia hingegen ein paar Skripte.

Thx @ Colourless !
:up:

Razor

P.S.: Ach ja, die originale Demo von ATI braucht Ihr dafür natürlich.

P.P.S.: Der 3DA läuft damit leider nicht, da dies über einen D3D9-Wrapper realisiert wird... :-(

P.P.P.S.: Läuft dank der ersetzten Shader auf ATI-Karten wesentlich besser, als auf den nVidia's... wenn auch dafür einige Effekte fehlen. Und 'laufen' heißt auch bei den NV35 gerade mal 3fps... dafür aber in 10x7 mit 2xAA... ;)

r@h
2004-05-08, 14:49:49
Original geschrieben von deekey777
Die Shader der NV3x sind ja "etwas" fortschrittlicher als die der R420. "Sehr viel" wäre da wohl angebrachter, oder ?

Schließlich scheint der einzige Unterschied - von R3x zu R420 - der höhere Instruction-Count, wie auch das explzit zu unterstützende 3Dc zu sein. Die NV3x-Architektur bietet da schon "etwas" mehr...

Razor

Bakunin3
2004-05-08, 14:49:53
Sieht aber auch auf 'nem R350 ziemlich gut aus... auch wenn bestimmte Effekte fehlen mögen. :)

Eins (http://www.dettmering-web.de/Ruby11.jpg)

und zwei (http://www.dettmering-web.de/Ruby1.jpg)

Gruß,
B3

betasilie
2004-05-08, 15:00:33
Hammer! Einfach nur geil, besonders auch die Texturierung.

Die Fingerkuppen bei dem Typen haben "Fingerabdrücke" und diese sogar mit Pixelshading. :o

Einfach nur geil, dass sowas in Echtzeit möglich ist und selbst mit meiner R300 mit 4*AA und 4*AF flüssig. :up:

MechWOLLIer
2004-05-08, 15:06:23
Läuft hier auf nem R300 odhc relativ gut, allerdings gibts auch Szenen bei mir wo ich grad mal 1FPS hat. Hab aber keine Lust duie Aparture Size im Bios umzustellen. Aber auch wenn Effekte auf nem R3x0 fehlen, sieht doch schon verdammt hübsch aus.

Korak
2004-05-08, 15:08:01
Original geschrieben von r@h

Allerdings haben die NV3x im Vergleich zu den R3x0 einen erheblichen BQ-Vorteil (wenn auch einen ebenso erheblichen Performance-Nachteil ;-). Sehr interessant fand ich aber den Ansatz, dieses Demo auf die NV3x-Familie umzusetzen, denn schließlich mussten dafür die Shader NICHT angepaßt werden. Also bedeutet dies, dass selbst die NV3x technologisch (!) dem R420 überlegen sind... wenn man mal von dem explizit zu unterstützenden 3Dc absieht.


Wieso bedeutet dies das?

Original geschrieben von r@h
Dass aber solch ein Demo (mit absolut gleicher BQ !) nicht auf einem NV40 möglich sein soll, wage ich doch stark zu bezweifeln...


Warum sollte das auch nicht möglich sein? Das sollte auch mit einer 9700 gehen.

Original geschrieben von r@h
Schließlich sagt ATI selbst, dass ein Redesign dieses Demo's für die R3x0 sehr, sehr aufwändig ist... was mit diesen 'profan-Wrappern' wiederlegt worden sein dürfte.

Razor

Die Wrapper stellen kein Redesign dar.

Korak
2004-05-08, 15:08:50
Original geschrieben von r@h
Und nur, damit dies nicht untergeht (des Mergens wegen ;-) :

Warum sollte es untergehen?

r@h
2004-05-08, 15:17:50
Original geschrieben von Mr. Lolman
Nanana, fühlt sich da wer auf den Schlips getreten? ;)

Zur Beruhigung ein Screenshot, ohne "R300 Powah" Schriftzug (aber mit den gleichen Einstellungen ;)):

http://img32.photobucket.com/albums/v95/franz/SushiDX-2004-05-08-00-33-56.jpg Naaaa ?
Hast Du Dich nicht 'getraut', die FPS mit anzuzeigen ?
:D

Habe hier auch mal ein Bildchen gemacht... und zwar aus der Original-Perspektive !
(würde ich Dich doch auch drum bitten ;-)

http://mitglied.lycos.de/razor3dc/pics/Ruby_nv3x_AtiSushi06_50_85.jpg (http://mitglied.lycos.de/razor3dc/pics/Ruby_nv3x_AtiSushi06.png)
(das 'sichtbare' Bildchen ist etwas in Größe und Quali reduziert ;-)

Wie man sieht, doch ganz erhebliche Unterschiede !
Von dem 'Teint' der Dame bei Dir mal ganz abgesehen...

Ich überlasse es den Experten, zu beurteilen, was genau an Effekten da bei Dir fehlt.

Razor

P.S.: Wenn man "-debug" an die SushiFX.EXE mit anhängt, gibt's ein paar 'nette' extra-Features, wie u.a. ein Benchmark (ohne FRAPS ;-) und noch vieles andere (mit "H" aufzurufen).

Quasar
2004-05-08, 15:18:16
Original geschrieben von Korak
Wieso bedeutet dies das?

Die Wrapper stellen kein Redesign dar.

Weil keine Effekte weggelassen werden mussten. =) Allerdings ist dies höchstens ein Indiz für einen Gleichstand, aber nicht für eine Überlegenheit - jene ergibt sich erst aus zusätzlichen Gegebenheiten.

ATi meinte auch ein Redesign, bei dem _alle_ Effekte (meinetwegen abgesehen von komprimierten Normal-Maps) auch auf R3xx dargestellt werden.

So fehlen Specular Highlights und Depth of Field.

r@h
2004-05-08, 15:18:53
Original geschrieben von Bakunin3
Sieht aber auch auf 'nem R350 ziemlich gut aus... auch wenn bestimmte Effekte fehlen mögen. :)

Eins (http://www.dettmering-web.de/Ruby11.jpg)

und zwei (http://www.dettmering-web.de/Ruby1.jpg) Klar... aber schau' Dir da mal mein Bildchen an... ;)

Razor

betasilie
2004-05-08, 15:22:01
Na Razor, willst Du wieder einen Flamewar initiieren?

Wir wissen doch, dass NV die besten Karten macht. Das musst Du uns nicht beweisen. ;)

MadMan2k
2004-05-08, 15:23:40
Original geschrieben von r@h
Klar... aber schau' Dir da mal mein Bildchen an... ;)

Razor
jo, bei der Performance, hätte mans gleich offline mit 3ds max rendern können :P

misterh
2004-05-08, 15:26:19
auf 5900 XT :D

2004-05-08 15:17:18 - Ruby
Frames: 389 - Time: 292613ms - Avg: 1.329 - Min: 0 - Max: 5

MadMan2k
2004-05-08, 15:27:07
Original geschrieben von r@h
Das hoffe ich doch stark, dass ein ATI-Demo, welches exklusive ATI-Features benutzt, auf ATI-Karten (der neuesten generation) wenigstens ein bissel besser aussieht...
:D

keine Angst, es ist ja nicht die Dawn-Demo, gell? ;D


Also bedeutet dies, dass selbst die NV3x technologisch (!) dem R420 überlegen sind...

ach, sag bloß - das ist jetzt aber neu...


Dass aber solch ein Demo (mit absolut gleicher BQ !) nicht auf einem NV40 möglich sein soll, wage ich doch stark zu bezweifeln...

wenn man 3dc per Software realisiert, dann schon.
Allerdings könnte man auch noch den einen oder anderen Effekt auch in software machen und die Demo dadurch auf einem Rage IIC in gleicher(!) Bildqualität zum laufen kriegen...

Mr. Lolman
2004-05-08, 15:28:17
Original geschrieben von r@h
Naaaa ?
Hast Du Dich nicht 'getraut', die FPS mit anzuzeigen ?
:D


Ich bin nicht so feig wie du ;) Bei meinem Screenshot erkennt man links unten eindeutig die fps. Wie schauts bei dir aus?

/edit: Hab nicht gleich aufs Bild geklickt, sry :)

Korak
2004-05-08, 15:36:53
Original geschrieben von Quasar
Weil keine Effekte weggelassen werden mussten. =) Allerdings ist dies höchstens ein Indiz für einen Gleichstand, aber nicht für eine Überlegenheit - jene ergibt sich erst aus zusätzlichen Gegebenheiten.

Eben.

Also bedeutet dies, dass selbst die NV3x technologisch (!) dem R420 überlegen sind

Original geschrieben von Quasar
ATi meinte auch ein Redesign, bei dem _alle_ Effekte (meinetwegen abgesehen von komprimierten Normal-Maps) auch auf R3xx dargestellt werden.

So fehlen Specular Highlights und Depth of Field.

Eben #2

Bakunin3
2004-05-08, 15:38:15
Original geschrieben von r@h
Klar... aber schau' Dir da mal mein Bildchen an... ;)

Razor

Ich habe genau das selbe Bild und versuche verzweifelt, es hochzuladen, damit verglichen werden kann... aber dummerweise bin ich bei Strato und es geht mal wieder gar nichts.

Jedenfalls sieht es - m.E. - bei mir nicht großartig anders aus... ;)

B3

Bakunin3
2004-05-08, 15:43:02
Oh, doch... die Handschuhe glänzen z.b. überhaupt nicht... hmmm... also doch fehlerhaft.

Naja, mal genauer vergleichen:

Hier (http://www.dettmering-web.de/Ruby12.jpg)

Gruß,
B3

Edit: Außerdem ist das Gesicht nicht ganz in Ordnung. Dafür sehen die Texturen bei mir schärfer aus...

r@h
2004-05-08, 16:15:27
Original geschrieben von MadMan2k
jo, bei der Performance, hätte mans gleich offline mit 3ds max rendern können :P Hast Du das schon mal gemacht ?
Dann wüsstest Du, man bei 3ds max eher in fph, statt in fps rechnet...
:D

Razor

r@h
2004-05-08, 16:18:27
Original geschrieben von MadMan2k
wenn man 3dc per Software realisiert, dann schon.Blödsinn... ist doch nur 'nen Komprimierungs-System. Im Zweifelsfall kann man ja die originalen Detail-Texturen nehmen...

Technisch sicher nicht ganz korrekt.
:D

Razor

r@h
2004-05-08, 16:29:56
Original geschrieben von Bakunin3
Oh, doch... die Handschuhe glänzen z.b. überhaupt nicht... hmmm... also doch fehlerhaft.

Naja, mal genauer vergleichen:

Hier (http://www.dettmering-web.de/Ruby12.jpg)

Gruß,
B3

Edit: Außerdem ist das Gesicht nicht ganz in Ordnung. Dafür sehen die Texturen bei mir schärfer aus... Wow !!!
Vielein, vielen Dank B3...

An diesem Vergleich (keine Ahnung, warum Lolmann kein vergleichbaren Shot machen wollte) kann man die Unterschiede nun recht deutlich fest machen.

Das mit der Schärfe wird maßgeblich vom DOF-Effekt abhängen. So kann man bei meinem Shot im Hintergrund (metallener Stahlträger) sehr gut erkennen, dass dort dieser Effekt zum Tragen kommt. Aber da ist noch weit mehr...

Schau' Dir mal die Haut von Ruby an. Bei mir wirkt diese schon fast Milchig... wie echte (seidene) Haut eben... in Deinem Shot hat sich da eher ein wieder eine Art "Plastik-Effekt" eingeschlichen, was so sicher nicht von den Entwicklern beabsichtigt war. Von dem 'dunklen' Teint ganz zu schweigen (wie ich ja auch schon zu dem Shot von Lolman schrieb).

Und ja, ganz normale Glanzeffekte scheinen ebenfalls zu fehlen.

Vielleicht bekommt Colourless das ja noch hin. Schließlich hat er ja 'ne Radeon im Rechner.
Dass er das für die FX'en hinbekommen hat, war eigentlich eher Zufall...

Razor

Quasar
2004-05-08, 16:37:19
The Ruby demo runs at somewhere around 250mb of of video memory and that's with the 3Dc compression on all the normal maps as well as a few other textures. The engine will actually decompress the textures on hardware that doesn't support 3Dc, however, given that we are right at the limit, even on a 256mb card you would still end up texturing out of AGP memory which is pretty slow, and it we wouldn't even be able to create all the textures we needed for 128mb cards.
Ausm B3D-Thread.

Wie ich's mir gedacht habe - bloß keine Chance für den nV40 lassen, das Ding schneller zu rendern.

Einen Apple-to-Apple Vergleich mit der 512MB-Version erwarte ich jetzt schon mit Freude.

edit:
Nicht, daß nV irgendwas anderes machen würde/macht

Mr. Lolman
2004-05-08, 16:39:33
Original geschrieben von r@h
Wow !!!
Vielein, vielen Dank B3...

An diesem Vergleich (keine Ahnung, warum Lolmann kein vergleichbaren Shot machen wollte)


Wollt ich doch, Nur brauchte ich ~5 Anläufe bis ich die Szene endlich eingefangen hatte, und da hatte dann B3 schon seinen Shot gepostet. Der Vollständigkeit halber:

1024x768, 4xAA 4xAF, 50% verkleinert:

Korak
2004-05-08, 16:39:58
Original geschrieben von r@h
Hast Du das schon mal gemacht ?
Dann wüsstest Du, man bei 3ds max eher in fph, statt in fps rechnet...
:D

Razor

Was hast du denn für 'nen lahmen Rechner? :D ;)

r@h
2004-05-08, 16:40:30
Original geschrieben von Korak
Wieso bedeutet dies das?Weil zu dem 2.0+ bei nVidia ja nun noch ein bissel mehr gehört, als nur der Instruction-Count.
Demirug wird Dir das sicher besser erklären können...
Original geschrieben von Korak
Warum sollte das auch nicht möglich sein? Das sollte auch mit einer 9700 gehen. Oder wie Beta auch schon schrieb: Mit 'ner TNT !
:D

Alles eine Sache des Aufwandes, nicht ?

Ich wollte nur darauf hinaus, dass für die nVidia-Architektur (der letzten Generation), nicht einmal die Shader angepaßt werden mussten (was bei den Radeons offenbar vonnöten ist).
Original geschrieben von Korak
Die Wrapper stellen kein Redesign dar. Zumindest hat sich ATI hier sehr unklar ausgedrückt, oder nicht ?

Klar, hätten sie gasagt, dass die Shader so komplex sind, dass sie nur auf der NV3x-Architektur laufen, nicht aber auf der R300-Architektur, hätte das auch irgendwie 'dumm' ausgesehen...
Original geschrieben von Korak
Warum sollte es untergehen? Weil er nach dem Mergen einfach zwischen den ganzen ATI-Tread-Posts gelandet ist, mein erneuter Post aber allen 'entgegen' kommen dürfte... ;)

Razor

Mr. Lolman
2004-05-08, 16:40:37
Original geschrieben von Quasar
Einen Apple-to-Apple Vergleich mit der 512MB-Version erwarte ich jetzt schon mit Freude.

Glaubst du ATi ist so paranoid?

betasilie
2004-05-08, 16:41:14
Original geschrieben von Quasar
Ausm B3D-Thread.

Wie ich's mir gedacht habe - bloß keine Chance für den nV40 lassen, das Ding schneller zu rendern.

Einen Apple-to-Apple Vergleich mit der 512MB-Version erwarte ich jetzt schon mit Freude.
Was erwartest Du? Dass ATI den Videomemory nicht ausnutzt, damit die Demo schlechter aussieht und damit auch Karten ohne 3Dc die Demo abspielen können ohne AGP-Texturing? :spock:

Das wäre ja wohl absolut paradox.

Quasar
2004-05-08, 16:44:01
Lo and behold!
(ich habe edited)

r@h
2004-05-08, 16:44:05
Original geschrieben von Mr. Lolman
Wollt ich dich, Nur brauchte ich ~5 Anläufe bis ich die Szene endlich eingefangen hatte, nud da hatte dann B3 schon seinen Shot gepostet. Der Vollständigkeit halber:

1024x768, 4xAA 4xAF, 50% verkleinert: Ähm...

Im Debug-Mudus starten (wie Du es ja gemacht hast), dann das Demo anhalten ("A") und dann Sequenz- oder Bild-Weise vor und zurück gehen (Bild: Pos1/Ende, Sequnz: Bild hoch/runter). Ganz einfach...

Aber klar, das Bild von B3 reicht völlig.

Razor

Mr. Lolman
2004-05-08, 16:45:46
Original geschrieben von r@h
Wow !!!
Vielein, vielen Dank B3...

An diesem Vergleich (keine Ahnung, warum Lolmann kein vergleichbaren Shot machen wollte) kann man die Unterschiede nun recht deutlich fest machen.

Das mit der Schärfe wird maßgeblich vom DOF-Effekt abhängen. So kann man bei meinem Shot im Hintergrund (metallener Stahlträger) sehr gut erkennen, dass dort dieser Effekt zum Tragen kommt. Aber da ist noch weit mehr...

Schau' Dir mal die Haut von Ruby an. Bei mir wirkt diese schon fast Milchig... wie echte (seidene) Haut eben... in Deinem Shot hat sich da eher ein wieder eine Art "Plastik-Effekt" eingeschlichen, was so sicher nicht von den Entwicklern beabsichtigt war. Von dem 'dunklen' Teint ganz zu schweigen (wie ich ja auch schon zu dem Shot von Lolman schrieb).

Und ja, ganz normale Glanzeffekte scheinen ebenfalls zu fehlen.

Vielleicht bekommt Colourless das ja noch hin. Schließlich hat er ja 'ne Radeon im Rechner.
Dass er das für die FX'en hinbekommen hat, war eigentlich eher Zufall...

Razor


Hat ja B3 eh schon fast alles geschrieben. Das einzige was noch im Raum steht, ist dass mein Rechner die Szene genau 13x (in Worten: DREIZEHN MAL !!!) schneller rechnet als deiner...

r@h
2004-05-08, 16:45:51
Original geschrieben von Korak
Was hast du denn für 'nen lahmen Rechner? :D ;) Was renderst Du denn in 3ds max ?
;D

Razor

r@h
2004-05-08, 16:49:47
Original geschrieben von Mr. Lolman
Hat ja B3 eh schon fast alles geschrieben. Das einzige was noch im Raum steht, ist dass mein Rechner die Szene genau 13x (in Worten: DREIZEHN MAL !!!) schneller rechnet als deiner... Entweder hast Du nicht richtig gelesen, oder Du willst es einfach nicht verstehen...

Solll ich mal aufzählen:

- alle wichtigen Shader fehlen bei Dir (insbesondere auf DoF sei hier verwiesen !)
- Shader sind vollständig auf ATI optimiert (und liegen damit der NV3x-Architektur 'quer' ;-)
- mein Shot wurde mit 2xAA gemacht (ohne siehts auch nicht viel besser aus ;-)
- ... das was mit gerade nicht einfällt ;)

Razor

Mr. Lolman
2004-05-08, 16:50:18
Original geschrieben von r@h
Ähm...

Im Debug-Mudus starten (wie Du es ja gemacht hast), dann das Demo anhalten ("A") und dann Sequenz- oder Bild-Weise vor und zurück gehen (Bild: Pos1/Ende, Sequnz: Bild hoch/runter). Ganz einfach...

Aber klar, das Bild von B3 reicht völlig.

Razor

Ui, hoppla :ups:

r@h
2004-05-08, 16:51:42
Original geschrieben von Mr. Lolman
Glaubst du ATi ist so paranoid? Nein, aber sie hätten mit ein paar weniger Texturen auch die R3x0-User an dem Teilhaben lassen können.
Nicht gerade ein feiner Zug.

Razor

Mr. Lolman
2004-05-08, 16:52:34
Original geschrieben von r@h
Entweder hast Du nicht richtig gelesen, oder Du willst es einfach nicht verstehen...

Solll ich mal aufzählen:

- alle wichtigen Shader fehlen bei Dir (insbesondere auf DoF sei hier verwiesen !)
- Shader sind vollständig auf ATI optimiert (und liegen damit der NV3x-Architektur 'quer' ;-)
- mein Shot wurde mit 2xAA gemacht (ohne siehts auch nicht viel besser* aus ;-)
- ... das was mit gerade nicht einfällt ;)

Razor

Ja wissen wir ja schon. Nur über 13x höhere Geschwindigkeit wird man doch wohl ein Wort verlieren dürfen...

BTW: Alle meine Screenshots wurde mit 4xAA 4xAF gemacht

*du meinst wohl 'schlechter'...

betasilie
2004-05-08, 16:53:23
Original geschrieben von Quasar
Lo and behold!
(ich habe edited)
Es geht ja nicht darum, dass NV das auch macht. ;-)

Techdemos sollen ja die Hardware, die sie präsentieren sollen, exzessiv ausreizen, um möglichst alle Vorzüge zu präsentieren.

Also eine Abwärtskompatiblität (oder Konkurrenzkompatiblität) zu fordern wäre nun wirklich unpassend. Bei NV-Demos möchte ich ja z.B. auch schließlich die Vorüge von SM3.0 sehen.

Aber generell gebe ich dir recht; ich würde auch gerne sehen wie sich die 512MB-Varainte eines NV40-Borads mit der Demo schlägt. :)

r@h
2004-05-08, 16:53:49
Original geschrieben von betareverse
Was erwartest Du? Dass ATI den Videomemory nicht ausnutzt, damit die Demo schlechter aussieht und damit auch Karten ohne 3Dc die Demo abspielen können ohne AGP-Texturing? :spock:

Das wäre ja wohl absolut paradox. Klar, 3Dc wäre ja sonst sinnlos... got the idea ?
:)

Razor

Mr. Lolman
2004-05-08, 16:53:53
Original geschrieben von r@h
Nein, aber sie hätten mit ein paar weniger Texturen auch die R3x0-User an dem Teilhaben lassen können.
Nicht gerade ein feiner Zug.

Razor

Klaro. Aber imo wars ja nichtmal in deren Absicht, dass die Demo noch auf Karten der alten Generation läuft, oder?

r@h
2004-05-08, 16:55:06
Original geschrieben von Mr. Lolman
*du meinst wohl 'schlechter'... Nein, "besser" im Sinne von (wesentlich) besserer Performance.
;-)

Razor

betasilie
2004-05-08, 16:55:18
Original geschrieben von r@h
Klar, 3Dc wäre ja sonst sinnlos... got the idea ?
:)

Razor
Genau das meinte ich.

r@h
2004-05-08, 16:56:29
Original geschrieben von Mr. Lolman
Klaro. Aber imo wars ja nichtmal in deren Absicht, dass die Demo noch auf Karten der alten Generation läuft, oder? Um so erstaunlicher, dass es das tut, oder ?
(wenn auch seeeeeehr viel langsamer ;-)

Razor

Korak
2004-05-08, 16:57:51
Original geschrieben von r@h
Weil zu dem 2.0+ bei nVidia ja nun noch ein bissel mehr gehört, als nur der Instruction-Count.
Demirug wird Dir das sicher besser erklären können...


:| Was hat das jetzt mit der Demo zu tun? Du schaust dir die Demo an und siehst, dass die PS-Einheit des NV3x der des R420 überlegen ist? X-D

Original geschrieben von r@h
Oder wie Beta auch schon schrieb: Mit 'ner TNT !
:D

Alles eine Sache des Aufwandes, nicht ?


Jup. So isses.

Original geschrieben von r@h
Ich wollte nur darauf hinaus, dass für die nVidia-Architektur (der letzten Generation), nicht einmal die Shader angepaßt werden mussten (was bei den Radeons offenbar vonnöten ist).

Ja, an die R300 angepasst, nicht and die R420. Das die NV3x die gleichen Shader benutzen kann wie der R420 bedeutet in der Demo Gleichstand. Eine Überlegenheit kann man da nicht rauslesen.

Original geschrieben von r@h
Zumindest hat sich ATI hier sehr unklar ausgedrückt, oder nicht ?


Vielleicht.

Korak
2004-05-08, 16:58:59
Original geschrieben von r@h
Was renderst Du denn in 3ds max ?
;D

Razor

Was anderes.

Allerdings ist die Qualli in 3DSm höher.

Bakunin3
2004-05-08, 16:59:50
Jungs! Nicht streiten, bitte.

Wir können uns ja vielleicht darauf einigen, daß wir jetzt weder Leistung noch Qualität von nVidia und ATi mit Grafikkarten vergleichen können - bzw. können wir schon, kommen aber zu keinem gültigen Schluß - weil die Demo nicht für die verfügbaren karten gemacht und gedacht ist.

Und wir wissen auch nicht, ob die nVidia Karten derart viel langsamer sind, weil sie praktisch alles sauber darstellen oder ob die ATi Karten immer noch schneller wären, wenn sie ebenfalls sauber darstellen würden.

Was wir sehen, ist, daß die Demo zum Glück auch auf anderen Karten abspielbar ist und - auch unkomplett gerendert - immer noch ziemlich gut aussieht. :)

Peace und allen Menschen einen Wohlgefallen. =)

B3

Quasar
2004-05-08, 17:02:04
Original geschrieben von betareverse
Es geht ja nicht darum, dass NV das auch macht. ;-)

Techdemos sollen ja die Hardware, die sie präsentieren sollen, exzessiv ausreizen, um möglichst alle Vorzüge zu präsentieren.
Ack.

Original geschrieben von betareverse
Also eine Abwärtskompatiblität (oder Konkurrenzkompatiblität) zu fordern wäre nun wirklich unpassend.
Tue ich ja auch nicht...


Original geschrieben von betareverse
Bei NV-Demos möchte ich ja z.B. auch schließlich die Vorüge von SM3.0 sehen.
Aber generell gebe ich dir recht; ich würde auch gerne sehen wie sich die 512MB-Varainte eines NV40-Borads mit der Demo schlägt. :)
Ack.

InsaneDruid
2004-05-08, 17:04:02
Original geschrieben von Bakunin3
Jungs! Nicht streiten, bitte.

Wir können uns ja vielleicht darauf einigen, daß wir jetzt weder Leistung noch Qualität von nVidia und ATi mit Grafikkarten vergleichen können - bzw. können wir schon, kommen aber zu keinem gültigen Schluß - weil die Demo nicht für die verfügbaren karten gemacht und gedacht ist.

Und wir wissen auch nicht, ob die nVidia Karten derart viel langsamer sind, weil sie praktisch alles sauber darstellen oder ob die ATi Karten immer noch schneller wären, wenn sie ebenfalls sauber darstellen würden.

Was wir sehen, ist, daß die Demo zum Glück auch auf anderen Karten abspielbar ist und - auch unkomplett gerendert - immer noch ziemlich gut aussieht. :)

Peace und allen Menschen einen Wohlgefallen. =)

B3

Amen.. und ACK.

r@h
2004-05-08, 17:04:41
Original geschrieben von Korak
Was hat das jetzt mit der Demo zu tun? Du schaust dir die Demo an und siehst, dass die PS-Einheit des NV3x der des R420 überlegen ist?Och mann, Korak...
Soll ich's Dir auseinander flöhen ?

1) NV3x rendert Ruby -> NV3x ist mindestend technologisch gelichwertig.
2) R420 unterstützt nicht, was NV3x unterstützt -> NV3x ist überlegen

Jetzt verstanden ?

Und ja, vermutlich habe ich mich nicht konkret genug ausgedrückt, aber gemient habe ich den Punkt 1, aber gleich im Hinterkopf gehabt, dass die NV3x-Architektur doch noch sehr viel mehr kann und so habe ich dann Punkt 2 ausgesprochen.

Werde mich nächstes mal einfach klarer ausdrücken...
Original geschrieben von Korak
Ja, an die R300 angepasst, nicht and die R420. Das die NV3x die gleichen Shader benutzen kann wie der R420 bedeutet in der Demo Gleichstand. Eine Überlegenheit kann man da nicht rauslesen.Wie schon oben geschrieben...
Werde mich bessern, OK ?
;-)
Original geschrieben von Korak
Vielleicht. Nein, ganz klare Absicht IMO.
Technologisch ist das Teil (der R420) ja nun wirklich keine Meisterleistung... es ist 'nur' ein verdammt schneller R3x0. Und wenn man sich jetzt noch vor Augen führt, was der NV3x noch so alles kann...

Razor

betasilie
2004-05-08, 17:05:30
Original geschrieben von Quasar
Tue ich ja auch nicht...
Weiß ich. ;) Dein Posting war halt nur etwas mißverständlich ausgedrückt.

Original geschrieben von Bakunin3
Und wir wissen auch nicht, ob die nVidia Karten derart viel langsamer sind, weil sie praktisch alles sauber darstellen oder ob die ATi Karten immer noch schneller wären, wenn sie ebenfalls sauber darstellen würden.
Full Ack. Deshalb haben diese Diskussionen soviel Streitpotenzial.

Original geschrieben von Bakunin3
Peace und allen Menschen einen Wohlgefallen. =)
:rainbow:

r@h
2004-05-08, 17:05:34
Ups... falschen Knop 'getroffen'...
:D

r@h
2004-05-08, 17:06:59
Original geschrieben von Korak
Was anderes.
Allerdings ist die Qualli in 3DSm höher. Gottlob.
Bin mal gespannt, wann sie endlich den Offline-Renderer für 3ds max frei geben...
Weiß da schon jemand was genaueres ?
:???:

Razor

Korak
2004-05-08, 17:11:38
Original geschrieben von r@h
Och mann, Korak...
Soll ich's Dir auseinander flöhen ?

1) NV3x rendert Ruby -> NV3x ist mindestend technologisch gelichwertig.
2) R420 unterstützt nicht, was NV3x unterstützt -> NV3x ist überlegen

Jetzt verstanden ?



Wenn ich ehrlich bin wusste ich von Anfang an was du meinst.
Nur war es so wie du es geschrieben hast nicht wirklich schlüssig. :heilig:

r@h
2004-05-08, 17:23:41
Original geschrieben von Korak
Wenn ich ehrlich bin wusste ich von Anfang an was du meinst.
Nur war es so wie du es geschrieben hast nicht wirklich schlüssig. :heilig: Dacht' ich's mir doch... und ja, darauf können wir uns eingen !
:bier:

Razor

AlfredENeumann
2004-05-08, 17:29:34
Original geschrieben von Iceman346

Alles auf dem System aus meiner Signatur. Merklich ruckeln tuts vor allem in den Szenen mit den Ninjas.


Komisch. Gerade bei deiser Szene läuft es bei mir extrem föüssig.

LovesuckZ
2004-05-08, 17:36:27
Vielleicht schafft jemand eine DXT5 - Unterstuetzung einzubauen, dann sollte das ganze auch auf nicht 3Dc - Karten von der Speichermenge her vernünftig laufen.

Sphinx
2004-05-08, 17:52:01
Also unter 4xAA + 4xAF unter 1024x768 habe ich ~ 9.5 FPS auf einer R9700Pro bei Frame 1805,xx da (ich xx nicht auf 16 stoppen konnte bzw bei vor/rückwärtsfahren ~+/- 0.5 davon entfernt war)

Und unter 0xAA + 0xAF unter 1024x768 habe ich ~ 20.5 FPS auf einer R9700Pro bei Frame EXACT 1805,16

---
Wenn ich einen Shot machen will sinkt die FPS anzeige kurz ins bodenlose und es wird der Shot dann anschließend wo er unten ist gemacht. Sollte ich vielleicht Hypersnap nutzen ?
---

BlackBirdSR
2004-05-08, 18:17:23
Original geschrieben von r@h
Och mann, Korak...
Soll ich's Dir auseinander flöhen ?

1) NV3x rendert Ruby -> NV3x ist mindestend technologisch gelichwertig.
2) R420 unterstützt nicht, was NV3x unterstützt -> NV3x ist überlegen

Und wenn man sich jetzt noch vor Augen führt, was der NV3x noch so alles kann...

Razor

3) Mein K7 unterstützt all das was NV3x und R420 kann, plus viel viel mehr. -> K7 ist überlegen.

Und wenn man sich jetzt noch vor Augen führt, was die CPU nocht so alles kann...

So ein BS hier.

r@h
2004-05-08, 18:26:05
Original geschrieben von BlackBirdSR
3) Mein K7 unterstützt all das was NV3x und R420 kann, plus viel viel mehr. -> K7 ist überlegen.

Und wenn man sich jetzt noch vor Augen führt, was die CPU nocht so alles kann...Karoak hat es (natürlich) verstanden... Du offenbar nicht.

Razor

ironMonkey
2004-05-08, 18:31:25
Natürlich hat er das verstanden und du hast auch jedem klar gemacht das NV3X besser( Technisch) ist als R300/R420, aber was bringt das????????


Gruß

deekey777
2004-05-08, 18:33:51
Original geschrieben von r@h
Och mann, Korak...
Soll ich's Dir auseinander flöhen ?

1) NV3x rendert Ruby -> NV3x ist mindestend technologisch gelichwertig.
2) R420 unterstützt nicht, was NV3x unterstützt -> NV3x ist überlegen

...

Razor

Korrektur:
2) R420 unterstützt nicht, was NV3x unterstützt -> NV3x ist technologisch überlegen.

Mr. Lolman
2004-05-08, 19:44:32
Wer als NV3x User, die Ruby Demo etwas flüssiger betrachten will, kann das, in dem er einfach die ATi Shader verwendet...

(B3d Forum)

Quasar
2004-05-08, 19:48:56
Original geschrieben von Mr. Lolman
Wer als NV3x User, die Ruby Demo etwas flüssiger betrachten will, kann das, in dem er einfach die ATi Shader verwendet...

(B3d Forum)

FP16 erzwingen hülft auch :-)
Oder Auflösung senken :-)

Aber Colourless arbeitet an Multipass-Shadern für die R3xx-Reihe. Dann können endlich auch Radeon-User Ruby erleben, the way she was meant to be seen. ;)

misterh
2004-05-08, 19:53:48
und wie ? hab 5900XT, kaum flüssig

dildo4u
2004-05-08, 20:02:28
http://www.hardwareluxx.de/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=2&t=000036&p=2 sehr viele infos zur
Rubydemo

"Auch sind 256 MB RAM empfehlenswert auf der Grafikkarte, denn die Demo läd alleine 220 MB an Texturen. ATI hat sich die Demo von RhinoFX erstellen lassen und dabei eine beeindruckende Polygonen-Anzahl vorgegeben :
Für Ruby selbst sollten 80.000 Polygonen verwendet werden,
für den bösen Schurken Optico 60.000 Polygonen,
für die Ninjas jeweils 30.000 Polygonen
und für die Umgebung 150.000 Polygonen"

Quasar
2004-05-08, 20:34:17
X-D
220MB Texturen auf einer X800, ja.
Dazu ~23MB Vertexbuffers, ~2 MB Index Buffer, Front- Back- und Multisample Buffer.
Da muss nur wenig ausgelagert werden.


Auf einer "normalen" Karte sind's aber schon ~280MB Texturen.

Korak
2004-05-08, 20:51:08
Original geschrieben von dildo4u
http://www.hardwareluxx.de/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=2&t=000036&p=2 sehr viele infos zur
Rubydemo

"Auch sind 256 MB RAM empfehlenswert auf der Grafikkarte, denn die Demo läd alleine 220 MB an Texturen. ATI hat sich die Demo von RhinoFX erstellen lassen und dabei eine beeindruckende Polygonen-Anzahl vorgegeben :
Für Ruby selbst sollten 80.000 Polygonen verwendet werden,
für den bösen Schurken Optico 60.000 Polygonen,
für die Ninjas jeweils 30.000 Polygonen
und für die Umgebung 150.000 Polygonen"

Gibt's solche Infos auch für die Subsurface-Demo?

LovesuckZ
2004-05-08, 20:53:26
Original geschrieben von Quasar
X-D
220MB Texturen auf einer X800, ja.
Auf einer "normalen" Karte sind's aber schon ~280MB Texturen.

Ein bissl wenig oder ein bissl zu viel. Sollte 3Dc nicht ein bisschen mehr Plus bringen? Ich meine, dass sind gerade mal 27%...
Wie gut stehen die Chancen, dass es einen "DXT5" Hack geben koennte?

Quasar
2004-05-08, 20:55:59
Original geschrieben von LovesuckZ
Ein bissl wenig oder ein bissl zu viel. Sollte 3Dc nicht ein bisschen mehr Plus bringen? Ich meine, dass sind gerade mal 27%...
Wie gut stehen die Chancen, dass es einen "DXT5" Hack geben koennte?

27% auf die Gesamtmenge. Aber ich weiß leider nicht, wie hoch der Anteil der durch 3dc komprimierbaren Normal-Maps ist.

Aquaschaf
2004-05-08, 20:56:21
@LS: Colourmaps machen halt den größten Anteil der Texturen aus, da bringt 3DC ja nichts für.

MadMan2k
2004-05-08, 21:00:44
Original geschrieben von LovesuckZ
Ein bissl wenig oder ein bissl zu viel. Sollte 3Dc nicht ein bisschen mehr Plus bringen? Ich meine, dass sind gerade mal 27%...

3dc komprimiert 1:2, d.h. 50% ersparniss bei Normalmaps.


Wie gut stehen die Chancen, dass es einen "DXT5" Hack geben koennte?
DXT5 hat eine höheren Komperssionsfaktor als 3dc, was allerdings auf Kosten der Bildqualität geht.
Daher wäre man im Falle eines Hacks wieder in derselben Äpfel - Birnen Sitution.

LovesuckZ
2004-05-08, 21:12:30
Original geschrieben von MadMan2k
DXT5 hat eine höheren Komperssionsfaktor als 3dc, was allerdings auf Kosten der Bildqualität geht.
Daher wäre man im Falle eines Hacks wieder in derselben Äpfel - Birnen Sitution.

Es wird aber von fast jeder Hardware unterstuetzt. Waere also ein fallback.

MadMan2k
2004-05-08, 21:26:35
Original geschrieben von LovesuckZ
Es wird aber von fast jeder Hardware unterstuetzt. Waere also ein fallback.
Wie gesagt, für ein Fallback wäre die Bildqualität zu schlecht.
Wobei mir gerade einfällt, dass man wohl 3dc komprimierte Texturen nicht mit DXT5 dekomprimieren kann ;)

LovesuckZ
2004-05-08, 21:28:12
Original geschrieben von MadMan2k
Wie gesagt, für ein Fallback wäre die Bildqualität zu schlecht.

Wieviel?

Wobei mir gerade einfällt, dass man wohl 3dc komprimierte Texturen nicht mit DXT5 dekomprimieren kann ;)

Ja, aber die Texturen müssten ja auf einer r3xx oder Nv3x Karte unkomprimiert vorliegen.

Demirug
2004-05-08, 21:34:28
Es gibt einen Trick wie man DXTC auf die gleiche Qualität wie mit 3dc kommen kann.

Man muss die X und Y Komponente der Normalmap nur auf die Alphakanäle von zwei Texturen aifteilen. Da man bei der Decalmap den Alphawert meist sowieso nicht braucht kann man dort X unterbringen und Y steckt man dann in eine andere Textur. Den Farbkanal dieser kann man dann noch anderweitig nutzen.

reunion
2004-05-08, 21:41:37
Original geschrieben von MadMan2k
3dc komprimiert 1:2, d.h. 50% ersparniss bei Normalmaps.


nein, 3dc komprimiert 4:1

Demirug
2004-05-08, 21:42:55
Original geschrieben von reunion
nein, 3dc komprimiert 4:1

Wenn man an die Milchmädchenrechnung von ATI glaubt. :D

reunion
2004-05-08, 21:53:44
Original geschrieben von Demirug
Wenn man an die Milchmädchenrechnung von ATI glaubt. :D

:???:
hab ich was verpasst?

StefanV
2004-05-08, 21:56:55
Original geschrieben von reunion
:???:
hab ich was verpasst?

Ja, hast du ;)

Beim Einsatz von 3dc wird ein Teil der Informationen einfach 'weggelassen' e voila: schon hab ich 'ne 2:1 Komprimierung.

Dummerweise dürfen die Shader umgeschrieben werden, damit man die fehlenden Informationen wiederherstellen kann.

reunion
2004-05-08, 22:00:44
Original geschrieben von Stefan Payne
Ja, hast du ;)

Beim Einsatz von 3dc wird ein Teil der Informationen einfach 'weggelassen' e voila: schon hab ich 'ne 2:1 Komprimierung.

Dummerweise dürfen die Shader umgeschrieben werden, damit man die fehlenden Informationen wiederherstellen kann.

Und warum spricht dann ATI von einer 4:1 komprimierung?

deekey777
2004-05-08, 22:02:20
Original geschrieben von reunion
Und warum spricht dann ATI von einer 4:1 komprimierung?

Das steht in irgendeinem Thread... :D

reunion
2004-05-08, 22:05:37
Original geschrieben von deekey777
Das steht in irgendeinem Thread... :D

Danke für den hinweis :fisch:

deekey777
2004-05-08, 22:07:50
Original geschrieben von reunion
Danke für den hinweis :fisch:

Immer gern!!! :bäh2:

StefanV
2004-05-08, 22:09:58
Original geschrieben von reunion
Und warum spricht dann ATI von einer 4:1 komprimierung?

Wieso?

4:1 stimmt doch *eg*

Wenn ich die hälfte der Infos entferne und den Rest mit 2:1 komprimiere hab ich am Ende eine 4:1 Komprimierung.

Demirug
2004-05-08, 22:14:32
Original geschrieben von reunion
Und warum spricht dann ATI von einer 4:1 komprimierung?

OK nochmal für alle die es noch nicht mitbekommen haben.

ATI rechnet wie folgt.

Texturen werden in 4*4 Texel Kacheln zerlegt. Deswegen müssen wir wir nur einen solchen Block berücksichtigen.

Die Grunddatenmenge ist also 4*4 = 16 Texel. Jeder Texel besteht aus 4 Komponeten a 8 Bit. Eine Kachel hat also 16*4*8 = 512 Bit. Nun wird komprimiert. Allerdings nur 2 Komponeten. X und Y. Für jeden der beiden Werte speichert man jeweils das minimum und das maximum. Also 2*2*8 = 32 Bit. Für jeden der 16 Texel wird nun noch mit 3 Bit (jeweils für X und Y) der lineare Faktor zwischen minmum und maximum angegeben. Also 16*2*3 = 96 Bit. Macht zusammen 32 Bit + 96 Bit = 128 Bit.

512 Bit : 128 Bit is gleich 4:1.

In wirklichkeit hat ATI aber keine 16 Texel mit 4 Komponeten a 8 Bit komprimiert sondern nur 16 Texel mit 2 Komponeten a 8 Bit. 16*2*8 = 256 Bit. Also

256 Bit : 128 Bit is gleich 2:1

ATI war also einfach so unverschämt und hat die 50% die man durch das wegstreichen der beiden Komponeten gespart hat auch als Kompressiongewinn von 3dc verbucht.

reunion
2004-05-08, 22:21:09
Original geschrieben von Demirug
OK nochmal für alle die es noch nicht mitbekommen haben.

ATI rechnet wie folgt.

Texturen werden in 4*4 Texel Kacheln zerlegt. Deswegen müssen wir wir nur einen solchen Block berücksichtigen.

Die Grunddatenmenge ist also 4*4 = 16 Texel. Jeder Texel besteht aus 4 Komponeten a 8 Bit. Eine Kachel hat also 16*4*8 = 512 Bit. Nun wird komprimiert. Allerdings nur 2 Komponeten. X und Y. Für jeden der beiden Werte speichert man jeweils das minimum und das maximum. Also 2*2*8 = 32 Bit. Für jeden der 16 Texel wird nun noch mit 3 Bit (jeweils für X und Y) der lineare Faktor zwischen minmum und maximum angegeben. Also 16*2*3 = 96 Bit. Macht zusammen 32 Bit + 96 Bit = 128 Bit.

512 Bit : 128 Bit is gleich 4:1.

In wirklichkeit hat ATI aber keine 16 Texel mit 4 Komponeten a 8 Bit komprimiert sondern nur 16 Texel mit 2 Komponeten a 8 Bit. 16*2*8 = 256 Bit. Also

256 Bit : 128 Bit is gleich 2:1

ATI war also einfach so unverschämt und hat die 50% die man durch das wegstreichen der beiden Komponeten gespart hat auch als Kompressiongewinn von 3dc verbucht.

Ahh, danke, also nichts als marktinggeblubber, nur warum wird nur X und Y und nicht auch Z komprimiert?

Demirug
2004-05-08, 22:28:48
Original geschrieben von reunion
Ahh, danke, also nichts als marktinggeblubber, nur warum wird nur X und Y und nicht auch Z komprimiert?

Genau weiss ich es auch nicht aber ohne Z bleibt man bei 128 Bit pro Block. Das entspricht auch den meisten DXTC Verfahren. Zudem braucht man so auch nur 2 Dekompressionblöcke (wie auch bei DXTC). Den einen (Bei DXTC für Alpha zuständig) kann man 1:1 benutzten und den zweiten musste man nur etwas aufbohren. Hätte man auch noch Z Komprimiert wäre eine neuen Address und Chachelogik sowie ein zusätzlicher Dekompressionblock fällig gewesen.

r@h
2004-05-08, 23:15:13
Original geschrieben von Mr. Lolman
Wer als NV3x User, die Ruby Demo etwas flüssiger betrachten will, kann das, in dem er einfach die ATi Shader verwendet...

(B3d Forum) Sieht echt übel aus, wenn man das tut.

Razor

r@h
2004-05-08, 23:26:23
@Demirug

Wenn man sich das so alles anhört... welcher 'Vorteil' ergibt sich denn dann noch aus 3Dc ?
Vor allem, wenn das ein 'wenig' verbreiteter Standard ist ?
:???:

Und was mir noch viel mehr am Herzen liegt: Heißt das defakto, dass diese 'Technik' nichts anderes macht, als der Engine eben 'mehr' verfügbaren Video-RAM zur Verfügung zu stellen, als physisch auf der Karte vorhanden (wie bei allen anderen Kompressionsverfahren auch) ?

Sorry, wenn das hier OT sein sollte und evtl. auch schon woanders diskkutiert wurde...

Razor

tokugawa
2004-05-08, 23:35:32
Original geschrieben von Demirug
OK nochmal für alle die es noch nicht mitbekommen haben.

ATI rechnet wie folgt.

Texturen werden in 4*4 Texel Kacheln zerlegt. Deswegen müssen wir wir nur einen solchen Block berücksichtigen.

Die Grunddatenmenge ist also 4*4 = 16 Texel. Jeder Texel besteht aus 4 Komponeten a 8 Bit. Eine Kachel hat also 16*4*8 = 512 Bit. Nun wird komprimiert. Allerdings nur 2 Komponeten. X und Y. Für jeden der beiden Werte speichert man jeweils das minimum und das maximum. Also 2*2*8 = 32 Bit. Für jeden der 16 Texel wird nun noch mit 3 Bit (jeweils für X und Y) der lineare Faktor zwischen minmum und maximum angegeben. Also 16*2*3 = 96 Bit. Macht zusammen 32 Bit + 96 Bit = 128 Bit.

512 Bit : 128 Bit is gleich 4:1.

In wirklichkeit hat ATI aber keine 16 Texel mit 4 Komponeten a 8 Bit komprimiert sondern nur 16 Texel mit 2 Komponeten a 8 Bit. 16*2*8 = 256 Bit. Also

256 Bit : 128 Bit is gleich 2:1

ATI war also einfach so unverschämt und hat die 50% die man durch das wegstreichen der beiden Komponeten gespart hat auch als Kompressiongewinn von 3dc verbucht.


Frage: rechnet 3Dc da auch irgendwie mit ein, dass bei Normalmaps im Tangentspace in der Regel die Komponente des Normalvektors, die "wegzeigt" (Y, soweit ich weiß), einen höheren Betrag hat als die restlichen Komponenten? Soll heißen, ist 3Dc jetzt wirklich auf Normalmaps optimiert, und nimmt deren spezielle Topologie unter Betracht?

Demirug
2004-05-08, 23:45:51
Original geschrieben von r@h
@Demirug

Wenn man sich das so alles anhört... welcher 'Vorteil' ergibt sich denn dann noch aus 3Dc ?
Vor allem, wenn das ein 'wenig' verbreiteter Standard ist ?
:???:

Und was mir noch viel mehr am Herzen liegt: Heißt das defakto, dass diese 'Technik' nichts anderes macht, als der Engine eben 'mehr' verfügbaren Video-RAM zur Verfügung zu stellen, als physisch auf der Karte vorhanden (wie bei allen anderen Kompressionsverfahren auch) ?

Sorry, wenn das hier OT sein sollte und evtl. auch schon woanders diskkutiert wurde...

Razor

Ja, eine mit 3dc komprimerte 2 Komponeten Normalmap braucht nur noch die Hälfte des Viedeospeichers. Das ist dann auch eigentlich schon der einzigen Vorteil. Gegenüber den standard Kompressionsverfahren hat 3dc eben den Vorteil das die Kompressionsfehler in der Regel kleiner sind.

Demirug
2004-05-08, 23:50:55
Original geschrieben von tokugawa
Frage: rechnet 3Dc da auch irgendwie mit ein, dass bei Normalmaps im Tangentspace in der Regel die Komponente des Normalvektors, die "wegzeigt" (Y, soweit ich weiß), einen höheren Betrag hat als die restlichen Komponenten? Soll heißen, ist 3Dc jetzt wirklich auf Normalmaps optimiert, und nimmt deren spezielle Topologie unter Betracht?

Z "zeigt normalerweise weg". Da Z ja im PS wieder errechnet wird stellt das ja kein Problem da. 3dc ist einfach daraus ausgelegt zwei 8 Bit Werte unabhängig voneinader zu komprimieren. Die Standardverfahren komprimieren ja die Farbe (RGA) gemeinsam und nur Alpha getrennt.

r@h
2004-05-08, 23:54:39
Original geschrieben von Demirug
Ja, eine mit 3dc komprimerte 2 Komponeten Normalmap braucht nur noch die Hälfte des Viedeospeichers. Das ist dann auch eigentlich schon der einzigen Vorteil. Gegenüber den standard Kompressionsverfahren hat 3dc eben den Vorteil das die Kompressionsfehler in der Regel kleiner sind. Ah ja...
Thx Demirug.

Und wenn ich jetzt noch fragen würde, wie groß die wahrscheinlichkeit wäre, dass dieses Feature (ausser in ATI-TechDemos) auch von den Entwicklern eingesetzt wird, sprengt das u.U. den (OT) Rahmen, gell ?

Hört sich für mich eben sehr aufwändig an, Texturen einmal komplett als zweiten Satz vorzuhalten und entsprechend zu komprimieren und dies dann auch noch in der Engine explizit (zusätzlich) zu unterstützen, wenn man eine breite Hardwarebasis bedienen möchte. Mit einem Patch wäre es sicher nicht getan, wenn man sich da Games wie FarCry anschaut, es sei denn, es gibt dann sog. Patch-DVD's.

OK, das war jetzt ein bissel sarkastisch, aber ich vermute einfach mal, dass der Aufwand angedenk der minimalen Hardware-Basis dem Nutzen einfach nicht gerecht wird.

Razor

tokugawa
2004-05-09, 00:03:00
Original geschrieben von r@h
Ah ja...
Thx Demirug.

Und wenn ich jetzt noch fragen würde, wie groß die wahrscheinlichkeit wäre, dass dieses Feature (ausser in ATI-TechDemos) auch von den Entwicklern eingesetzt wird, sprengt das u.U. den (OT) Rahmen, gell ?

Hört sich für mich eben sehr aufwändig an, Texturen einmal komplett als zweiten Satz vorzuhalten und entsprechend zu komprimieren und dies dann auch noch in der Engine explizit (zusätzlich) zu unterstützen, wenn man eine breite Hardwarebasis bedienen möchte. Mit einem Patch wäre es sicher nicht getan, wenn man sich da Games wie FarCry anschaut, es sei denn, es gibt dann sog. Patch-DVD's.

OK, das war jetzt ein bissel sarkastisch, aber ich vermute einfach mal, dass der Aufwand angedenk der minimalen Hardware-Basis dem Nutzen einfach nicht gerecht wird.

Razor

ATI wird da schon Libraries haben, mit denen man auch zur Laufzeit (etwa beim Laden eines Levels) die Normalmaps komprimieren kann... da müsste man nicht mal ein zweites Set an Normalmaptexturen haben (nur wird das Level-Laden wohl etwas länger dauern), da man es ja aus den unkomprimierten generieren kann.

Demirug
2004-05-09, 00:03:46
Original geschrieben von r@h
Ah ja...
Thx Demirug.

Und wenn ich jetzt noch fragen würde, wie groß die wahrscheinlichkeit wäre, dass dieses Feature (ausser in ATI-TechDemos) auch von den Entwicklern eingesetzt wird, sprengt das u.U. den (OT) Rahmen, gell ?

Hört sich für mich eben sehr aufwändig an, Texturen einmal komplett als zweiten Satz vorzuhalten und entsprechend zu komprimieren und dies dann auch noch in der Engine explizit (zusätzlich) zu unterstützen, wenn man eine breite Hardwarebasis bedienen möchte. Mit einem Patch wäre es sicher nicht getan, wenn man sich da Games wie FarCry anschaut, es sei denn, es gibt dann sog. Patch-DVD's.

OK, das war jetzt ein bissel sarkastisch, aber ich vermute einfach mal, dass der Aufwand angedenk der minimalen Hardware-Basis dem Nutzen einfach nicht gerecht wird.

Razor

ATI gibt ja an das es einige Entwickler nutzen wollen.

Die komprimierten Texturen kann man notfalls aus den unkomprimierten auch beim Endkunden erzeugen. Bei Laden gibt es kaum einen unterschied. Letzten Ende muss man beim Anlagen der Textur eben nur ein anderes Format angeben.

Das viel grössere Ärgernis ist das umschreiben der Shader. Wenn man 3dc von Anfang an berücksichtigt hält sich das in Grenzen. Baut man es allerdings nachträglich ein muss man jeden Shader mit einer Normalmap nochmal anfassen. Hier hat IMHO ATI einfach geschlafen. Sie hätte das ganze für die Entwickler besser automatisieren müssen. Der Code für das berechnen der Z-Komponete hätte der Treiber beim berweden einer 3dc textur einfach automatisch einfügen müssen wenn die Z-Komponete gebraucht wird.

tokugawa
2004-05-09, 00:06:17
Original geschrieben von Demirug
Z "zeigt normalerweise weg". Da Z ja im PS wieder errechnet wird stellt das ja kein Problem da. 3dc ist einfach daraus ausgelegt zwei 8 Bit Werte unabhängig voneinader zu komprimieren. Die Standardverfahren komprimieren ja die Farbe (RGA) gemeinsam und nur Alpha getrennt.


Ah, mich bitte schlagen... mein Hirn hat da etwas geschlafen (ich hab irgendwie einfach nur den "Merksatz" gehabt, dass Normalmaps als RGB-Images interpretiert bläulich sind, aber hab irgendwie "blau" als mittlere Komponente gedacht...)... hab den Schmarrn mit Y auch irgendwo anders geschrieben, find ich aber bei der Post-Flut im Forum nicht mehr...

r@h
2004-05-09, 00:17:10
Original geschrieben von tokugawa
ATI wird da schon Libraries haben, mit denen man auch zur Laufzeit (etwa beim Laden eines Levels) die Normalmaps komprimieren kann... da müsste man nicht mal ein zweites Set an Normalmaptexturen haben (nur wird das Level-Laden wohl etwas länger dauern), da man es ja aus den unkomprimierten generieren kann. Nun ja... der Vorteil ist ja, dass eben mehr Normalmaps in den Video-Speicher passen, als mit ohne 3Dc (gut Wortwahl ;-). Mir geht es da eigentlich mehr um das Basis-Design des Games. 'Rechne' ich nun mit dem größeren Video-Speicher, oder eben nicht. DAS ist doch die entscheidende Frage.

Wenn ich also annehmen muss, dass der Gros an Hardware dieses Feature nicht unterstützt, darf ich nicht damit rechnen und so braucht's einen 2. Satz an Texturen, der dann mit diesem Feature eben mehr Details zuläßt und explizit für die unterstützende Hardware bereit gestellt werden muss. Von der expliziten Unterstützung in der Engine mal ganz abgesehen (die ich mir nicht so sonderlich komplex vorstelle).

Und wenn Du auf den geringeren Traffic über den Bus anspielst, dann kann ich dazu nur anmerken, dass es sicher nicht 'wirtschaftlicher' ist, die Textueren erst einmal via CPU zu komprimieren, um sie dann über den Bus in den Video-Speicher zu schicken und dort dann die GPU damit zu beauftragen, das ganze dann zur Laufzeit wieder zu entpacken...

Razor

Mr. Lolman
2004-05-09, 00:19:51
Original geschrieben von r@h
Und wenn Du auf den geringeren Traffic über den Bus anspielst, dann kann ich dazu nur anmerken, dass es sicher nicht 'wirtschaftlicher' ist, die Textueren erst einmal via CPU zu komprimieren, um sie dann über den Bus in den Video-Speicher zu schicken und dort dann die GPU damit zu beauftragen, das ganze dann zur Laufzeit wieder zu entpacken...

Razor


Doch ist es, sofern die Texturen, nur ein einziges Mal, am Besten gleich bei der Installation des Spieles, komprimiert werden....

r@h
2004-05-09, 00:26:00
Original geschrieben von Demirug
ATI gibt ja an das es einige Entwickler nutzen wollen.Zur not wird ATI eben die Entwickler dafür 'bezahlen'.
(was auch immer darunter zu vestehen ist ;-)
Original geschrieben von Demirug
Die komprimierten Texturen kann man notfalls aus den unkomprimierten auch beim Endkunden erzeugen. Bei Laden gibt es kaum einen unterschied. Letzten Ende muss man beim Anlagen der Textur eben nur ein anderes Format angeben.Deswegen ja meine vorherige Anmerkung...
Was für einen Sinn soll das haben, wenn nicht jede Hardware dies unterstützt ?
Original geschrieben von Demirug
Das viel grössere Ärgernis ist das umschreiben der Shader. Wenn man 3dc von Anfang an berücksichtigt hält sich das in Grenzen. Baut man es allerdings nachträglich ein muss man jeden Shader mit einer Normalmap nochmal anfassen. Hier hat IMHO ATI einfach geschlafen. Sie hätte das ganze für die Entwickler besser automatisieren müssen. Der Code für das berechnen der Z-Komponete hätte der Treiber beim berweden einer 3dc textur einfach automatisch einfügen müssen wenn die Z-Komponete gebraucht wird. Das ist allerdings schlecht.
Hätte mir das irgendwie einfacher vorgestellt...
(wie eben den von Dir genannten Automatismus über den Treiber)

Na ja, hoffen wir mal, dass dieses Feature nicht genauso untergeht, wie seinerzeit dieses Zeugs für das Dolphin-Demo. War ja auch mal dafür gedacht, Polygone zu 'sparen'... nur leider ist mangels (zu geringer) Entwickler-Unterstützung nichts daraus geworden... wohl auch, weil der konkrete Aufwand, diese Technologie 'vernünftig' zu implementieren, von den meisten unterschätzt wurde.

Razor

MadMan2k
2004-05-09, 00:27:56
Original geschrieben von r@h
Nun ja... der Vorteil ist ja, dass eben mehr Normalmaps in den Video-Speicher passen, als mit ohne 3Dc (gut Wortwahl ;-). Mir geht es da eigentlich mehr um das Basis-Design des Games. 'Rechne' ich nun mit dem größeren Video-Speicher, oder eben nicht. DAS ist doch die entscheidende Frage.

Wenn ich also annehmen muss, dass der Gros an Hardware dieses Feature nicht unterstützt, darf ich nicht damit rechnen und so braucht's einen 2. Satz an Texturen, der dann mit diesem Feature eben mehr Details zuläßt und explizit für die unterstützende Hardware bereit gestellt werden muss.
siehs mal von der anderen Seite:
du kannst dem Spiel per default detaillierte 3dc Komprimierte Texturen mitliefern und bei der Installation abfragen ob 3dc vorhanden ist.
Wenn nicht werden die Texturen dekomprimiert und in eine niedrigere Auflösung runtergerechnet, damit sie den VRAM nicht sprengen.

r@h
2004-05-09, 00:28:33
Original geschrieben von Mr. Lolman
Doch ist es, sofern die Texturen, nur ein einziges Mal, am Besten gleich bei der Installation des Spieles, komprimiert werden.... Selbst wenn das so ist...
Welchen Sinn soll das haben ? Geringerer Bus-Trafic ?
Wäre das einzige, was mir jetzt spontan einfällt...

Razor

r@h
2004-05-09, 00:31:06
Original geschrieben von MadMan2k
siehs mal von der anderen Seite:
du kannst dem Spiel per default detaillierte 3dc Komprimierte Texturen mitliefern und bei der Installation abfragen ob 3dc vorhanden ist.
Wenn nicht werden die Texturen dekomprimiert und in eine niedrigere Auflösung runtergerechnet, damit sie den VRAM nicht sprengen. Und wie sollte ein Entwickler diesen Aufwand rechtfertigen ?
:???:

Man müsste also lediglich für eine äusserst dünne Hardware-Basis sehr detailiierte Texturen 'basteln', die aber auf dem Gros der Hardware da draußen herunter gerechnet werden muss.

Wozu ?
Welcher (wirtschaftliche) Sinn soll sich dahinter verbergen ?
:???:

Razor

tokugawa
2004-05-09, 00:32:20
Original geschrieben von r@h
Nun ja... der Vorteil ist ja, dass eben mehr Normalmaps in den Video-Speicher passen, als mit ohne 3Dc (gut Wortwahl ;-). Mir geht es da eigentlich mehr um das Basis-Design des Games. 'Rechne' ich nun mit dem größeren Video-Speicher, oder eben nicht. DAS ist doch die entscheidende Frage.

Wenn ich also annehmen muss, dass der Gros an Hardware dieses Feature nicht unterstützt, darf ich nicht damit rechnen und so braucht's einen 2. Satz an Texturen, der dann mit diesem Feature eben mehr Details zuläßt und explizit für die unterstützende Hardware bereit gestellt werden muss. Von der expliziten Unterstützung in der Engine mal ganz abgesehen (die ich mir nicht so sonderlich komplex vorstelle).


Da hast du recht! Wenn man den eigentlichen Vorteil von 3Dc ausnutzen will (mehr Platz für mehr Normalmaps), muß man entweder ein höher-auflösendes Set mitführen (und dann jeweils runterrechnen oder komprimieren auf die konkrete Hardware), oder gleich zwei Sets (normales, und 3Dc-komprimiertes, das dann auch höherauflösend sein kann). Diesselbe Problemstellung gibt's aber auch bei der "normalen" Image-Texture-Compression.

Original geschrieben von r@h
Und wenn Du auf den geringeren Traffic über den Bus anspielst, dann kann ich dazu nur anmerken, dass es sicher nicht 'wirtschaftlicher' ist, die Textueren erst einmal via CPU zu komprimieren, um sie dann über den Bus in den Video-Speicher zu schicken und dort dann die GPU damit zu beauftragen, das ganze dann zur Laufzeit wieder zu entpacken...

Razor

Ich spiel darauf nicht an. Aber hier muß man anmerken, dass man zwei Situationen "zur Laufzeit" bedenken muß: zur Laufzeit des Spiels selbst, oder zur Laufzeit, während eines Ladevorgangs (der nur einmal pro Level etwa gemacht wird).

Bei letzterem (einmal-laden/komprimieren) wäre der einmalige Kompressionsaufwand "feasable", bei ersteren natürlich nicht.

tokugawa
2004-05-09, 00:34:22
Original geschrieben von Mr. Lolman
Doch ist es, sofern die Texturen, nur ein einziges Mal, am Besten gleich bei der Installation des Spieles, komprimiert werden....

Fände es aber besser wenn's beim jeweiligen Level-Ladescreen geschieht...

Wenn es nämlich die Texturen das eine Mal während der Installation vorbereitet werden, und man dann die Grafikkarte wechselt, kann man das Spiel neu installieren...

tokugawa
2004-05-09, 00:37:46
Original geschrieben von r@h
Und wie sollte ein Entwickler diesen Aufwand rechtfertigen ?
:???:

Man müsste also lediglich für eine äusserst dünne Hardware-Basis sehr detailiierte Texturen 'basteln', die aber auf dem Gros der Hardware da draußen herunter gerechnet werden muss.

Wozu ?
Welcher (wirtschaftliche) Sinn soll sich dahinter verbergen ?
:???:

Razor

ATI promoten + Sponsoringvertrag mittels "Get in the Game" :D da hast du einen wirtschaftlichen Grund.


Na aber im Ernst: wenn man 3Dc wirklich einsetzen will, muß man wohl auf eine der genannten Varianten setzen. Dasselbe "Problem" hat man ja eigentlich auch bei normalen Texturen (wo man auch on-the-fly beim Laden komprimieren kann, aber da der Vorteil wiederum eine Platzersparnis und somit die Fähigkeit ist, mehr/größere Textures zu laden, muß man bei normalen Image-Texturen sich auch überlegen: führt man ultra-detaillierte mit und rechnet die dann runter, oder führt man vorkomprimierte ultra-detaillierte mit und rechnet die dann runter (oder schiebt sie gleich in die Grafikkarte), oder führt man mehrere Sets mit).

MadMan2k
2004-05-09, 00:39:19
Original geschrieben von r@h
Man müsste also lediglich für eine äusserst dünne Hardware-Basis sehr detailiierte Texturen 'basteln', die aber auf dem Gros der Hardware da draußen herunter gerechnet werden muss.

In der Regel werden die Texturen in einer höheren Auflösung erstellt, als der in der sie dann letztendlich verwendet werden.
Von daher fällt dieser "Aufwand" weg.

Der wirtschaftliche Sinn ist derselbe, wieso jemand seine Shader nochmal nach SM3.0 kompilieren sollte, nämlich um den Enthusiast-Markt anzusprechen.

Im übrigen kann das ganze so unwirtschaftlich nicht sein - ich will dich nur mal an die S3TC Texturen von UT99 erinnern, die damals noch S3 exclusiv waren...

r@h
2004-05-09, 00:45:41
Original geschrieben von MadMan2k
Im übrigen kann das ganze so unwirtschaftlich nicht sein - ich will dich nur mal an die S3TC Texturen von UT99 erinnern, die damals noch S3 exclusiv waren... Falsch... schließlich war auch die gf1 schon in der Lage S3TC-Texturen zu 'verdauen'. War wohl aber eine Treiberseitige Angelegenheit und da die gf1 genug Speicher hatte (32MB waren damals eine Menge ;-) wurden die S3TC-Texturen wohl erst 'dekomprmiert' um sie dann unkomprimiert (oder eben via DXT1/5 wieder komprimiert) an den Treiber weiter zu geben...

Razor

tokugawa
2004-05-09, 00:49:43
Was ich mich ja frage ist... wie die die "doppelte Auflösung" nutzen werden.


Im Prinzip wäre ja eine sichtbare Anwendung, wenn man höherauflösende Normalmaps verwendet (also 2x die Texel).

Aber: ein Sprung von 256x256 auf 512x512 wäre ja die 4-fache Texelanzahl.

Werden die jetzt eher so Sprünge wie von 256x256 auf 512x256 bzw 256x512 machen? Dann wäre die Auflösungserhöhung aber irgendwie in eine Texturkoordinatenrichtung limitiert... es sei denn man mappt das Model neu, um die höhere Auflösung in S- und T-Koordinaten-Richtung auszunutzen. Aber das wär dann schon wieder ein ziemlich hoher Aufwand, ob sich das lohnt?

r@h
2004-05-09, 01:03:20
@tokugawa
Original geschrieben von tokugawa
ATI promoten + Sponsoringvertrag mittels "Get in the Game" :D da hast du einen wirtschaftlichen Grund.Ja, daran hab' ich auch schon gedacht !
:D

Aber zur eigentlichen Frage...

Für mich sieht das Ganze eher so aus, als ob das ein reiner Marketing-Gag von ATI ist, um Technologie vorzutäuschen, wo eigentlich nicht viel dahinter ist. Ich bekomme also in einer 256MB-Karte mehr unter, als hinein geht (wie und warum mag jetzt mal dahin gestellt sein).
256MB wohlgemerkt !

Der Standard darf wohl heute bei 64MB gesehen werden, denn jede 08/15-Karte hat heute 64MB. Der Anteil an 128MB Hardware ist aber schon sehr groß und wächst permanent und wird sich wohl zum kommenden Standard mausern. Der Anteil von 256MB-Hardware hingegen ist verschwindend gering.

Jetzt zeigt ATI ein Demo, welches es erlaubt, Texturen für eine 512MB-Karte (oder eben ca. 300MB, wie Quasar jetzt anführte) auf einer 256MB-Karte zu laden.

-

Verstehst Du nun mein Problem ?

Für welche Hardwarebasis sollen Entwickler den Aufwand auf sich nehmen ?
:???:

Für 512MB-Hardware etwa ?
Wohl kaum...

Für 256MB-Hardware ?
Eher unwahrscheinlich, da 3Dc ja offenbar nicht genug bringt, um den benötigten Video-Speicher um die Hälfte zu reduzieren, um dies dann z.Bsp. wenigstens auf den X800SE zum Laufen zu bewegen.

Für 128MB-Hardware ?
Ja, wird vermutlich auch gemacht. Durch Kompressionen oder/und Herunterschrauben der Details wird's dann auf Sub-128MB-Hardware lauffähig gemacht.

-

Größere Texturen bedeuten dann auch mehr Medien, die an die Kunden ausgeliefert werden müssen (im Falle von FarCry wären das dann mal eben locker 2 DVD's !)... und das alles dann für das bissel Hardware ?

Neee...

Und wenn der Aufwand dann auch noch in der Texturauflösung selber steckt (wie ja gerade in Deinem letzten Post beschrieben), wage ich doch sehr zu bezeifeln, dass der Aufwand gerechtfertigt ist.

Es ist ja eine Sache ein bissel Eye-Candy via SM2/3-Shader mit ein paar Zeilen Code in die Engine zu packen, eine andere aber, die Texturen selbst anzufassen (und evtl. sogar noch höhere Kosten für die Publisher zu verursachen).

Na ja, wir werden sehen...

Razor

MadMan2k
2004-05-09, 01:09:31
Original geschrieben von r@h
Falsch... schließlich war auch die gf1 schon in der Lage S3TC-Texturen zu 'verdauen'.

aber der OpenGL Renderer, der die Texturen nutzbar machte kahm erst am 26. September 2000 - also fast ein Jahr später.
Ergo waren die Texturen nur als S3 only konzepiert.


War wohl aber eine Treiberseitige Angelegenheit (..murks..)
jo, weil die S3TC-Kompression vorerst an die Metal Schnittstelle gekoppelt war.
Erst als S3 Lizenzen an Ati & Nvidia verkauft hat, war sie auch in OpenGL drin.

tokugawa
2004-05-09, 01:09:46
Original geschrieben von r@h
@tokugawa
Ja, daran hab' ich auch schon gedacht !
:D

Aber zur eigentlichen Frage...

Für mich sieht das Ganze eher so aus, als ob das ein reiner Marketing-Gag von ATI ist, um Technologie vorzutäuschen, wo eigentlich nicht viel dahinter ist. Ich bekomme also in einer 256MB-Karte mehr unter, als hinein geht (wie und warum mag jetzt mal dahin gestellt sein).
256MB wohlgemerkt !

Der Standard darf wohl heute bei 64MB gesehen werden, denn jede 08/15-Karte hat heute 64MB. Der Anteil an 128MB Hardware ist aber schon sehr groß und wächst permanent und wird sich wohl zum kommenden Standard mausern. Der Anteil von 256MB-Hardware hingegen ist verschwindend gering.

Jetzt zeigt ATI ein Demo, welches es erlaubt, Texturen für eine 512MB-Karte (oder eben ca. 300MB, wie Quasar jetzt anführte) auf einer 256MB-Karte zu laden.

-

Verstehst Du nun mein Problem ?

Für welche Hardwarebasis sollen Entwickler den Aufwand auf sich nehmen ?
:???:

Für 512MB-Hardware etwa ?
Wohl kaum...

Für 256MB-Hardware ?
Eher unwahrscheinlich, da 3Dc ja offenbar nicht genug bringt, um den benötigten Video-Speicher um die Hälfte zu reduzieren, um dies dann z.Bsp. wenigstens auf den X800SE zum Laufen zu bewegen.

Für 128MB-Hardware ?
Ja, wird vermutlich auch gemacht. Durch Kompressionen oder/und Herunterschrauben der Details wird's dann auf Sub-128MB-Hardware lauffähig gemacht.

-

Größere Texturen bedeuten dann auch mehr Medien, die an die Kunden ausgeliefert werden müssen (im Falle von FarCry wären das dann mal eben locker 2 DVD's !)... und das alles dann für das bissel Hardware ?

Neee...

Und wenn der Aufwand dann auch noch in der Texturauflösung selber steckt (wie ja gerade in Deinem letzten Post beschrieben), wage ich doch sehr zu bezeifeln, dass der Aufwand gerechtfertigt ist.

Es ist ja eine Sache ein bissel Eye-Candy via SM2/3-Shader mit ein paar Zeilen Code in die Engine zu packen, eine andere aber, die Texturen selbst anzufassen (und evtl. sogar noch höhere Kosten für die Publisher zu verursachen).

Na ja, wir werden sehen...

Razor

Ich hab mich auch schon gefragt, wozu man noch zusätzlich weitere Texturkompressionen braucht, wenn die durchschnittliche RAM-Bestückung heutiger Grafikkarten kaum ausgenutzt wird...

Andererseits könnte man ja Texturen anstatt zu speichern während des Ladescreens prozedural generieren (wie in diesem 96KB First-Person-Shooter-Demo)... aber dann dauert das Laden noch länger als es heute schon dauert (was mir ehrlich gesagt schon heutzutage zu lang ist) - speziell wenn man Texturen/Normalmaps irgendwie fraktal generiert :)

MadMan2k
2004-05-09, 01:17:52
Original geschrieben von tokugawa
Was ich mich ja frage ist... wie die die "doppelte Auflösung" nutzen werden.


Im Prinzip wäre ja eine sichtbare Anwendung, wenn man höherauflösende Normalmaps verwendet (also 2x die Texel).

Aber: ein Sprung von 256x256 auf 512x512 wäre ja die 4-fache Texelanzahl.

320x320 bzw. 384x384 ?
mann muss die ja nicht genau doppelt so groß machen, oder?

tokugawa
2004-05-09, 01:19:08
Original geschrieben von MadMan2k
320x320 bzw. 384x384 ?
mann muss die ja nicht genau doppelt so groß machen, oder?

Ach ja, ich vergaß, irgendwann fiel ja der Zwang zu Zweierpotenzen bei Texturen...

Naja, so würd's natürlich gehen.

EDIT: wobei ich natürlich nicht weiß ob non-power-of-2 Texturen von der R420 unterstützt werden (unter OpenGL etwa GL_ARB_texture_non_power_of_two). Sinn würde es auf jeden Fall machen.

MadMan2k
2004-05-09, 01:20:59
Original geschrieben von tokugawa
Ich hab mich auch schon gefragt, wozu man noch zusätzlich weitere Texturkompressionen braucht, wenn die durchschnittliche RAM-Bestückung heutiger Grafikkarten kaum ausgenutzt wird...

du scheinst zu vergessen, dass es vom R420 noch kleinere Ausgaben geben wird - mit weniger RAM.

Außerdem geht ja jetzt schon UT2004 an die Grenzen von 128MB (AA ist nicht mehr drin) - obwohl S3TC verwendet wird...

tokugawa
2004-05-09, 01:33:03
Original geschrieben von MadMan2k
du scheinst zu vergessen, dass es vom R420 noch kleinere Ausgaben geben wird - mit weniger RAM.

Außerdem geht ja jetzt schon UT2004 an die Grenzen von 128MB (AA ist nicht mehr drin) - obwohl S3TC verwendet wird...

Für die kleineren RAM-Ausbaustufen macht es sicher Sinn.

Allerdings will man das Feature ja irgendwie auch mit der Highend-Karte nutzen können, und eine Karte mit 256 MB könnte ganz schön große oder ganz schön viele komprimierte Texturen laden (sagen wir das Äquivalent von 512 MB nicht-komprimierten).

Sagen wir das Spiel hat 16 Szenarien, in denen es neu laden muß (jedesmal sagen wir halt 500 MB Texturen). Das wären dann Daumen mal Pi 16*500 MB (ok, garantiert etwas weniger, man will ja auch noch Geometrie und so speichern).

Natürlich könnte man die Texturen auch hochauflösend 3Dc + DXTC komprimiert liefern (oder überhaupt komprimiert liefern) und dann halt jeweils auf die Target-Hardware umrechnen. Dann hätte man Daumen mal Pi 16*256 MB Texturen (auch hier in der Praxis weniger).

Dann ist dann noch der Aufwand für Texture-Artists: von vorhandenen Texturen höhere Versionen machen ist mal nicht sooo wenig Aufwand - selbst mit Normalmap-Generation Tools wie NVIDIA MeLODy oder das in Doom 3 verwendete (immerhin müsste man jede Normalmap neu generieren in der höheren Auflösung).

Es wird also vermutlich nicht in bereits existierende Engines eingebaut werden können - oder nicht so einfach (auch weil die Shader die Normalmaps verwenden modifiziert werden müssen).

Sagen wir so: ein Vorteil ist sicher da, aber der Aufwand, das einzubauen, ist nicht zu unterschätzen.

Und um es mal ganz frech mit Birnen zu vergleichen: SM 3.0 implementieren wäre einfacher, da man Shader getrennt von der Engine entwickeln kann (dazu sind Tools wie FX Composer da).

Mit anderen Worten: vermutlich (das spekuliere ich hier, aber gut begründet) werden wir früher SM 3.0 Spiele sehen als 3Dc Spiele.

Dann stellt sich hier natürlich wieder die Frage ob wir zur "Lebenszeit" des R420 noch 3Dc-Spiele sehen werden.

Mr. Lolman
2004-05-09, 01:44:47
Original geschrieben von r@h
Selbst wenn das so ist...
Welchen Sinn soll das haben ? Geringerer Bus-Trafic ?
Wäre das einzige, was mir jetzt spontan einfällt...

Razor

Mehr Speed, da geringere Speicherbelegung?

Original geschrieben von tokugawa
Fände es aber besser wenn's beim jeweiligen Level-Ladescreen geschieht...

Wenn es nämlich die Texturen das eine Mal während der Installation vorbereitet werden, und man dann die Grafikkarte wechselt, kann man das Spiel neu installieren...

Dann würde jeder Ladescreeen länger dauern, als kürzer. wenn er nur die komprimierten Texturen laden müsste. Das Installationmenü kann man ja so gestalten, dass wahlweise alle, nur komprimierte, oder nur unkomprimierte Texturen installiert werden sollen.

r@h
2004-05-09, 02:10:15
Original geschrieben von tokugawa
Ich hab mich auch schon gefragt, wozu man noch zusätzlich weitere Texturkompressionen braucht, wenn die durchschnittliche RAM-Bestückung heutiger Grafikkarten kaum ausgenutzt wird...Ahhh... Du verstehst mich... ;)
Original geschrieben von tokugawa
Andererseits könnte man ja Texturen anstatt zu speichern während des Ladescreens prozedural generieren (wie in diesem 96KB First-Person-Shooter-Demo)... aber dann dauert das Laden noch länger als es heute schon dauert (was mir ehrlich gesagt schon heutzutage zu lang ist) - speziell wenn man Texturen/Normalmaps irgendwie fraktal generiert :) Ja.

Und dieses Demo war wirklich außerordentlich beeindruckend.
Keine Ahnung wie das komprimiert wurde... wohl tatsächlich irgendein fraktaler Algorithmus.

Wenn ich mir allerdings vorstelle, dass man man das bei heutigen Games ähnlich handhabt...
*graus*
;-)

Razor

r@h
2004-05-09, 02:16:49
Original geschrieben von Mr. Lolman
Mehr Speed, da geringere Speicherbelegung?:???:
Original geschrieben von Mr. Lolman
Dann würde jeder Ladescreeen länger dauern, als kürzer. wenn er nur die komprimierten Texturen laden müsste. Das Installationmenü kann man ja so gestalten, dass wahlweise alle, nur komprimierte, oder nur unkomprimierte Texturen installiert werden sollen. Du vergißt den Dau vor der Mattscheibe... nix da mit irgendwelchen Fragen über komprimierte oder unkomprimierte Texturen. Oder meinst Du ernsthaft, dass der Normalo vor dem Bildschirm weiß, was Texturen sind ?

Aber auch sonst finde ich Deine Lösung... sagen wir mal... "unglücklich" !
:D

Wie gehabt würde einfach alle Texturen installiert...
(Festplattenplatz ist ja IMMER - man stehe mir hier Ironie zu - in rauhen Massen vorhanden ;-)

Und sorry, ich finde 3GB Games ala FarCry schon heftig. Wenn ich mir jetzt noch vorstelle, dass das Game dann locker 4,5GB frist (ohne mir Vorteile zu geben) und auch noch von 2 DVD's installiert werden muss (ok, vielleicht reicht hier auch eine ;-), dann ist irgendwann schluß mit lustig.

Und ich habe hier nur von der Anwender-Seite gesprochen.

Razor

Sphinx
2004-05-09, 02:19:47
Original geschrieben von tokugawa
Dann stellt sich hier natürlich wieder die Frage ob wir zur "Lebenszeit" des R420 noch 3Dc-Spiele sehen werden.


http://www.computerbase.de/picture/article/333/31.jpg

http://www.computerbase.de/picture/article/333/32.jpg

http://www.computerbase.de/picture/article/333/26.jpg

Wishnu
2004-05-09, 02:28:15
Original geschrieben von r@h


Jetzt zeigt ATI ein Demo, welches es erlaubt, Texturen für eine 512MB-Karte (oder eben ca. 300MB, wie Quasar jetzt anführte) auf einer 256MB-Karte zu laden.

-

Verstehst Du nun mein Problem ?


Ich verstehe es bspw. nicht, denn seit wann gibt es denn einen direkten Bezug zwischen Techdemos und Praxis?
Die Demos zeigen doch immer das, was quasi unter optimalen (und eben nicht praxisgerechten) Bedingungen möglich ist.
Und sofern ich das nicht übersehen habe, wird die Ruby-Demo ja nicht benutzt um für 3DC zu werben, sondern um zu zeigen, was mit dem neuen Flaggschiff theoretisch möglich ist.

Und zum Thema technische Überlegenheit:
Als langjähriger Nvidia-Käufer (ich bin weder ATi- noch Nvidia-Fanboy) bin ich es gewohnt, dass sich technische Neuerungen erst in den späteren Generationen bemerkbar machen. Lässt sich das SM3.0 in der Praxis also nur für Geschwindigkeit einsetzen, so bring mir diese technische Überlegenheit derzeit nicht mehr, als auch durch das Hochschrauben der Taktung möglich wäre (wie wir sie bspw. beim X800 finden).

r@h
2004-05-09, 02:34:20
Original geschrieben von Sphinx
http://www.computerbase.de/picture/article/333/31.jpg
http://www.computerbase.de/picture/article/333/32.jpg
http://www.computerbase.de/picture/article/333/26.jpg Was sollen denn jetzt bitte Deine bunten Bildchen mit der Fragestellung von tokugawa zu tun haben ?

Natürlich werden Normalmaps heute schon eingesetzt und funktionieren (man höre und staune) auch ganz hervorragend ohne eine X800! Es geht hier aber um einen weiteren Kompressions-Algo mit dem Name 3Dc (wie S3TC oder DXT1/5) und dessen Sinn oder Unsinn. Und schon gar nicht um irgendwelche ATI-Präsentationen, die da 2 Dinge in einen Topf werfen, die gar nicht zusammen gehören...

Klar, mit Normalmaps sieht's hübscher aus, aber braucht's dafür 3Dc ?
Got it ?

Oder willst Du einfach nur ein bissel rumspammen ?
:???:

Razor

P.S.: Und ich denke, dass er Spiele meint, die nicht von ATI 'gesponsort' werden, um die Technologie zu unterstützen...

Wishnu
2004-05-09, 02:39:05
Original geschrieben von tokugawa
Mit anderen Worten: vermutlich (das spekuliere ich hier, aber gut begründet) werden wir früher SM 3.0 Spiele sehen als 3Dc Spiele.


Das glaube ich nicht, denn mein Erfahrungswert sagt mir, dass die Hardware für tolle SM3.0-Spielereien bestimmt noch (mal wieder) zu lahm ist (so oder so halte ich beide Dinge für nicht besonders relevant...oder wer drückt bspw. in einem RTS a'la SS2 ständig die Pausentaste um sich die Vorzüge von 3Dc anzugucken?).

Sphinx
2004-05-09, 03:18:26
Original geschrieben von r@h
Was sollen denn jetzt bitte Deine bunten Bildchen mit der Fragestellung von tokugawa zu tun haben ?

Natürlich werden Normalmaps heute schon eingesetzt und funktionieren (man höre und staune) auch ganz hervorragend ohne eine X800! Es geht hier aber um einen weiteren Kompressions-Algo mit dem Name 3Dc (wie S3TC oder DXT1/5) und dessen Sinn oder Unsinn. Und schon gar nicht um irgendwelche ATI-Präsentationen, die da 2 Dinge in einen Topf werfen, die gar nicht zusammen gehören...

Klar, mit Normalmaps sieht's hübscher aus, aber braucht's dafür 3Dc ?
Got it ?

Oder willst Du einfach nur ein bissel rumspammen ?
:???:

Razor

P.S.: Und ich denke, dass er Spiele meint, die nicht von ATI 'gesponsort' werden, um die Technologie zu unterstützen...


*Schlauberger ich habe auf ~ die Frage geantwortet ....

"Original geschrieben von tokugawa
Dann stellt sich hier natürlich wieder die Frage ob wir zur "Lebenszeit" des R420 noch 3Dc-Spiele sehen werden. "

JA wir werden 3Dc Supported noch zu LEBZEITEB sehen... Schau dir die Bildchen an SeriousSam 2 - Wenn du noch möchtest gebe ich dir eine URL noch zum VIDEO...

Wer Lesen kann ist klar im Vorteil... * so ein TROLL Guest... tsts
"Klar, mit Normalmaps sieht's hübscher aus, aber braucht's dafür 3Dc ?"
Schau dir das Mittlere BILD an wenn du des Englischen mächtig bist und zitiere mal...


PPS: Du meinst wohl Spiele die von Nvidia gesponsored werden...

Aquaschaf
2004-05-09, 03:34:58
Original geschrieben von tokugawa
Dann ist dann noch der Aufwand für Texture-Artists: von vorhandenen Texturen höhere Versionen machen ist mal nicht sooo wenig Aufwand - selbst mit Normalmap-Generation Tools wie NVIDIA MeLODy oder das in Doom 3 verwendete (immerhin müsste man jede Normalmap neu generieren in der höheren Auflösung).


Üblicherweise fabriziert man Texturen grundsätzlich in einer höheren Auflösung als man sie am Ende braucht.

Prinzipiell ists doch einfach ein Tausch; PS-Rechenleistung gegen Bandbreite und Speicherplatz. Da es dem R420 eher an Bandbreite mangelt, warum nicht? Plant man 3DC direkt in die Engine ein ist es kein großer Aufwand, wieviel es bringt wird sich aber erst zeigen müssen. Hoffentlich war ATI schlau genug die Entwickler der "Next-Gen"-Games wie HL2, D3, Stalker usw. einzureden 3DC zu benutzen...

betasilie
2004-05-09, 04:29:34
Original geschrieben von r@h
:???:

:crazy: 3Dc schont die Bandbreite um fast 50%.

Ich wette so eine eine Bandbreiten schonenden Maßnahme sagt dir bloß nicht zu, solange NV sie nicht hat. :)

Jeden objektiven User in diesen Forum sollte klar sein, dass moderne Spiele enorm von 3Dc profitieren können, außer den NV-Fans. Die werden sicherlich 3Dc schlecht reden und SM3.0 zum absoluten must-have-Feature küren. :ratlos:

Quasar
2004-05-09, 07:27:21
Original geschrieben von tokugawa
EDIT: wobei ich natürlich nicht weiß ob non-power-of-2 Texturen von der R420 unterstützt werden (unter OpenGL etwa GL_ARB_texture_non_power_of_two). Sinn würde es auf jeden Fall machen.
Eine Extension mit dem Namen finde ich mit GLView2 nicht unterstützt im aktuellen Cat4.4.

r@h
2004-05-09, 10:06:01
Original geschrieben von Sphinx
Schau dir das Mittlere BILD an wenn du des Englischen mächtig bist und zitiere mal...Nun krieg Dich mal wieder ein...
:D

Da steht lediglich, dass SS2 Normalmaps einsetzt, nicht aber dass dieses Spiel auch 3Dc unterstützen wird.

"Wer lesen kann, ist klar im Vorteil !"
;-)

Razor

r@h
2004-05-09, 10:07:56
Original geschrieben von Aquaschaf
Üblicherweise fabriziert man Texturen grundsätzlich in einer höheren Auflösung als man sie am Ende braucht.Warum denn das ?
:???:

Razor

r@h
2004-05-09, 10:09:23
@beta

Ich antworte nur auf sachliche Posts...
(das gilt auch für einige andere hier)

Razor

LovesuckZ
2004-05-09, 10:27:37
Original geschrieben von betareverse
Jeden objektiven User in diesen Forum sollte klar sein, dass moderne Spiele enorm von 3Dc profitieren können, außer den NV-Fans. Die werden sicherlich 3Dc schlecht reden und SM3.0 zum absoluten must-have-Feature küren. :ratlos:

Interessant: Der "objektive User" sehe in 3Dc ein features, von welchen "moderne Spiele enorm [...] profitieren können". Du willst also sagen, dass du ein "objektive User" wärst.
Nun, ich möchte dir auf die Sprünge helfen und deine selbst genannte Objektivitaet anzweifeln: 3Dc bringt keine bessere Effekten bzw. Qualitaet. Es ermöglicht hoeher aufgeloeste und mehr Normalmaps zu verwenden, da der Speicherbedarf geringerer ist. Jetzt müsstest du eigentlich Parallelen zum SM3.0 sehen. Ja, genau zu dem featurs, welches du als "sinnlos" versuchst seit ein paar Wochen zu deklarieren.
Nunja, andere vorwerfen, sie waeren ein faehnchen im Winde, dann jedoch selbst für sich in Anspruch nehmen ein "objektive[r] User" zu sein, ist verdammt geil X-D

Lokadamus
2004-05-09, 10:31:24
mmm...

Hab mir die Demo auch mal angeschaut, sieht nett aus, aber irgend ein Shader fehlt schon beim Kopf von dem Typen. Wenn man mit der Maus um seinen Kopf zoomt, sieht man dort ein komisches Muster, was auf den gezeigten Bildern wie ein Fehler aussieht (dieser helle Strich auf der Glatze) ...

@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 ...

reunion
2004-05-09, 10:31:26
Original geschrieben von r@h
Nun krieg Dich mal wieder ein...
:D

Da steht lediglich, dass SS2 Normalmaps einsetzt, nicht aber dass dieses Spiel auch 3Dc unterstützen wird.

"Wer lesen kann, ist klar im Vorteil !"
;-)

Razor

Würde SS2 kein 3Dc verwenden könnte man wohl kaum das erste Bild mit akivierten 3dc schießen...

r@h
2004-05-09, 10:42:41
Original geschrieben von reunion
Würde SS2 kein 3Dc verwenden könnte man wohl kaum das erste Bild mit akivierten 3dc schießen... Du kannst 3Dc nicht 'sehen' !
Offenbar hast Du das Prinzip nicht verstanden...

3Dc ist ein Komprimierungs-Algorithmus, der es ermöglicht, Normalmaps (die gibt es schon laaaaange) im Faktor 2:1 ohne Kopressionsfehler zu komprimieren. Wenn ich die Normalmaps überhaupt nicht komprimiere, dann siehts genauso aus, nur der belegte Speicher ist bei den Normalmaps (und nur da !) eben doppelt so hoch.

Die gezeigte Scene sieht auf NV3x+ ohne 3Dc ganz genauso aus...
(offenbar haben das hier viele nocht nicht richtig verstanden)

Was meinst Du eigentlich, warum Ruby auf den NV3x fast 1:1 dargestellt werden kann ?
(um mal auf's Thema zurück zu kommen)

Razor

r@h
2004-05-09, 10:43:34
Original geschrieben von reunion
Würde SS2 kein 3Dc verwenden könnte man wohl kaum das erste Bild mit akivierten 3dc schießen... Durch's Wiederholen wird's auch nicht besser...
Siehe oben !

Razor

r@h
2004-05-09, 10:56:41
Original geschrieben von Lokadamus
Hab mir die Demo auch mal angeschaut, sieht nett aus, aber irgend ein Shader fehlt schon beim Kopf von dem Typen. Wenn man mit der Maus um seinen Kopf zoomt, sieht man dort ein komisches Muster, was auf den gezeigten Bildern wie ein Fehler aussieht (dieser helle Strich auf der Glatze) ...Offenbar hast Du eine Radeon, da ich diesen Fehler nicht nachvollziehen konnte. Denn ja, die Radeons können viele der Effekte nicht darstellen (fehlende Kapazitäten im Instruction-Count, bzw. Shader einfach zu komplex) und dass sie dies überhaupt zum Teil können, ist der Mühe von Colourless zu verdanken, der extra einen Teil (lange nicht alle) Shader so umgeschrieben hat, dass diese von den 2.0-Basis-Shader-Rechenwerken auch 'verdaut' werden können. So kommen die Radeon User eben in den Genuß eines in der Qualität zwar massiv beschnittenen Demo's - aber zumindest kann man überhaupt etwas sehen und muss nicht auf ein Video zurück greifen. (ATI wollte dies offenbar so nicht zulassen).

Mit den NV3x wird auch nicht alles 100%ig dargestellt (dazu kann man sich ja mal das Video von ATI reinziehen), aber es ist verdammt nah an dem Endergebnis... nur eben nicht schnell genug (was zum einen an der ATI-Optimierung, zum anderen an der Shader-Lastigkeit und dem Video-Speicher-Overload liegen dürfte ;-).
Original geschrieben von Lokadamus
<sinnlos>Immer schön an die eigene Nase fassen... oder was sollte dieser Teil Deines Posts ?
:???:

Razor

InsaneDruid
2004-05-09, 11:06:21
Colourless bastelt ja noch fleißig auch den Rest für die R3xx anzupassen. So sieht es mittlerweile aus (http://www.users.on.net/triforce/teaser2.jpg) Immer noch nicht PERFEKT, aber schon n Schritt weiter.

r@h
2004-05-09, 11:09:42
Original geschrieben von InsaneDruid
Colourless bastelt ja noch fleißig auch den Rest für die R3xx anzupassen. So siehts mittleweile aus (http://www.users.on.net/triforce/teaser2.jpg) Immer noch nicht PERFEKT, aber schon n Schritt weiter. Hey cool !
Sieht ja zumindest von der Farbgebeung schon fast korrekt aus.

Wenn er jetzt noch die 'Wichzeichner' und die anderen Effekte hinbekommt...

Drücken wir ihm mal kräftigst die Daumen !

Razor

LovesuckZ
2004-05-09, 11:11:18
Original geschrieben von InsaneDruid
Colourless bastelt ja noch fleißig auch den Rest für die R3xx anzupassen. So sieht es mittlerweile aus (http://www.users.on.net/triforce/teaser2.jpg) Immer noch nicht PERFEKT, aber schon n Schritt weiter.

Auch schon etwas von dem Leistungsverlust bekannt?

InsaneDruid
2004-05-09, 11:14:25
Naja DoF arbeitet ja schon.. nur noch nicht 100% korrekt (sieht man an den beiden Strichen am Boden).. über Performance etc weiß man noch nix. Dieser Shot hat laut Colourless ca 50% der fehlenden Shader der alten Version mit drin, bei einem beißt er sich atm wohl aber n bissl die Zähne aus beim umsetzen.

r@h
2004-05-09, 11:23:42
Na das hat doch was... und das mit dem (fas funktionierenden) DoF ist mir auch aufgefallen.

-


Was ich aber viiieeeeelllll interessanter finde:

Tommti hat einen 3DA heraus gebracht !Auch gerade im B3D-Forum gelesenn:
http://www.tommti-systems.de/main-Dateien/files.html
(von tb höchstpersönlich verlinkt ;-)

Mit der Version 2.34 braucht's den Fix von Colourless nun nicht mehr !
(zumindest den Wrapper nicht, die Scripts werden weiterhin benötigt)

Damit ist aber endlich eine Analyse der Shader möglich...

So kam bei mir folgendes heraus:
Shader-File for Import:
F:\Visuals\ATI Demos\DoubleCross\shaders.out
-> 18675 Lines importet...
-> Result:
Shader ps_2_0 = 2 times.
Shader ps_2_x = 252 times.
Pixel-Shader in total = 254 times.

Shader vs_2_0 = 150 times.
Vertex-Shader in total = 150 times.Schon heftig, was da zum Vorschein gekomen ist.
Colourless muss also locker 252 2.x-Shader umsetzen, um das Demo 1:1 auf den R3x0 zum Lauen zu bringen...
:-(

Razor

ShadowXX
2004-05-09, 11:25:13
Original geschrieben von r@h
Nun krieg Dich mal wieder ein...
:D

Da steht lediglich, dass SS2 Normalmaps einsetzt, nicht aber dass dieses Spiel auch 3Dc unterstützen wird.

"Wer lesen kann, ist klar im Vorteil !"
;-)

Razor

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...

AFAIK hat ATI neben HL2 auch SS2 genannt, als Beispiele für Games, welche 3dc einsetzen werden...

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...

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)

InsaneDruid
2004-05-09, 11:29:14
Hm "times".. kann das nicht auch bedeuten das 2.x Shader 252MAL eingesetzt werden, ohne auf die eigentlich Anzahl der Shader zu deuten?

Aquaschaf
2004-05-09, 11:30:41
Original geschrieben von r@h
Warum denn das ?


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.
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.

Winter[Raven]
2004-05-09, 11:33:19
Jeden objektiven User in diesen Forum sollte klar sein, dass moderne Spiele enorm von 3Dc profitieren können, außer den NV-Fans. Die werden sicherlich 3Dc schlecht reden und SM3.0 zum absoluten must-have-Feature küren.

Von deiner Objektivität für ATI sind sich die meisen User bewusst.

Aber reche bitte die mehr Arbeit die ein DEV erledigen muss wen er 3dc verwenden will, dagegen ist es Shader 3.0 zubringen viel einfacher.

Schon aus diesem Grund kann man sich denken was sich durchsetzen wird und was nicht.

betasilie
2004-05-09, 11:42:01
Original geschrieben von LovesuckZ
Nun, ich möchte dir auf die Sprünge helfen und deine selbst genannte Objektivitaet anzweifeln: 3Dc bringt keine bessere Effekten bzw. Qualitaet. Es ermöglicht hoeher aufgeloeste und mehr Normalmaps zu verwenden, da der Speicherbedarf geringerer ist.
Keine bessere Qualität, aber höher aufgelößte Normalmaps. Also für mich bedeuten höher aufgelößte Normalmaps mehr Qualität.

deekey777
2004-05-09, 11:42:31
Original geschrieben von Winter[Raven]
Von deiner Objektivität für ATI sind sich die meisen User bewusst.

Aber reche bitte die mehr Arbeit die ein DEV erledigen muss wenn er 3dc verwenden will, dagegen ist es Shader 3.0 zubringen viel einfacher.

Schon aus diesem Grund kann man sich denken was sich durchsetzen wird und was nicht.

Von deiner Objektivität sind auch nicht viele entzückt.
Frage: Was hat 3Dc mit SM 3.0 zu tun?

LovesuckZ
2004-05-09, 11:48:02
Original geschrieben von betareverse
Keine bessere Qualität, aber höher aufgelößte Normalmaps. Also für mich bedeuten höher aufgelößte Normalmaps mehr Qualität.

Ja, diese sind aber nicht 3Dc zu verdanken. Es bringt keine bessere Qualitaet, sondern die Moeglichkeit den Speicherbedarf zu senken und dadurch eben hoehere aufgeloeste zu verwenden.
Analogie zu PS3.0 -> Leistungssteigerung -> Mehr Shader -> bessere Qualitaet.
Nun liegt es an dir, deine "Objektivitaet" wiederherzustellen in dem du deinem Kampf gegen neue Features, welche heute keinen Sinn haben, auch gegen 3Dc führst.

Winter[Raven]
2004-05-09, 11:49:56
Manö ... ich habe nur den Arbeitsaufwand der beiden Features verglichen. Den da liegt 3dc viel höher als Shader3.0. Erst muss man die Normalmaps erstellen ,damit diese mit 3dc zusammen arbeiten, dann muss man die Shader anpassen damit Z-Wert wieder kommt.

ist ein deutlicher mehr aufwand ... ist schöner Ansatz von ATI, keine Frage nur hätten die sich auf wichtigeres konzentrieren sollen.

ironMonkey
2004-05-09, 11:54:09
Original geschrieben von Winter[Raven]
Manö ... ich habe nur den Arbeitsaufwand der beiden Features verglichen. Den da liegt 3dc viel höher als Shader3.0. Erst muss man die Normalmaps erstellen ,damit diese mit 3dc zusammen arbeiten, dann muss man die Shader anpassen damit Z-Wert wieder kommt.

ist ein deutlicher mehr aufwand ... ist schöner Ansatz von ATI, keine Frage nur hätten die sich auf wichtigeres konzentrieren sollen.


Du nix verstehen??????Shader3.0 muss auch ATI bei der nächsten Genration unterstützen( R500), hingegen NV aber nicht 3DC. Es geht ja um 2 ganz andere Sachen, nur die einen probieren halt vom ihrem lieblings Hersteller alles in den Himmel zu loben.



Gruß

tokugawa
2004-05-09, 11:55:25
Original geschrieben von Quasar
Eine Extension mit dem Namen finde ich mit GLView2 nicht unterstützt im aktuellen Cat4.4.

Hast du eine R420?

Sphinx
2004-05-09, 11:56:54
Ich glaube der richtige Weg zu besseren und detailreichenden Applicationen nennen wir sie Spiele - gehören Bandbreitenschonende Maßnahmen dazu...

...und dafür ist nunmal jede Möglichkeit auszuschöpfen die es gibt.

Sonst hätt einer, der sich damals mit UT99 und den installierten S3TC Texturen eine RuckelOrgie erlebt die schlichtweg nicht zu gebrauchen währe... währen diese HighRes Texturen nicht komprimiert...


Apropos Bandbreitenschonende Maßnahmen - ich behaupte mal
Nvidia nutzt wohl oder übel PS3.0 einzig und alleine dafür das ihre PS Geschwindikeit effektiver läuft <-<- Und ihr werdet wohl wirklich kaum was anderes sehen als selbe Effekte mit den selben Sinn.

Da der die Effektivität der R420 so enorm ist erreicht der NV40 diese Effektivität erst mit PS3.0 !

Darüber sich zu streiten... lohnt sich nicht. Wartet einfach ab was dieses Jahr euch bringen wird.

StefanV
2004-05-09, 11:56:56
Original geschrieben von Winter[Raven]
Manö ... ich habe nur den Arbeitsaufwand der beiden Features verglichen. Den da liegt 3dc viel höher als Shader3.0. Erst muss man die Normalmaps erstellen ,damit diese mit 3dc zusammen arbeiten, dann muss man die Shader anpassen damit Z-Wert wieder kommt.

ist ein deutlicher mehr aufwand ... ist schöner Ansatz von ATI, keine Frage nur hätten die sich auf wichtigeres konzentrieren sollen.

Ja, und wieviel Performance könnte 3dc bringen?
Wieviel Performance könnte SM3 bringen, wenn mans einsetzt?

ShadowXX
2004-05-09, 11:57:43
Original geschrieben von LovesuckZ
Ja, diese sind aber nicht 3Dc zu verdanken. Es bringt keine bessere Qualitaet, sondern die Moeglichkeit den Speicherbedarf zu senken und dadurch eben hoehere aufgeloeste zu verwenden.
Analogie zu PS3.0 -> Leistungssteigerung -> Mehr Shader -> bessere Qualitaet.
Nun liegt es an dir, deine "Objektivitaet" wiederherzustellen in dem du deinem Kampf gegen neue Features, welche heute keinen Sinn haben, auch gegen 3Dc führst.

Sinnvoll ist beides....

SM3.0 ist natürlich wesentlich "breiter" Anwendbar.

Wenn man einen direkten vergleich zwischen beiden Features machen würde, würde dies IMHO zu gunsten von SM3.0 ausfallen. (Wobei dies Apfel vs. Birnen-Vergleich wäre).

Die Frage ist doch eigentlich die:
Von was, werden die Games eher Profitieren bzw. was wird mehr eingesetztz werden..

NV hat hier den Vorteil, dass Sie das SM3.0 mit in ihre Shadercompiler reinstricken können und dies dadurch indirekt auch schon vorhandenen Games vielleicht einen Performance-Boost geben können...

Dies möglichkeit hat ATI mit 3dc nicht...

Jeder soll selbst entscheiden, was Ihm wichtiger ist..eine Karte die jetzt in ein paar Benches vorne liegt und ein Feature bietet, welches expliziet unterstützt werden mss....
Oder eine Karte, die wahrscheinlich zum jetzigen Zeitpunkt noch nicht voll ausgereizt ist und vielleicht später durch "indirekten" SM3.0 Support noch zulegen kann...

Bei beiden gibts "vielleichts"...man sollte Würfeln.

ch für meinen Fall werde erst mal auf Retailkarten beider Hersteller warten und dann entscheiden...momentan leibäugel ich eher mit einer 6800UEE...die stellt den kleinsten Kompromiss dar, ist allerdings auch die Teuerste...

tokugawa
2004-05-09, 11:58:54
Original geschrieben von Aquaschaf
Üblicherweise fabriziert man Texturen grundsätzlich in einer höheren Auflösung als man sie am Ende braucht.

Prinzipiell ists doch einfach ein Tausch; PS-Rechenleistung gegen Bandbreite und Speicherplatz. Da es dem R420 eher an Bandbreite mangelt, warum nicht? Plant man 3DC direkt in die Engine ein ist es kein großer Aufwand, wieviel es bringt wird sich aber erst zeigen müssen. Hoffentlich war ATI schlau genug die Entwickler der "Next-Gen"-Games wie HL2, D3, Stalker usw. einzureden 3DC zu benutzen...

Dass es bei Engines, die schon auf 3Dc vorbereitet sind, etwas einfacher ist, ist klar (sagte auch schon Demirug).

Aber wie gesagt, in eine vorhandene Engine 3Dc nachträglich einzubauen ist aufwändig.

StefanV
2004-05-09, 12:03:09
Original geschrieben von tokugawa
Hast du eine R420?

Könnte durchaus sein, zumindest gibts einige Andeutungen von Quasar...

tokugawa
2004-05-09, 12:04:37
Original geschrieben von betareverse
:crazy: 3Dc schont die Bandbreite um fast 50%.

Ich wette so eine eine Bandbreiten schonenden Maßnahme sagt dir bloß nicht zu, solange NV sie nicht hat. :)

Jeden objektiven User in diesen Forum sollte klar sein, dass moderne Spiele enorm von 3Dc profitieren können, außer den NV-Fans. Die werden sicherlich 3Dc schlecht reden und SM3.0 zum absoluten must-have-Feature küren. :ratlos:

Es geht mehr darum wie 3Dc zum must-have-Feature gekürt wird und SM 3.0 als "unnötig" hingeredet wird.


Es geht auch um Objektivität: SM 3.0 ist einfacher zu integrieren in eine vorhandene Engine als 3Dc (ich weiß, die beiden sind eigentlich ein Äpfel mit Birnen Vergleich).

Und da SM 3.0 weniger Aufwand ist, war meine These, dass SM 3.0 Spiele früher zu sehen sein werden als Spiele, die 3Dc nutzen (Spekulation, aber ich habe es glaube ich zumindest gut und logisch genug begründet).

Von da her kann ich die Aussage "wer weiß ob SM 3.0 überhaupt zur Lebenszeit des NV40 noch in Spielen zu sehen sein wird" nicht nachvollziehen - vor allem nicht aus den Mündern der ATI-Jünger, die glauben 3Dc wäre so viel einfacher zu implementieren.

Selbst wenn man Vertex Blending mit VS 3.0 nutzt (Vertex Blending wird schon mit VS 1.x-2.0 genutzt, hat da aber sicher eine limitiertere Anzahl an Matrizen die man dem VS übergeben kann als VS 3.0), hat man bereits eine Anwendung von VS 3.0 (Sprengung von VS 2.0 Limitationen), die garantiert schnell genug läuft.


Wieso glaubt eigentlich jeder dass SM 3.0 nur für Branching und nur für superlange Shader gut ist? Der Hauptvorteil ist doch weniger Limitation generell, und das muß nicht zwangsläufig langsamer sein.

Ein Shader, der SM 3.0 ausnutzt und nicht mehr mit SM 2.0 möglich ist, muß nicht unbedingt Branching benutzen oder gar viel länger sein.

LovesuckZ
2004-05-09, 12:05:41
Original geschrieben von Sphinx
Apropos Bandbreitenschonende Maßnahmen - ich behaupte mal
Nvidia nutzt wohl oder übel PS3.0 einzig und alleine dafür das ihre PS Geschwindikeit effektiver läuft <-<- Und ihr werdet wohl wirklich kaum was anderes sehen als selbe Effekte mit den selben Sinn.

Worin unterscheidet sich dies zu 3Dc?

Da der die Effektivität der R420 so enorm ist erreicht der NV40 diese Effektivität erst mit PS3.0 !

Falsch. Mit FP16 ist Nvidia gleichschnell, wenn nicht sogar schneller und das mit 125Mhz weniger. Wer hat jetzt die bessere "Effektivität"?
Das gehoert hier aber nicht hin!

Sphinx
2004-05-09, 12:08:27
Original geschrieben von LovesuckZ
Worin unterscheidet sich dies zu 3Dc?



Falsch. Mit FP16 ist Nvidia gleichschnell, wenn nicht sogar schneller und das mit 125Mhz weniger. Wer hat jetzt die bessere "Effektivität"?
Das gehoert hier aber nicht hin!


Derjenige der die "bessere" Effektivität - also ich nenn es mal Bandbreitenschonende Maßnahmen - hat sollte meistens in den meisten Benchmarks vorne liegen.

Demirug
2004-05-09, 12:09:39
Original geschrieben von Sphinx
Ich glaube der richtige Weg zu besseren und detailreichenden Applicationen nennen wir sie Spiele - gehören Bandbreitenschonende Maßnahmen dazu...

...und dafür ist nunmal jede Möglichkeit auszuschöpfen die es gibt.

Sicherlich aber man muss immer die Kosten/Nutzen Seite betrachten.

Sonst hätt einer, der sich damals mit UT99 und den installierten S3TC Texturen eine RuckelOrgie erlebt die schlichtweg nicht zu gebrauchen währe... währen diese HighRes Texturen nicht komprimiert...

S3RC war einfacher einzubauen als 3dc.

Apropos Bandbreitenschonende Maßnahmen - ich behaupte mal
Nvidia nutzt wohl oder übel PS3.0 einzig und alleine dafür das ihre PS Geschwindikeit effektiver läuft <-<- Und ihr werdet wohl wirklich kaum was anderes sehen als selbe Effekte mit den selben Sinn.

Das ist aber keine Sache von nVidia sondern den Devs. Auch hier gilt wieder Kosten/Nutzen. Primär wird man es aber erst mal zum Beschleuningen nutzen.

Da der die Effektivität der R420 so enorm ist erreicht der NV40 diese Effektivität erst mit PS3.0 !

Im Mittel hat der NV40 aber eine bessere IPC als der R420.

dildo4u
2004-05-09, 12:09:50
Original geschrieben von Sphinx
Derjenige der die "bessere" Effektivität hat sollte meistens in den meisten Benchmarks vorne liegen. naja dazu müssten aber beide karten den selben takt haben um wirklich rauszufinden wer die besser Effektivität pro mhz hat

Demirug
2004-05-09, 12:12:53
Original geschrieben von Sphinx
Derjenige der die "bessere" Effektivität - also ich nenn es mal Bandbreitenschonende Maßnahmen - hat sollte meistens in den meisten Benchmarks vorne liegen.

Nur wenn die Bandbreite limitiert. Rechnet ein Shader viel und sampelt wenig können sogar FP16 Texturen 4free sein.

Sphinx
2004-05-09, 12:15:44
Original geschrieben von Demirug
Nur wenn die Bandbreite limitiert. Rechnet ein Shader viel und sampelt wenig können sogar FP16 Texturen 4free sein.

Bei unkomprimierten Texturen wird wohl oder übel die Bandbreite limitierend wirken. Denke ich.

Bei Spielen die Hochauflösende Texturen benutzen werden um den Detailgrad zu steigern - dazu tendiert der Trend.

tokugawa
2004-05-09, 12:25:40
Original geschrieben von Demirug
Sicherlich aber man muss immer die Kosten/Nutzen Seite betrachten.



S3RC war einfacher einzubauen als 3dc.



Das ist aber keine Sache von nVidia sondern den Devs. Auch hier gilt wieder Kosten/Nutzen. Primär wird man es aber erst mal zum Beschleuningen nutzen.



Im Mittel hat der NV40 aber eine bessere IPC als der R420.

Wieviel "kostet" eigentlich jetzt konkret die Anpassung der Shader bei 3Dc?

Ich nehme an, es rekonstruiert den Z Wert aus dem X und Y Wert sowie aus dem Wissen, dass es normalisierte Vektoren sind (bitte korrigieren wenn ich falsch liege)?

D.h. bei der Rekonstruktion bräuchte man die Berechnung von:

z = SQRT(1 - x*x - y*y)
(unter der Annahme normalisierter Vektoren mit der Eigenschaft x*x + y*y + z*z = 1)

"Wie sehr" (wenn man das so überhaupt fragen/beantworten kann) würde das einen Shader aufblähen und dadurch verlangsamen?

Demirug
2004-05-09, 12:30:22
Original geschrieben von Sphinx
Bei unkomprimierten Texturen wird wohl oder übel die Bandbreite limitierend wirken. Denke ich.

Nicht zwangsläufig. Wenn ein Shader 10 Takte zum rechnen braucht hat man die Bandbreite für diese 10 Takte ebenfalls zur Verfügung. Braucht man sie nicht limitiert die Bandbreite auch nicht sondern die Shaderleistung.

Bei Spielen die Hochauflösende Texturen benutzen werden um den Detailgrad zu steigern - dazu tendiert der Trend.

Der Trend geht in Richtung prozeduraler Texturen die sind unendlich hoch aufgelösst brauchen aber keine Bandbreite. Hochauflösenden Texturen sind nur eine Notlösung weil die Rechenleistung noch nicht reicht.

Demirug
2004-05-09, 12:38:45
Original geschrieben von tokugawa
Wieviel "kostet" eigentlich jetzt konkret die Anpassung der Shader bei 3Dc?

Ich nehme an, es rekonstruiert den Z Wert aus dem X und Y Wert sowie aus dem Wissen, dass es normalisierte Vektoren sind (bitte korrigieren wenn ich falsch liege)?

D.h. bei der Rekonstruktion bräuchte man die Berechnung von:

z = SQRT(1 - x*x - y*y)
(unter der Annahme normalisierter Vektoren mit der Eigenschaft x*x + y*y + z*z = 1)

"Wie sehr" (wenn man das so überhaupt fragen/beantworten kann) würde das einen Shader aufblähen und dadurch verlangsamen?

Genau diese Berechnung muss einmal pro Normalmap ausgeführt werden. Ich gehe da von 3-4 Takten auf einem R420 aus. Wobei die Berechungen dabei nicht immer die gesamte Rechenpower belegen. Der Treiber könnte also durchaus den Bedarf auf weniger reduzieren. Das hängt aber vom jeweiliegen Shader ab.

Wenn man nicht durch die Rechenleistung limitiert ist kann der zusätzliche Rechenaufwand durchaus auch nicht auffallen. Das ist aber vom jeweiligen einzelfall abhängig.

Aquaschaf
2004-05-09, 13:07:59
Ganz um gewöhnliche Texturen wird man aber nie herumkommen. Die braucht man meistens auch bei photorealistischen CGI.

tokugawa
2004-05-09, 13:58:47
Da anscheinend die R420 zumindest mit Cat 4.2 keine non-power-of-2 Texturen unterstützt (laut Quasar), stellt sich natürlich die Frage:

Werden Spiele, die 3Dc nutzen, jetzt trotzdem 2mal so viel Texturspeicher verbrauchen für Normalmaps?

Denn: wenn man nun (beispielsweise) statt 256x256 eben 512x512 Normalmaps verwendet, würde man mit 3Dc statt 4x so viel eben nur 2x so viel Platz verbrauchen.

Oder werden sie die Platzanforderungen irgendwie so skalieren, dass die 3Dc-Normalmaps einfach nur eine "Länge" verdoppeln gegenüber non-3Dc-Normalmaps (also etwa 512x256 vs. 256x256). Das wär allerdings irgendwie etwas seltsam. Um das optimal auszunutzen muß man die ganzen Normalmaps (selbst wenn die schon höherauflösend vorliegen, denn da stehen sie meistens einfach in einer Auflösung zur Verfügung, die dasselbe Seitenverhältnis hat wie die bereits vorhandenen) neu generieren (das geschieht ja normal mit Normalmap-Generator-Tools), um etwa nicht nur entlang einer Texturkoordinate (S oder T) die doppelte Auflösung gegenüber non-3Dc-Normalmaps zu haben, sondern die höhere Auflösung besser auszunutzen.

Ich glaube dass die meisten 3Dc-unterstützenden Spiele nicht einfach nur höheraufgelöste, aber gleich große 3Dc-Normalmaps wie die im selben Spiel benutzten non-3Dc-Normalmaps haben werden, sondern dass die 3Dc-unterstützenden Spiele bei aktivierter 3Dc-Unterstützung auch trotzdem doppelt soviel Texturspeicher für Normalmaps verbrauchen (damit man dann einfach die 4-fache Auflösung, also z.B. 512x512 gegenüber 256x256, verwenden kann).

EDIT: oder denk ich hier ganz falsch? Passen dadurch dass die Z Komponente gar nicht mehr gespeichert wird, gar tatsächlich 4x mal so große Normalmaps in denselben Speicher?

Wishnu
2004-05-09, 14:48:11
Original geschrieben von tokugawa
Und da SM 3.0 weniger Aufwand ist, war meine These, dass SM 3.0 Spiele früher zu sehen sein werden als Spiele, die 3Dc nutzen (Spekulation, aber ich habe es glaube ich zumindest gut und logisch genug begründet).


Sollte man nicht besser sagen, dass SM3.0 eventuell früher zu 'fühlen' sein wird (denn sehen wirds man wohl eher erst in den nächsten Generationen, außer vielleicht in Techdemos)?

Demirug
2004-05-09, 14:53:53
Original geschrieben von Wishnu
Sollte man nicht besser sagen, dass SM3.0 eventuell früher zu 'fühlen' sein wird (denn sehen wirds man wohl eher erst in den nächsten Generationen, außer vielleicht in Techdemos)?

Sehen wirst du es wohl nie. Ich traue mir jedenfalls nicht zu aleine vom Bild her zu sagen ob etwas mit SM2 oder SM3 gemacht wurde.

Wishnu
2004-05-09, 15:39:01
Original geschrieben von Demirug
Sehen wirst du es wohl nie. Ich traue mir jedenfalls nicht zu aleine vom Bild her zu sagen ob etwas mit SM2 oder SM3 gemacht wurde.

Nanü, ich dachte mit SM3 sollte bspw. 'virtual displacement mapping' möglich sein. Oder ginge das auch mit SM2, wäre jedoch zu ineffizient?
Oder habe ich als 3D-Laie hier mal wieder irgendwas in den falschen Hals gekriegt? ;)

Demirug
2004-05-09, 15:50:44
Original geschrieben von Wishnu
Nanü, ich dachte mit SM3 sollte bspw. 'virtual displacement mapping' möglich sein. Oder ginge das auch mit SM2, wäre jedoch zu ineffizient?
Oder habe ich als 3D-Laie hier mal wieder irgendwas in den falschen Hals gekriegt? ;)

Man kann displacment mapping auch mit der CPU machen. SM3 bringt im wesentlich möglichkeiten Dinge entweder performater zu machen oder von der CPU auf die GPU zu verlagern.

'virtual displacement mapping' ist übrigens kein echte DM und funktioniert mit SM2 genauso performant wie mit SM3.

deekey777
2004-05-09, 16:14:43
Aber "richtiges" DM kann noch keine Grafikkarte (vernünftig) darstellen? (Ohne dass die CPU viel mitberechnen muss.)

Wieviele Bezeichnungen gibt es eigentlich schon viruelles DM? Parallax Mapping, (Offset Mapping)... Da war doch noch irgendwas.

Lokadamus
2004-05-09, 18:01:19
mmm...

Wegen Shader und 3DC Aufwand, im Prinzip ist es momentan egal, die Shader von NVidia bei der 5XXX- Reihe müssen extra optimiert werden, ansonsten bringen sie nicht viel, da sollte der Zeitaufwand, 3DC reinzubringen, nicht viel höher sein. Irgend ein NVidia- Fan wird das wohl schnell erklären können ;) ... NVidia's Shader müssen parallelisiert werden, um effektiv die gleiche Leistung zu bringen, wie Ati's Shader, nur klappt die Parallelisierung nicht so gut, wodurch die Shader meistens hinterher hängen.

@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, siehe 3DC Beispielbild (http://www.ati-news.de/Bilder/ATI/R420/3dc/2.jpg), oder willst du da keinen Unterschied erkennen? die Idee von 3DC ist so gesehen gar nicht mal schlecht und erlaubt höhere Texturqualität bei relativ kleiner Bandbreite ... hier (http://www.lokadamus.de.vu/3dc/Kopf.JPG) nochmal kurz den Fehler bei den Texturen, wenn man Space drückt und in der Szene mit der Maus über den Kopf geht, sieht man, das es ein Halbkreis wird, irgendwie ist der Übergang nicht ganz in Ordnung. Meine Graka ist eine 9800 Pro ...

Demirug
2004-05-09, 18:17:14
Original geschrieben von deekey777
Aber "richtiges" DM kann noch keine Grafikkarte (vernünftig) darstellen? (Ohne dass die CPU viel mitberechnen muss.)

Die Parhelia könnte es theoretisch von der Hardware her. Allerdings schreibt Matrox keine DX9 Treiber mit denen man es auch benutzten könnte.

Der NV40 kann eine vereinfachte aber gleichzeitig komplizierte Form des DM. Vereinfacht deshalb weil die Anzahl der Eckpunkte nicht dynamisch verändern kann. Komplizierter deshalb weil er es erlaubt mehr als eine Displacment map auf einmal zu nutzen. Zudem können zum berechnen der Texturkoordinaten alle Möglichkeiten des Vertexshader genutzt werden.

Wieviele Bezeichnungen gibt es eigentlich schon viruelles DM? Parallax Mapping, (Offset Mapping)... Da war doch noch irgendwas.

Spontan wüsste ich jetzt keine mehr aber der nächste der es in seine Engine einbaut findet bestimmt wieder einen neue Bezeichung dafür.

Demirug
2004-05-09, 18:26:46
Original geschrieben von Lokadamus
mmm...

Wegen Shader und 3DC Aufwand, im Prinzip ist es momentan egal, die Shader von NVidia bei der 5XXX- Reihe müssen extra optimiert werden, ansonsten bringen sie nicht viel, da sollte der Zeitaufwand, 3DC reinzubringen, nicht viel höher sein. Irgend ein NVidia- Fan wird das wohl schnell erklären können ;) ... NVidia's Shader müssen parallelisiert werden, um effektiv die gleiche Leistung zu bringen, wie Ati's Shader, nur klappt die Parallelisierung nicht so gut, wodurch die Shader meistens hinterher hängen.

Wenn das Spiel wichtig genug ist bekommt man die Shader ja von nVidia durch den Treiber optimiert. ;)

Ansonsten halten sich die Sachen die man für die FXen tun kan sowieso in Grenzen.

- Die kleinste Shaderversion einsetzten die den Job erledigen kann (seit neusten auch der Tipp von ATI)
- FP16 dort nutzten wo es ausreicht.
- Formeln durch kürzere ersetzten (was auch den Radeons bekommt)
- Level of Detail Shading (auch kein Fehler bei den Radeons)

Schreibt man dann das ganze noch mit HLSL erledigt der Shadercompiler den Rest.

Bei 3dc stellt sich eben die Frage in wie weit sich das lohnt wenn vorerst nur ein kleiner Prozentsatz Highend Karten dieses Feature unterstützt. Wenn ATI noch eine RV4XX mit 3dc nachschiebt wird das schon eher interesant.

tokugawa
2004-05-09, 19:12:35
Original geschrieben von Wishnu
Nanü, ich dachte mit SM3 sollte bspw. 'virtual displacement mapping' möglich sein. Oder ginge das auch mit SM2, wäre jedoch zu ineffizient?
Oder habe ich als 3D-Laie hier mal wieder irgendwas in den falschen Hals gekriegt? ;)

Ich sehe SM 3.0 hauptsächlich darin, dass einige Limitationen nicht so eng gefaßt sind wie SM 2.0. Das kann man entweder nutzen indem man in HLSL oder einer anderen Shader-Hochsprache "schludrig" programmiert, oder tatsächlich die weiter gefaßten Grenzen nutzen. Dabei kann der grundsätzliche Algorithmus sogar derselbe sein wie bei einem 2.0er Shader, nur dass er etwa nicht so limitiert ist (etwa beim Vertex Blending auf sagen wir 8 (Hausnummer) Matrizen bei älteren Vertex Shadern, oder ähnliches).

tokugawa
2004-05-09, 19:19:38
Original geschrieben von Lokadamus
mmm...

Wegen Shader und 3DC Aufwand, im Prinzip ist es momentan egal, die Shader von NVidia bei der 5XXX- Reihe müssen extra optimiert werden, ansonsten bringen sie nicht viel, da sollte der Zeitaufwand, 3DC reinzubringen, nicht viel höher sein. Irgend ein NVidia- Fan wird das wohl schnell erklären können ;) ...

3Dc reinbringen ist ja nicht alles. Es müssen ja die Texturen dementsprechend aufbereitet werden (da ich denke dass Normalmaps normalerweise auf die schon passende Größe generiert werden und daher neu höherauflösend generiert werden müssen, eventuell sogar anders gemappt - anders als Image-Texturen, die normal in höherer Auflösung da sind als im Spiel je zu sehen - zumindest kluge vorrausschauende Texture-Artists vorrausgesetzt).

Das kann heißen, _jedes_ Model das mit einer Normalmap versehen werden soll nochmal in ein Normalmap-Generation Tool zitieren (NVIDIA's MeLODy z.B. - ich fänd's irgendwie auch lustig wenn die Herstellet MeLODy verwenden würden, um höherauflösende 3Dc maps zu machen :) oder vielleicht kann man sogar ein 3Dc-Plugin für NVIDIA's MeLODy machen - NVIDIA programmiert ihre Tools ja normal so dass sie auch auf ATI laufen - und laden normal ATI immer ein, auch Plugins beizusteuern, wo sich ATI meines Wissens nach immer weigert... weswegen ich die Hoffnung auf ein R2xx-Profil für Cg schon aufgegeben habe - schade!).

Außerdem geht's ja um SM 3.0 und die NV 6xxx-er Reihe, nicht um die "Handoptimierung" der FXen.

tokugawa
2004-05-09, 19:22:24
Original geschrieben von deekey777
Aber "richtiges" DM kann noch keine Grafikkarte (vernünftig) darstellen? (Ohne dass die CPU viel mitberechnen muss.)

Wieviele Bezeichnungen gibt es eigentlich schon viruelles DM? Parallax Mapping, (Offset Mapping)... Da war doch noch irgendwas.

Wäre schön wenn du "echtes" Displacement Mapping definieren würdest.

Ich halte Displacement Mapping auf einer fixen statischen Anzahl von Vertizes (wie es die NV40 machen kann), auch für "echt".

Displacement Mapping mit dynamischer Tesselierung (also dynamischem Hinzufügen neuer Vertizes) wäre dann noch ein Level höher einzustufen.

Gasst
2004-05-09, 20:39:25
Woher wisst ihr alle wieviel Aufwand es ist. IMO Einfach alle Normalmaps mit der Routine behandeln, und schon sind sie 3DC komprimiert.

Zur Runtime noch eine Abfrage, if HW = R420 Then use 3DC Textures, oder s.ä., und wo soll da jetzt das Problem sein?

Gasst
2004-05-09, 20:41:58
Original geschrieben von tokugawa
...und laden normal ATI immer ein, auch Plugins beizusteuern, wo sich ATI meines Wissens nach immer weigert... weswegen ich die Hoffnung auf ein R2xx-Profil für Cg schon aufgegeben habe - schade!).

Außerdem geht's ja um SM 3.0 und die NV 6xxx-er Reihe, nicht um die "Handoptimierung" der FXen.

Ja und, ATi stellt es auch jedem frei Ati Extensions zu nutzen, und NV steigt drauf nicht ein. Zu gern hätte cih Ati Extensions auf NV Karten gesehen, aber wenn sich NV weigert...

Demirug
2004-05-09, 20:47:29
Original geschrieben von Gasst
Woher wisst ihr alle wieviel Aufwand es ist. IMO Einfach alle Normalmaps mit der Routine behandeln, und schon sind sie 3DC komprimiert.

Zur Runtime noch eine Abfrage, if HW = R420 Then use 3DC Textures, oder s.ä., und wo soll da jetzt das Problem sein?

Das komprimieren ist nicht das Problem. Dummerweise ist 3dc im Gegensatz zu anderen Kompressionverfahren nicht transparent für den Rest des Chips. Wird ein Wert aus einer mit 3dc komprimierten Textur benutzt muss dieser im Pixelshader anders behandelt werden als bei einer Normalmap wie man sie bisher benutzt hat. Erschwerend kommt hinzu das man dafür zwingend Pixelshader der Version 2.0 oder grösser braucht. Hat man noch viele von Hand programmierte 1.1-1.4 Shader wird das richtig lustig. Jeder dieser Shader der eine Normalmap benutzt muss dann neu geschrieben werden.

Demirug
2004-05-09, 20:55:38
Original geschrieben von Gasst
Ja und, ATi stellt es auch jedem frei Ati Extensions zu nutzen, und NV steigt drauf nicht ein. Zu gern hätte cih Ati Extensions auf NV Karten gesehen, aber wenn sich NV weigert...

Beim NV40 nutzt nVidia doch ATI Extensions.

- ATI_draw_buffers
- GL_ATI_texture_float
- WGL_ATI_pixel_format_float
- LUMINANCE_FLOAT32_ATI

tokugawa
2004-05-09, 22:54:38
Original geschrieben von Gasst
Ja und, ATi stellt es auch jedem frei Ati Extensions zu nutzen, und NV steigt drauf nicht ein. Zu gern hätte cih Ati Extensions auf NV Karten gesehen, aber wenn sich NV weigert...

Was ich erwähnte ist auf einem komplett anderen Level als die Extensions.

Immerhin funktioniert Cg auf R3xx (eben über die ARB extensions).

tokugawa
2004-05-09, 22:55:22
Original geschrieben von Gasst
Woher wisst ihr alle wieviel Aufwand es ist. IMO Einfach alle Normalmaps mit der Routine behandeln, und schon sind sie 3DC komprimiert.

Zur Runtime noch eine Abfrage, if HW = R420 Then use 3DC Textures, oder s.ä., und wo soll da jetzt das Problem sein?


Wenn du die Normalmaps neu generieren mußt, ist nix mit "nur mit der Routine behandeln".

Gasst
2004-05-09, 23:12:56
Original geschrieben von tokugawa
Was ich erwähnte ist auf einem komplett anderen Level als die Extensions.

Immerhin funktioniert Cg auf R3xx (eben über die ARB extensions).

?-)

Original geschrieben von tokugawa
Wenn du die Normalmaps neu generieren mußt, ist nix mit "nur mit der Routine behandeln".

Du hast scheinbar nichts verstanden...

Mr. Lolman
2004-05-09, 23:15:42
Original geschrieben von Demirug
Jeder dieser Shader der eine Normalmap benutzt muss dann neu geschrieben werden.

Auch unter OpenGL?

tokugawa
2004-05-09, 23:16:21
Original geschrieben von Gasst
?-)



Du hast scheinbar nichts verstanden...

Oder du...

Mr. Lolman
2004-05-09, 23:17:53
Original geschrieben von tokugawa
Oder du...

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?)

tokugawa
2004-05-09, 23:18:58
Original geschrieben von Mr. Lolman
Auch unter OpenGL?

Ja. Weil 3Dc komprimiert so, dass man nur die X und Y Komponente des Normalvektors bekommt.

Die Z Komponente muß man sich ausrechnen.

Mit dem Wissen dass die Normalvektoren normalisiert sind (also Länge 1 besitzen, also die Bedingung |n| = SQRT(x*x + y*y + z*z) = 1 erfüllen, wobei n ein Normalvektor (x, y, z) ist), kommt man zu folgender Berechnung:

SQRT(x*x + y*y + z*z) = 1, folglich kann man das SQRT einfach weglassen:

x*x + y*y + z*z = 1

Davon ist nur Z unbekannt, durch Umformung kommt man auf:

Z = SQRT(1 - x*x - y*y)

Dies ist das was man für jeden Texel der Normalmap ausführen muß, um Z aus X, Y und der Länge (=1) zu berechnen.

Winter[Raven]
2004-05-09, 23:21:43
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?)

Doch, hat Demirug doch schon mehrmals erklärt. Die normalmaps müssen neu generiert werden und den x und y Wert enthalten, den z Wert erhält man wenn man die shader umschreibt.

tokugawa
2004-05-09, 23:21:50
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?)


Wenn du höherauflösende Normalmaps haben willst (der wirkliche "Sinn" von 3Dc), mußt du die im Normalfall neu generieren.

Denn Normalmaps - anders als Image-Textures - werden normalerweise nicht in höherer Auflösung als benötigt erstellt.

Normalmaps werden auch nicht gemalt (im Normalfall, es gibt aber Ausnahmen), sondern mit Tools generiert (wie etwa NVIDIA MeLODy oder das Doom 3 spezifische Tool). Wenn es gemalte Bumpmaps sind, liegen die meist als Heightfield vor, hier muß man zumindest dann den Normalmap-Filter in Photoshop bemühen (gibt's von NVIDIA), bzw. ähnliche Tools.

Folglich, wenn man höherauflösende Normalmaps unter den genannten Bedingungen haben will, muß man die Tools neu mit den Models füttern und sich die Normalmaps höherauflösend ausspucken lassen.

Mr. Lolman
2004-05-09, 23:45:29
Original geschrieben von Winter[Raven]
Doch, hat Demirug doch schon mehrmals erklärt. Die normalmaps müssen neu generiert werden und den x und y Wert enthalten

Das sollte doch eine Kompressionsroutine hinbekommen...

Original geschrieben von tokugawa
Wenn du höherauflösende Normalmaps haben willst (der wirkliche "Sinn" von 3Dc), mußt du die im Normalfall neu generieren.

Denn Normalmaps - anders als Image-Textures - werden normalerweise nicht in höherer Auflösung als benötigt erstellt.

Normalmaps werden auch nicht gemalt (im Normalfall, es gibt aber Ausnahmen), sondern mit Tools generiert (wie etwa NVIDIA MeLODy oder das Doom 3 spezifische Tool). Wenn es gemalte Bumpmaps sind, liegen die meist als Heightfield vor, hier muß man zumindest dann den Normalmap-Filter in Photoshop bemühen (gibt's von NVIDIA), bzw. ähnliche Tools.

Folglich, wenn man höherauflösende Normalmaps unter den genannten Bedingungen haben will, muß man die Tools neu mit den Models füttern und sich die Normalmaps höherauflösend ausspucken lassen.

Ist mir alles klar, gehen wir aber mal von gleich hoch aufgelösten Normalmaps aus

Worauf ich hinaus will:

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...

tokugawa
2004-05-10, 00:07:57
Original geschrieben von Mr. Lolman
Das sollte doch eine Kompressionsroutine hinbekommen...



Ist mir alles klar, gehen wir aber mal von gleich hoch aufgelösten Normalmaps aus

Worauf ich hinaus will:

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...

Du meinst, dass der Shadercompiler die Normalmaps selbst schon so aufbereitet, dass die Shader die 3Dc-Normalmaps wie "normale" Normalmaps sehen, und damit selbst nichts mehr machen müssen?

Gfraast
2004-05-10, 09:03:29
Original geschrieben von tokugawa
Du meinst, dass der Shadercompiler die Normalmaps selbst schon so aufbereitet, dass die Shader die 3Dc-Normalmaps wie "normale" Normalmaps sehen, und damit selbst nichts mehr machen müssen?


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..

Natürlich müsste man dann noch auf Feinheiten achten, wie, dass Normalmaps für PS1.1-PS1.4 Shader unbehandelt bleiben. ..

Lolman
2004-05-10, 09:05:04
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 doch 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..

Natürlich müsste man dann noch auf Feinheiten achten, wie, dass Normalmaps für PS1.1-PS1.4 Shader unbehandelt bleiben. ..

Mein Post...