Ich möchte einen Egoshooter machen (ich weiss, sehr innovativ :P)
und habe mein letztes Projekt unter einer sehr frühen A6 Version abgebrochen,
weil ich glaubte, an die Grenzen der Engine gestoßen zu sein.

Ich habe dann vor kurzem aus Spass ein Wolfenstein-Sprite in A7 geladen um zu sehen,
wie groß\klein es im Gamestudio wirkt.
Ich habe dann das Playermodel aus meinem abgebrochenen A6-Projekt danebengestellt und musste feststellen,
dass das Modell riesig war im Vergleich zum Sprite.
Es war gefühlt doppelt so gross wie der Doom 3 Cyberdemon verglichen mit dem Doom 3 Player.
Dadurch wurde mir schnell klar, warum das alte Projekt so schnell langsam
wurde und warum ich keine großen Level bauen konnte.

Da ich schon länger raus bin und von der Leistungsfähigkeit der A7 und meiner Grafikkarte
(Radeon X800 GTO 256 Bit) kein wirkliches Bild machen kann im Bezug auf Spieleentwicklung,
möchte ich hier Fragen, was mit A7 plus meiner Karte möglich ist und welche
Größen die meisten hier für ihre Spiele benutzen (Größe der Playerfigur, ungefähre Polygonanzahl für Gegner, Skingrössen,
Art der Kollisionserkennung bei A7, Leveltexturgrössen und ähnliches).

Vor allem: Wie viele Pixel sind ein Meter?
Ich weiss, das kann man selbst bestimmen, aber welche Einteilung ist ein guter
Kompromiss aus Detail und Geschwindigkeit? Ich frage deshalb, weil ich alle Texturen selber mache
und ich dann wissen\umrechnen muss, wie groß zum beispiel ein Türrahmen- oder Fensterauschnitt wäre.
Ich benutze für dieses Spiel Sprite-Figuren, der Rest wird dreidimensional gemacht.
Meine Ziele für mein Spiel wären sehr große, teils offene Level
(ohne Terrain, für dieses Projekt mag ich es eckig),
sehr viele Schüsse, Feuerbälle und Trace-Schüsse gleichzeitig ohne Slowdowns
und sehr viele Gegner gleichzeitig, ohne dass man von (wenn auch weichgezeichneten)
Wandpixeln erschlagen wird, was bei der Wolfenstein\Doom-Größe der Fall ist.
Ich hoffe das ist kein zu großer brocken.

Nimm das Cyberbabe als Grössenvergleich.

Meine Erfahrungen bislang:

Grundsätzlich so klein wie möglich, so groß wie nötig.
Beispiel: Rennstrecke, 1000x1000 Meter, 2400 Quants.
Das läuft sehr gut hier.

Bei Außenleveln ist LOD für Figuren, Objekte und Materialien / Shader unabdingbar, wenn die Fps oben bleiben sollen.
Von Beginn an LOD nutzen, nicht erst wenn es eng wird.
Macht weniger Arbeit, man sieht die Auswirkungen direkt und kann daran feilen.

Modelle in MED sinnvoll gruppieren. Ist nicht immer einfach, muß man testen.
Es hat z.B. nichts gebracht Baumgruppen mit je 10000 Polys zu erstellen.
Einzelne Bäume renderten wesentlich schneller.
Ich schätze der ABT Tree und das LOD können dann besser wirken.
Statt fünf verschiedener Modelle mit je 10000 / Polys und 18 Skins habe ich nun
drei Modelle mit je 3000 Polys und 6 Skins, die dafür öfter im Level verteilt sind.
Im Grunde ist es klar das letztere Möglichkeit besser läuft, da nicht soviele Durchgänge nötig sind.
Mußte ich auf dem harten Weg lernen.
Man kann jede Engine ganz schnell in die Knie zwingen:
Ohne Gruppierung: >40 fps, mit Gruppierung: unspielbar.
Bei Modellen mit nur ein oder zwei Texturen kann das gruppieren natürlich einen gehörigen Boost erwirken!

Schau Dir infinite_terrain.c an, im Gamestudio Ordner unter "Samples"
Auch wenn Du kein Terrain brauchst, da sind viele gute tipps bezüglich großer Level drin.

Nebel benutzen um zusammen mit LOD und clip_far die Sichtweite einstellbar zu machen

Möglichst wenige Traces, vor allem wenn diese pro Frame einmal passieren sollen

Modelle nicht übermässig skalieren! Weder zur Laufzeit (am besten pro Frame: das ist ein echter fps Killer!)
noch im WED. Besser im MED schon die passende Größe einstellen.
Zweifach skalieren geht schon im WED, 20-fach oder 0.02 fach ist schlecht.

-Also: Immer wenn etwas extrem wird (skalierung, texturgrößen, entitieanzahl, anzahl der laufenden funktionen...)
gibt es Probleme. Wie jcl schon sagte: common sense muß sein beim Umgang mit solchen "Mengen".
Dann sind Optimierungen notwendig, die einem erstmal garnicht in den Sinn kommen, so wie die Kollision global abzuschalten,
alle Entities zu erstellen und sie dann wieder einzuschalten...wer und wie soll (man) das ahnen?

-Experimentieren, viel

-Jede Änderung auf Ihre Performance hin überprüfen

-Texturgrößen: Alles bis 2048 ist recht problemlos. 256 läuft sehr gut, ich benutze meist 512 und 1024.
Größer bitte nur wenn es unbedingt sein muss und auch hier wieder common sense: DDS benutzen.
Wenn es geht, immer!!

-Mit dem HEX editor Neo und dem Ati compressonator kannst Du viele Modelle schnell auf DDS umstellen.

-Darum, aber nicht nur: Alle Skins extern anlegen. Immer. Hat nur Vorteile.

-Kollision: Möglichst viele Objekte auf PASSABLE setzen.
LowPoly Kollisionsmeshes verwenden und unsichtbar machen, ist schnell und löst potentielle Probleme im Vorfeld

-...ich hab bestimmt was vergessen

-Edit: Levelgröße war falsch angegeben

-Edit 2: ab ins Wiki damit, ich hab aber jetzt echt keine zeit mehr.

@fogman
Du solltest mal ein Buch über Optimierungsmöglichkeiten für 3DGS schreiben.
Boah ey das waren ja mal massig Tipps!

Hinzufügend möchte ich sagen, dass die Frage "was ist ein Meter?" jeder selbst beantworten muss. Ob das jetzt auf einer Textur 8 Pixel, einer oder 1024 sind oder in Quants ausgedrückt 8 Quants 32 Quants oder 1567 Quants. Das hängt immer davon ab, wie du deine Spielewelt skalierst und was du für Genauigkeit brauchst. Man muss sich nur das Beispiel Micromachines vs. Flugsimulator vor Augen halten: während ein Meter in einem Micromachines-Spiel sehr viele Details enthalten kann, bzw. muss, ist ein Meter in einem Flugsimulator "nichts" - da fragt man sich eher wieviele Einheiten einem Kilometer oder sowas entsprechen.

Wenn du ein Level mit lightmaps im WED kompilierst, solltest du dich evtl. auch daran orientieren, da es mühselig sein könnte für jede Textur einen individuellen Skalierungsfaktor festzulegen, um schöne lightmaps zu erzeugen.

Als Umrechnungsmaß würde ich eine 2er-Potenz bevorzugen, da auch im WED das Grid in 8er-Schritten dargestellt wird. Du kannst ja im Spiel in Metern rechnen und dann über nen Umrechnungsfaktor in Quants, bzw. andersherum rechnen:

var qpm = 8; // 8 Quants pro Meter
var mpq = 0.125; // 0.125 Meter entsprechen einem Quant (1/8 = 0.125)

Wenn du z.B. prüfen willst, ob zwei Vektoren a und b mehr als 3,5 m entfernt sind, kannst du das so

if (vec_dist(&a, &b) * mpq > 3.5) {...}

oder so

if (vec_dist(&a, &b) > 3.5 * qpm) {...}

machen. Wichtig ist, falls du den Meter/Quants (mpq) Faktor verwendest: var ist ein Fixkomma-format und da geht die Präzision flöten! Entsprechen z.B. 32 Quants einem Meter, dann wäre mpq = 1/32 = 0.03125 --- und das kann der var-Typ nicht darstellen! Deshalb in solchen Fällen floats für die Umrechnung verwenden.

Wie fogman u.a. gezeigt hat, entscheiden also eher die äußeren Einflüsse, wie du deine Umrechnung wählst. Ich persönlich finde 32 (in großen Levels) oder 64 Quants (in kleineren Levels) als Metermaße gut!

[EDIT] Was ich vergessen habe: du kannst auch 100 quants als Maßeinheit nehmen um intuitiv mit den Quants umzugehen. Das harmoniert aber nicht so gut mit den 2er-potenzigen Texturgrößen... also ist dahingehend Vorsicht angesagt!

Da acknex ein Derivat von Quake ist, ist die klassische
skalierung
1 "quant" = 1 inch = 2,54 cm

ein 1,8 meter player sollte so 70 inches (quants) groß in
WED erscheinen.

Das ist auch die skalierung, die die meisten Models
schon haben. Macht somit die Arbeit einfacher.

---

ansonsten kannst du jede andere quant zu meter skalierung
selber festlegen. Da gibts keine "vorschriften".
Die 1 quant = 1 inch (Zoll) Konvention ist aber praktisch.

Erstmal Danke an die gewaltige Vielfalt an Antworten.
Ich werde mir diesen Thread noch öfters ansehen und bei Notwendigkeit viele der Tips ausprobieren.
Und in meinem Kopf gab es jetzt ein großes "AUA!!!".
Ich hatte mich die ganze Zeit gefragt, warum die Quake und auch die Doom 3 Modelle, die ich gestern mal zu Vergleichszwecken geladen hatte, so "krumme" Maße als Zahlen hatten, hab da nämlich jede menge hin und hergerechnet... NATÜRLICH, weil die ID-Jungs in Inches rechnen... aarrgg stand ich auf dem Schlauch und quäle meinen Windowsrechner stundenlang mit zentimeterrechnungen.
Ich habe jetzt erstmal beschlossen, 50 Pixel\Quants einen Meter sein zu lassen. Mein hauptchar ist dadurch 1.76 groß. Zudem ist die Einteilung ganz praktisch. Eine Textur mit 128x128 ist somit 2,56 m hoch, bis auf die 6 cm genau die Deckenhöhe unserer Räume in unserer Wohnung. Zudem kann ich dann jedes Maß einfach durch zwei teilen und hab sofort die Größe im Spiel parat.

@Widi: und das Cyberbabe ist in seiner Größe relativ zu was?... Aber ich habs ausgetestet. Das Cyberbabe hat ungefähr Quake-Größe. Nach einigem rumtesten ist es zu klein

@HeelX: Meter werde ich direkt im Spiel selbst nicht verwenden, aber trotzdem danke für den Umrechnungscode-Schnipsel.
Vielleicht ist der Später noch nützlich.
Mir ging es nur darum, dass ich ein Regal ankucke, messe, und dann sofort weiß, wie groß ich es modellieren muss, damit es maßstabsgetreu im Spiel zu allem anderen ist.
Sind 32 Quants für einen Meter nicht recht wenig? Hatte bei Games, die diese Skalierung hatten (Wolfen, Doom , Quake, das ganze alte gedöns halt) schon damals immer das Gefühl, mit dem virtuellen Kinn knapp über dem Boden zu schleifen, weil der View so dicht über dem Boden war.

@Fogman:
Und was den Optimierungs-Guide angeht. Wenn es sowas nicht schon gibt, wäre das doch mal wirklich eine Überlegung wert. Vielleicht schafft das es sogar in die reguläre Manual als eigenes Unterkapitel.
LOD... (schauder) Ich weiss, was das ist, aber ich hab noch nie damit gearbeitet, zudem hab ich "nur" die Comm-Edition, also kein Auto-LOD. Hab mich bis jetzt immer davor gescheut, da ich nicht weiss, wie ich aus meinem vorhandenen Model LOD-Stufen-Models machen kann und ich auch nicht weiß, ob man die Skin mitverkleinern muss für das Lower-Poly-Model, oder ob alle Stufen die gleiche Skin benutzen u.s.w. Ich werde mich dann mal auf die Suche nach einem LOD-Tutorial hier machen (Ich denke, es gibt hier bestimmt schon eins).
Skalieren tu ich in Echtzeit oder auch in WED ohnehin nicht. Die Modelle werden in MED direkt in der entsprechenden Größe gebaut und bleiben dann so. Deshalb ja auch mein Post, denn bis auf das Playermodel, das ich jetzt in MED auf "Referenzgröße" (88 Quants) runterskaliert habe, habe ich noch keine Artworks oder Modelle für das Spiel gemacht, und nochmal so einen Fehler wie damals wollte ich nicht wiederholen, so dass ich alles sofort mit ordentlichen und kompatiblen Größen erstelle.
"Möglichst wenige Traces, vor allem wenn diese pro Frame einmal passieren sollen"
Hmm.. Und was mache ich stattdessen? Ich brauche alleine schon für die Gravitation Trace bzw. gleichzeitig für das Treppensteigen, oder gibt es da andere Möglichkeiten.
Nehmen wir mal den Extremfall:
Ich möchte eine Minigun im Spiel haben und das Ding soll 3000 Schuss die Minute\50 Schuss pro Sekunde abgeben. In meinem letzten Spiel, das ich komplett fertiggestellt habe, einem 2D Top-Downshooter (Nicht mit Gamestudio, sondern mit dem Game Maker 6), war das möglich.
Ich denke "Trace" hat sich für diese Aufgabe in jedem Fall disqualifiziert. Gäbe es im Gamestudio Möglichkeiten, so etwas mit ordentlichen Drumherum (Keine Shader, hochauflösenden Texturen, Postprocessing, Stencilshadows und wasweißichnoch für Highend spielereien) umzusetzen, ohne das Spiel ein Meisterwerk des Minimalismus werden zu lassen?
Die Texturgrößen überraschen mich. Ich hab 512 für sehr groß und 1024 für unverschämt gigantisch gehalten... ich bin irgendwie von gestern.

"-Darum, aber nicht nur: Alle Skins extern anlegen. Immer. Hat nur Vorteile.
LowPoly Kollisionsmeshes verwenden und unsichtbar machen, ist schnell und löst potentielle Probleme im Vorfeld"

Das sind zwei Punkte, die mich noch interessieren...
Warum hat Skins extern anlegen Vorteile?
Und wie sieht das mit den Lowpoly Kollisionsmeshes im Detail aus und welche Probleme löst es schon im Vorfeld?

Und nochals danke, sehr viele probleme sind jetzt schon durch eure Antworten gelöst. Jetzt gehts erstmal ans Texturen erstellen.

Ich geb einfach mal mein´ Salmon dazuhuhu:



Ich finde das schon recht viel.
Überleg´ mal, bei 100 Metern bist Du schon bei 3200 Quants.
Bei 1000 Metern bist Du auf 32000 Quants - das ist schon ein drittel der maximal empfohlenen Levelgröße.
Meiner Erfahrung nach rendern "kleine" Level wesentlich schneller.

Ich würde versuchen es mit 16 Quants pro Meter zu bauen.
(aus Modellen, nicht aus Blöcken)




Skin verkleinern bringt nix - aber die Anzahl der Skins mit zunehmendem LOD verringern und auch die Normalmaps draußen lassen.
LOD Modelle: Der harte Weg geht übers mergen einzelner Vertices.
Ansonsten könnte Blender gute Dienste leisten, wenn es ums erstellen der LODs geht.
Vor allem: Je höher die LOD-Stufe desto unförmiger kann das Modell sein.
Auf 500 Meter Sichtweite tun es auch Klumpen mit 50 Polys als Gegner, man sieht es wirklich nicht. Allerdings muß die
Belichtung gut abgestimmt werden, vor allem wenn Material / Shader LOD genutzt wird.




Sind bei 50fps genau ein Schuß pro Frame.
Würde ich ausprobieren. Wenn Deine Gegner das auch alle machen sollen, am besten gleichzeitig, dann wird´s eng.
Also immer nur einen bösen Jungen mit Minigun rumlaufen lassen, die anderen müssen sich mit Schrotflinte und Raketenwerfer begnügen.

Wie gesagt und hier auch schon gezeigt wurde geht schon recht viel mit Gamestudio. Man muß nur wie eine Engine denken.


Skins extern: Stell Dir vor, Du willst eine Skin ändern.
Du hast im Spiel festgestellt, daß da ein Fleck ist der nicht da hingehört.
Na gut, Fleckentferner anwenden (Gimp / Photoshop) und Skin neu speichern.
Spiel starten - hoppla, Fleck ist noch da?!
Klar, wenn die Skin intern gespeichert wird. Du müßtest
das Modell erst wieder im MED öffnen und die Skin ersetzen.

Neeeervig! Wenn die Skins extern liegen, sparst Du Dir das.
Dann wird jede Änderung sofort übernommen.

Ein weiterer großer Vorteil:
Mehrere Modelle können sich Texturen teilen, was meines Wissens weniger Speicher beansprucht.

@all: Habe ich mit dieser Vermutung recht?





Du könntest es z.B. aus unsichtbaren Blöcken erstellen.
Je weniger Polygone auf Kollision geprüft werden müssen,
umso schneller ist die Choose.
Ein detailreiches Baummodell sollte also auf PASSABLE gesetzt werden und gleichzeitig ein einfaches Modell (ein Stiel mit Kiste / Kugel drauf) als Kollisionsmesh erhalten.

Immens wertvoll ist der ständige Blick hier hinein (das Manual Unterkapitel gibt´s nämlich schon):
http://www.conitec.net/beta/framerate.htm

So, Essen fassen.

@fogman



"Kugel drauf" würde ich nicht machen. Man will ja auch durch die Baumkrone ballern können. Stattdessen lieber ein paar einfache unsichtbare Coll.-Meshes für starke Äste setzen.

Hast recht. Ich war zu sehr in meinem Projekt versunken.
Da passen Kugeln ganz gut.