nee darum gehts ja nicht ich würds nur kenn können (besser als nicht können).

und genau das was du gesagt hast (dass es nur ein Richtungsvektor ist) irritiert mich ja.
Mein GL muss ja irgenwoher wissen wo jetzt dieser Vektor anzulegen ist.

Das Hauptproblem ist, dass ich nicht weiß an welcher Stelle Meines Programms ich die Funktion aufrufen muss.

_________________
Wieso kann es nicht einfach funktionieren?

OpenGL ist eine Statemachine. Wenn du glNormal aufrufst, dann setzt du diese Normale für alle folgenden Vertices bis wieder eine andere Normale gesetzt wird. Du setzt also immer direkt vor glVertex deine Normalen mit glNormal

Stell dir einfach vor, die Normale geht aus dem Vertex raus.

OpenGL interpolliert dann zwischen den Normalen der Vertices die an einer Fläche liegen. Damit werden dann quasi die Normalen innerhalb der Fläche "simuliert". Shader nutzen diese für fein strukturierte Oberflächen. Die berechnen die Normalen in der Fläche einfach anders und raus kommt z.B. eine rauche Oberfläche mit kleinen Knubbeln. Und das ohne zusätzliche Vertices, einfach durch "geschwindelte" Normalen.

Wenn du richtig harte Kanten willst musst du sogar mehr Aufwand betreiben als bei weichen, da du alle Vertices an der Kante doppelt rendern musst. Einmal mit der Normale für die eine Fläche und einmal mit der für die andere.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ums auf den Punkt zu bringen:
Ich bekomms nicht gebacken!

Hier mal meine Pyramide die wenigstens doch etwas Stumpf werden soll:


Es geht nicht.
Ich hab keine Ahnung warum.
Ich hab langsam keine lust mehr.
Wenn so weiter geht lass ichs und mach mit was anderem weiter!

Trotzdem Danke für die Geduld und deine Bemühungen Flash!!!

_________________
Wieso kann es nicht einfach funktionieren?

ist ja auch kein wunder, dass es so nicht funktioniert. In deinem geposteten Codeschnipsel zeigt die normale an ALLEN Eckpunkten deiner Pyramide nach oben, das ist aber nicht richtig, denn die Flächen zeign ja garnicht nach oben. Einzige möglichkeit die du hast ist, vor JEDEM glVertex3f(); aufruf auch glNormal3f(); aufzurufen und für jeden Eckpunkt anzugeben, in welche Richtung er zeigt. Da du deine Pyramide ja oben stumpf haben willst ist der oberste Punkt der einzige mit einer Normalen die nach oben zeigt, alle anderen stehen senkrecht auf ihrer Fläche und zeigen vom Mittelpunkt der Pyramide über die Ecken nach Außen.

PS: Im übrigen wird das Licht auch nicht sooo prall auf der Pyramide aussehen, da OpenGl Licht zwischen den Eckpunkten das Licht interpoliert und so kann es sein, dass die Oberfläche etwas merkwürdig aussieht. Je mehr vertices du in einem Objekt verbaust um so genauer ist das OpenGl Licht. Probier das mal mit einer einfachen Fläche aus, die mal aus nur einem Quad und mal aus 16 oder sogar 64 Quads besteht und lass eine OpenGl Lichtquelle darüber hin- und herfahren. Da sieht man dann den sogenannten Goraud-Shader in action. Sollte es noch hapern mach ich dir mal n Beispiel.

_________________
Klar Soweit?

um es zu vervoll ständigen:


So hab ichs auch schon versucht und es kam nix zu stande...

_________________
Wieso kann es nicht einfach funktionieren?

Du solltest aber bei diesem Stück Code auch eine OpenGL Fehlermeldung erhalten. Checkst du die? (Im Quickstart ist da eine simple Methode beschrieben.)

glEnable darf innerhalb glBegin/End nicht aufgerufen werden.

Außerdem hat Sellmann recht. Die Pyramide ist sehr grob unterteilt und wirklich viel sehen kannst du da nicht. Die Standardbeleuchtung orientiert sich nicht an der Größe der Fläche (also den Pixeln) sondern an der Anzahl der Eckpunkte (Vertex). Sie wird umso genauer, je feiner die Objekte strukturiert sind.
Eine Pixelorientierte Beleuchtung bekommst du nur mit Shadern hin. Das ist aber ein ganz anderes Kalliber.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Wie stellst du denn deine Lichtquelle ein? Wann und wie aktivierst du sie? Was mir aufgefallen ist: Du zeichnest deine Pyramide falsch herum. Ich habe deine Methode übernommen und ausprobiert und bei mir sind die Innenseiten der Pyramide zu sehen gewesen. Wenn du kein Backface-Culling eingeschaltet hast ist das aber egal.

_________________
Klar Soweit?

glNormal enthält jetzt dank Sascha ein Bild welches anzeigt was geglättete Normalen bringen.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Musste zwecks Klausuren ne kleine Pause einlegen...

Bin jetzt aber wieder am Start... Wort wörtlich leider.



hab das so mal versucht das liche ändert sich drastisch (immerhin) aber die glättung, also dass der zylinder nich mehr ganz so eckig aussieht geht noch nich so wie ich mir das vorgestellt habe. wenn ich mehr slices mache gehts trotzdem noch nicht...

bitte helft!

€dit:

mir is grade aufgefallen, dass in der mitte des Zylinders das gar nich so schlimm aussieht
=> kann es sein dass OGL an den Kanten Probleme hat?

_________________
Wieso kann es nicht einfach funktionieren?

Ich hab hier nur den Code von damals, den ich mir aus dieser Fragestellung heraus gebaut habe. Er operiert auf einem Gitter. Ich hoffe damit kannst du etwas anfangen:


€: oh die zweite Seite habe ich noch garnet gesehen

Screenshot?

_________________
Yeah!

Wenn es so aussieht, wie ich es mir gerade vorstelle, dann würde ich vermuten, dass das komische Aussehen von dem großen Winkel zwischen Deckel und Seite vom Zylinder liegt. Die "glättung" der Normalen kann da zu einem unerwünscht starkem Effekt führen.
Hilfreich ist es, Kanten mit einem Winkel von > 30° (werf ich einfach mal so in den Raum, ist der Defaultwert von Blender in dieser sache) als "Kante" zu betrachten und die Normalen ungeglättet lassen.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Wenn du dir den Code von Wh0p anschaust siehst du das er keinen Deckel hat und die Normalen auch nicht glättet o.ä. sondern direkt die für eine Zylinderwand korrekten Normalen berechnet. Eigentlich müsste das so richtig sein.

_________________
Yeah!

Oh, ähh, ja...

Coolcat, da hast du natürlich recht. Den Codeteil hab ich übersehen.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also wenn ich deinen Code bei mir mal so einfüge, zeigen die Flächen nach innen, die Normalen aber nach außen. Oder liegt das an mir?

Eine Möglichkeit warum die Lichtintensität nicht ganz gleichmäßig ist, konnte die Interpolation sein. Ich weiß ja nicht wie das normale OpenGL Licht das macht aber wenn ich Shader verwende, normalisiere ich die Normalen immer im Pixelshader, weil die interpolierten Normalen danach nicht automatisch normalisiert werden.
Zumindest denke ich, das es so ist.

Also mal als Beispiel: Wenn dein Zylinder nur aus 4 Quads besteht, wären die Normalen orthogonal zueinander.
(1,0,0) und (0,1,0) ergibt in der Mitte der Fläche interpoliert (0.5,0.5,0). Dieser Vektor hat aber nicht die Länge 1, wodurch das Licht schwächer wird als es eigentlich sein sollte.

Das sollte sich aber verringern wenn man den Zylinder feiner unterteilt. Wenn das bei dir nichts ändert, dann liegt es entweder an was anderem oder ich irre mich in Bezug auf die Lichtberechnung.