Jump to content
Unity Insider Forum

Kokujou

Members
  • Content count

    204
  • Joined

  • Last visited

  • Days Won

    1

Kokujou last won the day on September 27

Kokujou had the most liked content!

Community Reputation

2 Neutral

About Kokujou

  • Rank
    Advanced Member
  • Birthday 11/13/1993

Contact Methods

  • Website URL
    http://obscuritas.pw

Profile Information

  • Gender
    Male
  • Location
    Dessau-Roßlau
  • Interests
    Spieleentwicklung, Animes

Recent Profile Visitors

869 profile views
  1. Hallo erstmal~ Ich schätze mal das ist eine totale Grundlagenfrage die fast schon peinlich einfach zu beantworten ist, warscheinlich denke ich gerade viel zu kompliziert. Problem ist folgendes: ich will meine App fürmöglichst viele Geräte haben, sie soll exakt gleich angezeigt werden. Meistens wenn sich die größe des Geräts ändert, verschieben sich irgendwelche 3D-Objekte raus oder rein, die das nicht sollen. Ich hab eine orthografische Kamera, falls das interessiert, und das soll auch so bleiben. Aktuell arbeite ich mit dem Camera.rect, aber ich will eher dass der gesamte Inhalt gestreckt wird, statt dass man einen sehr sehr unschönen Bereich hat, auf dem irgendwelche BIldfragmente sind.
  2. Hallo... Ich hab ja kürzlich mal die Frage gestellt, wie ich graphische Effekte über der Skripting GUI anzeigen kann... Daraus ergab sich nun folgendes Setup: Ich habe eine Main und eine Effektkamera. Die Main cleart aller außer der Effekte, die Effektkamera eben nur die Effekte, Clear Flags sind auf Depth Only. Die Effektcamera rendere ich manuell mit Camera.Render() am Ende der OnGUI Funktion. Aber großes Problem: Plötzlich ist alles total verschwommen! Der ganze Rest ist in Ordnung und an den Grafikeinstellungen liegts auch nicht. Wenn ich z.B. die Effektkamera bei laufendem Spiel so einstelle, dass ihr ViewRect verschwindet, ist es wieder ganz normal. Das darf natürlich nicht sein, hat irgendjemand eine Idee was ich dagegen tun kann?
  3. Dann werd ich demnächst wohl mal ein bischen damit rumexperimentieren Dankeschön! Jetzt mal ehrlich, in diesem Gespräch hab ich mehr gelernt als in meinem ganzen studium XD
  4. Klingt schlimmer als es ist, das bezweifle ich ^^ Das Verändern an sich mag einfach sein, aber man muss auch erstmal berechnen wie es sich verändern würde, wenn... Also muss man die Kraft und Härte des Einschlags mit der Härte des Materials verrechnen und dann die Tiefe des Kraters berechnen. Das ist es ja was ich mit hardcoding meinte ^^ Das mit dem Teig war übrigens nur ein Beispiel dass mirspontan in den Sinn kam. Mir kam dieser Anwendungsfall in den Sinn und da hat mich interessiert wo aktuell so die Grenzen liegen. Vielleicht könnte man ja stattdessen, um mal wieder zum Beispiel mit dem Teig zurückzukommen, einen kleinen Sphere Collider, oder vielleicht auch lieber Boxcollider, irgendwas Effizientes, auf der Oberfläche Platzieren und statt der Form die Position dieser Collider entsprechend der Deformation ändern. Sodass man an verschiedenen Berührungspunkten den "Druck" messen kann der ausgeübt wird und entsprechend im Skript agieren kann. Aber das wird wohl die Grenzen von verfügbaren Tools überschreiten und am Ende läuft es wieder auf Hardcoding raus. Dann noch eine letzte Frage: Wie sieht es mit Texturanpassung aus? Verabschieden wir uns mal vom Teig, nehmen wir mal... einen Berg, den man abbauen will, oder ne Sprengung oder vielleicht einfacher gedacht, wieder die Rüstung die von etwas getroffen wird. Wie reagiert man jetzt mit Texturveränderung? Normalerweise haben Objekte ja eine feste Form der sich dann eine Textur anpasst, kann man die dann zur Laufzeit ansprechen und an der Einschlagstelle verändern? oder gibt's da eine bessere Methode. Besonders Landschaftsveränderungen sind ja für viele Spiele besonders im Bereich der Simulatoren extrem wichtig.
  5. Ach echt? Ich wusste dass normale Animationen damit möglich sind aber dass das auch für sowas wie Flattern oder z.B. Schleimmonster oder eben Brotteig gilt, wusste ich noch nicht! CPU-basiert klingt gut für Leute die ne Super CPU haben wie ich könnte man ja vielleicht auch entsprechend in den Einstellungen verfügbar machen. Deformation heißt auf Deutsch... Hardcoding? Also quasi dass man jeden einzelnen Vektor selbst beeinflusst und animiert und schlimmstenfalls auch auf Physik reagieren lässt? Dann jetzt mal die logische Folgefrage: Wie sieht es mit Collidern aus? Denn ich sehe bei den Methoden jetzt schon die Kollisionsbugs, wenn man damit nicht richtig umgehen kann. Beim Hardcoding könnte man das warscheinlich eher machen, aber Meshcollider dürfen ja per se schonmal nicht zu komplex sein, und dann da noch ne Deformation reinbringen... ist das performant? Bleiben wir mal bei dem Beispiel mit dem Brotteig. Stell dir vor du hättest als standardform eine Kugel, optional auf der BOdenseite etwas "angeplättet" dann kommen die Hände des Protagonisten, drücken drauf und dann soll sich der Teig den Händen anpassen, quasi wie in echt, kriegt man sowas hin oder muss man da tricksen? Die Reaktion auf äußere Einflüsse ist ja auch in vielen Professionellen Spielen nicht unbedingt Usus. Meistens wird das so geregelt, dass man wenn man z.B. getroffen wird einfach entsprechend des Schadens den Modus der Rüstung ändert und die Rüstung dann in den "Ausgebeult" oder "blutbefleckt" status wechselt, statt tatsächlich auf die Kollision des Schwertes oder der Kugel zu reagieren. Aber wenn ich mir das so logisch überlege ist eine direkte Reaktion auf Kollisionen wohl nur über Skripting möglich und frisst entsprechend viel Resourcen hm?
  6. Hallo erstmal~ Kleidung, die im Wind weht, Wellen, alles was keine feste Form hat. Wie würde man solche Dinge realisieren? Skriptet man da die entsprechenden Meshs um? Das klingt ziemlich aufwändig und ineffizient. Ein Beispiel: Sagen wir mal wir wollen eine Animation von einem Bäcker der Teig knetet. Wie würde man so etwas angehen?
  7. 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.)
  8. 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.
  9. 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.
  10. 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.
  11. 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... ^^
  12. 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
  13. 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?
  14. 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.
  15. 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.
×