Hallo erstmal!
Also ich bin ziemlicher Newbie in Sachen OpenGL, mit Delphi hab ich schon einige Erfahrung...
Also, wie schon im Betreff gesagt, brauche ich Hilfe bei Octrees!
Ich wollte ja ursprünglich BSP-Trees nehmen aber dann hat Son of Satan mir geraten, lieber Octrees zu verwenden!
Also hab ich das Tut auf gametutorials (oder so ähnlich) gelesen aber nix gerafft... vermutlich unter anderem wegen dem Englisch!
Also hab ich mir gedacht hier sind bestimmt ein paar (besser gesagt viele) Leute sind, die davon Ahnung haben!
Also ich hab z.Zt. weder einen Plan was Octrees sind noch wie sie funzen oder wie sie geladen werden...
Also meine Fragen:
1. Gibt es einen Leveleditor, der in diesem Format speichert (dann muss ich nämlich erstmal keinen eigenen coden, was bestimmt ne Menge Zeit spart!)
2. Was sind Octrees genau und wie funzen sie?
3. Wie kann ich sie mit OpenGL laden und darstellen?
4. Was ist der Unterschied zw. Octrees und z.B. BSP-Trees?

Ich hoffe ich bin euch nicht zu blöd und ihr helft mir, DANKE!!!

Tim

was octrees sind wird in dem OcTree tutorial hier von der Seite gut erklärt...

_________________
. . .

Uhhiii,
Ihr seid aber schnell hier, danke für die Antwort!
Aber ich kann unter www.delphigl.com / Tutorials nirgends ein Octree-Tut finden

Das liegt an der Umstellung der Tutorialsektion, da sind einige Tuts auf der Strecke geblieben, die aber demnächst wieder online gehen sollten.

Aber Octrees sind recht schnell erklärt :
Wie der Titel vermuten lässt, handelt es sich um einen binären Baum (wie es ein BSP auch ist, bloß halt anders unterteilt), der dazu dient die Zahl der pro Frame zu rendernden Dreiecke entsprechend des Betrachtersichtfeldes zu minimieren. Beim Octree (Oct = Acht) wird deine "Welt" (bestehend aus Dreiecken) in Boxen unterteilt, die Bezüge auf deine Dreiecke speichern. Diese Boxen werden dann solange in acht kleinere Boxen (deshalb Oct) unterteilt, bis eine jeweilige Box weniger als X-Dreiecke enthält. Dann wird die Subdivision gestoppt. Jede Box bestitzt da dann quasi acht "Kinder"-Boxen. Diese Unterteilung machst du einmal beim Laden des Levels.
Beim Zeichnen gehts dann ganz einfach : Du prüfst zuerst die Box die den ganzen Level umspannt darauf, ob sie im Frustum (Sichtfeld) liegt. Ist dies der Fall, prüfst du deren acht Unterboxen auf Sichtbarkeit, ist eine Unterbox sichtbar, prüfst du deren Unterboxen, usw. Und nur wenn eine Box auch im Frustum liegst, renderst du die Dreiecke die in dieser Box liegen. So sendest du im Endeffekt nur die Dreiecke an die Grafikkarte, die auch sichtbar sind. Würdest du blind alle Dreiecke an die Graka schicken, würde diese die zwar selbst cullen bzw. clippen, aber du hättest dann den Datentransfer aller Dreiecke auf dem Bus, was stark bremst.

Ein Octree ist auf aktuellen GPUs die binäre Raumunterteilungsmethode mit dem besten Verhältnis zwischen CPU und GPU, weshalb man diesen eigentlich den Vorzug ggü. z.B. BSPs geben sollte. Ausserdem sind Octrees z.B. im Gegensatzu zu PVS sowohl für Innen- als auch Aussenareale geeigent.

P.S. : Nen Editor der dir Octrees erstellt gibts AFAIK nicht, brauchst du aber nicht. Das Erstellen des Octrees ist nicht so sonderlich schwer, und da du ja nur die Dreiecksdaten deiner Szene brauchst, spielt dein Eingabeformat eigentlich keine Rolle.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ach du dicke Kacke, tut mir Leid aber DA hab ich trotz deinen Bemühungen nicht verstanden..
Ich kann quasi mit jedem Leveleditor ein Level bauen und dann per Octree anzeigen, weil Octrees nix mit dem Format (Dateiendung,...) zu tun haben, oder?
Also um des mit den Boxen stark zu vereinfachen (dass es auch in meine Birne geht) sieht des so aus:
Das Proggie läd immer nur den Teil des Levels (die Polys) die auch wirklich sichtbar sind,oder?
Also kannmir jemand mit einem Code-Snippet helfen?
Oder ein dt. Tut wäre super!!!
DAnke schon mal

Also Codesnippet kannste vergessen, denn die Erstellung eines Octrees und dessen Rendering kommt auf locker > 500 Zeilen (bei mir sinds knapp 600 Zeilen).
Und nein, das Programm lädt am Anfang den kompletten Level, denn es muss ja vom ganzen Level einen Octree erstellen. Es werden aber dann halt nur die Dreiecke gerendert, die sich in den sichtbaren Boxen befinden. Mit einigen wenigen 3D-Grundkenntnissen lässt sich so ein Octree vor dem geistigen Auge eigentlich leicht konstruieren. So kompliziert wie er evtl. klingt ist er eigentlich gar nicht. Deutsche Tutorials zu dem Thema kenn ich nicht, aber die von gametutorials.com sind doch so stark bebildert, das man eigentlich kaum noch Text dazu braucht.

Aber evtl. solltest du dich erstmal mit den 3D-/OpenGL-Basics beschäftigen, bevor du dich an nen Octree wagst. Den brauchste eigentlich auch erst dann wenn dein Level etwas komplexer wird. So ne kleine Map mit nen paar eckigen Räumen lässt sich auch Bruteforce rendern, ohne das du dir um die Geschwindigkeit Sorgen machen solltest.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wäre es sinnvoll / möglich dass ich einfach (z.B.) *.txt-Dateien nehme und darin irgendwie die Koordinaten speichere?
Also bei weniger komplexen Levels ist das sicher gut, aber bei komplexeren?
Mach das dann Sinn?

Das einzige Problem ist, daß die Dateien dadurch größer werden und die Ladezeiten natürlich länger sind. Aber wenn es nicht Millionen von Punkten sind, dürfte das für den Anfang erstmal reichen. Später kannst du das ja immer noch ändern und im Binärformat speichern.

Für nen Einstieg wäre so ne einfache Textdatei sicherlich das Leichteste, allerdings kannste komplexere Sachen damit total vergessen. An deiner Stelle würde ich lieber direkt ein besseres, verbreitetes Format wählen. Ich persönlich verwende 3DS und erstelle meine Maps/Objekte mit dem 3D-Studio. Nen passenden Loader dazu hat noeska ja in der Projektsektion bereitgestellt. Andere hier verwenden das Quake3-Format (entweder fertig kompiliert als BSP, oder roh als MAP), welches man mit dem Radiant erstellen kann. Hat natürlich den Vorteil das man für dieses Format nen Editor hat der auf das Erstellen von Levels für nen Ego-Shooter ausgelegt ist.
Im Endeffekt ist aber sowohl Format als auch Wahl des Editors eher Geschmackssache. Kommt halt drauf an was die besser gefällt, oder ob du bereits mit einem dieser Programme umgehen kannst.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi und danke für die Antworten!

Also ich hab auch schon drübernachgedacht, evtl. Quake-Files zu nehmen, aber dann brauch ich ja im Prinzip keine eigene Engine zu schreiben, da es ja schon die Quake-Engine gibt und ob man daran noch so viel verbessern kann...
Außerdem wollt ich sozusagen bei Null anfangen und alles selbst entwickeln, dasss ich dabei viel übe, ob das alles am Schluss so toll wird, das ist die andere Sache, ich will nur erst mal was ganz vom Anfang an uf die Beine stellen und desshalb wäre ich für ein eigenes Format, eine eigene Art die Levels zu saven und (logischerweise) auch zu laden

erstmal reicht ess allemal, wenn du aus einem Textfile das Level lädst... wenn du dann mal soweit bist, dass das auslesen zu langsam wird, dann ist ein Umstieg auf Binärdateien auch nicht so wild...
konzentrier dich am Anfang auf OpenGL
auf www.sulaco.co.za gibts überigens eine Mini-"Engine", wo das Level aus einer txt datei geladen wird... kannste dir ja mal ansehn

_________________
. . .

Von der Idee ne eigene "Engine" als Übung zu schreiben, wurde hier im Forum schon mehrfach abgeraten. Es wird dich mehr nerven als vorwärtsbringen. Und je weiter du kommst desto mehr fällt Dir auf was du schon von anfang an falsch gemacht hast. Am Ende baust Du nix neues in deine "Engine" ein sondern schreibst sie nur um.

Es gibt soviel verschiedene Sachen die man mit OpenGL machen kann, wieso solltest Du als Anfänger gleich ne Engine schreiben wollen?? Engine brauchst Du eh nur, wenn du ein und den selben Code für mehrere Projekte verwenden willst und da kommst du bestimmt mit Managern (SOS benutzt auch welche und erfindet das Rad nicht immer wieder neu) besser.
Also vergiss die Engine und bastel lieber ein Einfaches Spiel. Das kannste dann mit all dem OpenGL Schnickschnack ausstatten wie es Dir beliebt.

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

Ein minimaler Quake3 Level Viewer kommt im Idealfall mit wenigen hundert Zeilen Quellcode aus und ist eine ideale Übung, weil man schon eine Menge Daten zum Testen hat und man gleich zu schönen Ergebnissen kommt. In Quake3 Leveln ist nämlich alles schon fertig berechnet. Der BSP Baum und die Lightmaps müssen nur eingelesen werden und auch die Sichtbarkeitsinformationen sind bereits vorhanden.
Für eine eigenen Engine lohnt es sich nicht unbedingt das Quake3 BSP Format zu übernehmen, weil man sich dadurch auch ein wenig beschränkt. Aber nur mal zum Test ist das sicherlich keine schlechte Sache mal ein Quake3 Level zu laden und anzuzeigen weil man dadurch sieht wie es gemacht wird und so Anregungen bekommt.

Danke für die schnellen,vielen Antworten!

Ich hatte sowieso vor, wenn die kleine Engine fertig ist, erstmal ein Game damit zu coden und dann auf diese Art und weise zu lernen!

Weil durch eine engine, wird es ja leicher, später das eigentl. Spiel zu coden!

Meine Prophezeiung dazu ist, dass du mit der Engine überhaupt nie zum Spiel basteln kommst.

Bau einfach ein Spiel so wie dus im Dos modus auch machen würdest (irgend was simples so Richtung 4 gewinnt) und mach die ausgabe komplett in 3D. Wenn du das Spiel erstma soweit hast das du weißt wie's geht kannste nochma über ne engine Nachdenken.

Auch wenn du dich total für Ego Shooter begeistern kannst, heißt das noch lange nicht, dass dein erstes 3D projekt gleich sowas sein muss. Fang einfach an und steiger dich. Die Engine wird dich am Anfang nur hindern, weil du nichts sichtbares hast, sondern nur ein Haufen Code was machen könnte(!) wenn er denn irgend wann mal fertig wird.

Schieb die Engine erstma nach hinten raus und fang einfach an. Du tust Dir damit einen gefallen.

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