Matroids Matheplanet Forum Index
Moderiert von matroid
Mathematik » Numerik & Optimierung » Variationsproblem mit schwach differenzierbaren Lösungen
Druckversion
Druckversion
Antworten
Antworten
Autor
Universität/Hochschule Variationsproblem mit schwach differenzierbaren Lösungen
Manny
Junior Letzter Besuch: im letzten Monat
Dabei seit: 09.01.2010
Mitteilungen: 7
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Themenstart: 2020-05-10 17:23


Hallo Zusammen,
 
hier einmal kurz zur Motivation bevor unten meine Fragen kommen:
Es gibt ein Opensource Plugin, mit dem sich Maschinen-Stickdateien mit Inkscape erstellen lassen. Bisher wird dabei eine flächige Füllung allerdings nur durch aufeinander folgende gerade Linien realisiert. Im zugehörigen Forum gibt es bereits Gedanken zumindest geschwungene Linien zum Füllen verwenden zu können: hier
Über die Verwendung einer einzelnen Linie als Vorlage zum Füllen wollte ich gerne hinausgehen:
Der Anwender sollte beliebige Linien innerhalb seines zu füllenden Shapes vorgeben können, an die sich die Stickpfade zumindest lokal anschmiegen. Um dieses zu realisieren, hatte ich folgende Idee:
Die zu stickenden Linien sollen Isokonturen einer Funktion u(x,y) sein, welche es zu bestimmen gilt. Dabei hatte ich an eine Funktionalsminimierung mittels Euler-Lagrange gedacht:
\(F[u,\nabla u] =\int\int{{((\nabla u)^2-1)^2dxdy}}\)
Diese Gleichung sollte eine Fläche erzeugen, bei welcher der Gradient möglichst überall den Betrag 1 hat, um gleichmäßige Abstände zwischen den Isokonturen (und damit zwischen den zu stickenden Linien) zu ermöglichen.

Das obige Bild zeigt eine gewünschte Lösung für ein quadratisches, zu füllendes Shape, wobei an den Rändern jeweils Neumann-Randbedingungen (Gradient je Seite nach innen zeigend) vorgesehen wären.
Bezüglich der Möglichkeit beliebige Vorzugsrichtungen zur Füllung als Linie vorzugeben:
Hier würde ich den Gradienten \(\nabla u\) an der Position der Linie so setzen, dass er senkrecht auf der Linie steht (Ausnutzung, dass der Gradient stets senkrecht auf der Isokontur steht). Damit sollten dann z.B. auch diese Fälle realisiert werden können:

a) Vorgegeben: Neumann-Randbedingungen am Rand sowie Gradienten an einem Kreis (rot), an welchen sich die zu stickenden Linien orientieren sollen.
b) Vorgegeben: Neumann-Randbedingungen am Rand sowie Gradienten an einem Halb-Kreis (rot), an welchen sich die zu stickenden Linien orientieren sollen.
c) Vorgegeben: Nur Gradienten an einem Kreis (rot), an welchen sich die zu stickenden Linien orientieren sollen (ohne Randbedingungen).

Da in diesen Fällen die Lösung des Variationsproblems auf jeden Fall uneindeutig bezüglich einer Addition einer Konstanten ist, könnte man z.B. zusätzlich den Wert von \(u\) auf dem Kreis auf eine Konstante festsetzen.

Nun zu meinem Problem (zunächst der Einfachheit halber nur für den Fall ohne zusätzliche Linien-Vorgaben - also nur für das oberste Bild):
Ich habe einen iterativen Solver für die zugehörige Euler-Lagrange Gleichung geschrieben, aber dieser konvergiert z.B. nicht gegen eine Pyramide (Solver Idee: Diskretisierung der Euler-Lagrangegleichung; Auflösung nach \(u(i,j)\) in Abhängigkeit seiner Nachbarn; iteratives Anwenden, bis konvergiert). Nach Recherchen im Internet bin ich zu der Vermutung gekommen, dass dies daran liegen könnte, dass die gesuchte Funktion nicht überall stetig differenzierbar ist (vgl. z.B. Paper hier). Was ich aus dem Paper mitgenommen habe, ist, dass die problematische Ableitung \(\nabla u\) durch \(v\) ersetzt wird und dafür ein zusätzliches Constraint generiert wird:
\(\int{\int{\phi(\nabla u-v)dxdy}}\).
Wie ich dann aber diese Integralgleichungen für meinen Fall lösen kann, weiß ich damit leider noch nicht.
Zudem habe ich den Fall auch einmal zum Testen auf 1D heruntergebrochen:
Hier ergibt sich mittels Euler-Lagrange:
\(F[u,u'] = \int{\underbrace{(u'(x)^2-1)^2}_{f(u')}dx}\)
\(\rightarrow \frac{df}{du'} = \textrm{const} = 4u'(u'^2-1)\)
Für const = 0 ergibt sich also u'(x)={-1,0 oder 1}.
Damit ist aber nicht nur die 2D Pyramide eine Lösung (a), sondern genauso auch (b) und alle weiteren Kombinationen, welche die Randbedingungen einhalten:

Ob dieses Problem der Uneindeutigkeit auch genauso im 3D Fall oben besteht, kann ich gerade nicht abschätzen.

Meine Fragen wären daher:
-Ist mein Ansatz zur Generierung der Sticklinien überhaupt durchführbar oder spricht schon etwas Grundlegendes dagegen?
-Muss ich mein Funktional umformulieren, um die gesuchte Lösung zu erhalten oder muss ich einen anderen Solver finden? Habt ihr Ideen, was ich probieren könnte?

Vielen Dank auf jeden Fall für Eure Unterstützung und viele Grüße,

Manny





Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
StefanVogel
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 26.11.2005
Mitteilungen: 3577
Aus: Raun
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.1, eingetragen 2020-05-17 09:26


Hallo Manny,

2020-05-10 17:23 - Manny im Themenstart schreibt:
Ob dieses Problem der Uneindeutigkeit auch genauso im 3D Fall oben besteht, kann ich gerade nicht abschätzen.

die 3D-Pyramide kann man auch "zusammenfalten" wie die 2D Pyramide, ähnlich einem Balg der Ziehharmonika. Auf die Lösung (Isokonturen) hat das aber keinen Einfluss.


-Muss ich mein Funktional umformulieren, um die gesuchte Lösung zu erhalten

Kommt darauf an, was die gesuchte Lösung ist. In folgender Figur (außen ein flaches Recheck, innen ein Rechteck hochkant gestellt)

<math>
\begin{tikzpicture}
\draw (0,0) -- (5,0) -- (5,4) -- (0,4) -- cycle;
\draw (2,1) -- (3,1) -- (3,3) -- (2,3) -- cycle;
\end{tikzpicture}
</math>

wenn die Lösung ein Pyramidenstumpf mit ebenen Mantelflächen sein soll, dann erhalte ich für das Funktional ein kleineres Ergebnis, wenn ich die Lösung aus den beiden Teillösungen (außen flaches Rechteck, bis dazwischen zu einem Quadrat)

<math>
\begin{tikzpicture}
\draw (0,0) -- (5,0) -- (5,4) -- (0,4) -- cycle;
\draw (1,0.5) -- (4,0.5) -- (4,3.5) -- (1,3.5) -- cycle;
\draw [white] (2,1) -- (3,1) -- (3,3) -- (2,3) -- cycle;
\end{tikzpicture}
</math>

und (von dem Quadrat bis innen Rechteck hochkant)
 
<math>
\begin{tikzpicture}
\draw[white] (0,0) -- (5,0) -- (5,4) -- (0,4) -- cycle;
\draw (1,0.5) -- (4,0.5) -- (4,3.5) -- (1,3.5) -- cycle;
\draw (2,1) -- (3,1) -- (3,3) -- (2,3) -- cycle;
\end{tikzpicture}
</math>

zusammensetzte. Die Minimumslösung wäre dann nicht die gesuchte Lösung, möglicherweise wäre die Minimumslösung eine mit abgerundeten Ecken und Kanten, was vielleicht auch brauchbar ist. Möglich auch, dass ich mich verrechnet habe und das bisherige Funktional nicht kaputt machen muss.

Die beiden Links lesen und verstehen habe ich nicht geschafft.

Viele Grüße,
  Stefan



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Manny
Junior Letzter Besuch: im letzten Monat
Dabei seit: 09.01.2010
Mitteilungen: 7
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.2, vom Themenstarter, eingetragen 2020-05-17 20:08


Hallo Stefan,

erst einmal vielen, vielen Dank, dass du dich mit dem Problem genauer beschäftigt hast.
Zu deinem Beispiel - um sicher zu gehen, dass ich dich richtig verstanden habe, habe ich daraus einmal eine 3D Figur gemacht (nicht maßstabsgetreu):

In der untersten Punktebene hat man das große Rechteck, in der Mitte dann das Quadrat und die Spitze bildet dann das kleinere Rechteck - habe ich damit deine günstigere Lösung korrekt wiedergegeben?


Kommt darauf an, was die gesuchte Lösung ist.
Klingt zunächst erstmal wenig mathematisch, aber mein Grundproblem ist, dass ich möglichst equidistante Linien generieren möchte, welche sich an vorgegebene Geometrien anschmiegen (und dazwischen beliebig equidistant fortgesetzt werden). Deine Lösung als auch ein Pyramidenstumpf wäre nach dieser Definition erst einmal suboptimal aus folgenden Grund:

Angenommen \(a\) sei etwa halb so groß wie \(b\) - dann würden mit der Isolinien-Methode die Sticklinien im Bereich um \(a\) im Mittel doppelt so dicht liegen wie im Bereich um \(b\). Dies könnte natürlich je nach vorgegebener Geometrie noch schlimmer ausfallen (z.B. bei noch schmalerem inneren Rechteck) - während also im Bereich um \(a\) die Linien schon fast übereinander gestickt werden, könnten im Bereich um \(b\) Lücken entstehen, was definitiv nicht gewollt ist.
Als Lösung für dein Geometrie-Beispiel würde ich mir z.B. folgende Lösung vorstellen (rot wieder die vorgegebene Geometrie, schwarz die gesuchten Linien):

Diese sollte bis auf Singularitäten in der Ableitung an den Kanten überall einen |Gradienten| von etwa 1 haben.

Seit vergangener Woche habe ich mich mit dem Problem ebenfalls weiterbeschäftigt. Z.B. hatte ich die Idee, dass ich die gesuchte Funktion \(u(x,y)\) nicht durch ein Funktional beschreibe, sondern direkt durch eine Signed Distance Funktion berechne (hier). (Kurzfassung: Jeder Punkt bekommt als Wert den kürzesten Abstand zu einer vorgegebenen Geometrie zugewiesen). Diese Funktion hat per Definition einen |Gradienten| von 1 (außer an Singularitäten). Für die Pyramide (nur ein äußeres Rechteck vorgegeben) klappt dies z.B. auch ganz gut:

Was mich an dieser Lösung allerdings sehr stört ist folgendes: Ich erwarte von der Lösung, dass sie sich nicht verändert, wenn ich einzelne vormals berechnete Linien nun als Geometrie mit vorgebe und ansonsten alles unverändert lasse:

Hier wurde einfach ein weiteres, passendes Rechteck in der Mitte mit vorgegeben und man sieht wie sich die ganze Lösung verändert (entstehende Rundungen an den äußeren Ecken des inneren Rechtecks).
Aus diesem Grund habe ich diesen Ansatz wieder fallen gelassen und mich der Funktionalbeschreibung wieder zugewendet.
Dafür habe ich einen anderen Solveransatz verwendet - statt die diskretisierte PDGL nach \(u(i,j)\) aufzulösen und iterativ bis zur Selbstkonsistenz anzuwenden, habe ich ein Gradientenabstieg implementiert.
Dies habe ich für den 2D Fall (2D Pyramide) getestet, allerdings hat dies bisher noch überhaupt nicht funktioniert. Als Grund kann ich mir aktuell nur erklären, dass mein Funktional nicht konvex ist und daher das Gradientenabstiegsverfahren in einem lokalen Minimum hängen bleibt. (Um Fehler im Solver auszuschließen, habe ich es mit einem beliebigen, konvexen Funktional getestet und da passte die Lösung)
Aus diesem Grund habe ich versucht eine Lösung zu finden, wie man das geschilderte Problem ggf. als konvexes Problem formulieren kann.
Auf hier habe ich eine Methode gelesen, welche ein nicht-konvexes Funktional in \(u(x,y)\) in ein konvexes Problem umformuliert. Abgesehen davon, dass ich das Paper leider nur begrenzt verstanden habe, gehe ich aber aktuell davon aus, dass ich es so leider nicht verwenden kann, da mein Problem nicht-konvex in \(\nabla u(x,y)\) und nicht in \(u(x,y)\) ist.

Kennst du/ihr eine Möglichkeit das geschilderte Problem mit einem konvexen Funktional zu beschreiben?

Vielen Dank auf jeden Fall nochmal für die Hilfe und viele Grüße,

Manny




Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
StefanVogel
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 26.11.2005
Mitteilungen: 3577
Aus: Raun
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.3, eingetragen 2020-05-17 23:37


2020-05-17 20:08 - Manny in Beitrag No. 2 schreibt:
Hallo Stefan,

erst einmal vielen, vielen Dank, dass du dich mit dem Problem genauer beschäftigt hast.
Zu deinem Beispiel - um sicher zu gehen, dass ich dich richtig verstanden habe, habe ich daraus einmal eine 3D Figur gemacht (nicht maßstabsgetreu):

In der untersten Punktebene hat man das große Rechteck, in der Mitte dann das Quadrat und die Spitze bildet dann das kleinere Rechteck - habe ich damit deine günstigere Lösung korrekt wiedergegeben?

Korrekt, die beste Lösung für das Funktional bei ebenen Seitenflächen

<math>\pgfdeclarelayer{foreground}
\pgfsetlayers{main,foreground}

\pgfmathsetmacro{\h}{2.51} % etwas erhht wegen der Perspektive, richtiges Ergebnis wre 2.31

\begin{tikzpicture}
\coordinate (A) at (0,0,0);
\coordinate (B) at (5,0,0);
\coordinate (C) at (5,0,4);
\coordinate (D) at (0,0,4);
\coordinate (E) at (2,\h,1);
\coordinate (F) at (3,\h,1);
\coordinate (G) at (3,\h,3);
\coordinate (H) at (2,\h,3);
\draw[gray] (D) -- (A) -- (B);
\draw[gray] (E) -- (F) -- (G) -- (H) -- cycle;
\draw[gray] (A) -- (E);
\draw[thick] (B) -- (C) -- (D);
\draw[thick] (E) -- (F) -- (G) -- (H) -- cycle;
\draw[thick] (B) -- (F) (C) -- (G) (D) --(H);


\end{tikzpicture}</math>

lässt sich noch etwas verbessern bei geknickten Seitenflächen

<math>
\pgfmathsetmacro{\a}{1.14}
\pgfmathsetmacro{\b}{2.53} %richtiges Ergebnis wre 2.33, dann aber Knick nicht sichtbar

\begin{tikzpicture}
\coordinate (A) at (0,0,0);
\coordinate (B) at (5,0,0);
\coordinate (C) at (5,0,4);
\coordinate (D) at (0,0,4);
\coordinate (E) at (2,\b,1);
\coordinate (F) at (3,\b,1);
\coordinate (G) at (3,\b,3);
\coordinate (H) at (2,\b,3);
\coordinate (I) at (1,\a,0.5);
\coordinate (J) at (4,\a,0.5);
\coordinate (K) at (4,\a,3.5);
\coordinate (L) at (1,\a,3.5);
\draw[gray] (D) -- (A) -- (B);
\draw[gray] (L) -- (I) -- (J);
\draw[gray] (A) -- (I) -- (E) (B) -- (J) -- (F) (C) -- (K) -- (G) (D) -- (L) --(H) ;
\draw[thick] (B) -- (C) -- (D);
\draw[thick] (E) -- (F) -- (G) -- (H) -- cycle;
\draw[thick] (J) -- (K) -- (L);
\draw[thick] (B) -- (J) -- (F) (C) -- (K) -- (G) (D) -- (L) --(H) ;

\end{tikzpicture}</math>

Jede der ebenen Teil-Seitenflächen kann man dann genauso weiter knicken, so dass bei dieser Methode als Grenzfall bestimmt leicht gebogene Seitenflächen herauskommen. Ob sich das durch Abrunden der Seitenkanten noch weiter verbessern lässt?

Bei deinem nächsten Beispiel mit sehr breitem Rechteck außen




da würde es ja für das Funktional sprechen, wenn mit den benachbarten Bergen ebenfalls ein günstigeres Ergebnis herauskommen würde als für nur abfallende Seitenflächen. Doch zum Weiterrechnen bin ich noch nicht gekommen. Meine erste TikZ 3D Grafik hat etwas Zeit gebraucht.



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
StefanVogel
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 26.11.2005
Mitteilungen: 3577
Aus: Raun
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.4, eingetragen 2020-05-18 00:45


Die Skizzen sind alle nicht maßstabsgerecht. Noch ein anderer Versuch, ohne Rechnen. Das äußere Rechteck setze ich mit Anstieg -1 nach innen zu einem Dach fort, wegen dem negativen Anstieg nach unten gerichtet

<math>\pgfdeclarelayer{foreground}
\pgfsetlayers{main,foreground}

\begin{tikzpicture}
\coordinate (A) at (0,0,0);
\coordinate (B) at (5,0,0);
\coordinate (C) at (5,0,4);
\coordinate (D) at (0,0,4);
\coordinate (M) at (2,-3,1);
\coordinate (N) at (3,-3,1);
\draw[gray] (A) -- (M);
\draw[thick] (A) -- (B) -- (C) -- (D) -- cycle;
\draw[thick] (M) -- (N);
\draw[thick] (B) -- (N) (C) -- (N) (D) -- (M);
\end{tikzpicture}</math>

Das innere Rechteck setze ich mit Anstieg -1 nach außen ebenfalls zu einem Dach nach unten fort

<math>\pgfdeclarelayer{foreground}
\pgfsetlayers{main,foreground}

\begin{tikzpicture}
\coordinate (E) at (2,0,1);
\coordinate (F) at (3,0,1);
\coordinate (G) at (3,0,3);
\coordinate (H) at (2,0,3);
\coordinate (P) at (0,-2.5,-1);
\coordinate (Q) at (5,-2.5,-1);
\coordinate (R) at (5,-2.5,5);
\coordinate (S) at (0,-2.5,5);
\draw[gray] (E) -- (F) -- (G) -- (H) -- cycle;
\draw[gray] (P) -- (Q) -- (R) -- (S) -- cycle;
\draw[gray] (E) -- (P) (F) -- (Q) (G) -- (R) (H) -- (S) ;
\draw[thick] (E) -- (F) -- (G) -- (H) -- cycle;
\draw[thick] (Q) -- (R) -- (S);
\draw[thick] (F) -- (Q) (G) -- (R) (H) -- (S) ;
\end{tikzpicture}</math>

Dann schiebe ich beide Figuren soweit ineinander, dass das innere Rechteck vollständig über der Dachfläche vom äußeren Rechteck zu liegen kommt. Was dann von oben als Dachfläche zu sehen ist, nehme ich als Funktion u und das Funktional ist nach der Methode sogar 0 und man kann auch noch das innere Rechteck in der Höhe etwas variieren um verschiedene Lösungen zu erzielen. Die "benachbarten" Berge wären in dem Fall Täler.

<math>\pgfdeclarelayer{foreground}
\pgfsetlayers{main,foreground}

\begin{tikzpicture}
\coordinate (A) at (0,0,0);
\coordinate (B) at (5,0,0);
\coordinate (C) at (5,0,4);
\coordinate (D) at (0,0,4);
\coordinate (E) at (2,0,1);
\coordinate (F) at (3,0,1);
\coordinate (G) at (3,0,3);
\coordinate (H) at (2,0,3);
\coordinate (T) at (1,-1.2,1);
\coordinate (U) at (4,-1.2,1);
\coordinate (V) at (4,-1.2,3);
\coordinate (W) at (1,-1.2,3);
\coordinate (X) at (1.5,-0.6,0.5);
\coordinate (Y) at (3.5,-0.6,0.5);
\coordinate (Z) at (3.5,-0.6,3.5);
\coordinate (O) at (1.5,-0.6,3.5);
\draw[gray] (A) -- (M);
\draw[very thick] (A) -- (B) -- (C) -- (D) -- cycle;
\draw (A) -- (T) (B) -- (U) (C) -- (V) (D) -- (W);
\draw (T) -- (W) (U) -- (V);
\draw (T) -- (X) (U) -- (Y) (V) -- (Z) (W) -- (O);
\draw (X) -- (Y) (Z) -- (O);
\draw (E) -- (X) (F) -- (Y) (G) -- (Z) (H) -- (O);
\draw[very thick] (E) -- (F) -- (G) -- (H) -- cycle;
\end{tikzpicture}</math>




Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Manny
Junior Letzter Besuch: im letzten Monat
Dabei seit: 09.01.2010
Mitteilungen: 7
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.5, vom Themenstarter, eingetragen 2020-05-18 10:23


Hallo Stefan,

erneut vielen Dank für deine Mühe und deine schnelle Antwort.
Zu deinem ersten Beitrag:
Ich hätte die 3 Pyramidenspitzen so konstruiert, dass sie überall die Steigung 1 haben (bis auf an den Singularitäten) - da die Singularitäten aber im Integral nichts ausmachen, sollte das Funktional den Wert 0 erhalten.
Wenn das innere Rechteck breiter wird, dann würde in meiner Konstruktion die mittlere Pyramide immer größer werden und die Seitlichen immer kleiner. Sobald das innere Rechteck die gleichen Seitenverhältnisse hat wie das Äußere, würde das Ganze zu einem Pyramiden(stumpf) zusammengewachsen sein.

Deine gebogenen Lösungen würde ich dabei als lokales Minimum ansehen, da sie das Funktional nicht auf 0 drücken.

Zu deiner zweiten Antwort:
Vielleicht vertue ich mich, aber ich würde sagen, dass deine konstruierte Lösung äquivalent zu meiner Lösung mit den 3 Pyramidenspitzen ist - bei dir ist einfach die mittlere Pyramide nach innen/unten geklappt. Wenn ich das richtig sehe, sollten aber beide Lösungen die gleichen Isokonturen liefern (nur für andere Thresholds halt).

Deinen Konstruktionsansatz fand ich aber sehr interessant und daher habe ich ihn mal auf ein äußeres Quadrat mit einem inneren Kreis angewandt:

Als Operation habe ich dabei "Boolean-Differenz" verwendet. Das Ergebnis hat mich sehr stark an das erinnert, was ich auch bei den Signed Distance Funktions-Ergebnissen gesehen hatte:


Ich muss gestehen, dass ich diese Lösung nicht ganz so schön finde wie die Lösung a) aus meinem ersten Post, welche die Konturen von Kreis zu Rechteck interpoliert hat. Vom mathematischen Standpunkt aus ist diese Lösung hier aber auf jeden Fall günstiger für das Funktional. Die einzige Möglichkeit die andere Lösung zu erhalten, würde aus meiner Sicht daraus bestehen, zum Funktional zusätzliche Regularisierungsterme hinzuzufügen, welche Kanten & Spitzen mehr bestraft. Dies hätte auch den Vorteil, dass sowas wie der Fall b) bei der 2D Pyramide aus meinem ersten Post vom Funktional bestraft wird. Da ich aber aktuell noch Probleme habe, überhaupt automatisch eine Lösung für das Funktional für gegebene Geometrie zu finden, würde ich dieses Problem erst einmal hinten anstellen.

Ich denke dein Konstruktionsansatz könnte sich für 2 vorgegebene (geschlossene) Geometrien sogar ganz gut automatisieren lassen - für eine beliebige Anzahl an Geometrie-Vorgaben (die auch nicht notwendigerweise geschlossene Kurven darstellen müssen) fällt mir dazu allerdings gerade keine Lösung ein. Aus diesem Grund fand ich eine Funktionalsbeschreibung recht charmant, da man dort die Geometrien einfach als Constraint mit vorgeben könnte und der Solver dann den Rest übernimmt, ohne dass man zahlreiche Fallunterscheidungen vornehmen oder etwas von Hand justieren muss. Zudem ließe sich diese Lösung nachher evtl. leichter durch weitere Regularisierungsterme in eine gewünschte Richtung forcieren, während dies bei Boolean-Operationen nicht so leicht möglich ist. (Hier sehe ich z.B. keine Möglichkeit eine Interpolation von Shapes zu forcieren).

Hast du/ihr evtl. Erfahrung wie man mit einem nicht-konvexen Funktional umgehen sollte?

Vielen Dank auf jeden Fall nochmal und viele Grüße,

Manny









Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
StefanVogel
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 26.11.2005
Mitteilungen: 3577
Aus: Raun
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.6, eingetragen 2020-05-23 07:53


2020-05-18 10:23 - Manny in Beitrag No. 5 schreibt:
Deine gebogenen Lösungen würde ich dabei als lokales Minimum ansehen, da sie das Funktional nicht auf 0 drücken.
Oder die gebogene Lösung wird letztendlich auch noch in die spitz auslaufende Lösung mit Funktional=0 gedrückt, "gebogen" war nur eine vage Vermutung von mir.


Zu deiner zweiten Antwort:
Vielleicht vertue ich mich, aber ich würde sagen, dass deine konstruierte Lösung äquivalent zu meiner Lösung mit den 3 Pyramidenspitzen ist - bei dir ist einfach die mittlere Pyramide nach innen/unten geklappt. Wenn ich das richtig sehe, sollten aber beide Lösungen die gleichen Isokonturen liefern (nur für andere Thresholds halt).
... Das Ergebnis hat mich sehr stark an das erinnert, was ich auch bei den Signed Distance Funktions-Ergebnissen gesehen hatte:

Ja, das sehe ich inzwischen auch so, verschiedene Methoden mit gleichem Ergebnis. Und wenn man an den Ecken des inneren Rechteck das Dach konsequent in alle Richtungen mit Anstieg -1 abfallen lässt (wie bei einem Kegel), dann sollte sogar auch die gleiche Lösung wie bei dem Signed Distance Funktions-Ergebnis herauskommen:




Ich denke dein Konstruktionsansatz könnte sich für 2 vorgegebene (geschlossene) Geometrien sogar ganz gut automatisieren lassen - für eine beliebige Anzahl an Geometrie-Vorgaben (die auch nicht notwendigerweise geschlossene Kurven darstellen müssen) fällt mir dazu allerdings gerade keine Lösung ein.

Bei mehreren inneren Figuren, nicht unbedingt geschlossen, da kann man das Dach an beiden Seiten der Randlinien mit Anstieg -1 anfügen. An den Ecken und Endpunkten der Randlinie je nach Wunsch als kegelförmige Fortsetzung oder mit Dachgrat.


Hast du/ihr evtl. Erfahrung wie man mit einem nicht-konvexen Funktional umgehen sollte?

Da habe ich keine Erfahrung.




Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Manny
Junior Letzter Besuch: im letzten Monat
Dabei seit: 09.01.2010
Mitteilungen: 7
Zum letzten BeitragZum nächsten BeitragZum vorigen BeitragZum erstem Beitrag  Beitrag No.7, vom Themenstarter, eingetragen 2020-05-24 17:35


Hallo Stefan,

nochmals vielen Dank für deine Antwort 🙂


Bei mehreren inneren Figuren, nicht unbedingt geschlossen, da kann man das Dach an beiden Seiten der Randlinien mit Anstieg -1 anfügen. An den Ecken und Endpunkten der Randlinie je nach Wunsch als kegelförmige Fortsetzung oder mit Dachgrat.

Wenn ich das richtig sehe, dann würde eine kegelförmige Fortsetzung die gleiche Lösung ergeben wie mit signed distance functions, korrekt?


Die Fortsetzung als Dachgrat finde ich eine gute Idee, da sich dabei die Lösung nicht verändert, wenn man Linien hinzufügt, die ohnehin dagewesen wären (vgl. Post 2 - ein zusätzliches Rechteck innerhalb eines größeren Rechtecks erzeugt ungewollte Rundungen).
Eine Signed Distance Function ist aus meiner Sicht relativ leicht zu implementieren - wie man diese Methode abwandelt, um ein Dachgrat zu erhalten, muss ich mir jetzt nochmal ansehen.

Vielen Dank auf jeden Fall nochmal für deine tolle Unterstützung und viele Grüße,

Manny



Eine Notiz zu diese Forumbeitrag schreiben Notiz   Profil  Quote  Link auf diesen Beitrag Link
Manny hat die Antworten auf ihre/seine Frage gesehen.
Manny wird per Mail über neue Antworten informiert.
Neues Thema [Neues Thema] Antworten [Antworten]    Druckversion [Druckversion]

 


Wechsel in ein anderes Forum:
 Suchen    
 
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001-2020 by Matroids Matheplanet
This web site was originally made with PHP-Nuke, a former web portal system written in PHP that seems no longer to be maintained nor supported. PHP-Nuke is Free Software released under the GNU/GPL license.
Ich distanziere mich von rechtswidrigen oder anstößigen Inhalten, die sich trotz aufmerksamer Prüfung hinter hier verwendeten Links verbergen mögen.
Lesen Sie die Nutzungsbedingungen, die Distanzierung, die Datenschutzerklärung und das Impressum.
[Seitenanfang]