Tessellation und die Texturverzerrung

[Spasstiger]

Bei Tessellation + Displacement Mapping fällt mir ein großer Schönheitsfehler gegenüber normaler Geometrie auf. Die auf die tessellierten Oberflächen gemappten Texturen werden verzerrt und wirken stellenweise recht inhomogen in der Schärfe und sichtbar in die Länge gezogen. Schön ist das nicht:

http://www.abload.de/img/heaven_tess_tex_distorwycs.jpg

http://www.abload.de/thumb/heaven_tess_offpy48.jpg (http://www.abload.de/image.php?img=heaven_tess_offpy48.jpg)http://www.abload.de/thumb/heaven_tess_onsy24.jpg (http://www.abload.de/image.php?img=heaven_tess_onsy24.jpg)

Kann man theoretisch auch zusätzliche Texturen auf die zusätzliche Geometrie mappen oder ist die Texturverzerrung unvermeidbar? Für die Artists ist es ja sicherlich nicht einfach, mit Tessellation einen guten Kompromiss aus Geometriedetail und Texturhomogenität zu finden. Mit Parallax Mapping gab es das Problem ja auch schon, aber mit Tessellation und Displacement Mapping scheint es noch viel offensichtlicher zu werden.

P.S.: Die Screenshots stammen von meiner Radeon HD 4850. Hab Unigine Heaven 2.0 RC1 mit dem OpenGL-Renderpfad verwendet, dort wird die Tessellationseinheit der Prä-DX11-Radeon-HDs genutzt.

[DrFreaK666]

Danke für den Thread.
Mir ist das auch schon unangenehm aufgefallen.

[Sven77]

Texturen werden immer noch per UVs gemapped. Um UVs zu erstellen brauch man bestehende Geometrie. Da Tesselation adaptiv arbeitet kann das nicht funktionieren, höchstenfalls mit prozeduralen Texturen die auf UVWs basieren. Wäre mir aber neu, das es sowas schon in Games gibt. Das oben ist ein Beispiel für schlechten Content, hier muss reale Geometrie hier weshalb man noch viel mehr Polys in Games brauch (ohne Tesselation)..

[san.salvador]

Selbst wenns technisch möglich wäre, wäre es sicher kein Spaß für den Künstler, entsprechende Texturen zu Pinseln.

[Gast]

http://www.abload.de/image.php?img=heaven_tess_onsy24.jpg
Da ist ein Loch im Boden :lol:

[frix]

durchaus ein unschönes problem wo man auch ständig bei erstellung von vorgerenderter 3d animationen drauf stößt.
Im endeffekt kann displacement meißt nur subtil einsetzen.

[Gast]

Tessellation ist – genau wie Displacement- oder auch Parallax-Occlusion-Mapping – eine Ergänzung zu vorhandener Geometrie, kein Ersatz. Solange das im Rahmen von Techdemos, welche natürlich den Einsatz der verwendeten Technik deutlich hervorheben sollen, so sinnfrei genutzt wird, ist klar, dass da optische Merkwürdigkeiten entstehen. Ein anderes Beispiel in Unigine ist die "Schräge", die mit Tessellation zur Treppe wird: Kein Gamedesigner würde sowas machen.

In Spielen ist es dann so, wie in Dirt 2 oder AVP: Dezent eingesetzt fragt sich der Durchschnittskunde: "Ja wo isse denn, die Tessellation". :)


-Carsten

[deekey777]

Hatte nicht die Ur-Radeon eine Technik, um gerade diese Verzerrungen zu vermeiden?
Edit: War doch etwas anderes: http://www.tomshardware.co.uk/ati,review-207-5.html

[Gast]

Ein anderes Beispiel in Unigine ist die "Schräge", die mit Tessellation zur Treppe wird: Kein Gamedesigner würde sowas machen.



Und ich dachte, die Grundgeometrie eines Games würde sich in Zukunft auf genau ein Vertex reduzieren, so wie Tesselation von manchen hier als der heilige Gral angepriesen wurde.;)

[Stechpalme]

Ich sehe Tesslation als heiligen Gral, aber nur in Bestimmten Situationen. Rundungen, Oberflächenstrukturen wie Boden und Wände sind optimales Einsatzfeld dafür. Warum, wie in Metro 2033 einige Objekte wie eine Schreibmaschine per Tesslation eigentlich schon abgewertet werden (sieht irgendwie dämlich aus) verstehe ich nicht.
Das sich die Texturen ein wenig verziehen oder dann schwammig aussehen ist schade, dürfte aber mit einer höheren Grundgeometrie abgemildert werden können.

[Spasstiger]

Wenn man Tessellation für ein performantes und stufenloses Geometrie-LOD einsetzt, könnte die Texturverzerrung durchaus zum Problem werden. Man könnte die Texturen natürlich so vorverzerren, dass sie auf dem High-Poly-Mesh gut aussehen. Funktioniert aber wohl auch nur brauchbar, wenn die Texturen sehr hoch aufgelöst sind, um im Verzerrungsbereich noch Details zu haben.

Über kurz oder lang muss man wohl auf prozedurale Ansätze zurückgreifen wie es z.B. AMD in der Terrain-Rendering-Demo des Tessellation-SDK präsentiert. Dort kommt ab einer gewissen Geländehöhe, die sich mit dem Displacement-Level anpassen lasst, Schnee dazu.

[Stechpalme]

Hochauflösende Texturen sind ja derzeit eher auf dem Rückgang, grade in Bezug auf die Crossover Plattformen bei Spielen ist das eine traurige Geschichte.

[Gast]

Hochauflösende Texturen sind ja derzeit eher auf dem Rückgang, grade in Bezug auf die Crossover Plattformen bei Spielen ist das eine traurige Geschichte.

Wobei man den Konsolen nicht die alleinige Schuld geben kann. Auch die mäßige Speicherausstattung bei Grafikkarten trägt dazu bei.

Nur mal zur Erinnerung, mit der 8800GTX hatte man bereits 768 MiB, heute gibt es als Standard im Highend gerade mal 1GiB, also eine mikrige Steigerung von 33%. Mit der 480GTX gibt es zwar eine Steigerung auf das doppelte, aber das ist für den großen Abstand auch viel zu wenig.

Im Highend sollte eigentlich zumindest 2-3GiB Standard sein.

[fibric]

tessellation hat auch einen anderen nachteil. nämlich den, dass die kollisionsgeometrie nicht mit verändert wird.

tessellation und texturen sind ein traum paar wenn die texturen mittels "procedural textures" erzeugt werden. also texturen auf basis von algorithmen. in etwa vergleichbar zu vector grafiken (svg). hier bei kann auch (wenn der algorithmus angepasst wurde) das nervice mip map level bei landscapes entfernt werden. leider sind procedural textures aber sehr rechenaufwendig und soweit ich weiß werden solche texturen bis jetzt nur in der demo scene eingesetzt...

tessellation + procedural textures = killer feature für opencl :)

[FeuerHoden]

tessellation hat auch einen anderen nachteil. nämlich den, dass die kollisionsgeometrie nicht mit verändert wird.

tessellation und texturen sind ein traum paar wenn die texturen mittels "procedural textures" erzeugt werden. also texturen auf basis von algorithmen. in etwa vergleichbar zu vector grafiken (svg). hier bei kann auch (wenn der algorithmus angepasst wurde) das nervice mip map level bei landscapes entfernt werden. leider sind procedural textures aber sehr rechenaufwendig und soweit ich weiß werden solche texturen bis jetzt nur in der demo scene eingesetzt...

tessellation + procedural textures = killer feature für opencl :)

Wie wäre es mit einer normalen verzerrten Textur und einem prozeduralen Layer der nur wenige Informationen enthält um die Verzerrung soweit zu ergänzen dass diese wieder normal aussieht?

[Niall]

Wie wäre es mit einer normalen verzerrten Textur und einem prozeduralen Layer der nur wenige Informationen enthält um die Verzerrung soweit zu ergänzen dass diese wieder normal aussieht?

Dies ginge aber nur wenn deine prozedurale Map so aussieht wie die Texture die auf die Front gemapped ist. Ansonsten sieht man immer noch einen Unterschied - Wenn auch nich diese »gezogene« Verzerrung.

[Neomi]

tessellation hat auch einen anderen nachteil. nämlich den, dass die kollisionsgeometrie nicht mit verändert wird.

Kollisionsgeometrie und dargestellte Geometrie sind sowieso nicht identisch. Wäre ja noch blöder, wenn man an jedem reinen Grafikdetail hängenbleibt und mit anderen Grafikdetails sich auch das Gameplay ändert. Die Entkopplung ist schon ohne Displacement Mapping sinnvoll, wobei man bei Bedarf auch in der Physiksimulation mit Displacement arbeiten kann.

tessellation und texturen sind ein traum paar wenn die texturen mittels "procedural textures" erzeugt werden. also texturen auf basis von algorithmen. in etwa vergleichbar zu vector grafiken (svg). hier bei kann auch (wenn der algorithmus angepasst wurde) das nervice mip map level bei landscapes entfernt werden. leider sind procedural textures aber sehr rechenaufwendig und soweit ich weiß werden solche texturen bis jetzt nur in der demo scene eingesetzt...

Die meisten dieser "prozeduralen" Texturen werden beim Start erzeugt statt geladen, sind danach aber genauso gerasterte Texturen mit begrenzter Auflösung und haben bei Verzerrungen die gleichen Probleme. Abgesehen davon lassen sich nicht beliebige Sachen prozedural darstellen.

[Niall]

Kollisionsgeometrie und dargestellte Geometrie sind sowieso nicht identisch. Wäre ja noch blöder, wenn man an jedem reinen Grafikdetail hängenbleibt und mit anderen Grafikdetails sich auch das Gameplay ändert. Die Entkopplung ist schon ohne Displacement Mapping sinnvoll, wobei man bei Bedarf auch in der Physiksimulation mit Displacement arbeiten kann.


Vorallem wäre das tesselierte Mesh als Kollisionsmesh ziemlich unperformant.:freak:
Da macht es schon Sinn das Basismesh (wenn überhaupt) zu nehmen.

[fibric]

wenn man aber den tesselation effect auf den boden legt auf dem man lang läuft und dann clipping entsteht... sieht da aber sehr mies aus und degradiert eine technoligy zum reinen eye catcher...
das selbe problem wie mit den wasser shadern... und wenn die physik immer mehr zum spielelement wird und wasser nicht mehr der oberfläche folgt, weil die kollisionsgeometrie nicht mit verändert wird... dann hab wir ganz unglaubwürdige spielewelten zurück...

[Nighthawk13]

Das Bild sieht so aus, als ob die Textur-Koordinaten der tesselierten Eckpunkte unabhängig von der Höhe der Displacementmap sind
=> Eckpunkte die sich nur durch die Höhe unterscheiden erhalten die gleiche Texturkoordinate
=> Dreicke die senkrecht zum Basisdreick stehen erhalten eine unendlich langestreckte Textur in eine Richtung.

Korrekterweise müsste sich die Textur auch um die Erhebung "abwickeln". Das kann man für den "worst Case" (kleinkariertes Schachbrett als Displacementmap) kaum im Shader lösen, oder?

[Niall]

Korrekterweise müsste sich die Textur auch um die Erhebung "abwickeln". Das kann man für den "worst Case" (kleinkariertes Schachbrett als Displacementmap) kaum im Shader lösen, oder?

Korrekt, ich denke man könnte jedoch einen Algorithmus einbauen,
der bei »Tesselation: an« die Diffuse- /Specular- / Sonstwasmap anhand der Displacementmap »gegenverzerrt«. (Nicht die UVWs)

Zumindest in meinen Gedankengängen könnte so etwas funktionieren, oder?

[Gast]

Korrekterweise müsste sich die Textur auch um die Erhebung "abwickeln". Das kann man für den "worst Case" (kleinkariertes Schachbrett als Displacementmap) kaum im Shader lösen, oder?

Ein kleinkariertes Schachbrett ließe sich recht einfach prozedural berechnen ;)

[Niall]

Ein kleinkariertes Schachbrett ließe sich recht einfach prozedural berechnen ;)

Hehehe und dann? ;)

[InsaneDruid]

Ich würde das Startbeispiel als ein eher schlechtes ansehen. Mit einiger Wahrscheinlichkeit hätte das auch mit "statischen" Polygonen solche Texturverzerrungen, einfach weil der Einfachheit halber da so oder so einfach drauf projiziert würde. Solche glitches sieht man in jedem Game zuhauf, auch ohne Tesselation. Da daf man halt die Geometrie nicht so scharf rausstechen lassen, egal ob mit oder oder Tesselation.

Der Drache in Heaven ist IMHO auch ein mieses Bsp, grade weil sich da ohne und mit Tesselation die Geometrie so extrem unterscheidet. Das hat dann eben auch die Hitboxenproblematik. Ich denke und hoffe Tesselation wird eher als Feintuningmaßnahme eingesetzt, dann sollten sich die negativen Effekte in sehr engen Grenzen halten. Eben Struktur verfeinern, nicht fast ausschließlich darüber generieren.

[Spasstiger]

In der Terrain-Demo aus dem DX9-Tessellation-SDK von ATI wird das Problem recht hübsch prozedural angegangen:

http://www.abload.de/thumb/tess_displace_14ucn.jpg (http://www.abload.de/image.php?img=tess_displace_14ucn.jpg) http://www.abload.de/thumb/tess_displace_2cucz.jpg (http://www.abload.de/image.php?img=tess_displace_2cucz.jpg) http://www.abload.de/thumb/tess_displace_3g56i.jpg (http://www.abload.de/image.php?img=tess_displace_3g56i.jpg) http://www.abload.de/thumb/tess_displace_4761q.jpg (http://www.abload.de/image.php?img=tess_displace_4761q.jpg)

Mit wachsender Geländesteilheit wird auch zunehmend schroffer Fels sichtbar. Aber in einem echten Spieleszenario mit sehr vielfältigen Oberflächen und Objekten werden die prozeduralen Möglichkeiten schnell erschöpft sein.

[Niall]

In der Terrain-Demo aus dem DX9-Tessellation-SDK von ATI wird das Problem recht hübsch prozedural angegangen:

[/URL]http://www.abload.de/thumb/tess_displace_14ucn.jpg (http://www.abload.de/image.php?img=tess_displace_14ucn.jpg) http://www.abload.de/thumb/tess_displace_2cucz.jpg (http://www.abload.de/image.php?img=tess_displace_2cucz.jpg) http://www.abload.de/thumb/tess_displace_3g56i.jpg (http://www.abload.de/image.php?img=tess_displace_3g56i.jpg) [URL]http://www.abload.de/thumb/tess_displace_4761q.jpg (http://www.abload.de/image.php?img=tess_displace_4761q.jpg)

Mit wachsender Geländesteilheit wird auch zunehmend schroffer Fels sichtbar. Aber in einem echten Spieleszenario mit sehr vielfältigen Oberflächen und Objekten werden die prozeduralen Möglichkeiten schnell erschöpft sein.

Ja, so geht’s sicher.
Alerdings nur wenn du für die dritte Dimension in die displaced wird auch Texturkoordinaten in petto hast oder prozedurale Maps die direkt per Object oder World Space gemapped werden. (Wobei ich keiiiine Ahnung habe wie dynamisch und ob das mit den Mapping Koordinaten im Realtime-3D geht.) :D

[Nighthawk13]

Korrekt, ich denke man könnte jedoch einen Algorithmus einbauen,
der bei »Tesselation: an« die Diffuse- /Specular- / Sonstwasmap anhand der Displacementmap »gegenverzerrt«. (Nicht die UVWs)

Zumindest in meinen Gedankengängen könnte so etwas funktionieren, oder?
Für den gezeigten Fall hilft es auch nicht: wenn entlang einer Linie im Dreieck genau die gleiche Texturkoordinate verwendet wird, kann in der Map stehen was will, beim sampeln kommt immer der gleiche Wert raus.

Man muss schon dafür sorgen, dass entlang aller Dreieckskanten die Distanz der Texturkoordinaten grob zur Distanz der Positionen passt.

Als "Hack" würde ich im Shader zumindest die Höhe miteinberechnen, im einfachsten Fall so:
tex.xy += displacementHeight * empiricDelta.xy

Da gibts dann auch wieder "böse Winkel". Vielleicht noch skaliert zum UV-Zentrum des Basisdreiecks.
tex.xy += displacementHeight * (baseTriCenter.xy-tex.xy) * empiricDelta.xy

Kann man bestimmt noch beliebig weiter treiben. Perfekt kann man das nur von Hand/in einem Vorarbeitungssschritt lösen imo.

[Neomi]

Einfach mal per simpler Formel die Texturkoordinaten anzupassen, kann vielleicht in wenigen Ausnahmefällen funktionieren, in der Regel aber bestimmt nicht. Die Verschiebung durch die Höhe z.B. wirkt nicht gut, wenn die Höhe konstant ist, dann entsteht sowieso keine zusätzliche Verzerrung und eine Verschiebung ist unerwünscht. Da müßte die Höhenänderung herangezogen werden. Aber auch das ist ein Problem, wenn z.B. bei hochfrequenten Änderungen die Verschiebung von benachbarten Punkten so groß wird, daß die Textur nicht entzerrt wird, sondern weit über das Ziel hinausschießt und sogar stellenweise rückläufige Texturkoordinaten erzeugt. Jede Art der Verschiebung durch lokale Daten alleine ist zum Scheitern verurteilt.

Eine Möglichkeit wäre, per Vorberechnung unter Berücksichtigung der gesamten Geometrie zu entzerren und die entgültigen Koordinaten in eine zusätzliche Textur zu packen. Dann wird mit den planar projezierten Koordinaten im Pixelshader erst aus dieser Zwischentextur die Koordinate für den Lookup in den eigentlichen Texturen geholt. Im Pixelshader deshalb, weil ein Lookup im Domainshader dank dynamischer Tesselierung zu wabernden Texturen führen würde.

[Nighthawk13]

Einfach mal per simpler Formel die Texturkoordinaten anzupassen, kann vielleicht in wenigen Ausnahmefällen funktionieren, in der Regel aber bestimmt nicht.
Ack, wie gesagt nur ein Hack.
Das man den Speziallfall "singuläre Texturkoordinaten" entschärfen kann glaube ich trotzdem noch, mit Artefakten an anderer Stelle.


Eine Möglichkeit wäre, per Vorberechnung unter Berücksichtigung der gesamten Geometrie zu entzerren und die entgültigen Koordinaten in eine zusätzliche Textur zu packen. Dann wird mit den planar projezierten Koordinaten im Pixelshader erst aus dieser Zwischentextur die Koordinate für den Lookup in den eigentlichen Texturen geholt. Im Pixelshader deshalb, weil ein Lookup im Domainshader dank dynamischer Tesselierung zu wabernden Texturen führen würde.
Genau, etwas in der Art ist sicher die richtige Lösung. Hätte die Offsets zur planaren Texturkoordinate gespeichert, aber egal;)
Jedenfalls sehe ich keine Weg, das Mappingproblem "on the fly" lösen.

[Gast]

Mit wachsender Geländesteilheit wird auch zunehmend schroffer Fels sichtbar. Aber in einem echten Spieleszenario mit sehr vielfältigen Oberflächen und Objekten werden die prozeduralen Möglichkeiten schnell erschöpft sein.

In einem echten Szenario wird man wohl kaum das Gelände mit Tessellation erzeugen können, schließlich wird man höchstwahrscheinlich Kollisionsabfragen mit dem Gelände brauchen, und das wird ja nur schwer möglich sein, wenn die Geometrie erst auf der Grafikkarte erzeugt wird.

[starfish]

Auch auf die Gefahr hin als Idiot darzustehen, aber in Maya funktioniert sowas wunderbar.

Wenn ich auf mein Polymesh meine UVs plaziere und mit Texturen belege und DANN einen Smooth drüber lege und somit die Polys aufblase, passen die UVs und Texturen nachher meistens sogar besser, als vorher.

Ich frag nochmal meinen Texture Artist, aber ich bin mir fast 99% sicher, dass der Algorythmus in Maya das so hinbekommt.

[Niall]

Auch auf die Gefahr hin als Idiot darzustehen, aber in Maya funktioniert sowas wunderbar.

Wenn ich auf mein Polymesh meine UVs plaziere und mit Texturen belege und DANN einen Smooth drüber lege und somit die Polys aufblase, passen die UVs und Texturen nachher meistens sogar besser, als vorher.

Ich frag nochmal meinen Texture Artist, aber ich bin mir fast 99% sicher, dass der Algorythmus in Maya das so hinbekommt.

Der Smooth verzerrt die Texturkoordinaten bzw. das Mesh auch nicht
so wie das Displacement. Und da die Texturen beim Realtime 3D i.d.R. für die LowPoly Modelle erstellt wurden verzerren sie auch stärker beim smooth als wenn du verschiedensten Maps in deinem Shader kombinierst, die, nur als Beispiel, aus tileablen Texturen bestehen.

[fibric]

gibt es denn keine möglichkeit die kollisionsdaten "aufzubewahren" und durch opencl für die physik verarbeitbar zu machen?

[Neomi]

Was hast du nur ständig mit deiner Kollision? Die darf nicht von der Darstellung abhängig sein, sondern muß separat berechnet werden können. Wenn eine Heightmap für die Physik relevant ist (was in der Regel nicht der Fall sein wird), dann kann sie innerhalb der Physiksimulation selbst berücksichtigt werden.

Ein konkretes Beispiel, warum die Physikbindung an die zur darstellung dynamisch generierte Geometrie eine dämliche Idee ist:
Stell dir ein Rennspiel vor, bei dem du über Feldwege, Kopfsteinpflaster oder anderen unebenen Boden fährst. Displacement auf dynamischer Tesselation aufsetzend sorgt dafür, daß die Geometrie dort schön detailliert und damit uneben ist, wo man es sieht, also unter deinem Auto. Was in der Entfernung zu sehen ist, ist nicht annähernd so fein aufgelöst, weil es nicht nötig ist. Was hinter dir außerhalb des Sichtfeldes passiert, bleibt bei der groben und glatten Basisgeometrie. Auf gleichmäßigem Boden fährt es sich leichter, deshalb können die Fahrzeuge vor dir ihren Vorsprung locker ausbauen und die hinter dir ihren Rückstand abbauen. Es sei denn natürlich, du regelst trotz flüssiger Darstellung all die netten Grafiksettings auf das Minimum herunter, um genauso schnell fahren zu können. Anders wären auch nicht die guten Rundenzeiten in den Ranglisten schaffbar.

In den meisten Spielen unterscheidet sich die Geometrie zur Physikberechnung sowieso schon von der für die Darstellung, auch bei statischer Levelgeometrie und auch ohne dynamische Tesselation und Displacement. Ganz einfach deshalb, weil es für das Gameplay sinnvoll ist.

[Niall]

Stell dir ein Rennspiel vor, bei dem du über Feldwege, Kopfsteinpflaster oder anderen unebenen Boden fährst. Displacement auf dynamischer Tesselation aufsetzend sorgt dafür, daß die Geometrie dort schön detailliert und damit uneben ist, wo man es sieht, also unter deinem Auto. Was in der Entfernung zu sehen ist, ist nicht annähernd so fein aufgelöst, weil es nicht nötig ist. Was hinter dir außerhalb des Sichtfeldes passiert, bleibt bei der groben und glatten Basisgeometrie. Auf gleichmäßigem Boden fährt es sich leichter, deshalb können die Fahrzeuge vor dir ihren Vorsprung locker ausbauen und die hinter dir ihren Rückstand abbauen. Es sei denn natürlich, du regelst trotz flüssiger Darstellung all die netten Grafiksettings auf das Minimum herunter, um genauso schnell fahren zu können. Anders wären auch nicht die guten Rundenzeiten in den Ranglisten schaffbar.


Interessantes Szenario, welches ich noch gar nicht in meine Überlegungen eingebaut hatte. Trotzdem sollte allein die Performance doch auch schwer einbrechen wenn ich das HiRes Mesh für die Kollisionsabfrage nutzen will, was diese Überlegung schon im Keim erstickt. Wie du angesprochen hast werden seibst bei nicht tesselierten und/oder displaceten Objekten der Performance wegen i.d.R. Primitives benutzt oder sollten benutzt werden. (Sofern es die Dynamikberechnungen nicht komplett verfälschen würde und/oder die normalen Objekte an sich schon recht schlank sind.)

[InsaneDruid]

Wobei ich das Rennspiel Szenario für eher ungeeignet halte. Im Human vs Human sollte eh jeder Client seine eigene Physik haben, und die Gegner übermitteln nur grob ihre aktuelle Position, Heading, Speed. Und Humans vs AI hat die AI eh fast immer ihre eigene (einfachere) Physik.

[Niall]

Wobei ich das Rennspiel Szenario für eher ungeeignet halte. Im Human vs Human sollte eh jeder Client seine eigene Physik haben, und die Gegner übermitteln nur grob ihre aktuelle Position, Heading, Speed. Und Humans vs AI hat die AI eh fast immer ihre eigene (einfachere) Physik.

Wird die »unterschiedliche« Physik dann untereinander abgeglichen?

[InsaneDruid]

Weiß jetzt nicht genau wie du das meinst.. aber die AI muss ja nur so eingestellt sein, das sie mit ihrer Physik ähnlich fix ist wie der Player...

[fibric]

ich denke da spontan an doom3 wo pixel genau ermittelt wurde wo der spieler getroffen wurde. dass kollisions geometrie daten denen der darstellungs geometrie entsprechen kann vom gameplay her sinn machen. die perfomance leidet sehr (doom3 max 4 spieler) und deshalb wurde ja in prey und anschliessend in quake4 diese pixelggenau kollision wieder entfernt.

zum beispiel mit racing game. man sieht die strasse unter dem auto sowie unter den reifen nicht. trotzdem erwartet der spieler dass sich auto so verhält als würde es über kopfsteinpflaster fahren... hier endet meine gedankengang... die mittagspause ruft ^^

[Gast]

Wobei ich das Rennspiel Szenario für eher ungeeignet halte.

Die Rennspielphysik hat wenig mit der realen Geometrie zu tun.

Es gibt einfach ein Physikmodell für ebene Straße, ein anderes für unebenen Untergrund, einen für Schnee usw.

Wie dem Spieler diese unterschiedlichen Straßenverhältnisse optisch vermittelt werden ist der Physiksimulation ja egal.

[Fragman]

der content ist nicht aufs tessalieren angepasst. das kann man ganz leicht machen, texturen am highres mesh painten und die dann verwenden fuer die tessalierte version. so wird man das auch mal machen wenn tessalation standardmaessig genutzt wird denk ich mal. heute als techdemos wie es in dem benchmark drin ist wird es sich nicht lohnen fuer die paar user die texturen zu ueberarbeiten. allerdings gibt es techniken diese verzerrungen zu vermeiden.

[Partner]

Tut's auch:
http://www.abload.de/img/endless4h8x.png"Wunderschönes" Beispiel um zu verdeutlichen das Geometrie-Tesselation für den Großteil an Szeneinhalten unbrauchbar ist.

Geometriedetails sind in absehbarer Zukunft mit großem Abstand das unbedeutenste Attribut für die visuelle Qualität in Spielen. Und das wird sich auch nicht ändern bis eine Alternative zur Rasterisierung standardisiert wird (sprich 10+ Jahre). Weitaus wichtiger sind Beleuchtungsprobleme und da ist Geometrie-Tesselation sogar extremst kontraproduktiv.

[Coda]

"Wunderschönes" Beispiel um zu verdeutlichen das Geometrie-Tesselation für den Großteil an Szeneinhalten unbrauchbar ist.
Begründung? Dir ist schon klar, dass das ein Techdemo mit Coder-Art ist?

Und Geometrie-Tesselation ist nicht "unbrauchbar für einen Großteil der Szenen". Es wird wenn die Hardwarebasis da ist sogar für alles der Standard sein, weil man so völlig umsonst aus der Heightmap der Artists LOD bekommt, die sie für die Normalmaps eh anfertigen müssen. Spart Rechenleistung (besseres LOD) und Speicher (nur ein Modell + Heightmap als Textur). Win-Win.

Weitaus wichtiger sind Beleuchtungsprobleme und da ist Geometrie-Tesselation sogar extremst kontraproduktiv.
Mit deferred Lighting ist es bums egal wieviel Geometrie man hat. Die Lichtberechnung ist nur abhängig von der Menge der beleuchteten Pixel und der Anzahl der Lichter.

Sorry Ail, aber das kann ich nicht unkommentiert lassen. Split es doch bitte raus ;)

[Partner]

Begründung? Dir ist schon klar, dass das ein Techdemo mit Coder-Art ist?

Und Geometrie-Tesselation ist nicht "unbrauchbar für einen Großteil der Szenen". Es wird wenn die Hardwarebasis da ist sogar für alles der Standard sein, weil man so völlig umsonst aus der Heightmap der Artists LOD bekommt, die sie für die Normalmaps eh anfertigen müssen. Spart Rechenleistung (besseres LOD) und Speicher (nur ein Modell + Heightmap als Textur). Win-Win.Zum Beispiel hat man bereits bei displacement mapping erkannt dass zusätzliche Texturkoordinaten unablässig sind. Darüber moniert man halt nicht bei irgend welchen schnöden Demos sondern bei qualitativ hochwertigen Spielen.
Der zentrale Punkt ist das diese Geometriedetails im Vergleich zu anderen Attributen keinen wesentlichen Einfluss auf die Wahrnehmung der Grafikqualität haben (virtuelle Bodenkriecherei mal ausgeschlossen).

Mit deferred Lighting ist es bums egal wieviel Geometrie man hat. Die Lichtberechnung ist nur abhängig von der Menge der beleuchteten Pixel und der Anzahl der Lichter.So? Dann zeig mir z.B. mal einen Algorithmus der weiche Schatten ohne nennenswerte Artefakte auf die hochfrequenten (texel-generierten) Geometriedetails zuverlässig und vor allem effizient zeichnen kann. Da hilft verzögerte Beleuchtung gar nichts.

[Coda]

Zum Beispiel hat man bereits bei displacement mapping erkannt dass zusätzliche Texturkoordinaten unablässig sind. Darüber moniert man halt nicht bei irgend welchen schnöden Demos sondern bei qualitativ hochwertigen Spielen.
Wieso zusätzliche Texturkoordinaten? Das normale Mapping das man für die Normalmap verwendet tut's doch?

Der zentrale Punkt ist das diese Geometriedetails im Vergleich zu anderen Attributen keinen wesentlichen Einfluss auf die Wahrnehmung der Grafikqualität haben (virtuelle Bodenkriecherei mal ausgeschlossen).
Man bekommt sie doch praktisch umsonst. Und das LOD will man sowieso haben.

So? Dann zeig mir z.B. mal einen Algorithmus der weiche Schatten ohne nennenswerte Artefakte auf die hochfrequenten (texel-generierten) Geometriedetails zuverlässig und vor allem effizient zeichnen kann. Da hilft verzögerte Beleuchtung gar nichts.
Wer redet denn von hochfrequent? Man tesseliert natürlich so, dass man nicht 30 Dreiecke pro Pixel hat.

Abgesehen davon leuchtet mir spontan nicht ein warum ein moderner Shadowmapping-Algorithmus damit Probleme haben sollte.

[Screemer]

Irgendwo muss man ja seinen Schwerpunkt setzen.
Die Endless City Demo sieht auch an gewissen Stellen relativ beschissen aus.
ich finde das das ganze ding im texturierten modus echt kacke aussieht. einzig der wireframe mode ist "yaw dropping".

[Partner]

Wieso zusätzliche Texturkoordinaten? Das normale Mapping das man für die Normalmap verwendet tut's doch?Nein, es wird ja Geometrie zugedichtet ohne das dafür Anpassung an den Texturkoordinaten vorgenommen wird. Daher ergibt sich immer eine Texturverzerrung und die wird sehr deutlich wenn man Tesselation so einsetzen will das man es während des spielens überhaupt bemerken kann.

Man bekommt sie doch praktisch umsonst. Und das LOD will man sowieso haben.Deren Einsatz ergibt wie bereits gesagt mehrere Probleme. Statische LODs braucht man bis kurz vor der Linse sowieso und ab dann merkt man beim spielen einfach keinen Unterschied mehr. Parametrische Oberflächen machen da eine seltene Ausnahme.

Wer redet denn von hochfrequent? Man tesseliert natürlich so, dass man nicht 30 Dreiecke pro Pixel hat.

Abgesehen davon leuchtet mir spontan nicht ein warum ein moderner Shadowmapping-Algorithmus damit Probleme haben sollte.Eine erhöhte Komplexität der Oberfläche verstärkt Artefakte wie temporales Rauschen durch die begrenzte Genauigkeit der Tiefeninformation. Auch verstärkt sich das Problem der Lichtlecks durch die vermehrte Varianz von Überdeckungen.

Auch werden polygonbasierte Verdeckungsabfragen ausgehebelt und so weiter...

[Fragman]

Nein, es wird ja Geometrie zugedichtet ohne das dafür Anpassung an den Texturkoordinaten vorgenommen wird. Daher ergibt sich immer eine Texturverzerrung und die wird sehr deutlich wenn man Tesselation so einsetzen will das man es während des spielens überhaupt bemerken kann.


wobei das dann aber schlechter content ist. diese probleme kann man vermeiden indem man die texturen am tesselierten objekt erstellt. sollte heute eigentlich standard sein.

[Partner]

wobei das dann aber schlechter content ist. diese probleme kann man vermeiden indem man die texturen am tesselierten objekt erstellt. sollte heute eigentlich standard sein.Das vermeidet genau nichts. Man braucht zusätzliche Texturkoordinaten und bei solch feinen Details bedarf das einen gewaltigen Arbeitsaufwand.

[Sven77]

Das vermeidet genau nichts. Man braucht zusätzliche Texturkoordinaten und bei solch feinen Details bedarf das einen gewaltigen Arbeitsaufwand.

Nicht wenn man die Topologie richtig erstellt.

[Partner]

Nicht wenn man die Topologie richtig erstellt.Welche Topologie? Willst du die Texturprojektion herbeizaubern oder wie? Es ist völlig wurscht ob die Objektgeometrie statisch modeliert ist oder indirekt über Pixeldaten generiert wird.

[Fragman]

Welche Topologie? Willst du die Texturprojektion herbeizaubern oder wie? Es ist völlig wurscht ob die Objektgeometrie statisch modeliert ist oder indirekt über Pixeldaten generiert wird.

du erstellst die texturen auf dem highres und nur auf dem highres. diese texturen uebertraegst du dann aufs lowres, ist eigentlich der normale workflow.

edit: zum teil hast du natuerlich recht, wenn man, als extrembeispiel, einer plane per disp viele grobe und feine details zuweisst sodass am ende zb ein gebirge ensteht, dann passen die texturen nicht. aber heute erstellt man das highresmesh und per retopo erstellt man darauf das lowres. so uebergeht man das problem das die topologien zu sehr voneinander abweichen.

[Sven77]

Als Beispiel mal eine Hose eine Characters.. die Falten koennen nicht einfach per Tessellierung erstellt werden, sie muessen immer grob ausmodelliert sein. Und wie Fragman schon gesagt hat, werden die Texturen sowieso aus dem Hi-Res Modell generiert. So kann es sein das die Textur bei der Generieriung verzerrt wird auf einem tessellierten Objekt entzerrt wird.

edit: Der Eingangspost ist ein gutes Beispiel wie man es NICHT macht..

[Partner]

du erstellst die texturen auf dem highres und nur auf dem highres. diese texturen uebertraegst du dann aufs lowres, ist eigentlich der normale workflow.
Als Beispiel mal eine Hose eine Characters.. die Falten koennen nicht einfach per Tessellierung erstellt werden, sie muessen immer grob ausmodelliert sein. Und wie Fragman schon gesagt hat, werden die Texturen sowieso aus dem Hi-Res Modell generiert. So kann es sein das die Textur bei der Generieriung verzerrt wird auf einem tessellierten Objekt entzerrt wird.

edit: Der Eingangspost ist ein gutes Beispiel wie man es NICHT macht..Ihr versteht offensichtlich absolut nicht wie Texturprojektion funktioniert.
Der Texturraum ist geordnet und zweidimensional.
Die Objektgeometrie ist ungeordnet und dreidimensional.

Es ist absolut UNMÖGLICH die Texturdaten ohne Zusatzdaten auf chaotische Geometrie korrekt zu projizieren. Über die Änderung der Texturdaten kann man da überhaupt nichts erreichen weil es immer ein geordnetes Raster bleiben wird.

edit: zum teil hast du natuerlich recht, wenn man, als extrembeispiel, einer plane per disp viele grobe und feine details zuweisst sodass am ende zb ein gebirge ensteht, dann passen die texturen nicht. aber heute erstellt man das highresmesh und per retopo erstellt man darauf das lowres. so uebergeht man das problem das die topologien zu sehr voneinander abweichen.Die Objektgeometrie unterscheidet sich. Da kannst du nichts "übergehen". Es ist einfach so!

[Sven77]

Ihr versteht offensichtlich absolut nicht wie Texturprojektion funktioniert.
Der Texturraum ist geordnet und zweidimensional.
Die Objektgeometrie ist ungeordnet und dreidimensional.

Es ist absolut UNMÖGLICH die Texturdaten ohne Zusatzdaten auf chaotische Geometrie korrekt zu projizieren. Über die Änderung der Texturdaten kann man da überhaupt nichts erreichen weil es immer ein geordnetes Raster bleiben wird.

Die Objektgeometrie unterscheidet sich. Da kannst du nichts "übergehen". Es ist einfach so!

Du reistest auf Prinzipien rum, die an sich so richtig sind, aber in der Praxis keine Probleme machen sofern man den Content entsprechend erstellt. Mal davon abgesehen brauchst du weder meine noch Fragmans Kompetenzen anzweifeln, immerhin verdienen wir mit sowas unser Geld..

[Partner]

Du reistest auf Prinzipien rum, die an sich so richtig sind, aber in der Praxis keine Probleme machen sofern man den Content entsprechend erstellt. Mal davon abgesehen brauchst du weder meine noch Fragmans Kompetenzen anzweifeln, immerhin verdienen wir mit sowas unser Geld..Und ich verdiene mein Geld u.A. damit den Künstlern technologische Grundprinzipien begreiflich zu machen, auch wenn das öfters mal aussichtslos erscheint.

Wenn chaotische Geometrie geändert wird, müssen für korrekte Texturprojektion zwangsläufig auch die Texturkoordinaten geändert werden. PUNKT!

[Fragman]

Die Objektgeometrie unterscheidet sich. Da kannst du nichts "übergehen". Es ist einfach so!

hast du jemals so einen workflow durchgespielt? ich hab das schon ein paarmal gemacht und hatte keine probleme mit verzerrungen. wenn der workflow sauber ist funktioniert das ohne probleme.

kannst du mal ein beispiel in bildern bringen was und wie probleme bereitet?

[Partner]

Wir haben das Problem wie bereits gesagt bei displacement-maps bemerkt. Die Stärke der Verzerrung ist natürlich vom Grad der geometrischen Auslenkungen abhängig. Man sieht das auch z.B. in dieser Unigine Dings-Demo.

Versuch mal so heranzugehen:
Dein Objekt ist ein planares Rechteck. Die Textur hat ein Punktmuster und die Eckpunkte des geometrischen Rechtecks entsprechen auch den Eckpunkten der Textur. Nun willst du mit displacement mapping oder geometry tesselation der Oberfläche kleine Würfel hinzufügen.
Wie sieht dann die Texturierung der Würfelseitenflächen aus?

Du meinst das kann man durch Änderung der Texturdaten lösen, ohne zusätzliche Texturkoordinaten hinzuzufügen? Dann zeige/beschreibe bitte wie die Textur dann aussehen müsste um ein korrektes Punktmuster mit identischer Auflösung an die Seitenflächen zu projizieren.

[Fragman]

Wir haben das Problem wie bereits gesagt bei displacement-maps bemerkt. Die Stärke der Verzerrung ist natürlich vom Grad der geometrischen Auslenkungen abhängig. Man sieht das auch z.B. in dieser Unigine Dings-Demo.

Versuch mal so heranzugehen:
Dein Objekt ist ein planares Rechteck. Die Textur hat ein Punktmuster und die Eckpunkte des geometrischen Rechtecks entsprechen auch den Eckpunkten der Textur. Nun willst du mit displacement mapping oder geometry tesselation der Oberfläche kleine Würfel hinzufügen.
Wie sieht dann die Texturierung der Würfelseitenflächen aus?

Du meinst das kann man durch Änderung der Texturdaten lösen, ohne zusätzliche Texturkoordinaten hinzuzufügen? Dann zeige/beschreibe bitte wie die Textur dann aussehen müsste um ein korrektes Punktmuster mit identischer Auflösung an die Seitenflächen zu projizieren.

was du beschreibst ist schlechter content. gerade die unique engine zeigt sehr gut wie man es NICHT machen sollte.

das beispiel mit den wuerfeln wuerde man so nie rendern, dafuer erstellt man das lowres mesh entsprechend und schon gibt es an der stelle kein problem.
in zeiten von zbrush, mudbox und zb topogun sind solche probleme eigentlich keine mehr.

[Partner]

Das hat doch nichts mit den Inhalten zu tun. Das Problem ist prinzipbedingt!
Displacement mapping oder geometry tesselation ist schlicht unnötig wenn sich die Detailoberfläche so wenig vom Objekt abhebt dass man keine Verzerrung erkennen kann.

Deine Behauptung, das Problem angeblich mit irgendwelchen Texturmanipulationen lösen zu können, ist nichts als heiße Luft. Ohne zusätzlichen Texturkoordinaten wird die Textur entweder verzerrt oder mit inhomogener Auflösung projiziert. Wenn dem nicht so währe, würde uv-mapping nichts als Zeitverschwendung sein!

[Fragman]

Das hat doch nichts mit den Inhalten zu tun. Das Problem ist prinzipbedingt!
Displacement mapping oder geometry tesselation ist schlicht unnötig wenn sich die Detailoberfläche so wenig vom Objekt abhebt dass man keine Verzerrung erkennen kann.

Deine Behauptung, das Problem angeblich mit irgendwelchen Texturmanipulationen lösen zu können, ist nichts als heiße Luft. Ohne zusätzlichen Texturkoordinaten wird die Textur entweder verzerrt oder mit inhomogener Auflösung projiziert. Wenn dem nicht so währe, würde uv-mapping nichts als Zeitverschwendung sein!

unnoetig? hast du jemals dispmapping eingesetzt?
und wo hab ich gesagt das ich die texturen manipuliere. das basemesh wird durch retopo so ans highres angepasst das es keine groben unterschiede gibt und man eben diese verzerrungen vermeidet. man rendert keine plane mit einer dispmap die wuerfel erzeugt, absolut unsinnig. das beispiel hat nichts mit der wirklichkeit zu tun.

deine argumente hoeren sich an als wenn sie 12 jahre alt sind. EDIT: wobei man ja sagen muss das man damals schon retopo genutzt hat fuer gescannte modelle.

[Partner]

Ja, wir haben offset mapping eingesetzt und das Problem war auch da mehr als deutlich.

Alles was du mit deinen Werkzeugen machst ist nichts weiter als soviel Objektdetails hinzuzufügen bis die prinzipbedingte Texturverzerrung zumindest weniger offensichtlich ist.

[del_4901]

Ja, wir haben offset mapping eingesetzt und das Problem war auch da mehr als deutlich.

Alles was du mit deinen Werkzeugen machst ist nichts weiter als soviel Objektdetails hinzuzufügen bis die prinzipbedingte Texturverzerrung zumindest weniger offensichtlich ist.
Dann waren eure Artists einfach nicht gut genug. :D

[Fragman]

Ja, wir haben offset mapping eingesetzt und das Problem war auch da mehr als deutlich.


und was hat offset mapping mit dispmapping zu tun?

offset mapping simuliert doch nur das mehr details da sind ohne wirklich welche zu erstellen, dispmapping dagegen generiert komplett neue geodetails (wobei ich mir hier nicht so ganz sicher bin ob das nicht vielleicht besser geht, bei crisis oder auch age of conan ist mir sowas nicht aufgefallen).

nochmal, wenn ich eine plane nehme und darauf eine dispmap mit extremen geometrieaenderungen rendere kommt nur mist raus. das ist aber schlechter content. statt eine plane zu nehmen sollte man ein verneunftiges basemesh hernehmen und darauf displacen, dann gibts auch keine texturverzerrungen.

[Langenscheiss]

Seh ich auch so. Texturverzerrung ist zwar nicht ganz vermeidbar, aber wenn man die Technik überstrapaziert und teilweise die gesamte Geometrie nur noch durch Displacement-Mapping realisiert, isses einfach zuviel des Guten. Vernünftiges meshes mit "per Hand" erstellten UVs können dadurch leider noch nicht ersetzt werden. Stattdessen sollte man sich auf das Abrunden von Objekten und (im Falle von virtual displacement allein auf) zusätzliche Textur-Details (die Furchen im Sand bei Crysis, oder die Steine) konzentrieren. Das Beispiel aus dem Startpost zeigt eindeutig, wofür diese Technik nicht gemutzt werden sollte. Die dort dargestellte Geometrie sollte per Hand erstellt werden, zumindest das base-mesh und der rest kann ja dann mit tesselation abgerundet werden. Offensichtliches Problem: Workload für die Grafiker!
Ein Vorteil hat aber z.B. Parallax-Mapping. Man kann es (mal besser, meistens weniger gut) in eine bestehende Engine integrieren und muss "nur" heightmaps erstellen. Tesselation muss schon von Anfang an geplant und integriert werden.

[Partner]

und was hat offset mapping mit dispmapping zu tun?

offset mapping simuliert doch nur das mehr details da sind ohne wirklich welche zu erstellen, dispmapping dagegen generiert komplett neue geodetails (wobei ich mir hier nicht so ganz sicher bin ob das nicht vielleicht besser geht, bei crisis oder auch age of conan ist mir sowas nicht aufgefallen).Das Problem tritt bei jedem dieser Verfahren auf.

nochmal, wenn ich eine plane nehme und darauf eine dispmap mit extremen geometrieaenderungen rendere kommt nur mist raus. das ist aber schlechter content. statt eine plane zu nehmen sollte man ein verneunftiges basemesh hernehmen und darauf displacen, dann gibts auch keine texturverzerrungen.Es gibt IMMER eine Texturverzerrung! Man kann lediglich deiner Beschreibung entsprechend zusätzliche statische Geometrie hinzuzufügen um die Offensichtlichkeit zu minimieren, was ja das Gegenteil von dem ist, was man mit den Verfahren eigentlich bezwecken will.
Texturverzerrung ist ein prinzipieller Nachteil dieser Verfahren eben weil u.A.Texturkoordinaten ausgelassen werden.

Es ist mir jetzt wirklich deutlich zu blöd weiter darüber zu diskutieren.

[del_4901]

Das Problem tritt bei jedem dieser Verfahren auf.

Es gibt IMMER eine Texturverzerrung! Man kann lediglich deiner Beschreibung entsprechend zusätzliche statische Geometrie hinzuzufügen um die Offensichtlichkeit zu minimieren, was ja das Gegenteil von dem ist, was man mit den Verfahren eigentlich bezwecken will.
Texturverzerrung ist ein prinzipieller Nachteil dieser Verfahren eben weil u.A.Texturkoordinaten ausgelassen werden.

Es ist mir jetzt wirklich deutlich zu blöd weiter darüber zu diskutieren.
Wenn man auf dem Highpoly texturiert und dann die Information auf ein (angemessenes) Lowpoly transferiert, kann man die Verzerrung wieder ausgleichen. Dabei verliert man maximal etwas Texturaufloesung. Zumal zusaetzliche UVs auch kein garant fuer Verzerrungsfreies arbeiten ist, wenn man schlampig arbeitet.

[Sven77]

Es ist mir jetzt wirklich deutlich zu blöd weiter darüber zu diskutieren.

Oh verdammt, haben eigentlich schon die grossen Postproduktionshäuser mitbekommen das du Displacementmapping für obsolet erklärst? Die klatschen sich bei Framestore und co. bestimmt auf die Stirn..

[Partner]

Wenn man auf dem Highpoly texturiert und dann die Information auf ein (angemessenes) Lowpoly transferiert, kann man die Verzerrung wieder ausgleichen. Dabei verliert man maximal etwas Texturaufloesung. Zumal zusaetzliche UVs auch kein garant fuer Verzerrungsfreies arbeiten ist, wenn man schlampig arbeitet.Ob nun so oder so, ändert nichts am Nachteil.

Oh verdammt, haben eigentlich schon die grossen Postproduktionshäuser mitbekommen das du Displacementmapping für obsolet erklärst? Die klatschen sich bei Framestore und co. bestimmt auf die Stirn..Was soll der Blödsinn mir irgend welche Dinge in den Mund zu legen!? Displacement mapping wird für Mikropolygone beim offline rendering eingesetzt, wo der Nachteil eh keine Rolle spielt.

Pseudogeometrie wie offset mapping und texturbasiertes geometry tesselation haben in Spielen die gleichen prinzipbedingten Nachteile, nur sind diese dort Aufgrund der limitierten Ressourcen deutlich dramatischer. Es ist in der Spieleindustrie nicht nur meine Einschätzung das heutzutage Geometriedetails relativ unwichtig und gleichzeitig kontraproduktiv gegenüber viel bedeutendere Eigenschaften wie z.B. die Beleuchtung sind.

Wenn ihr der Meinung seid, dass geometry tesselation für Euer Spiel vorteilhaft ist, dann nutzt es doch. Euer Versuch die definitiven Nachteile wegzudiskutieren ist jedoch einfach totaler Schwachsinn.

Habe nun alles dazu mehrmals gesagt. Und tschüß.

[Sven77]

Tessellation erweitert in Realtimeanwendungen die bisher vorhandenen Methoden des Normal/Bump/Parallaxmappings für High-Details, und nicht mehr.. deine angesprochenen Probleme entstehen nur dann wenn man Tessellation für reine Geometrieerstellung benutzt, statt Geometrie mit mehr Details auszustatten. Nicht mehr.. das die Techdemos da einfach zu weit gehen ist ja wohl klar.. allein um die hässlichen Polygonkanten wegzubekommen ist Tesselation genial, und wenn da auch nur die kleinste Texturverzerrung sichtbar ist, dann hat der Artist einfach geschlampt. Punkt.
Ausserdem solltest du mal deinen Wissen über mögliche UV-Workflows auffrischen..

[Fragman]

Wenn ihr der Meinung seid, dass geometry tesselation für Euer Spiel vorteilhaft ist, dann nutzt es doch. Euer Versuch die definitiven Nachteile wegzudiskutieren ist jedoch einfach totaler Schwachsinn.

Habe nun alles dazu mehrmals gesagt. Und tschüß.

darum ging es doch garnicht. es geht darum das du versucht hast schlechten content damit zu entschuldigen das diese technik allgemein nicht funktioniert und genau das ist nicht der fall.

und die verwendung von micropolygonen als technik hat erstmal mit dem problem von schlechtem content und den damit verbundenen verzerrungen nichts zu tun. wenn spieleentwickler der meinung sind sie muessen simple planes mit extremen dispmaps aufhuebschen ohne den content anzupassen ist das schon ein problem. allein darum ging es hier.

[del_4901]

Ob nun so oder so, ändert nichts am Nachteil. Und was ist mit den Vorteilen, die kehren wir schoen unter den Tisch oder was?

Was soll der Blödsinn mir irgend welche Dinge in den Mund zu legen!? Displacement mapping wird für Mikropolygone beim offline rendering eingesetzt, wo der Nachteil eh keine Rolle spielt.

Pseudogeometrie wie offset mapping und texturbasiertes geometry tesselation haben in Spielen die gleichen prinzipbedingten Nachteile, nur sind diese dort Aufgrund der limitierten Ressourcen deutlich dramatischer. Es ist in der Spieleindustrie nicht nur meine Einschätzung das heutzutage Geometriedetails relativ unwichtig und gleichzeitig kontraproduktiv gegenüber viel bedeutendere Eigenschaften wie z.B. die Beleuchtung sind.

Wenn ihr der Meinung seid, dass geometry tesselation für Euer Spiel vorteilhaft ist, dann nutzt es doch. Euer Versuch die definitiven Nachteile wegzudiskutieren ist jedoch einfach totaler Schwachsinn.

Habe nun alles dazu mehrmals gesagt. Und tschüß.Und ich find es schwachsinning die Vorteile wegzudiskutiern... Und ausserdem waehr ich vorsichtig wenn man Offsetmapping und Displacmentmapping in eine Wagschale wirft. Jeh nach implementierung des Offsetmappings kann es pasieren, das man das filtern von Hand im Shader korrigieren muss. Beim Displacementmapping hat man solche Probleme prinzipbedingt nicht. Und ausserdem stellt es niemand hier in Frage das gutes Lighting sehr wichtig ist.

[deekey777]

http://www.pcgameshardware.de/aid,814915/Dragon-Age-2-im-Techniktest-Nur-DirectX-11-bringt-maximale-Bildqualitaet/Rollenspiel-Adventure/Test/
Beim Einsatz von DirectX 11 fällt als erstes das Displacement Mapping auf dem Boden auf (die Spielfigur "versinkt" etwas),
Wie kriegt man eigentlich so etwas hin?

[Nakai]

Wie kriegt man eigentlich so etwas hin?

Indem man bein der Kollisionsabfrage eben den untesselierten Boden nimmt, was rein technisch gesehen völlig verständlich ist. Lächerlich ist es allemal...;D

[y33H@]

Daran erkennt man - wie an verzerrten Texturen auch -, dass das Feature schlicht "aufgeflanscht" wurde. Verständlich, aber optisch eben stellenweise lächerlich.

[san.salvador]

Daran erkennt man - wie an verzerrten Texturen auch -, dass das Feature schlicht "aufgeflanscht" wurde. Verständlich, aber optisch eben stellenweise lächerlich.
Genau das hab ich von Anfang an gesagt. Für viele Devs ist es ein angeflanschtes Chebox-Feature, das hinten drangenudelt wird. Wenn man nicht von Anfang an mit dem Konzept Tessellation arbeitet, sieht es so aus, wie es aussieht - und zwar shice.

Aber Daumen hoch für die Vergleichsshots - sehr praktisch. Bissl größer dürftens noch sein. ;)

[y33H@]

Mehr als 640pix sprengen die Breite. Und ich konzentriere mich lieber auf die zu zeigenden Details (idR Ausschnitte).

[san.salvador]

Mehr als 640pix sprengen die Breite.
Wovon? Deinem Handy? :D

Und ich konzentriere mich lieber auf die zu zeigenden Details (idR Ausschnitte).
War auch Kritik auf hohem Niveau. Gute Sache, I like! ;)

[deekey777]

Daran erkennt man - wie an verzerrten Texturen auch -, dass das Feature schlicht "aufgeflanscht" wurde. Verständlich, aber optisch eben stellenweise lächerlich.
Es ist gerade unverständlich.
Man hätte auch die Ränder nach unten ziehen können und die originale Fläche gleich hoch belassen.

[san.salvador]

Es ist gerade unverständlich.
Man hätte auch die Ränder nach unten ziehen können und die originale Fläche gleich hoch belassen.
Da siehst du mal, wie sehr man sich bei der Tessellation bemüht hat.

"Haben wir auch Tessellation?"
"Nö Chef."
"Dann mach mal, in drei Wochen ist Release."

[Sven77]

http://www.pcgameshardware.de/aid,814915/Dragon-Age-2-im-Techniktest-Nur-DirectX-11-bringt-maximale-Bildqualitaet/Rollenspiel-Adventure/Test/

Wie kriegt man eigentlich so etwas hin?

Wurde mein Beitrag gelöscht? :confused:

Ist ein Nebeneffekt, tessellierte Geometrie kann man nicht zur Kolliosionsabfrage benutzen, deswegen sollte man es bei Terrain mit Bedacht einsetzen, vor allem wenn man damit interagiert

[y33H@]

Man könnte natürlich die Kolliosionsabfrage auf die tessellierte Geometrie abgleichen, aber das wird wohl erst in 5 Jahren oder mehr der Fall sein, wenn Tessellation so banal ist wie heute Bump Mapping.

[y33H@]

Wovon? Deinem Handy?Ich schaue mir auf meinem Legend keine Klickvergleiche an :freak: Nein, die Seite ist für "Unregs" auf 1.024 Pixel ausgelegt, mache ich die Vergleich größer als 650pix (dann fällt der Rand weg), sprengt es da Layout.
War auch Kritik auf hohem Niveau. Gute Sache, I like!+1 :biggrin:

[Coda]

Man könnte natürlich die Kolliosionsabfrage auf die tessellierte Geometrie abgleichen, aber das wird wohl erst in 5 Jahren oder mehr der Fall sein, wenn Tessellation so banal ist wie heute Bump Mapping.
Eher nie. Der Aufwand ist kaum gerechtfertigt.

[y33H@]

Ich meinte, wenn Tessellation kein abschaltbares Feature mehr ist. Also Tessellation das ist, was heute die CPU in Sachen Geometrie berechnet die Basis für den Polycount und die Kolliosionsabfrage ist.

[Coda]

Du redest wirres Zeug.

[y33H@]

Ich würde eher sagen, du verstehst nicht was ich meine. Was bei meinem "wirrem Zeug" aber nicht verwunderlich ist ;)

[Coda]

Doch doch, ich verstehe schon was du meinst, es ergibt nur technisch rein gar keinen Sinn. Mal abgesehen davon, dass der zweite Satz grammatikalisch falsch ist.

Hint: Die CPU sieht die durch Tesselation berechnete Geometrie NIE. Außer du willst SPF statt FPS.

[y33H@]

Im zweiten Satz fehlt ein Komma, ja. Und schei0e formuliert, wie ich nach erneutem Lesen zugeben muss. Wieso ergibt's technisch keinen Sinn? Wo am Ende die Polygone herkommen auf die ich die Kolliosionsabfrage setze, sollte doch egal sein? Hauptsache, die Geometrie ändert sich nicht, ansonsten haben wir den DA2-Fall.

[Coda]

Wo am Ende die Polygone herkommen auf die ich die Kolliosionsabfrage setze, sollte doch egal sein?
Ist es nicht.

[y33H@]

Kannst du mir bitte auch erklären, warum? Ich würde das gerne wissen/verstehen. THX.

[Coda]

Readbacks von der GPU sind ein völliges No-Go, vor allem wenn es auch noch eine Abhängigkeit im gleichen Frame gibt. Das liegt wirklich in Dantes letztem Kreis der Performance-Hölle.

Mal abgesehen davon, dass die Datenstrukturen für die Kollisionsabfrage natürlich voroptimiert und statisch vorliegen.

[del_4901]

Da man eh extra Geo fuer die Kollision hat koennte man die Displacementmap auch da rein baken. Das wird aber entweder sehr aufwendig zur Laufzeit oder nur wenig genauer als ohne. Und bei letzterem steht der Aufwand der Implementierung in keinem Verhaeltniss.

[Coda]

Wenn dann so, ja. Das wäre wahrscheinlich sogar halbwegs schnell machbar. Dynamische Geometrie zur Kollisionsabfrage zu verwenden wäre eh hirnverbrannt. Viel zu undeterministisch.

[y33H@]

Ich sehe schon, ich sollte mal mehr programmieren als HTML :ugly: Dennoch danke.

[Coda]

Ich muss dich enttäuschen, selbst HTML ist kein Programmieren *scnr*

[san.salvador]

Ich sehe schon, ich sollte mal mehr programmieren als HTML :ugly: Dennoch danke.
Programmier du erst mal mehr als 640px in dein html!



*duck* :D

[del_4901]

Wenn dann so, ja. Das wäre wahrscheinlich sogar halbwegs schnell machbar. Dynamische Geometrie zur Kollisionsabfrage zu verwenden wäre eh hirnverbrannt. Viel zu undeterministisch.
Ja und wenn man es zu genau macht, dann schwebt der Fuss in der Luft und dann wird dort gemeckert. Solang man keine 10 oder mehr bones in den Fuessen hat, lohnt sich das wirklich noch nicht. Warscheinlich ist es besser einfach den Boden nicht so stark zu verformen.

[Coda]

Ich habe das Gefühl, dass das Problem vor allem ein rein positives Displacement ist. Das führt dazu, dass der gerenderte Boden nicht durchschnittlich die gleiche Höhe wie die Kollisionsgeometrie hat, sondern immer darüber liegt.

[del_4901]

Ich habe das Gefühl, dass das Problem vor allem ein rein positives Displacement ist. Das führt dazu, dass der gerenderte Boden nicht durchschnittlich die gleiche Höhe wie die Kollisionsgeometrie hat, sondern immer darüber liegt.
Ja das koennte an der Toolchain liegen, aber da bin ich nicht weit genug drin um das zu beurteilen.

[Sven77]

Man muss einfach aufpassen wenn man Content erstellt, bei den DA2 Platten ist ea sinnvoll statt der Platten die Fugen entgegen der Normalen zu versetzen, gleiches Ergebnis ohne Clipping

[dllfreak2001]

Und dann hast du unten drunter das Terrain welches wieder aus den Fugen guckt.

[deekey777]

Und dann hast du unten drunter das Terrain welches wieder aus den Fugen guckt.
Aber dieses Terrain sollte doch von der neuen Geometrie verdeckt werden - wie die Füße der Alten jetzt.

[Sven77]

Und dann hast du unten drunter das Terrain welches wieder aus den Fugen guckt.

Wat? Nein... da ist nix "drunter"..

[DaBrain]

Wie sieht es eigentlich mit den Tools aus?

Erstellt man einfach eine Displacement Map und kann sie gleich so verwenden?

Lassen sich diese Maps platzsparend speichern?
(Nicht nur wegen des Grafikkartenspeichers, sondern auch weil auf dem PC noch immer alle Spiele auf eine DVD (oder im schlimmsten Fall) 2 DVDs passen müssen...)

Muss immer gleichmäßig tessliert werden?
Gerade wenn ich an nicht-organische Objekte denke stellt sich mir die Frage ob Tesslation dafür sinnvoll nutzbar ist. Fahrzeuge, Rüstungen, Gebäude, usw. die nicht komplett abgerundet sind bräuchten massiv mehr Polygone und sehr hoch aufgelöste Maps um korrekt auszusehen.


Kann man den Poly Count auch dynamisch unter den des Base Meshes reduzieren?

[Coda]

Und dann hast du unten drunter das Terrain welches wieder aus den Fugen guckt.
:facepalm:

Erstellt man einfach eine Displacement Map und kann sie gleich so verwenden?
Ja.

Lassen sich diese Maps platzsparend speichern?
Ist halt ne zusätzliche Textur

Muss immer gleichmäßig tessliert werden?
Nein.

Kann man den Poly Count auch dynamisch unter den des Base Meshes reduzieren?
Nö.

[DaBrain]

Wenn nicht gleichmäßig tessliert werden muss, was wäre denn dann eine sinvolle Möglichkeit die Poly-Dichte zu kontrollieren?

Wäre den denkbar den Tesslationsgrad über einen Kanal der Displacement Map zu steuern?

[dllfreak2001]

:facepalm:
.

Warum nicht?

[Sven77]

Da ist nix was "durchkucken" könnte...

[Langenscheiss]

Da ich bis auf unigine noch nicht viele Spiele mit Tess. selbst gespielt habe mal ne Zwischenfrage: Werden jetzt eigentlich Einschusslöcher und ähnliches korrekt auf die Geomtrie geklatscht? Ich hab das beim virtual disp. mapping noch nie korrekt gesehen. Ich mein, hier wurde ja schon über die Unzulänglichkeiten bei der "physikalischen" Geometrie gesprochen, und da ich nicht genau weiß, wie das decal system in engines technisch genau funktioniert, wollt ich das mal wissen.
:devil: :devil: :devil:

[dllfreak2001]

Da ist nix was "durchkucken" könnte...
Bist du dir da so sicher? :wink:

[deekey777]

Warum soll da was überhaupt durchguggen?

[Langenscheiss]

Lassen sich diese Maps platzsparend speichern?
(Nicht nur wegen des Grafikkartenspeichers, sondern auch weil auf dem PC noch immer alle Spiele auf eine DVD (oder im schlimmsten Fall) 2 DVDs passen müssen...)

Spiele, die POM nutzen, verwenden doch auch heightmaps, also graustufen-texturen. Ich weiß jetzt nicht, wie groß die Teile beim DM via Tesselation sind und welche Auflösung ausreicht, aber üblicherweise sollten die Kapazitäten ausreichen, dass tun sie zumindest beim virt. displacement mapping und deswegen wohl auch beim geometrischen DM via Tesselation. Und darüber hinaus ist DM (mit verzerrten diffuse maps) auch kein Problem bei der Spieleentwicklung, weil für viele Texturen (nicht bei komplexen Characktermodellen, wo Geometrie in die Normalmap gepresst wird) afaik sowieso die heightmaps zusammen mit den normalmaps erstellt werden. Ich persönlich habe für meine privaten Minimods zumindest immer die heightmaps gemalt um dann mit nem ps plugin die normals berechnen zu lassen. Doch genau deshalb entstehen ja die Probleme, weil für eine grundsätzliche Funktionstüchtigkeit von DM der content nicht groß angepasst werden muss. Wenn man dies müsste, so würden die Entwickler auf Grund von Zeitdruck und Entwicklungskosten wohl möglich gar nicht erst DM einsetzen, abgesehen von den Fällen, wo wenig Vorarbeit nötig ist wie z.B. bei Wasseroberflächen, dessen "Farbe" sowieso fast nur durch Shaderberechnungen erzeugt werden.

[dllfreak2001]

Warum soll da was überhaupt durchguggen?

Ich denke mir das so wie zB. in der FarCry-Sandbox oder im Hammer-Editor, dort sind Terrain und sonstige Levelgometrie zwei verschiedene Objekte. Unter dem Fußboden könnte weiterhin das Terrain dargestellt werden und wenn die Ausprägung der Tess. nun negativ wäre, könnte der tiefste Punkt der Fuge durchaus tiefer liegen als das darunter gelegene Terrain an dieser Stelle...
Man macht es sich eben einfach.

Als Beispiel....
http://www.abload.de/thumb/ako340nn2x.jpg (http://www.abload.de/image.php?img=ako340nn2x.jpg)

[Coda]

Bist du dir da so sicher? :wink:
Ja.

[del_4901]

Ich denke mir das so wie zB. in der FarCry-Sandbox oder im Hammer-Editor, dort sind Terrain und sonstige Levelgometrie zwei verschiedene Objekte. Unter dem Fußboden könnte weiterhin das Terrain dargestellt werden und wenn die Ausprägung der Tess. nun negativ wäre, könnte der tiefste Punkt der Fuge durchaus tiefer liegen als das darunter gelegene Terrain an dieser Stelle...
Man macht es sich eben einfach.

Als Beispiel....
http://www.abload.de/thumb/ako340nn2x.jpg (http://www.abload.de/image.php?img=ako340nn2x.jpg)

Das ist kein Beispiel, das ist einfach nur schlechter Content.

[Langenscheiss]

das ist einfach nur schlechter Content.
Aber gings ihm nicht genau darum, schlechten Content zu zeigen? Zugegeben, jeder mapper bei Verstand weiß, dass er sowas vermeiden muss, aber kann denn nicht genau sowas theoretisch passieren, wenn man DM im Nachhinein einfach draufklatscht, oder wird die Geometrie unter der mit DM behandelten Geometrie weiterhin ausgeblendet, als sei sie tatsächlich noch dahinter bzw. darunter (keine Ahnung wann genau der renderer entscheidet, was gerendert wird)?

[Fragman]

Aber gings ihm nicht genau darum, schlechten Content zu zeigen? Zugegeben, jeder mapper bei Verstand weiß, dass er sowas vermeiden muss, aber kann denn nicht genau sowas theoretisch passieren, wenn man DM im Nachhinein einfach draufklatscht, oder wird die Geometrie unter der mit DM behandelten Geometrie weiterhin ausgeblendet, als sei sie tatsächlich noch dahinter bzw. darunter (keine Ahnung wann genau der renderer entscheidet, was gerendert wird)?

man sollte eigentlich davon ausgehen das man den content dann zumindest grob ueberfliegt im editor oder spiel um zu schauen ob es passt. das ist einfach nur schlechter content der mit dm ueberhaupt nichts zu tun hat. wenn sowas passiert haben die artists gepennt und die qualitaetskontrolle sowieso. ist aber voellig unabhaengig von der tech. wenn ich in einem sw spiel ein bsg raumschiff sehe dann geb ich ja auch nicht der engine die schuld sondern dem depp der das falsche model integriert hat.

[Langenscheiss]

man sollte eigentlich davon ausgehen das man den content dann zumindest grob ueberfliegt im editor oder spiel um zu schauen ob es passt. das ist einfach nur schlechter content der mit dm ueberhaupt nichts zu tun hat. wenn sowas passiert haben die artists gepennt und die qualitaetskontrolle sowieso. ist aber voellig unabhaengig von der tech. wenn ich in einem sw spiel ein bsg raumschiff sehe dann geb ich ja auch nicht der engine die schuld sondern dem depp der das falsche model integriert hat.

Alles richtig, aber weshalb sagst du mir das? Mir (und so wie ich das verstanden habe auch dem dllfreak, wenn nicht, dann sorry das ich hier für dich spreche) ging es nur um die theoretische Möglichkeit. Dass das einfach nur mieser content ist, hab ich nie bezweifelt.

[Coda]

Aber gings ihm nicht genau darum, schlechten Content zu zeigen? Zugegeben, jeder mapper bei Verstand weiß, dass er sowas vermeiden muss, aber kann denn nicht genau sowas theoretisch passieren, wenn man DM im Nachhinein einfach draufklatscht, oder wird die Geometrie unter der mit DM behandelten Geometrie weiterhin ausgeblendet, als sei sie tatsächlich noch dahinter bzw. darunter (keine Ahnung wann genau der renderer entscheidet, was gerendert wird)?
Kein Renderer dieser Welt wird das Terrain zweimal rendern, nur weil Tesselations-Shader eingesetzt werden. Das ist einfach hahnebüchener Unsinn. Es ist genau der gleiche Basemesh der verwendet wird. Man setzt nur einen Domain- und Fragment-Shader in die Pipeline und bindet eine zusätzliche Displacement-Textur dran.

[Fragman]

Alles richtig, aber weshalb sagst du mir das? Mir (und so wie ich das verstanden habe auch dem dllfreak, wenn nicht, dann sorry das ich hier für dich spreche) ging es nur um die theoretische Möglichkeit. Dass das einfach nur mieser content ist, hab ich nie bezweifelt.

eben weil es mieser content ist und nicht an der tech liegt braucht man das nicht weiter zu diskutieren. wenn sowas in spielen drin ist, dann hat da jemand nicht aufgepasst, wie ein bug. natuerlich ist sowas theoretisch moeglich, aber es ist technisch nicht vorgesehen das der artist die objekte falsch plaziert. ich versteh hier nicht ganz weshalb man sich so an contentfehlern aufhaengt.:confused:

[del_4901]

eben weil es mieser content ist und nicht an der tech liegt braucht man das nicht weiter zu diskutieren. wenn sowas in spielen drin ist, dann hat da jemand nicht aufgepasst, wie ein bug. natuerlich ist sowas theoretisch moeglich, aber es ist technisch nicht vorgesehen das der artist die objekte falsch plaziert. ich versteh hier nicht ganz weshalb man sich so an contentfehlern aufhaengt.:confused:
Weil in den Koepfen der Menschen drin ist, dass das Codeingdepartment alles fixen muss. Da werden dann Spezialloesungen gefordert die ueberhaupt nicht noetig sind.

[dllfreak2001]

Aber gings ihm nicht genau darum, schlechten Content zu zeigen? Zugegeben, jeder mapper bei Verstand weiß, dass er sowas vermeiden muss, aber kann denn nicht genau sowas theoretisch passieren, wenn man DM im Nachhinein einfach draufklatscht, oder wird die Geometrie unter der mit DM behandelten Geometrie weiterhin ausgeblendet, als sei sie tatsächlich noch dahinter bzw. darunter (keine Ahnung wann genau der renderer entscheidet, was gerendert wird)?

Ich dachte es geht um Tess. und nicht um DM.

Edit: Sehe gerade ich habe mich verguckt, ich dachte das in Dragon Age 2 Tess für den Boden verwendet wurde, sorry...
Meine Diskussionsbeiträge sind deshalb hinfällig.

[LovesuckZ]

Kann mir jemand erklären, was in Dragon Age 2 beim Einsatz von Tessellation mit den Texturen passiert?
Video (http://www.multiupload.com/CU2G3IUHK9)

Ohne Tessellation:
http://www.abload.de/thumb/da2_1knii.png (http://www.abload.de/image.php?img=da2_1knii.png)
Mit Tessellation (sehr hoch):
http://www.abload.de/thumb/da2_2yn27.png (http://www.abload.de/image.php?img=da2_2yn27.png)

/Offtopic: Die Tessellation-Implementierung ist weitaus schlimmer als das Versinken der Figur: Es gibt deutlich sichtbares morphen, starkes Aliasing und diese Artefakte. Das müsste doch den Leuten bei Bioware und AMD peinlich sein soetwas in einem Spiel zu veröffentlichen.

[y33H@]

Wie du erkennen kannst, kriegt die Umgebung an einigen Stellen mehr Polygone ab. Das Displacement Mapping sorgt zudem für das "versinken". Es wie so oft: DX11 wurde "aufgeflanscht" und das sieht man halt auch.

[LovesuckZ]

Wie du erkennen kannst, kriegt die Umgebung an einigen Stellen mehr Polygone ab. Das Displacement Mapping sorgt zudem für das "versinken". Es wie so oft: DX11 wurde "aufgeflanscht" und das sieht man halt auch.

Darum geht es mir nicht. Anscheinend kommt es zu Problemen, wenn die Kamera nicht exakt auf die Textur ausgerichtet wird. Dann entstehen diese Artefakte, die deutlich sichtbar sind. Das die Umgebung mehr Polys abbekommen, ist mir klar.

[y33H@]

Ok. Was meinst du mit Artefakte? Vll bin ich hier am 19er @ work zu blöd es zu sehen.

[LovesuckZ]

Ok. Was meinst du mit Artefakte? Vll bin ich hier am 19er @ work zu blöd es zu sehen.

Hier:
http://www.abload.de/thumb/da2_3vn10.jpg (http://www.abload.de/image.php?img=da2_3vn10.jpg)

[y33H@]

Das ist das Displacement Mapping, welches weder von MSAA noch AF erfasst wird. Daher sieht das so "kaputt" aus (ähnlich bei Crysis, nur dass das POM hier "rund" ist und nicht so heraussticht wie das DM).

EDIT
Hier im Detail:

http://www.abload.de/thumb/dragon_age_2_bodentextg7rl.jpg (http://www.abload.de/image.php?img=dragon_age_2_bodentextg7rl.jpg) http://www.abload.de/thumb/dragon_age_2_bodentextd719.jpg (http://www.abload.de/image.php?img=dragon_age_2_bodentextd719.jpg)

[LovesuckZ]

Das ist das Displacement Mapping, welches weder von MSAA noch AF erfasst wird. Daher sieht das so "kaputt" aus (ähnlich bei Crysis, nur dass das POM hier "rund" ist und nicht so heraussticht wie das DM).

EDIT
Hier im Detail:

http://www.abload.de/thumb/dragon_age_2_bodentextg7rl.jpg (http://www.abload.de/image.php?img=dragon_age_2_bodentextg7rl.jpg) http://www.abload.de/thumb/dragon_age_2_bodentextd719.jpg (http://www.abload.de/image.php?img=dragon_age_2_bodentextd719.jpg)

Nein, davon rede ich nicht. Ich meine die Fehldarstellungen an den Felsen, wenn die Kamera in ungünstiger Position ist. Hier Bilder ohne AF, die das Problem deutlich zeigen:

http://www.abload.de/thumb/dragonage2_2011_03_15_trza.png (http://www.abload.de/image.php?img=dragonage2_2011_03_15_trza.png)
http://www.abload.de/thumb/dragonage2_2011_03_15_3rbg.png (http://www.abload.de/image.php?img=dragonage2_2011_03_15_3rbg.png)

http://www.abload.de/thumb/dragonage2_2011_03_15_zokr.png (http://www.abload.de/image.php?img=dragonage2_2011_03_15_zokr.png)
http://www.abload.de/thumb/dragonage2_2011_03_15_arg4.png (http://www.abload.de/image.php?img=dragonage2_2011_03_15_arg4.png)

[Coda]

Müsste man in Bewegung sehen.

[LovesuckZ]

Ganze 860MB (http://www.multiupload.com/Q5ODOO70UE) für 19 Sekunden reiner Überwältigung.
Das ganze wurde auf einer GTX580 mit 270.32 und "sehr hoch" aufgenommen. Keine Ahnung, ob AMD User und/oder andere Treiber-User dieses Problem nicht haben.

Das ist das Displacement Mapping, welches weder von MSAA noch AF erfasst wird. Daher sieht das so "kaputt" aus (ähnlich bei Crysis, nur dass das POM hier "rund" ist und nicht so heraussticht wie das DM).

Natürlich kann man MSAA auf Displacement Mapping anwenden, da echte Geometrie darunterliegt. Siehe dazu auch das Sample im DX SDK.
Man kann sich also mal fragen, wieso "Tessellation" in Dragon Age 2 Aliasing einfügt, dass nicht von MSAA behandelt werden kann. Da gekoppelt mit dem Artefaktproblemen scheint es sich hier nicht um echtes Terraintessellation zu handeln, sondern um eine Erzeugung über andere Techniken ala Parallax Occlusion Mapping.

[Coda]

Die Multiupload hat das ganze nur auf megashare.com geladen und da ist es derzeit nicht verfügbar X-D

[LovesuckZ]

Funktioniert dieser Link (http://www2.multiupload.com:800/files/EAE190473C7C40D1E8632AB31C7BF8159D496C465783B6D92ACFEF03BABB12EB9925E2433C51C84D 14588BCE281FE3FB52DAA3D268C27F53998B7BA5504EA695569AD4098581FA822ACD2E248E61AE66 9D/DragonAge2%202011-03-15%2018-51-03-47.avi) nicht?

[Coda]

nö

Edit: Ah doch jetzt

[Coda]

Das sieht tatsächlich so aus als wäre das zusätzliches POM

[y33H@]

Natürlich kann man MSAA auf Displacement Mapping anwenden, da echte Geometrie darunterliegt.Auf Geometrie, ja. Aber wie Coda sagt, da ist noch was anderes dabei, was ich halt mit unter DM laufen ließ - sorry.

[LovesuckZ]

Auf Geometrie, ja. Aber wie Coda sagt, da ist noch was anderes dabei, was ich halt mit unter DM laufen ließ - sorry.

Es gibt anscheinend Tessellation nur an den Kanten der Landschaftsobjekte. Die Objektstruktur wird nicht anhand echter Geometrie und Displacement Mapping realisiert. Deswegen sieht es auf dem Video auch so aus: Es gibt keine zusätzliche Geometrie.

[Liszca]

tessellation hat auch einen anderen nachteil. nämlich den, dass die kollisionsgeometrie nicht mit verändert wird.

wenn dem wirklich so ist, dann brauche ich auch keine tesselation mehr. Vollkommen sinnbefreit das feature ... (wenn dem denn so ist!)

ist dem so?

Kollisionsgeometrie und dargestellte Geometrie sind sowieso nicht identisch. Wäre ja noch blöder, wenn man an jedem reinen Grafikdetail hängenbleibt und mit anderen Grafikdetails sich auch das Gameplay ändert. Die Entkopplung ist schon ohne Displacement Mapping sinnvoll, wobei man bei Bedarf auch in der Physiksimulation mit Displacement arbeiten kann.

[PCGH_Carsten]

I.d.R. ist dem so. Denn die Kollisionsabfrage läuft auf der CPU, die müsste die erzeugten Geometriedaten dann ja von der GPU erstmal bekommen. So funktioniert das (derzeit nohc?) nicht.

[Grey]

Ist doch im Regelfall auch okay, da die Kollisionsabfrage ohnehin i.d.R. weitaus gröber ausfällt als die Darstellung. Wenn das richtig eingesetzt wird, dann passt es auch. Es ist weitaus seltener die Technik das Problem, als deren Umsetzung.

[DanMan]

Ist doch im Regelfall auch okay, da die Kollisionsabfrage ohnehin i.d.R. weitaus gröber ausfällt als die Darstellung. Wenn das richtig eingesetzt wird, dann passt es auch. Es ist weitaus seltener die Technik das Problem, als deren Umsetzung.
Von Balance-Problemen im Multiplayer ganz zu schweigen. Wenn der eine noch den Schuss durchkriegt, weil bei ihm die Tesselation das Hindernis noch weggebogen hat, und beim anderen nicht. Oder man noch irgendwo drüberspringen kann deshalb...

[Dicker Igel]

So kann es sein das die Textur bei der Generieriung verzerrt wird auf einem tessellierten Objekt entzerrt wird.

Wenn man ein "Tessellation LOD" für die "Nähe" macht und ein zusätzliches für die "Ferne" (+ entsprechenden Modellen mit Hi- und Lowrestexturen), sollte sowas imo besser aussehen.
Man bräuchte das zusätzliche LOD auch nicht für die ganze Szene, sondern nur für entsprechende Objekte, die man wegen dem "Geometrieunterschied" nicht in entsprechender Qualität mappen kann.