4. 3D Kennfeld: beliebige Punkte im 3D-Raum zu einer Fläche verbinden

3D Kennfeld: beliebige Punkte im 3D-Raum zu einer Fläche verbinden


  • rapso schrieb:

    wenn du jeden punkt mit jedem verbindest, müßtest du am ende eigentlich einen normalen, convexen körper erhalten.

    Das bezweifele ich schonmal, denn daraus ergibt sich nur ein Liniengewirr. Oder meinst du vielleicht, das man nicht jeden punkt mit jedem verbindet, sondern alle Kombinationen von 3 Punkten sucht und Dreiecke formt? Dann würde man zwar auch keinen sauber definierten Körper erhalten, aber durch den z-Buffer würde man nur die Dreiecke sehen, die zur konvexen Hülle der Punkte gehören. Die Konvexe Hülle ist also gewissermassen die Oberfläche. Ist es die gesuchte Oberfläche?

    Bye, TGGC (Demo or Die)

    0
  • R
    Mod

    F98 schrieb:

    Nuja, Deine Aussage hilft mir aber nicht gerade viel ...

    schade dass es dir nicht hilft deinen wunsch genauer zu äußern, so wirst du viele versuche brauchen deine wunschoberfläche zu erhalten.

    @TGGC, ja, hast recht, mir ging es um das erscheinungsbild bei allen 3-eck flächemöglichkeiten.

    rapso->greets();

    0
  • F

    So, ich habe mal ein gängiges Beispiel compiliert, allerdings habe ich darin wieder ein 1000x1000 Array verwendet, in dem die Höhenpunkte drin sind. Das näherungsweise Einsortieren der Punktwolke in dieses Array muss ich dann eben extra implementieren.

    http://fatman98.fa.funpic.de/Test/

    Jetzt meine Probleme:

    1. Die 2 Gebirge erscheinen in ihrer Länge und Breite oval, obwohl ich sie aus jeweils 4 Vierecken male, eigenlich müßten die Dinger ja kreisrund sein. Woran liegt das?

    2. Durch die Gebirge sieht mal ab und zu noch den Hintergrund durch, aber eben nicht immer. Wie kann ich das abstellen, die Anweisungen

    glEnable(GL_DEPTH_TEST);              // Enables Depth Testing
glDepthFunc(GL_LEQUAL);               // The Type Of Depth Testing To Do
glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);

    sollten das doch beheben? Tun sie aber nicht.

    0
  • M

    Hi,

    Ich könnte mir vorstellen, dass sich dein Problem mit dem Algorithmus zur Mesh-Optimierung von Hoppe lösen lassen könnte. Vielleicht mit einigen Vereinfachungen.

    Der Algorithmus läuft zwar normalerweise in die andere Richtung (von einem Mesh mit vielen Dreiecken zu einem mit wenigen), er wird allerdings von Hoppe auch dazu benutzt Geometrie aus Punktwolken zu generieren.

    Im Wesentlichen funktioniert er so:
    Gegeben sei eine Menge von Kontrollpunkten (das sind deine Punkte), so wie ein Dreiecksgitter (dazu könnte man das Rechteck [xmin, xmax] x [ymin, ymax] wählen und es durch zwei Dreiecke darstellen). Der Algorithmus modifiziert das Gitter nun so, dass

    1.) der Abstand der Kontrollpunkte zum Gitter minimiert wird
    2.) die Länge der Kanten möglichst klein bleibt
    3.) möglichst wenige Dreiecke verwendet werden.

    Dazu wird zum einen für jede Komponente (x, y, z) ein lineares Gleichungssystem gelöst, so dass 1 und 2 erfüllt sind (die Gitterpunkte werden entsprechend verschoben) so wie in einem anderen Schritt folgende Operationen ausgeführt:

    1.)edge-collapse
    2.)edge-swap
    3.)edge-split

    Die Operationen werden für eine zufällig gewählte Kante nacheinander durchprobiert und falls sie die Energie des Mesh-Kontrollpunkt-Systems reduzieren ausgeführt.
    Die Energie wird definiert als

    E = SummeDerAbständeDerKontrollpunkteZumMesh + c_rep * AnzahlDerGitterPunkte + c_spring * SummeDerKantenlängen

    c_rep, c_spring sind vom Benutzer zu wählende Konstanten.

    Nicht so leicht das in ein paar Zeilen zu quetschen, und auch die Implementierung ist recht aufwändig. Wie gesagt: Unter Umständen reicht es für dein Problem eine einfachere Version des Algorithmus anzuwenden.
    Auch wenn es sehr, sehr Aufwändig ist führt es wahrscheinlich zu den schönsten Ergebnissen!

    Um das paper zu finden einfach bei google suchen:
    Hoppe mesh optimization

    0

  • Ich frag mich natürlich, was passiert, wenn zwei Punkte übereinanderliegen.

    Bye, TGGC (Demo or Die)

    0
  • M

    Der Algorithmus wird die durch die Punke definierte Fläche natürlich nur approximieren.
    Das kann dann entweder so aussehen, dass die Fläche zwischen den Punkten hindurchläuft, oder - das hängt von der Wahl der Konstanten ab - in der Tat eine 'senkrechte Wand' produziert wird.

    Bis jetzt bin ich allerdings davon ausgegangen, dass keine Überhänge zugelassen sind. Genausowenig Punkte die genau übereinander liegen. Ansonsten wäre unsere Fläche nämlich durch die vorgegebenen Punkte nicht mehr eindeutig definiert.

    0
  • F

    Klingt gut und ist interessant, brauch ich aber jetzt nicht mehr. Meine 2 Fragen von Seite 1 wurden noch nicht beantwortet. Gibt es hier keinen der schon mal aus lustigen 4Ecken Oberflächen generiert hat? 😞

    0
  • S

    Na die nächsten. Wird dann natürlich nicht regelmässig. Aber sollte doch klappen!?

    0
  • F

    Hm. Versteh ich jett nicht ganz. Was meinst Du mit "nächsten" und "klappen"?

    0
  • M

    Dein zweites Problem wird wahrscheinlich damit zusammenhängen, dass zNear / zFar zu klein ist.

    0
  • F

    Hi, ich verwende dafür folgende Werte:

    zNear = 0.1F;
    zFar = 12200.0F;

    Mein Koordinatensystem erstreckt sich dabei von 0.0 - 1000.0 in jede Achsenrichtung. Was wären dann sinnvollere Werte für zNear und zFar?

    0
  • R
    Mod

    far muss nicht weiter sein als du sehen kannst, in deinem fall also maximal 1000.f*sqrtf(2.f)

    rapso->greets();

    0
  • F

    Also 1000.0*1.4 ist einfach zu wenig, da ist slbst bei höchstem Zoom nur das halbe Gitter zu sehen. 5000 Muss es schon sein, und selbst da treten diese komischen flackernden Überblendeffekte auf.

    0

  • Ich denke mal eher, die Sichtweite müsste der Diagonale im Würfel entsprechen, und wenn du dich von -1000 bis +1000 freie bewegen kannst, dann ist die Kantenlänge dessen auch 2000.

    Bye, TGGC (Demo or Die)

    0
  • F

    Danke für den Denkanstoß. Folgende Werte sehen am Besten aus:

    zNear = 250.0;
    zFar = -250.0;

    Übrigens sitze ich gerade an einer Funktion, die mir höhenabhängig einen Farbwert zurückgibt, also sowas:

    // höhenabhängig die Farbe setzen
void __fastcall TfrmMDI::SetVertexColor(float fHeigth)
{
     float r, b, g;

     r = fHeigth/MAXGRIDSIZE;
     b = 1 - r;
     g = 1.0;

     glColor3f(r, g, b);
}

    Mit dieser Funktion läßt sich ein Farbverlauf von Türkis nach Gelb realisieren. Jetzt möchte ich aber einmal im Farbkreis rum, sprich

    Orange, Gelb, Grün, Türkis, Blau, Lila, Rot

    Das müßte doch mit Winkelfunktionen gehen, oder? Aber wie setzt man da die Werte für r,g,b?

    MfG F98.

    0
  • S

    F98 schrieb:

    einen Farbwert zurückgibt

    SetVertexColor

    🤡

    0
  • F

    Jadoch. 😉

    Dann hab ich mich eben verschrieben. "Farbe einstellt" wäre besser. Nun?

    0
  • L

    also "einmal im farbkreis rum": dazu würde sich HSV eignen. du musst einfach nur beim V höher gehen, und wenn du bei 360° bist biste fertig.
    http://de.wikipedia.org/wiki/HSV-Farbraum

    0
  • M

    zNear und zFar geben die Abstände der Near- bzw Far-Clipping-Plane zu deiner Kamera an. Es ist eigentlich nicht unbedingt optimal, wenn so ein Abstand negativ ist!
    Wenn du also ein hohes zFar haben willst, dann solltest du, falls dein Z-Buffer streikt zNear ebenfalls erhöhen.

    z.B: zNear = 1, zFar = 5000
    wenns dann noch flackert wählst du eben zNear = 10 usw.

    Um so kleiner der Quotient zNear / zFar ausfällt, umso schlechter sind deine Z-Buffer Ergebnisse.

    0
  • F

    Yo, ich hab schon etwas damit rumexperimentiert. Die besten Ergebnisse liefer eben solche Werte im Bereich -250, 250.

    Übrigens habe ich eine feine Bibo zum Thema HSV2RGB und RGB2HSV gefunden:

    http://www.tac.dk/software/viz/src/libviz/

    und dort die Datei VizCM.C und VizCM.h

    0
Anmelden zum Antworten