"Poly-Bump"

[aths]

Crytek (www.crytek.de) offeriert eine Möglichkeit, per Bumpmapping aus einem High Detail Model ein Low Poly Model zu generieren, in dem entsprechende Bump Maps erzeugt werden. Im Zusammenspiel mit Single Pass Bumpmapping soll dieses Model dann sehr viel schneller zu rendern sein.

Das klingt recht vernünftig.

Wieso wird das eigentlich nicht schon längst umgesetzt? Dot3 Bumpmapping ist immerhin seit GeForce256 verfügbar.

[tEd]

-zu wenig HW support (voodoos und tnts waren immernoch in der überhand)
-die bekanntesten engines hatten kein dot3 support(q2,q3,unreal)
-ob es gut ausgesehn hätte? textur + bumpmap , und wenn man mehr wollte musste man multi pass machen was wiederum zu langsam gewesen wäre

[Demirug]

Ist die gleiche Technik die DOOM III auch benutzt. Ein ähnliches Tool gibt es auch von ATI und einer UNI (müsste ich jetzt raussuchen) auch umsonst.

Nun will Crytek das ganze ja verkaufen und muss die Sache deshalb auch etwas schönreden. Woran mangelt es heute den meisten Chips? An Bandbreite und Fillrate. Durch die geringer Anzahl von Vertexdaten kann man etwas Bandbreite sparen wenn die Daten in der Grafikkarte gespeichert sind. Aber weniger Pixel werden es kaum. Und die Bumpmap ist ja eine Textur die zusätzlich gesampelt werden muss. Und da die interpolatoren nicht unbedingt gut dafür geeignet sind einen normal-Vector über eine Dreieck auch als Normalvektor zu halten braucht man eigentlich noch eine Cubemap zum normalisieren. Das wären dann schon mal 3 Texturen minimum. Und da kommt eine GF256 im Singelpass schon nicht mehr mit zurecht. Solange die Entwickler noch gezwungen sind auf die "alten" Karten rücksicht zu nehmen hat diese Technik nur begrennzte Möglichkeiten im Mainstreambereich.

[[dzp]Viper]

Originally posted by Demirug
Ist die gleiche Technik die DOOM III auch benutzt.


genau das wollte ich auch sagen :)

warum eigentlich immer dieses "wir wollen mehr polygone" wenn es mit bummapping und co und weniger Polygonen genauso oder besser aussieht ....
Ich finde den weg in Doom3 wesentlich vorschrittlicher ...

[Demirug]

Originally posted by [dzp]Viper



genau das wollte ich auch sagen :)

warum eigentlich immer dieses "wir wollen mehr polygone" wenn es mit bummapping und co und weniger Polygonen genauso oder besser aussieht ....
Ich finde den weg in Doom3 wesentlich vorschrittlicher ...

Dann schau dir die verfügbaren DOOM III shots noch mal genau an. Vorallem die Konturen gegen den Hintergrund. Das ist immer noch kantig. Im Prinzip könnte man auch relative ungestraft (was die Leistung angeht) viel mehr polygone und DOT3 Bumpmapping in Kombination einsetzten. Aber leider kommen da die Schatten ins Spiel. Beim Volumenschatten mit Stencilbuffer Verfahren tut jede Kante zwischen 2 Dreiecken der Leistung weh.

[tEd]

Originally posted by [dzp]Viper



genau das wollte ich auch sagen :)

warum eigentlich immer dieses "wir wollen mehr polygone" wenn es mit bummapping und co und weniger Polygonen genauso oder besser aussieht ....
Ich finde den weg in Doom3 wesentlich vorschrittlicher ...

ich denke das ziel ist beides , mehr polygone + bumpmapping , beides ergänzt sich auch sehr gut.

Bumpmapping wird sicher auch noch sinn machen bei sehr grossen polygon mengen , vorallem bei den kleinen oberflächendetails/unebenheiten welche sich nur schwer mit polygonen machen lassen

[[dzp]Viper]

wenn man z.b. für die figuren in Unreal 2 die hälfte der Polygonen verwendet hätte - und dafür dann aber bumpmapping eingesetzt hätte, bin ich der meinung, dass das dann genauso gut oder sogar leicht besser ausgesehen hätte ...
Mir gefallen die D3 figuren sehr gut - ok ein wenig mehr Polygone hätten nicht geschadet - aber im spiel merkt man das dann eh nicht so - nur wenn man godmode anmacht und sich direkt vor eine figur stellt^=)

[Demirug]

Originally posted by [dzp]Viper
wenn man z.b. für die figuren in Unreal 2 die hälfte der Polygonen verwendet hätte - und dafür dann aber bumpmapping eingesetzt hätte, bin ich der meinung, dass das dann genauso gut oder sogar leicht besser ausgesehen hätte ...
Mir gefallen die D3 figuren sehr gut - ok ein wenig mehr Polygone hätten nicht geschadet - aber im spiel merkt man das dann eh nicht so - nur wenn man godmode anmacht und sich direkt vor eine figur stellt^=)

Besser ausgesehen hätte es wahrscheinlich schon. Aber die Performances hätte darunter auch noch mal zu knappern gehabt. Die Rechnung Bumpmapping an dafür weniger Polygone geht leider nicht auf. Weil die Menge an Polygone primär auf die Vertexshader und das Trisetup auswirkt. Bumpmapping aber die Pixelshader belastet.

[Pitchfork]

Und geskinnte Bumpmaps dem Vertexshader nochmal einiges an Mehrarbeit aufbürden.... so führt das also zu weniger, aber dafür aufwendigeren Vertices beim Bumpmapping. Wobei rein vom Vertexdurchsatz her Bumpmapping immer noch von Vorteil ist ggüber Highpoly Modellen.
Aber verrennt euch mal nicht: um die Strukturen zu erzeugen, die Bumpmapping darstellt, müßte man nicht 2-3x so viele Polys einsetzen, sondern gleich 20-50x oder nochmehr, nämlich die Tris tatsächlich bis auf Pixellevel runterbrechen. Das verursacht selbst auf aktueller Hardware dann doch Vertexdurchsatzprobleme.
Polybump und Normalmapper und wie die Tools heissen, setzen auf einer anderen Argumentationskette auf:

1. Wir wollen Bumpmaps, weil mit egal wieviel Polys dieser Detailgrad nicht zu erreichen ist.
2. Bumpmaps zu erstellen ist unintuitiv und unpraktisch für die Grafiker.
3. Aber Ultrahighpoly, das können sie gut!
4. Also laß sie zwei Models erzeugen (realtime und ultrahighpoly) und generiere die Bumpmap aus der Differenz.

Es geht also nicht darum, ein anspruchsvolles Realtimemodel zu komprimieren sondern ein völlig unsinnig detailliertes (aus dem Polystandpunkt) als Vorlage für eine Bumpmap zu nehmen. Es geht hier um die Größenordnung von einer Millionen Vertices runterdampfen auf 30000.

[Rampage 2]

Originally posted by aths
Crytek (www.crytek.de) offeriert eine Möglichkeit, per Bumpmapping aus einem High Detail Model ein Low Poly Model zu generieren, in dem entsprechende Bump Maps erzeugt werden. Im Zusammenspiel mit Single Pass Bumpmapping soll dieses Model dann sehr viel schneller zu rendern sein.

Das klingt recht vernünftig.

Wieso wird das eigentlich nicht schon längst umgesetzt? Dot3 Bumpmapping ist immerhin seit GeForce256 verfügbar.

Kann man mit dieser Technik eigentlich auch Gesichtszüge animieren
(Pixelshader) oder muss man dazu weiterhin die einzelnen Polygone
bewegen (Vertexshader)?

[Demirug]

Originally posted by Rampage 2


Kann man mit dieser Technik eigentlich auch Gesichtszüge animieren
(Pixelshader) oder muss man dazu weiterhin die einzelnen Polygone
bewegen (Vertexshader)?

Theoretisch machbar ist das schon. Man müsste aber für alle Gesichtszüge und die Übergänge eigene Bumpmaps haben. Man muss sich eine Bumpmap als eine Art Haut vorstellen welche über das vom Vertexshader berechnete Gittermodel gezogen wird. Aus diesem Grund überläst man Effekten welche auf Muskel und/oder Knochen bewegungen bassieren besser dem Vertexshader.

[Rampage 2]

Originally posted by Demirug


Theoretisch machbar ist das schon. Man müsste aber für alle Gesichtszüge und die Übergänge eigene Bumpmaps haben. Man muss sich eine Bumpmap als eine Art Haut vorstellen welche über das vom Vertexshader berechnete Gittermodel gezogen wird. Aus diesem Grund überläst man Effekten welche auf Muskel und/oder Knochen bewegungen bassieren besser dem Vertexshader.

Moment mal!

Bei DOT3-Bumpmapping werden doch nur die Pixel einbezogen, d.h. jedem
Pixel wird ein Licht bzw. Schattenwert zugeordnet wodurch das Objekt
plastisch erscheint - warum sollten da noch die Polygone berücksich-
tigt werden???

2.) Müsste die von mir vorgeschlagene Methode denn nicht von dem
Pixelshader berechnet werden? - Es werden ja nur die Pixelwerte
berechnet.

Noch etwas zum Thema Polybump/DOOM3: Irgendwie sind diese Techniken
der Displacement Bump-Mapping Technik ähnlich, habe ich da recht?

[ethrandil]

das beste ist immernoch HW-Displacement !!!
Ist das denn so schwer zu realisieren? und das würde doch auch die Bandbreite schonen, da die Displacementmaps ja im Speicher liegen und zB bei animationen nur die 'paar' Eckpunkte übertragen werden müssten.

Die Parhelia hat doch sowas, oder?

[Demirug]

Mit Schatten hat DOT3-Bumpmapping gar nichts zu tun. Schatten muss man anders berechnen.

Aber ansonsten ist das schon richtig das der plastische Effekt nur aufgrund der Lichtberechnung entsteht. Und Berechnung ist das wichtige Wort hier. Die Bumpmap enthält also keine vorberechneten Werte pro Pixel sondern Vektoren. Diese Vektoren geben an in wie weit die Normale des Pixels von der Normalen des Dreiecks abweicht. Deswegen spricht man davon das diese Vektoren im Tagentspace vorliegen. Um nun die korrekte Lichtberechnung durchzuführen müssen die Vertexshader etwas Vorarbeit leisten. Aus diesem Grund müssen zum Beispiel Lichtvektoren im Vertexshader pro Vertex in den entsprechneden Tagentspace transfomiert werden.

Nahezu jeder Pixelshader effekt muss mit ein paar Daten aus dem Vertexshader gefüttert werden.

Displacement Mapping (Matrox nicht ATI) ist eine ähnliche Technik. Dabei wird die Geometrie mit einer Highmap verändert. Aus einer Highmap kann man recht einfach eine Bumpmap berechnen. Der primäre unterschied ist das Displacement Mapping wirklich die Geometrie verändert Dot3-Bumpmapping aber nur den Eindruck einer veränderten Geometrie erzeugt.

[ethrandil]

Originally posted by Demirug
Displacement Mapping (Matrox nicht ATI) ist eine ähnliche Technik. Dabei wird die Geometrie mit einer Highmap verändert. Aus einer Highmap kann man recht einfach eine Bumpmap berechnen. Der primäre unterschied ist das Displacement Mapping wirklich die Geometrie verändert Dot3-Bumpmapping aber nur den Eindruck einer veränderten Geometrie erzeugt.
Gaynow und damit wäre man auch die Kanten des Bumpmappings los ... Die Schatten wären allerdings weiterhin LANGSAM ... Man könnte natürlich für die Schatten nur die Eckpunkte verwenden, dann wären die nicht ganz so hübsch, müssen sie ja auch net.

Ist das bestandteil von DX10/9 ?? Wird das noch von anderen als matrox unterstützt? Warum nicht?

Eth

[Demirug]

Originally posted by ethrandil
das beste ist immernoch HW-Displacement !!!
Ist das denn so schwer zu realisieren? und das würde doch auch die Bandbreite schonen, da die Displacementmaps ja im Speicher liegen und zB bei animationen nur die 'paar' Eckpunkte übertragen werden müssten.

Die Parhelia hat doch sowas, oder?

Ja die Parhelia kann das. Aber das beste ist denoch nicht, den auch Displacement Mapping hat seine Grenzen. Wenn sich noch was bewegen soll kann man ein Model nicht endloss in kleinere Dreiecke zerlegen. Aber es spricht ja nichts dagegen beide Techniken zu kombinieren. Da aber derzeit nur Matrox diese Feature anbieten kann würde ich mal nicht darauf spekulieren das man sowas sehen wird.

[Demirug]

Originally posted by ethrandil

Gaynow und damit wäre man auch die Kanten des Bumpmappings los ... Die Schatten wären allerdings weiterhin LANGSAM ... Man könnte natürlich für die Schatten nur die Eckpunkte verwenden, dann wären die nicht ganz so hübsch, müssen sie ja auch net.

Ist das bestandteil von DX10/9 ?? Wird das noch von anderen als matrox unterstützt? Warum nicht?

Eth

Stencil-Schatten und Displacement Mapping vertragen sich überhaupt nicht. Und wenn man den Schatten nicht mit dem gleichen Model wie das Licht berechnet gibt es Fehler in der Eigenschattierung.

Displacement Mapping ist eine Option von DX9. Matrox hat bei DX8 etwas die Auslegung gebeugt so das man es auch schon mit DX8 benutzen kann.

Warum das ATI und NVIDIA nicht eingebaut haben dürfte damit zusammenhängen das beide schon mit HOS Technik auf die Nase gefallen sind.

[Chris Lux]

Originally posted by Demirug Aber ansonsten ist das schon richtig das der plastische Effekt nur aufgrund der Lichtberechnung entsteht. Und Berechnung ist das wichtige Wort hier. Die Bumpmap enthält also keine vorberechneten Werte pro Pixel sondern Vektoren. Diese Vektoren geben an in wie weit die Normale des Pixels von der Normalen des Dreiecks abweicht. Deswegen spricht man davon das diese Vektoren im Tagentspace vorliegen. Um nun die korrekte Lichtberechnung durchzuführen müssen die Vertexshader etwas Vorarbeit leisten. Aus diesem Grund müssen zum Beispiel Lichtvektoren im Vertexshader pro Vertex in den entsprechneden Tagentspace transfomiert werden.

Nahezu jeder Pixelshader effekt muss mit ein paar Daten aus dem Vertexshader gefüttert werden.

hi,
ich hab mich schon ein bisschen mit dem thema befasst, aber fragen habe ich immer noch dazu.
sind die normalmaps so generiert, das sie genau auf entsprechende dreiecke gemappet werden müssen (für LOD sachen wäre das eine frage)? wie sieht es aus, wenn sich bei einer animation das 'gebumpmappete' model bewegt und sich winkel zwischen dreiecken ändern, dann dürfte man doch ab bestimmten winkeln wieder kanten sehen, die durch die technik ja versteckt werden sollten. mir ist klar dass auch die vertexnormalen verändert werden und per phong shading über das/die dreieck/e interpoliert werden um dann mit der normalmap verändert zu werden.

[Demirug]

Originally posted by Hans Ohlo


hi,
ich hab mich schon ein bisschen mit dem thema befasst, aber fragen habe ich immer noch dazu.
sind die normalmaps so generiert, das sie genau auf entsprechende dreiecke gemappet werden müssen (für LOD sachen wäre das eine frage)? wie sieht es aus, wenn sich bei einer animation das 'gebumpmappete' model bewegt und sich winkel zwischen dreiecken ändern, dann dürfte man doch ab bestimmten winkeln wieder kanten sehen, die durch die technik ja versteckt werden sollten. mir ist klar dass auch die vertexnormalen verändert werden und per phong shading über das/die dreieck/e interpoliert werden um dann mit der normalmap verändert zu werden.

Ja, eine Normalmap wird genau wie eine "normale" Texture genau auf die Dreiecke gemapt.

Bewegungen des Objekts in sich selbst stellen da schon ein gewisses Problem da. Da man aber beim Skinnig sowieso mehrer Vektoren gewichtet miteinander verrechnet kann man auch mehrer Tangentspace Vektoren miteinader verrechnen. Damit lassen sich dann schon viele Artefakte verhindern.