Hallo!

Zur Zeit mache ich einen performance Test mit dem GameGuru.
Dabei sind ein par Fragen aufgetaucht.

Zum Beispiel:
.) Kann man beim Starten das "Creating A. I. Obstacles" ausschalten.
Das benötigt bei mir schon fast 4 Minuten beim Starten des Levels.
Soweit ich weiß dient das zur Pfadfindung von Gegnern.
Bitte korregiert mich wenn ich falsch liege.
Da ich außer dem Spieler keine anderen Figuren im Level habe,
würde ich das nicht brauchen, und das würde das ganze sehr beschleunigen.

.) Wieso dauert das Laden und Speichern des Levels so lange,
wenn ich nur 2 Objekte auf flachen Terrain im Level habe?
Es sind zwar tausende Instanzen davon, aber wenn beim Speichern oder Laden
nur pro Objekt Position, Größe/Skalierung und Rotation speichern würde,
benötigte man für diese Information nur einen Bruchteil einer Sekunde.

.) Kann man mit LUA-Skript Instanzen/ Kopien von Objekten erstellen?
Am besten wäre es wenn man per Skript Objekte ins Level einfügen könnte.
Dann würde ich mir ein Laden oder Speichern von Objekten im Level selbst programmieren,
welches viel effektiver wäre.
Vorerst würde genügen wenn von Objekten im Level Instanzen/ Kopien erstellt werden könnten.

.) Gibt es irgend eine ander Möglichkeit als das Verlinken von Objekten,
um Gruppen von Objekten zu erstellen, bzw diese zu Speichern oder Laden,
so wie die Preflabs im alten FPSC.
Das würde das Handling von komplexeren Maps erheblich verbessern.


Meine bisherigen Tests haben ergeben, das der GameGuru mit vielen Poligonen (bis zu 4 Millionen sichtbaren)
nicht wirklich ein Problem hat.

Die meiste Performance nimmt die Vegitation weg.
Wahrscheinlich wegen der Transparenz.
Danach kommt das Terrain, welches viel an Performance schluckt.

Erstaunlicher weise braucht die Physik-Berechnung weniger Performance als gedacht,
und das obwohl alle Objekte Collision pro Mesh eingestellt haben.

Was wirklich nervt und sehr störend ist, sind die langen Ladezeiten.
Sonnst könnte man einfach mehrere kleinere Levels statt eines großen machen.

Zum Beispiel wenn man ein Haus betritt, das der Innenraum ein eigenes Level ist,
welches beim Betreten geladen wird, und beim Verlassen wieder das Außen-Level läd.

Oder verschiedene Zonen auf der Map, die nur geladen werden wenn der Spieler in der nähe ist,
ansonsten aus dem Speicher entfernt werden.
Das bedeutet ein per Skript Instanzieren/Kopieren von Objekten würde momentan den größten Performancegewinn bringen.

Ich setzte meine Test noch weiter fort, und vielleicht lade ich dann ein Video dazu hoch.
Wäre nett wenn jemand die Fragen beantworten könnte.

Hallo!

1.) Ich denke AI obstacle kannst du mit diesen Zeilen in der Setup.ini ausschalten:

skipobstaclecreation=1
skipterrainobstaclecreation=1

2.)

Frag mal Cybernescence oder Dimoxinil. Die haben an derartigem gearbeitet.



Nein, es sei denn du machst das extern in einem 3d programm.

So! Mehr weiss ich auch nicht weiter zu helfen.



-Wolf

Interessant, war mir irgendwie entgangen.

Ich hatte anderenorts hier schonmal vorgeschlagen, das obstacle creation gedöns an das Save Level zu binden,
und zwar optional, damit man das nicht jedesmal durchmachen muss, wenn man kurz mal zwischendurch gucken will, wie der Level so aussieht; im Save Moment ist der Level ja stabil.
Wollt aber wohl keiner hören. Wenn man den o.g. Parametern auch den Wert "2" erlaubt, könnte eben beim Save die entsprechende Abfrage kommen.

Danke für die Antworten.
Das Ändern in der Setup.ini hat geholfen.

Jetzt geht das Testen viel schneller.

Gestern habe ich mich noch mit Scripts auseinandergesetzt.
Es ist nicht möglich Meshdaten in Entitys zu tauschen.

Also momentan, muss sich jeder Gegenstand den man im Level haben möchte
auch in der Map befinden, und kann nicht über Script dupliziert werden.

Das Platzieren von Entitys per Skript ist kein Problem.
Wirklich schade das keine Instanzen erstellt werden können,
Dabei wäre es Programmtechnisch sehr einfach zu lösen, Eine Instanz bzw. Kopie zu erstellen.

Wir wissen alle leider nicht wie Lee die einzelnen Bestandteile umgesetzt hat, wir können nur mutmaßen wie "einfach" das alles ist. Ich kenne auch nicht wirklich eine Engine, die es so umgesetzt hat mit Duplikaten(im Source Code) und welche Performancegewinn, dies bringen würde. Aber viel Erfahrung in der Engine Programmierung hab ich eh nicht, weil es einfach zu kompliziert ist für ein Freizeitprojekt wäre. Was Lee macht ist als "one-man-show" schon sensationell. Das man da gewisse Programmierparadigmen über Board schmeißt, ist glaub ich jedem klar.

Ich muss auch zugeben, Lee macht sehr gute Arbeit.
Es gibt wichtigere Dinge die zuerst umgesetzt werden müssen.
So finde ich auch nicht schlecht das er an der Umstellung auf DirectX11 arbeitet.
Er hat erkannt wie wichtig die Performance und Optik für eine Spiele-Engine sind.

Jeder hier auch die Moderatoren in diesem Forum machen sehr gute Arbeit.
Und jeder User des Game-Guru hat andere Prioritäten und Wünsche,
die zu erfüllen sicher nicht immer einfach sind.

Da ich schon seit über 30 Jahren in über 10 Programmiersprachen programmiere,
und ich Hauptberuflich auch Programmierer bin,
denke ich dennoch einschätzen zu können wie schwierig die Umsetzung
zur Erzeugung von Kopien ist.

Vor allem dann, und deshalb, weil diese Funktion bereits im Map Editor vorhanden ist!
Mit gedrückter Hochstell-Taste können im Map Editor jederzeit Kopien angelegt werden.
Was fehlt ist diese Funktion mittels LUA-Script aufrufen zu können, und natürlich zu wissen,
wo sich das Mesh, welches man einfügen möchte, befindet.

Es ist nicht schwieriger als das Einfügen von Sprites, Bilder und Partikel,
welche ja auch schon im LUA-Skript umgesetzt sind.

Die Frage ist eher, ob man es zulassen sollte das jeder einfach per Skript
Modelle einfügt, und platziert.
Vielleicht kommt ja einer noch auf die Idee, die Map prozedural generieren zu lassen.
Oder das jemand damit endlose Open World Spiele macht.

Die größte Schwierigkeit ist der Faktor: ZEIT!
Einen Plan zu haben, und diesen auch umzusetzen.

Ich bewundere Menschen die beharrlich daran arbeiten ihre Ziele zu erreichen.

Meine Ideen die ich hier vorgebracht habe, sollten niemanden vor den Kopf stoßen.
Es war nur ein Vorschlag, keine Kritik.
Und aus Sicht eines Programmierers wie mich, ein Wunsch, der mit verhältnismäßig wenig Aufwand,
sehr viele und große Möglichkeiten schafft, den Game-Guru als die bessere Spiele-engine zu platzieren.

@yrkoon: Ich hab auch schon viele schlichte Dinge vorgeschlagen die ne Menge gebracht hätten die soweit aber noch nicht im Programm sind. Andere wurden wiederrum von Lee übernommen. Nunja, ich denke vieles geht auch einfach im Forum unter

@Maurehago:

Vielen Dank, Maurehago!



Ich bin mir Sicher nicht nur gesehen zu haben dass User über sowas sprachen, sondern auch dass jemand ein script hatte zufallsgenerierte Level zu erstellen. Wenn ich nun nur noch wüsste wo das war. Naja, ich such heut abend einfach nochmal.



-Wolf

@Wolf: Ja so ist es halt - ...immerhin tröstlich, nicht allein zu sein


@ Maurehago:

Den Witz habe ich irgendwie nicht verstanden.

Meinst du das: https://forum.game-guru.com/thread/216163
Das ist das einzige was mir einfällt.


Ich bin nicht sicher ob das ein Witz war. Ist es wirklich gut Objekten die "Macht" zu geben, andere Objekte zu referenzieren? Man müsste ja irgendwie eine Rangebene erstellen. Wäre es nicht komisch wenn ein Baum Kisten erstellen darf
Ok, ich glaube es war Ironie, weil es ja schon irgendwie die Kreativität einschränkt, auf der anderen Seite sind zufallsgenerierte Level ziemlich langweilig Mir hat bisher noch keines Spaß gemacht....

@Corno_1



Ja, nee, ich kann nicht für Maurehgao sprechen, bin aber der Ansicht, er meint was anderes.
Ein einfaches Beispiel wäre vllt. der Einsturz einer Fels- oder Höhlenwand, und ein entsprechendes Script
erzeugt Felstrümmer, Geröll, etc. Auch "Wasserspielereien" könnte ich mir vorstelllen.

Und wenn ich an bestimmte italienische oder österreichische Bergdörfer denke, die sich gerne um die eine Kirche arrondieren,
könnte ich mir auch vorstellen, dass man sie halbautomatisch erstellt.
Irgendwann GAAANZ früher hatte ich sowas auch schon mal vor, (jedoch nicht für GG, sondern eine Engine mit Source Code Access),
mit "Profilen" für "Dörfer", "amerikanische Städte (Schachbrettmuster-Städte)",
Stadviertel für "Wohlsituierte", andere für "Arme", plus Zufalls-Rahmenparameter (z.B. "Strassenbreite zwischen x und y"), usw. usf.

Da lässt sich schnell ein Kaff oder auch Städtchen mal eben generieren,
und wenn's nicht gefällt, gibt's den "Hau-wech-und-mach-nochmal" Button,
es wird schon irgendwann halbwegs passen.
Wenn das nicht reicht, ändert man halt den einen oder anderen Parameter.

Da ja "richtig gehende Objekte " generiert werden, kann man da natürlich mit den normalen Editorfunktionen nach Belieben verbesschlimmern.
Allerdings dürfte GG das so ziemlich ungeeignetste SW-Produkt überhaupt für sowas sein - das Ganze will ja auch abgespeichert werden,
und die Engine muss die Objekte ja auch "normal" behandeln können.

Also, sinnvoll könnte sowas wie das von Maurehgao geforderte schon sein, und mein Beispiel ist ja nur ein schnell hingeschriebenes.

Ich möchte bevor ich jetzt eine Diskussion aufreiße wie sinnvoll das Feature ist, das ich ein guten Grund haben will, warum man das braucht!
Wir Coder sagen immer zu Anfängern:"Mit lua kann man das machen". Nun sag ich Geröll, Wasserspielerreien sind ohne Probleme im Editor mit Triggern zu erstellen. Warum so ein Feature implementieren?
Ach ja und prozentuale Level sind meiner Meinung nach ein guter Gedanke der Gaming-Industrie, mehr nicht und jeder der bisher das auf ein Spiel geschrieben hat, hat entweder getrickst oder das Spiel war grottig.

Wie schon oben beschrieben,
jeder hat andere Vorstellungen Wünsche und Anregungen an die Engine.
Die Diskussion zeigt das wieder mal deutlich.

Um aber das ganze wieder auf den Tread-Titel zurückzubringen.
Mir geht es hauptsächlich um die Performance, was natürlich auch
das Memmory-Management mit sich bringt.

Meine Tests haben bis her ergeben das die Engine selber,
wenn mal die Map läuft, nicht wirklich Performance Probleme hat.

Das meiste geht zu lasten des hohen Speicherverbrauches,
und der langen Ladezeiten.

Andere Engines haben das bereits erkannt und laden, bzw. zeigen auch nur die Objekte,
die gerade gebraucht werden.
Obwohl mir bei den neuesten Spielen aufgefallen ist, das Shader jetzt meistens beim (erstmaligen-) Start
vorkompelliert und in die Grafikkarte geladen werden, was auch ewig dauert, und nicht alle gebraucht werden.


Um das mal vorstellbar zu machen ein kleines Rechenbeispiel.
Wir nehmen an wir machen einen Wald (zufallsgeneriert, oder nicht) mit 1000 Bäumen.

Der Baum(direct.x) hat z.B.: bei pine01 32 kb (~32.768 byte)
Als .dbo Datei 184kb (~188.416 byte)
Diffuse Textur 513kb (~528.384 byte)
Normal Map 257kb (~266.240 byte)
Specular Map 65kb (~69.632 byte)

Ich nehme mal die dbo Datei, weil da warscheinlich alle Eigenschaten zusammen drinnen sind excl. Texturen
Somit hätte der Baum:
A) Mesh: 0.18 MB
B) Texturen 864256 byte (~0.83 MB)

Für den 1. Baum benötigt man Metadaten, die beim Game-guru folgende wären
x, y, z, anglex, angley, anglez,
(scaleX, scaleY, scaleZ) sind offizell nicht angegeben, müssten aber auch dabei sein.
object, active, activated, collected,
haskey, plrinzone, entityinzone,
plrvisible, health, frame, plrdist,
avoid, limbhit, limbhitindex

Welche rund 100 Byte belegen. Kommt darauf an wie diese gespeichert werden.
Wieso man im Game-guru all diese Daten bei jedem Baum diese Daten benötigt, entzieht sich meiner Kenntniss.

Für alle weitern Bäume würde man nur Position, Rotation, Scale und die MeshID(object) benötigen,
Welche rund 60Byte benötigen würden.

Also gehen wir mal von den 100 Byte aus
C) Metadaten: ~0,1kb -- 0,0001MB

Wie der Game-guru das Terrain behandelt weiß ich leider (noch)nicht.
Wenn ich alle dafür benötigten Informationen zusammenkratze (Texturen, highmap, Vegitationsmap, Skybox, Gras-Mesh, usw.)
komme ich auf gute 90MB.
Ich nehmen hier mal einen Wert von 100MB an, was meiner Meinung nach schon sehr hoch ist.
D) Terrain: 100MB

Natürlich fehlen noch Informationen über den Spieler, Startpunkt, Skripte, Shader, Lightmap, Physik, usw..
Ich werde das mal beiseite lassen.

Jetzt rechnen wir mal was der Game-guru an Daten im Speicher braucht um unseren Wald darzustellen.

A (0.18MB) * 1000 = 180MB -- für 1000 Bäume
+ B (0.83MB) = 180.83MB -- Texturen werden nur 1x geladen
+ C (0.0001MB) * 1000 = 180.93MB -- für jeden Baum Metadaten
+ D (100MB) = 280.93MB -- Terrain-Daten
-------------------------------------------------

Wie Ihr erkennen könnt, benötigen die Bäume fast die Hälfte des Speicherverbrauches.
Und die Metadaten nur 1 Promille an Speicherinformation.

Wäre es dann nicht besser mehr über die Metadaten abzubilden?
Wenn man das Instanzing in der Grafikkarte verwendet,
benötigte man nur einmal das Mesh (0.18MB) und man würde sich 179.82MB an Speicher sparen.

Ihr könnt euch selbst ausmalen was passiert, wenn wir jetzt noch 500 andere Bäume, 700 Büsche, 350 Steine, usw. einbauen.

So wie oben angesprochen, das Objekte auch ausgeblendet werden können,
bringt in diesem Fall nicht viel, weil der Game-Guru diese nicht aus dem Speicher entfernt.
Sie werden halt von der Engine nicht angezeigt.
Auch jeder Game-Loop überprüft trotzdem immer alle Objekte.
Würde man jedem Objekt eine Gruppe ("sichtbar", "nichtsichtbar") zuteilen,
bräuchte der Game-Loop nur die Gruppe, bzw. die Objekte in der Gruppe "sichtbar" prüfen.
Alleine das würde schon einiges an Performance bringen.

===============================
Kommen wir zum Speicher-Verhalten.
Ein etwas ältere SATA Festplatte kann rund 150MB pro Sekunde lesen.
Die neueren Platten und vor allem SSD Laufwerke ein Vielfaches davon.

Würde das oben angeführte Beispiel 1:1 auf die Platte geschrieben,
bräuchte man im schlimmsten Fall 2 Sekunden zu Laden der Map.

Da die Daten aber Komprimiert abgelegt werden,
wird weniger Zeit zum laden oder Speichern gebraucht, als zum Komprimieren und Dekomprimiren.

Hinzu kommt das die Engine die ganze Map aufbauen muss (Mesh + Metadaten) bevor diese angezeigt wird.
Shader kompelliert, Texturen in den Grafikspeicher verschieben usw.

Meiner Meinung nach braucht der Game-Guru viel zu lange dafür.
Deshalb mein 2. Ansatz:
Wir lassen von der Engine nur eine Map mit einem Baum speichern.
Und speichern zusätzlich die Meterdaten aller andern Bäume (1kb) in eine oder mehrere Textdateien.
Somit würde das Laden und Speichern der Map um ein vielfaches beschleunigt.

Weiters würden wir nur die Metadaten laden die gerade
für den Angegebenen(sichtbaren-) Bereich des Spielers gelten, laden,
den Baum Instanzieren und die Position, Rotation, Scale auf der Map setzten.
Zum kaschieren, so das der Spieler den Aufbau nicht sieht, können auch angrenzende (nicht sichtbare) Bereiche,
mit geladen werden.

Bei einer Ladegeschwindigkeit von 150 MB / Sekunde, und einer Dateigröße von 1kb,
kann sich jeder mal ausrechnen wie lange das dauern würde.

Außerdem wäre es möglich in einem Bereich der Map,
unterschiedliche Daten zu laden, und so ein endloses Open World zu simulieren.

Und das ganze ohne den Hauptspeicher Rahmen zu sprengen.

============================
Kommen wir zum 3. Punkt
Das in voran gegangenen Beiträgen als "Witz" bezeichnete Einwand:

Soll dem Entwickler die Macht, das zu tun gegeben werden?

Das ist auch die Negativ-Seite des ganzen.

Die Spiele-Engine geht jetzt von einer konstanten Anzahl an Objekten aus.
Somit weiß sie wie lange sie für Physik Berechnung, Schatten, Berechnung, Shader, Speicherverbrauch usw. benötigt.
Damit kann sie eine relativ konstante FPS Rate, und eine gewisse Stabilität für die Anzeige halten.
Prüfungen auf Vorhandensein von Texturen, Shader, Meshes, usw.
entfallen während des Spielens, und finden nur beim Start statt.

Wenn nun dynamisch Objekte hinzugefügt oder entfernt werden.
Muss das die Engine mitbekommen, und muss deshalb mehr Prüfungen machen.
Das ganze kann die Stabilität der Engine ins Wanken oder auch zum Absturz bringen,
wenn der Entwickler vergisst der engine die neuen Objekte mitzuteilen.

Außerdem funktioniert das LightBacking nicht mehr so wie vorgesehen.

Und so wie ich die Skript-Kenntnisse der meisten GemGuru Anwender einschätze,
ist das eine erhebliche Fehlerquelle.

So etwas muss gut durchdacht und "deppensicher" vorbereitet werden.
Deshalb meine Bedenken (kein Witz).

Ich weiß ja jetzt nicht, ob sich jemand die Mühe macht das ganze durchzulesen.
Aber ich hoffe das für den einen oder Anderen neue Erkenntnisse dabei waren.

Genau das in kurz schrob ich doch ?

Und was den "Witz" angeht, las sich das für mich, als wolltest hier diskutieren, ob man einem Koch die scharfen Gewürze oder besonders intensiv schmeckende Beilagen untersagen sollte. Davon abgesehen, dass ich Deinen Optimismus, GG würde nennenswertes Balancing wie von Dir beschrieben vornehmen, überhaupt nicht teile, sind dynamische Objekte einfach nur noch eine Möglichkeit, Mist zu bauen, ... eine von .. mehreren. Aber wie man sieht, kann sich der eine oder andere hier sowieso so gar nichts drunter vorstellen, diese Gefahr ist also sehr niedrig.

Ceterum censeo, dass Du das alles besser in Englisch in ein anderes Unterforum ( etwa:Feature Creep ?) geschrieben und an Lee adressiert haben solltest... for obvious reasons.

Edith trägt nach:

Ich mein', das GG sowas inwischen seit Februar macht, vllt. war's aber wieder nur ein Feature, das wieder raus ist...oder verloren ging...oder ...