Leistung von 3dgs zum Vergleich von UT

Einen Sonnigen Guten Tag.

Ich habe eine Frage bezüglich der Engine.

Ich habe schon viele Projekte gesehen mit tollen Shadern und schönen Texturen aber auch Models. Leider waren es oft nur kleine Teile also mehr Experimente mit 3DGS.
Also hat jemand Erfahrung bezüglich der Leistung von 3d Gs gesammelt?

Messen wir mal an Unreal 3D also sind Spiele
vom Niveau

Unreal 1)
Unreal 2)
Unreal 3)

Möglich sowohl Models ( Anzahl Polygone) als auch genutze Shader und Texturen bei Humanen FPS und PCS?!

Mich würden Erfahrungen und vieleicht auch Ergebnisse in form von Videos Interessieren.
Beziehungsweise eine Abgabe von 1,2 3.

Es geht um mein Spiel was ich gerade Entwickel und wollte wissen wieviel Meshes ich den Spieler Models und dem Level zu trauen kann bei guten FPS.

Viele Grüss von Kopf bis Füsse :-)

hi sammy,

na wenn du schon die A8 com hast, teste es doch einfach und lade models bis die framerate einbricht.

Ansonsten würde ich sagen.....Acknex entspricht ungefähr Unreal 4.

Das ist eine natürlich sehr pauschale Frage, weil die Leistung der Engine natürlich eng an die Bedürfnisse des Spiels gekoppelt ist. Grundsätzlich würde ich nicht ausschließen, dass man in der Lage ist, Spiele wie Unreal 1+2 mit Gamestudio auf gleichem Niveau zu entwickeln. Die Anzahl an Polygonen ist irrelevant, weil Gamestudio das genau wie jede andere DirectX 9 engine auch macht, höchstes Limit sind 65536 Polygone pro Modell. Das Gleiche gilt für shader - im Prinzip kannst du alles das machen, was du sonst so in anderen DirectX 9 Spielen auch siehst.

Wichtig zu wissen ist allerdings, dass du alles Notwendige - wie bei jedem anderen größeren Spiel auch - bedarfsorientiert selber entwickeln und zusammensetzen musst. Daneben brauchst du ein gutes, wenn gleich hohes, technisches Verständnis für das, was du machst - und wie du was effizient erreichen kannst, bei gegebener Qualität (oder andersherum). Beispielsweise hat Gamestudio zwar eine kleine shader library und ein paar Effekte dabei, die aber nicht als Maßstab dafür gelten sollten, was möglich ist.

Leistungstechnisch hängt dass dann weniger von der Gamestudio engine ab, sondern von deinem Geschick und von deinem Können und von der Art, wie du dein Spiel mit der Hand maßgeschneidert hast - sowohl aus technischer als auch aus artistischer Perspektive.

Meiner Meinung nach ist es sowohl möglich ein Spiel in Klötzchengrafik zu schreiben, das die Mindestanforderungen von Skyrim braucht, um anständig zu laufen, als auch ein top notch Spiel mit wunderbarer Grafik für diesselbe Maschine oder weniger. Ein aktuelles Beispiel für soetwas ist das Spiel Supercan, falls du das nicht kennst. -- Ist aber vielleicht auch nicht 100%ig zu vergleichen, da es mehr Comicgrafik ist, und mit Unreal zielst du ja schon eher auf realistische Grafik ab.

Tut mir Leid, wenn dir das jetzt zu paraphrasierend ist. Das Problem was du haben wirst, ist, dass wenn du keine Details lieferst, dir nicht sehr technisch geantwortet werden kann. Zweitens ist damit zu rechnen, dass es Leute gibt, die eventuell größere Projekte gestemmt haben (oder versucht haben, soetwas in Angriff zu nehmen), und an technischen Hürden gescheitert sind (oder hatten), für die die engine nichts kann - aber die Programmierer dahinter, aus Zeitdruck, wenig Fachwissen usw.

Das heißt: Willst du dein Spiel mit Wahnsinns-Optik versehen bei guter Laufzeit, brauchst du nicht nur einen Grafiker, der dir Wahnsinns Modelle, Level und Texturen basteln kann, sondern auch noch einen Wahnsinns-Techniker, der genau weiß, was er da macht und was zu tun ist.

Da kannst du auch dein Unreal 2 nachbauen. Zu Unreal 3 und darüber kann ich nicht viel sagen, aber ich meine (korrigiert mich, wenn ich falsch liege), dass die Engine DirectX 10 und höher verwendet?

EDIT: Ich hoffe du meinst das ironisch ^^

also es gibt pro Modell eine 64k Grenze, dh. ein Modell darf nicht mehr als 64.000 polyone (oder vertices?!) haben.
nun ist 64k doch schon sehr übertrieben für ein "normales" Spielermodell aber generell würde ich sagen das du mit 3000-6000 Polygone im sicheren Bereich bist.

sehr übertrieben..
mein Raum den ich gerade ausdesigne hat mit allen objekten darin, der weltkarte und dem Tod insgesamt 43.112 Polygone, wovon auch nicht alle sichtbar im Screen sind.
mit Shadern, Beleuchtung und Animationen komme ich damit immernoch auf 340 FPS.. mehr als genug!

Btw.. als Beispiel: Malcom aus UT3 hat gerademal 3266 Polygone.. Daran kann man also schonma garnicht messen wiveiel leistung eine engine bringt. Es liegt allein an deiner Technik, der verarbeitung und deinem Wissen für problemlösungen, wie gut eine Engine eine große modelnenge, Shader und Animationen aushält.

Der Trend geht auch wieder zu weniger Polygonen, dafür mehr Details mit Normalmaps + Specmaps + Heightmaps + Sonstiges (je nach Technik). Ich hab mal irgendwann in einem Bericht gelesen, dass z.B. die Spielermodelle in Call of Duty 4 weniger Polygone hatten als in CoD 2, dasselbe gilt für das Masterchief Modell in Halo 2 verglichen mit dem in Halo 1.

Andererseits, es kommt auch mal wieder darauf an, was man für ne Kameraperspektive hat (1st Person vs. 3rd Person vs. isometrisch), wie groß und detailliert das Level ist usw. --- beispielsweise haben in beatemup's die Charaktere traditionell relativ viele Polygone, weil das einfach die beiden zentralen Modelle im Spiel sind und man daher viel viel mehr Details zeigen kann, bei Dead or Alive auf der (ersten) XBOX hatten die so 10-14.000 Polygone, der Masterchief aus Halo 1 auf dem gleichen System, aus der gleichen Ära dann aber wiederum nur 2.000. Das variiert dann aber auch je nach Anforderungsprofil, die Modelle in Virtua Fighter 5 (2006) auf der PS3 hatten durchschnittlich ca. 40.000 Polygone, die Spielerfiguren in Uncharted: Drake’s Fortune hatten wiederum 20-30.000 Polygone. NPCs haben deutlich weniger, in GTA 4 z.B. hatten die Spielerfiguren 8-10.000 Polygone, die NPCs durchschnittlich 3-4.000.

Also man kann sich schon an den Zahlen heutiger Spiele orientieren, wobei man das aber so ummünzen muss, dass die Ansicht und das Genre in etwa zum eigenen Spiel passt. Wesentlich ist vor allem der Einsatz der oben genannten zusätzlichen Texturen, bei GTA 4 wurden z.B. für die Figuren entweder 256x256 oder 512x512 diffuse, specular und normal maps verwendet.

Rennspiele sind da teilweise noch krasser, da kann man in heutigen Spielen wie Gran Turismo oder so 80-100.000 Polygone pro Auto erwarten.

[EDIT] grundsätzlich kommen Grafikkarten heutzutage mit großen Polygonmengen sehr gut klar, die Performanz wird bei den meisten Karten noch nichtmal ausgereizt. Vielmehr entstehen bei Texturen und Rendertargets arge bottlenecks, weshalb eine gute Architektur des Renderings sehr wichtig ist. Deshalb kommt es nicht mehr soooo auf die Polygonanzahl an.

Guten Morgen,

--------------------------------------------------------------------------
@HeelX: Ja ich gebe dir insofern Recht, es kommt natürlich auf das Spiel an bzw. an die Bedürfnisse, des Spiels, will ich eine riesen weitsicht haben, befinde ich mich nur in Dungeons, wird es ein Singleplayer oder Multiplayer ec.

Es kommt natürlich auch auf den Entwickler an wie geht er mit dem Werkzeug was mann ihm gibt um, nutz er alle Fähigkeiten der Enigine ec.
--------------------------------------------------------------------------

Aber grundsätzlich sieht mann zwischen den Engines die auf dem Markt sind immer Unterschiede ungeachtet dessen, von welchen Entwickler sie benutzt wurden.
zb. ist die Crytek Engine detailierter als die Unreal Engine, dafür ist die Unreal engine Leistungfähiger, mehr Frames bei geringerer Rechnerleistung, bei ausreichender Ausbeute an Details. Es sind zb. auch grössere Level möglich durch Streamingtechnik.

Mann kann also denke ich schon nicht sagen alle Engines haben die gleiche Ausbeute zwischen Frames, benötigter Rechnerleistung und zeitgemässen aussehen.

Wenn ich natürlich einen Super Rechner habe kann ich die Leistung ein solchen Engine noch nach oben drücken was aber nicht heisst, dass ich alles richtig mache, da vieleicht der "Kunde" eine schwächeren Rechner hat und dieses Leistung gar nicht warnehmen kann.

Ich habe auch schon eingige Shader und Models getestet, ich bin mit der Leistung soweit sehr zufrieden, für meinen Teil. Ich habe auch schon seh viel Demos und "Scriplets" getestet die sich so fand. Auch von dir HeelX, die mich sehr wirklich sehr beeindruckt haben und ich "Speichel" im Mund hatte.
Also 3DGs vermag viel zu leisten, Wasser, Normalmap, DOF ec. alles Sachen die aktuelle Engines auch besitzen.

Natürlich von ein Indy Projekt nie so aussehen wie Call of Duty oder Crysis was nicht nur an der Engine liegt sondern auch an der Entwicklung, also der Zeit bzw. Manpower 1 oder 2 leute würden mit der besten Engine nicht das erreichen was 30 Designer und Entwickler machen.

Nur hätte mich Interressiert ob es jemand schon geschaft oder in Irgendeiner weiss wo sich 3DGS einreiht, es gab ja wohl auch mal ein MMO Projekt von JCL selbst was wohl aus Zeitgründen verworfen wurde. Vieleicht gibt es da noch mehr Projekte die etwas grösser waren und vieleicht auch auf den Kommerzielen Markt abgezielt hatten.

Ich weiss es sind viele Fragen auf einmal und mann kann vieles nicht pauschalieren, aber ich würde halt gerne mal wissen was mit guter Mannpower und Erfahrenen Entwicklern und Designern mit 3DGS möglich wäre.

Viele Grüsse
Sammy

ok sammy.... klingt so als wärst du noch recht jung an Jahren.

Was willst du eigentlich? Eine 3d Engine lizensieren und dich dann hinstellen und labern das du damit crysis 23 machen könntest?

Oder du setzt dich einfach hin und bastelst an kleinen Projekten....machst so Sachen aus den AUM's.
Auf diese Weise lernst du die engine eher kennen.

Wenn du unbedingt ressourcestreaming brauchst, kannst du dir ein system auch selbst schreiben.

Es liegt an dir wie das Endresultat aussieht. Du kannst mit einer high-end engine totalen Rotz produzieren oder wenn du Acknex richtig nutz Unreal 4

Ach so..... Beispiele von veröffentlixhten Projekten findest du links auf der gamestudio seite.
Und das Großprojekt von jcl wurde nicht aus zeitgründen eingestellt sondern weil der auftraggeber nach afrika geflohen ist.

möp?

wieso der Angriff?

1. bin ich nicht Jung an Jahren, eher etwas Älter ,-)
Ich habe schon auf dem c64 Programmiert, Programmiere aber Hauptsächlich Webandwendungen.

2. habe ich geschrieben das es wohl klar ist auch mit der besten Engine kann 1 oder 2 mann kein Crysis produzieren.
3. und Unreal 4 , ok ,-)
Ich habe auch nicht behauptet das ich Resourcen Streaming benötige nur das es existiert.

Ich bin noch nicht alzulange dabei um genau zu wissen was mit dem Projekt von JCL passiert ist, mich würde nur Interressieren, welche Grafik Qualität das Projekt hatte bzw. vieleicht gab es ja schon Videos ec. ,-)

Und leider sind die Beispiele sehr veraltet die es in der Gallery gibt. und das Mainvideo kenne ich, auch die anderen Videos, auch alle Videos die ich so in Youtube fand.

Und ich habe und werde nie behaupten das ich was in der Qualität von UT 3 oder gar was besseres Designen kann, dazu bin ich
A.) zu Frisch und b.) zu wenig Zeit.
Egal mit welcher Engine.

Mich Interresiert es nur Grundsätzlich und Formel was schon gemacht wurde bzw. welche Erfahrungen einzelne Member da gemacht haben. Und vieleicht "kitzelt" mann ja auch noch mehr schöne Videos raus ,-)

und noch was, ich erwarte nicht das GS mein Projekt von alleine baut und finde GS so wie es ist Super, bis auf ein paar weniger updates bei den Editoren die es verdient hätte.

in diesem Sinne dieser Beitrag dient nur zu Recherche und zur einafchen Info und Ehrfahrungsaustausch.

MFG
Sammy

Ich hab mich nur kurz mal im Showcase umgesehen, manche Projekte davon sind schlichtweg genial, für den Fakt, dass sie von meist blos einer Person erstellt wurden:
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showgallery&Number=399974
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showgallery&Number=373539
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showgallery&Number=390492
Auch wenn du ein bisschen im WhatAreYouWorkingOn-Thread blätterst, findest du richtig gute Sachen, zum Beispiel den Angelsimulator, welcher durch schöne, detailreiche Level besticht.

Gamestudio kann einiges, man braucht blos Zeit und Assets, oder halt noch mehr Zeit

@Sammy: Mit deinen Ausführungen zum UDK oder Cryengine hast du natürlich völlig recht. Da steckt viel mehr Substanz, manpower und vor allem Funktionalität hinter, keine Frage. Technisch gesehen bietet dir diese AAA engines schon einiges mehr an Raffinesse und eingebetetter middleware, die du nutzen kannst (u.a. Scaleform, SpeedTree, Allegorithmic Substances, PhysX, Havoc, Beast...). Mir ist auch kein Entwicklerstudio bekannt, dass ein Großprojekt erst mit Gamestudio, dann mit dem UDK oder der Cryengine gemacht hat. Es gibt aber wohl einige, die von Gamestudio nach Unity gewechselt sind.

Ich würde gerne mehr über deine Pläne erfahren.

Also vergleichen kann mann meiner Meinung nach nur 2 dinge(Vorwissen mal ausgenommen):

1) Was ist implimentiert, und was muss ich selber implimentieren?
2) Wie gut(technisch gesehen) kann ich das ganze selbst erweitern?

Guten Abend,

genau darum ging es was würde passieren wenn ein kleines Projekt doch mal grösser wird und aus einer Idee bzw. aus einem Wohnzimmer Projekt was grösseres wird, dann stellt sich die Frage kann mann mit 3dgs weiter machen oder muss mann alle Scripte ec. einstampfen und zu einer ganz anderen Engine greifen.

Zu meinem Projekt @HeelX:

Es wird ein 3 Person Multiplayer Shooter mit RPG Elementen.
Kampfsystem wird Actionlastig aber nicht nur Fernkampf sondern auch Nahkampf.

Wichtig dabei sind Elemente aus vergangen Tagen und wiederspielbarkeit und Suchtfaktor.

Es wird auch ein Level und Skillsystem geben.

Prozess:
Mainchar 60% ( Blender Model Lowpoly und Highpoly für die Normalmap)
Level Texturen 30% (Modulares SCifi Konzept) 20% da diese gerade in Blender erstellt werden.
Level Konzept 90%
Scripte 30%

Projekt wurde im März 2012 angefangen.
Seit 1 Jahr Lerne und Teste ich 3DGS.


Weitere Details gerne auf Anfrage per PM oder Mail.
MFG
Sammy

ich habe auch viel mit 3DGS rumgetestet, lerne es seit A6.. und brauche immernoch Hilfe ^^"

Aber ich und ein Buddy ausm Forum erarbeiten nun mein [ironic]kleines[/ironic] Traumspiel, dabei versuchen wir eine möglichst gute optische leistung, aber dennoch einsehr schneller gameplay zu erzielen.
Die Kunst ist nunmal wirklich an unwichtigen Stellen einzusparen (sofern man die Erfahrung hat und weiß wo), und dafür an brisanteren Stellen ranzuklotzen.
So lege ich weniger Wert auf highpoly Meshes, da ich denselben Effekt auch über gutes texturmapping und Normalmaps bekomme ^^


Es ist alles eine frage der eigenen technischen leistungsfähigkeit und Erfahrung. Sicher geht kein Crysis 3 mit A8.. Aber das ist ja auch nicht der Gedanke dahinter. Die Engine soll für Anfänger bis Fortgeschrittene ein guter Einstieg sein, und für letztere auch Leistungstechnisch auf Höhe aktueller Titel stehen - dabei rede ich nicht von Highend-Deca-A Titeln wie Crysis oder Doom4 (baaaald!).. sondern im bereich von Alice.
Ein super Beispiel für Optische feinheit ist Supercan.


Ich schätze mal das ein Enginewechsel sich wirklich nur lohnt, wenn man Plattformunabhängig, Mobil oder im Highend Bereich arbeiten will. Allerdings finde ich das A8 technisch mit UE3 mithalten kann!

!"NACHTRAG"!

Guten Morgen ,

ich muss zusätzlich noch anmerken bevor ich mich für 3dgs entschieden habe habe ich viel Recherche betrieben.
Ich habe Unity 3 , Unreal UDK und div. andere Installiert und getestet und für mich als Anfänger in diesem Bereich war 3DGS am meissten Interressant, eben wegen dem Forum und voraldingen dem Magazin AUM (Thx George).
Denn Auch wenn ich seit Jahren Programmiere, Spieleprogrammierung ist noch mal ein andere Schritt.

Und auch die Lizensen bzw. die Preise erledigen bei einem Wohnzimmerprojekt das übrige.

Ob ich mit meiner Idee mal Geld verdiene oder nicht, mann wird sehen, noch geht es mehr um Erfahrung und neue Welten erkunden.

Aber sollte ein Publisher doch mal auf mein Spiel aufmerksam werden, wäre natürlich auch schön gewesen zu sagen, "was du willst grössere level oder willst mehr player (multiplayer),
Kein Problem ! ". Denn nicht umsonst gibt es neue Versionen von UT UDK und natürlich von Gamestudio, weil die Technik weitergeht, neue Techniken gefunden werden um mehr Polygone zu nutzen oder andere Techniken die Spiele noch Realistischer oder Leistungsfähiger machen, Spielerzahl ec.
Deswegen hatte mich Interressiert zu welchen Produkt Gamestudio 8 ungefähr gleichzieht ohne die Komponente Designer denn auch bei UT gibt es schönere Spiele und nicht so schöne weil das Budget kleiner war und weniger Designer zu Hand waren.

Und es gab auch in der Geschichte der Entwicklung Designer/Entwickler die das letzte aus dem Rausgeholt hatten was möglich war. Ein sehr gutes Beispiel für diese Leistung war der C64 , von Anfangs Klötzschen Grafik bis zu "defender of the crown" war alles drin.


MFG Sammy

So ne Diskusion überdie Leitungsfähigkeit macht keinen Sinn wenn man keine Metrik hat.

Dazu müsste man wirklich mal eine gleiche Szenerie Bauen
(Polygone, Shader etc)
Und die Frameraten aufdem gleichen System vergleichen.

Außerdem ist es ne Frage wie tief man in den Code der Engine runtersteigen kann,
um sich zB einen Custom Terrainrenderer zu schreiben.
Denn die Performance hängt sehr start von der richtigen Umsetzung ab.
Und da gibts einfach Schranken bei 3dgs, da bestimmte Bereiche
abgekapselt sind (der sourcecode der Engine ist ja nicht offen), und man langsamere Workarounds schreiben muß.

zB ist das Terrain von Skyrim nicht einfach ein Viereck mit
verschieden hohen Polygon-Vertecies, sondern
Wird dynamisch in vielen LOD stufen zusammengebaut.
Es wird auch immer nur ein Teil der Terraindaten geladen.
Das wird man nicht mit der gleichen Performance in 3dGS nachbauen können.
Sicher, ein Workaround ist möglich, aber nicht mit dem gleichen Speed.

Der andere (sogar wichtigere) Bereich sind die Tools um das Projekt zu basteln.
Das ist auch der Grund warum Unity etwa so ein Erfolg ist.
Es hat gute Tools. (Vor allem für nicht-Coder, denn die braucht ein größeres Projekt)

Ja, der Maßstab ist ganz wichtig. Nur die Frage ist: Wenn du die gleiche Szene hast und dich auf einen Katalog an Effekten, Fachlogik und so weiter geeinigt hast - baust du es dann nach den Standardtools zusammen oder erlaubst du, dass man pro engine fachmännisch und spezifisch alle (gängigen Kniffe) ausreizt um das Tollste rauszuholen?

Zu Skyrim: Naja, wenn du die Höhendaten der Parzellen in einer geeigneten Datenstruktur ablegst und dann diese über einen Hilfsthread nebenläufig von der Festplatte holst und dann das mesh der Randparzellen (3x3-1 = 8) anpasst, dann sollte das reichlich schnell sein und geht auch alles mit Gamestudio - ich sehe da nicht das Problem, da es ja ein sehr spezielles feature eines einzeln herausgegriffenen Spiels ist. Auch hängen die Fähigkeiten des engine toolsets ja auch stark davon ab, was du wie in deinem Spiel dann spezifisch machst.

Außerdem unterstützt Gamestudio Terrain-LOD, siehe terrain_lod:



Erweiterst du die engine also um konkrete tools mit konkreten workflows, fokussierst du die engine und hast dann weniger die Möglichkeit "alles" zu machen. So wie ich das verstanden habe, ist dies aber das credo von den Gamestudio Entwicklern und erlaubt es, leistungsstarke, eigene in sich geschlossene Lösungen zu entwickeln, bei denen man nicht erst die ganze Engine behauen und beschlagen muss, dass es irgendwann dann klappt.

Guten Tag,

1. Natürlich kann mann am besten "Messen" wenn mann ein vergleichbares Scenario gegenüberstellt.

2. Zum Thema "Tools", Unity ist da mit verschiedenen Tools natürlich am weitesten, das geht vom Ingame Terrain-Editor bis zum Material Editor bis zum im Editor bearbeitenden Beleuchtung.( mein Weihnachtstraum ( Material Editor wie in Unity in WED und den GED verschmolzen in WED so ein bischen Unity Feeling ,-) )

Auch diverse Fähigkeiten von anderen Engines wie z.B. die Streaming Technologie um grosse Aussenareale zu Erstellen und dem "Spieler" vorzusetzen sind dabei vieleicht von Entscheidung.

Auch die Fähigkeiten des Einzelnen "Designers" oder Entwicklers sind dabei tragend. Wie gesagt ein guter Programmierer holt auch aus einem "Brotkasten"(C64) das letzte raus, keine Frage.

Aber im Grunde lassen wir mal alle diese Merkmale aussen vor,
und stellen wir uns mal einen einfachen Shooter wie z.B.: UT 3 vor auf ebend dieser seiner Engine und stellen wir uns vor den selben Shooter würden wir übetragen auf 3 DGS , würde es funktionieren, mit dem selben FPS, oder eher UT2 ?

MFG
Sammy

Sammy,

du kannst die FPS nicht als Vergleichskriterium heranziehen und dann auf ein Spiel einer vorherigen Generation verweisen, die qualitativ nicht so weit war und dementsprechend auch nicht die Bandbreite an Technik (Shader, Mehrprozessorkerne, GPU Verwendung), Texturfülle (Diffuse, Normal, Height plus Weißdergeiermaps), Postprocessing, etc.pp. verwendet/bietet.

Ich bleibe dabei: auch wenns schwierig wird, Du kannst ein Spiel in der Qualität wie UT 3 mit Gamestudio machen, natürlich vorrausgesetzt, du löst das content-Problem. Die Frage der FPS hängt davon ab, was du für Techniken einsetzt; insgesamt bezweifle ich aber, dass du auf denselben Speed kommst wie mit UDK.

Ich rate dir, vom Standard her erstmal UT 2 anzupeilen und wenn es geht, die Schraube höher zu drehen; wenn ich mir die screenshots von UT 3 nochmal anschaue sieht das alles nämlich furchtbar übertrieben aus.

Hallo HeelX,

nein reine FPS nicht und viele Effecte in UT 3 sind auch extrem übertrieben, ja da gebe ich dir Recht.
Das Content-Problem ist natürlich eine Sache für sich, ich selbst denke ich bzw. hoffe ich werde warscheinlich eh so Richtung Doom 3 anpeilen bzw. UT 2, alleine von der manpower und natürlich sind auch meine Künste in sachen Model Design noch eher am Anfang.

Wie gesagt es war halt reines Interesse, vieleicht auch wie du ja selbst richtig festgestellt hast, der Zukunft wegen, sollte , ja sollte überhaupt, ein Publisher anfragen , um zu sagen "hey das geht in der Qualität" oder "hey das geht leider nicht" auch mit 10 Mann nicht. Denn wie viele wissen auch wenn mann als Entwickler den schnellsten Rechner hat, bringt das alles nichts wenn mann nachher der einzigste ist der das "Produkt" benutzen kann ,-)

Und wie gesagt wenn mann UT 2 oder doom 3 ähnliche Spiele schaft, Talent ec. verrausgesetzt, diese auch auf Durchnits Rechnern laufen, bin ich Persönlich mehr als zufrieden .

Verzeit mir meine Unwissenheit und Neugier diesbezüglich.


MFG Sammy

Vielleicht solltest du auch erstmal versuchen, -ein- prototypisches Level zu bauen mit Standardgegnern und einer speziellen Sache, in der Optik, die du haben willst. Dann hast du wahrscheinlich schon einen ziemlich guten Gradmesser von dem, was dich bei einer Vollproduktion erwartet.

Hallo HeelX

ja da bin ich schon dabei :-) , bin noch bei den Texturen und dann werde ich ein erstes Level erstellen um dieses mit Shadern zu Testen ec.



viele Grüße
Sammy

Ich möcht hier mal noch anmerken, dass man mit Gamestudio von der Renderleistung her recht zufrieden sein kann:
(Klicken für volle Auflösung)

Dem kann ich nur zustimmen.
Mit einer effizienten Programmierung und einem gut durchdachten Level of Detail management kann man meiner Meinung nach auch mit den 'großen' mithalten.

? Das Beispiel mach doch gar keinen Sinn.

Denn weder ist dein PC ein Standardgerät (wie bei einer XBox wo alle die gleichen Vorraussetzungen haben)
noch läßt du das gleiche Rendering auf einer anderen Engine laufen.

Es zeigt nur daß es läuft.

Vieleicht wäre die Szene auf dem UDK 30 mal schneller, who knows.

Vergleichen kann man nur wenn man einen Vergleich hat.

Ich find aber allein schon den Ansatz "alles rauszuholen" völlig falsch.
Denn das wirft im Trend (wie so oft hier) nur Spiele mit schlechter Performance ab.
Am besten ist es wenn das Spiel auf einer 5 jahre alten Krücke noch ordendlich läuft.

Einer der wenigen Luxusgüter die Indyspiele habe ist, daß
man keine Highend Grafik erwartet.
Und danach sollte man sein Design richten und nicht
versuchen irgendwie wie ein kommerzielles Spiel auszusehen, aber
derbe Zuppelperformance zu haben.

Da ich an einem Spiel arbeite, dass Unreal 2004 ähnlich kommen soll(vor allem in der Performance), möchte ich auch kurz ein par Worte verlieren:

Es gibt soviele Aspekte, die eine Engine leisten muss und abdeckt,..
Ich weis nun nicht genau, was direkt Direct X oder die Grafikkarte dazu beiträgt.(Bin Softwareentwickler und Designer, kein Hardwarespezi)-Aber es fängt beim berechnen der Polygone an, geht ueber die Dekompression, Darstellung und Berechnung von Texturen, Modelgroessen,Polygonmengen, Partikel und Modelmengen.

Selbst mit einem Pentium 800 Mhz und einer Gforce Fx 5200 läuft Unreal 2004 immer noch ruckelfrei bei höchstem Detailgrad.ich nehme an, diese Engine hat nicht nur ein besseres Speichermanagement...

Im Selbststudium empfand ich eigendlich immer die Engine als Schwachpunkt und da liege ich sicher nicht ganz falsch.Irgendwo steht auch geschrieben, sie sei für RPGs ausgelegt und nicht für schnelle Prozesse.
In meinem eigenem Spiel bricht irgendwo immer die Framerate ein und liegt bei 70 Fps.Mit UT im vergleich sollte sie eigendlich bei theoretischen 400+ liegen.(Utopisch gesehen).Was ich alles ausprobiert habe, steht auch in meinem Tutorial geschrieben.In UT gibt es im Spiel nur eine einzige Stelle, in der FPs einbricht.Und das wäre im letzten Level der Antrieb des Schiffes.

Aber eigendlich kann mir das in gewisser Hinsicht auch recht sein.
3D gamestudio fordert heraus und der Designer/Programmierer versucht das beste draus zu machen.Der eine aus finanziellen Gründen, der andere ehr aus Spass und Ehrgeiz, wie meine Wenigkeit.Darum sitze ich immer noch nach guten 2 Jahren Entwicklungszeit an meinem 2. Level(Das erste ging verloren) und optimiere, wo es nur geht.Es ist erstaunlich, was der Entwickler erreichen kann.
Sicherlich wird niemand 100% der Leistung erreichen, wie in UT aber ich bin fest davon ueberzeugt, dass rund 80 % möglich sind.Vielleicht etwas weniger.
Dafür kostet die Engine auch nur ein Bruchteil.
Um das Know-How zu entwicklen, was nötig ist, um diese Leistung zu erreichen, braucht es schon ein par Jahre Erfahrung in der Programmierung und rund um die Engine selbst.Und wer auf Qualitaet und nicht auf Quantitaet setzt, wird nochmal 2 Jahre drauf packen müssen.

Desto besser du programmierst, desto besser der Resultat.
Ganz einfach.

Unglaublich! Ein Spiel von 2004, das auf Hardware von 2003 läuft. Das muss ja ein überirdisches Speichermanagement sein...
Wo immer das steht: Es ist Unfug. Grober Unfug.
Immer wenn ich mit meinem Golf zum Supermarkt fahre muss ich an der Ampel halten. Mit einem Audi müssten es aber theoretische 800 PS sein (Utopisch gesehen). Im Supermarkt gibt es Wurst. Und zwar an der Wursttheke.

Das ist einer von vielen Faktoren, ja.

@Uhrwerk

Zur Hardware: Mir ist doch egal, von wann die Hardware ist.Ich habe extra dazugeschrieben, das es ein Vergleich sein soll.Es ist auf jedefall Fakt, dass Unreal 04 performancetechnisch kaum etwas das Wasser reichen kann.Jedenfalls nach meinem Gefühl zu urteilen.Wenn du anderer Meinung bist, dann nenn mir ein Gegenbeispiel.

Das die Engine auf RPGs ausgelegt sein soll, habe ich schon öfter gelesen.Ob es so ist, kann ich nicht sagen.In einigen Posts ist immer wieder davon die Rede.

Ich weis zwar nicht, wieso dich mein Post so derbe anmacht, aber etwas netter könntest du dich schon verhalten, findeste nicht?In deinem Fall magst du wohl sehr gerne ironisch werden.
Dein letzter Satz ergibt keinen Sinn.Was hat die Ampel mit den utopischen 800Ps zu tun?

Aber damit auch du mich verstehst und nicht in deiner Ironie versinkst(das wirkt unreif und lächerlich): Mein Beispiel sollte nur anführen, dass unter gleicher oder höherer Vorraussetzung theoretisch die selbe Leistung erzielt werden "kann".Ich bin weder auf meine Programmierkentnisse eingegangen noch auf sonstige Aspekte meines Spiels oder?Aber für dich schreibe ich nächstes mal einen extra Post

EDIT:
Was ich noch anmerken will: Es hat schon seinen Grund, wieso die Unreal Engine im 5 stelligen Bereich liegt und Gamestudio
ein par Nullen weniger hat

Bei den "Preisvergleichen" nicht vergessen:
Die UT Engine (war) eine reine Lizenzengine, die nur wenige Produktionsstudios
nutzen durften.
Deshalb ist das auch eine anderere Preisstruktur und ein anderer Markt.


Eine Software für einen Blumenladen wird auch
mehrere Tausend Euro kosten, wenn sie eine Auftragsarbeit und speziell zugeschnitten ist.
Als Massenprodukt (wobei es da keinen so großen Markt gibt)
würde die gleiche Software warscheinlich nur 50€ kosten.

@Ayumi
Gute Performance hat nicht nur etwas mit der Engine zu tun.
Teilweise sogar recht wenig, vor Allem im Grafik-Bereich.
Da kann die Engine noch so "gut" sein, ein komplexer Shader zum Beispiel wird durch eine andere Engine auch nicht schneller laufen.

Hauptsächlich liegt es an den Personen, die das Ganze programmieren.

In der Engine hinter Unreal Tournament steckt keine Magie. Klar, sie hat sehr gut durchdachte features, aber diese kann man ebenso für die Acknex Engine verwirklichen.
Die Engine an sich bietet die Basis, performance-starke features kann man selbst dafür schreiben.

Es ist doch absurd eine Engine zu loben, weil sie auf der damals verfügbaren Hardware läuft.
Merkste selber, oder?
Ich wüsste ja nicht mal wofür. Die Aussage "ist performancetechnisch super" ist überhaupt nicht überprüfbar, weil sie viel zu vage ist.
Das machts aber doch nicht wahrer. Wenn hier alle schreiben würden, dass man mit Unity nur Tower Defense Spiele machen kann und die Unreal Engine nur für Schachspiele taugt wäre es genau so unsinnig.
Mich macht derbe an, wie hier Äpfel mit Birnen, Bananen und Handstaubsaugern verglichen werden. Und das dann auch noch auf Basis von Gefühlen. Ich sehe nicht wo ich etwas beleidigendes, kränkendes oder unwahres geschrieben hätte. Der Post sollte dich nicht verletzen. Wenn Du dich durch ihn gekränkt fühlst, dann möchte mich dafür entschuldigen. Ich bin aber auch der Meinung, dass man ein bißchen Ironie abkönnen muss, wenn man Sachen in einen Pott wirft, die da nicht reingehören.
Gar nichts. Das war ein Wink mit dem Zaunpfahl. Was hat dieses Unreal Level mit dem Antrieb mit deinem Spiel zu tun. Oder mit der Performance der Unreal Engine? Wieso redest Du bei 70 fps von "einbrechen"? Wie schließt Du, dass die Unreal Engine eine Szene mit 400 fps rendert ohne das ausprobiert zu haben? Was sind utopisch gesehene theoretische fps?

Die Framerate in irgend einem Spiel hat überhaupt nichts mit der Leistungsfähigkeit der Engine zu tun. Wenn UT 2004 immer flüssig läuft, dann zeigt das, dass die Leveldesigner gute Arbeit geleistet haben und die Level genauestens auf die Limitationen, die durch die Engine gegeben sind, abgestimmt haben. Wenn Dein Spiel an vielen Stellen ruckelt, dann ist das ein sicheres Zeichen, dass Dir das an eben diesen Stellen nicht gelungen ist. Dafür kann 3DGS überhaupt nichts.

Wenn Du die Performanz zweier Engines vergleichen willst, musst Du eine Metrik heranziehen. Z.B. gerenderte Kilopolygone pro Sekunde. Oder bei welcher Framerate wird die Sponza Szene aus einem bestimmten Winkel heraus gerendert bei vergleichbarer Renderingqualität. Und selbst das ist es enorm schwierig zu bestimmen, was "verlgeichbar" in diesem Kontext bedeutet. Du kannst auch bzgl Features vergleichen, aber das ist eine andere Geschichte.

Hat es aber nicht. Exakt das ist mein Kritikpunkt.

@Kartoffel
Das ist natuerlich richtig.Darum fuehrte ich auch an, nicht genau zu wissen, welcher Bereich was berechnet.UT hat mit Shadern recht wenig zu tun.(Auch ein Grund, wieso ich dieses Spiel als Vorlage benutze)...ansonsten nur das Uebliche zu dieser Zeit.Environment Mapping, einige Pipline Effekte (Schatten) und Reflexionen sowie Detailmapping.Shader sind hier vielleicht ein schlechtes Beispiel aber ich versteh , was du meinst.

Ja, hinter UT steckt auch eine ganze Armee von Entwicklern.Ich werd mich demnächst mal etwas stärker damit befassen, welche Aspekte eine Engine wirklich bieten kann.



@Uhrwerk
Mein Beispiel mit meinem Level sollte nichts aussagekräftiges sein.Ich bin seit 2005 Designer und Programmierer, nicht unbedingt unerfahren.Daher habe ich auch keine direkten Fakten genannt.Mein Level hat maximal 20000-25000 sichtbare konstante Polygone und ist 20000 Quants gross.Daran arbeite ich nun seit 2 Jahren um immer mehr zu optimieren.Ich benutze keine Shader und versuche alles aus UT zu entnehmen, dass sich performancetechnisch umsetzen und steigern laesst.Und trotz dessen habe ich diesbezueglich Ruckler, die auf 40fps runtergehen.Darum war ich nur etwas erstaunt.Das Problem habe ich nur mit Gamstudio(seit 2005, A5), mit keinem anderem Spiel/Engine.

Letzten Endes gebe ich dir recht, ich hätte nicht Äpfel mit Birnen vergleichen sollen.Das sollte auch nur eine objektive Empfindung sein.

Ayumi,
wenn deine fps auf 40fps sinkt, dann hast du entweder uralte hardware oder du machst irgendetwas total falsch.
Die sichtbaren Polygone sind dabei ziemlich egal, bzw werden auf hardware die maximal 4 Jahre alt ist erst ein problem wenn es mehr als 500k sind, wobei das noch eine sehr niedrige Zahl ist.
Problematisch sind dagegen dinge wie viele unterschiedliche Texturen, selbst wenn sie zum gleichen modell gehören (hier helfen in der regel atlas texturen, auch wenn man dann mal ein paar mehr polygone benötigt), viele einzelne objekte und transparenz (schonmal 1000 halbtransparente hintereinander platzierte pixel gehabt die das ganze bild verdecken?).
Zusätzlich kann man mit dem BSP von alten Gamestudio versionen bzw A8 Pro in einigen Fällen auch noch einiges optimieren, wenn man es geschickt einsetzt.
Aber hier müsste man dann einfach mal ein bisschen profilen und dann würde sich herausstellen wo die probleme liegen.

Das gilt übrigens für jede beliebige Engine.

Was mich sehr interessieren würde wäre ein Screenshot (samt F11 Debug-Panel) der Stelle deines Levels, in welchem die FPS niedrig ist, und dann vielleicht noch ein weiterer aus einem anderen Blickfeld, bei welcher das Level schneller gerendert wird. Es wird dich auch niemand für die Optik des Levels/ Qualität der Assets kritisieren, solltest du deswegen nichts dergleichen zeigen wollen, da jeder hier - na gut, fast jeder - weiß, wie viel Arbeit in so etwas steckt.

@Slin
Alles bereits bekannt, wenn du mal zufaellig in mein Tutorial geschaut hast.(Aum 101).
Auch das Problem der Transparenzen....
Bsp zaehlt doch nur fuer Blöcke oder?Ich benutze ausschliesslich Modelle und habe im Gegenzug eine Funktion zum ein und ausblenden auf Entfernung oder in bestimmten Situationen.

@Superku
Ja, das kann ich gerne machen.Ich denke nicht, für mein Level Design Kritik zu ernten.Im Gegenteil.
Zudem hast du vielleicht sogar eine Idee, wieso das Problem auftritt.
Ich editiere im Laufe des Abends.Bin gerade nur mit meinem Laptop online.

Die fände ich außerordentlich interessant.

Was wäre daran interessant für dich?
Das meiste steht alles grob in den AUM Heften(vec_dist und trace) und muss nur optimiert werden.

vec_dist für die Enfernung zum Objekt.Besser mit einem Scanaufruf bei vielen Objekten.Und für Objekte hinter irgendwelchen Gegenständen kannst du Flags benutzen(z.b. Haus->Flag 1) und mit einem Trigger arbeiten.Da gibt es eigendlich sehr vielfaelltige Möglichkeiten.

Oder meinst du etwas bestimmtes?

Daran wäre interessant für mich, ob die vielleicht für Deine Performance Probleme verantwortlich ist.

Nein, weil ich das Problem schon vor der Implementierung der Vegetation hatte und für alle anderen Objekte habe ich die Funktion nicht implementiert.Abgesehen natuerlich von den Funktionen für die Flares.Der Gedanke ist aber nicht schlecht.(Auch wenn es eigendlich nur eine einfache Trace Funktion zum Spieler ist).Ich werde später mal alle Funktionen, die eine While schleife beinhalten, ausblenden.Vor einigen Monaten habe ich das zwar schonmal gemacht aber im Laufe der Zeit kann sich natuerlich ein Fehler eingeschlichen haben.

Viel zu viel Arbeit. Überprüfe doch erst mal im Debugpanel was wie lange dauert. Da klingeln bei mir aber gerade sämtliche Alarmglocken.

Guck dir halt einfach das debug panel an, das sagt dir doch ob das problem in deinem code liegt... Du hast 15ms wenn du 60fps schaffen willst, wenn deine eigenen Funktionen nun schon 10ms brauchen, dann ist das vermutlich zu viel, wenn die aber unter 5ms liegt würde ich das Problem woanders suchen.

Treten diese Ruckler nur ein einziges mal auf (also wenn Du Dich z.B. mit der Kamera zum ersten mal in eine bestimmte Richtung drehst), und danach dann nicht mehr? Oder hast Du diese Ruckler jedesmal, wenn die Kamera in eine bestimmte Richtung blickt?

Hast Du schon versucht, die Texturgröße zu verringern (z.B. durch Verwendung von DDS-Texturen)? Möglicherweise hat Deine Grafikkarte zu wenig Speicher, um alle Texturen im Speicher halten zu können. Dann muss Speicher ausgelagert werden, und die Framerate sinkt in den Keller.

Ruckelt Dein Spiel nur, wenn Du nebenbei auch den WED, MED, SED laufen hast, oder auch wenn Dein gepublishtes Spiel ganz alleine läuft? Verwendest Du Windows Vista mit einer DirectX(Aero)-Oberfläche? Weil diese Dinge benötigen DirectX-Ressourcen(Texturenspeicher), die Deinem Spiel dann fehlen könnten. Beim WED macht es eventuell Sinn, die DirectX-Darstellung auszuschalten (VideoOutput auf Gxl2Bas32.dll stellen). Habe ich getan, um mehr Texturenspeicher für mein Spiel zur Verfügung zu haben, und auch die Aero-Oberfläche von Vista habe ich deaktiviert. Bei mir ist die Framerate auch geringer, wenn nebenbei der SED läuft (keine Ahnung, wieso das so ist, und es dürfte auch nicht auf allen PCs der Fall sein).

Fnc schwankt zwischen 0.2ms und 0.8ms und den Framerateneinbruch hab ich auf die schnelle jetzt nicht finden können.Es bleibt bei konstanten 75 fps, egal wohin ich schaue.Das Debugpanel vernachlaessige ich immer etwas hehe.In letzter Zeit habe ich derart viel optimiert, dass ich gar nicht mehr weis, ob das Frame Problem noch besteht.

@Harry Potter

- Windows 7
- Gepublished habe ich mein Spiel bisher nie(wozu auch;) , ich will quasi nie fertig werden.Vielleicht binde ich das Spiel irgendwann in mein Tutorial ein)
- DDS Texturen nutze ich selbstredend grundsaetzlich(selbst bei Panel und
Schriften, soweit das geht....aber das hat auch wieder verschiedene Gründe).
Das auswechseln der Texturen war die erste Optimierung, seit ich UT 04 im Auge hatte
- Maximal 1 Texture pro Model, maximal 1024 x 1024, ueberwiegend 512er Bereich
- ruckelt eigendlich willkuerlich, da muss ich morgen allerdings nochmal schauen
- probleme mit SED habe ich nicht.Bei dir liegt das sicher an Vista


Ich werde morgen 1 oder 2 Bilder posten und das Debug Panel mit inbegriffen.

Wenn du das aus Spaß an der Freude machst und auf keinerlei Ergebnis hinarbeitest, alles klar, viel Spaß, mach weiter so. Ansonsten: Optimieren ohne Debugpanel, ist mehr als sinnfrei. Du hast überhaupt keine Erfolgskontrolle und selbst wenn Du die hättest würdest Du völlig ins Blaue irgendwelche Änderungen machen.

Ins blaue wuerde ich es nicht nennen.
In meinem Fall geht es ums optimieren der Texturen z.b.(DDS,1 textur pro Model) oder um die Polygonmengen.Anwendung einiger Tricks(z.b. Texturen statt Partikel für Laser usw.).Ich glieder quasi in 2 Bereiche.Das programmieren kommt immer 2. STelle.


So, hier ein par Bilder meines Spiels und des Debugpanels.
Das Level ist momentan ohne Vegetation, daran arbeite ich erst seit kurzem.Funktioniert aber soweit und ist optimiert.Dann verfälsche ich aber das Ergebnis.
Ich schrieb auch nicht, das Debug panel nie zu nutzen, nur seltener als ueblich.
Unten stehendes ist alles slebstverstaendlich Eigenleistung.Bis auf die Steintextur.

EDIT:
Befasse mich jetzt mit der Suche des Framerateneinbruchs.

Debug Panel:


Level 2:




Menue:

Von den screenshots her sieht das ja eigentlich ganz ordentlich aus.

Aber was mich irritiert, ist dass deine ms-Zahl für Funktionen so hoch ist, obwohl ich im Level... naja, nix sehe ^^ ich hab hier gerade mal ne Demo gestartet, in der ~650 Entities existieren und ~200 Funktionen gleichzeitig laufen und ich verbrauche nur 1-2 ms pro frame.

Auch würde ich gerne wissen, wie du die Schatten generierst. Sind die dynamisch, statisch in einer Lightmap oder was machst du da?

Da seh ich mal als Kompliment, danke:D

Die ms zahl wird wohl durch das Gras kommen(was du nicht siehst, aber eine region hab ich vergessen zu entfernen).Ansonsten muesste ich erst prüfen.
Mit "nix sehen" meinst du sicher, dass alles statisch ist.Auf einem Bild leider normal:D

Die Schatten sind statisch und werden als 2.tes Texturset mit gerendert.Lightmap.
Auf dynamische Schatten verzichte ich komplett.Machen nur Probleme und sehen nicht gut aus.
(Edit: Bis auf den Player selbst natuerlich...und alles bewegliche)

EDIT:
Hier noch ein Beispiel mit Gras, das per Scan einen Klotz scannt und die Grasmodelle alle aus oder einblendet ohne 300 Funktionen fuer alle Grasmodelle laufen zu haben.Mit Möglichkeit zur Helligkeitseinstellung per Shadowmap, die unter dem terrain liegt(sonst waere das zu langsam).
Die Modelle selbst sind nicht optimiert und haben eine 512 x 512 DDS Texture.Hier besteht noch optimierungsbedarf.Zudem geht die ms /frame Zahl etwas zu hoch.



Aber da ich gerade

Bitte so war es auch gemeint! Was ich halt meinte, war, dass ich keine Figuren, Objekte und offensichtliche Effekte sehe. Wenn das alles nur sttaische Geometrie ist, dann sollte das eigentlich rennen wie sonstwas. Auch weil du z.B. auf Shader verzichtest.

Entferne mal das Gras und checke erneut. Hast du vielleicht kostenintensive Funktionen am Laufen, wie z.B. Pathfinding?

Du hast gesagt, dass du eine eigene Funktion zum Ein/Ausblenden von Sachen hast - eventuell kostet das viel - schalte das mal aus und nehm Standard-LOD und guck wie sich deine framerate verändert.

[EDIT] Wobei 83 fps ja eigentlich schön schnell ist, oder sehe ich das falsch?

[EDIT2] Bei allen statischen Modellen - hast du da sichergestellt dass da keine while-wait(1) Schleife drüberläuft und dass DYNAMIC aus ist?

Ok, also wenn ich auch noch die Funktionen für die Flares entferne, steht FNC bei 1-3 ms(Bruecke).Aussenbereiche liegen bei 3-5ms.

Mit Gras liegts bei 15ms.
Mit Flares liegts bei 4-8ms.
Ohne alles bei 1-2ms.

Natuerlich hat jedes statische Objekt das Dynamic Flag resettet.
(Ich hab dafuer ne extra Funktion, allerdings ginge das auch ohne Zuweisung automatisch, sofern das Objekt keine Action hat).

Scheinbar liegts wirklich an den traces(vom Spieler sind das jeweils maximal sichtbare 20 Traces.

83 Fps sind mir eigendlich zu wenig, wenn du bedenkst, im Level nur statische Sachen zu sehen.Im fenstermodus bei 800 x 600 habe ich knappe 200 Fps.Die schwanken aber gewaltig zwischen 120 und 130 in einigen Bereichen(wieder mit Gras und Flares).
Naja, da ich jetzt einige Wochen an meinem menue gearbeitet habe(sieht man ja:D) , musste ich das Level erstmal beiseite schieben.
Das Gras ist recht neu implementiert worden und die Flares besitzen "noch" eine einfache vec_dist trace Funktion mit check, ob ein Objekt getroffen wurde.

Nun habe ich wenigstens einen Anhaltspunkt im Fenstermodus.

Je nachdem wie lange die Tracestrahlen sind und welche Flags gesetzt wurden, können 20 Traces ganz schön was ausmachen.

Eventuell kannst Du die ganzen Traces (auch die für die Flares) über mehrere Frames verteilen, so dass in jedem Frame maximal fünf Traces stattfinden?

Ich verwende eigendlich immer wait(5), das reicht vollkommen aus.
Ansonsten auch soweit es geht wait(random(5)) vor der while und wait(5) in der Funktion, sodass die Last aufgeteilt wird.

Aber ich merk selber, dass da der Fehler liegt.Gleiches Prinzip beim Gras.
Ich habe uebrigens am freitag meine Prüfung zum Fachinformatiker in Anwendungsentwicklung bestanden und bin daher etwas beschäftigt mit Bewerbungen schreiben:)

Sowas wie wait(2) oder wait(5) mag konzeptionell vertretbar sein, aber sowas wie wait(random(5)) würde ich einfach mal lassen

Für flare-Sprites empfiehlt sich CLIPPED auszuwerten. Wenn das flag -aus- ist, dann wurde es im letzten frame nicht weggeclippedt, ist also potentiell sichtbar. Dann würde ich statt einer Aktion für alle flares mit einer Schleife pro frame über alle flare-Entities iterieren und abwechselnd alle sichtbaren tracen, sodass nur 1 trace pro Frame verbrauchst. Das heißt, wenn 20 flares potentiell sichtbar sind, hast du erst nach 20 frames alle flares gecheckedt. Wenn du dann die flares nicht aufpoppen lässt sondern sanft ein und ausfadest, "siehst" du das gar nicht, dass du in jedem frame jeden flare checkst. Und wenn du feststellst, dass ein flare angeschaltet ist, aber CLIPPED = true ist, dann kannst du den flare erstmal abschalten, weil der sowieso weggeclippedt wurde und potentiell NICHT sichtbar ist.

Das umzusetzen erfordert ein wenig Arbeit aber statt 10-20 traces pro frame für irgendwelche flares nur einen auszugeben ist doch lukrativ.

Ach du glaubst nicht, wie lange ich da ueberlegt habe, wie ich diesen Code am besten optimieren kann.wait(random..) war nur zum probieren von George, aber das Problem bleibt.Und danke für den Tip.Das werde ich mal in Erwaegung ziehen.

Wo wir gerade dabei sind: Ich benutze ja für das Gras einen Scanaufruf alle 20 Frames.Funktioniert(e) eigendlich auch ohne Fps einbruch ganz gut.Jetzt hab ich aber vorhin festgestellt, dass die Funktionsanzahl auf 2000 stieg.(I-wie steckt ein Fehler)...wie dem auch sei, gibt es ein Konzept für viele Modelle?

EDIT: Wie gesagt, ich mache das aus Spass mit dem Ziel, eines Tages die selbe Performance wie in UT zu erreichen und letztenendes etwas vorzeigbares und spielbares zu haben.Da ist jede noch so kleine Optimierung willkommen:)

Mach aus allen Grasmodellen ein einziges dass immer sichtbar ist, das sind dann zwar vielleicht 10k Polygone, aber ist vermutlich trotzdem schneller als jedes LOD System.

Dieses Prinzip habe ich bereits umgesetzt und es funktioniert nicht so, wie ich es mir vorstelle.Damals hab ich noch alle Grasmodelle auf den schrägen per Hand gesetzt(das ist eben mein Typ:D...).Irgendwann habe ich es aufgeben, da das erzeugen der Grasmodelle flexibler ist.
Der einzige Vorteile liegt in dem, was du geschrieben hast.Da ich das Grundkonzept und schon gar nicht das Terrain nochmals umforme, ist die Lösung eigendlich ganz gut.....ich werds mir ueberlegen.

EDIT: Jetzt hab ich doch glatt das Prinzip hinter meinem neuen Konzept vergessen.Die Grasmodelle werden nur einmal erzeugt und werden dann auf Entfernung nur ausgeblendet(unsichtbar gemacht).Per Scan werden alle Modelle durchgeschalten.Darum bin ich auch vom oben genannten weg, um ein wenig Flexibilitaet zu wahren.

Ayumi, ohne dir zu nahe treten zu wollen, aber so wie ich das sehe hast du zwei Probleme
1) Du optimierst Dinge von denen du **glaubst** das sie das Problem sind
2) Du machst dir Dinge unnötig kompliziert indem du versuchst schlauer zu sein als das Problem

Zum ersten; Bitte, bitte, bitte niemals versuchen die performance zu steigern wenn du nicht weißt was genau die Performance killt! Performance optimierung läuft in dem du per profiler guckst was wieviel Zeit kostet, wo du am meisten Zeit verschwendest und dann kümmerst du dich darum. Nimm die low hanging fruits. Manchmal ist es recht einfach zu raten wo das Problem liegt, aber in der Regel ist das sehr sehr schwer einzuschätzen und du machst dir nur mehr Arbeit wenn du phantom Probleme löst.

Zum zweiten; Warum braucht dein Gras actions? wait() ist eine wunderschöne Funktion, aber sie kommt zu einem sehr heftigen Preis. Tausende von actions die per wait() "gleichzeitig" laufen, kosten eine unglaubliche Menge an Zeit. Nicht nur weil Funktionsaufrufe generell teuer sind (einer der Gründe warum tail-call optimization in fast jeder Sprache implementiert sind), sondern weil wait() auch noch sehr viel Magie im Hintergrund wirken muss um den Stack wiederherzustellen. Das Gras auf invisible zu schalten halte ich auch für eher unwirksam, die Engine culled automatisch so gut wie alles nicht sichtbare weg und wird es nicht rendern, die paar Grasbüschel die da durchfallen sind es nicht wert das jedes gras pro Frame etwas tut! Und wenn das doch das Problem ist, dann mach das in einer Funktion die pro Frame durch das gras durch geht und guckt wie ob es sichtbar ist oder nicht (wobei das auch immer noch langsam ist, vec_dist() ist zwar nicht unbedingt eine langsame Operation, aber nichts was du ein paar hundert tausendmal pro Frame machen willst. Viel besser wäre hier wohl ein spatial hash, aber, und das ist der springende punkt; Bevor du irgendwas machst, guck ob es das Gras überhaupt das Problem ist, danach und wirklich erst danach, kannst du dir tolle optimierungen überlegen).

Edit:

Noch zwei weitere Punkte
1) Bitte behalte im Hinterkopf das Spiele Schall und Rauch sind. Viele unglaublich tolle Effekte sind eine ungeheure schusterei und trickserei, die alle möglichen Dinge ausnutzt um den Effekt performant zu ermöglichen. Quasi jedes Post Mortem zu Spielen ist eine Sammlung von anekdoten von schmutzigen Tricks die gemacht wurden um wunderschöne Effekte zu zaubern, und wenn du probierst das straightforward selber zu implementieren, fällst du in der Regel auf die Nase. Das heißt nicht das die Engine schlechter ist, sondern einfach nur das jemand mit sehr viel Ahnung und viel Zeit sich hingesetzt hat und das einmal ausgetüftelt hat um es so hinzukriegen wie es ist.
2) Kleine optimierungen sind schön, aber nur wenn sie VIEL bringen. Wenn du performance steigern willst, fang mit dem an was am meisten performance kostet. Danach kannst du immer noch die anderen Dinge angucken und optimieren, aber bitte fange mit den Dingen an die am meisten Zeit benutzen.

Und noch etwas was HeelX schon leicht angedeutet hatte; random() ist böse. Ein Zufallszahlengenerator sorgt nicht automatisch für eine normal Verteilung, und so etwas wie wait(random(5)) mag zwar wie eine gute Idee klingen, ist aber non-deterministisch und geht garantiert in die Hose. Zufallszahlen sind noch einmal so eine Sache für sich, und vor allem sind sie eines; Nur pseudozufällig.

Sorry, Ayumi, aber da musst Du jetzt durch:
Die Engine ist deswegen langsam, weil Du die Finger dran hattest und "optimiert" hast. Bestes Beispiel:

http://img4.fotos-hochladen.net/uploads/graspwlx0v73jy.jpg

Da hast Du 30 FPS. Und warum? Weil Du 26.3 ms für die "Optimierung" verschleuderst. Ohne diese "Optimierung" hättest Du die doppelte Framerate, nämlich 60 FPS, wie leicht nachzurechnen ist. Andere haben das schon gesagt, aber es ist so wichtig, dass ich es hier gerne nochmal wiederhole:

Optimierung ohne Erfolgskontrolle ist großer Murks.

Ich kann mich meinen Vorrednern nur anschließen, aber auch von mir noch ein paar Tipps: In meinem Sidescroller habe ich teils hunderte Plattformen (manche (sich drehende) mit komplexen Berechnungen) und sich bewegende oder zerstörbare Entities in einem Level, dazu tausende statische. Die Auslastung der Engine im Funktionsbereich beträgt jedoch nur im Schnitt 0.6-0.7ms samt aller Spieler-Movement und sonstigen Routinen, obwohl ich auch einige wait-Schleifen benutze und diverse Sachen sichtbarkeitsabhängig schalten muss. Alles über ca. fnc 1ms in einem statischen Level ohne Gameplay und sonstigem aktiv ist meiner Meinung nach absolut inakzeptabel, du solltest keine Sekunde an irgendeinem anderen Aspekt weiterarbeiten bis du das in den Griff bekommst.

c_traces für Sichtbarkeitschecks sind (geschwindigkeitstechnisch) absoluter Unsinn, die kannst du getrost alle entfernen. Wenn du in einem Level Tunnel/ gekrümmte Schluchten/ Räume oder sonstiges hast, kannst du mit einfachen würfelförmigen Regionen arbeiten (gibt es zwar nativ erst in A8, aber auch leicht selbst zu implementieren), so dass bspw. Region 1 und 3 ausgeschaltet werden, wenn du dich in Region 4 befindest (bspw. über eine for-Loop über alle dafür registrierten Entities, welche einen Regionsskill auf 1 oder 3 gesetzt haben).

Den Rest sollte dann auch der ABT oder BSP Tree erledigen. Den automatisch BSP Sichtbarkeitscheck (PVS?) kannst du theoretisch trotzdem noch benutzen, indem du große statische Modelle sehr grob mit Blöcken nachmodellierst (du musst einmal prüfen, ob die Sichtbarkeitschecks auch mit "None"-Blöcken, also unsichtbaren, funktionieren, weil das dann deutlich einfacher würde).

Das Rendern von Gras ist eine nicht ganz triviale Angelegenheit, da bei jeder Polygonüberlagerung auf dem gerenderten Bild normalerweise zwischen je zwei Pixeln drei Konvexkombinationen (der Farbwerte) berechnet werden müssen, um die Transparenz zu realisieren. Wenn nun viel Gras/ Vegetation sichtbar ist, oder nur scheinbar viel, wenn es sich im Grunde überlagert, wäre es so als rendertest du fast in einer doppelt so großen Auflösung. Um das zu umgehen, gibt es normalerweise 2 Ansätze: Entweder, du renderst alles mit einem alphaTest-Material, welches dann zwar nur 0% und 100% Transparenz kennt (dafür sehr schnell), oder aber du renderst die Vegetation in einem separaten View bzw. 2mal, einmal als "maximum" Alphamaske und einmal die Farbwerte normal, aber deckend/ nicht transparent. Dann legst du letzteres mittels der Alphamaske über den View und brauchst nur einmal zu blenden (und hast trotzdem eine recht schicke Transparenz). In dem/ den Vegetationsviews könntest du dann auch die Modelle mittels der Shader sanft nach ein paar hundert/ tausend quants ausblenden und den clip_far Wert auf einen niedrigen, etwas größeren Wert setzen. Dann brauchst du dich überhaupt nicht mehr um das Gras zu kümmern, sprich 0 Sichtbarkeits- oder Distanzchecks wären notwendig.

Ich optimiere nicht nur ...meistens versuche ich ehr das Level entsprechend zu gestalten.Zu den Optimierungen zaehlen z.b,. nur die Vegetation und die Texturen und anderweitiges, das dazu beitraegt.Ich jage keinem Phantom nach.Weit gegriffen ist theoretisch alles eine Optimierung, was mit Gestaltung und Verbesserung zu tun hat.

Sicher mache ich auch Fehler.C# ist nicht das gleiche wie lite c.Das Gras Problem hab ich schon lange und ist , wie bereits geschrieben, recht frisch.Frueher benutzte ich nur die Funktion von George mit einer Farbkarte.
Da mir das Prinzip aber zu aufwendig ist(auch wenn es nach Wochen funktionierte), suchte ich eine Alternative.

@JustSid
Wie kommst du darauf?Ich habe wie gesagt 1 Funktion, die einen Scan aufruf startet, sobald der Spieler nahe kommt.Die Graeser werden zum ersten mal in spezifischer x,y Richtung generiert und werden danach, je nach vec-dist zum Spieler wieder ausgeblendet aber nicht mehr neu erzeugt.Der Scan wird alle 20 Frames einmal ausgeführt.Ist der Spieler in der Nähe, werden alle Modelle nacheinander wieder sichtbar gemacht.(Per Event).Das Prinzip ist an sich top, aber den Fehler im Script suche ich später.Es hatte eigendlich mal funktioniert.(Bevor ich mit meinem Menue anfing)

Um am Level weiter zu arbeiten schalte ich einfach die "blobs" mit den Grasfunktion ab.Schon laeuft alles wie es soll:)

Zum anderen Abschnitt: Darum sind mir auch fast alle Tricks von UT 04 bekannt.Fängt bei den Texturen an und geht hin übers Level Design und Darstellungen sowie spezielle Effekte.Wenn du dir etwas Zeit für ein bestimmtes Level nimmst, fallen 1000 Dinge auf, die vor Allem du als Designer oder Programmier schnell selbst umsetzen willst.Aber ich merke gerade, dass du dir nicht alle vorherigen Posts durchgelesen hast.Mir ist eine Menge bekannt, was die Trickserei angeht.Ich bin nur leider noch nicht so gut in lite c und ehr ein Designer.Allerdings verbessert sich ja jeder ständig.Das bisgerige, bis auf ein par Ausnahmen, steht in der Aum 101.

Das Prinzip von George(AUM) mit der wait funktioniert in seinem Script bei der Erstellung der Graeser an sich ganz gut.Aber ich werds lassen.


@Uhrwerk
Siehe Gras...ich hab das Grasproblem erst seit einigen Wochen, bevor ich mit dem Menue anfing.Das Level besteht schon ~2 Jahre, in etwas abgewandelt.Aber bestimmte Details füge ich erst nach und nach hinzu.Und daran werkel ich dann solange, bis das Problem aus der Welt ist.Was ist daran "Verschleuderung"?(Du beziehst das sicher aufs Gras aber es klingt so sehr allgemein)

Und natuerlich ziehe ich jetzt beim Programmieren öfter das Debugpanel vor.
Danke für die Ratschläge, die ich demnächst auch umsetze.



@Superku
Auch an dich danke fuer die Ratschläge.Ich werde das ein oder andere ausprobieren , um mein Grasproblem zu lösen.Noch lebe ich eine Weile.


@ Alle anderen
Alles in allem bleibt es beim Problem des Grases und der Traces um es nicht noch weiter auszuweiten.Die Kritik habe ich gerne aufgenommen und dabei möchte ich es jetzt belassen.Sobald ich alle Probleme gelöst habe, werde ich mich mit einem Screen zurueck melden.

Btw. eines noch:


Bezieht sich deine erste Frameangabe auch auf den Fenster- oder den Vollbild-Modus? Ist dir bewusst, dass die Framerate durch deine Monitorfrequenz im Vollbildmodus begrenzt ist?

@Superku
Ja ist mir bewusst.Die Fps im Vollbildmodus werden je nach Monitorfrequenz begrenzt.
Die 83 Frames habe ich im Vollbildmodus.Damit stehe ich aber nicht alleine...wieso das keine 60 Fps sind, weis ich nicht und ist mir auch relativ.(Vorlaeufig).Überwiegend sind es 60 Fps in der Zeit meiner Entwicklung gewesen.

EDIT: Sollte eigendlich auch in einem der Screens zu sehen sein

Hier zu sehen:


@Alle
Ich weis jetzt woher die 2000 Funktionen und die 30 Fps kommen.In dem Moment wurden die Graeser erzeugt und das erste Mal geladen.Naja ich prüf das später nochmal.
Also bleiben nur die Traces übrig, aus denen ich eine Überprüfung fuer alle Flares machen muss.Bei den Graesern muss ich nur etwas bei der Erstellung umstellen.

Was sollte in dem Screenshot zu sehen sein?
Übrigens, in meinem Spiel begrenze ich fps_max auf die Monitorfrequenz, wenn ich mich im Vollbildmodus befinde, da es sonst teilweise unruhig laufen kann, ich habe dann auch 60-63fps (ich denke, das begründet sich auf begrenzte Genauigkeit der künstlichen Verzögerung, wenn ein Frame ansonsten sehr schnell gerendert wird, aber ich weiß es nicht).

In dem Screen ist die aktuelle Fps Zahl zu sehen, wie oben erwaehnt.
Mit fps_max begrenze ich meine Frames auch grundsaetzlich auf 60 fps.Um aber einigen Ungereimtheiten auf den grund zu gehen, kommentiere ich diese Zeile gerne aus.

Ok, Problem gelöst.



Mit meiner Methode kam ich schon auf 4-5ms fnc.
Mein geschätzter kollege Jane hat dann aber letztendlich das Schlusslicht gesetzt, indem einfach aus den Event Funktionen rausgesprungen wird.
Somit erreichen wir 0.4 ms.
Die Gräser werden trotz dessen einzeln sichtbar gemacht und nicht wie vorher alle auf einmal pro Klotz.Dies diente eigendlich auch nur dem Optimieren.

Es sind noch 2-3 Fehler offen.Z.b. hakt der Spieler, wenn er einfach ganz kurz stehen bleibt und sofort wieder los rennt.
Zudem steigt die fnc Anzahl von 15 auf 50, wenn bestimmte Bereiche der Map erreicht werden.

Die Fps liegt nun bei knappen 180 im Aussenbereich und 210 im Innenbreich bei der Brücke (fenstermodus)



Ein Problem bestand noch: Warum habe ich 75 Fps im Vollbildmodus?
Dieses Bild verät es :-)




Ich bedanke mich vor allem bei fogman für seinen Hinweis und natuerlich bei allen anderen, die dazu beigetragen haben., diese Probleme zu loesen.


EDIT: Nun sind es durchgehend 17 Funktionen und es hakt auch nichts mehr.:D