3D Texture rendern, mit mehrern ebenen / slices



  • Hallo,
    wenn ich eine 3D Texture bzw. in meinem Fall eine Volumendatei lade
    z.b. von der Größe 256*256*256 wie kann man es anstellen das mehrere
    ebenen durch diese 3D Textur schneiden und an dieser Stelle das
    bild der Textur zeigen. So das man quasi durch gucken kann, bzw. ins
    innere gucken kann. Das einzige was mir als Information zur Verfügung steht
    ist, dass man wohl 3 Ebene anlegt xyz und dann noch 6 andere Ebenen. Und
    es wirdmit automatischer Texturkoordinatengeneration gearbeitet.

    Mit 2D Texturen funktioniert das schon wunderbar. Habe aber beim rotieren
    einen blobb Effekt wenn der Texturstapel für die nächste Hauptachse geladen
    wird.

    Grüße
    cmos


  • Mod

    naja, wenn du schon mit gltexgen arbeitest, siehst du da ja den dritten parameter, der generiert dir dann die koordinate fuer die dritte achse der volumen textur. wenn die volume textur richtig uebergeben ist, sollte es alles sein damit das laeuft.



  • Hallo,
    also ich weiß nicht was ich sehen soll. Und das was du geschrieben hast, hilft mir nicht weiter. Ich möchte einfach eine beliebige anzahl von eben durch
    das Volumen durchschneiden lassen. Nennt sich auch Volume Rendering mit 3D Texture mapping, falls dir das etwas sagt. Bei glTexGen macht das OpenGL soweit automatisch das es die Koordinaten berechnet und auch entsprechend interpoliert um mir die Texture pro Schnitt anzuzeigen.

    Grüße



  • Vll. hilft dir das weiter. Ich habe damals die Texturkoordinaten für die Proxygeometrie von Hand berechnet.

    http://www.itwm.fhg.de/bv/theses/works/hirschenberger/Diplomarbeit_Hirschenberger.pdf



  • Hallo,
    und dank erstmal. Schön das es auch verwertbare Antwortern gibt.
    Den von dir angewandten Algorithmus habe ich nun auch gefunden.
    Gibt es einen Unterschied oder Nachteil wenn man sich die Texturkoordinaten
    von OpenGL berechnen lässt anstatt per Hand

    Wenn man die Box aus Vektoren der Form
    r = r0 + s*t
    zusammenstellt und dann eine Ebene immer entlang des Sichtvektors verschiebt und
    die Schnittpunkte berechnet, sollte man doch auch auf die gewünschten Schnittpunkte kommen. Was genau muss bei deinem verwendeten Algorithmus sortiert werden und wo ist die Ebene, bzw. wo sind die Slices deren Eckpunkte du bestimmen
    musst (in deinen Algorithmus)?

    Grüße,
    cmos



  • c-mos schrieb:

    Hallo,
    und dank erstmal. Schön das es auch verwertbare Antwortern gibt.
    Den von dir angewandten Algorithmus habe ich nun auch gefunden.
    Gibt es einen Unterschied oder Nachteil wenn man sich die Texturkoordinaten
    von OpenGL berechnen lässt anstatt per Hand

    Also das war eigentlich falsch ausgedrückt von mir, ich berechne die Eckpunkte des Polygons (3, 4 oder 5 Ecken), die eigentlichen Texturkoordinaten (u, v, w) werden von OpenGL automatisch erzeugt und die Textur in das Polygon gezeichnet (deshalb der Ausdruck Proxygeometrie).

    c-mos schrieb:

    Wenn man die Box aus Vektoren der Form
    r = r0 + s*t
    zusammenstellt und dann eine Ebene immer entlang des Sichtvektors verschiebt und
    die Schnittpunkte berechnet, sollte man doch auch auf die gewünschten Schnittpunkte kommen. Was genau muss bei deinem verwendeten Algorithmus sortiert werden und wo ist die Ebene, bzw. wo sind die Slices deren Eckpunkte du bestimmen
    musst (in deinen Algorithmus)?

    So mache ich das auch, du musst aber die Schnittpunkte noch so umsortieren, daß du ein konvexes Polygon bekommst und die gleiche Drehrichtung/Vorderseite hast.

    Gruß,
    Falco



  • Hallo,
    habe nochmal in diesem PDF gelesen. Also, wenn man den Würfel auf die Ausmaße von 1 begrenzt, also Länge, Breite und Höhe hat man durch die Schnittpunkte schon die
    eigentlichen Textukoordinaten, richtig ?
    Kannst du mir das mit dem Sortiern einmal genauer erklären. Das habe ich noch nicht so ganz verstanden.

    Grüße,
    c-mos



  • c-mos schrieb:

    Hallo,
    habe nochmal in diesem PDF gelesen. Also, wenn man den Würfel auf die Ausmaße von 1 begrenzt, also Länge, Breite und Höhe hat man durch die Schnittpunkte schon die
    eigentlichen Textukoordinaten, richtig ?

    Ja, oder du dividierst die Schnittpunkte halt noch durch die Bilddimension und normierst so.

    c-mos schrieb:

    Kannst du mir das mit dem Sortiern einmal genauer erklären. Das habe ich noch nicht so ganz verstanden.

    Da du Polygone mit mehr als 3 Ecken bekommen kannst musst du dafür sorgen, dass die Vertices reihum angegeben werden um Überschneidungen zu vermeiden:

    Damit sowas:
    
    4           3
    +-----------+
    |           |
    |           |
    +-----------+
    1           2
    
    nicht so aussieht:
    
    4           2
    +-         -+
    | \       / |
    |   \   /   |
    |     -     |
    |   /   \   |
    | /       \ |
    +           +
    1           3
    

    Ich hoffe das macht es klar.

    gruß,
    Falco



  • Hallo,
    ja mir ist klar das so etwas nicht passieren darf. In diesem PDF war etwas erklärt wie die Sortierung mit einer Tabelle funktioniert. Dort wurden Kanten und
    vertices irgendwie überprüft. Das wollte ich eigentlich nochmal genauer erklärt haben. Mir ist nicht klar wie diese Tabelle genau aufgebaut ist, was dort rein muss und was dort eigentlich genau berechnet oder überprüft wird.

    grüße,
    c-mos



  • Die Tabelle beinhaltet die Zuordnung der Kanten (A-J) zu den, an die Kanten angrenzenden Seiten (oben, unten,....) des Würfels.

    Bsp: Kante A hat die Bits für 'oben' und 'vorne' gesetzt, weil die Seiten an dieser Kante liegen.

    Die Sortierung funktioniert dann so, daß du ausgehend von einer Kante auf der der erste Schnittpunkt liegt, überprüfst mit welcher anderen Kante auf der ein Schnittpunkt liegt ein Bit überein stimmt, das ist dann der 2. Punkt. Ausgehend von dem prüfst du dann den 3. Punkt auf die gleiche Weise....

    Bsp: Ich habe 4 Schnittpunkte auf A, B, E, F.
    Ausgehend von A hat E oder B ein gleiches Bit gesetzt, welchen du nimmst ist egal. Ich nehm B.
    Ausgehend von B hat nur A (hatten wir schon) oder F ein gleiches Bit. Also nehmen wir F.
    Das wird jetzt so lange gemacht bis alle Punkte erreicht/sortiert sind so entsteht dann ein konvexes Polygon.



  • Hallo und danke nochmal für deine Geduld.

    Also ich hoffe das ich das nun richtig verstanden habe.

    Ich kann mir im Programm also einen Cube definieren der z.b. den Kantenbeschreibung aus diesem (ich nehmen an, das ist deine Arbeit) PDF
    entspricht, damit wir immer vom Gleichen sprechen.

    Jetzt wird eine Box-Plane intersection durchgeführt und heraus kommen z.b.
    4 Schnittpunkte, welche auf den Kanten A, B, E und F liegen.

    Jetzt nehme ich Kante A, also z.b. meinen ersten Schnittpunkt und schaue in der Tabelle nach welche anderen Kanten mindestens ein gleiches Flag teilen. Von A
    ausgesehen währe das B und E. Denn A und B teilen sich das oben-Flag und A und E
    teilen sich das vorne-Flag.

    Jetzt nehmen ich B, was auch gleichzeitig mein 2. Punkt des Polygons ist. Von B aus gesehen teilen sich A und F ein Flag. A war schon dran also nehmen wir F. F ist also der 3. Punkt des Polygons. Kommt zum Schluss noch E.

    Also, hab ich das jetzt so richtig verstanden ? 😃

    Ich werf gleich zu diesem Thema noch eine andere Frage ein. In der Ebenegleichung
    n * (r0 - r1) = 0
    gibt r0 ja die Position der Ebene an. Liege ich richtig, dass
    diese Position immer das naheliegendste Vertex ist, in bezug auf den Betrachter, also die Kamera ?

    Grüße,
    und danke c-mos

    Edit:
    Muss ich die Tabelle jedesmal neu aufstellen oder reicht das, wenn ich sie einma
    zu Programmstart aufstelle ? Ich meine damit diese Flags setzen.

    Ich meine dieses hier.

    oben unten links rechts vorne hinten
    A     X                       X
    B     X
    C     X
    D
    E
    .
    .
    .
    

    Kann ich das einmal zum Start so initialisieren oder muss das ständig erneuert werden ?

    Grüße,
    c-mos



  • c-mos schrieb:

    Hallo und danke nochmal für deine Geduld.

    Also ich hoffe das ich das nun richtig verstanden habe.

    Ich kann mir im Programm also einen Cube definieren der z.b. den Kantenbeschreibung aus diesem (ich nehmen an, das ist deine Arbeit) PDF
    entspricht, damit wir immer vom Gleichen sprechen.

    Jetzt wird eine Box-Plane intersection durchgeführt und heraus kommen z.b.
    4 Schnittpunkte, welche auf den Kanten A, B, E und F liegen.

    Jetzt nehme ich Kante A, also z.b. meinen ersten Schnittpunkt und schaue in der Tabelle nach welche anderen Kanten mindestens ein gleiches Flag teilen. Von A
    ausgesehen währe das B und E. Denn A und B teilen sich das oben-Flag und A und E
    teilen sich das vorne-Flag.

    Jetzt nehmen ich B, was auch gleichzeitig mein 2. Punkt des Polygons ist. Von B aus gesehen teilen sich A und F ein Flag. A war schon dran also nehmen wir F. F ist also der 3. Punkt des Polygons. Kommt zum Schluss noch E.

    Also, hab ich das jetzt so richtig verstanden ? 😃

    Exakt

    c-mos schrieb:

    Ich werf gleich zu diesem Thema noch eine andere Frage ein. In der Ebenegleichung
    n * (r0 - r1) = 0
    gibt r0 ja die Position der Ebene an. Liege ich richtig, dass
    diese Position immer das naheliegendste Vertex ist, in bezug auf den Betrachter, also die Kamera ?

    Ja, genau.
    Da deine Schnittebenen immer zum Betrachter ausgerichtet sein sollen, entspricht n dem negativen Kameravektor und r0 ist sein Stützvektor.



  • Hallo und danke für die schnelle Antwort.
    Zum Schluss noch die Frage mit dieser Tabelle. In dem PDF
    ist ja gegeben das ABCD oben liegen. Wenn man nun das Objekt bzw.
    die Kamera sich dreht, dann stimmt die Ausrichtung der Kannten ja nicht mehr
    mit der der Tabelle überein. Gibt es da einen
    Algorithmus wie man dann die Flags der Tabelle neu aufstellt ?
    Oder liege ich da komplett falsch, das man diese Tabelle immer neu
    aufstellen muss, also diese Flags setzen muss (?)

    Grüße,
    c-mos



  • Nein musst du nicht, wie die Dinger heissen iss letzenendes egal, es muss nur eindeutig sein. Ich hab das damals mit enums gelöst:

    enum EnFaces{
        FRONT_FACE  = 1,
        BACK_FACE   = 2,
        RIGHT_FACE  = 4,
        LEFT_FACE   = 8,
        BOTTOM_FACE = 16,
        TOP_FACE    = 32 };
    
    const unsigned int aEdgeCodes[] = {(FRONT_FACE + BOTTOM_FACE), (FRONT_FACE + RIGHT_FACE),
                                       (FRONT_FACE + TOP_FACE),    (FRONT_FACE + LEFT_FACE),
                                       (RIGHT_FACE + BOTTOM_FACE), (RIGHT_FACE + TOP_FACE),
                                       (LEFT_FACE  + TOP_FACE),    (LEFT_FACE  + BOTTOM_FACE),
                                       (BACK_FACE  + BOTTOM_FACE), (RIGHT_FACE + BACK_FACE),
                                       (TOP_FACE   + BACK_FACE),   (LEFT_FACE  + BACK_FACE)};
    

    Mit Bitoperationen kannste dann die Nachbarn finden.



  • Danke.

    Wenn ich das nahliegendste Vertex gefunden habe muss ich mir ja dann
    den Würfel entsprechend zusammenbauen, so das das vom Schema her wieder
    mit der Tabelle passt. Ich habs nun so gemacht, dass ich gleich den Index des Vertices bekomme, welches am nächsten zu mir liegt. Wie genau hast du das gemeint,
    mit Bitoperation? Also ich weiß wie man das in C schreibt.

    Sagen wir, ich hab jetzt den Index von meinem vordersten Vertex. Was nun ?
    Du hast ja sicherlich auch 8 Vektoren erzeugt die die Vertex definieren.
    Ich hatte eben probiert schon vor zu definieren was oben unten usw. ist, in
    abhängigkeit meines vordersten Vertices. Aber das ging in die Hose. Das sind zu
    viele Möglichkeiten pro Vertex.

    Vielleicht könntest du dir die Zeit bitte noch nehmen um mir das zu erklären (?)
    wie man dann darauf kommt. Ich meine, wie letztendlich auf die restlichen Vertices kommst, die deine Flächen bzw. die Kanten bestimmen, damit man dann
    das Sortieren in der Tabelle vornehmen kann.

    Grüße,
    cmos



  • Hallo nochmal,
    was passiert eigentlich mit den Schnittpunkten die keine sind, also die beim
    Bounding Sphere Test durchfallen ?

    Grüße,
    c-mos


Anmelden zum Antworten