Newdark Limits

    Ich bin gerade dabei, die Newdark-Grenzen auszuloten. Hier sieht man ein Bild eines Versuchslevels. Wie man sieht, werden in dieser Szene mehr als 23000 Polys gerendert. Natürlich ist eine solche FM unspielbar. Aber gut zu wissen, dass es möglich ist.


    Ich hätte einige Fragen:
    Das WorldRep-Cell-Limit liegt angeblich bei 32760. Wo in Monolog steht die entsprechende Zeile? Gleich nach csmerge?


    Welches ist die größte bislang veröffentlichte FM in Sachen WR-Cells? Vielleicht hat sich ja schon jemand damit befasst.


    Edit: Ich habe eine riesige Textmap erstellt (2000x2000 Units) mit vielen verschieden Brushes



    *das ist übrigens diesselbe Zahl, die unter csmerge steht.
    Noch ein einziger Brush mehr und portalise klappt nicht mehr. Optimize versagt schon längst den Dienst (man muß Area-Brushes verwenden und stückweise arbeiten)
    Im Spiel merkt man übrigens nichts davon. Es läuft ganz normal.

    (Fazit unten)
    Zuweilen kommt es in DromEd zu Fehlermeldungen beim Optimieren, nämlich, wenn man bestimmte Grenzen erreicht:
    MAX_GLOBAL_RENDER und
    MAX_GLOBAL_POINTS



    Ich habe dazu einige FMs getestet und verglichen
    Zunächst eine eigene Test-FM mit 2000x2000 Units. Sie ist vollgestopft mit vielseitigen Zylindern and Dodecahedrons, dazu verschachtelt. Optimize geht noch gut

    Code
    Eigene Testmap--------------- csgmerge ---------------Epsilon is 1.e-004File has 19813 cells.Allocations: 19814Min: -1541.1672 -1929.3213 -921.875Max: 1205.7419 1836.1686 520.25Input polys: 63609Unique planes: 9194Unique render aspects: 7849Unique vertices: 78641Allocations: 146908Merges made: 32989Merges with internal colinear points: 00 colinear points deletedAllocations: 90124Discarded degenerate polys: 62Current allocations: 19960Max allocations: 146909Releasing remaining allocs: 19960------------- csgmerge end -------------


    Ich kann auch noch mehr hinzufügen. Optimize geht immer (noch)

    Code
    Eigene Testmap--------------- csgmerge ---------------Epsilon is 1.e-004File has 20214 cells.Allocations: 20215Min: -1745.4189 -1623.1268 -921.875Max: 1192.9919 1836.1686 520.25Input polys: 64746Unique planes: 9334Unique render aspects: 7992Unique vertices: 80151Allocations: 149579Merges made: 33276Merges with internal colinear points: 00 colinear points deletedAllocations: 92361Totally coplanar... ick.Discarded degenerate polys: 64Current allocations: 21330Max allocations: 149580Releasing remaining allocs: 21330


    Wenn ich aber auch nur einen einzigen Brush hinzufüge, kommt eine Fehlermeldung:


    Code
    --------------- csgmerge ---------------Epsilon is 1.e-004File has 20511 cells.Allocations: 20512Min: -1745.4189 -1866.1963 -921.875Max: 1192.9919 1836.1686 520.25ERROR: Increase MAX_GLOBAL_RENDERCurrent allocations: 144456Max allocations: 144456Releasing remaining allocs: 144456------------- csgmerge end -------------WARNING: Optimization failed, level remains unoptimized!


    Schaut so aus, als ob eine Grenze erreicht sei. Aber welche? Jedenfalls nicht das WR-Cell limit, das liegt höher. Es muß ein anderes sein.


    Ich lud Beltzers "The Favour" in DromEd. Eine große Mission, die sich prima für Testzwecke eignet (wie sich später herausstellen sollte)


    Beltzer: The Favour

    Code
    --------------- csgmerge ---------------Epsilon is 1.e-004File has 23100 cells.Allocations: 23101Min: -104.5 -206.25 352.5Max: 670.75 683.625 559.01843Input polys: 68923Unique planes: 5220Unique render aspects: 2755Unique vertices: 84861Allocations: 160847Merges made: 40178Merges with internal colinear points: 00 colinear points deletedAllocations: 85711


    Nun habe ich Unmengen Multibrushes (Zylinder, Dodecahedrons, usw) in Beltzers Map eingefügt, bis zu diesem Punkt

    Code
    --------------- csgmerge ---------------Epsilon is 1.e-004File has 30608 cells.Allocations: 30609Min: -905.63165 -976.36102 352.5Max: 922.14026 889.33569 689.78076Input polys: 98029Unique planes: 10900Unique render aspects: 7349Unique vertices: 121984Allocations: 226531Merges made: 53587Merges with internal colinear points: 00 colinear points deletedAllocations: 130257Totally coplanar... ick.Totally coplanar... ick.Totally coplanar... ick.Totally coplanar... ick.Discarded degenerate polys: 68Current allocations: 19172Max allocations: 226532Releasing remaining allocs: 19172


    Zu meiner Überraschung geht Optimize immer noch. Komisch. Wenn ich aber die Daten vergleiche, sehe ich einen gewaltigen Unterschied zwischen meiner Test-FM und Beltzers FM. Beltzers Map hat nur 2755 “Unique render aspects”, während ich bei 7992 lag und meine WR-Cell-Zahl liegt deutlich niedriger. Und ich kann Beltzers Map mit Kram (fast ohne Ende) füllen, ohne das Optimize versagt. Optimize versagte in meiner Testmap bei mehr als 7992 “Unique render aspects”. Deshalb denke ich, das ist das Limit für MAX_GLOBAL_RENDER.


    Ich kann sogar noch mehr Krempel in Beltzers Map einfügen, aber Optimize versagt bald.



    Ein anderes Limit, das nach nur wenigen Brushes mehr erreicht war. Diesmal MAX_GLOBAL_POINTS. Und wenn ich die Daten vergleiche, tippe ich auf „Unique planes“, die hier eine Rolle spielen.
    Fazit:
    Nach diese Nachforschungen gehe ich von folgenden Limits aus:
    MAX_GLOBAL_RENDER: Vermutlich ca. 8000 Unique Render Aspects oder weniger
    MAX_GLOBAL_POINTS: Vermutlich ca. 11000 Unique Planes oder weniger


    Man wird im Normalfall zunächst die Grenze zu MAX_GLOBAL_RENDER erreichen. Sensut hat dies neulich mit gerade mal etwas mehr als 15000 WR-cells erreicht (das ist nicht mal die Hälfte des eigentlichen Limits von 32760). Ich sah diese Zahl sehr schnell wachsen, wenn ich vielseitige, ineinander verschachtelte Dodecahedrons und Zylinder kopierte.
    Wenn man wissen will, wie man riesige FMs bauen kann, sollte man sich Beltzers „The Favour“ ansehen.
    Falls man nun in Nöten ist und wenn man nun doch auf solches Zeugs wie Dodecahedrons angewiesen ist und diese nicht gerade zum Herausschnitzen braucht, sollte sich das Newdark-Feature „Export as Obj“ ansehen. Wenn man etwas Übung hat, kann man Objekte wie Felsen schnell selbst basteln (z. B. mit Replacement-Textur) und damit viele Ressourcen einsparen. Denn ein Objekt benötigt keine WR-Cells, keine Unique Trallalas und man kann 8192 davon einfügen.

    Ein anderes sehr wichtiges Limit verbirgt sich hinter einem unscheinbaren Eintrag im monolog:
    "more than 32 edges after edge-merge"
    Dieser Eintrag ist nicht farblich gekennzeichnet und hat auch zunächst keine Konsequenzen für die weitere Arbeit. Optimize, Portalize und Pathfinding klappen immer noch, was sich aber schnell ändern kann. Denn der Fehler kann einen Riesenärger verursachen, spätenstens dann, wenn die Map größer wird und/oder Roombrushes gesetzt werden. Dann kann Portalize den Dienst versagen und monolog kann eine Fehlerquelle herausspuken, die rein gar nichts mit der Stelle zu tun hat, an der man gerade arbeitet, sondern am anderen Ende der Map sein kann. "more than 32 edges after edge-merge" gibt glücklicherweise auch die Koordinaten der Stelle an, die DromEd nicht behagt. Man kann dann vm_teleport xxx,yyy,zzz eingeben, um zu dieser Stelle zu gelangen. Wenn man diese Fehlermeldung nicht beachtet, wird mann immer wieder auf bestimmte Cells verwiesen, die angeblich nicht funktionieren. Geht man dann mit "cc xxxx" dorthin, kann man das Problem kurzfristig beheben, aber die eigentliche Ursache liegt woanders.


    Noch ein Limit, das nur ein ungefähres Limit ist und anscheindend zuweilen mit der o. g. Fehlermeldung zusammenhängt: Die Fehlermeldung "winding too large". Portalize wird nicht mehr funktionieren, wenn die kommt. Wahrscheinlich sind dann Terrain-Brushes in einem Winkel anders als ein Vielfaches von 22,5 Grad im Level (also einem Gradienten, der nicht automatisch in den Grid snappt). Die Fehlermeldung kann kommen oder auch nicht, sehr wahrscheinlich kommt sie erst in Verbindung mit anderen Problemen. Man kann mit hilight_nonaxial herausfinden, welche Terrain-Brushes nicht im 45/90/180, usw.-Winkel sind. Das ist leider etwas ungefähr. Besser, man schreibt sich die Brushes auf, die unbedingt (und manuell) in einen ungewöhlichen Winkel gesetzt wurden. Wenn man mit Multibrushes arbeitet, können schnell solche Winkel entstehen (abgesehen davon, dass Multibrushes nicht automatisch einrasten, das muß man in jedem Fall doppelt und dreifach nachprüfen).


    Ich weiß gar nicht, wie man früher ohne dieses schicke Monolog-Fenster bauen konnte.

    In Newdark ist es nun möglich, sehr große Texturen zu verwenden (bis 4096x4096). Inwiefern dies notwenig ist, muß sich jeder selbst überlegen. Im allgemeinen ist es keine gute Idee, allzu viele sehr großen Texturen zu verwenden, denn die fressen viel Grafikspeicher.
    Man kann davon ausgehen, dass etwa ab 1GB (je nach Karte) Probleme auftreten. Man sollte auch daran denken, das irgendwer die FM später spielen soll.
    Neulich wars soweit. DromEd.exe benutze bei mir mehr als 1,1 GB im Taskmanager und folgende Meldung kam im Monolog (bzw. der craslog):


    Out of texture memory; entring swapout mode.
    Can't find suitable swapout candidate; dumping all textures!
    ASSERT: [d8States.cpp@1812] CreateTexture failed for sys texture: error -2147024882


    Man kann dann nur noch Texturen verkleinern oder löschen, bzw. mit compress_family (all) versuchen, Platz zu schaffen.
    Außerdem sollte man sich überlegen, ob man nicht besser das dds-Format mit DXT-Compression verwendet, wie hier beschrieben wird.

    Da's hier am besten reinpasst: Bis zu welchem time-Wert darf ich basteln mit Newdark? :)
    Meine nächste Mission wird mal wieder etwas größer. (Aber nicht aufgedunsen, wie zB bei Milhorn ;))) )


    Und es gab doch auch einen Konsolenbefehl mit dem man gewisse Limits ändern konnte oder nicht? (Den finde ich leider nirgends mehr.)

    Der maximale Time-Wert ergibt sich theoretisch aus der Summe der anderen Limits (Terrain Brushes, andere, also mindestens 20000). Ich glaube nicht, dass es damit Probleme geben kann, vorher erwischt dich ein anderes Limit. Mir ist kein Limit in Time-Werten bekannt.
    Welche Fehlermeldung hast du?

    Ich habe bisher noch keine Missionszerstörenden Fehlermeldungen gehabt ;)


    Meine Vergessene Stadt wächst und wächst genauso die Höhlen.


    Nur hab ich manchmal dass es ein wenig laggt. Weiß nicht woher das kommt.

    Je größer ein Map wird, umso eher können sich Fehler und Störungen einschleichen.
    Wenns stottert, liegt es erfahrungsgemäß
    -An einer unoptimierten Map
    -An sehr großen Texturen (vor allem PNGs)
    -An einem Emitter, der lustig vor sich hinspukt.
    -Wenn DromEd über 1GB RAM schluckt
    Behalte deinen Monolog im Auge und schau dir den immer wieder genau an. Alles, was im NewDark-Monolog gelb oder gar rot erscheint, muß korrigiert werden. Es sei denn, du weißt, warum das so ist und es so sein soll.
    Du mußt auch regelmäßig mit show_stats im Gamemod prüfen, ob z. B. die Backface Checks nicht ins Unendliche wandern (das sind Obj-Polys). Ab ca. 10000 sollte Schluß sein, es kann aber auch schon vorher ruckeln.

    also es kommt sehr selten. ich beobachte mal ob es auch bei optimized kommt. aber an manchen stellen gehts tatsächlich über die 10000.


    ich will in einer höhle feuerbällchen platzieren aber wenn die mich angreigen, artet das in starken lagspitzen aus.



    EDIT: ja ich wollte auch schon sagen wir sollten auf pm umschwenken oder ich mache einen thread auf.

    Noch was zur Problematik, dass DromEd ab etwa 1,3-1,5 GB Speichernutzung abstürzt. Wie oben schon angesprochen, kann man die Ressourcen schmälern, so dass DromEd weniger Speicher braucht. Nun habe ich festgestellt, dass dieser Speicherverbrauch keineswegs statisch ist oder stagniert, sondern sehr stark fluktuieren kann. In einer Testmap hatte ich einen Speicherbedarf zwischen 700-900 MB, allerdings gab es ständig Peaks über 1,3 GB und mehr, sodass DromEd abstürzte. Ziemlich nervig. Mir fiel dann ein, dass man schon früher die Thief.exe patchen konnte, damit sie 2GB und mehr adressieren kann. Dasselbe kann man auch mit DromEd veranstalten, nämlich mit Large Address Aware


    Eine damit gepatchte DromEd.exe kann auf 64bit-Systemen den gesamten freien RAM adressieren, für 32Bit sind Grenzen gesetzt (auch muß man hier etwas nachhelfen, s. 2. Link).
    In einer Testmap (DromEd unter Win 7 64bit) fügte ich viele riesige 4096x4096 png-Texturen hinzu und kam auf einen Speicherverbrauch von 2,8 GB. Früher undenkbar, DromEd hat damit nun kein Problem mehr.
    Allerdings sind so große Texturen reichlich übertrieben und kontraproduktiv, man merkt es im GameMod an den FPS, die dann langsam gen Null gehen, je nachdem, wieviele man davon hat.


    Der Speicherverbrauch im Spiel, d. h. in Thief2.exe ist übrigens längst nicht so hoch, wie in DromEd. Aber das muß man von Fall zu Fall selbst prüfen.

    Das nennt man mal ein nützliches Tool. Vorallem kennt jeder bei Spielen, dass wenn nachgeladen wird es zu rucklern kommen kann, diese minimieren sich durch das Tool merklich. Habs an dem beschriebenen Beispiel von GTA 4 auch gemerkt, dass diese Ruckler nicht mehr wirklich da sind. :thumbup:

    Nein. Den versierten Bastlern ist es schon bekannt, soviel habe ich erfahren. Zunächst muß ich die Auswirkungen selbst noch testen. Es geht dabei um die Abwärtskompabilitäten. Zwar sehe ich nach Tests kein Problem, aber man muß vorsichtig sein. Außerdem besteht die Gefahr, dass nun ein FM-Bauer beliebig viele Ressourcen in eine FM packt, die von den Spieler-PCs später nicht bewältigt werden können (ohne weitere Patches).

    Nachdem nun NewDark 1.22 veröffentlicht wurde, sind einige der Limits, die hier besprochen wurden, Makulatur (rot markiert)


    Nicht geändert haben sich z. B. WR-Cells und Pathfinding Cells


    Aus den Modders Notes NewDark 1.22