Jump to content
Unity Insider Forum

Performance durch eigenen Skriptmanger gewinnen


Marganeus

Recommended Posts

Hallo zusammen,

 

ich arbeite an einem MMO, wobei die Performance natürlich einer der kritischsten Punkte überhaupt ist.

Da ich gelesen habe, das vor allem GUI Elemente relativ viel Performance fressen können (vor allem wenn jedes Frame abgefragt wird, ob das Element nun angezeigt werden soll oder nicht), habe ich überlegt, ob nicht ein Skriptmanager sinnvoll wäre.

 

Wir arbeiten in einer MVC ähnlichen Struktur, wobei eben jedes Fenster ein eigenes Skript ist.

Da es natürlich viele Fenster geben wird, wollen wir nicht alle Skripts permanent durchlaufen lassen und abfragen, ob es gezeigt werden soll oder nicht.

Es ist nun die Idee, dass wir einen Manager schreiben, welcher die Skripts einem leeren Objekt hinzufügt, und sobald man das Fenster wieder schließt, das Skript wieder vom Objekt gelöscht wird.

 

Dieses System wollen wir auch auf diverse andere Objekte, welche eine Interaktion haben, anwenden. Da die Informationen von dynamischen Objekten vom Server kommen, würden die Skripts durch den Manager vom Server gesteuert werden.

 

Wir glauben, dass wir dadurch einen Performance Gewinn erzeugen, da nur wirklich benötigte Skripts (was ja für jedes Objekt anders sein kann, auch wenn es das selbe Prefeb ist) vorhanden sind und somit nicht immer alles mögliche abgefragt werden muss, ob es nun ausgeführt werden soll oder nicht.

 

Glaubt ihr, dass diese Lösung eine gute ist, oder habt ihr evtl. noch andere Ideen?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich kann mir nicht vorstellen, dass dir das etwas bringt.

Mein Vorschlag: Nimm etwas Geld in die Hand und hol dir EZ-GUI oder NGUI. Diese Guis arbeiten mit Texturatlanten und einem Manager und brauchen nur ganz wenige Drawcalls. (Mehrere Buttons und Fenster unter 10 DC)

 

Das was du da vor hast, wo jedes Fenster ein eigenes Script hat, bedeutet, dass jedes Script eine OnGUI Funktion mit bei hat.

Diese Funktion ist der Übeltäter und davon sollte man wirklich so wenig wie möglich haben. Selbst leere OnGUI Funktionen brauchen schon performance.

Das Ein- und Ausschalten von Scripts, wenn sie nicht benötigt werden, verändert zwar die Performance, dafÜr musst du da aber immer ran. Ja und wenn mehrere Fenster offen sind? Buttons dabei? Dann gehts in den Keller. ;)

Eine Abfrage ob ein Fenster auf (bzw. im Sichtfeld) sein soll kostet sogut wie nix. Die GUI Funktion kostet.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Kann ich noch nicht genau sagen.

EZ GUI kenne ich jetzt schon 2 Jahre. Bei NGUI arbeite ich mich gerade ein.

 

NGUI scheint das Rennen zu machen. :)

 

Beide sind ähnlich, beide Arbeiten quasi mit einer 2ten Camera die nur den GUI Laver darstellt. Da bei beiden die GUI Objekte echte Körper sind, lassen sie sich super anordnen und man weiß, wo sie sind und sein werden. Man kann bei beiden auch Spielobjekte zu GUI Elementen machen also Buttons und Anzeigetafeln in der Szene. Touches oder drag/drop sind schon eingebaut.

NGUI scheint aber flexibler zu sein, wel ich über vorgefertigte GUIScripte die Eigenschaften der Elemente besser an meine Bedürfnisse anpassen kann und außerdem brint es auch den Font in den Texturatlas rein und hat die Möglichkeit Fonts aufzuhübschen, was EZGUI nicht hat. Da muss der Font schon hübsch rein kommen. Die Fonts sind bei beiden übrigens Bitmaps keine TTF's mehr.

 

Ja, NGUI ist bis jetzt besser.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Vielen Dank nochmal für den Tipp mit NGUI.

Ich bin fasziniert, dass es so einfach geht, aber gleichzeitig super dynamisch ist.

 

Ich habe jedoch leider ein Problem, was ich mir absolut nicht erklären kann.

Ich habe in einer Szene 3 GUI Elemente.

- Login Fenster

- Charakterliste

- Error Message

 

Je nachdem welche Rückmeldung ich vom PhotonServer bekomme, blende ich das jeweilige Fenster ein/aus.

So zumindest die Theorie...

Wie man am Bild sehen kann, sind die Elemente in der Szene und im NGUI deaktiviert, werden jedoch weiterhin im Hintergrund dargestellt.

Die Charakterliste sogar noch ein 2. mal etwas größer.

Wir hatte versucht die Charakterliste mit einer 3D Kamera zu erstellen, wobei hier die Buttons nicht funktioniert haben (das werden wir uns noch genauer anschauen).

 

Ich kann mir aber nicht vorstellen, dass es damit zu tun hat (wir haben die 3D Kamera wieder gelöscht).

 

Die Frage zusammengefasst: Warum werden andere Kameras angezeigt, obwohl sie inaktiv sind?

post-1781-0-39028600-1361635186_thumb.png

Link zu diesem Kommentar
Auf anderen Seiten teilen

Warum werden andere Kameras angezeigt, obwohl sie inaktiv sind?

 

nach deinem Screen sind alle deine Kameras auf dem Default Layer . Wenn eine Kamera deaktiviert ist kann ja die aktive Kamera denoch anzeigen was auf dem Default Layer ist, Da die GUI auch Object ist und nicht verschwindet nur weil eine Kamera deaktiviert ist , musst du dafür also einen seperaten Layer erstellen um so deinen Kameras dann anzweisen was für ein Layer sie rendern sollen und welchen nicht (Culling Mask ).

Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke für die Rückmeldung.

Ich werde es mal ausprobieren, klingt auf jeden Fall logisch. :)

 

Aber warum wir dann nicht von Anfang an alles gezeigt?

Ich habe in Unity selbst alles Aktiv und sage beim Starten, dass er die Fenster ErrorMessage und Characterlist deaktivieren soll. Das passiert und sie werden nicht angezeigt.

Logge ich mich nun mit falschen Daten ein, wird die ErrorMessage eingeblendet (wobei diese über dem Login liegt). Wenn ich dort dann den Button klicke, wird die ErrorMessage wieder ausgeblendet.

Das funktioniert im Prinzip genauso wie die Characterliste.

Ich aktiviere und deaktiviere das Gesamte NGUI Objekt. Nur bei der Characterlist zeigt er alles an.

Ich finde es ein wenig unlogisch, aber wenn es mit den Layern Funktioniert, dann soll es mir recht sein. :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hat super funktioniert.

Wir haben jetzt einen Layer für das gesamte GUI (also quasi für dinge die eh immer angezeigt werden) und einen für PopUps, z.B. Fenster/Fehlermeldungen, etc..

 

Noch ein kleiner Tipp von mir, achtet auf die Z Achse in NGUI, das hat uns einige Zeit gekostet, bis die Buttons funktioniert haben...

Die Z Achse sollte möglichst bei -1 stehen. :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...