Ab welcher Hardware ist Bumpmapping möglich?

[BAGZZlash]

Was muß eine GraKa mindestens können? Meiner Meinung nach ging das doch schon mit DirectX v6.0, die Voodoo 3 als DX7-Karte konnte es doch auch? Muß überhaupt ein spezielles Feature zur Verfügung stehen oder ist's rein programmiertechnisch zu lösen und braucht dann zur anständigen Performance nur die passende Füllrate? Oder braucht man schon Hardware-T&L?

[Gast]

hast dir die frage ja schon selber beantwortet. man kann prinzipell alles per software emulieren, ist halt dann nur entsprechend langsam. die imho erste mainstream-karte die bumpmapping in hardware unterstützte war die geforce 3.

[Rockhount]

IMHO müsste es sogar schon der GeForce 256 in Hardware unterstützt haben bzw. Matrox Millenium G400 (enviromental).

Hier ein Link zu nem passenden Artikel:

Bumpmapping auf 3concept.ch (http://www.3dconcept.ch/artikel/bump/2.htm)

Zitat:

Ich wette das Ihre aktueller Grafikchip angeblich Bump Mapping kann. Das ist aber nicht richtig. Ausser dem Matrox G400, dem 3DLabs Permedia 3, dem GeForce256 und VDO PowerVR 250 - Chip kann noch kein Chip echtes Bump Mapping in Hardware. Das was die aktuellen Chips (TNT 1 & 2, Voodoo 1 - 3, Savage4, ...) können sollte man eigentlich nicht Bump Mapping nennen. nVidia hat beim RivaTNT damit angefangen, diese "Embossed" genannte Technik Bump Mapping zu nennen, getreu nach dem Motto "ein Feature mehr auf der Featurelist". 3dfx und S3 zogen bald darauf nach, wobei 3dfx Bump Mapping wieder aus der aktuellen Featurelist für den Voo3oo gestrichen hat.

[PCGH_Carsten]

Emboss-Bump-Mapping konnte bereits jede Multitexturing-fähige Karte - evtl. sogar schon die Voodoo Graphics, aber das weiß ich grad nicht aus dem Kopf.

Environment Mapped Bump Mapping (EMBM) gab's zuerst auf der Matrox G400, dann auf der Ur-Radeon und schließlich auf der Geforce 3.

[AnarchX]

PCGH_Carsten[/POST]']Emboss-Bump-Mapping konnte bereits jede Multitexturing-fähige Karte - evtl. sogar schon die Voodoo Graphics, aber das weiß ich grad nicht aus dem Kopf.

Environment Mapped Bump Mapping (EMBM) gab's zuerst auf der Matrox G400, dann auf der Ur-Radeon und schließlich auf der Geforce 3.

Genau, Voodoo konnte auch EBM.

Dot3-BM gab erst mit der Geforce256 bei Nvidia und dem Radeon bei ATI.
AFAIK ist es doch ein Pflichtteil von Hardware TnL oder?

[Gast]

AnarchX[/POST]']Genau, Voodoo konnte auch EMBM.
Nee, kein EMBM. Emboss. Und das glaube ich, auch nur ab Voodoo2.

[Gast]

kommst darauf an welche art von bumpmapping, da gibt es nämlich sehr viele.

das alte emboss-bump-mapping konnte bereits die voodoo, environmental bumpmapping gab es bei matrox ab der G400, ATI ab der ur-radeon, bei nvidia erst mit der GF3.

dot3 bumpmapping gab es bei nvidia ab der GF256, ati ab der radeon, matrox wohl ab der parhelia.

für fortgeschrittenere bumpmapping-techniken wie displacement-mapping oder relief-mapping ist zumindest eine Shader2.0-karte erforderlich.

[Gast]

AnarchX[/POST]']Genau, Voodoo konnte auch EBM.


keine voodoo konnte, außer emboss-bump-mapping, jemals eine andere bump-mapping-technik, weder dot3 noch evironmental-bumpmapping waren möglich.

[Kloogshicer]

EMBM is aber nicht Embossed. Die GF2 hatte zuerst Dot3only, die G400 EMBM. Kyro hatte EMBM (only?) und die Radeon erstmals alles afaik.

[Gast]

Und was ist die Zukunft von BM. Gibt ja schon Verfahren, die auf ner SM2-Karte nicht mehr laufen, hatte da maln techdemo

[Gast]

diverse relief-mapping-verfahren sind glaub ich zumindest auf SM2.0 nicht mehr lauffähig.

[HOT]

Kloogshicer[/POST]']EMBM is aber nicht Embossed. Die GF2 hatte zuerst Dot3only, die G400 EMBM. Kyro hatte EMBM (only?) und die Radeon erstmals alles afaik.

Kyro konnte beide Verfahren, 3dfx konnte keines von beiden. NV hatte Dot3 ab Geforce1, Matrox ab G400 EMBM und ATI ab der Radeon auch beides. Der Savage2k sollte auch beides können, konnte AFAIK aber auf Grund des buggy Chips nur Dot3.

[Spasstiger]

Gast[/POST]']Und was ist die Zukunft von BM. Gibt ja schon Verfahren, die auf ner SM2-Karte nicht mehr laufen, hatte da maln techdemo
Echtes Displacement Mapping über Geometry Shader (D3D10) könnte vielleicht mal Bumpmapping ablösen.

[Gast]

Spasstiger[/POST]']Echtes Displacement Mapping über Geometry Shader (D3D10) könnte vielleicht mal Bumpmapping ablösen.

das ist dann aber kein bump-mapping mehr, dort wird echte geometrie erzeugt.

zudem wird man wohl auch in zukunft sowohl displacement-mapping als auch bump-mapping einsetzen, wobei displacement-mapping für die "grobe geometrie" und bumpmapping für kleine details zuständig ist.

wenn man alles, was heute mit bumpmapping realisiert wird durch echte geometrie darstellen würde, dann würde das kantenaliasing noch wesentlich stärker und das gesamte rendering fürchterlich ineffizient (GPUs mögen lieber weniger, größere dreiecke als viele kleine)

[Gast]

HOT[/POST]']Der Savage2k sollte auch beides können, konnte AFAIK aber auf Grund des buggy Chips nur Dot3.

Der Savage2k beherrscht weder EMBM noch DOT3. Ob es in Hardware vorgesehen war weiss ich nicht, aber bis zuletzt haben die Treiber keine entsprechenden Features gemeldet.

[Coda]

AnarchX[/POST]']AFAIK ist es doch ein Pflichtteil von Hardware TnL oder?
Nö. Hat nicht die Bohne miteinander zu tun.

[BAGZZlash]

Alles sehr interessant, danke. Gemeinsamer Nenner ist eigentlich, daß Multitexturing verfügbar sein muß, ja?
Klar kann man (fast) alles in Software emulieren, auch tollste SM3.0-Effekte, aber für Echtzeit-Performance bei Bumpmapping sind Euren Aussagen nach GraKas schon lange schnell genug. Warum ist also Bumpmapping erst seit wenigen Jahren so richtig selbstverständlich geworden? In der Prä-Doom3-Ära gab's da doch eigentlich nicht wirklich was, oder?
Wäre doch eigentlich mal ein Thema für die 3DCenter-Homepage: "Die Geschichte des Bumpmapping - Methoden, Unterschiede und Ausblick". Ich würd's verschlingen!

[Gast]

BAGZZlash[/POST]']In der Prä-Doom3-Ära gab's da doch eigentlich nicht wirklich was, oder?

Doch sicher. Das Problem war und ist eben die Verbreitung von Dingen wie "GF2 MX" oder I852G.

[Gast]

BAGZZlash[/POST]']Alles sehr interessant, danke. Gemeinsamer Nenner ist eigentlich, daß Multitexturing verfügbar sein muß, ja?


für emboss-bump-mapping ja (der berühmte 3dfx-donut), für aufwändigere formen von bump-mapping muss es schon etwas mehr sein.

aber für Echtzeit-Performance bei Bumpmapping sind Euren Aussagen nach GraKas schon lange schnell genug.


wer hat von schnell genug geredet?


Warum ist also Bumpmapping erst seit wenigen Jahren so richtig selbstverständlich geworden? In der Prä-Doom3-Ära gab's da doch eigentlich nicht wirklich was, oder?


naja ein paar spiele gab es schon, z.b. giants, das für die landschaft und die haut von kabuto DOT3-bump-mapping benutzt hat, die colin mcrae-reihe benutzt auch seit version 2 oder 3 bumpmapping, und farcry verwendete sogar sehr viel bump-mapping und ist lange vor doom3 erschienen.

aber du hast natürlich recht, dass diese effekte erst lange nach der ersten hardware die es konnte breit eingesetzt wurden, aber das ist eigentlich immer so.

einer der gründe ist sicher der speicherverbrauch, normalmaps brauchen nunmal einiges, vor allem wenn man sie unkomprimiert verwendet. andererseits wollten die meisten softwarehersteller wohl kaum auf das unterschiedliche featureset der IHVs eingehen. da konnte eine karte DOT3, eine ENVBM, die nächste konnte beides.
dieses featureset wurde erst mit der ersten DX-8-hardware halbwegs vereinheitlicht, und dementsprechend verwendet.

ähnliches dürfte wohl mit dem displacement-mapping geschehen, einst mit der parhelia eingeführt wird es wohl als geometry-shader in D3D10 sein revival finden.

[BAGZZlash]

Welche zu Beispiel? /edit: Okay, ich war zu langsam. Danke für die Beispiele. Ja richtig, irgendwie hatte ich vergessen, daß FarCry vor Doom3 da war... :rolleyes:

Auf welche Weise wird bei displacement-mapping via geometry-shader echte Geometrie erzeugt? Ähnlich wie weiland mit ATIs TruForm?

[Gast]

BAGZZlash[/POST]']

Auf welche Weise wird bei displacement-mapping via geometry-shader echte Geometrie erzeugt? Ähnlich wie weiland mit ATIs TruForm?

ähnlich ja, nur hat man im GS wesentlich mehr kontrolle als bei TruForm

[BAGZZlash]

Hmm, TruForm war aber auch reichlich ineffizient, oder? Hoffentlich wird's beim GS nicht genauso... :rolleyes:

[Coda]

BAGZZlash[/POST]']Hmm, TruForm war aber auch reichlich ineffizient, oder? Hoffentlich wird's beim GS nicht genauso... :rolleyes:
Die zwei haben ungefähr soviel gemeinsam wie Sauerkraut und Apfelsaft.

[Neomi]

BAGZZlash[/POST]']Auf welche Weise wird bei displacement-mapping via geometry-shader echte Geometrie erzeugt? Ähnlich wie weiland mit ATIs TruForm?

Immer auf die Weise, die der Programmierer haben will. Das ist ja das tolle an programmierbaren Shadern.

[BAGZZlash]

Die zwei haben ungefähr soviel gemeinsam wie Sauerkraut und Apfelsaft.

Immer auf die Weise, die der Programmierer haben will. Das ist ja das tolle an programmierbaren Shadern.

Hmm, danke für die Beiträge. Mir geht's hier übrigens wirklich darum, was zu lernen... :(

[AnarchX]

BAGZZlash[/POST]']Hmm, danke für die Beiträge. Mir geht's hier übrigens wirklich darum, was zu lernen... :(

Truform:
http://www.3dcenter.org/artikel/2001/06-13a.php
http://www.anandtech.com/showdoc.html?i=1476
Wie du aus diesem Artikel erkennst nimmt sich Truform bestehender Geometry an, wobei aber die Tesselation ziemlich ungerichtet wirkt und deswegen vom Entwickler der Einsatz mit viel Arbeit vorbereitet werden müsste.
Dies war auch ein Grund warum Truform scheiterte.

[Gast]

relief mapping - ist das wieder ein anderes wort für was, was es schon längst gibt. offset-vdm-parallax alles dasselbe

[Neomi]

BAGZZlash[/POST]']Hmm, danke für die Beiträge. Mir geht's hier übrigens wirklich darum, was zu lernen... :(

Auch wenn dir die Antwort nicht gefällt, so ist es nunmal. Der Geometry Shader ist ein programmierbarer Shader, da gibt es keine vorgeschriebene Funktionsweise. Er arbeitet immer so, wie die Instruktionen des jeweiligen Shaders es vorgeben.

Der GS bekommt alle Vertices eines vollständigen Primitives (Punkte, Linien, Dreiecke) und kann vollständige Primitives (meist Dreiecke, aber nicht darauf beschränkt) an den Rasterizer übergeben. Wieviel der GS an den Rasterizer übergibt, ist zwar nach oben begrenzt (4096x float4), aber die Menge ist variabel. Man kann auch die Funktionsweise von Truform exakt nachbilden, das ist aber nur eine von vielen Verwendungsmöglichkeiten.

[Spasstiger]

Könnte man per Geometry Shader eigentlich auch Eckpunkte verschwinden lassen, um Rechenarbeit zu sparen? Oder erreicht man so keine Entlastung der Grafikkarte? Sonst könnte man ja LOD-Systeme über Geometry-Shader laufen lassen.

[Gast]

Spasstiger[/POST]']Könnte man per Geometry Shader eigentlich auch Eckpunkte verschwinden lassen, um Rechenarbeit zu sparen?


prinzipiell kann man eckpunkte verschwinden lassen.


Oder erreicht man so keine Entlastung der Grafikkarte?


wohl kaum, der GS liegt zwischen VS und PS, dementsprechend haben alle vertices bereits den VS durchlaufen (der auch eine art "null-shader" sein kann, also nichts macht).

zwischen GS und PS liegt noch das tri-setup, welches allerdings praktisch nie limitiert und damit auch nicht von weniger vertices profitieren würde.


wesentlich sinnvoller wäre der umgekehrte weg: man übergibt dem VS einfache objekte, die man im GS dann endgültig "ausmodelliert", am besten je nach abstand zur kamera.

[Coda]

Gast[/POST]']prinzipiell kann man eckpunkte verschwinden lassen.
Nur ganze Primitive eigentlich.

[up¦²]

Microsoft DirectX 6 Environment-Mapped Bump Mapping
Matrox G200 :smile:
Among the numerous games implementing support for Environment-Mapped Bump Mapping this year are: Slave Zero from Accolade; Expendable from Rage Software; Messiah from Interplay/Shiny; Carmageddon 3 from Sci/Torus; Mars Maniacs from The Church of Electronic Entertainment; and Dungeon Keeper 2 from EA/Bullfrog, to name a few.
June 28, 1999
http://www.matrox.com/mga/media_center/press_rel/1999/msft_london.cfm

[dildo4u]

Incoming hatte afaik auch Bumpmaps dürfte anno 1998 gewesen sein.

[c0re]

Gast[/POST]']hast dir die frage ja schon selber beantwortet. man kann prinzipell alles per software emulieren, ist halt dann nur entsprechend langsam. die imho erste mainstream-karte die bumpmapping in hardware unterstützte war die geforce 3.

Nö, meine GeForce 2 Ti 500 64 MB DDR konnte das afaik auch.

[AnarchX]

c0re[/POST]']Nö, meine GeForce 2 Ti 500 64 MB DDR konnte das afaik auch.

Geforce 2 Ti 500 :|
Die Geforce 2 konnte Embossed und Dot3-BM.

[c0re]

AnarchX[/POST]']Geforce 2 Ti 500 :|
Die Geforce 2 konnte Embossed und Dot3-BM.

Ja...ahso, das ist kein BM dann!? Ähm, ja.... ich muss....achja, meine Katze... füttern gehen. Sie ist schon sehr hungrig...wirklich... :sneak:


:wink:

[Coda]

Emboss BM würde ich wirklich nich als verwendbar bezeichnen - das konnte aber auch schon eine Voodoo 1.

Dot3-Combiner hat alles ab GeForce/Radeon. Die Voodoo 5 allerdings nicht (wofür 3Dfx nachträglich geschlagen gehört :tongue:)

[Banshee18]

AnarchX[/POST]']Geforce 2 Ti 500 :|
Die Geforce 2 konnte Embossed und Dot3-BM.
Von irgendeinem Hersteller gabs sogar eine Geforce 2 Ti 500. Keine Ahnung warum, vielleicht als DAU-Fang. ;)

[dildo4u]

Banshee18[/POST]']Von irgendeinem Hersteller gabs sogar eine Geforce 2 Ti 500. Keine Ahnung warum, vielleicht als DAU-Fang. ;)Von Gainward wem sonst der Hersteller mit den verwirrensten Produktbezeichungen. *g*


http://www.dooyoo.de/grafikkarten/gainward-geforce2-ti-500-xp-quot-golden-sample-quot/

[ScottManDeath]

Neomi[/POST]']
Wieviel der GS an den Rasterizer übergibt, ist zwar nach oben begrenzt (4096x float4), aber die Menge ist variabel.

Sind leider nur 1024 floats. Ist also nur begrenzt als tesselator verwendbar und war auch nicht dafür gedacht.

[Shink]

Gast[/POST]']Der Savage2k beherrscht weder EMBM noch DOT3. Ob es in Hardware vorgesehen war weiss ich nicht, aber bis zuletzt haben die Treiber keine entsprechenden Features gemeldet.
Interessiert jetzt zwar vermutlich tatsächlich niemanden, aber:
- Die Savage2K-HW beherrscht Dot3-Bumpmapping, aber anscheinend buggy.
- Manche Savage2K-Treiber haben das sogar implementiert, aber deaktiviert. Durch Hacks kann man es in manchen Anwendungen (AFAIK nur 3DMark2K1) aktivieren.
- Schon die Savage 4 (Vorgänger der Savage2K) beherrschte Dot3-Bumpmapping.

Davon abgesehen:
- Dass man EMBM (Environment Bump Mapping) als BumpMapping bezeichnet finde ich eigentlich irreführend.
- EMBM in Dungeon Keeper 2 ist leider eine Matrox-only Implementierung und funzt AFAIK auch nur mit der G400.
- Ich liebe Dungeon Keeper 2. Vielleicht kauf ich mir mal eine G400.

[Gast]

warum wird immer ebm angegeben, das ist fake bump mapping. wurde auch nie in spielen verwendet

[Neomi]

Gast[/POST]']warum wird immer ebm angegeben, das ist fake bump mapping.

Interessanter Satz. JEDE Form von Bumpmapping ist nur ein Fake für feinere Geometrie bzw. eine Oberflächenstruktur.

[Gast]

Shink[/POST]']Interessiert jetzt zwar vermutlich tatsächlich niemanden, aber:
- Die Savage2K-HW beherrscht Dot3-Bumpmapping, aber anscheinend buggy.
- Manche Savage2K-Treiber haben das sogar implementiert, aber deaktiviert. Durch Hacks kann man es in manchen Anwendungen (AFAIK nur 3DMark2K1) aktivieren.
- Schon die Savage 4 (Vorgänger der Savage2K) beherrschte Dot3-Bumpmapping.


Es ist nicht nutzbar, also beherrscht der Chip es nicht. Was ist denn das für eine Aussage: "Der Chip kann es, aber es ist kaputt"?
Genausogut kann man behaupten, dass ein Riva 128 EMBM und DOT3 kann, es aber kaputt ist.

[Gast]

Spasstiger[/POST]']Könnte man per Geometry Shader eigentlich auch Eckpunkte verschwinden lassen, um Rechenarbeit zu sparen? Oder erreicht man so keine Entlastung der Grafikkarte? Sonst könnte man ja LOD-Systeme über Geometry-Shader laufen lassen.

Würde man damit nicht die UV Map total durcheinander bringen?

[Coda]

Man kann wie gesagt nur ganze Dreiecke raushauen.

[c0re]

Banshee18[/POST]']Von irgendeinem Hersteller gabs sogar eine Geforce 2 Ti 500. Keine Ahnung warum, vielleicht als DAU-Fang. ;)

Wieso DAU-Fang. Das war eine Golden Sample. Die Karte ging ab wie eine Sau.

[tokugawa]

Neomi[/POST]']Interessanter Satz. JEDE Form von Bumpmapping ist nur ein Fake für feinere Geometrie bzw. eine Oberflächenstruktur.

Naja, wenn man analytische Tracer auch in die Klasse von Bumpmapping gibt (was ich tue), dann stimmt das nicht.

Auch die fortgeschritteneren Parallaxmapping-Techniken (mit richtiger Silhouette usw.) sind IMO nicht mehr "fake", da man mit Geometrie auch erst dann genauere Formen schaffen könnte, wenn die Geometrie feiner tesseliert wäre als die Texel der Parallax-Map bzw. des Heightfields bzw. der Sampling-Rate der Analytischen Funktion - also Dreiecke auf Subtexelniveau.



Und wenn man von "fake" redet: letztendlich ist in der Echtzeitgrafik sowieso ALLES fake.

[Gast]

Neomi[/POST]']Interessanter Satz. JEDE Form von Bumpmapping ist nur ein Fake für feinere Geometrie bzw. eine Oberflächenstruktur.

ja nur das ist eben fake fake mapping

[Gast]

Nein, das Mapping ist das einzige was nicht 'fake' daran ist. Die simulierte Oberfläche ist es.

Aber es stimmt schon. Das ganze gezeigte Objekt ist fiktiv.

Ein nicht vorhandenes Objekt mit einer simulierten Oberfläche. *lol*

[Neomi]

tokugawa[/POST]']Naja, wenn man analytische Tracer auch in die Klasse von Bumpmapping gibt (was ich tue), dann stimmt das nicht.

Auch die fortgeschritteneren Parallaxmapping-Techniken (mit richtiger Silhouette usw.) sind IMO nicht mehr "fake", da man mit Geometrie auch erst dann genauere Formen schaffen könnte, wenn die Geometrie feiner tesseliert wäre als die Texel der Parallax-Map bzw. des Heightfields bzw. der Sampling-Rate der Analytischen Funktion - also Dreiecke auf Subtexelniveau.

Das hängt davon ab, wo man die Grenze zieht. Kann etwas ein Fake sein, wenn das Ergebnis identisch zum "Original" (in dem Fall der vorgegaukelten Geometrie) ist? Meiner Meinung nach ja, und dann sind selbst analytische Tracer (die ich ebenfalls zu Bumpmapping zähle) ein Fake.

tokugawa[/POST]']Und wenn man von "fake" redet: letztendlich ist in der Echtzeitgrafik sowieso ALLES fake.

Das ist sowieso klar.

[Coda]

c0re[/POST]']Wieso DAU-Fang. Das war eine Golden Sample. Die Karte ging ab wie eine Sau.
Kann aber kein Multisampling :(

[tokugawa]

Neomi[/POST]']Das hängt davon ab, wo man die Grenze zieht. Kann etwas ein Fake sein, wenn das Ergebnis identisch zum "Original" (in dem Fall der vorgegaukelten Geometrie) ist? Meiner Meinung nach ja, und dann sind selbst analytische Tracer (die ich ebenfalls zu Bumpmapping zähle) ein Fake.


Andersherum mußt du allerdings auch fragen: sind polygonale B-Reps nicht auch nur ein Fake im Vergleich zu der Oberfläche, die sie beschreiben sollen? Die möglicherweise durch eine Formel beschreibbar ist? Womit dann Analytische Tracer dann die nicht-fake Variante sind, und Polygone eben die fake Variante?

Man muß ja die B-Rep-Geometrie nicht unbedingt als "Original" sehen (tu ich auch nicht). Ich sehe ja Bumpmapping-Algorithmen nicht als Methode, höher tesslierte Geometrie vorzugaukeln, sondern eben eine Oberfläche zu simulieren, d.h. bei mir ist das "Original" nicht die Geometrie, sondern die Oberfläche, die man simulieren will, und damit nicht weniger oder mehr "fake" als würde man es mit Polygonen ausmodellieren.

Man sieht, das geht in vielerlei Richtung - in der Echtzeitgrafik sollte man nicht anfangen irgendwas als "fake" zu kritisieren. Das hört sonst nämlich nirgends auf.

[aths]

BAGZZlash[/POST]']Was muß eine GraKa mindestens können? Meiner Meinung nach ging das doch schon mit DirectX v6.0, die Voodoo 3 als DX7-Karte konnte es doch auch? Muß überhaupt ein spezielles Feature zur Verfügung stehen oder ist's rein programmiertechnisch zu lösen und braucht dann zur anständigen Performance nur die passende Füllrate? Oder braucht man schon Hardware-T&L?Natürlich müssen dazu spezielle Features zur Verfügung stehen. Jeder Pixelshader (auch Version 1.0) bringt qua definitionem auch diverse Bumpmapping-Fähigkeiten mit. "Normales" Bumpmapping ist eigentlich Dot3-BM, was eine GeForce 256 auch ohne Pixelshader beherrscht, da die Dot3-Operation im Combiner (also pro Pixel) angeboten wird. Andere Bumpmapping-Arten, wie Environment(al) Bumpmapping sind aufwändiger, weil dafür dependent reads erforderlich sind (man muss also Texturkoordinaten anhand der Werte einer vorher gesampelten Textur modifizieren können.)

Man kann einen Dot3-BM-Effekt auch faken, das nennt sich dann Emboss Bumpmapping und erfordert mehrere Texturzugriffe, ist aber was den Beleuchtungwinkel angeht, eingeschränkt, und ohnehin recht ungenau.

Neomi[/POST]']Interessanter Satz. JEDE Form von Bumpmapping ist nur ein Fake für feinere Geometrie bzw. eine Oberflächenstruktur.Genau. Texturen sind Fake, die Tesselation in Dreiecke ist ein Fake, ... überhaupt 2D-Grafik als 3D-Grafik zu bezeichnen, ist auch ein Fake, was wir so 3D-Grafik nennen ist ja in Wahrheit flach. Dann Geometrie mit Bumpmapping zu faken ist zwar ein Fake im Fake, aber letztlich ist die "3D-Grafik" ohnehin ein Riesenfake. Hauptsache, es kommt glaubwürdig rüber.

[tokugawa]

Wenn man das weiterspinnt: unsere wahrgenommene Realität ist auch nur ein fake der objektiven Realität (falls es diese überhaupt gibt).

Und damit wären wir bei der Philosophie angelangt :)

[aths]

tokugawa[/POST]']Wenn man das weiterspinnt: unsere wahrgenommene Realität ist auch nur ein fake der objektiven Realität (falls es diese überhaupt gibt).

Und damit wären wir bei der Philosophie angelangt :)Ja, die "objektive Realität" kann man ohnehin nicht ermitteln, sonst könnten wir im Leben einfach Schlussfolgerungen ziehen – und müssten keine Entscheidungen mehr treffen. (Dies habe ich mal frech von Manfred Spitzer (http://www.br-online.de/alpha/geistundgehirn/) übernommen.)

Ich würde das Bumpmapping-Problem vereinfachen: Jede Bumpmapping-Art funktioniert nur unter bestimmten Bedingungen zufriedenstellend. Sofern diese Bedingungen gegeben sind, ist Bumpmapping ein sinnvoller Fake in der ohnehin gefakten 3D-Grafik. Es ist oft nicht notwendig, "echte" Geometrie zu haben, weil die Unterschiede in der Grafik minimal wären. Wenn die Unterschiede größer sind, muss man halt abwägen was man mit der gegebenen 3D-Leistung machen kann und was nicht.

[tokugawa]

aths[/POST]']
Ich würde das Bumpmapping-Problem vereinfachen: Jede Bumpmapping-Art funktioniert nur unter bestimmten Bedingungen zufriedenstellend. Sofern diese Bedingungen gegeben sind, ist Bumpmapping ein sinnvoller Fake in der ohnehin gefakten 3D-Grafik. Es ist oft nicht notwendig, "echte" Geometrie zu haben, weil die Unterschiede in der Grafik minimal wären. Wenn die Unterschiede größer sind, muss man halt abwägen was man mit der gegebenen 3D-Leistung machen kann und was nicht.

Wie gesagt, ich halte GPU-Vertex-Geometrie nicht für "echter" als die Variante einer Oberflächensimulation mittels "Per-Pixel-Geometrieabtastung im Pixelshader" (was ein analytischer Tracer im Prinzip wär).

Anstatt dass man eine Geometrie rasterisiert die als Primitive/Vertexdaten in Boundary Repräsentation vorliegt, rasterisiert man (im Pixelshader) halt Geometrie, die als Formel vorliegt, oder eben als "Map" (die halt im entferntesten Sinne - teilweise beschränkt, teilweise vollständiger - auch Information über die "Oberflächengeometrie" speichert - Texturen als Funktionstabelle quasi). Das kann man ja mathematisch auch als eine "Geometrierepräsentation" sehen, nur halt nicht im GPU-Vertex-Pipeline-Sinn.

Der Nachteil dass bei vielen Bumpmapping- bzw. Parallaxmapping-Techniken die Silhouette nicht stimmt da man im Prinzip eine planare Fläche rendert (was wohl das einzige Argument wäre, inwiefern diese Techniken "faker" sind als Vertexgeometrie), trifft auf neueste Algorithmen nicht mehr zu.

[Gast]

Was es in Spielen mehr "fake" macht, ist die Tatsache, dass die eigentlich immer noch flache Oberfläche, auch wenn deutlich Teile aus ihr hinausragen, trotzdem keine veränderte Kollisionsabfrage hat.

Ich bezweifele dass man daran viel ändern kann...

[tokugawa]

Gast[/POST]']Was es in Spielen mehr "fake" macht, ist die Tatsache, dass die eigentlich immer noch flache Oberfläche, auch wenn deutlich Teile aus ihr hinausragen, trotzdem keine veränderte Kollisionsabfrage hat.

Ich bezweifele dass man daran viel ändern kann...

Sicher, aber das hatte man selbst bei ausmodellierter Geometrie.

Meistens verwendet man für Kollisionsabfrage bzw. Physik auch niedriger aufgelöste Meshes als jene, die gerendert werden, ganz einfach weil das Performance bringt.

Für das Gameplay ist es normal ziemlich irrelevant, für jede kleinste Rille Collision Response zu berechnen, da schaut man darauf, dass bei einem niedrigen Oberflächendelta (nur feine Unterschiede) diese eher bei der Kollsionsabfrage ignoriert. Das bringt dann massig Performance.

[Gast]

Bei Offsetmapping kann man klar erkennbare Objekte aus einer Wand ragen sehen...

Imho sehen die 100%ig so aus, als könnte man nicht einfach gerade an der Wand entlanglaufen, sondern müsste ausweichen. Ich bin mir ziemlich sicher, dass das ein Problem wird.

Vielleicht kann man ja noch irgendwie über den blauen Farbkanal eine Fake Kollisionsabfrage einbauen, ansonsten wird das Feature doch stark eingeschränkt, obwohl es viel mehr könnte...

[Gast]

Ich habe gerade die Vergleichsbilder gefunden, die ich eben in Hinterkopf hatte.

http://graphics.cs.brown.edu/games/SteepParallax/index.html


Spätestens bei Steep Parallax Mapping, muss etwas passieren.

[tokugawa]

Gast[/POST]']Bei Offsetmapping kann man klar erkennbare Objekte aus einer Wand ragen sehen...

Imho sehen die 100%ig so aus, als könnte man nicht einfach gerade an der Wand entlanglaufen, sondern müsste ausweichen. Ich bin mir ziemlich sicher, dass das ein Problem wird.

Vielleicht kann man ja noch irgendwie über den blauen Farbkanal eine Fake Kollisionsabfrage einbauen, ansonsten wird das Feature doch stark eingeschränkt, obwohl es viel mehr könnte...


Die Render-Geometrie muß nicht unbedingt mit der Kollisionsgeometrie übereinstimmen.

Wenn tatsächlich eine Bumpmapping-Technik dazu mißbraucht wird, extrem rausragende/"reinragende" Objekte (großes Oberflächen-Delta) zu bauen, dann kann man dies in der (unsichtbaren) Geometrie die für die Kollisionsabfrage verwendet wird, berücksichtigen.

Bei kleineren rausragenden (bzw. "reinragende") Oberflächendetails bringt es für's Gameplay ja sowieso nichts, wenn die Kollisionsabfrage dies berücksichtigen würde.

Wenn man an einer "bumpy wall" entlanggleitet, kratzt man sich ja sowieso nur die Schulter auf (und eventuell rüttelt die Kamerasicht etwas), aber richtige Auswirkungen hat's nicht.

[Gast]

Oh... stimmt. Das macht Sinn. Also ist das Problem weit weniger schlimm als ich dachte.


Ich frage mich wie weit Bumpmapping noch kommen wird.

Ob irgendwann nur noch Box Modelle im Spiel rumlaufen, denen jegliches Detail via normal Map gegeben wird?

Mit dem normalen Normal Mapping, waren die Ecken der Modelle noch ein Problem. Jetzt kann die Fake Geometrie über die eigentliche Modell Fläche hinausgehen.

Sogar gröbste Formen sollten auchreichen um komplexe Geometrie zu simulieren.

[elianda]

Ich finde hier fehlt eindeutig mal eine Tabelle / Datenbank mit den realen Features in Hardware die die Karten koennen. (Ich meine damit nicht die verwaschenen Marketingnamen).
Am besten auch, dass man Zwei auswaehlen kann und es dann anzeigt, was die eine Karte mehr / anderes kann. So aehnlich wie Verzeichnisse synchronisieren im Total Commander.

[Coda]

Gast[/POST]']Sogar gröbste Formen sollten auchreichen um komplexe Geometrie zu simulieren.
Nö. Man bekommt an den Kanten und bei flachen Betrachtungswinkel viel zu große Probleme für sowas.

[tokugawa]

Coda[/POST]']Nö. Man bekommt an den Kanten und bei flachen Betrachtungswinkel viel zu große Probleme für sowas.

Da tut sich grad allerdings einiges in Bezug darauf. Jemand von unserem Insti hat da ein Paper geschrieben über eine weitere Methode, bei der Silhouette Edges kein Problem sind (SM3.0 ist natürlich Vorraussetzung). Leider weiß ich nicht mehr wie das Paper geheißen hat...

Klar, bis das "praxisreif" für Spiele wird, dauert's eine Weile, aber bei diversen Visualisierungsanwendungen ist das schon durchaus praktibel.

[Gast]

tokugawa[/POST]']Da tut sich grad allerdings einiges in Bezug darauf. Jemand von unserem Insti hat da ein Paper geschrieben über eine weitere Methode, bei der Silhouette Edges kein Problem sind (SM3.0 ist natürlich Vorraussetzung). Leider weiß ich nicht mehr wie das Paper geheißen hat...



leider funktioniert das ganze aber nicht mit multisampling, und mit TSAA kostet das ganze jede menge leistung ;)

[Xmas]

Gast[/POST]']leider funktioniert das ganze aber nicht mit multisampling, und mit TSAA kostet das ganze jede menge leistung ;)
Deswegen wird man im D3D10-Nachfolger auch mehr Kontrolle über die Samples im Shader haben.

[Darkstar]

Shink[/POST]']- EMBM in Dungeon Keeper 2 ist leider eine Matrox-only Implementierung und funzt AFAIK auch nur mit der G400.Die EMBM-Unterstützung in Dungeon Keeper 2 ist keine Matrox-only-Implementierung. Auf meinen Kyros hat es problemlos funktioniert. Bei Expendable läßt sich EMBM nur auf einer Matrox G4x0 einschalten.