Truform (N-Patch) was ATi nicht gerne zugibt

[Demirug]

Der Titel ist zugegebenermaßen etwas provokativ aber viele Radeon Besitzer dürften sich inzwischen wunder was aus dem von ATi großartig angekündigten Truform Support in Spielen geworden ist. Viele Spiele verzichten darauf und dort wo es Support gibt ist er meistens nicht sehr berauschend. ATi hat in ihren Dokumenten vergessen eindringlich darauf hinzuweisen das doch mehr als nur das einschalten von Truform notwendig ist damit die Grafik damit besser wird.

Ich habe mir erlaubt ein Beispiel für den gutgemeinten Einsatz von Truform zu rendern (DX Referenzrenderer). Ein Zylinder den man zum Beispiel für einen Autoreifen benutzten könnte. Das Ergebnis ist jedoch nicht so wie man es gerne hätte. Das T über den Spalten gibt die Tesselationsstufe an. Die fehlenden Teile sind in der zweiten Reihe rot markiert.

[Ganon]

Kann man das gelbe denn nicht "krümmen"?

[ow]

Nein, Ganon, kann man nicht. Zumindest nicht in der notwendigen Form.

Du kannst die gelbe Flaeche hoechstens nach aussen woelben, das schliesst aber die Luecken nicht.

[AlfredENeumann]

Erklärt mir mal bitte warum man nicht inder Lage sein soll das "gelbe" in die passende Form zu bringen ?

[ow]

Weil die gelbe Flaeche senkrecht auf der gruenen steht.

Und da Truform nicht anderes tut, als zwischen den Eckpunktsnormalen zu interpolieren kriegst du diese Luecken nicht ausgefuellt.

[Unregistered]

Man kann aber kleine (fast oder ganz unsichtbare) Dreiecke an dem Übergang zwischen gelb und grün einmodellieren und völlig auf Smoothinggroups verzichten. Dann kann man auf beiden Teilen des Meshes Trueform aktivieren und diese Übergangstris sorgen dafür, daß es keine Cracks gibt.

Pitchfork

[Demirug]

Ich könnte die Fläche schon entsprechend verformen. Dabei würde ich mir aber die Normalen ruinieren und könnte mir dann eine korrekte dynamische Beleuchtung in die Harre schmieren.

Das ganze würde dann zwar als ebene Fläche gerendert aber wie eine nach aussen gewölbte beleuchted.

[Demirug]

Originally posted by Unregistered
Man kann aber kleine (fast oder ganz unsichtbare) Dreiecke an dem Übergang zwischen gelb und grün einmodellieren und völlig auf Smoothinggroups verzichten. Dann kann man auf beiden Teilen des Meshes Trueform aktivieren und diese Übergangstris sorgen dafür, daß es keine Cracks gibt.

Pitchfork

Natürlich könnte man Übergangtris einmodellieren. Ich möchte dabei aber folgendes zu bedenken geben:

1. ATi spricht immer von minimalen Änderungen an der Geometrie in Verbindnung mit Truform. Das ist so einfach nicht richtig.

2. Die Übergänge sind abhängig von der gewählten Tesselationsstufe. Man muss also für jede Stufe die man verwenden will einen neuen Satz dieser Tris erstellen.

Das Hauptproblem ist das auch DM auf N-Patch zur Tesselation setzt und damit auch alle diese Einschrängungen mitbekommen hat. IMO hätte man bei N-Patch mit zwei normalen pro Vertex arbeiten sollen. Eine für die Beleuchtung (und Bumpmapping) und eine für die Verformung. Dann wären die meisten Schwierigkeiten gar nicht aufgetaucht.

[RadioactiveMan]

@ Demirug

Ich denke man sollte den Schuldigen eher bei der Marketingabteilung suchen, denn bei den Dev Support.

ATI hat IMHO exzellente Papers zu N-Patches/PN Triangles veröffentlicht http://www.ati.com/developer/sdk/Npatch/npatchresource.html
in dem Paper Curved PN Triangles wird etwa auch auf Seite 8 auf mögliche Probleme hingewiesen.

Matrox hat übrigens auch ein nettes Paper zu DM gemacht, http://developer.matrox.com/details.cfm?CFID=224878&CFTOKEN=93413141&s=docs&i=36 dort werden im Gegensatz zu den Marketingzeug auch Schattenseiten und Inkompatiblitäten der Technologie aufgezeigt.

Ich finde es ziemlich dumm, wie heutzutage derartige Features für Vermarktungszwecke mißbraucht werden, die meisten Spieleentwickler empfinden es eh als Übel solche Funktionen zu unterstützen, welche meistens noch zahlreiche Restriktionen besitzen.

IMHO sollten sich die 3D Architekten universell einsetzbare Lösungen ausdenken und nicht solche zusammengeschusterte Bullet Point Features, die sich allenfalls bei Präsentationen gut machen.

[Demirug]

@RadioactiveMan:

Wo hab ich den den Dev Support von ATi als schuldig hingestellt?

Ich muss sowieso eher die Geschichten der Marketingabteilung ausbaden. Denn wenn dort erzählt wird das man einen Trufrom support in 5 Minuten in jede Engine eingebaut hat muss ich mir 10 Minuten später die Frage gefallen lassen warum wir noch keinen Truform support haben. (Leicht überspitzt :D)

Die Dokumente kenne ich. Aber sowas bekommen in der Regel ja nur die Personen aus der Technik zu Gesicht. Matrox ist aber wesentlicher ehrlicher wenn es um die Nachteile und Probleme von DM geht als es ATi IMO bisher bei Truform war.

Features die irgendwelchen einschrängungen unterliegen sind immer schlecht. Aber in der Regel führt der Weg nach vorne nur über solche zwischenschritte.

So wäre eine frei Programmierbare tesselationseinheit besser als die ganzen derzeit verfügbaren HOS Techniken. Aber auch das wäre nur ein zwischenschritt zu einer frei programmierbaren Geometrieerzeugungseinheit.

Genauso ist DM nur ein halbfertiges feature. Viel sinnvoller wäre es wenn man im VS eine TMU zur verfügung hätte und dann das DM (oder anderes) selbst machen könnte.

Der P10 geht ja ansatzweise in diese Richtung aber OpenGL 2.0 geht noch nicht weit genung.

[Unregistered]

Originally posted by Demirug
1. ATi spricht immer von minimalen Änderungen an der Geometrie in Verbindnung mit Truform. Das ist so einfach nicht richtig.


Die Veränderungen sind relativ harmlos. In Max handelt es sich um denselben Vertex, der durch Smoothinggroups beim Engineexport verdoppelt wird. Wenn man nun anstelle der Verdoppelns die Degenerate Quads einbaut, stimmen die Normalen ebenfalls und der Mesh ist zusätzlich NPatch tauglich.... läßt sich locker automatisieren. Vorausgesetzt, die Grafiker setzen halt ausschließlich Smoothinggroups für solche Übergänge ein (oder direkt diese kleinen Übergangsquads).

Originally posted by Demirug
2. Die Übergänge sind abhängig von der gewählten Tesselationsstufe. Man muss also für jede Stufe die man verwenden will einen neuen Satz dieser Tris erstellen.

Da die Viehcher ja mittesseliert werden, gibt es überhaupt keine Probleme und man kann beliebig weit aufpumpen.

Pitchfork

[Demirug]

Pitchfork:

Die Quads taugen nur dazu die Löcher dicht zu bekommen. Die Normalen die dabei rauskommen sind aber leider nicht zu gebrauchen. Von den Texturekoordinaten will ich gar nicht reden.

[aths]

Originally posted by Demirug
Matrox ist aber wesentlicher ehrlicher wenn es um die Nachteile und Probleme von DM geht als es ATi IMO bisher bei Truform war.Soweit ich das verstanden habe, fährt ATI bei Truform zweigleisig. Dem Entwickler muten sie mehr oder weniger die Wahrheit zu, dem potenziellem Kunden zeigen sie ihren Truform-Delfin und versprechen, dass das Feature bald breit genutzt würde. Ich sehe (nicht zuletzt durch deine Tätigkeit im Forum) inzwischen keine breite Anwendungsmöglichkeit von Truform mehr, denke aber doch, dass es in bestimmten Fällen mit sehr wenig Aufwand gute Ergebnisse liefert. (Jedenfalls hätte ich in meinem "Metall-Demo" (www.aths.net/files/metall2.exe) sowas wie Truform gewüscht.)

[Demirug]

@aths:

Eigentlich fahren alle zweigleisig. Nur gibt es dar vorallem in den Developerbereichen kleine aber feine unterschiede. Wenn ich dar zum Beispiel die ATi Präsentation (für Entwickler) zu Truform sehe da wird eigentlich nur von Vorteilen gesprochen. Dagegen gehen die Shadowbuffers Folien von NVidia ganz klar (in Wort und Bild) auf die Nachteile und Probleme ein.

Truform funktioniert dann immer noch brauchbar wenn man man keine harten Kanten braucht. Allerdings wird die Verwendung von Bumpmapping leider auch eingeschränkt. Für beide Problem gäbe es Lösungen aber scheinbar keine bestrebung etwas zu tuen.

[Unregistered]

Originally posted by Demirug
Pitchfork:

Die Quads taugen nur dazu die Löcher dicht zu bekommen. Die Normalen die dabei rauskommen sind aber leider nicht zu gebrauchen. Von den Texturekoordinaten will ich gar nicht reden.

Betrachten wir mal den einfachen Fall eines Hausdachgiebels. Bisheriges Modelling: Jede Dachhälfte wird als großes Quad modelliert und in zwei verschiedene Smoothing Groups eingetragen. Beim Import in die Engine werden die Vertices des Giebels dupliziert (damit sie nicht mehr die gleichen Normalen haben), das führt zu einer (erwünschten) scharfen Kante in der Beleuchtung des Meshes. Beim NPatching werden nun die Vertices auseinandergezogen und es entstehen die Cracks.

Korrekte Lösung im Hinblick auf DispMapping und NPatching: 2cm unterhalb des Giebels werden auf jeder Dachseite Vertices eingefügt, so daß das Dach aus insgesamt vier Flächen besteht:

1. Hauptteil links
2. 2cm bis zum Giebel links
3. 2cm bis zum Giebel rechts
4. Hauptteil rechts

Es werden alle Flächen in derselben Smoothinggroup aufgenommen.

Wie sehen jetzt die Normalen aus? Wichtig ist dabei zu beachten, daß Normalen üblicherweise so berechnet werden:

1. Von jedem Dreieck wird die Normale berechnet und abgespeichert.
2. Die fürs Rendern wichtige Normale des Vertex ist einfach der Durchschnitt der Normalen der angrenzenden Dreiecke (evtl. nach Fläche der Dreiecke gewichtet).

Unser Giebel hat jetzt also 10 Vertices und 8 Dreiecke.

Die vier Normalen an den Vertices der rechten und linken Unterkante zeigen senkrecht zur Dachfläche nach aussen.

Die vier Normalen an den Vertices 2cm links und rechts unterhalb des Giebels zeigen ebenfall senkrecht nach aussen.

Die zwei Normalen der Vertices des Giebels zeigen senkrecht nach oben.


Was passiert nun beim NPatching? Bei den großen Dachflächen gar nichts, weil ja die normelen aller angrenzenden Vertices senkrecht zur Fläche zeigen. Die kurzen Giebelstücke werden allerdings schön rund gebogen.

Kleiner Trick große Wirkung:

- unser Dach wird nicht zur Tonne
- unsere Beleuchtung bleibt korrekt
- und wir haben eine (falsche) scharfe Kante durchs NPatching schön rund gemacht.

Nachteil:

- ein paar Vertices mehr, aber durch die Smoothinggroups werden ja eh die Giebelvertices dupliziert, so daß das nicht wirklich ins Gewicht fällt.

Das ganze läßt sich auch automatisieren, solange keine Diskontinuitäten bei den Texturen existieren, ansonsten gibt es dort ein paar falsche Texel.


Das Verfahren funktioniert genauso beim Autoreifen!


Pitchfork

[Pussycat]

Pitchfork, könntest du dass mal zeichnen?

[Unregistered]

Originally posted by Pussycat
Pitchfork, könntest du dass mal zeichnen?

Ich wußte, daß die Frage kommt *bg*

Ich kanns ja mal versuchen.

Pitchfork

[Demirug]

@Pitchfork:

Was du hier beschreibst ist ein 3d-Model Kantenweichzeichner. Danach hatte man ja eines der von mir als mit Truform kompatible eingestufften Models ohne harte Kanten.

Wenn die dabei entstehenden Kantentris im verhältniss zu den restlichen tris sehr klein sind geht das ja auch ganz gut. Bei einem Reifen oder Fass werden die Kantetris aber beim NPatching stark verformt was sich nicht sehr schön auf die texturierung auswirkt. Aber auch das läst sich unter kontrolle bekommen wenn man dem Grundmodel eben mehr tris spendiert. Was aber mit N-Patch und HOS im allgemeinen nicht gut harmoniert ist Bumpmapping.

Ich bezweifle ja auch gar nicht das man jedes Model irgendwie N-Patch fähig bekommt. Ich bezweifle nur das man diesen Prozess weitgehend automatisieren kann. Es gibt einfach zu viele kombinationen die man berücksichtigen müsste. Die Tatsache das ATi bis heute dafür noch kein Tool zur verfügung stellt spricht IMO ebenfalls Bände.

Ich hoffe aber das sich die Technik noch weiterentwickelt. IMO wäre es eine sehr schöne Sache wenn man die gleiche Höhentextur zum einen für das DM und dann im Fragmentshader als Bumpmap einsetzten könnte. Wobei im Fragmentshader natürlich dann die durch das DM bereits durchgeführte Model veränderungen berücksichtigt wird.

[Unregistered]

Originally posted by Demirug
@Pitchfork:

Ich bezweifle ja auch gar nicht das man jedes Model irgendwie N-Patch fähig bekommt. Ich bezweifle nur das man diesen Prozess weitgehend automatisieren kann. Es gibt einfach zu viele kombinationen die man berücksichtigen müsste. Die Tatsache das ATi bis heute dafür noch kein Tool zur verfügung stellt spricht IMO ebenfalls Bände.


Es gibt doch von ATI die Trueform Exporter und Viewport Plugins für 3ds max. Habe sie selber noch nicht ausprobiert (kein Max), aber laut Beschreibung erfüllen die alle Anforderungen, die nötig sind.


Wg. der Doppeltnutzung von Normalmaps und Displacement Maps bin ich zur Zeit recht skeptisch, weil die Auflösung doch sehr unterschiedlich ist. Die eine Map verlangt eine Pixelgenaue Auflösung, während die andere eher bei 5cm liegt. Auch die Amplitude ist unterschiedlich... naja, hier ist einfach ein wenig Research nötig, um Erfahrungswerte zu sammeln.

Pitchfork

[Demirug]

@Pitchfork:

Den Exporter kenne ich. Hab mich da mal extra durch den Quellcode gewühlt um raus zu bekommen was er macht. Er wählt das einfachste Verfahren. In dem Fall mit dem Dach würde er einfach einen zusätzlichen Quad einfügen welcher die beiden oberen Endpunkte der einen Dachseite mit den Endpunkten der anderen verbindet.

Wobei mir gerade noch aufgefallen ist das in deinem Dachbeispiel ja Truform eigentlich überhaupt nicht zum tragen kommen dürfte da alle Normalen einer dachseite gleich sind. Oder hast du dir das anders gedacht?

Ein Problem entsteht ja eigentlich nur dort wo eine abzurundende Fläche auf eine harte Kante trift.

[Pitchfork]

Originally posted by Demirug
@Pitchfork:

Den Exporter kenne ich. Hab mich da mal extra durch den Quellcode gewühlt um raus zu bekommen was er macht. Er wählt das einfachste Verfahren. In dem Fall mit dem Dach würde er einfach einen zusätzlichen Quad einfügen welcher die beiden oberen Endpunkte der einen Dachseite mit den Endpunkten der anderen verbindet.

Wobei mir gerade noch aufgefallen ist das in deinem Dachbeispiel ja Truform eigentlich überhaupt nicht zum tragen kommen dürfte da alle Normalen einer dachseite gleich sind. Oder hast du dir das anders gedacht?

Ein Problem entsteht ja eigentlich nur dort wo eine abzurundende Fläche auf eine harte Kante trift.

Logisch ist es fast völlig überflüssig ein Dach zu NPatchen. Aber eine Fortführung des Beispiels wäre eine Axt, die ja eine scharfe Kante hat (den Giebel) und gerundete Flächen (die Flachseiten mit leichter Wölbung). Und hier funktioniert das Verfahren wie erwünscht.


Btw, was jetzt hier etwas untergeht:

ATI hat von minimalen Anpassungen der Assets gesprochen, um sie Trueformfähig zu machen, was wir hier diskutieren sind tatsächlich minimale Anpassungen bzw. einfache Regeln, die -wenn im Vorfeld beachtet - keinen zusätzlichen Aufwand bedeuten. Diese Aussage ist IMO aber auch in Relation zu setzen zu den HO Surfaces von nVidia, wo bis heute nicht klar ist, wie sich hier die Artpipeline vom Modeller in die Engine gestaltet haben könnte... naja, das Thema HO a la NV ist ja vorerst abgeschlossen aber andere Methoden als NPatches werden bestimmt wieder aufkommen in Zukunft.

Pitchfork

[Demirug]

@Pitchfork:

Ich glaube du hast das Zauberwort im Zusammenhang mit allen Arten von HOS gefunden: Vorfeld

Wenn jetzt noch die Modeller das ganze besser unterstützen würde wären wir einen Schritt weiter.

Allerdings habe ich immer noch keine Lösung für das Bumpmapping Problem gefunden. Aber das könnte sich mit DM ja vielleicht in wohlgefallen auflösen. Das hängt aber wohl davon ab wie detailiert man ohne performanceneinbrüche tesselasieren können wird.

[tb]

Bisher sind fast alle Ansätze von HOS doch mehr, oder weniger unbrauchbar (meiner Meinung nach). NVIDIA's RT-Patches waren ein Flop, ATi's N-Patches aka. Truform wird auch nicht lange leben, bzw. großartig angewendet, einfach weil sie mehr Probleme als Nutzen bringen. Matrox Displacement Mapping + Adaptive Tesselation ist bisher der einzige wirklich vielversprechende Ansatz, bleibt nur zu hoffen, dass diese Technik in anderen GPU's auch eingebaut wird.

Gruß
Thomas

[Demirug]

@Thomas:

Ja die ganze HOS Techniken leiden entweder an mangelder Kontrolle über die Tesselation (N-Patch) oder sie sind inkompatible zum bisherigen System (RT-Patch).

Bei Displacement Mapping habe ich inzwischen auch etwas Zweifel bekommen da es ja in der Basis auf N-Patch aufbaut. Die Linear Variante könnte aber bei Terrainrendere durchaus was bringen.

was ich von Adaptive Tesselation halten soll ist mir noch nicht ganz klar da die Programmierbarkeit und Flexibilität dieser Technik aufgrund der Vorliegenden Dokumenten noch nicht ganz klar ist.

Alles in allem ist die ganze HOS Geschichte einfach IMO noch zu unflexibel.

[Frank]

Gibts ein paar gute Links über RT- und N- Patches ? Würde das mal gern einordnen in meine CAGD Bibel (Farin) - dort leben die aber noch im Jahr 94. :(

[Fanatic_Ice]

Braucht man auch diesen NPatch für kommende Radeon 9500 Pro- Karten?

[Xmas]

Originally posted by Fanatic_Ice
Braucht man auch diesen NPatch für kommende Radeon 9500 Pro- Karten?
N-Patches (auch "PN-Triangles" genannt) sind gekrümmte Oberflächen, kein Software-Update das Fehler behebt (auch "Patch" genannt).

[Frank]

Ok also zu n-Patch (oder PN - Triangles) hab ich jetzt etwas gefunden. Klingt zwar noch alles etwas kryptisch, scheint aber an Bézierdreiecke angelehnt zu sein. ??? RT-Patches.... *such*

???


edit:
kann es sein, dass es kaum Quellen gibt??

[Frank]

aahhhhhh ja

[Demirug]

Ja Frank, dazu findet man recht wenig im Web. Habe mir damals als DX8 rauskam beide Sachen angeschaut. Gefallen hat mir beides nicht so richtig. Und das Thema RT-Patch hat sich ja wohl wieder mal für eine Runde erledigt.

[Frank]

hmmm - muss man sich also wenndan selber drum kümmmern. Ich red mal mit meinen Prof (CAGD).

[Frank]

...hat mir gleich das Projekt übertragen, zweifelte aber auch den allgemeinen praktischen Nutzen dieser neuen Features an. Heute zählt eben nicht mehr so sehr ein optimierter Algorithmus, den sich Mathematiker ausdenken, als vielmehr die Ingeneursleistung, immer mehr Rohpower anzubieten.

naja mal sehn
*anfang*

[Demirug]

Frank,

habe was gefunden was dir möglicherweise weiterhilft:

http://www.hinjang.com/gfx01.htm
http://www.hinjang.com/gfx02.htm

[Frank]

Danke :)


*durchles*