Guten Tag,
ich bin grad dabei ne kleine Engine zu schreiben und bin am verzweifeln Also es geht um die Map, die beleuchtet werden soll.
Meine vorgehensweise war - die betonung liegt dierbei auf war- folgendermaßen.
Der Boden wird mit runden Flächen aus der Lektion "Abseites Eckiger Welten" zusammengesetzt mit texturen überzogen
mir glEnable(GL_NORMALIZE) ; die Normalen generiert und das licht (hier die Sonne) einfach angeworfen.
Das Licht ist zwar an nur die Fläche reflektiert alles gleichermaßen. Also zum Licht und den normalen hab ich ein paar fragen.
Zunächst legen wir eben die Position des lichtes mal fest
Code:
const position : rray[0..3]ofSingle=(0,10,10,0;
glLightfv(GL_LIGHT0,GL_POSITION,@position[0]);
hier ist erstmal dier frage macht diese Position als Sonne überhaupt Sinn ?
1. Letzte wert ist null . Was beudeutet dieser Wert ? .. nun gutt. Eine Abnahme des Licht mit der Entfernung findet nicht statt, da die Sonne SEHR stark ist ^^.
3.so noch eine frage. Das ambiente licht hat keine Richtung. Das hieße doch, selbst wenn wir normalen hätten, würde kein Unterschied bei der Reflektion sein ?
jetzt haben wir unsere Sonne. Bravo Ist bis hierhin alles in Ordnung ? Oder macht etwas keinen Sinn ?
4.Jetzt kommt unsere Landschaft, die aus dreiecken beseht. Die berechnung der normalen erfolgt, so wir ich das verstanden habe, indem ich die 3 Punkte des dreiecks nehme und die multiplizieren. Also wie das funzt ka. hat da jemand ein beispiel, denn ich habe das im Tut nicht so ganz verstanden. Außerdem kann man diese normalen noch glätten oder so damit es runder aussieht ? .
Außerdem , wie berechne ich normalen für andere Flächen, z.b Runde Flächen (Abseits Eckiger Welten). oder Beispielsweise einer Viereckigen Fläche.
Oder aber mit 3ds Objekten. Sind da schon alle normalen dabei ?
Registriert: Do Aug 25, 2005 16:00 Beiträge: 189
Programmiersprache: Java, C#
zu Frage 2 und 3 kann ich dir die Antwort geben:
Die Farbwerte für den ambienten und diffusen Lichtanteil sind RGBA Werte.
Der erste Wert steht also für den roten Lichtanteil, der zweite für den Grünen, der dritte für den blauen und der vierte ist der Alphawert für die Farbe, also die Intensität.
Bei den restlichen Fragen bin ich im Moment auch überfragt...
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Deathball... Ich bin enttäuscht.
Der letzte Wert bei der Position ist 0 falls dein Licht direktional ist. D.h. Das Licht kommt aus einer Richtung, und die Lichtquelle Befindet sich unendlich weit weg. Dadurch sind die Lichtstrahlen alles Parallel zueinander. Das wird vorallem bei Sonnenlicht genutzt.
Mehr dazu in der Funktionsbeschreibung im Wiki: glLight (Da sollte man bei sowas immer zuerst gucken)
Glätten tut man diese indem man die Normalen in den Eckpunkten einer jeder Fläche berechnet. Da ein Eckpunkt an mehreren Flächen Teil hat, kann man einen Mittelwert für die Normale bestimmen. Diese wirkt dann abgerundet.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
OK. danke Aber was ist mit 3ds modellen. Sind da die normalen auch schon brerechnet ?
Gut . Wie man jetzt bei dreiecken die normale berechnet is ja klar.
Wir funktioniert das aber beim runden Flächen (Abseits Eckiger Welten).
Oder ist es besser seine ganze map nicht mit dieser Technik von runden Flächen zu zeichnen, sondern alles aus dreiecken und diese mit den normalen so zu manipulieren, dass sie rund wirken ?
Gut. Das mit den 3ds Modellen schein ein Problem von mehreren zu sein.
Egal. dazu les ich mir nochmal die fertigen Biträge durch.
Wie sieht es aber aus mit normalen bei dreiecken.
Ich glaube es ist am besten seine Welt aus vielen dreiecken zu zeichnen und diese so zu beleuchten dass e s rund erscheint ? d.h. für jedes einzelne vertex die normale berechnen? und hier schon meine erste Frage:
1. Ist das so korrekt? Oder werden outdoor welten eher nicht aus dreiecken gerendert ?
Gut. Weiter .
Um eine normale zu berechnen brauche ich immer drei Punkte.
Nehmen wir an wir haben zwei dreiecke, die aneinander liegen und ein viereck bilden.
Es gibt 4 Vertexe, a,b,c,d, wobei b und c die gemeinsamen vertexe sind.
um Normale der Fläche 1 zu berechnen nehme ich a,b,c. Um Normale der Fläche 2 zu berechnen b,c,d.
Jetzt hab ich zwei normalen und die Beleuchtung sieht sehr Eckig aus.
Wie würde ich jetzt bei diesen beiden Flächen ür jedes Vertex die Fläche berechnen.
Ich hab da was von Mittelwert gelesen aber nicht verstanden
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Kommt ganz auf die Landschaft drauf an.
Willst du eine standard Umgebung oder willst du Hölen, Kliffe, oder dinge die Künstlich erschaffen wurden.
Heightmaps finden in standard Terrain ihren Platz aber für eine ordentliche Umgebung sollten zusätzlich noch richtige Vertice Koordinaten her halten.
Ein extrem wichtiges Thema ist LOD hierzu.
Eine LOD,Heightmap,Offsetmapping,Bumptmapping umgebung kann so heftig aussehen, dass man denkt, es wäre fast echt.
LOD reduziert die Polyanzahl über die entfernung hinweg.
Heightmap liefert die Höhendaten aus den das Terrain errechnet wird.
Offset-Bumpmapping kann mit LOD kombiniert werden und die fehlenden Polygone sehr existent darstellen.
Die Berechnung würde mit in den LOD part fallen und müsste zur Laufzeit berechnet werden.
Du ermittelst du die Normal von deinem aktuellen Vertice und jedem anliegenden Vertice. http://wiki.delphigl.com/index.php/Normalen Die Normals sollten normalisiert sein. Die ermittelten Normals werden aufaddiert und durch die Anzahl der Normalen dividiert.
Die Neue Normal ist nun eine smooth Normal und sollte temporär gespeichert werden, bis alle Normals errechnet sind.
Erst dann kopiert man die smooth Normals über die aktuellen Normals, da sonnst bei der Berechnung Fehler auftreten.
In der Regel braucht man 4 normals pro Vertice und das wird ein bischen rechenaufwendig zur laufzeit.
Wenn es ein bischen schneller sein soll, dann kannst du auch einfach die Normal jedes Polygons errechnen und diese zusammen rechnen.
So geht die ganze angelegenheit 4mal schneller, ist aber nicht so perfekt im resultat.
Ich selber halte nicht mehr so viel von diesen Techniken und setzte da lieber auf ähnliche Verfahren wie bei Indoor.
Statisches Mesh ins VBO und über Octree, Occlussion culling und Possible Visible Tree die Leistung holen.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Gut, ich habe die ganze Zeit gedacht, ich könnte aus runden Flächen aus dem Kapitel "Abseits Eckiger Welten" ein Landschaft erzeugen ?!
Falsch gedacht oder ?
Nun gut, ich werde mich dann mal mit LOD, Heightmap und Bumpmapping auseinandersetzen.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Beschäftige dich lieber erstmal nur mit heightmaps und LOD, Bumpmapping ist eher erweitertes wissen.
http://wiki.delphigl.com/index.php/Tutorial Bereich Terrain und Landschaft
-alle tuts durchgehen
Bereich Rendertechniken
-beide tuts durchgehen
Wenn das alles läuft, dann kannst du die einzelnen module verbinden.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Im 3DS-Format werden keine Normalen gespeichert, sondern nur sog. Smoothing-Groups, aus denen dann die jeweilige 3DS-Importbibliothek recht aufwendig die Normalen errechnen muss. Der Loader von Noeska macht das z.B. nicht (liegt u.a. wohl auch daran dass die Smoothing-Groups schlecht dokumentiert und kompliziert umzusetzen sind, hab da auch mal was probiert) und berechnet die Normalen "blind", weshalb 3DS-Modelle dadurch oft falsch beleuchtet aussehen. Entweder muss man damit leben oder auf ein anderes, neueres Format umsteigen (3DS stammt noch aus DOS-Zeiten, weit vor der 3D-Beschleunigung oder gar 3D-Spielen). Ich persönlich bin auf DirectX-3D-Meshes (.x) umgestiegen und hab mir dafür nen Loader geschrieben. Da man die auch nach ASCII exportieren kann ists kein Problem nen Loader zu schreiben, und dieses Format speichert auch direkt die Normalen mit.
Nun gut. Hab mir jetzt Das Tut Heightmap und Tut HeightMap2 angeschaut.
Am anfang des Tuts Heightmap2, ist ein Bild indem sich Kenntisse aus Tut Heighmap und Tut Heightmap2 "vereinen" und eine schöne Heighmap ergeben.
Dreiecke bilden verschiedene Höhen je nachdem wie weiß die Heightmap ist. Je nachdem wie hoch das Dreieck ist, werden verschiedene Texturen genutzt. Soweit alles paletti.
Wie werden die zwei Tuts denn genau verbunden?
Im ersten Tut werden erstmal die Triangles geszeichnet anhand der Heightmap. Normalen werden berechnet, Licht wird angeschaltet usw.
Im zweiten Tut wird ein Bittmap erstellt. Jedes einzelne Pixel de Bitmap wird Prozentual mit verschiedenen HöhenImages belegt (also der Farbwert). Ich bekomme am schluss ein BILD. nur ein Bitmap eben ohne jegliches OpenGL sozusagen.
(Normalen wurden jetzt noch nicht berechnet. Auch kein licht und schatten, ich denke das ist auch nicht nötig wenn man diese Bitmap nur als Textur nutzen will. Ich eläutere gleich wie ich das mit der Textur meine)
wie werden nun diese zwei Komponenten nun zsammengesetz?
wird einfach das entstandene Bitmap über die ganzen Triangles gelegt ?
Reicht das ?
Achja und noch ne kleine Frage am rande. Ich mach mri jetzt schon sorgen wegen der performance Ich will auch später die Sich begrenzen, dass nicht alles gerendert wird. Aber dazu gibts bestimmt was in den Rendertechniken. Aber mal angenommen wir haben 140000 Treiecke, die alle 60 mal pro sekunde gezeichnet werden. Dazu wird bei jedem zeichnen die Normale,nicht nur für jedes Dreieck, sonder für jeden Vertex berechnet.
SCHAFFT DER DAS ? ..
Registriert: Sa Jan 01, 2005 17:11 Beiträge: 2068
Programmiersprache: C++
Du berechnest die Normale nur einmal und speicherst sie dann Aber im dritten Tutorial wird noch erklärt, wie man Dreiecke spart indem man ein LOD-System einbaut.
Edit1:
Zu der Frage wegen Terrain2:
Ja, du erhälst "einfach" eine Textur, die du auf die Heightmap legst. "Mehr" nicht
Edit2:
Übrigens kann der Originaltext weg, weil du ja kein Licht haben solltest, da die Schatten schon in der Textur für die Heightmap eingearbeitet sind, somit brauchst du die Normalen auch nicht mehr, da sie schon bei der Erstellung der Textur eingeflossen sind.
Wow,
das heißt also ich brauch garnichmehr ide Normalen für mein Terrain zu Berechnen.
Praktisch nur noch für Objekte , die später reinkommen. Häuser, ect. ?!
Achso. Noch eine frage zu drei bildern.
Bild 1:
sehr große dreiecke, dadurch Grobe Langschaft
Wenn man jetzt darüber diese Textur aus Heightmap2 legt, soll es so aussehen ?
ich denke hier sind die Dreiecke viel kleiner und viel mehr oder? ist das nötig oder reichen da die groben dreiecke ?
Weil hier sind nur 14 fps. Das ist zu wenig ^^.
die demo ist nur so langsam, weil hier knallhart mit aller gewalt alles per hand auf der cpu gerechnet wird massenhaft divisionen auftauchen und nirgends, aber wirklich nirgends optimiert wurde sondern nur das ziel war, die landschaft möglichst billig anzuzeigen - von der FPS lasse man sich bei dem Bild nicht beeindrucken Zur Auflösung der landschaft auf dem Bild kann ich im Nachhinein leider nichts mehr sagen.
Also für mich ist die Landschaft folgendermaßen aufgebaut.
1). Texture wird berechnet mit allen schatten und lichteinfällen und als Textur eben gespeichert.
2). Dann werden 104000 Dreiecke gezeichnet und die Dextur drübergelegt. Gibs doch nicht viel zu rechnen ?!
also ich mein divisionen. hm. Wo sollen da die divisionen sein ? und wie kann ich die verhindern. also optimieren, wie du sagtest ?
Wäre eine Optimieren (mal abgesehen von dem Kapitel Rendertechnik und Terrain Teil 3) z.b. Cullface und displaylisten, also glgenlist und sowas eben ?
Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.