Slin, ich stimme mit Dir im Grunde überein. Aber sehen wir es mal ganz objektiv. Da ich eh Lizenzen von C4, GS, Unity und Torque3D habe, kann ich da emotionslos rangehen:

Erstens erwähnst Du die Regionen von A8, genauso wie ich das kommende Umbra Occlusion Culling von Unity erwähnen kann. Beides ist noch nicht da. Deshalb bin ich hier ganz vorsichtig. Theoretisch könnten beide aber eine super Arbeit leisten. Ich bin jedenfalls sehr neugierig darauf.

Dann erwähnst Du BSP in Gamestudio. Ich kenne es ja von der A6 Com, wo es noch enthalten war. Es funktionierte allerdings nur ohne Shader. Und da man Portale nicht per Hand gesetzt hat und es keine Detail-Meshes gab, hat er oft unglaublich viele unnötige Portale erstellt.
Ich möchte erstmal ein BSP-Level mit Shadern sehen.
In der Theorie müsste es mit Detail-Meshes ähnlich wie ein UDK oder Source funktionieren, aber selbst dann fehlt ja noch das direktionale Lightmapping.

Bei Unity und Torque3d habe ich ebenfalls noch keine großen Interior-Level gesehen, sondern eher größere Räume.

Bei C4 und UDK gibt es solche Demos allerdings, die ganz klar zeigen, das sowas geht.

Aus solchen Gründen würde ich Max Payne 2 eher mit diesen beiden Technologien machen, es sei denn eine kommende Demo beweist mir demnächst was anderes.

An mir liegt es nicht, ich wäre gerne dabei und würde mein kommendes Sci-Fi Interior Construction Kit mit dem neuen Regionen-System von A8 umsetzen, wenn es so leistungsfähig ist. Wir werden sehen, vorerst werde ich das Level in UDK und C4 bauen und wenn Unity 3 pünktlich kommt, werde ich auch das ausprobieren.

Nur um mal ganz kurz eines KLARZUSTELLEN:

das 64K Polycount limit ist für EIN model.
Ihr könnt soviele 64k poly modelle in euren levelplazieren bis euer rechne den geist aufgibt .

MAn würde also ein level min in 64k Poly blöcke teilen, hätte aber trotzdem freie größenwahl

BSP mit Normalmapping, läuft recht fix:
http://www.vulkanware.de/schutzkontakt/

Ist mit der A7.77 gerendert.

Edit:
Und Detailmeshes gibt es seit A5.
Oder sogar schon seit A4, daß weiß ich nicht.

Ähhm.. Ihr braucht hier keine Engineschlacht zu machen...
Lasst euch eure Gliedmaßen noch dran, denn bei den Features für Torque, Shiva, Unity, Ultimate, Engine-God und Carmacks-Mind
verstehe ich eh fast nur Bahnhof (Mann, ich werd zu Alt für diese modernen Dinge)...

Aber nun noch zum geschriebenen...
Was soll ich denn jetzt davon halten?
Machinery_Frank sagt etwa sinngemäss: "Ack kann ein bisschen gutes 3D, aber Spieletechnisch reicht es höchstens
für Casual-Games und Aussenlevel-Minigames". Ihr anderen sagt, mit der Engine lässt sich
(auch ohne den Einsatz von Plugins) einiges erreichen. Auch mit indie-kommerzieller Qualität.

Dann wurde der ABT-Tree angesprochen. Der rendert doch auch Innenlevel in optimierter Form, oder etwa nicht??
Nur, dass ABT nicht so schnell in innenleveln ist wie BSP, da ABT das in Echtzeit machen muss und BSP vorberechnet ist,
oder habe ich da etwas gründlich missverstanden (Dann müsste ich ja auf Pro upgraden, AARRggghh teuer.)?
Also, werden reine Innenlevel mit ABT gecullt\geclippt?

Was sagen denn die Game Studio Creators dazu (falls ihr dieses Thema mitgelesen habt)?

Ich will ja kein High-End Game machen, nicht mal Previous-Gen Spiele.
Mir würde umsetzungstechnisch sowas wie Quake 2 reichen, mit guten bonesanimierten Modellen
statt verwaschenen Schuhkartons, gut aufgelösten Texturen, ein paar Shader aus der Mtl_Fx Liste und max bis zu 60 Gegnern gleichzeitig,
die KI-Technisch auch nicht viel mehr machen, als aus der Ecke zu springen und
"UUUAAARRRGG aam äi MOONSTÖÖÖRR" machen, um anschließend Sensei- Shot-Ghuun kennenzulernen.
Solche Dinge wie Far-Cry oder Crysis, die hier genannt wurden, wird kein Team unter 12 Mann auch nur im
Ansatz hinbekommen, vom Budget ganz zu schweigen, selbst wenn man es als "günstige Alternativ-Version" erstellen wollen würde...
Und ich bin nur einer, zur Not hätte ich noch einen zweiten Texturen-Pinsler, und deshalb glaube ich,
dass ich Space-Dynamic-Occlusion-Volumination-Space-Normal-Displacement-Clouding und so nicht sonderlich oft brauchen würde.

Du gehst da sehr pragmatisch heran, finde ich gut.
Letztlich würde ich mir um die Leistung gar keine so großen Gedanken machen, sondern eher die Engine wählen, mit der ich am produktivsten arbeiten kann.

Ein Quake 2 Klon wäre auch mit A7 möglich, aber Du solltest die verwendete Engine gut kennen, damit das Ergebnis rund wird.
Unterschätze den Aufwand nicht, ich rate zu sinnvollen Kernfeatures die das Spiel bestimmen.
Multiplayer würde ich von vornherein draußen lassen, oder ein reines Multiplayer Spiel entwerfen.

ABT rendert auch Innenlevel mit einem variablen Octree, wie im Manual unter "Rendering" beschrieben.
Wenn es mit der Leistung eng wird, kannst Du die Räume als Mapentities anlegen und mit LOD arbeiten.

Optimieren wird man immer, egal mit welcher Engine.
Einfach weil sich manche Flaschenhälse erst ergeben, wenn Code und Grafikpracht aufeinandertreffen.

Am besten testen mit einem einfach gestrickten, großen Innenlevel mit Shadern und Platzhaltermodellen.

Ja, teste es mal mit einem größeren Level, vielen Modellen und vielen Texturen. Aber mit dem ABT wirst Du Indoor nicht viel Freude haben. Er kann zwar gut alles wegschneiden, was nicht in Sichtweite ist (Camera View Frustrum), aber da kann bei einem detaillierten Indoor-Game doch noch verdammt viel im Frustrum sein, obwohl es bereits hinter Mauern, Fußböden oder Decken verschwunden ist. Daher nutzen die die Engines für Interiors andere Szenen-Manager (BSP, Regionen und Portale). Nicht ohne Grund soll A8 Regionen bekommen, wie auch immer diese dann im Detail implementiert werden. Vermutlich haben sie Vorteile, die bisher mit ABT und BSP nicht erreicht werden können.

Der ABT ist sehr allgemein, flexibel, er funktioniert mit allem Möglichen. Aber er hat seine Grenzen bei großen Welten.

Aber das ist Theorie, probier es einfach aus und damit meine ich keinen Blockraum mit 12 Polygonen und ein paar Kisten darin.

Wie du schon sagst... Wenn ich mit GS gut arbeiten kann (und das kann ich) soll man es auch nutzen, nur ich hab die Befürchtung, dass ich zu schnell an einem Punkt komme, wo ich starke Abstriche machen müsste. Ich hab seit Ende A4\ Anfang A5 so lange auf die Features gewartet, die jetzt endlich alle da sind (Shaders, ent_decal, Bones, Spotlichter, polygongenaue Kollisionen) würde ich mich ärgern, wenn diese Features benutze und dann merke, dass mehr oder minder nur Spiele von der größe meiner Wohnung mit höchstens 3 Gegnern gleichzeitig möglich sind, ausser man beschränkt sich auf die grundlegendsten Features. Dann hätte sich das Engineupgrade nicht gelohnt.

Aber ich werde einfach mal weiter ausprobieren, und das mit den Platzhaltermodellen... Ich sollte es wirklich mal von hinten angehen und ein Worst-Case-Szenario basteln und dann sehen, wann bei meinem Rechner Diashow angesagt ist.
Dann kann ich weitersehen,

Wenn Du für große Innenlevel auf ABT zurückgreifen mußt, dann würde es Sinn machen von vornherein mit LOD und Map Entities zu arbeiten.
Das ist zwar kein Vergleich zu richtigen Regionen, aber bereits eine Annäherung.

Wenn Du versuchst ein großes Innenlevel im gesamten mit ABT und Shadern zu rendern, wirst Du sehr schnell eine Diashow produzieren.

Du wirst also nicht um LOD herumkommen. Sowohl für Objekte als auch für Shader.
Den mußt Du an die Verhältnisse anpassen:

Beispiel kleiner Raum, spät einzusehen:
-Nur eine Mapentity erforderlich die alle Modelle und sonstigen Entities im Raum enthält.
-Diese Mapentity kann früh geclippt werden, es wäre nur eine Detailstufe nötig.

Beispiel großer Raum, früh einzusehen, z.B. über einen langen Flur:
-Mehrere LOD Mapentities einplanen,
die mit mehr Abstand immer weniger Entities enthalten.

Türen als Event-Trigger nutzen um Räume sichtbar zu machen, etc...

Es gibt viele Tricks, um ein perfekt passendes Scene Management zu basteln bzw. das Vorhandene zu optimieren.
Wie schon geschrieben wurde, ABT ist flexibel und das ist die eigentliche Stärke. Große Innenlevel benötigen noch Trickserei.

Oder ganz anders, Halflife Style:
Kleine Level, öfter laden, dafür nur sehr kurze Ladezeiten.
Wäre eventuell eine Alternative.

Oder, ich weiß, klingt doof: Die Pro Version kaufen und BSP nutzen.
Sich auf längere Kompilierzeiten einstellen und mit den Beschränkungen zurechtkommen.
Oder die Regionen der A8 Beta nutzen.

Am meisten Saft verbraten dynamische Lichter, Du solltest die
sichtbare Anzahl also sehr begrenzen, zumindest auf Oberflächen mit Shadern.