Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Wie stark komprimiert 3Dc?
Leonidas
2005-06-15, 21:13:02
Link:
http://www.3dcenter.org/artikel/3dc/
Banshee18
2005-06-15, 21:56:12
Damit die Lichtberechnung ein "schönes", kantenloses Ergebnis liefert, muss das Dreieck aus beleuchtungstechnischer Sicht gebogen sein. Dies erreicht man, in dem die Normalen der Dreie ckspunkte nicht senktrecht zur Dreiecksfläche stehen, sondern für eine konvexe Oberfläche abgespreizt sind, und für eine konkave Rundung zueinander geneigt (konvex heißt in diesem Kontext "nach außen gebogen", konkav "nach innen gebogen").
Da hat sich der Fehlerteufel eingeschlichen. =)
Weitere Fehler folgen eventuell, sobald ich mit dem Artikel fertig bin.
Normalmaps kann man aus Heightmaps gewinnen, welche wiederum die Höhe speichern. Wir zeigen der Übersichtlichkeit wegen nicht, wie man 3D-Normalen aus einer 2D-Höhenkarte gewinnt, sondern wie man 2D-Normalen aus einer 1D-Höhenkarte gewinnen kann.
Demirug
2005-06-15, 22:03:44
DXT2 entspricht vom Aufbau her genau DXT3, nur dass die berechneten Alpha-Werte im Alphablender anders interpretiert werden. Der gleiche Zusammenhang besteht zwischen DXT4 und DXT5.
Das würde ich aber ganz schnell entfernen. Auf das Alphablending hat das DXT Format keinen Einfluss.
Das würde ich aber ganz schnell entfernen. Auf das Alphablending hat das DXT Format keinen Einfluss.DXT2 und 4 speichern doch "premultiplied" Alpha-Werte?
BUGFIX
2005-06-15, 22:11:28
Erstmal:
Schöner Artikel - großes Lob
Ich will es mir aber nicht nehmen lassen noch etwas Anzumerken:
ist das Offsetmapping wirklich so der Weißheit letzter Schluss? - ich meine mal Hand auf Herz - es sieht ziemlich mies aus.
Vor allen dann, wenn von der Seite auf die zu tode gestretchten Teile der Textur geschaut wird.
Naja - nur so meine Meinung
MfG
BUGFIX
Leonidas
2005-06-15, 22:22:17
Damit die Lichtberechnung ein "schönes", kantenloses Ergebnis liefert, muss das Dreieck aus beleuchtungstechnischer Sicht gebogen sein. Dies erreicht man, in dem die Normalen der Dreie ckspunkte nicht senktrecht zur Dreicksfläche stehen, sondern für eine konvexe Oberfläche abgespreizt sind, und für eine konkave Rundung zueinander geneigt (konvex heißt in diesem Kontext "nach außen gebogen", konkav "nach innen gebogen").
Normalmaps kann man aus Heightmaps gewinnen, welche wiederum die Höhe speichern. Wir zeigen der Übersichtlichkeit wegen nicht, wie man 3D-Normalen aus einer 2D-Höhenkarte gewinnt, sondern wie man 2D-Normalen aus einer 1D-Höhenkarte gewinnen kann.
Gefixt. Thx.
Erstmal:
Schöner Artikel - großes Lob
Ich will es mir aber nicht nehmen lassen noch etwas Anzumerken:
ist das Offsetmapping wirklich so der Weißheit letzter Schluss? - ich meine mal Hand auf Herz - es sieht ziemlich mies aus.
Vor allen dann, wenn von der Seite auf die zu tode gestretchten Teile der Textur geschaut wird.
Naja - nur so meine MeinungEs sieht plastischer aus als normales Bumpmapping. Der neuste Schrei ist Reliefmapping, das ist noch besser als Offsetmapping, weil es echte Höhenänderungen darstellen kann. Aber sowohl Offsetmapping als auch Reliefmapping ist nur ein Oberbegriff – genau wie Bumpmapping. Wie gut es dann aussieht hängt von der konkreten Realisierung ab. Humus hat Offsetmapping in seiner Demo nachträglich fix eingebaut, es ginge sicherlich auch besser – wenn man einen aufwändigeren Pixelshader schreibt.
Banshee18
2005-06-15, 22:49:10
Im ersten zitierten Abschnitt sind nochmal 2 Fehler, die mir beim ersten Lesen entgangen sind. Habs editiert.
Es sieht plastischer aus als normales Bumpmapping. Der neuste Schrei ist Reliefmapping, das ist noch besser als Offsetmapping, weil es echte Höhenänderungen darstellen kann. Aber sowohl Offsetmapping als auch Reliefmapping ist nur ein Oberbegriff – genau wie Bumpmapping. Wie gut es dann aussieht hängt von der konkreten Realisierung ab. Humus hat Offsetmapping in seiner Demo nachträglich fix eingebaut, es ginge sicherlich auch besser – wenn man einen aufwändigeren Pixelshader schreibt.
auch ein aufwändigerer Shader könnte nix gegen das stretchen der ausgangstextur unternehmen,es fehlt ja halt an informationen was zusätzlich in den "gestretchen" teil als textur reinsollte oO
Leonidas
2005-06-15, 23:37:18
Im ersten zitierten Abschnitt sind nochmal 2 Fehler, die mir beim ersten Lesen entgangen sind. Habs editiert.
Gefixt.
http://www.3dcenter.de/images/3dc/height4.png
Warum gehen die Lichtstrahlen zu den Pfeilspitzen der Normalen? :|
Obendrüber ist noch so ein Bild, das dadurch auch arg seltsam aussieht.
Wäre ne Überarbeitung wert...
Demirug
2005-06-15, 23:56:48
DXT2 und 4 speichern doch "premultiplied" Alpha-Werte?
Nein, die Farbwerte sind mit den Alphawerten "premultiplied". Das war mal für Chips mit nur einer Texture pro Pass und verkrüppeltem AlphaBlender gedacht. Spielt heute aber eigentlich keine Rolle mehr. OK man könnte ein MUL im Shader sparen. Nur kann man das auch wenn man DXT 3 und 5 nimmt. Um es auf den Punkt zu bringen. Im Treiber und Chip gibt es keinen Unterschied zwischen DXT2 und 3 bzw 4 und 5. Nur im Toolchain wird unterschieden.
Nein, die Farbwerte sind mit den Alphawerten "premultiplied". Das war mal für Chips mit nur einer Texture pro Pass und verkrüppeltem AlphaBlender gedacht. Spielt heute aber eigentlich keine Rolle mehr. OK man könnte ein MUL im Shader sparen. Nur kann man das auch wenn man DXT 3 und 5 nimmt. Um es auf den Punkt zu bringen. Im Treiber und Chip gibt es keinen Unterschied zwischen DXT2 und 3 bzw 4 und 5. Nur im Toolchain wird unterschieden."Das war mal für Chips mit nur einer Texture pro Pass und verkrüppeltem AlphaBlender gedacht." – die Farbwerte werden im Alphablender anders interpretiert – stimmt diese Formulierung denn?
http://www.3dcenter.de/images/3dc/height4.png
Warum gehen die Lichtstrahlen zu den Pfeilspitzen der Normalen? :|
Obendrüber ist noch so ein Bild, das dadurch auch arg seltsam aussieht.
Wäre ne Überarbeitung wert...Die Lichtstrahlen sollten eigentlich zum Fußpunkt der Normalen gehen. Dass sie zu der Pfeilspitze gehen soll andeuten, dass der Lichtwinkel mit dem Normalenwinkel verrechnet wird. Ich weiß, dass diese Darstellung suboptimal ist, hatte aber keine bessere Idee.
Ich weiß, dass diese Darstellung suboptimal ist, hatte aber keine bessere Idee.
Einfach die normale Darstellung verwenden?
Die ist eindeutig und da gibts auch nicht viel rumzuüberlegen.
So sind da ein paar Lichtstrahlen eingezeichnet die garnichts mit den eingezeichneten Normalen zu tun haben.
Wenn du mehr andeuten willst wäre es noch eine Möglichkeit einfach die Winkel zwischen Lichtstrahl und Normale einzuzeichnen.
Piffan
2005-06-16, 00:45:13
Ich habe es noch nicht "erschöpfend" gelesen und komplett verstanden, aber vom ersten Eindruck her: saubere Arbeit! :up:
Guter Artikel, besonders die Komprimierungs-Mouseover-Bilder sind wirklich mal 'ne coole Sache. Ein bisschen was zu Relief-Mapping wäre noch ganz schön gewesen aber das wäre wohl zuviel des Guten geworden.
Einfach die normale Darstellung verwenden?
Die ist eindeutig und da gibts auch nicht viel rumzuüberlegen.
So sind da ein paar Lichtstrahlen eingezeichnet die garnichts mit den eingezeichneten Normalen zu tun haben.
Wenn du mehr andeuten willst wäre es noch eine Möglichkeit einfach die Winkel zwischen Lichtstrahl und Normale einzuzeichnen.Ja, das war meine erste Idee, aber dann dachte ich, das wäre zu viel des Guten und würde nur verwirren. Aber du hast recht, die aktuelle Lösung ist nicht optimal. Ich überlegs mir, ob ich die beiden Bilder ändere.
edit: Anstatt den Winkel so schön mit Schenkeln etc einzuzeichnen, habe ich (von Hand, sieht etwas krude aus) jetzt ausgefüllte "Tortenstücke" genommen. Der Zusammenhang sollte mit der neuen Illustration jetzt besser klar werden.
Guter Artikel, besonders die Komprimierungs-Mouseover-Bilder sind wirklich mal 'ne coole Sache. Ein bisschen was zu Relief-Mapping wäre noch ganz schön gewesen aber das wäre wohl zuviel des Guten geworden.Das ist jetzt schon viel mehr geworden als geplant. Reliefmapping habe ich weggelassen weil das für den praktischen Einsatz noch zu aufwändig ist. Letztlich ist es "nur" ein besonders gutes Offsetmapping, und dies wiederum ist nichts weiter als ein besonders hochwertiges Bumpmapping. Für des Kapitel "Ausblick" war mir nur wichtig, dass modernere Bumpmapping-Verfahren eben noch die Heightmap brauchen.
Andere Bumpmapping-Arten wie z. B. EMBM habe ich gleich gar nicht erwähnt, auch Emboss BM kommt mit keinem Wort vor. Der Sinn des Artikel war es ja nicht, dass ich alles aufschreibe was ich übers Bumpmapping weiß :) sondern die 3Dc-Technik von ATI in den Zusammenhang zu setzen, wo sie besonders häufig angewendet wird.
Banshee18
2005-06-16, 09:50:11
Der Sinn des Artikel war es ja nicht, dass ich alles aufschreibe was ich übers Bumpmapping weiß :)...
Wäre das nicht eine Idee für einen weiteren Artikel? =)
Imho ein sehr interessantes Thema, worüber ich mich sehr gerne weiterbilden würde. Wenn man ein wenig Ahnung von Mathematik hat, ist es auch nicht so schwer verständlich.
Demirug
2005-06-16, 10:00:32
"Das war mal für Chips mit nur einer Texture pro Pass und verkrüppeltem AlphaBlender gedacht." – die Farbwerte werden im Alphablender anders interpretiert – stimmt diese Formulierung denn?
Nein, die Interpretation der Farbwerte im Alphablender ist völlig unabhängig von den gewählten Textureformate. Für das Textureformat interesiert sich nur die TMU und für die ist DXT2 und 3 bzw DXT4 und 5 gleichwertig.
Aktuelle Grafikchips können bei Vektoren mit drei Komponenten pro Pixelpipe und Takt bei Vektoren mit drei Komponenten nur ein Skalarprodukt berechnen.
2x das gleiche sieht etwas komisch aus ;)
ansonsten toller artikel, auch für den laien verständlich, obwohl ich mir etwas mehr über relief-mapping gewünscht hätte, aber das kann ja noch kommen ;)
tombman
2005-06-16, 11:57:12
ALso bumpmapping und co ist ja sicher tausend mal besser als gar nix (offset mapping find ich schon mal recht nice), aber ich bin echter Polygonfan, nichts schlägt echte Geometrie :cool:
Gaestle
2005-06-16, 13:09:05
In der Ankündigung steht "dediziert" statt wie IMHO richtig "dezidiert"
Grüße
[edit]: sorry, hab's nicht gesehen...Danke Crushi
Crushinator
2005-06-16, 13:13:38
*Post von Gaestle in den Thread merged* :)
[Edit]
Den nachfolgenden Beitrag auch. Das Posting von Schroeder mit dem Hinweis, daß es diesen Thread gibt, habe ich ohne böse Absicht entsorgt. Bitte um Verständnis.
Besserwisser
2005-06-16, 13:43:19
Was mir schon am Anfang aufgefallen ist...
In Grundlagen der Beleuchtung:
"In der Geometrie ist eine Normale ein Zeiger (im Jargon: ein Vektor), der senkrecht auf der Ebene steht."
-> Ich dachte, ein Normalvektor ist ein Vektor der Länge null ... *wunder*
Nette Grammatik:
"Sofern wenn beide Operanten ..." :tongue:
Werd mal weiterlesen.
Gaestle
2005-06-16, 13:46:13
Es sieht plastischer aus als normales Bumpmapping. Der neuste Schrei ist Reliefmapping, das ist noch besser als Offsetmapping, weil es echte Höhenänderungen darstellen kann. Aber sowohl Offsetmapping als auch Reliefmapping ist nur ein Oberbegriff – genau wie Bumpmapping. Wie gut es dann aussieht hängt von der konkreten Realisierung ab. Humus hat Offsetmapping in seiner Demo nachträglich fix eingebaut, es ginge sicherlich auch besser – wenn man einen aufwändigeren Pixelshader schreibt.
Ich würde auch nochmal zur Frage kommen, wie stark man die "Verzerrungen" minimieren könnte. Mir gefällt es (bei dem gezeigten Beispiel) auch nicht so sonderlich.
Außerdem möchte ich noch anmerken, dass Du IMHO mit den ersten beiden Teilsätzen Deines Fazits ("Obwohl es keine geistige Schöpfung einer besonderen Höhe ist, da hierfür praktisch nichts neu entwickelt wurde, ...") wohl einen ziemlich üblen Flamewar vom Zaun brechen wirst. Ich bin bin der Meinung, dass man das auch ohne Änderung des gemeinten Sinnes (die ja in Ordnung geht) auch weniger "flame-mäßig" ausdrücken könnte. Und gerade der erste Teilsatz kommt - finde ich - auch ein wenig naja... von oben herab.
Grüße...
Ich würde auch nochmal zur Frage kommen, wie stark man die "Verzerrungen" minimieren könnte. Mir gefällt es (bei dem gezeigten Beispiel) auch nicht so sonderlich.
Außerdem möchte ich noch anmerken, dass Du IMHO mit den ersten beiden Teilsätzen Deines Fazits ("Obwohl es keine geistige Schöpfung einer besonderen Höhe ist, da hierfür praktisch nichts neu entwickelt wurde, ...") wohl einen ziemlich üblen Flamewar vom Zaun brechen wirst. Ich bin bin der Meinung, dass man das auch ohne Änderung des gemeinten Sinnes (die ja in Ordnung geht) auch weniger "flame-mäßig" ausdrücken könnte. Und gerade der erste Teilsatz kommt - finde ich - auch ein wenig naja... von oben herab.
Grüße...Im Fazit bringe ich es eben noch mal auf den Punkt. Ich glaube nicht, dass ich Flamewars vom Zaun breche, nur weil ich die geringe geistige Fallhöhe anspreche.
Die Verzerrungen zu minimieren wird schwierig. Nach welchem Algorithmus willst du denn die Texturemap auf die Heightmap legen? Eine hochauflösende Texturemap – bzw. der Einsatz einer Detailmap – könnte dafür sorgen, dass man bei den steilen Wällen mehr als Streifen sieht. Man kann weder mit Bump- noch mit Offsetmapping steile Flächen glaubwürdig gestalten. Um eine Mauer darzustellen etc. sollte es jedoch reichen.
Außerdem könnte man noch mit Selfshadowing arbeiten (wofür Humus seine Demo eigentlich geschrieben hatte) – damit besteht ja eine gute Chance, dass die steilen "Schluchten" im Schatten liegen. Bei Humus sieht es so aus:
http://www.dudv.de/files/3dcf/offset_selfshadowing.jpg
In der Ankündigung steht "dediziert" statt wie IMHO richtig "dezidiert"Man kann einen Standpunkt dezidiert vertreten. Das ist aber nicht gemeint, sondern dass R420 für die 3Dc-Komprimierung bestimmte extra Hardware-Einheiten – dediziert für Normalmapkomprimierung (obwohl mans auch für andere Dinge zweckentfremden kann) – mitsichbringt.
Die ganzen im Thread angesprochenen Formulierung werde ich mal zu einer Korrekturliste zusammenstellen. Wenns geht, bitte immer die Artikel-Seite (hier: 1-7) mit angeben.
Nein, die Interpretation der Farbwerte im Alphablender ist völlig unabhängig von den gewählten Textureformate. Für das Textureformat interesiert sich nur die TMU und für die ist DXT2 und 3 bzw DXT4 und 5 gleichwertig.Ja, aaaber. Wie die Farben dann im Alphablender behandelt werden, hängt dann doch von DXT2 oder 3 (bzw. 4 oder 5) ab, oder nicht? Warum wurde denn in DX die Unterscheidung eingeführt?
ALso bumpmapping und co ist ja sicher tausend mal besser als gar nix (offset mapping find ich schon mal recht nice), aber ich bin echter Polygonfan, nichts schlägt echte Geometrie :cool:Mit Bumpmapping kann man in gewissen Bereichen Geoemetrie sparen und dafür mehr Ressourcen für anderes freimachen – also auf einen bestimmten Leistungslevel bezogen den Realismus erhöhen. Pixelgenaue Beleuchtung sollte man sowieso machen, im gleichen Zuge kann man dann noch eine Normalmap einsetzen.
Mit Offsetmapping lässt sich die Illusion ja noch deutlich steigern, während Reliefmapping aufgrund des Rechenaufwandes in Spielen in der nächsten Zeit noch nicht zu erwarten ist.
Demirug
2005-06-16, 17:20:23
Ja, aaaber. Wie die Farben dann im Alphablender behandelt werden, hängt dann doch von DXT2 oder 3 (bzw. 4 oder 5) ab, oder nicht? Warum wurde denn in DX die Unterscheidung eingeführt?
Nein dem Alphablender ist das völlig egal. Geht ja auch gar nicht anders oder was willst du machen wenn jemand gleichzeitigt eine DXT2 und eine DXT3 Texture verwendet.
Der Unterschied ist nur für den Toolchain wichtig.
Nein dem Alphablender ist das völlig egal. Geht ja auch gar nicht anders oder was willst du machen wenn jemand gleichzeitigt eine DXT2 und eine DXT3 Texture verwendet.
Der Unterschied ist nur für den Toolchain wichtig.Das DX9SDK schreibt:
"The difference between DXT2 and DXT3 are that, in the DXT2 format, it is assumed that the color data has been premultiplied by alpha. In the DXT3 format, it is assumed that the color is not premultiplied by alpha. These two formats are needed because, in most cases, by the time a texture is used, just examining the data is not sufficient to determine if the color values have been multiplied by alpha. Because this information is needed at run time, the two four-character code (FOURCC) codes are used to differentiate these cases. However, the data and interpolation method used for these two formats is identical."
Das lese ich so:
Der Unterschied zwischen DXT2 und DXT3 ist der, dass im DXT2-Format vorausgesetzt wird dass die Farben mit dem Alphawert vormultipliziert sind. Im DXT3-Format wird unterstellt, dass die Farben nicht mit Alpha vormultipliziert sind. Diese beiden Formate sind notwendig weil in den meisten Fällen dann, wenn die Textur genutzt wird, eine Untersuchung der Daten nicht ausreicht um zu bestimmen ob die Farbwerte schon mit Alpha multipliziert wurden. Weil diese Information zur Laufzeit benötigt wird, werden diese beiden 4-Zeichen-Kodes (FourCC) genutzt um beide Fälle zu unterscheiden. Allerdings ist die Datenspeicherung und Interpolationsmethode für beide Formate identisch."
Demirug
2005-06-16, 17:43:06
Nochmal. Diese Information wird nur vom Toolchain benötigt.
ALso bumpmapping und co ist ja sicher tausend mal besser als gar nix (offset mapping find ich schon mal recht nice), aber ich bin echter Polygonfan, nichts schlägt echte Geometrie :cool:
:cool: Dann kauf' dir 'ne XBox-360 und zerre den Thread nicht ins OT. ;)
Nochmal. Diese Information wird nur vom Toolchain benötigt.Wenn du so freundlich wärst zu sagen, was das "Toolchain" ist. Im SDK steht, dass die Information zur Laufzeit bekannt sein muss. Das kann ich jetzt nicht mit der Information, diese Info werde nur vom "Toolchain" benötigt, in Einklang bringen.
Demirug
2005-06-16, 18:47:03
Wenn du so freundlich wärst zu sagen, was das "Toolchain" ist. Im SDK steht, dass die Information zur Laufzeit bekannt sein muss. Das kann ich jetzt nicht mit der Information, diese Info werde nur vom "Toolchain" benötigt, in Einklang bringen.
Zum Toolchain gehören zum Beispiel die D3DX Funktionen zur Texturekonvertierung. Diese nutzen den Unterschied zwischen premultiplied und nicht premultiplied um zu bestimmen ob eine Konvertierung erlaubt ist. Man darf eine premultiplied nicht in eine normale Texture konvertieren weil dadurch der Sachverhalt das sie premultiplied ist nicht mehr ersichtlich ist. Die Information ist aber rein organisatorisch. Irgendwie ist das aber alles völlig überholt und entsprechend nutzt heute auch eigentlich keiner mehr die premultiplied Formate.
@Humus-Screenshot mit Selfshadowing
Also das sieht doch jetzt auch mal extrem matschig aus, selbst die Schattengrenzen. Das wirkt nicht mehr gezeichnet, sondern gemalt, richtig wie ein Gemälde, aber extrem entfernt vom Foto. Ich weiß nicht ob ich das wirklich gut finden soll...
Ich mein, wozu ist da noch sowas wie AF gut, wenn ich doch nur Matsch habe?
Ich mein, wozu ist da noch sowas wie AF gut, wenn ich doch nur Matsch habe?AF kann sich keine Details aus den Rippen schneiden. Die Textur wird an dieser Stelle vergrößert.
@Humus-Screenshot mit Selfshadowing
Also das sieht doch jetzt auch mal extrem matschig aus, selbst die Schattengrenzen. Das wirkt nicht mehr gezeichnet, sondern gemalt, richtig wie ein Gemälde, aber extrem entfernt vom Foto. Ich weiß nicht ob ich das wirklich gut finden soll...Das ist ja auch 'ne reine Techdemo. Um Steine realistisch wirken zu lassen ist mehr als die mäßig aufgelöste Basemap und eine Heightmap erforderlich.
Zum Toolchain gehören zum Beispiel die D3DX Funktionen zur Texturekonvertierung. Diese nutzen den Unterschied zwischen premultiplied und nicht premultiplied um zu bestimmen ob eine Konvertierung erlaubt ist. Man darf eine premultiplied nicht in eine normale Texture konvertieren weil dadurch der Sachverhalt das sie premultiplied ist nicht mehr ersichtlich ist. Die Information ist aber rein organisatorisch. Irgendwie ist das aber alles völlig überholt und entsprechend nutzt heute auch eigentlich keiner mehr die premultiplied Formate.Hrm.
"DXT2 entspricht vom Aufbau her genau DXT3, nur dass die Farbwerte als bereit mit dem Alphawert multipliziert gelten. Der gleiche Zusammenhang besteht zwischen DXT4 und DXT5, heutzutage finden DXT2 und 4 keine Anwendung mehr."
Kann man das so formulieren?
Demirug
2005-06-16, 19:48:15
Hrm.
"DXT2 entspricht vom Aufbau her genau DXT3, nur dass die Farbwerte als bereit mit dem Alphawert multipliziert gelten. Der gleiche Zusammenhang besteht zwischen DXT4 und DXT5, heutzutage finden DXT2 und 4 keine Anwendung mehr."
Kann man das so formulieren?
Ja, wobei ich jetzt nicht meine Hand dafür ins Feuer lege das es wirklich niemand mehr benutzt.
In OpenGL gibts diese zwei Formate (DXT2/4) nicht mal, sie wurden wegen mangelndem Interesse einfach weggelassen.
Eine Frage, die nur bedingt mit dem Artiklel zu tun hat:
Virtuell Displacement Mapping, Heightmap.. schön und gut, aber diese Techniken lassen sich doch nur einsetzten, wo keine (pixel-)genaue Kollisionsabfrage benötigt wird, da diese sich an der 2D-Textur orientiert. Außerdem bleibt das Problem bestehen, dass man an den Kanten einer Textur den Trick sofort bemerkt.
Wäre es nicht praktikabler, gleich echtes Displacemenent Mapping zu benutzen bzw. dessen Komprimierung zu fördern? Zwar ist hier ebenfalls keine genaue Kollisionsabfrage möglich, aber wenigstens sehen die Texturkanten zerklüftet aus.
Problem ist vermutlich die Rechengeschwindigkeit, allerdings kenne ich keine ganaue Zahlen was den Leistungsaufwand zwischen echtem und virtuellem Displacement Mapping betrifft.
Endorf
Eine Frage, die nur bedingt mit dem Artiklel zu tun hat:
Virtuell Displacement Mapping, Heightmap.. schön und gut, aber diese Techniken lassen sich doch nur einsetzten, wo keine (pixel-)genaue Kollisionsabfrage benötigt wird, da diese sich an der 2D-Textur orientiert. Außerdem bleibt das Problem bestehen, dass man an den Kanten einer Textur den Trick sofort bemerkt.
Wäre es nicht praktikabler, gleich echtes Displacemenent Mapping zu benutzen bzw. dessen Komprimierung zu fördern? Die Kollisionsabfrage wird in der CPU gemacht, wenn die GPU Displacementmapping macht, nützt das der Enginge dann nichts.
Zwar ist hier ebenfalls keine genaue Kollisionsabfrage möglich, aber wenigstens sehen die Texturkanten zerklüftet aus.
Problem ist vermutlich die Rechengeschwindigkeit, allerdings kenne ich keine ganaue Zahlen was den Leistungsaufwand zwischen echtem und virtuellem Displacement Mapping betrifft.Das hängt davon ab. Auch NV40 ist entgegen Nvidias vollmundigem Marketing nicht zu echtem adaptiven, performanten Displacementmapping in der Lage.
FIXME
2005-06-18, 04:01:06
seite 4: "Man kann man schon an der Normalmap den Effekt sehen, dass..."
endlich wieder mal ein grundlagenartikel \o/
wobei der titel dem artikel nicht wirklich gerecht wird (titel war wohl vor dem artikel da :))
danke jedenfalls
FIXME
2005-06-18, 04:21:15
"Bei DXT3 werden 16 Werte á 4 Bit gespeichert. 0000 steht für "völlig durchsichtig", 1111 für "völlig opaque". 0011 steht für "20 Prozent sichtbar" – man hat also den Bereich von 0 bis 100 Prozent Sichtbarkeit in 16 Schritten aufgelöst zur Verfügung."
wenn die abstufung linear ist, dann sind das 6,25% pro bit (100/16)
bei 0011 sind das dann 18,75% und nicht 20% oder?
Nein, da die Werte von 0 bis 15 gehen, nicht bis 16. 0011 entspricht 3/15 = 20%
seite 4: "Man kann man schon an der Normalmap den Effekt sehen, dass..."Das ist Seite 3. Wird korrigiert werden.
endlich wieder mal ein grundlagenartikel \o/
wobei der titel dem artikel nicht wirklich gerecht wird (titel war wohl vor dem artikel da :))
danke jedenfallsSo ist es. Die erste Häfte kam erst später dazu, der originale Einstieg war der Satz "Mit "3Dc" hat ATI 2004 eine Komprimierung für Normalmaps entwickelt."
Ich glaub ich hab grad beim durchlesen auch noch 'nen Fehler entdeckt:
Da steht unter der Heightmap Zitat:"Weiß steht hier für "niedrig", schwarz für "hoch"."
Das ist glaub ich nicht korrekt, wenn ich mir die Normalmap ansehe sollte es richtig heißen:
schwarz = "niedrig"
weiß = "hoch"
Also : "Weiß steht hier für "hoch", schwarz für "niedrig"."
so wie es halt mit Bumpmaps auch normalerweise ist.
Oder liege ich falsch ?
Gruß, Niall
Niall
2005-06-21, 14:58:42
Ich glaub ich hab grad beim durchlesen auch noch 'nen Fehler entdeckt:
Da steht unter der Heightmap Zitat:"Weiß steht hier für "niedrig", schwarz für "hoch"."
Das ist glaub ich nicht korrekt, wenn ich mir die Normalmap ansehe sollte es richtig heißen:
schwarz = "niedrig"
weiß = "hoch"
Also : "Weiß steht hier für "hoch", schwarz für "niedrig"."
so wie es halt mit Bumpmaps auch normalerweise ist.
Oder liege ich falsch ?
Gruß, Niall
Entschuldigt bitte, irgendwie waren meine Cookies gelöscht und ich war nicht mehr eingeloggt.
Dazu fällt mir dieses (http://www.mathe.tu-freiberg.de/~hebisch/cafe/mce/galerie/wuerfel.html) ein... ;)
Ich glaub ich hab grad beim durchlesen auch noch 'nen Fehler entdeckt:
Da steht unter der Heightmap Zitat:"Weiß steht hier für "niedrig", schwarz für "hoch"."
Das ist glaub ich nicht korrekt, wenn ich mir die Normalmap ansehe sollte es richtig heißen:
schwarz = "niedrig"
weiß = "hoch"
Also : "Weiß steht hier für "hoch", schwarz für "niedrig"."
so wie es halt mit Bumpmaps auch normalerweise ist.
Oder liege ich falsch ?
Gruß, NiallDas hängt davon ab, wie die Normalmap interpretiert wird. In diesem Beispiel sind (sofern ich mich nicht vertan habe) hohe Grünwerte = große Y-Werte, kleine Grünwerte = negative Y-Werte, während Rot genau andersherum interpretiert wird: Viel Rot = negativer X-Wert, wenig Rot = positiver X-Wert. Wie man die Normalmap nutzen will, hängt davon ab, wie man die Heightmap interpretiert, ebenfalls.
Niall
2005-06-23, 11:19:06
Das hängt davon ab, wie die Normalmap interpretiert wird. In diesem Beispiel sind (sofern ich mich nicht vertan habe) hohe Grünwerte = große Y-Werte, kleine Grünwerte = negative Y-Werte, während Rot genau andersherum interpretiert wird: Viel Rot = negativer X-Wert, wenig Rot = positiver X-Wert. Wie man die Normalmap nutzen will, hängt davon ab, wie man die Heightmap interpretiert, ebenfalls.
Klar hängt es davon ab wie die ganze Schose interpretiert wird, ich meinte ja auch nur, daß in der Regel "schwarz oder dunkel" als "tief" und "weiß oder hell" als hoch interpretiert wird. Bei ATI gibbet da noch was anderes (irgendwas mit invertiertem y-Wert oder so).
Grüße, Niall
Klar hängt es davon ab wie die ganze Schose interpretiert wird, ich meinte ja auch nur, daß in der Regel "schwarz oder dunkel" als "tief" und "weiß oder hell" als hoch interpretiert wird.Ich würde es so machen (also Weiß = Erhöhung) aber was die Regel ist, weiß ich nicht.
Asmodeus
2006-01-05, 21:53:26
Sorry für das Ausgraben des alten Threads. ich habe den Artikel jetzt erst gelesen, da ich mich zur Zeit interessehalber etwas mit der Komprimierung von Normalen beschäftige.
Nun bin ich am Grübeln, ob ich einen Denkfehler habe, oder tatsächlich im Artikel einige Dinge falsch erklärt sind. Es geht mir um die Argumentation im Abschnitt "Nachteile einer Zweikanal-Darstellung". Dort wird als Nachteil angegeben, dass mit 3 Vektoren a 8 Bit 16.777.216 Winkelwerte möglich sind und mit 2 Vektoren a 8 Bit nur noch 65.536 Winkelwerte und die Sache deshalb schlechter ist.
Dazu folgendes einfaches Beispiel zur genaueren Erläuterung:
Wir haben die einfache Funktion y = 2*x gegeben. Der Wertebereich für x und y ist mit jeweils 8 Bit aufgelöst und als Format nehmen wir mal die natürlichen Zahlen an. Somit kann x und y jeweils die Werte von 0 bis 255 annehmen. Würde man nun konservativ vorgehen, dann würde man Paare von x und y in einer Textur als Lösung dieser Gleichung abspeichern (so wie es bisher auch bei Normalmaps gemacht wurde mit den 3 Vektoren a 8 Bit). Da die Gleichung für die Lösung aber bekannt ist und in Hardware einfach umsetzbar ist, kann man es sich auch sparen y abzuspeichern. Denn y kann mit Hilfe von x und der Gleichung ja direkt berechnet werden (so wie es bei 3Dc ja auch gemacht wird). Die Aussage (auf mein simples Beispiel bezogen), bei der Speicherung von x und y könnten wir (2 hoch (8 + 8)) = 65.536 Werte abspeichern, bei der Speicherung nur noch von x aber nur noch (2 hoch 8) = 256 Werte und das ist damit schlechter ist meiner Meinung nach jedoch komplett falsch. Denn damit die Gleichung y = 2*x erfüllt ist, gibt es für jeden Wert x genau einen Wert y, der die Gleichung erfüllt. Haben wir also 256 mögliche x Werte, so haben wir auch genau 256 mögliche y Werte. Und alle anderen theoretisch möglichen Werte für y erfüllen nun mal nicht die Gleichung y = 2*x.
Und meiner Meinung nach ist das bei der Zweikanal-Darstellung genauso. Die Z-Komponenten ist in dieser Gleichung die Abhängige von X und Y. Und somit kann sie für jede beliebige Kombination von X und Y innerhalb des Wertebereiches von jeweils -1 bis 1 eben immer nur genau einen Wert annehmen, damit die Gleichung erfüllt ist. Und wenn es für X und Y genau 65.536 Kombinationen gibt, dann gibt es für jede dieser Kombinationen genau einen Wert für Z, der die Gleichung erfüllt. Und bei der Abbildung dieses Wertes auf das Format von Z tritt dann natürlich ein Quantisierungfehler auf (so wie bei meinem simplen Beispiel ab X > 127 für Y ein Quantisierungsfehler auftreten würde). Aber der rührt nicht daher, dass man Z eben berechnet und nicht mehr separat abspeichert.
Angenommen, wir haben eine Normale, die den Punkt (1.0|1.0|1.0) schneidet.
Normalisiert besitzt sie also die Koordinaten X = Y = Z = 0.577350. Speichern wir alle drei Werte in einer 3x8Bit-Normalmap ab so erhalten wir den Wert R = G = B = (0.577350 * 256 = 147 - 128) = 19. Speichern wir diesen Wert ab und rechnen dann zurück und vergleichen die resultierende Normale (nach nochmaliger Normalisierung) bezüglich ihrer Winkelabweichung zur ursprünglichen Normale, so weichen die beiden nach meiner Rechnung um knapp 6 Grad voneinander ab. Speichere ich jetzt nur den Wert 19 für X und Y und berechne eben dann den Wert für Z und normalisiere den Ergebnisvektor wieder, so erhalte ich eine Normale, die nur knapp 0.5 Grad von der ursprünglichen Normale abweicht. Ok, diese Rechnung müsste man natürlich für alle 65.536 Normalen machen, um die Sache abschätzen zu können. Aber ich denke, auch da wird sich zeigen, dass die Zweikanal-Methode auch bezüglich der Winkelabweichung keine schlechteren Ergebnisse liefert als die Methode der Abspeicherung aller drei Komponenten.
Ich hoffe, mit meiner langen Erläuterung ist mein Gedankengang deutlich geworden. Die Frage ist jetzt eben nur, habe ich nen Denkfehler, oder ist die Sache im Artikel wirklich falsch dargestellt im betreffenden Kapitel.
Gruss, Carsten.
Du setzt voraus dass man die Normalen im 3-Kanal-Format normalisiert speichern würde. Nur tut man das in der Regel nicht, weil durch die Quantisierung sowieso keine wirklich normalisierten Vektoren rauskommen.
Außerdem, wie schaffst du es, beim Normalisieren eines Vektors mit X = Y = Z != 0 auf irgendetwas anderes als X = Y = Z = 1/sqrt(3) zu kommen?
Asmodeus
2006-01-06, 09:22:38
Du setzt voraus dass man die Normalen im 3-Kanal-Format normalisiert speichern würde. Nur tut man das in der Regel nicht, weil durch die Quantisierung sowieso keine wirklich normalisierten Vektoren rauskommen.
Außerdem, wie schaffst du es, beim Normalisieren eines Vektors mit X = Y = Z != 0 auf irgendetwas anderes als X = Y = Z = 1/sqrt(3) zu kommen?
Und genau das ist eben meine Frage: Werden in einer 3-Kanal-Normalmap wirklich Normalen, also 3 Koordinaten eines Vektors mit der Länge 1 abgespeichert, wobei dann, wie Du sagst, es natürlich zu Quantisierungsfehlern kommt, was dann wiederum zu Vektoren führt, die eben nicht genau die Länge 1 haben. Oder speichert man in Normalmaps 3 Koordinaten eines Vektors der erstens den geforderten Winkel einhält und dabei bei der Umwandlung in das Zielformat (hier 3 x 8 Bit) den kleinsten Quantisierungsfehler aufweist. Meiner Meinung nach sind es eben wirkliche Normalenvektoren, die abgespeichert werden, mit entsprechendem Quantisierungsfehler. Denn die Suche nach dem Koordinatentripel, das auf einer gegebenen Strecke (beginnend im Ursprung mit dem gewünschten Winkel zur Senkrechten) für alle 3 Koordinaten den kleinsten Quantisierungsfehler ergibt, dürfte nicht so leicht zu berechnen sein. Und ich denke, diesen Aufwand betreibt kein Programm zur Generierung von Normalmaps. Oder liege ich damit doch falsch und diese Optimierung wird wirklich betrieben?
Gruss, Carsten.
WTF is Offset Mapping, langsam gibts schon genug begriffe für ein und dasselbe
Was ist jetzt eigentlich der genaue Unterschied zwischen gewöhnlichem bumpmapping und Normalmapping? Nur dass eine Normalmap in RGB Form die Höheninformation gespeichert hat?
Und ich denke, diesen Aufwand betreibt kein Programm zur Generierung von Normalmaps. Oder liege ich damit doch falsch und diese Optimierung wird wirklich betrieben?
Kommt auf das Tool an das die Normal Maps generiert. Die meisten scheinen dies wohl nicht zu tun, dabei wäre es nicht besonders schwer zu implementieren.
Was ist jetzt eigentlich der genaue Unterschied zwischen gewöhnlichem bumpmapping und Normalmapping? Nur dass eine Normalmap in RGB Form die Höheninformation gespeichert hat?
Normalmapping ist eine Unterform von Bumpmapping, bei der die Oberflächennormalen in einer Textur (egal welchen Formats) gespeichert werden.
BlackBirdSR
2006-09-04, 17:51:40
Etwas OT:
Aber nutzt irgendein Spiel mit Ausnahme von Farcry denn 3dc?
Serious Sam2 soll es angeblich tun. Aber ich finde weder eine Option dazu, noch irgendwelche Hinweise im Internet abseits der Marketinginfos.
deekey777
2006-09-04, 18:09:06
Etwas OT:
Aber nutzt irgendein Spiel mit Ausnahme von Farcry denn 3dc?
Serious Sam2 soll es angeblich tun. Aber ich finde weder eine Option dazu, noch irgendwelche Hinweise im Internet abseits der Marketinginfos.
Wenn du Russisch kannst: http://www.ixbt.com/video2/tech_ss2.shtml
So weit ich es verstanden habe, hat 3Dc nicht ins fertige Spiel geschafft - wie so vieles, was in Techdemos gezeigt wurde.
Normalmapping ist eine Unterform von Bumpmapping, bei der die Oberflächennormalen in einer Textur (egal welchen Formats) gespeichert werden.
Aber was hat es für eine Vorteil gegenüber einer normalen schwarz weiß hightmap? Dass die Qualität unter verschiedenen Blickwinkeln konstatn bleibt?
Aber was hat es für eine Vorteil gegenüber einer normalen schwarz weiß hightmap? Dass die Qualität unter verschiedenen Blickwinkeln konstatn bleibt?
Um die Beleuchtung zu berechnen braucht man die Oberflächennormale, so dass man weiß in welche Richtung das Licht reflektiert wird. Von einer Heightmap müsste man dann erst mehrere Punkte samplen und daraus die Oberflächenneigung bestimmen. Es sind ja die Höhenänderungen die relevant sind, nicht die Höhe selbst. Da ist es einfacher und schneller die Normalen vorzuberechnen und in einer Textur zu speichern.
der link zu der seite von Humus funktioniert nicht mehr.
seine neue page lautet www.humus.name .... der link demnach:
http://www.humus.name/index.php?page=3D&ID=38
ansonsten generell paar nette artikel hier :)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.