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.