4. W20 Normalen berechnen oder gehts auch anders?

W20 Normalen berechnen oder gehts auch anders?

  • G

    Grüße,
    ich habe einen 20seitigen Würfel berechnet über alpha phi und r. Is ja kein Problem.
    So geht auch alles ohne Probleme. Blending geht. Jetzt fragt ihr euch sicher was will der eigentlich. 🙄

    Also wenn ich GL_LIGHTING aktiviere scheinen meine Normalen nicht zu stimmen.
    Wenn ich den Würfel drehe bleibt immer nur die Vorderseite beleuchtet. (sie dreht sich also mit, schaut aus als ob sich die Lichtquelle bewegte --> ein Effekt wenn die Normalen nicht stimmen) 😞
    Erst hab ich es versucht die einzelnen Dreiecke im Linksdrehsinn zu zeichnen. Damit der Normalenvektor nach außen (sichtbare Fläche) zeigt. Nichts. Jetzt bin ich dabei für jedes Polygon die Normalen zu berechnen. Über das Kreuzprodukt der Strecken AB AC. Müsste doch auch so funktionieren oder? Doch ich glaube bei der Berechnung der Strecke AB AC bau ich Bockmist. Eigentlich müsste die sich doch aus der Vektorsubtraktion ergeben vom Ortsvektor zu Punkt A unb B bzw A und C. Oder liege ich da falsch.

    Oder aber gibt es eine einfachere Möglichkeit die Normalenvektoren zu berechnen/lassen?

    Über Hilfe währe ich sehr dankbar. 🤡

    Ich sollte vielleicht noch dazusagen das ich naja siehe GL... mit OpenGL arbeite. 😃

    0
  • S

    Stimmt schon so, du musst aber darauf achten, dass du dann auch 1) den Vektor normalisierst, 2) das Kreuzprodukt richtig berechnest und 3) beim Kreuzprodukt nicht die Vektoren die du vorher errechnet hast vertauschst, sonst zeigt der Normal dann doch in die falsche Richtung.
    Zu 3) gibts die "Rechte-Hand-Regel": dein gestreckter Zeigefinger ist v1, dein eingeknickter, sonst aber gestreckter Mittelfinger v2 und der nach oben zeigende Daumen v3:
    v1 x v2 = v3

    0
  • G

    danke, hab eben festgestellt das ich den Vektor nicht normalisiert habe über die MAGNITUDE... jetzt gehts... 😃

    0
  • G

    aber mal noch ne andere Frage...
    ich hab mal wo gelesen wenn man ein Polygon im Linksdrehsinn beschreibt so wird von OpenGL der Normalenvektor automatisch in die Richtung des Betrachters gesetzt?! Oder hab ich da jetzt was falsch verstanden? 🙄

    de Gortosch...

    0

  • Da es Splat nicht ganz eindeutig gesagt hat: es reicht einmal normalisieren nachdem das Kreuzprodukt berechnet ist. Und es müsste eigentlich auch irgendwo ein Flag zu setzen sein (sogar bei OpenGL, oder?) wo er dann automatisch normalisiert.

    @gortosch: Nein das kann ich mir nicht vorstellen. Es könnte ja Absicht sein.

    Und Würfel haben definitionsgemäß 6 Seiten! (SCNR 😉

    Bye, TGGC \-/

    0
  • S

    TGGC schrieb:

    Und Würfel haben definitionsgemäß 6 Seiten! (SCNR 😉

    Na, ein Ikosaeder halt! 🤡

    0
  • G

    jup ein Ikosaeder... hab ihn blos W20 genannt weil es
    1. einfacher zu schreiben ist 😉
    2. ich mir das so aus DSA-Spielen angewöhnt habe
    3. öhm s. Punkt 1.

    de Gortosch...

    Ps.: Is schon klar das, dass Kreuzproduktes nur einmal Normalisiert werden muss. Hab das auch so verstanden. 🕶

    0
  • S

    Ja, wenn mich nicht alles täuscht, normalisiert OGL mit dem Flag GL_NORMALIZE automatisch.
    D.h. du könntest in der Initialisierung auch schreiben: glEnable(GL_NORMALIZE);
    (bin mir aber nicht 100%ig sicher, braucht man doch eh nicht 😉 )

    0

  • ich denke mal, dass einmal normalisieren ein wenig performanter sein wird...
    automatisches normalisieren is was für faule.

    0
  • T

    [quote="dot"]ich denke mal, dass einmal normalisieren ein wenig performanter sein wird...
    automatisches normalisieren is was für faule.[/quote]

    vor ein paar jahren war gl_normalize noch todsünde, heute empfehlen nvidia und co. sogar, daß man das im zweifelsfall einfach aktiviert und fertig (kann ja mal jemand testen, wie groß der unterschied wirklich ist, aber in zeiten, wo normalen aus ner normalmap kommen spielt sowas ohnehin bald keine rolle mehr).

    theorie: in the mitte jeder fläche entspricht die normale der kugelnormalen.
    weitere theorie: für ein gleichschenkliges dreieck bekommt man den mittelpunkt durch mitteln der drei eckpunkte.
    voraussetzung: ein model wird um den ursprung entworfen (sonst eben mittelpunkt abziehen).
    vereinfachung: eine anständige vektor-klasse für lesbaren syntax wird angenommen
    ergebnis:

    n = (v0+v1+v2)/3;
    n.normalize();

    bei soviel theorie ist aber sicher ein denkfehler inklusive ,-)

    0

  • Das /3 kann man gleich sparen.

    Bye, TGGC (Zu viele Primitive hier.)

    0
  • T

    [quote="TGGC"]Das /3 kann man gleich sparen.[/quote]

    *hust* peinlich. da will man möglichst aufwand sparen und flickt noch ne sinnlose division rein. wobei ich jetzt zweifel bekomme, wenn ich mir das "von oben" vorstelle. aber an jedem eckpunkt wäre der positionsvektor auch (richtungsmäßig) der normalenvektor.. also eigentlich.. hätte ich in mathe wirklich besser aufpassen sollen *g*

    0
Anmelden zum Antworten