4. Terraingröße und Speicherausnutzung

Terraingröße und Speicherausnutzung

  • D

    Also ich weiß ja nicht, ob ich nicht mal wieder offene Türen einrenne, aber was solls..

    Ich bin am Überlegen, ob es sinnvoll ist, sich einen größeren Terrain so einzuteilen, daß man immer nur Teile aus einer Datei liest.
    Quasi würd ich immer nur einen Viewport herausladen auf dem man sich bewegen kann. Ist der Spieler etwas außerhalb der Mitte des Ganzen (beispielsweise ist der Viewport 150 * 150 Meter und die Mitte definiert jeweils 1/3 der Seitenlängen) wird einfach Viewport neu geladen.
    Ist das überhaupt sinnvoll?
    Ich meine, bei beispielsweise 4000 * 4000 Pixeln á 1 char (1 Pixel wird bei mri 1 Meter) lade ich "lediglich" 16 MB in meinen RAM.. Das ist eingentlich noch etwas, das nen heutiger PC problemlos und ohne großen Rechenaufwand verwalten kann.

    Ich würde mir den Viewport dann aus dem schnelleren RAM holen und die Platte entlasten.

    Also was mir fehlt ist eigentlich nur die Dimension, ab der man lieber fragmentiert lesen sollte.. Kann mir da wer nen sinnvollen Tipp geben?

    0
  • C

    DocJunioR schrieb:

    Ich bin am Überlegen, ob es sinnvoll ist, sich einen größeren Terrain so einzuteilen, daß man immer nur Teile aus einer Datei liest.

    Klar, das ist eines der Features mit dem alle Hersteller von Outdoor Spielen angeben.
    "Riesige Terrein -- keine Ladezeiten" .. usw.

    DocJunioR schrieb:

    Quasi würd ich immer nur einen Viewport herausladen auf dem man sich bewegen kann. Ist der Spieler etwas außerhalb der Mitte des Ganzen (beispielsweise ist der Viewport 150 * 150 Meter und die Mitte definiert jeweils 1/3 der Seitenlängen) wird einfach Viewport neu geladen.
    Ist das überhaupt sinnvoll?

    Naja, damit das ganze effizient läuft, muss es wohl im Hintergrund ständig nachgeladen werden. Ich weis nicht, wie das bei Spielen gemacht wird, aber ich stell mir das so vor:
    - Die Landschaft ist räumlich in Knoten unterteilt, die ihrerseits wieder unterteilt sind, bis man eine gewünschte grösse erreicht. (Ich glaube Octrees sind bei Outdoorszenen populär)
    - Man hat die Landschaft in einer Struktur, in die dynamisch Knotenpunkte entfernt und hinzugefügt werden können.
    - Für jeden Knotenpunkt ist vorberechnet, welche anderen Knotenpunkte von ihm aus sichtbar sind.
    - Im Hintergrund läuft ein Thread, der Überprüft wo sich der Spieler befindet und nach Bedarf Knotenpunkte einhängt oder entfernt
    - Sollte wider erwarten der Scenenmanager einen Knotenpunkt darstellen wollen, der nicht geladen ist kommt ein "Bitte warten" Fenster und der Knoten wird geladen

    DocJunioR schrieb:

    Ich meine, bei beispielsweise 4000 * 4000 Pixeln á 1 char (1 Pixel wird bei mri 1 Meter) lade ich "lediglich" 16 MB in meinen RAM.. Das ist eingentlich noch etwas, das nen heutiger PC problemlos und ohne großen Rechenaufwand verwalten kann.

    OK, ich komme grade drauf das du das ganze für ein 2D Spiel brauchst.
    Da ist es noch einfacher: Die Landschaft ist in Quadrate unterteilt und du holst dir jeweils die an den Viewport angrenzenden quadrate bis zu einer gewissen Entfernung, je nach verfügbaren Speicher.

    DocJunioR schrieb:

    Ich würde mir den Viewport dann aus dem schnelleren RAM holen und die Platte entlasten.

    Also was mir fehlt ist eigentlich nur die Dimension, ab der man lieber fragmentiert lesen sollte.. Kann mir da wer nen sinnvollen Tipp geben?

    Ich würde sagen: den verfügbaren RAM maximal auslasten. Aber nicht darüber, denn dann fängt das OS zu swappen an. Und es ist wahrscheinlich das du das mit intelligenten (lies: an die Problemstellung angepassten) Algorithmen effizienter hinbekommst.

    0
  • D

    naja, das OS swapt auch ohne, daß es ausgelastet ist..

    Also werd ich das Ganze wohl mittels Threading bauen müssen..
    Naja, kommt man wohl bei Spielen eh seltenst drum rum..

    0
  • L

    Ich benutze für die jetztige Terrainengine auch filemapping, jedoch benutze ich einfach die von windows bereitgestellten filemapping Funktionen (http://www.flipcode.com/articles/article_filemapping.shtml). Damit kann man einfach wie gewohnt die heightmap direkt dereferenzen und das in Ram rein- und rausladen geschieht voll automatisch und optimiert. Das klappt zumindest bis 2^32 byte sehr gut.. Wenn deine heightmap größer wird, musste wieder kreativ werden, aber normalerweise sollte das nicht der Fall sein ;).
    Damit jedoch auch möglichst wenig "Blöcke" geladen werden müssen, hab ich die Indexstruktur noch auf meinen lod-algorithmus optimiert, indem ich die Indizies entlang einer hierarchischen Hilbertkurve lege. Damit versuche ich sicherzustellen, dass Punkte, die häufig genutzt werden, möglichst im File zusammenliegen und außerdem Punkte, die im Terrain dicht beieinander liegen, auch möglichst im File zusammenliegen. Wie man das am besten erreicht hängt natürlich von deinem LOD Algorithmus ab..

    @chockoCookie Es geht hier um das Cachen der Heightmap und nicht um dessen Darstellung mit Hilfe von Quadtrees o.ä. .. und btw. "- Für jeden Knotenpunkt ist vorberechnet, welche anderen Knotenpunkte von ihm aus sichtbar sind." ist wohl "leicht" überzogen 😮 ..

    0
  • C

    life schrieb:

    @chockoCookie Es geht hier um das Cachen der Heightmap und nicht um dessen Darstellung mit Hilfe von Quadtrees o.ä. .. und btw. "- Für jeden Knotenpunkt ist vorberechnet, welche anderen Knotenpunkte von ihm aus sichtbar sind." ist wohl "leicht" überzogen 😮 ..

    Ja, das habe ich bemerkt, als ich den ersten Teil geschrieben hatte (wie angemerkt) aber ich wollte es trotzdem stehen lassen, ich dachte mir vielleicht würde jemand der Erfahrung damit hat was dazu schreiben und damit die Wissensbasis des Forums erweitern ;).
    Und meine Überlegungen waren auch nur prizipieller Natur, klar das man aus Speichergründen die Sichbarkeitsinformationen von mehreren Knotenpunkten in einen übergeordneten zusammenfassen würde.
    Mich würde interessieren ob das in den Grundzügen so stimmt.
    Es wäre auch interessant wie gut die generischen Windows filemapping funktionen arbeiten im vergleich zu einem Angepassen Algorithmus, der Informationen darüber hat, was wahrscheinlich demnächst benötigt wird.

    LG Chocko

    0
  • L

    ChockoCookie schrieb:

    Und meine Überlegungen waren auch nur prizipieller Natur, klar das man aus Speichergründen die Sichbarkeitsinformationen von mehreren Knotenpunkten in einen übergeordneten zusammenfassen würde.
    Mich würde interessieren ob das in den Grundzügen so stimmt.

    es gibt viele algorithmen fürs occlusion culling. So kann man z.b. ausgehend von einem vertex die anderen vertices in n sektoren unterteilen und dann alle vertices in einem sektor mit einer convex hülle überziehen und dann den maximalen "horizont" für diesen sektor ausrechnen und die information dann abspeichern...

    Es wäre auch interessant wie gut die generischen Windows filemapping funktionen arbeiten im vergleich zu einem Angepassen Algorithmus, der Informationen darüber hat, was wahrscheinlich demnächst benötigt wird.

    LG Chocko

    ich denke nicht, dass man da sehr viel optimieren kann, aber das ist normalerweise auch nicht der zeitfresser bei der engine ;). Außer man macht vielleicht nen flugsimulator oder so, wo sich das terrain sehr schnell ändern muss (und sehr viele daten aufeinmal neu geladen werden müssen)..

    0
  • D

    Ich denk mal, ich bin schon froh, wenn ich über nen Heightmap laufen kann..

    0
Anmelden zum Antworten