wenn ein dreieck aus drei vertices aufgespannt wird, dann gibt es genau eine ebene in der alle drei punkte liegen, mit der berechnung s.o. errechnest du die normale zu dieser ebene, diese setzt du dann für alle drei vertices des dreiecks ein.


ps: schau dir doch einfach glNormal im Wiki an :

_________________
www.extrawurst.org

Ja, das war mir auch klar. Ich versuche mein restliches Problem anders zu formulieren:
Jedes Vertex meines Körpers ist Eckpunkt von 3 verschiedenen Dreicken, von denen jedes eine andere Fläche aufspannt. Wie also setze ich jetzt die Normale für diesen Vertex?

Vorrausgesetzt du renderst deine Dreiecke in etwas wie folgt.


Evtl zeichnest du auch mehrere Dreiecke auf ein mal. Aber du hast für jeden Vertex eines Dreiecks einen Aufruf. Bei einer Pyramiede mit 4 Seiten hast du 12 Vertexaufrufe ob wohl du nur 5 wirkliche Vetrexe hast. Das bedeutet du hast in wirklichkeit 12 Vertexe. Die aber im nachhinein zu 5 "veschmelzen". Diese könnten aber durchaus auch eigenständige Koordinaten haben.

Und jeder Vertex darf eine eigene Normale haben. Somit könntest du 4 Vertexe haben die alle auf dem selben Punkt liegen aber Bestandteil unterschiedlicher Dreiecke sind und somit auch unterschiedliche Normalen haben können.

Wenn du mit Trianglestrip, Trianglefan oder ähnlichem renderst, dann hast du auch nur wirklich 5 Vertexe womit deine Aussage vollkommen stimmt. Mit einem Trianglefan wäre es nicht möglich, dass du die Flächennormalen benutzt. In diesem Fall müsstest du dann dazu greifen, dass du den Fan/Strip in einzelne Dreiecke zerlegst.

PS: Bei intensiven Berechnungen bietet es sich an die Daten zu Cachen. Also entweder Clientseitig, in einer Displayliste oder per VertexBufferObject.

Also werde ich das jetzt wie folgt machen:
Ich erstelle das Objekt per GL_COMPILE mit ner Liste und mache für jedes Dreieck 3 Vertice, die dann ja von der GraKa/Treiber evtl. verschmelzen und/oder optimiert werden. Dann werde ich für jedes dreier-Paar eine eigene Normale errechnen und sie mit glNormal angeben. Soweit alles richtig verstanden?

Soweit alles richtig. Ich denke mal bei den paar Punkten sollte es sogar durchaus ohne Probleme gehen, wenn du diese bei jedem Renderdurchgang berechnest. Das das aber nicht wirklich optimal ist muss man glaube ich nicht erwähnen. Aber vom Aufwand her noch überhaupt kein Ding. So lernst du aber auch Listen.

Ach ja. Ne kleine Anmerkung habe ich aber dennoch. Also speziell zu dem was ich selber gesagt habe. War vielleicht ein "bisschen doof" ausgedrückt. Die Punkte verschmelzen nicht. Auf Grafikkartenebene werden die Flächen immer als Dreiecke betrachtet. Und dann sind die Punkte auch losgelöst. Aber bei der API (OpenGL) ist es bei einem Fan so, dass man enorme Bandbreite sparren kann, da equivalente Punkte nur noch ein mal angegeben werden müssen. Bei einer Pyramide ersparrt man sich 7 Vertices, was mehr als 50% Ersparrnis ausmacht. Bei größeren Landschaften etc. kommt da schon ein stattliches Sümmchen zu stande. Allerdings hat man so das Problem, da man nur eine Normale pro Vertex angeben kann. Wodurch Flachennormalen recht schlecht lösbar sind. Bei komplexeren Objekten (Kugel) wird man aber wohl sowieso eher Punktnormalen angeben. Also die Flächennormalen der angrenzenden Flächen interpoliert.

Listen kann ich schon =) Arbeite ich häufiger mit...

Aber nochmal zum Thema: Wenn ich in ner Liste viele Punkte angeb, dann ist das ja schneller, als wenn ich beim Rendern viele Punkte angeb, weil er sie bereits auf der GraKa speichert. Aber mal zum Optimieren bzw. "Verschmelzen": Wenn ich einen Punkt mehrfach verwende, für viele Polygone, dann behält das die GraKa bei? Sie optimiert nicht? Auch nicht, um Speicherplatz zu sparen?

Wie siehts mit der optimalen Strategie aus? Wenn man kleine Objekte hat (klein = Polygonarm), dann berechnet man sie am besten Live, richtig? Wäre es dann klüger, Strips und Fans zu benutzen oder ist das egal? (Beachte: Bei kleinen Objekten) (Mal vom Normalen-Problem abgesehen)

Bei größeren oder SEHR häufigen Objekten ist dann sicher die Liste vorteilhafter. Aber dort ist es dann egal, ob mit Strips oder ohne, stimmts?

So Leute,

ich hab die Normalenberechnung eingefügt.
Das Ergebnis hänge ich an.

Diesmal im Vergleich: gluSphere mit 4/2 (Slices/Stacks) und mein Objekt.
Sichtbare Verbesserung im Bereich der verteilten Beleuchtung (GUT!!)
Aber: Auf der gluSphere sind die Kanten schöner "schattiert", woran liegt das? Werden die Normalen dort interpoliert?

So viele Fragen auf ein mal. Dann fange ich mal oben an.

DL: Die Grafikkarte kann die Displaylisten optimieren. Das würde sie tun in dem sie die Vertexdaten in den Speicher der Grafikkarte auslagert. Aber nicht alle Karten unterstützen das Auslagern. Also kann eine DL mitunter genau so langsam sein wie das iterative rendern. Das aber auch nur auf sehr alten Karten die es immernoch gibt. Das heißt eine DL muss nicht zwingend schneller sein. Heutzutage kann man aber davon ausgehen, dass eine DL schneller ist.

Und wenn du in eine DL nur dreiecke packst dann bleiben es auch nur dreiecke. Ich glaube nicht, dass der Treiber das optimiert. Der Aufwand so etwas automatisch zu optimieren dürfte ziemlich häftig sein. Vor allem, da bei einem bisschen zu viel optimierereien dann die Daten verändert werden würden.

Grafikkarte: Die Grafikkarte kennt nur Dreiecke. Alles was du hast wir von der Grafikkarte immer in Dreiecke zerlegt. Render mal ein Quad bei dem ein Punkt weiter oben ist. Du wirst dabei ganz klar erkennen, dass dort ein Knick in der Fläche ist. Der aber mitunter auch so aussehen kann, dass eine Art Steg zu dem höheren Punkt aufgebaut wird. Die zusätzlichen Objekte sind nur dazu gut um den Entwickler und die Schnittstelle zu entlasten.

Live oder nicht Live: Ich denke mal es kommt immer darauf an was du vor hat. Wenn du mit VertexBufferObjects arbeitest bietet es sich eigentlich an alles auf der Grafikkarte abzulegen. Aber teilweise ist es einfach so, dass du wesentlich mehr Verwaltungsaufwand hättest als wie wenn du es direkt renderst. Also für ein weißes Quad oder ein simples HUD lohnt es wohl eher nicht ein VBO zu erstellen und dort die paar Flächen abzulegen. Der micromale Geschwindigkeitsvorteil dürfte den Verwaltungs/implementations-aufwand wohl eher nicht gerecht werden.

Dreiecke, Fans und Strips: Sofern diese nicht iterativ gerendert werden sollte es auf modernen Grafikkarten kaum einen Unterschied mehr geben. Sofern du diese aber iterativ renderst hast du natürlich eine Vielzahl an OpenGL Aufrufen. Also im Vergleich Dreiecke zu Strips. Das macht sich natürlich richtig bemerkbar.

Wenn du die Datem mit einem VBO allerdings im Speicher ablegst wirst du recht schnell merken, dass ein Strip wesentlich Speicherärmer ist als die direkten Dreiecksdaten. Aber eine Vielzahl an Dreiecken in Strips zu zerlegen ist ziemlich komplex.

Bild und Licht: Bei der Glut hast du Weiche Lichtkanten eingestellt. Du müsstest pro Vertex weiche Normalen berechnen. Sprich, dass du bei einem Punkt die Flächennormalen der benachbarten Flächen nimmst und diese interpolierst. Aber wenn du das so machst hast du wieder 5 equivalente Vertices. Dann könntest du wieder mit dem Fan arbeiten. Argh. Ich glaube das wolltest du jetzt nicht hören, oder?

Vielen, vielen Dank für die Erklärungen.

Fragen:
Dass DLs nicht zwingend schneller sind, ist okay, aber sie sind auf keinen Fall langsamer, richtig? (So dass eine Auslagerung auf DLs die gleiche Geschwindigkeit oder eine höhere zur Folge hat)

Wenn ich weichere Lichtkanten malen will, muss ich dann selber interpolieren, oder kann er das aus den vorhandenen Normalen selbst berechnen?

Anmerkung: Ich sprach von GLU... nicht von glut.

Was sagts Du zu dem Screenshot? Ist das suboptimal oder ist das alles, was man mit wenigen Polygonen und verzicht auf BumpMapping und Shader rausholen kann?

Ja. Ist richtig. Das ist eine Sache die ich permanent verdrehe.


Richtig. Und bei DLs werden die berechneten Normalen ja auch zwischengespeichert.


Ich meine es geht andersrum. Als das OpenGL die Flächennormalen anhand der Vertexnormalen berechnet. Wenn du die Vertexnormalen haben willst nimmst du die umliegenden Flächen und Addierst die Vektoren einfach. Damit bekommst du dann einen Vektor der die Normale des Vertices beschreibt. Diesen müsstest du dann noch auf 1 normalisieren. In deinem Spezialfall kannst du aber für die Normalen aber die entsprechenden Achensichtungen benutzen. Da die Vertices alle genau auf den Achsen liegen. Vorrausgesetzt Koordinatenursprung ist der Punkt in der Mitte des Objektes. Aber das würde nur hier gehen.


Das kommt immer darauf an was es darstellen soll. Wenn es etwas glänzendes sein soll, dann würde ich die normalen durchaus schon auf Flächennormalen lassen, da das Objekt nun mal große glänzende Flächen hat. Wenn es aber ein mattes Objekt sein soll, dann sollten die Normalen entsprechend auf die Punkte gesetzt werden. Aber sonst schaut es schon gut aus. Aber eine Sache irritiert mich geradeDas Licht bei der Kugel ist oben rechts. Bei deinem Objekt aber unten links. Ich weiß nicht ob das so 100% richtig ist.

Aber sonst denke ich mal würden sich Shader eher bei komplexeren Objekten bzw. Spotlichtern lohnen. Vieles wird in den Spielen sowieso eher durch statische Lichter (Lightmaps) realisiert. Dynamische Lichtquellen über Multitexturing/Multipass Renderverfahren oder eben über Texturen. Wobei es für Spotlichtern auch eine Möglichkeit gibt Texturen zu Projezieren. Ich glaube Shader sind da ein viel zu häufig fallendes geiles Modewort. Ähnlich wie es immer wieder einen Hype um "Engines" gibt.

Na matt und glänzend wird ja nicht über die normalen sondern über die Materialeigenschaften gemacht.

Die normalen sagen viel mehr etwas über die härte der Kanten aus. Wenn du z.B. eine Kugel nimmst und dort die Normalen nicht interpolierst sieht die kugel nicht mehr rund aus, sondern man sieht die einzelnen Flächen. D.h. die Kanten treten härter hervor.

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

Diesen Abschnitt kannst Du grad nochmal umformulieren bzw. mehr erläutern. Ich hatte beim Lesen Schwierigkeiten.


Ja, das irritierte mich auch, aber das ist inzwischen hinfällig, weil ich das Licht jetzt erst hinterher hinzufüge...


Ach Du hast doch keine Ahnung! In meine Engine müssen unbedingt noch viele Shader rein! </Spaß>

Flash: Ja das stimmt schon. Nur bei dem Objekt kannst du den Glanz nicht alleine durch die Materiale lösen da musst du schon dafür sorgen, dass die Normalen den Effekt noch untermauern. So meinte ich das doch.

Ich glaube ich sollte das heute mit dem Schreiben lassen. Irgendwie kann ich mich nicht ausdrücken.


Dafür aber Moderatorenrecht, mit denen ich solche Kommentare löschen kann.


Also das war auf den ShadeModel bezogen. Ich meine der passt auch die Normalen so an, dass die Lichtberechnung aussieht wie mit Flächennormalen.

Das zweite war der Weg wie du weiche Vertexnormale berechnen kannst. Also die Summe der einzelnen Vektoren bilden und dann normieren. Als Kurzfassung.

Das Letzte war eigentlich nur eine Beschreibung wie deine Normalen aussehen müsstest. Da alle Punkte deines Objektes sich auf einer Achse befinden wären die weichen Koordinaten direkt der Vector der entsprechenden Achse. Also (x = 0, y = 0, z = 1) und (0, 0, -1) für jeweils die Z Achse. Nach hinten und nach vorn. Und so weiter. Das aber nur in diesem einen Fall.