ZFX + Developia

Moin moin,
wenn man ein Modell Texturieren will muss man ja bei komplexeren Modellen einen UV-Atlas erstellen um die Textur ordentlich auf das Modell mapen zu können. Dabei muss man ja dann "Seams" angeben und das Programm errechnet dann diesen UV-Atlas. Dabei kann es ja dann dazu kommen, dass die Textur gestreckt wird und was-weiß-ich-nicht-noch-alles was später unschön aussieht. Die Texturkoordinaten, die ich jedem Punkt meines Modells übergebe, sind ja nichts anderes als die Koordinaten des Bildpunktes meiner Textur, die ich auf mein Modell mapen will.

Warum erstellt man die Textur für ein Modell nicht nachdem man das Modell fertig hat? Zum besseren Verständniss ein Beispiel.

Wir haben in unserem Editor einen menschlichen Kopf modelliert, nun muss der noch texturiert werden. Nun passiert folgendes:

• 1)der Editor kreiert eine blanke Textur
  2)nun iteriert man durch alle Dreiecke des Polygons, ermittelt die Fläche und weist dem Dreieck genau diese Fläche auf der Textur zu
  3)nun kann man mithilfe eines Malwerkzeuges auf dem Modell herumzeichnen und der Editor färbt die entsprechenden Pixel in der Textur ein

Dadurch müsste man doch eigentlich keine Probleme mehr mit Streckungen der Textur haben und man müsste nicht mehr mit Seams arbeiten. Jedoch ist es schwierig diese Textur für andere Modelle zu verwenden, auch Änderungen an dem Polygon wären schwieriger zu bewerkstelligen.

Was meint ihr dazu? Ich hoffe ich konnte mich irgendwie verständlich ausdrücken, wenn nicht meckert und ich probiere klarer zu formulieren.

Mfg
BS

Hi,

Die Texturfilterung würde an jedem Dreiecksrand hässliche Artefakte produzieren, da die Texturdaten nicht mehr auch räumlich nebeneinander lägen. Aus dem Grund hättest du auch Seams an jeder Dreieckskante (jedes Dreieck ist leicht unterschiedlich rotiert usw).

Beim Lightmapping wird das so ähnlich gemacht (man sucht jeder Fläche einen Platz auf der Textur), darum wirken nicht-rechteckig ausgelegte, komplexe Models damit oft schmutzig. Für Charaktere, Vegetation usw. ist das also weitestgehend unbrauchbar.

Gruß, Ky

Die Texturfilterung würde an jedem Dreiecksrand hässliche Artefakte produzieren, da die Texturdaten nicht mehr auch räumlich nebeneinander lägen. Aus dem Grund hättest du auch Seams an jeder Dreieckskante (jedes Dreieck ist leicht unterschiedlich rotiert usw).

Und was wäre, wenn die eingefärbte Fläche auf der Textur ein wenig größer wäre als die Fläche des Dreiecks, sprich einen eingefärbten Rand von 2 bis 3 Pixeln? Könnte man nicht die Rotation des Dreieckes beibehalten? Vielleicht könnte man somit die Seams am Rande der Dreiecke verhindern?

Mfg
BS

Man müsste dann schon einen Rand von z.B. mindestens 16 Pixeln lassen - allein soweit geht ja schon der anisotropische Filter der Grafikkarte im schlimmsten Fall, und da sind noch keine MipMaps im Spiel. Daher geht man ja auch dazu über, leichte Verzerrungen der Dreiecke hinzunehmen, um so größere zusammenhängende Dreieckshaufen kontinuierlich abbilden zu können. Das reduziert die Menge der sichtbaren Kanten. Um die kann man dann ordentlich Luft lassen.

Der zweite Teil des Problems ist dann, eine vernünftige Zeichenmethode zu implementieren. Wenn Du mal einem Grafiker zugeschaut hast, wie er in Photoshop über eine Textur drüberwirbelt, hast Du einen groben Eindruck davon, was alles an Zeichenwerkzeugen im Editor implementiert werden müsste. Eine sinnvolle Layer-Organisation wäre nötig, und aber-dutzende Manipulationswerkzeuge, globale Bearbeitungsmöglichkeiten wie Farbeinstellungen usw...

Werkzeuge wie ZBrush können das angeblich, aber da fehlt mir die Erfahrung.

BlueShark hat geschrieben:Und was wäre, wenn die eingefärbte Fläche auf der Textur ein wenig größer wäre als die Fläche des Dreiecks, sprich einen eingefärbten Rand von 2 bis 3 Pixeln?

So kann man die Ränder minimieren, rein theoretisch verschenkt man damit aber Bildqualität, weil der Filter mit Fülldaten arbeitet, anstatt echte Texturinformation zu verarbeiten. Wie groß der Verlust dabei ausfällt, kann ich dir nicht sagen – ganz abgesehen davon, dass du eine Menge Texturplatz verschenken musst um die Textur anderer Dreiecke soweit entfernt zu platzieren, dass sie den Filter nicht mehr beeinflussen.

BlueShark hat geschrieben:Könnte man nicht die Rotation des Dreieckes beibehalten? Vielleicht könnte man somit die Seams am Rande der Dreiecke verhindern?

Um die Rotation beizubehalten, muss man alle zusammen liegenden Dreieckskanten gleich ausgerichtet auf die Textur bekommen – dann hat man quasi wieder gemeines UV-Mapping.

Wenn ich darüber nachdenke, komme ich gerade ein bisschen ins Träumen. Ich wollte seit geraumer Weile mal so eine Art "Unified" Editor schreiben. Ausgehend von dem Gedanken des Megatexturings, bei dem wirklich jeder einzelne Pixel in der Landschaft unikat texturiert ist, müsste man doch die gängige Trennung zwischen Geometriebearbeitung und Texturbearbeitung aufheben können... indem man Bearbeitungswerkzeuge anbietet, die gleichzeitig die "Materie" und deren Oberflächenbeschaffenheit bearbeiten. Und der Editor wurschtelt dann intern aus, ob der die Änderungen in Textur oder in Geometrie umsetzt. Man könnte damit zum Beispiel einen Quader ins Land setzen, die Ecken und Kanten abrunden, die Oberfläche mit einem "Putz"-Material überziehen, und dann mit einem "Abkratz"-Werkzeug an einer Stelle wieder den Putz runterpickern und 2cm drunter Ziegelsteine einfügen.

So faszinierend ich die Idee finde, es zeigen sich doch eine Menge Probleme ab, die nach meinem Wissen kein sonstiger Editor lösen muss. Zum einen die schiere Datenmenge - ein Quadratkilometer rein planare Oberfläche würde z.B. 256 GB Speicher fressen, wenn man 1mm Texelgröße annimmt und allein nur Farbe und Normalmap pro Pixel speichert - DXT-Kompression bereits vorausgesetzt. Dann ist da die interne Datenhaltung: wenn der Designer mehrfach über eine Oberfläche im Level drübergeht, um da mal ein Loch reinzustanzen, dort die Kanten abzurunden und am Ende ein Stück Holz reinzustecken, verändern sich permanent Textur und Mesh an der Stelle. Wenn da die Ausgangsdaten nur DXT-komprimiert vorliegen (~5 Bits Genauigkeit) und der Editor dann permanent Texturdetails in Geometriedetails umrechnen muss und umgekehrt, sind die orginalen Daten durch den permanenten Genauigkeitsverlust nach ein paar Bearbeitungen nur noch Matsch. Ein solides Cache-System, das in Bearbeitung befindliche Szenenteile kurzfristig in viel höherer Genauigkeit vorhält, müsste da Abhilfe schaffen, und ist wahrscheinlich schon allein wegen der ganzen internen Beschleunigungsstrukturen notwendig, die man für eine komplexe Geometriebearbeitung so braucht.

Und dann ist da am Ende noch die Bearbeitung selbst, ganz konkret das "Ausrendern" des Designer-Wunsches in eine Kombination aus Geometrie und Texturdetail, so dass die Kombination nachher beim Rendern möglichst genau so aussieht, wie der Designer es wollte. Und die Größenordnungen dieser Bearbeitung ist neu: die gleichen Werkzeuge, die einen Riss in den Asphalt malen oder einen querstehenden Ziegelstein in eine Mauer einfügen, müssen auch Täler aus einem Berg rausschneiden oder einen Hügel aus dem Meer wachsen lassen können.

Klingt nach ner Lebensaufgabe :-)

Bye, Thomas

Ja, über sowas denke ich auch schon seit langer Zeit nach … die Speicherung der Datenmenge ist das geringste Problem, denn bis sich so ein System etabliert hat, sind 64 GiB RAM längst Standard … und dann gibt es noch LoD. Festplatten packen auch heute schon ein TiB. Problematischer ist: Welcher Artist produziert so riesige Datenmengen? Wie komplex müssten die LoD-Algorithmen werden, damit Artists nicht auch noch unterschiedliche Detailstufen produzieren müssen?

Ich habe vor ein paar Monaten mit puren Volumenkörpern experimentiert und werde da wohl auch bald weitermachen … meine Idee war, Materialien kleine Volumentexturen zuzuweisen, die dann als Detailtexturen verwendet würden, das wäre perfekt um Körper aufzubrechen … und sonst alles Mögliche in echter Geometrie umzusetzen, weil die effizienter ist.

Von einem vereinigten Ansatz sind wir – und wären es auch mit Voxeln und Raycasting – aber noch zu weit entfernt, und dass wir mit heutiger, superparalleler Hardware da drankommen, bezweifle ich.

@Schrompf: Klingt irgendwie monumental :o

Wahrscheinlich könnte man meine Idee nur dann umsetzten, wenn man die Texturfilterung abstellt, aber ich glaube das man dennoch das Problem mit dem Seams hätte und gut aussehen würde das ganze sicherlich auch nicht gerade.

Mfg
BS

Stimmt, ohne Texturfilterung könntest du auch gleich hoch tesselieren und Vertices färben anstelle von Pixeln. Sähe mäßig aus und würde fürchterlich flimmern.

Schrompf,
warum die Details in die Daten reinrendern und statisch speichern? Du könntest ausgehend von deiner prozedural oder grob modellierten Welt diese Details zur Laufzeit "bei Bedarf" auf den Daten anwenden.
Also bei deiner Mauer merkst du dir nur den Block (Koordinaten), die Textur bzw die Seeds für ihre Erzeugung mit Perlin z.B., und and der Stelle den Kratzer und an der anderen das Einschussloch. Du wendest also dieselben "Tools" wie der Designer/Grafiker/Modellierer einfach auf den Rohdaten an und zwar nur wenn das ganze sichtbar ist und in der LOD-Stufe die du brauchst.
So ist das ganze viel dynamischer und platzsparender. Das ganze beschreibst du z.B. in XML. So kannst du auch einzelne Effekte Ausblenden je nach Rechenleistung oder sonstigen Szenenbedinungen und du kannst diese auch zur Laufzeit einfügen z.B. wenn ein Fahrzeug die Wand rammt.

Zur Bedienung kannst du dir mal das Google SketchUp ansehen sofern du es noch nicht kennst. Da fand ich waren ein paar sehr nutzerfreundliche (einfache ;) Konzepte dabei.

Gruß
Despotist

Despotist,

Du scheinst davon auszugehen, dass solche Operationen in hinreichendem Tempo umsetzbar sind. Wenn das der Fall ist, kann man diese Art der "iterativen" Speicherung verwenden. Aber mir fehlt da ein bisschen der Glaube. Zumal ja nach der Erzeugung der eigentlichen Szenen-Texturen und -Geometrien noch die Aufbereitung steht - Beschleunigungsstrukturen, Kollisionsmeshes, LOD und nicht zuletzt das indirekte Licht. Und von den Berechnungen *weiß* ich, dass man sie nicht mal so nebenbei nach dem Laden ausführen kann. Bei den eigentlichen Szenenbearbeitungs-Werkzeugen *vermute* ich nur, dass sie zu rechenaufwändig sind, um sie im Ladeprozess verstecken zu können.

1)der Editor kreiert eine blanke Textur
2)nun iteriert man durch alle Dreiecke des Polygons, ermittelt die Fläche und weist dem Dreieck genau diese Fläche auf der Textur zu
3)nun kann man mithilfe eines Malwerkzeuges auf dem Modell herumzeichnen und der Editor färbt die entsprechenden Pixel in der Textur ein

Also was ich bei der ganzen diskussion immer noch nicht so richtig verstehe ist, was da jetzt das neue ist?
Mit Bodypaint kann man auf Modellen malen, mit ZBrush auch und noch dazu eben etwas vom Modell abschaben und Ziegel einsetzten sowie bemalen.
Mit Automatischem Unwrapping kann man für jedes Modell zumindest eine grobe UVW Map automatisch genrieren, deren Flächenverhältnisse bei Bedarf auch gleich sein können (padding ist natürlich auch einstellbar...).

hier findet man ein paar videotutorials die das ganze anschaulicher machen: http://www.pixologic.com/zclassroom/homeroom/ (zbrush)

Hallo,

über so einen einheitlichen Editor hab ich auch schon hin und wieder nachgedacht. Wenn man ein "Replay" der Editor-Funktionen durchführt, kommt man trotzdem nicht drum rum das gesamte Modell zu berechnen. Man kann auch nicht so einfach irgendwelche Aktionen auslassen, denn sie bauen ja potentiell aufeinander auf. Man müsste genau prüfen welche Aktionen keinen Einfluss auf das Endergebnis haben (z.B. aushlöhlen an einer Stelle wo am Ende sowieso nur leerer Raum ist). Es gibt aber genug Aktionen die man nicht los wird. z.B. wenn mit einer art "Paintbruch" Werkzeug eine Oberfläche bearbeitet wird. Dadurch dürfte der Speicher- und Rechenaufwand schnell ins Unerträgliche anwachsen.
Die ganze Sache scheint selbst in relativ kleinem Umfang nicht so einfach lösbar zu sein. Das sieht man z.B. auch am "Sculpt"-Modus von Blender. Dort kann man mit verschiedenen "Brushes" die Vertices durch die Gegend schubsen. Allerdings wird dabei die Topologie nicht angepasst. Dadurch passiert es bei größeren Veränderungen schnell das sich die Flächen derart strecken das man nicht mehr normal arbeiten kann. Das ist aus meiner Sicht das Hauptproblem dieses Tools.
Ein Ansatz der vollkommen aus der anderen Richtung kommt sind die Voxel. Die haben den Vorteil das man halt wirklich mit einem Volumen statt mit expliziten Polygon-Oberflächen arbeiten kann. An sich sind solche Voxel-Würfel eher unspektakulär weil sie eine misserable Detailausbeute für ihren Speicherbedarf haben und auch erst in Polygon-Objekte umgerechnet werden müssen damit man sie per GPU darstellen kann. Allerdings finde ich das Sauerbraten zeigt das man doch eine ganze Menge damit machen kann. Dort sind die Voxel in einem Octree organisiert und können verschiedene Auflösungen haben. Außerdem lassen sich die Seiten der einzelnen Würfel abschrägen, wodurch die zugrundeliegende Octreestruktur bis zur Unkenntlichkeit verschleiert werden kann.
Die Maps können in einem relativ einfach gestrickten ingame Editor-Modus erstellt werden. In dem ist man zwar gezwungen auf Würfelebene zu arbeiten, aber man könnte auf der Grundidee aufbauend versuchen etwas wie Sculpting zu implementieren.

BlueShark hat geschrieben:Könnte man nicht die Rotation des Dreieckes beibehalten?

Nein, versuch mal einen Tetraeder manuell zu mappen: man kann unmöglich sämtliche aneinanderstoßenden Kanten parallel halten ohne die Dreiecke zu verzerren.

Nicht das Rad neu erfinden: ZBrush hat wie bereits erwähnt wirklich schon die meisten der hier besprochenen Features eingebaut. Ein paar Beispiele:
- Das Projection-Manager-Tool ist eigentlich eine interne 2.5D-Voxel-Engine (interner Begriff für Voxel ist hier "Pixol"), die nach der Bearbeitung das Pixel-Sculpting auf das Mesh zurück überträgt. Natürlich gibt es auch die reinen Mesh-Sculpting-Tools, es ist nicht die komplette Philosophie des Programms (war es aber ursprünglich soviel ich weiß).
- Interner 3D-Painting-Editor vs. unschlagbare Photoshop-Tools - das löst Z-Brush folgendermaßen: per Befehl kann man in Photoshop wechseln, wo die aktuelle Ansicht in Ebenen aufgebaut ist (Licht extra, Farbe extra). Auf der Farbebene kann man in PSD beliebig rummalen, nach dem Schließen wird die PSD-Farbebene zurück auf die Textur projiziert.
- Automatische Texturerstellung wie eingangs angedacht gibts auch: da es ein Subdivision-Modeler ist, basiert das aber auf Quads statt Dreiecken. Es gibt eine Option mit und ohne Clustering.
- Retopology ist seit der letzten Version immerhin als manueller Ansatz drin, ich hoffe das wird mit (halb-)automatischen Werkzeugen noch weiterentwickelt. Absolute Kontrolle über hochaufgelöste Topologie hat man im Moment leider nur, wenn man das Basemesh richtig plant und nicht gerade beliebig wild modelliert ;-) hier wäre noch Potential für neue Ideen und Tools für intuitiveres Arbeiten.