spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo! Mein erster Post hier .

Also, ich zunächst einmal mein aktueller Status:

Meine Klasse erstellt momentan einen Würfel. Jede dieser Seiten stellt eine Wurzel dar.
Daraus mache ich sechs Quad-Trees.
Das wird alles noch in der INIT-Phase vollzogen, also ohne Auswirkungen auf die Framerate.


Während der Update Phase wird der Baum unter folgenden Kriterien rekursiv durchlaufen:
Es gibt eine minimale und maximale Tiefe die erreicht werden muss/kann. Diese werden bei jedem
Aufruf dekrementiert. Zusätzlich gibt es eine Variable die die momentane Tiefe angibt.

Minimale Tiefe:
(Funktionsname BerechneWerte(Node, minTiefe, maxTiefe,maxEntfernung, EntfernungsMod)

Wenn min > 0
{
Wenn MomTiefe > 0
{
Wenn Winke (CamToViewTarget, CenterSphereToPoint) > 90°
Mach Nichts
Sonst
BerechneWerte(Node.Child[1 bis 4], minTiefe-1, maxTiefe-1, maxEntferung, EntfernungsMod)
}
}
Sonst
Wenn MaxTiefe > 0
Wenn Winkel(CamToViewTarget, CamToPoint) < SichtFeld
Wenn Entfernung(Cam, Punkt) < maxEntfernung
BerechneWerte(Node.Child[1 bis 4], minTiefe, maxTiefe-1, maxEntfernung--EntfernungsMod, EntfernungsMod
Sonst
Key = ÜberprüfeObPunkteBereitsInArray(Node) (Gibt entweder den Index des schon Bestehenden oder einen neuen Index wieder)
BerechneNormale(Node)
BerechneIndizes(Node)
Kopiere NodePunkte in Array
Füge Keys als Indizes hinzu.

So das läuft jede Update-Phase.
Ich habe es schon probiert als ÜberBedingung zu stellen, Sobald die Kameraposition oder Planetenposition sich von ihren alten Werten zu viel unterscheiden.
Das Problem ist dann aber, dass das ganze sehr stockend aussieht (Center of More Detail ist nicht in der Mitte bzw beim herauszoomen viel zu klein).

Es werden somit in jedem Update maximal 6*4^Tiefe Rekursionen durchgeführt. Was einiges an Rechenzeit brauch, selbst mit den Bedingungen:
Nicht Hintereinander liegende und nicht solche, die Außerhalb des Sichtfeldes liegen zu beachten.

Jetzt ist meine Überlegung Folgendes.
Init:
Ich erstelle für ALLE Planeten nur EINEN Quadtree. Somit habe ich die Ladezeit vor Eintritt im Spiel reduziert.
Der Quadtree speichert die Vertex-Positionen in globalen Lists und zwar in so vielen, wie MaxDepth-MinDepth.
Der Quadtree speichert die Indices in zu den Vertex-List passenden Index-Lists.
Da das vorher alles im Update war, wird der ganze Aufwand in Update beträchtlich reduziert.

Es werden nun so viele Buffer (Index/Vertex) erstellt, wie MinDepth Faces hat.

Update:
Berechnung der Nähe zu jedem MinLevel-Face (Nicht Sichtbar wegen Entfernung, Detail-Level-Entfernung)
Berechnung der Sichtbarkeit des MinLevels(Im Bezug auf Hintereinander liegen)
Daraus resultierend wird berechnet welcher Buffer welchen Anteil von welcher List bekommt.
Somit kann jedes Face detaillierter werden, ohne, dass die Listen berechnet werden müssen oder Quadtree durchlaufen,
da es alles vorher berechnet wurde. Das Ganze ist natürlich minimal so groß wie ein MinLevel-Face.

So dürften weitaus mehr Planeten darstellbar sein als einer, ohne die Performance-Einbuße eines ständigen Ladens.
Das kopieren in den Buffer an sich ist relativ einfach zu bewerkstelligen, da sich die Anzahl der Einträge pro Level
vervierfacht. Somit muss einfach nur das vierfache dessen geladen werden, wie zuvor. Der nächste Buffer muss dementsprechend
erst ab einer vierfach größeren Stelle laden usw.

Um natürlich unterschiedliche Planeten zu machen, kopiert sich jeder Planet die Listen (Index/Vertex) und manipuliert sie so.

Was haltet ihr davon?

Okay zur 1. Antwort.
Ungefähr das, was BlueCobold gesagt hat. Ich möchte eine Art Raumschiff-Simulation basteln, in der es möglich ist durch die Milchstraße zu düseln.

Zu BlueCobold. Es geht nicht darum, ob es langweilig ist oder nicht. Mag sein, dass es sich für mich als solches herausstellen wird.
Aber im Moment ist es für mich nichts weiter als ein Lernprozess. Ich stecke mir das Ziel, schaue grundsätzlich nach, welche Werkzeuge es dafür gibt,
und Modelliere dann so, wie ich es für richtig halte und bessere dann nach. Wenn ich an einen Punkt komme, der nicht mehr funktioniert, dann
überdenke ich nochmal und nutze die Erfahrungen aus dem vorherigen Schritt.

M.A. ist es schon möglich:
A) So ein ganzes Sonnensstem zu rendern, zumal die Planeten, die nicht sichtbar sind auch nicht gezeichnet werden, und da "nur" das Terrain für jeden Planeten
wirklich einzeln erstellt wird (die Detailstufen der Kugeln sind für alle da) ist die Ladezeit auch nicht das größte Problem.
Mein Problem bis jetzt war immer, alles in Echtzeit und in jedem Frame neu zu berechnen. Das wollte ich dadurch abstellen.

B) Eine gute Detailstufe beim hereinzoomen zu erreichen um das Terrain realistisch darzustellen, da es für jedes Face in der Low-Detail-Stufe einen Buffer gibt.
Somit haben diese Buffer zusammen eine enorm größere Aufnahme-Grenze als in der früheren Version, als ich nur einen Buffer pro Planeten hatte.

C) Der Baum dient "nur" dazu, intial die Vertices und Indices (für jede Detailstufe je ein Array) zu generieren. Die Planeten bekommen eine Kopie von diesen Werten und können (auch in der Init-Phase) dann ihre Terrains prozedural darauf gestalten.
Im Endeffekt teilt sich niemand etwas außer die Kugelstruktur. Wenn ich für jeden Planeten einzeln MAX-MIN-Detail Bäume rekursiv aufbaue (bei allen Planeten eines Systems + Sonne + Monde + evtl Gesteinsbrocken) habe ich dann einen Aufwand von: (x = Körper, i = aktuelle Stufe)
Summe von i = MIN bis MAX [ x*(6*4^i)].
Es mag vll wenig aussehen, wenn man das x einfach weglässt, gar irrelevant. Habe ich aber ca 10.000.000 Vertices allein für einen Körper (und das ist noch wirklich nicht sehr detailliert) habe ich für 10 Planeten dann 100.000.000 Vertices. D.H. die Laufzeit verzehnfacht sich tatsächlich. Einen Deal den ich ungern eingehe.

Ach ja. Ein letzter Punkt, weil ich nicht so ganz verstanden habe, was du damit meinst:

Zitat

Ich würde das aber auf keinen Fall die verwendeten Nodes eines gesamten detaillierten Planeten verwenden um daraus Low-Poly-Modelle während der Laufzeit zu berechnen

Wenn ich das richtig verstehe, denkst du, ich hätte "nur" ein High-Level-Modell und skaliere die dann runter.

In meinem Fall habe ich zu beginn einen Würfel, der wird rekursiv in einem Quad-Tree subdividiert und deren Vertices normalisiert,
bis ich ein bestimmtes Level erreiche. Das wird als Min-Level-Array gespeichert, von hier ab für jede neue Stufe wird ein neues Array für Indices und Vertices erstellt.
Ich berechne also rauf.