Das mit dem "kleiner" und "ineinander" versteh ich nicht.
Es wird dann doch immer schwerer den Kollisionsort zu berechnen weil ja der LOD dafür einigermaßen mit dem sichtbaren LOD übereinstimmen sollte (wenn sichtbare LODs und LODs für andere zwecke unterschiedlich/simpler sein sollen).
Ich dachte immer dass die Engine versucht alle LODs eines Objekts in den VRAM zu schaufeln um das LOD-switching bei schnell bewegten Objekten oder wenn man sich selbst schnell bewegt recht fluffig zu machen.
Zitat:
Die LODs dienen zwei Zwecken: Sie sollen als "Platzhalter" für Objekte dienen, wenn jemand nur schwache Grafikeinstellungen vornehmen kann.
Sehr gut zu sehen wenn man spawned oder neben einem spawnenden "Ding" steht. Erst gibt es ein paar Geometrie-Anschauungsobjekte und irgendwann erkennt man was es sein soll.
Zitat:
Das "Negativ" der derzeitigen Grafik wäre übrigens, wenn man zuerst den höchsten Detail-Level anbietet und die Maschine sich den passenden darunterliegenden LOD herausnimmt und abbildet. Diese Denkweise ist typisch menschlich, weil sie keine Gleichzeitigkeit in Betracht zieht.
Mir ist die "Gleichzeitigkeit" nur geläufig im Sinne von Gleichzeitigkeit aller Ereignisse zwischen den Clients via Server wahren.
Früher war das nutzen des "billigsten" LODs logisch weil man den ja erst von der Platte kratzen muss. Und VRAM war rar.
Jetzt eben anderer Design-Ansatz. "Alles" im VRAM, SATA und PCI-Bus fallen als Flaschenhals weg, Grenze ist die GPU, Speed und Größe des VRAM und der Himmel.
Den LOD wollte ich auf den "fettesten" limitieren weil ich annehme das bei sagen wir mal 5 LODs die Summe der unteren 4 LODs zusammen die größe des fettesten LODs hat.
Ergo kann man den Speicherbedarf halbieren wenn man nur den "fettesten" nimmt. Schlagt mich wenn ich da falsch liege. Kann mal ein Kenner rausbekommen wieviel GB die LODs aller BIS addons sind und die von ACE 2?
Das ganze Kartenhaus fällt natürlich zusammen wenn man nur soviel VRAM hat das 1-2%+ der LODs nicht rein passen weil man dann noch ein VRAM managment braucht was die wahrscheinlichkeit des Bedarfs von LODs berechnen muss sonst ruckelts doch immer wieder. Und wird nie funzen.
Der Ansatz legt sich voll auf die GPU weil die ein fetten LOD bei entfernten Objekten auf die Darstellung mit wenigen Pixeln runterrechnet. Dafür sind die "leichten LODs" ja schon optimiert.
Aber mein alter Leitsatz: Ich bin Unwissend. Aber wenn ich mir in meiner Unwissenheit etwas vorstellen kann, hat es irgendein Wissender auf der Welt schon gebaut.
SUCHT IHN! 