Wieso ist Bump Mapping immer noch Luxus?

[7th Guest]

Hab mal das Titan Quest Demo gespielt, aber mit BM geht die Performance meiner R96tx so in den Keller, wieso werden Grakas nicht auf solche Features hin getrimmt, sodaß dies keine Auswirkung mehr macht. Das ist doch ein alter Hut seit Expandable ('99)?

[Gast]

werden sie ;) aber nicht deine 96tx

[Neomi]

Bumpmapping ist (seitdem es programmierbare Shader gibt) nichts, worauf man speziell hinoptimieren könnte. Die Hardware wird nichtmal "wissen", daß Bumpmapping genutzt wird, sie führt einfach nur Instruktionen aus. Es werden ganz normal Texturen gesampelt und der resultierende Farbwert weiterverrechnet, nur eben nicht als Farbe.

[Die gelbe Eule]

Mit einer verkappten 9500pro von Medion die MSI hergestellt hat, sollte man sich auch nicht an solche Spiele heranwagen ;)
Bei Doom3 ist fast alles was man sieht reines Bump Mapping, das man vor lauter Plastik kaum noch hinschauen mag.

[Gast]

Da dies ja sehr beliebt ist, warum wird es dann nicht darauf ausgelegt. So alt ist die R300 jetzt auch nicht, aber BM frisst. Und auf der XBox gibts das auch bei D3 oder Riddick. Mit meiner Karte hab ich im 3dM2001SE bei Fillrate Multi 3x soviel wie bei FR Single, wird dahin nicht optimiert?

[Die gelbe Eule]

Lass mal im 01er nur BumpMapping laufen und sag mal Deine Frames an. Danach erschrecke ich dann Deine Karte mit meinen Werten, die heutzutage auch nicht mehr die Welt sind.

[-Miles_Prower-]

Gast[/POST]']Da dies ja sehr beliebt ist, warum wird es dann nicht darauf ausgelegt. So alt ist die R300 jetzt auch nicht, aber BM frisst. Und auf der XBox gibts das auch bei D3 oder Riddick. Mit meiner Karte hab ich im 3dM2001SE bei Fillrate Multi 3x soviel wie bei FR Single, wird dahin nicht optimiert?
Deine Radeon ist einfach zu langsam. Sie war zu Zeiten der Radeon 9800Pro (R300) als MidRange -Karte entwickelt worden und entsprechend langsam ist sie inzwischen halt. Ich hatte ich mal ein R9600 und eine R9800Pro und zwischen diesen beiden Karten liegen Welten in Sachen Performance bei Spielen wie z.Bsp. Riddick. Und auch der R300 ist inzwischen nicht mehr der jüngste Grafikchip. Wenn du anständige Performance in aktuellen Spielen haben willst kommst du um das aufrüsten deines Computers nicht herum.

[deekey777]

7th Guest[/POST]']Hab mal das Titan Quest Demo gespielt, aber mit BM geht die Performance meiner R96tx so in den Keller, wieso werden Grakas nicht auf solche Features hin getrimmt, sodaß dies keine Auswirkung mehr macht. Das ist doch ein alter Hut seit Expandable ('99)?

Wenn es kein Buchstabendreher ist, dann handelt es sich um die 9600TX, was weder was mit der 9600er Serie zu tun hat, noch ist es eine verkappte 9500Pro, denn es ist eine 9500Pro-Sonderedition für Medion mit einem vollwertigen R300 (="RV300"), was hier limitiert, ist in erster Linie die Speicherbandbreite.
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=284507

[Gast]

Die gelbe Eule[/POST]']Lass mal im 01er nur BumpMapping laufen und sag mal Deine Frames an. Danach erschrecke ich dann Deine Karte mit meinen Werten, die heutzutage auch nicht mehr die Welt sind.

~160 fps bei embm und dot3

[san.salvador]

X800 Pro @Standard; HQ; 1024er
EBM: 231 fps
Dot3: 375 fps

€dit: LQ und a bissl OC:
EBM: 244 fps
Dot3: 476 fps

[Die gelbe Eule]

Gast[/POST]']~160 fps bei embm und dot3

493fps und 460fps, war auch noch Quality.

Siehst schon, das sind Welten.

[Gast]

sind wohl alles 256bit SI's. ich hab ne 128er.

[7th Guest]

Kann das auch an der CPU oder am SDR-Mainram liegen? Jedenfalls ruckelt man sich auf nem 1,3+ GHZ Duron so mit 12 fps durch die Pampa, anfangs noch 20fps@full+schatten medium. Wenn das 128er SI zu lahm ist, wieso gibts nix besseres. die 95p war jetzt auch keine Budget-Karte

[HotSalsa]

Nö nicht direkt Budget aber halt Mainstream von vor ca. 2 Jahren und das entspricht nicht mal mehr heutigem low end. So ist das nun mal.

Ich hatte Titan Quest noch auf meinem alten Rechner Athlon XP 3200+, 1 Gig Ram und gForce 6800 gespielt und das lief man gerade so. Dein System reicht halt leider nicht mehr für ein aktuelles Spiel, weder von der CPU noch von der Graka her.

[robbitop@work]

Bumpmapping ist ja ein ziemlich allgemeiner Begriff.
Davon gibt es ja verschiedene Umsetzungen.

Dot3 BM
Hat wohl die größte HW Basis. Ab NV10 und R100 ist eine DP3 BM Unterstützung da. Die Texturcombiner können in einem Pass die pertubed Normale berechnen und daraus die Lichtintensität die mit dem Farbwert multipliziert wird.
Allerdings kostet das mindestens (angenommen wir haben nur einen Texturlayer...wenn Detailtexturen, Lightmaps ect vorhanden sind die natürlich auch) Texturzugriffe. Es muss ja die Hightmap mit der Texturverrechnet werden.
Ergo: viel Texturpower nötig und eine Karte, die >4 Texturen pro Pass loopen kann. Ist allerdings von der Optik nicht so beeindruckend wie einige andere BM Arten

EMBM
Hier fließen mindestens gleich drei statt nur zwei Texturen ein. Die Environment Map, die Hightmap und die Basistextur. Zuersteinmal wird die Umgebung in eine Environment Map Textur gerendert. Dazu benötigt es Dependant Reads (das kostet tw richtig Zeit). Nachdem die Hightmap auf die Basistexturaufgetragen wird, wird das Resultat mit den Environmentmap kombiniert. Die Oberfläche spiegelt nun.

Parallax Mapping
Das rechenaufwändigste Verfahren. Allerdings auch das ansehnlichste, da auch bei sehr spitzem Blickwinkel die Oberfläche erhalten bleibt.

Für eine großflächige Umsetzung von DP3/EMBM braucht es Texturleistung. Doom3 hat diese Variante genutzt (4-5 Jahr später als die HW Basis da war).
Für eine großflächige Parallaxumsetzung ist viel mehr noch die Rechenleistung gefragt. Bei Oblivion kommt sie schon viel zum Einsatz aber noch nicht breitflächig.

Ergo: die Rohleistung muss da sein.

[Gast]

Es muss ja die Hightmap mit der Texturverrechnet werden.


DOT3-bump-mapping verwendet normalmaps und keine highmaps, die höhe ist bei der berechnung nicht mehr bekannt. genau das ist ja die schwäche dieses verfahrens, dadurch dass die höhe nicht in die berechnung einfließt sehen spitze winkel sehr bescheiden aus.

erst parallax-mapping kennt sowohl die oberflächennormale als auch die höhe und sieht deshalb auch viel besser aus spitzen winkel aus.

[robobimbo]

Titan Quest frisst meiner Meinung nach am meisten zeit bei den Schattenberechnungen - zumindest ruckelts da bei mir am häufigsten (X1600pro 512mb, XP @ 2 Ghz)

[Spasstiger]

Nö nicht direkt Budget aber halt Mainstream von vor ca. 2 Jahren und das entspricht nicht mal mehr heutigem low end. So ist das nun mal.
Vor zwei Jahren? Vor vier Jahren! Ende 2002 kam die Radeon 9500 Pro im Mainstream-Segment auf den Markt. 2004 nach dem Erscheinen von Radeon X800 und GeForce 6 war sie schon ganz klar im Budget-Segment angesiedelt.

Bumpmapping ist ein sehr schwammiger Begriff, da kann man viel drunter verstehen, da er eigentlich alle Techniken zusammenfasst, die dafür sorgen, dass eine ebene Fläche plastisch wirkt. Das klassische Bumpmapping, was man bereits zu Voodoo-2-Zeiten kannte, hat mit den heutigen Techniken (insbesondere Parallax-Mapping) gar nichts mehr gemeinsam. Und es war auch optisch nur ein sehr mieses Fake.
Ab der GeForce 1 findet man brauchbares Bumpmapping, nämlich Normalmapping (siehe Doom-3-Engine), welche so auch noch mit Shadern in vielen Spielen realisiert wird. Allerdings wird Normalmapping zunehmend durch Parallax-Mapping ergänzt und teilweise auch ersetzt.

Eine Radeon 9600 TX hat halt für heutige Verhältnisse keine besonders gute Shaderleistung, entsprechend kostet auch Normalmapping und vor allem Parallax-Mapping viel Leistung, wenn der Content für modernere Grafikkarten ausgelegt ist. Und spezialisierte Hardware für Normalmapping und Parallax (also fest verdrahtete Einheiten statt programmierbare Shadereinheiten) wäre unsinnig, da dies ja genau dem Trend entgegenläuft, Grafikchips möglichst flexibel auszulegen, um den Entwicklern mehr Freiheiten und Möglichkeiten gewähren zu können.

[Coda]

EMBM
Hier fließen mindestens gleich drei statt nur zwei Texturen ein. Die Environment Map, die Hightmap und die Basistextur. Zuersteinmal wird die Umgebung in eine Environment Map Textur gerendert. Dazu benötigt es Dependant Reads (das kostet tw richtig Zeit). Nachdem die Hightmap auf die Basistexturaufgetragen wird, wird das Resultat mit den Environmentmap kombiniert. Die Oberfläche spiegelt nun.

Err. Nicht für das rendern der Cubemap braucht man dependent reads sondern später für das samplen der Cubemap im Fragment-Shader abhängig von der Normalen aus der Normalmap ;)

[robbitop@work]

Err. Nicht für das rendern der Cubemap braucht man dependent reads sondern später für das samplen der Cubemap im Fragment-Shader abhängig von der Normalen aus der Normalmap ;)
Aww right, wusste ich doch, dass ich da was verdreht hatte. Danke :)

[HotSalsa]

Vor zwei Jahren? Vor vier Jahren! Ende 2002 kam die Radeon 9500 Pro im Mainstream-Segment auf den Markt. 2004 nach dem Erscheinen von Radeon X800 und GeForce 6 war sie schon ganz klar im Budget-Segment angesiedelt.

Bumpmapping ist ein sehr schwammiger Begriff, da kann man viel drunter verstehen, da er eigentlich alle Techniken zusammenfasst, die dafür sorgen, dass eine ebene Fläche plastisch wirkt. Das klassische Bumpmapping, was man bereits zu Voodoo-2-Zeiten kannte, hat mit den heutigen Techniken (insbesondere Parallax-Mapping) gar nichts mehr gemeinsam. Und es war auch optisch nur ein sehr mieses Fake.
Ab der GeForce 1 findet man brauchbares Bumpmapping, nämlich Normalmapping (siehe Doom-3-Engine), welche so auch noch mit Shadern in vielen Spielen realisiert wird. Allerdings wird Normalmapping zunehmend durch Parallax-Mapping ergänzt und teilweise auch ersetzt.

Eine Radeon 9600 TX hat halt für heutige Verhältnisse keine besonders gute Shaderleistung, entsprechend kostet auch Normalmapping und vor allem Parallax-Mapping viel Leistung, wenn der Content für modernere Grafikkarten ausgelegt ist. Und spezialisierte Hardware für Normalmapping und Parallax (also fest verdrahtete Einheiten statt programmierbare Shadereinheiten) wäre unsinnig, da dies ja genau dem Trend entgegenläuft, Grafikchips möglichst flexibel auszulegen, um den Entwicklern mehr Freiheiten und Möglichkeiten gewähren zu können.

Jup sind 4 Jahre.... Recht haste :wink:

[aths]

DOT3-bump-mapping verwendet normalmaps und keine highmaps, die höhe ist bei der berechnung nicht mehr bekannt. genau das ist ja die schwäche dieses verfahrens, dadurch dass die höhe nicht in die berechnung einfließt sehen spitze winkel sehr bescheiden aus.

erst parallax-mapping kennt sowohl die oberflächennormale als auch die höhe und sieht deshalb auch viel besser aus spitzen winkel aus.Das würde ich so pauschal nicht sagen. Parallaxmapping sieht besser aus, weil auch die Basemap verzerrt wird. Bei reinem Licht-Bumpmapping bleibt die Basemap flach. Nun braucht man für Parallaxmapping auch die Heightmap, ja. Aber würde man bei Licht-Bumpmapping noch irgendwie eine Hightmap einfließen lassen, hätte man noch keine Parallaxmapping-Qualität.

Parallax Mapping
Das rechenaufwändigste Verfahren. Allerdings auch das ansehnlichste, da auch bei sehr spitzem Blickwinkel die Oberfläche erhalten bleibt.Das Polygon bleibt aber flach, wodurch es bei flachem Betrachtungswinkel Irritationen geben kann.

[Gouvernator]

493fps und 460fps, war auch noch Quality.

Siehst schon, das sind Welten.
Ohh... ich muss auch.

1900XTX@overclocked,standard
EBM=740.0 fps
DOT3=649.1 fps

[Henroldus]

ich frage mich eher, warum es NOCH bumpmapping gibt, welches ja nur eine gewölbte oberfläche vorgaukelt.
es hieß doch schon vor jahren der nächste schritt ist displacementmapping :|
und wo sind sie nun die spiele, die das bereits nutzen? ;(

verdammt, auf fotorealismus muss ich wohl noch weitere 10 Jahre warten.

[TheGamer]

Ohh... ich muss auch.

1900XTX@overclocked,standard
EBM=740.0 fps
DOT3=649.1 fps

Das geiche Ergebniss (bisschen weniger) ca. mit der 8800GTX ein wenig OC @ 1920x1200x32 und 16xAF und 16xAA

[Gouvernator]

Das geiche Ergebniss (bisschen weniger) ca. mit der 8800GTX ein wenig OC @ 1920x1200x32 und 16xAF und 16xAA
Das sind Grosse Worte :wink:

Mit 1920x1200+6xAA+16xAF @770/900mhz

EBM=253.4 fps
DOT3= 186.7 fps
SOgar wenn die GTX doppelt so schnell ist wie CF ist das unrealistisch.

[SavageX]

ich frage mich eher, warum es NOCH bumpmapping gibt, welches ja nur eine gewölbte oberfläche vorgaukelt.
es hieß doch schon vor jahren der nächste schritt ist displacementmapping :|
und wo sind sie nun die spiele, die das bereits nutzen? ;(


Displacementmapping auf der CPU geht mit DX9/GL2 Hardware nicht - diese Anzahl an Vertices willst Du nicht über AGP/PCIe jagen.

Mit dem Geometry Shader der GeForce 8 kann man das wohl eher machen. Allerdings frage ich mich, ob man damit allen Ernstes die barbarisch vielen Polygone erzeugen kann, um Oberflächen auzubeulen, ohne dass man Ecken sieht. Und wirklich krasses Displacementmapping kannst Du nicht betreiben, weil für die CPU (und die Spielephysik) die Oberfläche weiterhin flach ist.

Mit den üblichen Pixelschader-getriebenen Sachen ist man meiner Meinung nach deshalb eigentlich schon gut bedient.

http://quake10year.com/Shots/q10_040306_05.jpg

[TheGamer]

Das sind Grosse Worte :wink:

Mit 1920x1200+6xAA+16xAF @770/900mhz

EBM=253.4 fps
DOT3= 186.7 fps
SOgar wenn die GTX doppelt so schnell ist wie CF ist das unrealistisch.

Stimmt es waren nur 8xAF und AA da hab ich mich vertan. Ansonsten ist das Ergebnis so wie es da steht, da gibts nichts zum schoenreden oder ueber Realismus zu spekulieren

[Gast]

ich frage mich eher, warum es NOCH bumpmapping gibt, welches ja nur eine gewölbte oberfläche vorgaukelt.
es hieß doch schon vor jahren der nächste schritt ist displacementmapping :|
und wo sind sie nun die spiele, die das bereits nutzen? ;(


displacement-mapping wird auch, wenn es einmal kommen wird, in erster linie für die groben strukturen sorgen, feine details wird man noch immer über bump-mapping-techniken erzeugen, ganz einfach weil das rendering von vielen kleinen polygonen verdammt ineffizient ist.

mit einem unified-shader-core hat man auch keine unterbelasteten vertexshader mehr und man würde sich selbst mit einer so rießigen zahl an polygonen unnötig rechenleistung wegnehmen.

außerdem würden so kleine echte polygone auch nicht besonders gut aussehen, die kanten werden ja "nur" mit normalem multisampling geglättet, wo es bei 6x(ATI) bzw. 8x/16x(NV) schluss ist. die antialiasing-wirkung von texturfiltern bzw. shader-aa können mit geringerem aufwand wesentlich besser aussehen.

[Joolz]

Ist es überhaupt noch so, dasBumpmapping bei Karten wie der R300-128SI Performance bringt statt nimmt. Wieso kann man Bumpmaps nicht komprimieren, welcher Depp hat sich sowas ausgedacht. 32MB Karten ohne BM bringen dann bessere Texturen + Detailtexturen wie ne 128MB Karte mit BM.

[Joolz]

Wenn man stattdessen echte Geometrie nimmt, müßte eine Shader2-Karte mit Vertexshader doch schneller laufen. Selbst die PS2 ersetzt BM durch echte Geometrie bei Splinter Cell CT.

[Gast]

Ist es überhaupt noch so, dasBumpmapping bei Karten wie der R300-128SI Performance bringt statt nimmt.


wieso sollte bump-mapping performance bringen? natürlich kostet es performance


Wieso kann man Bumpmaps nicht komprimieren, welcher Depp hat sich sowas ausgedacht. 32MB Karten ohne BM bringen dann bessere Texturen + Detailtexturen wie ne 128MB Karte mit BM.

natürlich kann man auch bump-maps komprimieren, je nachdem wie man das macht sieht es allerdings nicht unbedingt gut aus.

[Gast]

Wenn man stattdessen echte Geometrie nimmt, müßte eine Shader2-Karte mit Vertexshader doch schneller laufen. Selbst die PS2 ersetzt BM durch echte Geometrie bei Splinter Cell CT.

nö muss sie nicht, und wird sie auch nicht.

du kannst nicht die PS2 mit dem pc vergleichen, die PS2 ist ein sonderfall mit verhältnismäßig extrem hoher geometrieleistung aber unterirdischer pixelleistung, und viel zu wenig texturspeicher.

kleine polygone sind extrem ineffizient zum rendern.

[Spasstiger]

32MB Karten ohne BM bringen dann bessere Texturen + Detailtexturen wie ne 128MB Karte mit BM.
Ich glaube nicht, dass eine 32-MB-Karte (typischerweise DX7-Karten) in HL2 bessere Texturen liefern als eine 128-MB-Karte (typischerweise DX9-Karte). Und HL2 verwendet shadergestütztes Normal-Mapping.

[tokugawa]

ich frage mich eher, warum es NOCH bumpmapping gibt, welches ja nur eine gewölbte oberfläche vorgaukelt.
es hieß doch schon vor jahren der nächste schritt ist displacementmapping :|
und wo sind sie nun die spiele, die das bereits nutzen? ;(


Nicht gewölbt, sondern fein strukturiert. Adern z.B.

Es wird auch in naher Zukunft eher selten sein dass man die Sachen die man durch Normalmapping darstellt durch echte Geometrie ersetzt, weil dann die durchschnittliche Triangle-Fläche auf Subpixel-Niveau sein müsste.

Mal abgesehen davon muß man auch an die Artists denken. Es ist viel leichter für 3D-Modeller, ein bestimmtes Modell zu bauen, und dann halt in Anlehnung an ein "Hautparadigma" (Also dass man quasi eine "Haut" auf das Modell aufzieht, bzw. Tapeten) dann die Texturen wie etwa Bumpmaps dann dem Texturierer überlässt.

Vor allem wenn man viel ähnliche Geometrie hat, die sich hauptsächlich in ihrer feineren Oberflächenstruktur unterscheidet - da kann man dann dasselbe 3D-Modell nehmen mit unterschiedlicher Bumpmap.


verdammt, auf fotorealismus muss ich wohl noch weitere 10 Jahre warten.

Fotorealismus ist das heute schon. Der Begriff "Fotorealismus" wird mißbräuchlich mit "Realismus" verwechselt.

Mal abgesehen davon find ich das gar nicht so interessant.

[ScottManDeath]

Oder der Artist macht ein Model mit hoher Tesselation und eins mit geringer und lässt dann ein Tool die Normalmap erzeugen. Dann sind dir Künstler happy, das sie mit Polygonen schweinsen können, und die Photoshopper auch, das sie nicht die Heightmaps malen müssen ;)

[tokugawa]

Oder der Artist macht ein Model mit hoher Tesselation und eins mit geringer


Schon allein daran kann's scheitern.


und lässt dann ein Tool die Normalmap erzeugen. Dann sind dir Künstler happy, das sie mit Polygonen schweinsen können, und die Photoshopper auch, das sie nicht die Heightmaps malen müssen ;)

Ich hab eigentlich das Gegenteil gemeint. Dass man Heightmaps malen WILL.

Damit hat man, jetzt von der Toolchain aus gesehen, doch sehr viel Einflußmöglichkeiten.

Vorhandene hochtesselierte Geometrie zu modifizieren ist auf jeden Fall zäher als Heightmaps/Bumpmaps zu modifizieren, wenn man nur mal eine Maserung oder Äderchen ändern will.

Außerdem ist das dann wie wenn man auf dem Objekt "feiner malen" würde. Mit einem Grafiktablett eigentlich sehr spaßig.

[tombman]

Das sind Grosse Worte :wink:

Mit 1920x1200+6xAA+16xAF @770/900mhz

EBM=253.4 fps
DOT3= 186.7 fps
SOgar wenn die GTX doppelt so schnell ist wie CF ist das unrealistisch.
1920x1200 16xAF 16xAA TRSSAA

EBM = 347 fps
DOT3= 258 fps

;D;D

Btw, bei etwas über 1000fps war ich cpu limitiert ;D;D (1920x1200 0/0)

p.s. das selbe mit 4xAA: ~700 fps, ~550fps :)

[ScottManDeath]

Schon allein daran kann's scheitern.







Ich hab eigentlich das Gegenteil gemeint. Dass man Heightmaps malen WILL.



Damit hat man, jetzt von der Toolchain aus gesehen, doch sehr viel Einflußmöglichkeiten.



Vorhandene hochtesselierte Geometrie zu modifizieren ist auf jeden Fall zäher als Heightmaps/Bumpmaps zu modifizieren, wenn man nur mal eine Maserung oder Äderchen ändern will.



Außerdem ist das dann wie wenn man auf dem Objekt "feiner malen" würde. Mit einem Grafiktablett eigentlich sehr spaßig.


Mhmm, OK, einigen wir uns drauf das es die Mischung macht ;) Autogeneration und dann die Photoshopper dran lassen =)

[tokugawa]

Mhmm, OK, einigen wir uns drauf das es die Mischung macht ;) Autogeneration und dann die Photoshopper dran lassen =)

Dagegen hab ich nichts gesagt.

Bei mir ging's um die Modifikation vorhandenen Contents, was durchaus vorkommen kann. Und eine Bitmap modifizieren ist um einiges leichter als hochtesselierte Geometrie.

[Gast]

natürlich kann man auch bump-maps komprimieren, je nachdem wie man das macht sieht es allerdings nicht unbedingt gut aus.

Was ist dann das neue an 3dc (was die r300 noch nicht hat) gewesen?

[Gast]

Was ist dann das neue an 3dc (was die r300 noch nicht hat) gewesen?

das ist eigentlich "nur" ein leicht erweitertes DXTC.

von den 3 normalenvektoren werden 2 nach dem gleichen verfahren wie der alpha-kanal bei DXTC gespeichert und die 3. verworfen. die 3. normale muss dann im pixelshader wiederhergestellt werden.

[Neomi]

von den 3 normalenvektoren werden 2 nach dem gleichen verfahren wie der alpha-kanal bei DXTC gespeichert und die 3. verworfen. die 3. normale muss dann im pixelshader wiederhergestellt werden.

Es sind keine 3 Vektoren, sondern nur ein einziger mit 3 Komponenten. Ein klitzegroßer Unterschied.

[Gast]

Es sind keine 3 Vektoren, sondern nur ein einziger mit 3 Komponenten. Ein klitzegroßer Unterschied.

stimmt, hab mich verschrieben sorry ;)
wirklich ein blöder fehler.

allerdings könnte man auch einen 3D-vektor in seine komponenten zerlegen und diese ebenfalls als vektoren ansehen, wobei 2 komponenten dann den wert 0 haben und der 3D-vektor die summe der einzelnen vektoren darstellt, also so ganz falsch ist das auch nicht :D

[Henroldus]

Nicht gewölbt, sondern fein strukturiert. Adern z.B.

Fotorealismus ist das heute schon. Der Begriff "Fotorealismus" wird mißbräuchlich mit "Realismus" verwechselt.

Mal abgesehen davon find ich das gar nicht so interessant.
BM gauckelt durch die lichteinfallsabhängige beleuchtung aber doch eine 3D struktur vor obwohl es nur eine 2 D struktur ist(in schrägansicht oft leicht zu erkennen.

fotorealismus bedeutet für mich, dass ich überlegen muss, ob es echt aussieht.
eine heutiges PAL TV bild sieht trotz der niedrigen auflösung ja auch natürlich aus.
die illusion macht eine hohe polygonzahl(runde ecken :biggrin: ) und vor allem das beleuchtungsmodel(schatten, spiegelungen, ambient light etc)

[L.ED]

Na ja man darf dabei die Menschliche Komponente selbst nicht Vergessen, platt zusammenfassend ausgedrückt, unser Gehirn.

Um das zu Überlisten braucht es gerade bei Computer generierter Grafik wesentlich mehr Aufwand, als es heute (und noch auf längere Zeit), Echt zeitlich eben möglich.

Wenn man eben den Effekt erreichen will das man an wirklicher Authentizität Glauben kann/könnte! (die Auflösung spielt dabei ab bestimmten Punkt, nur bedingt eine Rolle, selbst ein Film in schlechter Qualität kann nämlich *für uns, sprich unser Gehirn* noch genauso gut sehr, sehr authentisch Wirken)

Aber eben nicht umsonst (nach wie vor), die heute und oder seit einigen Jahren nun schon fast ausschließlich rein Computer generierten Hollywood Effekte. Berechnungs- technisch über ganze Renderfarmen im Endeffekt dann nur realisiert. (deshalb sieht es auch so aus, und wenn Zeit<->Aufwendungen keine kritische Rolle spielen (nicht echtzeitlich muß), konnte man schon vor X Jahren über diesen wegen unseren Gehirn authentisches Wirken über Computer retorten Grafik Vorgaukeln)


Aber wenn ich mir anschaue was heute eben Echt zeitlich schon möglich bzw. uns dargeboten. Und mir überlege das man noch zu Seeligen Amiga(Glanz)Zeiten, Beispielsweise das Optische Wirken eines X3, sich bestenfalls unter Raytracing hätte Vorstellen können, wobei auch da nur in Standbildern, die von welchen jedes Einzelne Minimum mehre Stunden Berechnung gebraucht. Von Animationen des Selben mal ganz zu Schweigen oder dessen gar in den Auflösungen wie wir se heute Echt zeitlich dann kennen, sind wir doch schon auf einem guten (akzeptablen) Stand! ;)

Klar ist das alles bisher ein Riesen geFake in der heutigen echtzeitlichen Comptergrafik wie wir sie aus Spielen Kennen (Trickserreien bis zum Erbrechen und mit natürlichen Gegebenheiten hat das nicht wirklich was zu tun)!

Aber es ist ein guter Kompromiss den man noch eine Zeit lang mehr und mehr Verfeinern und Optimieren wird. Bis in ferner Zukunft (wenn die Menschheit so lange noch macht?). Dann wenn die pure Rechenkraft einmal nahezu "unendlich" erscheint und man wohl in der Konsequenz, auf Raytracing zurückgekommen sein wird!?

Erst mit einfachen Algorithmen die nach und nach immer komplexer bis hin zur sprichwörtliche (echtzeitlichen) Simulation von Licht-pothonen und deren physikalischen Eigenheiten und allem was da noch mit hinzu gehört. Also dessen was heute dann u.a. in Hollywood Effekt Farmen von Rechen-Clustern Realisiert und getrieben.

[Henroldus]

[...]Also dessen was heute dann u.a. in Hollywood Effekt Farmen von Rechen-Clustern Realisiert und getrieben.
Ich glaube bei diesem Satz warst Du schon recht müde :biggrin:
</OT>

[Gast]

@L.ED: Raytracing ist auch nicht der heilige Gral...

[L.ED]

Ja der Begriff Cluster ist im Bezeichnenden Sinne bestimmt falsch, aber Sinngemäß meint es dann von mir jetzt eben halt, das da ganze Rechner Armadas. Die jeweils an den Final Berechnungen Rendern.

Und wie diese sich im Einzelnen realisieren ist bestimmt auch noch Effekt Studio abhängig. Ich täte ja auf so Art Server-racks im Keller Tippen und nein ich hab mich damit nie direkt befasst. :)

Aber ich bin mir ziemlich sicher, auch ohne nu speziell wiki & Co zu Befragen, das da so was in der Art dann Anzutreffen (Renderfarmen halt) ?

Diese Erkenntnis schließe ich aus der eingesetzten Software Technik (wie die Effekte realisiert) und dem Wissen drum wie enorm Rechen aufwendig das Ganze nach wie vor ist.

@Gast
Der Spruch hat bereits einen Bart und ist so dann noch immer Falsch Formuliert!

Richtiger währe das Raytracing nicht nötig um dem Menschlichem Auge Realitäten Vorzugaukeln, aber es ist ein verdammt guter Weg. Welchen man in jedem Fall allem anderen von daher vorzieht, wenn es auf die Zeit nicht ankommt, wie es nun mal bei echt zeitlichem nötig!

Und oder allein schon von daher, wenn die durchschnittlichen Computerrohpotenzen in den Haushalten einmal gewaltig genug (nur ne Frage der Zeit), wird man darauf nach und nach dann kommen.

Der heilige Gral in der Computergrafik wurde also schon vor Unzeiten gefunden, nur die Technik die es echt zeitlich ermöglicht (in all seinen möglichen Fassetten), noch nicht!

[Gastafari]

Titan Quest braucht von 153MB Texturen 64MB schon fürs BM. Wieso brauchen PC-Spiele überhaupt soviel Texturram, bei der Kompression 6:1 sind das 900MB Texturen, Konsolen kommen mit 32(x6)MB aus. Jedenfalls also 80MB Texturen zu 64MB Bump Texturen, irre viel für die BM.

[Coda]

Die Konsolen können auch keine andere Texturkompression. Sie sind einfach nicht so hoch aufgelöst. Auf der Matt(sch)scheibe fällt das nicht so auf.

[Gast]

Dann müßte man das am PC halt genauso machen. Wenn ich 800x600 nehme, bräuchte ich ja niedrigere Texturen wie bei 1280 und konnte damit VRam Engpässe umgehen.

[Neomi]

Dann müßte man das am PC halt genauso machen. Wenn ich 800x600 nehme, bräuchte ich ja niedrigere Texturen wie bei 1280 und konnte damit VRam Engpässe umgehen.

Was heißt "müßte"? Die Möglichkeiten (Detailregler) sind da, sie müssen nur noch vom Spieler genutzt werden. Aber die allgemeine Einstellung ist ja leider diese: alles auf Maximum, man könnte ja sonst was verpassen. Und wenn es dann auf Lowend-Hardware ruckelt, ist das Spiel eben "schlecht optimiert".

[Raff]

Ein Spiel ist "schlecht optimiert", wenn es bei gleicher Optik schlechter läuft als die Konkurrenz. Was da wo wie Leistung frisst ist eigentlich egal, da es offenbar Alternativverfahren gibt, die ressourcenschonend(er) gleiche Grafiken erlauben.

MfG,
Raff

[Neomi]

Ein Spiel ist "schlecht optimiert", wenn es bei gleicher Optik schlechter läuft als die Konkurrenz. Was da wo wie Leistung frisst ist eigentlich egal, da es offenbar Alternativverfahren gibt, die ressourcenschonend(er) gleiche Grafiken erlauben.

Nehmen wir mal zwei Spiele, die beide das gleiche Szenario mit identischen Texturen, identischer Geometrie und sowieso allem identisch darstellen. Bei einem ist der Sonnenstand fixiert, beim anderen steht die Sonne zufällig gerade genauso, wandert aber dynamisch über den Himmel. Letzteres Spiel dürfte gerade bei der Schattenberechnung eine Ecke langsamer laufen. Ist es deshalb schlecht optimiert? Nein, nur flexibler.

Anderes Beispiel: KI. Bei einer CPU-Limitierung ist ein Spiel mit starker KI logischerweise langsamer als ein ansonsten identisches Spiel mit Kanonenfutter-KI. Wenn die Gegner nur feuern können und dem Spieler schnurgerade vor die Flinte laufen, passiert auf dem Bildschirm vielleicht sogar mehr, im Falle einer CPU-Limitierung zählt das aber nicht. Können die Gegner auch in Deckung gehen, sich untereinander absprechen und den Spieler einkreisen oder sonstwie gemeinsam attackieren, ist natürlich mehr Rechenzeit nötig. Wieder nicht schlecht optimiert, sondern nur flexibler.

Ein Spiel ist dann (und nur dann) schlecht optimiert, wenn relativ viel Optimierungspotential verschenkt wurde. Optimierungspotential läßt sich aber nicht durch den Vergleich mit "optisch ähnlichen" Spielen messen.

[tokugawa]

Ein Spiel ist "schlecht optimiert", wenn es bei gleicher Optik schlechter läuft als die Konkurrenz. Was da wo wie Leistung frisst ist eigentlich egal, da es offenbar Alternativverfahren gibt, die ressourcenschonend(er) gleiche Grafiken erlauben.

MfG,
Raff

Optik ist nicht nur Technik, sondern zu einem Großteil Artwork.

Optimierung ist reine Softwaretechnik.

Dass man von der Optik - zumindest aus Laienaugen und nicht mit einem technisch versierten Auge das Technik von Art/Content unterscheiden kann - auf die gute oder schlechte Optimierung schließen kann, wäre damit widerlegt.

Das was Neomi geschrieben hat, kann man zu 100% unterschreiben: die Optik (auch nicht "vergleichend") ist kein Indiz für die gute oder schlechte "Optimierung". Es kann genauso gut ein guter oder schlechter Artist sein. Und Art/Content hat mit "Optimierung" nichts zu tun.


Man kann's viel nüchterner definieren:
Ein Spiel ist schlecht optimiert wenn es einen systematischen Bottleneck gibt, der nicht nötig wäre, und zu dem es keinen vernünftigen Trade-off gibt.

Diese Definition ist praxisrelevant und realistisch, denn der Aspekt mit dem Trade-off ist kein unwichtiger: Flexibilität bei der Contenterstellung (komfortable In-Game-Editoren, oder ähnliches) kosten in der Regel etwas Performance und man könnte in diesem Bereich auf Kosten des Content-Erstellungs-Komforts optimieren. Ist das Spiel deswegen schlecht optimiert? Nein. Denn wenn die Artists einfach bequemere Tools haben wollen, ist ein geringer Performance-Trade-off nicht nur erträglich, sondern sogar sehr vernünftig.

[Gast]

Ein Spiel ist "schlecht optimiert", wenn es bei gleicher Optik schlechter läuft als die Konkurrenz. Was da wo wie Leistung frisst ist eigentlich egal, da es offenbar Alternativverfahren gibt, die ressourcenschonend(er) gleiche Grafiken erlauben.Man kann nicht von "schlecht optimiert" sprechen, nur weil die Grafik zweier Spiele auf den ersten Blick ähnlich gut aussieht und eins davon weniger Leistung braucht. Neomis Beispiel mit der Schattenberechnung war da schon sehr gut. "Fake-Schatten" ala HL2 mögen zwar auf den ersten Blick ganz gut aussehen, letztendlich ist mir ein korrekter Echtzeitschattenwurf ala Fear aber lieber, auch wenn es mehr Leistung braucht.

[Gast]

Beispiel Titan Quest: Wieviel MHZ frißt die Physik, alles andere lief auch auf nem Pentium233 mit Diablo. Die Entwickler kauften irgendwelche schlechte Physik und Pathfinding-Middleware, die nur auf Effekt ausgelegt ist aber nicht auf Performanz. Und ich kann beim besten Willen nicht verstehen, warum das jetzt 3Ghz braucht. Insofern wäre es das mindeste, die Physik endlich mal ausschalten zu können oder auf geringere Genauigkeit umzustellen.

[Mr.Magic]

Beispiel Titan Quest: Wieviel MHZ frißt die Physik, alles andere lief auch auf nem Pentium233 mit Diablo. Die Entwickler kauften irgendwelche schlechte Physik und Pathfinding-Middleware, die nur auf Effekt ausgelegt ist aber nicht auf Performanz. Und ich kann beim besten Willen nicht verstehen, warum das jetzt 3Ghz braucht. Insofern wäre es das mindeste, die Physik endlich mal ausschalten zu können oder auf geringere Genauigkeit umzustellen.

Vergleichst du ernsthaft ein 640x480 2D- mit einem DX8 (DX9?) 3D-Game?

[tokugawa]

Beispiel Titan Quest: Wieviel MHZ frißt die Physik, alles andere lief auch auf nem Pentium233 mit Diablo. Die Entwickler kauften irgendwelche schlechte Physik und Pathfinding-Middleware, die nur auf Effekt ausgelegt ist aber nicht auf Performanz. Und ich kann beim besten Willen nicht verstehen, warum das jetzt 3Ghz braucht. Insofern wäre es das mindeste, die Physik endlich mal ausschalten zu können oder auf geringere Genauigkeit umzustellen.

Gerade bei Physik ist es recht schwer "auf geringere Genauigkeit" umzuschalten.

Oder willst du dass Projektile durch Wände durchschießen können oder man einfach durch den Boden flutscht und ähnlichen Schabernack? Das wäre nämlich die Konsequenz.

[Rennsemmel]

Quatsch, man könnte auch Scripte verwenden, außerdem gibt es sowas in Fear und Max Payne 2!

[Gast]

Vergleichst du ernsthaft ein 640x480 2D- mit einem DX8 (DX9?) 3D-Game?

Ja, ich vergleiche sogar Mausklick-Programmierer mit Assembler-Codern, Hammer was!

[Aquaschaf]

Quatsch, man könnte auch Scripte verwenden

Zusammenhang?

[tokugawa]

Falls Rennsemmel auf mein Posting anspricht, hier meine Antwort drauf:

Physik über Scripte? So ein Schwachsinn. Lern erst mal Spiele programmieren.

Klar kann man Physik auch skalieren, aber das geht nur problemlos nur über die Menge der "Physik-Objekte" (z.B. Partikelanzahl), nicht über die Physikberechnung an sich. Oder zumindest nur sehr sehr schwer (mit dem Risiko wie gesagt, dass "ungenauere aber schnellere" Berechnungen zu "Physik-Artefakten" führen wie eben dass Projektile durch Wände durchsausen oder man selbst durch den Boden fällt.



Falls sie nicht auf mein Posting anspricht, dann bitte dieses ignorieren :)

[Mr.Magic]

Ja, ich vergleiche sogar Mausklick-Programmierer mit Assembler-Codern, Hammer was!

Dann musste dich aber fragen wozu Diablo so exorbitant Leistung zieht. Schließlich läuft Young Merlin auf dem SNES perfekt. :|

[Gast]

Ja und Gauntlet lief auf nem 2MHZ Z80 mit 4-Spielern simultan und <=50 Monstern. Das unterstützt jedoch eher meine These als das es sie widerlegt.
Mich würde brennend mal die Geschichte der Physikengine (in Spielen) in einer erstzunehmenden Abhandlung interessieren, aber sowas gibts im allwissenden Internet nicht; ihr braucht jedenfalls nicht zu glauben, das Havok oder PhysX die ersten überhaupt waren, die sowas nutzten. Vielleicht hatte sogar Diablo2 schon eine, who knows?
Physikengines gabs jedenfalls schon in der 90ern bei Incredible Machine, selbst der C64er-Klassiker 'Space Taxi' simulierte die Schwerkraft. Und auch auf der lahmen 500mhz Krücke Gamecube gibts ne Havok-Build, also ist sowas sehr wohl abwärtskompatibel.

[Mr.Magic]

Ja und Gauntlet lief auf nem 2MHZ Z80 mit 4-Spielern simultan und <=50 Monstern. Das unterstützt jedoch eher meine These als das es sie widerlegt.
Mich würde brennend mal die Geschichte der Physikengine (in Spielen) in einer erstzunehmenden Abhandlung interessieren, aber sowas gibts im allwissenden Internet nicht; ihr braucht jedenfalls nicht zu glauben, das Havok oder PhysX die ersten überhaupt waren, die sowas nutzten. Vielleicht hatte sogar Diablo2 schon eine, who knows?
Physikengines gabs jedenfalls schon in der 90ern bei Incredible Machine, selbst der C64er-Klassiker 'Space Taxi' simulierte die Schwerkraft. Und auch auf der lahmen 500mhz Krücke Gamecube gibts ne Havok-Build, also ist sowas sehr wohl abwärtskompatibel.

Incredible Machine und Space Taxi verwenden einfache Scripts, und der Computer hat abgesehen von diesen nicht viel zu tun. Wie sich viele Scripts auswirken kann man ganz gut bei Morrowind testen - da gibt es viele zum ziehen falls man nicht selbst programmieren will (selbst mit den Optimierten geht der Rechner spätestens nach ein paar Dutzend in die Knie, je nach Komplexität).
Viel mehr macht eine Physikengine übrigens auch nicht. Der Unterschied zu Scripts ist, dass Objekte und Materialien bestimmte Eigenschaften (Gewicht, Geschwindigkeit, Reibungswiderstand etc.) haben die sich (ständig) beeinflussen. Ab einer bestimmten Anzahl von bewegten Objekten in geht dem Rechner da einfach die Luft aus. Ruhezustand ist auch nicht (immer) ganz kostenlos, schließlich muss der Zustand der Objekte abgefragt werden.

Für Fehler haftet meine Tastatur.

[Gast]

ihr braucht jedenfalls nicht zu glauben, das Havok oder PhysX die ersten überhaupt waren, die sowas nutzten. Vielleicht hatte sogar Diablo2 schon eine, who knows?


jedes spiel hat eine physikengine, selbst pong oder super-mario auf dem gameboy.

die frage ist nur wie detailiert und wie flexibel diese ist.

[tokugawa]

Ja und Gauntlet lief auf nem 2MHZ Z80 mit 4-Spielern simultan und <=50 Monstern. Das unterstützt jedoch eher meine These als das es sie widerlegt.
Mich würde brennend mal die Geschichte der Physikengine (in Spielen) in einer erstzunehmenden Abhandlung interessieren, aber sowas gibts im allwissenden Internet nicht; ihr braucht jedenfalls nicht zu glauben, das Havok oder PhysX die ersten überhaupt waren, die sowas nutzten. Vielleicht hatte sogar Diablo2 schon eine, who knows?
Physikengines gabs jedenfalls schon in der 90ern bei Incredible Machine, selbst der C64er-Klassiker 'Space Taxi' simulierte die Schwerkraft. Und auch auf der lahmen 500mhz Krücke Gamecube gibts ne Havok-Build, also ist sowas sehr wohl abwärtskompatibel.

Klar, weiß ich alles. "Physikengine" hatte sogar schon Pong. Man könnte den Terminus "Physikengine" als glorifizierte Collision Detection & Response bezeichnen.

Der Punkt ist dass die Berechnung selbst nicht skalierbar ist. Dass es Havok auch auf Gamecube gibt, ist logisch: dort schafft es aber quantifiziert einfach weniger Objekte.

Die Quantität kann man in der Physik skalieren - das hab ich auch bereits so geschrieben. Bei der Qualität ist das schwer ohne dass man sich die Physik in einem Spiel ruiniert, wobei "schwer" nicht "unmöglich" heißt. Aber es ist zach und unlustig, deswegen skaliert man in SPielen hauptsächlich über die Menge der berechneten Physikobjekte und nicht über die Genauigkeit/Qualität der Berechnung (außer etwa über verschiedene Solver, aber das führt wieder zu weit).