Archiv verlassen und diese Seite im Standarddesign anzeigen : Noch besseres Bumpmapping
zeckensack
2004-12-14, 01:06:26
Wirklich erstaunlich :redface:
Thread (http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012842)
Ein Bild (http://www.paralelo.com.br/img/relief_curved_new.jpg) (und ein Vergleichsbild mit "altmodischem" Bumpmapping (http://www.paralelo.com.br/img/relief_curved_old.jpg))
Pikanterweise dürfte dies einer der ersten Effekte sein, die auf Chips vom Schlage eines R420 nicht darstellbar sind. Benötigt wird hierfür ein NV4x. Aber nicht wegen der Instruktionsmenge, und auch nicht wegen branching, sondern aufgrund zu tief verschachtelter dependent reads.
(wobei hierfür eine schrittweise Approximation verantwortlich ist; man könnte dies -- mit weniger Schritten, und dadurch natürlich gröberer Approximation -- vielleicht noch so weit reduzieren, dass es auch auf R300esquen Chips funktioniert)
Das benützt aber texkill, d.h. MSAA wird nicht funktionieren :(
sieht schön aus , braucht scheinbar auch recht power (248instr.). Mal sehen wie weit sie es noch drücken können
Gaestle
2004-12-14, 11:51:39
Sieht gut aus, auch die Sache mit den Steinen, leider ist mein technisches Englisch nicht so prall. Könnte mir jemand erläutern, ob das so 'ne Art Displacement Mapping ist bzw. die Unterschiede zu DM erläutern und dazu noch erzählen, ob die OpenGL-Methode ggü. DM Vor- oder Nachteile hat? Oder klärt mich auf, WARUM die eben gestellten Fragen total dämlich sind?
Wäre nett!
Grüße
Sieht gut aus, auch die Sache mit den Steinen, leider ist mein technisches Englisch nicht so prall. Könnte mir jemand erläutern, ob das so 'ne Art Displacement Mapping ist bzw. die Unterschiede zu DM erläutern und dazu noch erzählen, ob die OpenGL-Methode ggü. DM Vor- oder Nachteile hat?
Relief Mapping ist eine Art 2D-Raytracing. Man schiess eine Strahl in eine Heightmap und guckt wo er auftrifft.
Dieser Ansatz hier erweitert das Reliefmapping wohl auf einen gekrümmten Raum.
DM tesselliert dagegen nur.
Die Rechenlast wird also weiter in die Fragmentshaderunit verschoben.
Ich hatte mir schon vor einiger Zeit einfache Beschleunigerstrukturen überlegt, die es wohl noch um einiges beschleunigen würden. Ob hier sowas gemacht wurde weiss ich nicht. In der alten Version wars zumindest nicht drin.
Probleme treten dabei an (Schnitt-)Kanten auf, weil eben keine wirkliche dreidimensionale Struktur da ist.
Oder klärt mich auf, WARUM die eben gestellten Fragen total dämlich sind?
Fragen können nie dämlich sein ;)
Monger
2004-12-14, 12:16:20
Schlagt mich, aber was ist an dem neuen Verfahren besser als dem alten? Auf den Vergleichsscreenshots kann ich irgendwie keinen relevanten Unterschied feststellen.
Edit: Frage hat sich grad überholt, hab das an den Rändern gesehen...
Trotzdem finde ich es unverschämt viel Performance für eine relativ unspektakuläre Bumpmapping Textur.
Beide Bilder sind übrigends Reliefmapping und kein Bumpmapping.
Vergleichsbilder mit normalem Bumpmapping sehen wesentlich extremer aus.
Über den Performanceverlust kann man natürlich diskutieren, ob ers wirklich wert ist.
Man muss aber dran denken, dass man über die Filterung automatisches LOD hat und es mit richtigen Texturen wesentlich besser aussehen würde wie mit den Testtexturen.
Mr. Lolman
2004-12-19, 18:52:20
... und es mit richtigen Texturen wesentlich besser aussehen würde wie mit den Testtexturen.
Stimmt:
http://www.paralelo.com.br/img/relief_curved_new_rockbump_sphere.jpg
http://www.paralelo.com.br/img/relief_curved_new_rockwall_sphere.jpg
http://www.paralelo.com.br/img/relief_curved_new_brickwall_sphere.jpg
Wieso soll das auf einer Radeon nicht laufen?
"It works with Cg profile ARBFP1 and in D3D with pixel shader 2b."
Nette Bilder
In dem Verzeichnis finden sich aber scheinbar noch mehr. :biggrin:
Erstmal Vergleich
Bumpmapping:
http://www.paralelo.com.br/img/bump_mapping.jpg
Reliefmapping:
http://www.paralelo.com.br/img/relief_mapping.jpg
Relierfmapping mit Schatten:
http://www.paralelo.com.br/img/relief_mapping_texture_shadows.jpg
Und noch 2 Bilder:
http://www.paralelo.com.br/img/rockwall_teapot.jpg
http://www.paralelo.com.br/img/relief_mapping_rendermonkey.jpg
Wieso soll das auf einer Radeon nicht laufen?
"It works with Cg profile ARBFP1 and in D3D with pixel shader 2b."
Es braucht zu viele dependant reads.
zeckensack
2004-12-20, 10:47:07
Beide Bilder sind übrigends Reliefmapping und kein Bumpmapping.
Ja, auch. Bumpmapping, als Oberbegriff, ist alles was Oberflächenkrümmungen auf planen Objekten simuliert. "Emboss" ist primitives Bumpmapping, "EMBM" ist besseres Bumpmapping, Parallax Mapping ist noch besser, etc pp, aber alles ist Bumpmapping.
Sry. Wollte nicht verwirren. Die Begriffe haben schon schwer gelitten, weil so viele Marketing-Fuzzies sie benutzt haben :ugly:
Sieht gut aus, auch die Sache mit den Steinen, leider ist mein technisches Englisch nicht so prall. Könnte mir jemand erläutern, ob das so 'ne Art Displacement Mapping ist bzw. die Unterschiede zu DM erläutern und dazu noch erzählen, ob die OpenGL-Methode ggü. DM Vor- oder Nachteile hat? Oder klärt mich auf, WARUM die eben gestellten Fragen total dämlich sind?
Wäre nett!
GrüßeDisplacement mapping (http://www.pcstats.com/articleview.cfm?articleid=1109&page=5) ist was anderes. DM modifiziert tatsächlich die Geometrie, dh eine Ebene die mit DM bearbeitet wurde, ist danach keine Ebene mehr.
Nicht verwechslen mit sog. "virtual displacement mapping" und ähnlich gelagertem Marketing-Bullshit. "Virtual displacement mapping" ist kein displacement mapping, sondern parallax mapping. Irgendein Vollpfosten war einfach der Meinung, dass der falsche Begriff besser klingt.
Die Geometrie bleibt dabei aber flach, so wie bei allen Bumpmapping-Techniken. Dh es sieht "innerhalb" eines Objekts ganz nett aus, aber die Silhuette bleibt glatt, so wie im von mir verlinkten "altmodischen" Bildchen, oder in dem Rendermonkey-Screenshot den RLZ gepostet hat.
Bei der "neuen" Technik bleibt die Geometrie selbst btw ebenfalls flach. Das neue daran, nämlich die verbeulte Silhouette, wird ebenfalls nur simuliert, also ist auch das kein Displacement mapping.
Das ganze funktioniert, indem in einem Pixel-Shader durchgerechnet wird, ob der "Sehstrahl" auf eine der simulierten Erhebungen trifft, oder zwischen den Erhebungen glatt durchrauscht. Wenn an der Stelle zwar Objektgeometrie ist, aber die Bumpmap sagt, dass das Objekt dort zu flach ist, dann wird der Pixel verworfen.
micki
2004-12-20, 12:07:59
Ja, auch. Bumpmapping, als Oberbegriff, ist alles was Oberflächenkrümmungen auf planen Objekten simuliert. "Emboss" ist primitives Bumpmapping, "EMBM" ist besseres Bumpmapping, Parallax Mapping ist noch besser, etc pp, aber alles ist Bumpmapping.
Sry. Wollte nicht verwirren. Die Begriffe haben schon schwer gelitten, weil so viele Marketing-Fuzzies sie benutzt haben :ugly:
Displacement mapping (http://www.pcstats.com/articleview.cfm?articleid=1109&page=5) ist was anderes. DM modifiziert tatsächlich die Geometrie, dh eine Ebene die mit DM bearbeitet wurde, ist danach keine Ebene mehr.
Nicht verwechslen mit sog. "virtual displacement mapping" und ähnlich gelagertem Marketing-Bullshit. "Virtual displacement mapping" ist kein displacement mapping, sondern parallax mapping. Irgendein Vollpfosten war einfach der Meinung, dass der falsche Begriff besser klingt.
Die Geometrie bleibt dabei aber flach, so wie bei allen Bumpmapping-Techniken. Dh es sieht "innerhalb" eines Objekts ganz nett aus, aber die Silhuette bleibt glatt
glatt??? (http://www.paralelo.com.br/img/relief_curved_new.jpg)
die frage ist, wenn der zwert verändert wird bzw dei Silhouette, ist es dann schon displacementmapping? immerhin verändern raytracer oft auch nicht das mesh wenn sie displacementmapping rendern, sondern 'displacen' anhand der heightmap etwas sobalt sie desssen volume treffen. (sonst wäre kein vorteil in displacementmaps vorhanden gegenüber HRM)
btw. das ist kein flame, bloss finde ich verschwimmen die grenzen der beiden techniken so sehr ineinander, dass man keine wirkliche differenzierung mehr vornehmen kann.
MfG
micki
die frage ist, wenn der zwert verändert wird bzw dei Silhouette, ist es dann schon displacementmapping?
Bei gekrümmten Oberflächen erhält man eine "richtige" Silhouette. Nicht am Rand oder bei Schnittstellen.
immerhin verändern raytracer oft auch nicht das mesh wenn sie displacementmapping rendern, sondern 'displacen' anhand der heightmap etwas sobalt sie desssen volume treffen. (sonst wäre kein vorteil in displacementmaps vorhanden gegenüber HRM)
Das kann man nicht vergleichen.
Bei Raytracing berechnest du ja den Schnittpunkt mit einem mathematischen Objekt. Wenn man nun zu der mathematischen Beschreibung eine Heightmap hinzufügt, verändert man dieses Objekt auch wirklich geometrisch.
Der Unterschied ist halt wo diese erweiterte Geometriebeschreibung Einfluss kriegt. Beim Raytracer direkt im Intersector (damit wirkliche Veränderung der Geometrie) und bei Rasterizer erst im Shader, wenn die Projektion eigentlich schon abgeschlossen ist.
Das unschöne an der Lösung und auch ein Unterschied zum "echten" Displacementmapping ist, dass MSAA nicht funktioniert (wie oben schon erwähnt)
Also solange SSAA nicht Standard wird ist das Verfahren nicht sehr gut einsetzbar...
Corrail
2004-12-20, 13:07:07
Ja, das ist eine echt nette Technologie
Nur hat sie leider extreme Artefakte, wenn man beinache parallel auf die Fläche draufschaut...
Es braucht zu viele dependant reads.
Nun, meine Zitation stammte aus dem OpenGL.org-Thread vom Ersteller dieses Effektes.
Und wenn es unter D3D in das 2.B-Profil kompiliert, können eigentlich nicht zuviele DRs genutzt werden. :confused:
Wo steht das in dem Thread?
It uses the same approach as the previous shader (linear search followed by a binary serach). For the linear search 16 steps are fine (16 texture reads) and for the the binary search about 6 dependent texture reads are enougth. Then two reads for color and normal textures.
(total 24 texure reads with 6 dependent ones)
Das ist zuviel für R3xx/R4xx
Wo steht das in dem Thread?
2. posting des threadstarters nach dem 4. quote
Das laaange posting von fpo am 11.12.2004, 10:56AM. Das achte Posting, wenn ich richtig gezählt habe.
Ich bin mir ziemlich sicher, dass das ein Fehler war. Das muss wohl PS2.0a heißen.
Sonst hätte er das nicht geschrieben:
I use GeForce6800 GT (only one that runs this shader I think... maybe 3dlabs one can also do it).
micki
2004-12-20, 15:34:45
Bei Raytracing berechnest du ja den Schnittpunkt mit einem mathematischen Objekt.
ja, mit dem volume in dem die diplacte fläche ist
Wenn man nun zu der mathematischen Beschreibung eine Heightmap hinzufügt wenn du eine heightmap drauflegst, hast du meißt keine 'mathematische' beschriebung (also keine die durch eine formel lösbar ist), sondern die heightmap selbst.
verändert man dieses Objekt auch wirklich geometrisch.
nein das macht man eben nicht, es würde keinen sinn machen eine displacementmap drauf zu legen, wenn das objekt auch in der geometrie das detail haben könnte. displacementmaps wendet man gerade deshalb an, damit man nicht die geometrie dauerhaft verändern muss (sondern nur im moment der verarbeitung), das sparrt extreeem speicher und es ist einfacher durch den voxelspace der textur zu tracen bis man die displacte höche/position (je nach art der displacementmap) hat als durch eine wirkliche geometrie tracen zu müsse. (der beweis dafür ist, dass es mit offsetmapping und dieser 'neuen' technik jetzt auch welche in den pixelshader einbauen konnten was raytracer schon immer machen)
Der Unterschied ist halt wo diese erweiterte Geometriebeschreibung Einfluss kriegt. Beim Raytracer direkt im Intersector (damit wirkliche Veränderung der Geometrie) und bei Rasterizer erst im Shader, wenn die Projektion eigentlich schon abgeschlossen ist.
tja und das ist der hacken, das passiert nicht wirklich im intersector der die geometrie traced (denn zu der zeit existiert nur das mesh dass erst ein dispalcementmapping erhalten soll), sondern leicht später wenn durch den voxelspace der displacementmap getraced wird, und das funktioniert etwa so wie in dem shader der technik (um welche es in diesem thread geht).
es kann natürlich sein, dass jemand HighResolutionMeshes aus displacementmaps generiert um sie dann zu tracen, aber eigentlich macht man das nicht wenn der tracer das besser kann, sonst würde man viele vorteile von 'maps' verlieren wie z.b. speicherverbrauchssenkung aufgrund von tiling und 8bit/hixel.
MfG
micki
wenn du eine heightmap drauflegst, hast du meißt keine 'mathematische' beschriebung (also keine die durch eine formel lösbar ist), sondern die heightmap selbst.
Auch eine Heightmap kann man (wie jedes Bild) immer als diskrete Funktion ansehen.
nein das macht man eben nicht, es würde keinen sinn machen eine displacementmap drauf zu legen, wenn das objekt auch in der geometrie das detail haben könnte. displacementmaps wendet man gerade deshalb an, damit man nicht die geometrie dauerhaft verändern muss (sondern nur im moment der verarbeitung),
Wer hat denn von dauerhaft geredet?
das sparrt extreeem speicher und es ist einfacher durch den voxelspace der textur zu tracen bis man die displacte höche/position (je nach art der displacementmap) hat als durch eine wirkliche geometrie tracen zu müsse.
Es gibt auch was anderes als triviale Dreiecksintersectoren :|
(der beweis dafür ist, dass es mit offsetmapping und dieser 'neuen' technik jetzt auch welche in den pixelshader einbauen konnten was raytracer schon immer machen)
Dein Beweis bleibt mir irgendwie unverständlich. :|
Diese Shader (offset,relief,...) können beim Raytracing genausogut verwendet werden.
Es hat aber nichts mit Displacementmapping zu tun.
Displacementmapping verändert nunmal die Geometrie.
Ansonsten ists kein Displacementmapping mehr.
tja und das ist der hacken, das passiert nicht wirklich im intersector der die geometrie traced (denn zu der zeit existiert nur das mesh dass erst ein dispalcementmapping erhalten soll), sondern leicht später wenn durch den voxelspace der displacementmap getraced wird, und das funktioniert etwa so wie in dem shader der technik (um welche es in diesem thread geht).
Da ist Hacken, dass du das falsch siehst.
Warum sollte ein Intersector nicht durch "Texturzugriff" die Displacementmap in die Schnittberechnung mit eingehen lassen?
Die Geometrie wird verändert, aber die zusätzlichen Infos können auch sonst wieder Verwendung finden.
Genauso wie man einen Intersector beschleunigen kann, wenn er Zugriff auf den Alphatextur hat. etc.
Hmm bei einem Raytracer wird aber soweit ich weiß die Geometrie wirklich nicht direkt verändert, sondern die Intersection anders gerechnet.
Wäre auch viel zu Speicheraufwändig sonst...
etwas OT, aber das neue Bumpmapping mit Displacement Mapping Effekten erinnert mich doch ein bisschen an das "gute alte" Relief Texture Mapping :
http://www.inf.ufrgs.br/~oliveira/RTM.html
Zumindest was das Resultat betrifft. Schade, das das RTM eigentlich nie benutzt wurde.
Das ist halt nicht so einfach anzuwenden, gerade bei Collision Detection, etc.
Spasstiger
2004-12-24, 15:11:05
Kann man den Shader irgendwo runterladen? Würd mir das gerne mal direkt im FX Composer anschauen.
http://evolution.times.lv/Relief2.rar
RenderMonkeyFile
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.