4. Shadow Maps

Shadow Maps

  • G

    Hallo!

    Ich habe schon einiges zum Thema ShadowMaps gelesen, allerdings bin ich mir nicht ganz klar darüber wie das Transformieren des Koordinatensystems auf die Shadowmap tatsächlich umgesetzt wird.
    Wie kann man in der Kameraperspektive feststellen ob ein Punkt sichtbar ist oder nicht? Oder besser gesagt: Woher weiß ich welchen Pixel ich (aus Kamerasicht) für welchen (aus der Lichtquellenperspektive) verwenden muss?
    (Damit meine ich ganz allgemein was darunter zu verstehen ist - Ist das eine Art Raytracing auf die FarPlane um zu Testen ob es der selbe Punkt ist?)
    Und wie kann man berechnen welche welche Stellen nun im Schatten liegen, bzw wie trägt man diese Schattentextur dann auf? (Verwendet man in dem Fall einen der Buffer oder muss man da tatsächlich berechnen in welchem Winkel das Objekt den Schatten wirft und welche Oberflächen davon betroffen wäre(und wenn ja, wo genau) - letzteres kann ich mir nicht vorstellen, denn dann wäre es ja wieder eine Volume Shadow Art) ?

    Leider ging das aus keinem der Texte die ich gefunden habe klar hervor.

    Noch eine kleine Nebenfrage: Gibt es in OGL oder C++ selbst, einen Datentypen für (4x4) Matrizen (inklusive überladenen Operatoren) ?

    Hoffe ihr könnt mir da helfen 🙂

    MfG

    0
  • H

    wie trägt man diese Schattentextur dann auf?

    Du renderst die Tiefeninformation aus der Sicht der Lichtquelle in die Shadow-Map.
    Die dabei jeweils vorliegende Vertex-Position bildet eine Texturkoordinate fuer die Shadow-Map.
    Diese Texturkoordinate verwendest Du dann auch beim Rendern aus der Kamerasicht.
    Beachte dass es sich um eine projezierte Textur handelt.

    0
  • G

    hellihjb schrieb:

    wie trägt man diese Schattentextur dann auf?

    Du renderst die Tiefeninformation aus der Sicht der Lichtquelle in die Shadow-Map.
    Die dabei jeweils vorliegende Vertex-Position bildet eine Texturkoordinate fuer die Shadow-Map.
    Diese Texturkoordinate verwendest Du dann auch beim Rendern aus der Kamerasicht.
    Beachte dass es sich um eine projezierte Textur handelt.

    Genau letzteres habe ich gemeint. Mich interessiert in dem Fall wie die Zuordnung der Koordinaten aus der Shadowmap und denen des 3D Raums aus Sicht der Kamera funktioniert. Wie trägt man in dem Fall eine projezierte Textur(?) auf ?

    MfG

    0
  • T

    Gorkosh schrieb:

    Genau letzteres habe ich gemeint. Mich interessiert in dem Fall wie die Zuordnung der Koordinaten aus der Shadowmap und denen des 3D Raums aus Sicht der Kamera funktioniert. Wie trägt man in dem Fall eine projezierte Textur(?) auf ?

    Wenn du auf Vertices eine Textur projizieren willst, dann transformierst du die Positionen der Vertices wie gewohnt mit der Model*View*Projection Matrix. Die Texturkoordinaten erhältst du, indem du die Positionen mit der Model*View_Projector*Projection_Projector multiplizierst. Dann hast du ja bekanntlich Koordinaten im Normalized Device Space, die du mit einer simplen Scale und Translation Matrix noch in Texture Space Koordinaten ([0,1]^2) transformieren musst.

    0

  • Dann hast du ja bekanntlich Koordinaten im Normalized Device Space, die du mit einer simplen Scale und Translation Matrix noch in Texture Space Koordinaten ([0,1]^2) transformieren musst.

    scale + translation + perspektivische projektion. ausser natürlich wenn es sich um eine "parallele" lichtquelle (sonne) handelt. dann fällt die perspektivische projektion weg.

    0
  • T

    hustbaer schrieb:

    Dann hast du ja bekanntlich Koordinaten im Normalized Device Space, die du mit einer simplen Scale und Translation Matrix noch in Texture Space Koordinaten ([0,1]^2) transformieren musst.

    scale + translation + perspektivische projektion. ausser natürlich wenn es sich um eine "parallele" lichtquelle (sonne) handelt. dann fällt die perspektivische projektion weg.

    Wieso persp. Projektion NACH der Scale/Trans Matrix? Die Projektion steckt ja bereits in der Projektions Matrix.

    Etwas ausführlicher läuft Texturprojektion so:
    Textur koordinate = Position * World * View_Projector * Projection_Projektor, Homogene Division, ScaleBiasMatrix

    0

  • this->that schrieb:

    hustbaer schrieb:

    Dann hast du ja bekanntlich Koordinaten im Normalized Device Space, die du mit einer simplen Scale und Translation Matrix noch in Texture Space Koordinaten ([0,1]^2) transformieren musst.

    scale + translation + perspektivische projektion. ausser natürlich wenn es sich um eine "parallele" lichtquelle (sonne) handelt. dann fällt die perspektivische projektion weg.

    Wieso persp. Projektion NACH der Scale/Trans Matrix? Die Projektion steckt ja bereits in der Projektions Matrix.

    Etwas ausführlicher läuft Texturprojektion so:
    Textur koordinate = Position * World * View_Projector * Projection_Projektor, Homogene Division, ScaleBiasMatrix

    wieso nachher? damit man mehr rechenschirtte per vertex braucht?

    alles was du nach der division noch an scale/offset rechnen willst, kannst du genauso in die projektions-matrix mit rein rechnen, die du sowieso brauchst.
    verstehe grad nicht wieso man das nochmal nachher machen sollte.

    ich wollte eigentlich nur darauf hinweisen, dass es mit matrix-multiplikationen nicht getan ist. kurz: die division ist mir abgegangen 😉

    0
  • T

    hustbaer schrieb:

    this->that schrieb:

    hustbaer schrieb:

    Dann hast du ja bekanntlich Koordinaten im Normalized Device Space, die du mit einer simplen Scale und Translation Matrix noch in Texture Space Koordinaten ([0,1]^2) transformieren musst.

    scale + translation + perspektivische projektion. ausser natürlich wenn es sich um eine "parallele" lichtquelle (sonne) handelt. dann fällt die perspektivische projektion weg.

    Wieso persp. Projektion NACH der Scale/Trans Matrix? Die Projektion steckt ja bereits in der Projektions Matrix.

    Etwas ausführlicher läuft Texturprojektion so:
    Textur koordinate = Position * World * View_Projector * Projection_Projektor, Homogene Division, ScaleBiasMatrix

    wieso nachher? damit man mehr rechenschirtte per vertex braucht?

    alles was du nach der division noch an scale/offset rechnen willst, kannst du genauso in die projektions-matrix mit rein rechnen, die du sowieso brauchst.
    verstehe grad nicht wieso man das nochmal nachher machen sollte.

    ich wollte eigentlich nur darauf hinweisen, dass es mit matrix-multiplikationen nicht getan ist. kurz: die division ist mir abgegangen 😉

    Naja, der OP hat offensichtlich Verständnisprobleme mit dem Algo, also wollte ich die logischen Schritte erklären. Optimieringen sind einem herzlich egal in so einer Phase;)

    0
Anmelden zum Antworten