Hilfe beim Overlay der alten(!) GUI

[Kokujou]

Hallo...

Ich bin wohl mit der Einzige der noch die Unityengine.GUI Komponente benutzt, mein Projekt ist auch zu groß um es noch zu ändern und ich finde diese Variante irgendwie komfortabler....

Das Problem: Ob mit SortingLayers oder Renderqueue oder Z-Achse, ich kriegs nicht hin dass meine Partikelanimation ÜBER der UI liegt. Geht das etwa nur bei dem Canvas-Zeug? Oder gibt's da nen Trick?

Das Problem ist halbwegs minimal aber es wäre doch recht ärgerlich wenn ich diesen Anzeigebug lassen müsste.

[malzbie]

Die alte GUI ist  immer die vorderste Renderebene. Da hast du keine Möglicheit sie hinter z.B. die Partikel zu schieben. Vielleicht gibt's irgend einen Lifehack mit 2 Cameras und einer Rederntexture.

Ich weiß nicht genau wann die alte GUI nicht mehr da sein wird, aber es gibt schon Warnmeldungen die darauf hinweisen, dass die GUI obsolet ist und irgendwann nicht mehr da sein wird.
Wenn du also Unity immer fein updatest, wirst du ohnehin irgendwann auf die neue UI oder irgendeine andere UI schwenken müssen.
Klar, manche Dinge sind mit der alten GUI schneller erledigt und vielleicht komfortabler, aber das ganze System ist auch viel starrer und codelastiger. Also ich an deiner Stelle würde schwenken.

[Kokujou]

Naja meine ganze GUI ist dynamisch generiert das ist n Haufen code zumindest für meine Verhältnisse... Ich weiß nicht ob die neue GUI da genauso flexibel ist was das dynamische Erstellen von Elementen eingeht... Ich hab sogar extra ne Art Wrapperklasse geschrieben... Ärgerlich.

[Kokujou]

Also jetzt mal ehrlich gibt's nicht irgendeine GUI die Scriptfreundlicher ist? Hier brauch ich ja 20 Zeilen nur um endlich mal ne halbtransparente Box darzustellen und man braucht erstmal 5 komponenten um die Buttons zum laufen zu bringen... das ist doch nicht mehr feierlich... Und das ist nichtmal übertrieben:
EventSystem, GraphicsRaycaster, StandaloneInputModule, Canvas dann noch den Button selbst, die Texte...

Was haben die sich bitte dabei gedacht so einen Schund zu entwickeln?

[Kokujou]

Okay falls hier noch jemand mitliest, was ich nicht glaube, ich hab nach langem recherchieren und mit dem richtigen Suchbegriff (IMGUI) die Lösung gefunden!

Man erstellt einfach eine 2. Camera, wie malzbie schon angedeutet hat, die nur die entsprechenden Layer rendert. Dann braucht man nur noch folgende Zeile am Ende der OnGUI() Funktion aufzurufen:

Camera.Render();

Damit wird alles was die Camera anzeigt über der GUI gerendert! So einfach ich wünschte das würde irgendwo fett gedruckt stehen

Die Lösung stammt aus diesem Forum: https://answers.unity.com/questions/1123428/46-ui-sort-order-in-fornt-of-imguiongui-possible.html

PS: Mit Camera.Render(); ist natürlich nicht die Klasse sondern die entsprechende Instanz gemeint

[malzbie]

Erklär doch mal, was du da machen willst.
Willst du alles per Script erstellen oder warum brauchst du 20 Zeilen Code für ne tranzparente Box?

Denk daran, dass UI Elemente auch einfach nur GO's sind. Du erzeugst doch deine GO's auch nicht per script, oder doch?

[Kokujou]

Also zuerst mal braucht man, wenn mans per Script machen will wohl für so ziemlich jedes höhere Objekt ein Prefab, ziemlich nervig. Denn ansonsten kriegst du ja die eingebauten Texturen nirgends her wie z.B. von dem Panel der Hintergrund. Dann muss man erstmal ein neues GO erstellen, den Parent setzen, die Position erstmal völlig neu kalkulieren, weil das ja natürlich ein riesiger Unterschied ist und ich mich jetzt mit den Variablen Anchor, Pivot, localposition, anchoredposition etc... rumschlagen musste und das Theater um dann noch genauso einen Button zu erstellen damit fang ich gar nicht erst an.

In meinem Projekt geschieht vieles dynamisch, der gesamte GUI-Inhalt ja sogar die Elemente der GUI variieren nach den Eingaben, das gilt auch für die darin abgebildeten Bilder, da kommt man mit der IMGUI einfach deutlich besser. Vielleicht ist die hier ja ein bischen flexibler was Skalierung und dergleichen angeht, aber wir haben doch alle keine Angst vor Mathe

Und es steht auch nirgends obsolet dran, also hoffe ich mal dass die noch lange so sein wird. Ich hatte mir zwar wirklich vorgenommen auf die neue UI umzusteigen aber die ist einfach nur zum Skripten entwickelt worden. Was man da machen muss erinnert ja auch schon mehr an lifehacks XD

Also ich kann nur jedem raten fürs dynamische Scripten die IMGUI zu benutzen und die Canvas UI, wenn man sie in der Szene bauen kann... und keine Angst vor gefühlten 20 Subkomponenten hat, nur weil man nen Button möchte... ^^

[Sascha]

vor 46 Minuten schrieb Kokujou:

Und es steht auch nirgends obsolet dran

IMGUI ist nicht als obsolet markiert, weil es für Editor-GUI benutzt wird. Für ingame-UI ist es offiziell nicht mehr gedacht.

Das ändert natürlich nichts daran, dass sie noch benutzt wird und es sie tatsächlich wohl noch lange geben wird

vor 47 Minuten schrieb Kokujou:

Ich hatte mir zwar wirklich vorgenommen auf die neue UI umzusteigen aber die ist einfach nur zum Skripten entwickelt worden.

Meinst du "einfach nicht"?

Klar ist das neue UI-System anders, aber sie ist absolut programmierbar. Man muss sich erst einiges anschauen, aber dann geht das irgendwann wunderbar. Wichtiger Punkt ist, dass das neue System funktioniert wie der Rest von Unity: Mit Komponenten, die sich gegenseitig benutzen. Wenn du eine Automatisch befüllte Liste haben willst, dann baust du ein Script das die Listenelemente instanziiert, aber das Layouting übernimmt dann eine LayoutGroup-Komponente, die Unity schon fertig hat. Es ist ein (häufiger) Fehler, beim Umstieg von IMGUI auf das neue System bei dem Mindset zu bleiben, dass man das ganze Layouting selber schreiben muss, und das am besten alles in einer Komponente.

vor 52 Minuten schrieb Kokujou:

Also ich kann nur jedem raten fürs dynamische Scripten die IMGUI zu benutzen und die Canvas UI, wenn man sie in der Szene bauen kann...

Da spricht halt leider die Angst vor dem neuen System, weil du es dir noch nicht genügend angeschaut hast

[malzbie]

Ich bin mal gespannt, wie lage die alte GUI noch lebt.
Bei dem GUI Layer, der zwar nur für GUI Text Und GUI Texturen zuständig ist, Steht es seit der Version 2017 schon dran:

[Sascha]

Na, das System ist ja auch offziell veraltet, IMGUI eben nicht.

[Kokujou]

Ja das ist richtig, das ist die Angst vorm neuen System... Aber trotzdem finde ich die ist nicht zum Skripten. Sollte es da keine Shortcuts geben die mir verborgen blieben bleibt das Ergebnis doch dasselbe.

Für einen einfachen Button musst du erstmal dem Parent 5 verschiedene Komponenten hinzufügen, dann dem Button noch einen untergeordneten Text hinzufügen, weil der ja nichtmal ein Button ist sondern nur ein Bild mit Klickevents, dass die Farbe wechselt, wobei ich die IMGUI Komponente da sogar deutlich besser animiert finde, schließlich machen Klickeffekte nicht einfache Farbwechsel sondern auch Schattierungen und Lichtspielereien aus die in der IMGUI wenigstens ein bischen simuliert worden. Und dann klatscht man da noch nen Text drüber, nochmal als separates GameObject, und das soll jetz effizienter sein?

Klar alles ist programmierbar die Frage ist ob es sinnvoll ist. Man könnte bestimmt das gleiche mit der IMGUI erreichen und mit dem kleinen Lifehack den ichg efunden habe auch in der entsprechenden Ordnung. Obwohl ich zugeben muss bei der neuen gibt es den Vorteil, dass man sie eben nicht nur als Screen Overlay sondern auch als Element der Spielwelt einbauen kann wie z.B. solche Ingame Fernseher wie man es im Tutorial sieht. Das geht mit der neuen GUI natürlich sehr umständlich, wenn überhaupt.

Aber bei Screen Overlays schlägt die IMGUI die neue Canvas GUI bei weitem. Und bei meinem SPiel ist es nunmal nur das. Ansonsten würde  ich mir ja auch nur das Layout vorher bauen und den Inhalt irgendwie neuladen oder verschiedene Presets von Layouts machen zwischen denen ich hin und herschalte.

Dennoch solange mir da nichts entgangen ist, ist die IMGUI was das Scripten beim Screen Overlay angeht besser, es sei denn mir entgehen da irgendwelche Vorteile die ich noch nicht entdeckt habe.

Auf jeden Fall bin ich froh dass ich rausgefunden hab, dass man Cameras auch manuell am Ende der OnGui Funktion rendern kann und somit das Problem des Overlay gelöst ist Auch wenns etwas umständlich ist.

[Sascha]

Du baust halt ein Prefab für deinen Button, klatscht da ein Script drauf das den Inhalt des Buttons unter Kontrolle hat und arbeitest von außen nur mit diesem Script. Die Animationen der neuen Buttons sind selbstverständlich komplett einstellbar, du musst dir die Komponente nur einmal ansehen.

Dass das neue System effizienter ist hat ja auch niemand behauptet. Es gibt Benutzern halt die Möglichkeit, beliebig viel der UI-Arbeit ohne Code zu erledigen, da UI-Design eben nicht Programmier-Arbeit, sondern Design-Arbeit ist. Der Punkt ist, dass es auch nicht schlechter ist als IMGUI. Man muss halt lernen, damit umzugehen, aber das musste man bei IMGUI auch.

Was die Komplexität angeht, weiß ich auch nicht mal wie weit du in IMGUI drin bist. Hast du schonmal richtig dynamische UIs damit gemacht? So die Art von UIs, wo du plötzlich Event Phase-Fehler kriegst, wenn du nicht außpasst, deine Änderungen an der UI auf die Layouting-Phase zu verschieben? Da darf man dann erstmal Events queuen, damit das blöde Ding nicht öfter vom Stack popt als draufgepusht wurde...

[Kokujou]

Aber genau das ist ja mein Punkt ^^ ich bin halt ein Programmierer und kein Designer, also erledige ich viel über Skript, weswegen IMGUI besser geeignet ist für mich.

Öhm... den letzten Teil musst du mir mal erklären... Events? Wie dynamisch muss man denn coden dass solche Fehler auftreten? Ich generiere meine gesamte UI über den Code und passe auch die Inhalte Texte und Bilder dynamisch an je nach den Geschehnissen im Spiel, allerdings ist es nur ein recht simples 2D-Spiel, da ich das allein mache und wie gesagt leider nur ein Programmierer bin und keinerlei Ahnung von Design und Grafik habe...

Ich wünschte echt ich könnte irgendwas studieren wo man mal ordentliche Projekte vorgesetzt kriegt. Das "Spiele"-Studium was ich begonnen habe da mussten wir höchstens mal 3D Pacman über reines OpenGL entwerfen oder halt über ASCII mit C. Niemand hatte da wirklich ahnung von irgendwas aber wer da wohnt wo ich wohne und arm ist wie ne Kirchenmaus kann sich wohl nichts leisten wo Qualität dabei ist ohne einen massigen Studienkredit aufzunehmen...

Mir graut schon davor was später im Beruf auf mich zukommt wennich dann endlich meinen Master hab und bei Spieleunternehmen auf Jobsuche gehe. Hoffentlich arbeiten die mich zumindest ein und schmeißen mich nicht ins kalte wasser.

[Sascha]

vor 4 Stunden schrieb Kokujou:

Aber genau das ist ja mein Punkt ^^ ich bin halt ein Programmierer und kein Designer, also erledige ich viel über Skript, weswegen IMGUI besser geeignet ist für mich.

Meine Behauptung beinhaltet, dass Programmierer auch mit dem neuen UI-System keinen wirklichen Nachteil haben. Man muss es sich nur halt mal aneignen und fertig. Nach einem sehr schmalen Ersteindruck zu sagen, IMGUI sei besser, egal in welcher Hinsicht oder für wen, ist einfach sehr kurzsichtig. Und aus eigener Erfahrung mit dem neuen System kann ich auch sagen: falsch.

Bitte nicht wieder falsch verstehen: Ich sage nicht, dass man IMGUI nicht benutzen sollte oder dass es schlechter ist (wobei es da auch so ein paar Aspekte gibt...), sondern einfach nur, dass das neue System in keinem Punkt schlechter ist.

vor 4 Stunden schrieb Kokujou:

Öhm... den letzten Teil musst du mir mal erklären...

Ich kann das gerade nicht reproduzieren, aber ich war schon mehr als einmal in der Situation, dass sich das Layout während einer anderen Eventphase als der Layouting-Phase geändert hat, woraufhin das ganze IMGUI-Ding in die Brüche gegangen ist. Da muss dann erstmal solcher Code her:

private int someValue;
private int nextSomeValue;

private void OnGUI()
{
  if (Event.current.type == EventType.Layout)
  {
    someValue = nextSomeValue;
  }
  
  // IMGUI-Code, der auf someValue basiert
}

public void ChangeValue(int value)
{
  nextSomeValue = value;
}

 

[Kokujou]

naja der Fix sieht doch aber nicht so umsätndlich aus Das layout ändert sich...
Ich meine ich kann mit dem Begriff schon was anfangen aber irgendwie versteh ich nicht wie sowas unkontrolliert passieren kann...
Ist das so per Android gewesen wie wenn man zwischen horizontal und vertikal wechselt oder wie?

 

Und diese Aspekte würden mich mal interessieren. Von der Praxis her ist das neue Sicherlich nicht schlechter als das Alte aber komplizierter auf jeden Fall.
Wenn man bedenkt dass man nur für einen simplen Button so viele Einstellungen machen muss, verlgeich dass man mit dem

if(GUI.Button(new Rect(x,y,w,h),"")){};

von der IMGUI. Was die effekte angeht so hat es die IMGUI geschafft das über ne einfache mathematische  Spielerei über eine minimale Textur zu regeln, um so einen hovereffekt des Buttons zu erwirken. Statt irgendwelche komplizierten Animationsbäume zu erstellen. Aber natürlich kann man auch für jeden Status eine eigene Textur festlegen, sodass auch die Individualisierung kein Problem ist.

Ich bleibe bei der  Meinung dass die Canvas GUI einfach nicht vorrangig zum Skripten entworfen wurde. Während die IMGUI explizit dafür ist und soweit ich weiß keine direkte Umsetzung im Editor hat.  Klar hast du Recht und ich bin nicht so tief in der Materia wie irgendwelche Profi Spiele-Entwickler oder... Naja Leute die im Team arbeiten XD aber mir fällt zumindest nichts ein was die Canvas GUI in Punkto Skripting einfacher macht als die IMGUI.

Am Ende ist es aber irrelevant was besser zu skripten ist denn am Ende zählt für den Spieler ja nur das Ergebnis und das ist mit der Canvas GUI potenziell sicherlich besser. Bei meinem aktuellen Projekt spielt es jedoch keine Rolle.

[malzbie]

Zitat

Ich bleibe bei der  Meinung dass die Canvas GUI einfach nicht vorrangig zum Skripten entworfen wurde.

Da hast du Recht!

Es ist nämlich ein ganz anderer Ansatz. Den die GUI ist bei Spielen etwas Grafisches und wurde auch in diesen Bereich rein geschoben.
Man erzeugt keinen Button per Code und gibt ihm dann per Code seine eigenschaften. Man nimmt sich einfach einen Button aus dem Menü und wirft ihn in die Szene. Schon werden fast alle nötigen Komponenten und das Drumherum, wie die Canvas erzeugt. Alle anderen Dinge fügt man einfach hinzu.
Ob und wie sich ein Button verhalten soll, wenn z.B. die Maus darüber kommt, er also den Fokus kriegt, stellst du einfach über Parameter ein. Soll er sich animieren, dann machste eben eine Animation für die einzelnen Zustände. Soll er eine andere Grafik oder Farbe bekommen, dann stellst du das einfach ein. Alles ohne Code.
Und wenn er gedrückt wird, sagst du dem Button einfach in welches Script und welche Funktion er rein springen soll. Fertig!
Natürlich ist es etwas umständlicher, wenn du z.B. die Grafiken oder Texte eines Buttons je nach Gegebenheit ändern willst, weil du für jedes Element eine eigene Referenz bilden musst. Aber das ist jetzt auch nicht so schlimm.
Wenn alles in dem Spiel extrem dynamisch ist, muss man halt Prefabs bilden und die dann instanzieren. Aber in der Regel baust du dir deine GUI Elemente zurecht und schiebst sie einfach aus der Szene (Bzw. dem Sichtfeld der Camera heraus) und wieder rein, wenn sie gebraucht werden oder eben weg sein sollen.

Man muss also für das Aussehen der GUI (Positionierung, Aussehen, Verhalten) gar nichts groß programmieren. Man programmiert nur was passieren soll, wenn der Button gedrückt wird.
Und das ist doch gut, denn ein GUI Layout ist nicht die Arbeit eines Programmierers!
Wenn du jetzt einfach mal so an ein Team denkst, wo Grafiker und Porgrammierer zusammen arbeiten und sich in der Entwicklung öfters mal das Layout ändert, kann das dem Programmierer egal sein. Lass den Grafiker die Buttons da hin schieben wo er will oder in der Größe ändern oder in der Animation. Der Einsprung in die Funktion hat sich ja nicht geändert, nur weil der Button jetzt etwas weiter unten ist oder anders aussieht.
In der alten GUI müsstest du als Programmierer aber alles selber machen, denn du gibst ja im Code an, wo die Position ist und wie der Button aussieht.
Von daher ist die neue GUI schon gut.
Ob sie besser ist, muss jeder für sich selbst entscheiden. Ich habe mich für die neue GUI entschieden, denn sie spart echt viel Zeit! 

[Kokujou]

Naja das Eventsystem musste ich selbst erzeugen, war schon völlig erledigt weil ich nciht wusste warum der button einfach nicht funtioniert hat...

Ja GUI Layout ist nicht die Arbeit eines Programmierers aber ich bin ja nur ein Programmierer XD Und ich bin der einzige der an dem projekt arbeitet. Darum ist es  mir auch lieber sowas per Skript zu machen, für mich ist das irgendwie einfacher und etwas dynamischer. Dafür siehts dann am Ende zwar auch son bischen aus wie "typsich programmierer" aber naja...
Ich hätte in meinem Studium echt gerne mal mit ein paar Fähigen Grafikern zusammengearbeitet, aber alles was mir vergönnt war, war in einer Gruppe mit Leuten zu sein die mich die ganze Arbeit machen lassen haben. Und weil ich eh eher Einzelgänger bin hat das nicht geholfen, obwohl ich ja schon da raus wollte, richtige Projekte macht man eben nur im Team. Aber statt sowas zu lernen setzen die uns hin, sagen "macht mal irgendein Projekt" und dann wars das. Und sowas nennt sich dann Studium. Ich fühlmich chronisch unqualifiziert...

Apropos: Der Programmierer ist dann aber auch dafür zuständig die GUI-Elemente zu instanziieren, wenn sie dynamisch erzeugt werden sollen.
Wenn z.B. ein Lebensbalken über deinem Charakter zu sehen sein soll, ist es zwar der Graifker der festlegt, wie Lebensbalken, Text und MP-blaken angeordnet sind, aber der Programmierer muss schätze ich mal dafür sorgen, dass er irgendwie dem Spieler folgt. Aber egal ^-^

Aber mal ehrlich, warum haben sie bei Unity nicht einfach beides gemacht? Ich meine das Skripting hat man doch immer ein bischen im Blick, wie kann dann aus sowas einfachem wie

if(GUI.Button(...)){}

sowas abartiges Werden wie ein Bild + Text als Child mit x weiteren Komponenten und nochmal y Komponenten auf dem Parent?

da wäre es ja fast einfacher ein extra C# Skript zu machen, wo quasi nur if(GUI.Button(...){}  drin steht und dan als globale Variablen die Position und n bisl drumrum skripten XD
Nix gegen die ganzen tollen Layoutmöglichkeiten etc, aber bei den einzelnen Elementen haben sie, wie ich finde, richtig mist gebaut.

Einen Button als Image + Text zu interpretieren ist ja mal richtig alte Schule, da wäre ja nur noch das i-tüpfelchen, dass man nichtmehr mit Onclick handeln kann sondern erstmal den Klickstatus der linken maustaste und deren position mit der aktuellen position des Buttons abgleichen muss und zwar händisch XD Ichmeine klar am Ende wird da vieles automatisch erstelt undso, aber stell dir mal vor du bist ein Neuling, willst dir ganz harmlos ne simple GUI zusammen klicken und plötzlich, du drückst nichtsahnend auf Button, ploppen da x neue Komponenten durch die Gegend und extra Children und du denkst dir so "oh mein gott hab ichs kaputt gemacht?"

und 8/10 wechseln lieber zu UnrealEngine oder CryEngine (die will ich demnächst mal ausprobieren, kommt ja beim Arbeitgeber sicher gut an wenn man Erfahrung mit merheren Engines hat.)
 

[malzbie]

Ich kann deinen Unmut voll verstehen. Aber es hilft ja nichts.
Die alte GUI ist etwas für Programmierer und die neue GUI eben eher nicht.
Und ja, es ist wirklich so, dass du ein einziges Script nur für die GUI nutzt. Dieses Script hat die ganzen Einsprungfunktionen für die Buttons und setzt bzw. übermittelt alle informationen an die GUI Elemente. Es ist also die Schnittstelle von der UI zum Game und umgekehrt.  Da drin passiert nichts Herausforderndes sondern nur das übermitteln von Werten und eigenschaften.
Auch das instanzieren von neuen Eingabefeldern, Listenelementen oder Buttons würde da gemacht werden. Trotzdem wären all diese Elemente irgendwann ja mal definiert und als prefab abgelegt worden. Somit ist da nicht viel für den Programmierer zu tun, außer eben die Elemente zu erzeuegen, unterzuordnen und in Relation zum Überobjekt zu positionieren.

Wenn du nicht ein reines Textadventure machen willst, wird dir als Programmierer leider nichts anderes übrig bleiben, als dich mit Grafikertätigkeiten auseinander zu setzen.  Jetzt nicht unbedingt auf die GUI bezogen, sondern allgemein. Somit schadet es nichts, mal über den Tellerrand zu schauen und einfach mal rauszufinden, wie die das machen und warum das so ist.

Du wirst sehen, dass vieles, auch wenn man es per Code lösen könnte, sinnvoller oder praktischer ist. Ich z.B. manipuliere irgendwelche Objekte immer öfter über eine Animation als über code.
Als Beispiel 2 Türen eines Aufzugs. Die kann man per Code bewegen lassen lassen, man braucht die 2 exakten Punkte an denen die Bewegung aufhören soll.
Dann braucht man eine Beschleunigung, eine Verzögerung und die Dauer der Bewegung. Das alles Programmierst du ein, schaust es dir an und änderst im Code die Parameter, bis dir die Tür in der Bewegung gefällt. Das machst du für das Öffnen der Tür und für das Schließen.
Oder aber du machst das über den Animator und programmierst einfach 2 Zeilen um dem Animator zu sagen was er tun soll.
Im Animator steuerst du über die 2 Parameter einfach 2 Animationen der Türen. Natürlich musst du die Animationen erstellen und mit ein paar Klicks die Logik im Animator verdrahten. Aber ich würde mal sagen, dass ich das innehalb von 2-3 Minuten erstellt haben würde. Denn ich setze in jeder Animation einfach nur 2-3 Keys für die Tür und manipuliere etwas an der Animationskurve.

Das ist also ein ganz anderer Weg, der fast ausschließlich über die Grafik gelöst ist. Er ist nicht unbedingt besser als die Codevariante, aber viel einfacher und flexibler. Denn stell dir mal vor, du wolltest eine Tür bewegen, die irgendwo schleift oder hakt und dadurch sich stotternd bewegt. Das zu programmieren stelle ich mir spannend vor. 

WIe dem auch sei. Ich will damit nur sagen, dass man über den Tellerrand schauen soll und muss. Denn wenn man sich fragt: "Was haben die sich nur dabei gedacht?", dann bedeutet das nicht unbedingt, dass es schlechter ist, sondern einfach nur, dass es anders ist.

Und deswegen schau ruhig mal bei Unreal oder Cry vorbei und mach dir dein eigenes Bild.
Es kann schon sein, dass 8/10 da rüber gegangen sind. Aber 5/8 sind auch wieder zurück gekommen.

[Sascha]

vor 6 Minuten schrieb malzbie:

Die alte GUI ist etwas für Programmierer und die neue GUI eben eher nicht.

Das ist halt das, wo ich widerspreche. Man muss sich das neue System halt angucken und den Komponenten-basierten Ansatz verstehen. Die meisten sehen, dass sie nicht einfach mit einer einzelnen Zeile Code in einem Gottklasse-UI-Script ihr Ziel erreichen können und sagen dann "das neue System ist doof", bevor es "klick" gemacht hat. Klar ist da erst einmal eine Hürde zu bewältigen, aber die Code-Qualität für UI-Code nimmt schlagartig zu, sobald man begriffen hat, wie das funktioniert. Und das meine ich im Vergleich zu IMGUI.

Zu sagen, das neue UI-System ist eher weniger angenehm für Programmierer, ist zu sagen, Unity sei weniger angenehm als selbst eine Engine zu schreiben, weil man sich erstmal hinsetzen muss und lernen muss, wie man mit Unity zu arbeiten hat. Hier wird zusätzlicher Einarbeitungsaufwand mit niedrigerer Anwendbarkeit verwechselt.

[malzbie]

vor 5 Stunden schrieb Sascha:

Zu sagen, das neue UI-System ist eher weniger angenehm für Programmierer...

So hab ich das ja nicht gesagt. Denn es geht nicht um angenehm oder nicht. Sondern es geht darum dass man auf fertige Skripte zugreift und denen nur wenige Befehle oder infos geben muss. Denn was ist den die neue GUI? Genau! Ein Sammelsorium aus Skripten. Und somit ist die meiste Arbeit des Programmierers, wie sie bei der alten GUI war, gar nicht mehr nötig. Jetzt nutzt man nur noch wenige Zeilen Code für die Steuerung und alles andere ist auf des Grafikers Seite.
Verstehste? Der Programmierer ist nicht mehr nötig, wenn ich fancy Effekte erstellen will oder einfach nur das Layout gestalte. Die Kompetenz wurde verschoben.
Klar, wenn man will, kann man auch das Rad nochmal neu erfinden oder einfach eine GUI mit all seinen Komponenten auch per Code zusammenbauen. Nur warum sollte man das tun, wenn es doch mit ein paar Mausklicks geht und man für dynamische GUI's auch Prefabs machen kann, auf die man dann zurückgreift?

 

[runner78]

Fun fact: Bei Kerbal Space Program wurde nach dem ersten finales Release, große Teile der der UI von der alten GUI auf das neue UI-System umgestellt.