UV Unwrapping / Mesh Unwrapping (solved)

[starvald]

Hallo allerseits!

Ich bin auf der Suche nach einem Algorithmus, der eine beliebig Geometrie (Triangulation) als Eingabe erhält, und der mir als Ausgabe eine 2D Textur bzw. einen Textur-Atlas mit den "aufgefallteten" (u,v)-Koordinaten ausspuckt. Die Eingabegeometrie ist konkav, kann also nicht auf eine einfachere Geometrie wie eine Kugel projiziert werden.

UV Unwrapping haben die meisten von Euch wahrscheinlich schonmal im Kontext des Skin-Rendering gesehen, wo das Gesicht dann so aufgefaltet wird, um dann eine Blur auf dieser Textur auszuführen.

Ich kenne mich in dem Bereich nicht sehr gut aus, habe aber gelesen, dass es Verfahren gibt, die auf möglichst geschickt platzierten Slices basieren. Ich habe aber auch gehört, dass es Brute-Force Verfahren gibt, die diese Slices nicht benötigen, aber dafür einen sehr un-optimierten Textur-Atlas erzeugen. Das würde mir genügen.

Über Literatur oder gar (Pseudo-)Code würde ich mich sehr freuen!

Viele Grüße,
Nicolas

[dot]

Wofür musst du das denn selbst implementieren? Ich denk, das richtig gut hinzubekommen, erfordert ziemlich komplexe Optimierungsverfahren. Kannst du nicht einfach ein fertiges Tool dafür verwenden!?

[starvald]

Hi,

das könnte ich natürlich auch - der Vorgang müsste aber innerhalb eines Softwareproduktes ausgeführt werden. Ich wäre also auf eine freie Bibliothek angewiesen! Deshalb wäre ein Brute Force Algorithmus ja so klasse... :-)

[dot]

Ich kenn leider keine entsprechende Library, es gab mal was in D3DX. Blender ist OpenSource und enthält entsprechende Funktionalität.

[Schrompf]

Schau vielleicht mal nach LightMapping-Bibliotheken und -tutorials. Die müssen doch exakt dasselbe machen: beliebige Mengen Geometrie möglichst zusammenhängend und verzerrungsarm auf einer Textur unterbringen.

[waigie]

Angel Based Flattening schaut recht einfach aus, aber ich weiß nicht ob die Ergebnisse dir reichen würden.

Blender verwendet meiner Meinung nach Least Squares Conformal Maps, ein Paper dazu findet sich hier: http://alice.loria.fr/index.php/publica ... =lscm@2002

[eXile]

Es gibt schon Dutzende Verfahren zur Geometrieabwicklung. Ein großes Gebiet sind die least-squares-conformal-maps-Methoden, welche halt konforme Abbildungen generieren. Als externes Programm könnte man z.B. Graphite nehmen, welches eine solche LSCM-Abbildung generieren kann (siehe hier). Eine andere Gruppe sind z.B. die signal-specialized-parametrization-Verfahren, die auch von UVAtlas im Direct3D-9-SDK verwendet werden, und von Hugues Hoppe mitentwickelt wurden.

Lightmapping baut in der Regel eher auf abwickelbarer (d.h. Geometrie mit Gauss-Krümmung 0) und leicht slice-barer Geometrie auf, von daher sind die meisten Lightmapping-Abwickler nicht für arbiträre Geometrie einsetzbar.

Nachtrag: Wie waigie schon kurz vor meinem Beitrag gesagt hat: Der Bruno Lévy hat da viel gemacht; und Blender benutzt eine LSCM-Methode ;)

[starvald]

Habe eine Lösung gefunden: DirectX bietet die Methode "D3DXUVAtlasPartition( )" an. Außerdem gibt es im DirectX SDK ein Projekt, welches beliebige .x Dateien in Atlanten umwandelt. Allerdings bin ich jetzt auf ein neues Problem gestossen: Wenn man sich den folgenden Atlas einmal anschaut:

Dann sieht man, dass durch die Parametrisierung viele kleinere Segmente entstanden sind. Bei der Texture-Space Diffusion wird ja ein Gauss-Blur auf dem Atlas ausgeführt. Dieser simuliert die Energie-Integration über einen lokalen Oberflächenbereich (anders als z.B. bei den Translucent Shadow Maps). Das Problem: Über die Segmentkanten hinaus kann man nicht integrieren. Das heisst, je mehr Komponenten die Parametrisierung erzeugt, desto mehr Fehler macht man bei der Oberflächenintegration. Oder sehe ich das falsch?

Vielleicht ist das der Grund, warum man bei Texture Space Diffusion bisher immer nur diese perfekt aufgeklappten Gesichter gesehen hat...habe den Ansatz noch nie bei beliebigen oder dynamischen Triangulationen gesehen. Wobei das Verfahren ja auch für menschliche Haut gedacht ist...

Gruß,
Nico

Edit: Hier sieht man mal das Standardbeispiel für Texture Space Diffusion

[eXile]

Macht man dabei die Diffusion als Vorverarbeitungsschritt oder beim Rendern?

Bei ersterem kann man sehr wohl den korrekten Nachbarschaftsgraphen der Pixel berechnen.
Bei letzterem kann man einen evil Hack machen, und einfach mal die Textur via Dilation einfach an den Kanten des Atlas nach außen dilaten. Das ist halt einfach ein Dilate in größe des Gauss-Radius; das gibt natürlich dann auch kein korrektes Resultat, aber immer noch besser, als einfach schwarz zu samplen.

[starvald]

Hi eXile,

den Atlas muss man bei jeder Änderung der Lichtposition(en) rendern, da dot(N,L) + Farbe berechnet wird (Spekularer Anteil wird nicht geblurred). Daher kann man nicht vorberechnen!

AddressU/V=Mirror im PS bringt nix: Den Fehler macht man an allen Kanten aller weißen Flächen, die Du auf dem obigen Bild siehst. Nicht nur an den Kanten der Textur.

Wie alles im Screen- oder Texture Space (Szene-abhängiges Parameter Tuning bei SSAO lässt grüßen), ist Texture Space Diffusion offenbar einfach le fuck, wenn man nicht eine zusammenhängende Komponente erzeugen kann. Das wird man wohl durch kein Tool erreichen, sondern nur durch manuelle und sorgfältige Parametrisierung einer Triangulation.

Computergraphik wäre so schön, wenn die Realität einem nicht immer dazwischenfunken würde...

[dot]

Mir ist noch nicht ganz klar, warum du die Parametrisierung nicht mit einem vorhandenen Tool machen kannst. Dass du gerade selbst an einem Modelling-Tool schreibst halt ich mal für eher unwahrscheinlich, wenn du da mit solchen Techniken ankommst!?

[starvald]

Hi Dot,

Ich kann die Parametrisierung nicht manuell ausführen, da in meinerCAD Software die Modelle unterschiedlichste Geometrien besitzen und darüber hinaus durch Tools dynamisch veränderbar sind (ganz konkret handelt es sich um Zähne). Das ist der Unterschied zu einem Computerspiel, wo man ein und dasselbe Modell immer und immer wieder benutzt und die Parametrisierung vorher einmal berechnen und abspeichern könnte.

-Nicolas

[eXile]

AddressU/V=Mirror im PS bringt nix: Den Fehler macht man an allen Kanten aller weißen Flächen, die Du auf dem obigen Bild siehst. Nicht nur an den Kanten der Textur.

Du hast mich falsch verstanden: Man muss in der Textur dilaten. Und zwar an allen gelben Kanten oben, nach außen (ins Schwarze hinein). Dazu muss man natürlich erstmal genug Platz zwischen den Patches schaffen. Sowas meinte ich. Ist aber natürlich ein Hack.

Aber das ist ja ein allgemeines Problem: Wie werden eigentlich Mip-Maps zu einem Texturatlas berechnet?! Für Cubemaps als Preprocessing ist das ja schon gelöst; ich könnte mir aber denken, dass für allgemeine Texturatlanten da auch schon jemand mal Mip-Maps korrekt berechnet hat. Das ist ja de-facto das gleiche Problem.

Und jetzt sagt nicht, dass man einfach genug Padding zwischen die Cluster im Atlas haut, damit es bei der Mip-Map-Generierung keine Artefakte gibt.

[starvald]

Ich würde sagen man haut einfach genug Padding zwischen die Cluster... Upsa!

Der Platz zwischen den Clustern müsste sich ja aus 2^(MipMapLevels) Pixeln ergeben. Das artet natürlich irgendwann ins Lächerliche aus, wenn man zwischen den Clustern 256 Pixel Platz lassen müsste.

Gute Frage!! :oops: *wirftgooglean*

Edit: Habs gefunden:

Truth is that the tool-chain generates the mip-maps for individual textures before these are packed into an atlas. To obtain the highest fidelity results, a specialpurpose mip-map filter should be used (such as NVIDIA’s texture tools [TextureTools2000]).

Es wird also nicht der gesamte Atlas gemipmapped, sondern die einzelnen Komponenten. Der Atlas wird dann in jedem Schritt neu erzeugt.

[eXile]

Ich habe noch einmal über das Problem nachgedacht. Der wohl richtige Schritt wäre es, einfach bestimmte Texel im Texturatlas an den Rändern der Cluster zweifach oder noch-mehr-fach zu speichern, so circa wie hier (lass dich nicht durch die unterschiedlichen Auflösungen stören; das ist jetzt nicht der Punkt). Das heißt, an diesen Stellen außerhalb des Randes jedes Clusters gibt es texturierte Texel, obwohl die UV-Abwicklung dort niemals hinkommt.

Kurzum: Wenn man irgendwelche Diffusions-Verfahren im Texture-Space implementieren will, kommt man nicht um einen eigenen Atlas-Generator rum.

[eXile]

Dealing with Seams

Texture seams can create problems for texture-space diffusion, because connected regions on the mesh are disconnected in texture space and cannot easily diffuse light between them. Empty regions of texture space will blur onto the mesh along each seam edge, causing artifacts when the convolved irradiance textures are applied back onto the mesh during rendering.

An easy solution is to use a map or alpha value to detect when the irradiance textures are being accessed in a region near a seam (or even in empty space). When this is detected, the subsurface scattering is turned off and the diffuse reflectance is replaced with an equivalent local-light calculation. A lerp makes this transition smooth by blending between scattered diffuse light and nonscattered diffuse light (the alpha map is pre-blurred to get a smooth lerp value). Also, painting the stretch textures to be black along all seam edges causes the convolution kernels to not blur at all in those regions, reducing the distance from the seam edges at which the scattering needs to be turned off. This solution creates hard, dry-looking skin everywhere the object contains a seam, and may be noticeable, but it worked well for the NVIDIA "Froggy" and "Adrianne" demos. For the head models shown in this chapter the UV mappings fill the entire texture space, so none of these techniques are required. Objectionable seams are visible only under very specific lighting setups.

A more complicated solution involves duplicating certain polygons of the mesh for the irradiance texture computation. If there is sufficient space, all polygons that lie against seam-edges are duplicated and placed to fill up the empty texture space along seam edges. If light never scatters farther than the thickness of these extra polygons, then empty space will never diffuse onto accessed texels and light will properly scatter across seam edges. These extra polygons are rendered only in the irradiance texture pass and not in the final render pass. The duplicated polygons may need to overlap in a small number of places in the texture, but this should not create significant artifacts. We expect this technique would provide a good solution for many meshes, but have not tried it ourselves.

A more general solution is to find many overlapping parameterizations of the surface such that every point is a safe distance away from seam edges in at least one texture. The irradiance texture computation and convolution passes are duplicated for each parameterization (or many parameterizations are stored in the same texture) and a partition of unity—a set of weights, one for each parameterization—blends between the different sets of textures at every location on the surface. This "turns off" bad texture coordinates in locations where seam edges are near and "turns on" good ones. These weights should sum to 1.0 everywhere and vary smoothly over the surface. For each surface location, all weights that are nonzero should correspond to texture parameterizations that are a safe distance away from seam edges. Techniques for computing such parameterizations and their respective partitions of unity can be found in Piponi and Borshukov 2000. Given a partition of unity, the entire texture-space diffusion algorithm is run for each parameterization and the results are blended using the partition weights. This requires a considerable amount of extra shading and texture memory and is comparatively expensive, but probably still outperforms other subsurface-scattering implementations.

Kennt ihr es, wenn ihr die ganze Zeit ein Bild vor Augen habt, das ihr vor sieben Jahren mal gesehen habt, und noch genau wisst, wie es aussieht, aber nicht mehr wiederfinden könnt? Nun ja, das Bild an das ich hier die ganze Zeit denken musste, war von hier (Folie 18). Und dort haben die es auch mit einer Dilation gelöst.

[starvald]

Hi,

vielen Dank für dieses sehr hilfreiche Update zu einer extrem unchristlichen Zeit! :-) Habe die Folien gerade gelesen, da werden im Prinzip alle Probleme die ich genannt hatte abgearbeitet. Perfekt!!