Jump to content
Unity Insider Forum

Leaderboard


Popular Content

Showing content with the highest reputation since 06/14/2018 in all areas

  1. 5 points
    Version: 1.45 Entwicklerforum: Canyonbreed Forum DiscordChannel: https://discord.gg/NRaJKe2 Ein Respawnpunkt Ronith-4, ein sandiger Planet. Sandsturm im Zeitraffer
  2. 5 points
    Hallo zusammen, ich habe die letzten 10 Monate neben einem Spiel auch an einem Video gearbeitet. Ich dachte mir, dass eventuell einige von euch das Thema interessieren könnten. Es geht um eine relativ stark verallgemeinerte Erklärung, wie eine Game Engine realistische Modelle/Materialien darstellt.
  3. 5 points
    Moin zusammen, wir bei PHOS Digital, mein Kollege und ich, arbeiten an einem "postapokalyptischen racing shooter" im Stil von Mad Max und Co. und ich möchte euch unseren Titel kurz vorstellen. Seit Anfang des Jahres arbeiten wir daran und noch sind wir mitten in der Preproduction, aber ich denke zum zeigen ist es schon ganz ordentlich. Wer Interesse an dem Titel gefällt, kann uns gerne auf www.phosdigital.com über den Newsletter folgen oder uns auf Facebook / Twitter finden. Es wird typische Rundenrennen und andere Spieltypen gegen KI oder Online Konkurrenten geben, in denen ihr euch gegenseitig bekämpfen könnt... Ob mit guten Zeiten oder Waffen, ist euch selbst überlassen. :-) Hier ein paar Screenshots
  4. 5 points
    Hey, Ich experimentier aktuell mit meiner eigenen Idee rum, Oberflächen aus Distanzfunktionen (signed distance function, SDF) zu generieren. Ihr könnt meinen Ansatz in diesem Thread verfolgen, falls ihr euch für so Voxel Zeugs interessiert: https://www.gamedev.net/forums/topic/697431-a-novel-approach-to-non-manifold-dual-contouring/ Im Grunde gehts darum Eckpunkte (vertices) durch Schnittpunkte von Oberflächenkanten (surface edges) ausfinding zu machen. Die 2D Methode scheint ohne probleme zu funktionieren, und ermöglicht so auch scharfe geometrische Features wie Ecken. (dabei ist's auch deutlich einfacher zu verstehen, als 2D Dual Contouring) Mit dem 3D Ansatz bin ich aktuell noch ein wenig am kämpfen, aber erste Ergebnisse gibts dazu auch schon, wie ihr hier nochmal sehen könnt:
  5. 4 points
    Ich hab den Algorithmus ein wenig angepasst, um das Problem mit den weichen Ecken zu lösen. Im Grunde schau ich mir einfach die vertices an, die nicht ganz korrekt sind, addier alle Normalen zusammen (nennen wir das Ergebnis einen Vektor A) und interpoliere dann von diesem Vertex aus in die Richtung A bis die SDF an diesem Punkt = 0 ist. Ich musste allerdings einen kleinen Bias einbauen, aber ich denke das sind einfach bloß Genauigkeitsprobleme, da die Implementation aktuell komplett auf floats setzt. Die schwarzen Linien am Ende zeigen das Ergebnis der Normalen (Vektor A) bei den Vertices, die zunächst gesmoothed wurden. Ich werd noch mehr testen müssen, um zu schauen, ob die Lösung so allgemein aufrecht erhalten werden kann.
  6. 3 points
    so nach langer Pause auch mal wieder ein Bildchen von mir , ich poste sonst immer in meinem Discord Channel oder auf unserer Facebook Seite naja jeden falls hab ich hier ein Bild von unserem Necromancer in der Dämonen Kathedrale
  7. 3 points
  8. 3 points
    @Helishcoffe Oder halt Gizmos.DrawWireCube bzw Handles.DrawWireCube
  9. 2 points
    Ohwe ohwe war ich hier lange nicht mehr unterwegs... Kennt mich hier überhaupt noch jemand? Das Studium frisst einen auf... Aber: Ich kann endlich mal wieder was (öffentlich) von meiner Arbeit zeigen! Und noch dazu ein Unity-Projekt, was doch eher untypisch ist. In den letzten 4 Monaten habe ich im Rahmen des 5. Semesters ein Augmented Reality Sandbox Game entwickelt - vielleicht kennt ihr das aus Museen, Sea Life, etc, manchmal gibt es da so Sandkästen, auf die mehr oder weniger in Echtzeit Höhenlinien projeziert werden. Ich habe das gesehen und mir gedacht: Da muss man doch mehr mit machen können. Und nach viel viel Arbeit kann ich euch meine erste Installation präsentieren: Basic Info: Man nutzt den Schatten seiner Hände um herumwirbelnde Natur-Teilchen einzufangen, diese kann man in vorher gegrabenen Mulden sammeln und so Stück für Stück die Landschaft vergrößern. Technischer Breakdown: Ich nutze eine Microsoft Kinect 2 um die Höheninformationen des Sandes und der Hände zu bekommen. Aber: Das "Raw" Kinect Tiefenbild ist für diesen Zweck eigentlich komplett unbrauchbar. Das rauscht wie verrückt, und immer wenn es eine harte Kante gibt werden die Höheninfos an dieser Kante einfach null - lauter so Zeug. Deshalb war mein erster Schritt das Kinect Bild möglichst performant und vor allem schnell zu filtern und zu smoothen. Dieses GIF zeigt den Effekt. Normalerweise ist es ja so, dass wenn man seine Hand jetzt über den Sandkasten hält, diese Höheninformation auch in die Projektion aufgenommen wird und dort ein sehr hoher Berg entsteht (einer der Gründe für die große Verzögerung der bekannten AR Sandboxes). Ich wollte das auf keinen Fall, weshalb ich nach einem Weg gesucht habe, die Hände aus den Höheninformationen herauszufiltern. Das funktioniert viel billiger als man vielleicht annimmt: Man kalibriert den Tisch einmal ohne Hände und ab diesem Moment werden alle Informationen, die über einem bestimmten Threshold sind, einfach ignoriert. Sobald man die Hand 3cm über den Sand hält, wird diese wieder als Terrain wahrgenommen (Es gibt dann mehrere Thresholds für schnelle Bewegungen etc.) Das Resultat fühlt sich nach einer sehr "magischen" Interaktion an, da eben nur die wirklichen Sandinteraktionen auch Änderungen in der Projektion hervorrufen. Zugleich bekomme ich aus den gefilterten Höhendaten dann eine Maske für die Hände, mit der ich über OpenCV Handgesten und Formen für den Game Input erkennen kann. Da dieses ganze System dann doch immer langsamer und nicht richtig "befriedigend" auf den Input reagiert habe ich das Kinect Bild in 8, sich überlappende Teile aufgeteilt, die auf unterschiedlichen Threads verarbeitet werden. Threading (und vor allem Multi Core Threading) ist in Unity ja bekanntermaßen eher, nennen wir es mal: kompliziert. Aber für ein Spiel wie dieses war es super essentiell, dass alles so schnell wie möglich reagiert. Ich berechne die Positionen der Hand Schatten aus der Projekterposition und den Kinect Daten, um die Spieler damit Objekte einfangen zu lassen - da will man natürlich keinen Lag haben. Und auch das Graben fühlt sich so richtig gut an. Visuall Stuff Das Terrain wird aus einer Displacement Map (die aus den verbesserten Höheninfos generiert wird) erstellt. Der Rest passiert dann in einem Shader: Ich berechne mir die Normalen aus der Heightmap, indem einfach ein Vektor aus einem umliegenden Dreieck von Höhendaten berechnet wird - die Normalmap brauche ich für die richtige Beleuchtung der Landschaft. Wenn man jetzt die Höhe vom Mittelpunkt dieses Dreiecks mit der Höhe von den Eckpunkten vergleicht, kann man eine Realtime Curvature Map berechnen - die ist für schöne Schneebedeckte Bergspitzen und saftig grüne Täler. Die Steigung der Normalen wird auch noch dazu berechnet um Felsen an Steilwänden zu erzeugen und die Wälder an solchen Stellen auszumaskieren. Hier mal eine kleiner Debug Ansicht davon: Der ganze Landschaftsshader ist dann doch sehr groß - es gibt eine Art "Fake"-Erosion, damit die Felsen schick aussehen und eine riesige Anzahl Noises um die Sandstrände, Schneeverteilung, Wälderfarben, Meereswellen etc. zu erzeugen. Das ist aber nur die Landschaft! Es gibt auch noch die dunkle, zerglitchte Welt mit dem selben Setup, aber eben anderen erzeugten Effekten. Da sich das Spiel ja um das Fangen und Verbinden von Natur-Fragmenten dreht sollte diese "Verbindungs-Interaktion" etwas ganz besonderes werden und dem Spieler das visuelle Feedback geben, etwas richtiges getan zu haben. Mithilfe eines Voronoi Effekts habe ich die ganzen Natur-Teile sich miteinander verbinden lassen - jedes Natur Objekt kann sich über einen Shader so hin morphen, dass es in seine umgebenden Voronoi Positionen passt. Das erzeugt einen sehr coolen, snappy Effekt als ob man ein passendes Puzzlestück gefunden hat. Solltet ihr in zwei Wochen zufällig in Stuttgart sein könnt ihr gerne auf der FMX Conference 2018 vorbeischauen, wo das Spiel öffentlich präsentiert wird und dann auch tagsüber spielbar ist. Wenn nicht - ich versuche gerade Museen und Ausstellungen ausfindig zu machen, die sich für so ein Exponat interessieren könnten. Wenn ihr da Ideen habt, schreibt mir doch gerne! Zum Abschluss noch zwei schöne Making Of Bilder Vielen Dank fürs Lesen & ich freue mich auf Fragen und Feedback!
  10. 2 points
    Moinsen! Ich habe gerade ein Paket im Asset Store veröffentlicht: Der Thread dazu auf Englisch im Unity-Forum: https://forum.unity.com/threads/released-13pixels-pooling.587068/ Falls jemand noch nicht so richtig weiß was Pooling ist: Instantiate und Destroy sind keine besonders performanten Methoden. Instantiate deserialisiert das gesamte Prefab einmal und Destroy erzeugt Memory Garbage. Pooling beschreibt den Ansatz, bestimmte Objekte nicht zu löschen, sondern zu deaktivieren und später wiederzuverwenden. Objekt-Typen, die oft spawnen und wieder despawnen, werden dabei performanter, wenn man Pooling benutzt. Es gibt bereits einige Pooling-Pakete, und ich habe einige angeschaut und ausprobiert... trotzdem habe ich mein eigenes geschrieben, weil mir nichts davon gefallen hat. Kurze Zusammenfassung, was mein Paket anders macht als andere: Kein Extra-Setup nötig. Andere Pakete haben meistens einen Pool Manager oder so, also ein Objekt, in das man seine Prefabs ziehen muss, damit man Pooling mit ihnen machen kann. Oder man muss die PRefabs alle in einen bestimmten Ordner tun. Bei 13Pixels Pooling gilt der Grundsatz: Pooling ist eine technische Angelegenheit, und deshalb sollte es im Editor so wenig wie möglich auftauchen. Deine Szenen werden sich nicht ändern, wenn du von Instantiate/Destroy auf dieses Paket umsteigst. Anpassbares Pooling-Verhalten pro Prefab. Standardmäßig benutzt das Paket GameObejct.SetActive, um Objekte zu de- und zu re-aktivieren. Je nach Prefab kann es aber auch reichen, das Objekt einfach aus der Szene rauszuverschieben oder eine einzelne Komponente gezielt zu deaktivieren. In solchen Fällen kann man ein einfaches Interface implementieren, um einem Prefab sein eigenes Pooling-Verhalten zu geben. Pooling-Instanzen können beliebigen Objekten untergeordnet werden. Oft müssen von einem Pooling-System instanziierte Objekte einem Pooling-spezifischen Objekt untergeordnet bleiben - hier nicht. Hier gibt's (auf Englisch) die Anleitung, um mal einen Einblick in den Workflow zu bekommen: http://13pixels.de/pages/assetstore/Pooling/User-Manual.pdf Hier gibt's das Paket im Asset Store zu kaufen: http://u3d.as/1nvh Feedback, Nachfragen und Ideen sind gerne gesehen. Und das nicht nur, weil ich das Ding in meinen eigenen Projekten benutze
  11. 2 points
    Hallo Ich habe vor kurzem Substance Painter abonniert und zum Test ein kleines Schwert modelliert und danach in Painter bemalt. Ist jetzt nicht perfekt, aber ich dachte ich könnte es ja trotzdem mal hier reinstellen, falls es jemand gebrauchen kann. Wenn gewünscht, könnte ich den Rost entfernen oder im unteren Teil auch noch etwas Rost hinzufügen. Sword.unitypackage
  12. 2 points
    Hier mein Script zur Anzeige der FPS. Einfach der Szene hinzufügen (vorzugsweise auf ein Text Ui) und eine Referenz eines beliebigen Text Ui hinzufügen. using System.Collections; using System.Collections.Generic; using UnityEngine; using UnityEngine.UI; /// <summary> /// This script calculate the current fps and show it to a text ui. /// </summary> public class UiDisplayFps : MonoBehaviour { public string formatedString = "{value} FPS"; public Text txtFps; public float updateRateSeconds = 4.0F; int frameCount = 0; float dt = 0.0F; float fps = 0.0F; void Update() { frameCount++; dt += Time.unscaledDeltaTime; if (dt > 1.0 / updateRateSeconds) { fps = frameCount / dt; frameCount = 0; dt -= 1.0F / updateRateSeconds; } txtFps.text = formatedString.Replace("{value}", System.Math.Round(fps, 1).ToString("0.0")); } }
  13. 2 points
    Hallo Leute Ich arbeite zurzeit an diesem Projekt. Der Name ist noch nicht fix. Ich überlege mir noch einen passenden Namen. Zurzeit ist es einfach Das Projekt "DungeonGame"^^ Um was geht es in "DungeonGame"? Du startest in einer Stadt. Dort kannst du Waffen und Rüstungen kaufen und Quests annehmen. Danach kannst du dich für eine Dungeon anmelden. In der Dungeon kannst du zusammen mit Freunden kleine und grosse Monster verprügeln. Nach dem Ausflug kannst du dir bessere Ausrüstung und Waffen kaufen oder diese selbst herstellen. Aktueller Stand: Ich habe einmal das Dorf gebaut und den Markt, in dem der Spieler startet, wenn er ins Spiel kommt. Zukunft: In nächster Zeit werde ich versuchen eine Dungeon zu bauen und ein paar Monster zum leben zu erwecken. und versuchen ein einfaches Gameplay auszuarbeiten. Fortschritte werde ich hier im Forum posten Schreibt mir doch was ihr denkt. Ich würde mich freuen 😁
  14. 2 points
    Moin, habe mal ein Video erstellt, dass verallgemeinert ein grober Einblick in den Renderprozess einer Game Engine gibt. Ich habe recht viele Animationen erstellt um diese Prozesse zu visualisieren.
  15. 2 points
    Junge! Schreib doch mal ganze Sätze. Ich weiß echt nicht wovon du redest. Was sind 6 gewesen und von was benutzt man 3???
  16. 2 points
    Tut mir Leid, "that guy" sein zu müssen, aber das ist einfach völlig falsch. Der Fixed Timestep ist dafür da, zwei Dinge auszulösen: Das FixedUpdate-Event und das Physik-Update über PhysX bzw. Box2D. Physics.Raycast ist eine ganz normale Funktion - man ruft sie auf, sie wird ausgeführt, sie gibt etwas zurück, fertig. Das passiert sofort und ansich unabhängig von jeder Art von Timestep. Wovon das Ergebnis in dieser Situation tatsächlich abhängt, ist die Rate, in der das Event passiert, in dem Physics.Raycast durch @jan1267s Code ausgeführt wird. Ich gehe stark davon aus, das der Aufruf in Update passiert. Damit hängt die Genauigkeit von der Framerate des Programms ab, und damit von der Leistungsfähigkeit des Geräts. Dass das keine gute Sache ist, kann man sich vorstellen. @Mr 3d hat daher schon die richtige Richtung vorgeschlagen. Du willst nicht jeden Frame schauen, wo der Finger gerade drüber ist und dann damit etwas machen. Wenn der Finger sich kaum oder gar nicht bewegt, ist das auch unnötige Arbeit, die das Programm da verrichten muss. Stattdessen willst du den Weg anschauen, den der Finger zwischen letztem Frame und jetzigem zurückgelegt hat, und dann mit einem passenden Algorithmus ausrechnen, welche Würfel alle von diesem Weg abgedeckt werden. Es bleibt nur zu bestätigen:
  17. 2 points
    Mein 3D Lead arbeitet gerad am Workflow mit Vegetation Studio für die "Umwelt" und hat nun noch ein weiteres kleines Hindernis (Waffe) für die Rennstrecke gebaut... Was darf bei einem postapokalyptischen Battle Racer nicht fehlen? Genau, Minen!
  18. 2 points
    Ich fände es auch schön, wenn hier mal wieder mehr gepostet werden würde. War immer sehr interessant zu sehen woran andere hier grade so arbeiten.. Hier mal wieder ein Update zu meinem Blutfluss Shader..
  19. 2 points
    Hallo Community, Ich konnte den Fehler nun finden und beheben. Sollte noch jemand das Problem haben versuche es mal die Lösung könnte für mehrere Package Probleme helfen wenn ihr seltsame Probleme habt. Unity lädt die Packete nicht jedes mal neu runter sondern Speichert sie in einem Localen Ordner. Den Ordner findet ihr unter C:\Users\Benutzername\AppData\Local\Unity\cache\packages\packages.unity.com Löscht den Inhalt, dann lädt Unity die Packete neu runter und Fehler im Download werden so behoben. So konnte ich alle meine Fehler mit der HDR Pipline beheben.
  20. 2 points
    Da hier aktuell ja nicht viel los ist, ändere ich das jetzt mal. (Glücklicherweise habe ich auch mal was vorzeigbares) Generierung eines Straßenzuges, könnte zwar überall noch etwas mehr Varianz vertragen, aber immerhin funktioniert es.
  21. 2 points
    Einfach mal alle Autos die ich bis jetzt gemacht habe auf die Strecke. Da stecken viele Stunden Arbeit drin und Jahre. (Wie man halt Zeit hat)
  22. 2 points
    In dem Fall ist deine Berechnung von dem t Parameter falsch. Da t nur aus dem intervall von [0, 1] sein darf muss deine Formel angepasst werden: (Time.time - startZeit) * geschwindigkeit Da Time.time in Sekunden ist wäre bei geschwindigkeit = 2 bereits bei einer halben Sekunde t = 1. Je kleiner geschwindigkeit wird desto länger würde es dauern z.B geschwindigkeit = 0.5 sorgt dafür das t erst bei 2 Sekunden auf 1 gesetzt wird. Was du willst ist: (Time.time - startZeit) / geschwindigkeit Zudem musst du nicht abfragen ob die Farben gleich sind, prüf einfach ob t >= 1 ist. Zusätzlich darfst du niemals die gesetzte Farbe von den Textboxen wiedeverwenden da es sonst keine lineare interpolation mehr ist. Du musst immer die start und endfarbe wiederverwenden: public void Update() { var t = (Time.time - this.startTime) / geschwindigkeit; foreach(Text text in this.texte) text.color = Color32.Lerp(this.startColor, this.targetColor, t); if(t >= 1) // t = 1 bedeutet wir haben targetColor erreicht { this.startColor = this.targetColor; this.targetColor = // Berechne random Farbe } }
  23. 2 points
  24. 2 points
    Sei mir nicht böse, wenn ich das sage. Aber du stehst dir selber im Wege! Natürlich erkläre ich dir, warum ich das meine. Der Hauptgrund ist dein Optimierungswille, der aber leider in die genau falsche Richtung führt. Wenn ich mich recht erinnere, geht das alles hier um dein Tomb-Spiel, also das ägyptische Thema. Und für dieses recht überschaubare Projekt nutzt du jetzt alle Optimierungsmöglichkeiten, die Unity zu bieten hat. So z.B. Occlusion Culling, welches eher für Open-World Dinge gemacht ist, wo wirklich viiiiiele Objekte eingebaut sind. Natürlich kann man diese Technik in alle Spiele einbauen, aber Sinn macht das nicht unbedingt. Denn damit OC funktioniert, muss Unity ersteinmal die Gegebenheiten backen und als Daten irgendwo ablegen. Du erkaufst dir also Rendergeschwindigkeit und gibst dafür Speicherplatz her. Diese Technik bringt aber nur dann was, wenn die verdeckten Objekte in Blickrichtung der Camera liegen. Also hinter irgendwelchen Wänden, auf die du schauen würdest. Alles was in deiner Szene ist, und nicht im Sichtkegel der Camera ist, wird sowieso nicht gerendert. Das macht Unity auch ohne OC. Da deine Räume bestimmt aus immer wieder den gleichen Objekten zusammen gestellt werden, braucht das auch nicht unbedingt viel Platz, falls du wirklich jeden Raum in einer einzigen Szene drin hast. Du kannst übrigens Szenen auch Additv hinzu laden und besuchte Szenen, in die du nicht mehr rein gehst, wieder entladen. Für dein Spiel bietet sich das wahrscheinlich eher an als OC. Genauso ist das mit dem Backen von Licht, Schatten, Ambient Occlusion ud ähnlichen Dingen. Beim Backen werden Texturen erzeugt, die für deine Objekte wichtig sind. Diese Texturen brauchen Platz auf der Platte und natürlich im Grafikkarten-Ram, sobald sie genutzt werden. Das macht Sinn, wenn man die Texturen nicht zu groß raus rechnen lässt. Wichtig für dich ist einfach zu wissen, dass solche Lightmaps Ram brauchen und dewegen so klein wie möglich gehalten werden sollten. Auch wenn Grafikkarten heutzutage echt viel Ram haben, die Daten wollen alle da rein geschoben werden. Jetzt nutzt du den Profiler um zu sehen, was noch zu optimieren wäre. Du schaust aber eigentlich genau in den Bereich, indem du nur Infos bekommst und der sich selbst verwaltet: Der Speicherbereich! Unity zeigt dir nicht unbedingt die Dinge an, die in einem Build da wären, sondern sammelt Daten indem es schaut, wann welches Objekt welche Textur hat oder wann welches Script welches Objekt steuert. Viele dieser Werte sind also Gesamtzahlen, die nicht für die Szene gelten, sondern für das ganze Projekt. Diese Werte sind auch im Build nicht zu erreichen, denn beim Builden wird wirklich nur das genommen, was nötig ist. Außerdem entsprechen diese Werte nicht dem, was im Build sein wird, weil da nur grob erfasst wird. Richtig erfasst wird erst beim Build, wenn alle Szenen und Objekte definiert sind, die gebraucht werden. Alleine eine Textur, die du ins Projekt eingeladen hast, wird von Unity ganz anders importiert. Deine Ursprungsgrafik ist vielleicht eine Photoshop-Datei und somit unkomprimiert oder hat Vectorgrafik Elemente drin, die noch nicht gepixelt wurden. Unty erzeugt davon aber eine Kopie mit ganz anderen Eigenschaften. Und diese Kopie wird dann im Spiel genutzt. So lange du im Editor arbeitest, siehst du einen Wert, der viel zu hoch ist, denn da wird nahezu doppelt gezählt. Dazu kommen dann noch die von Unity erzeugten Texturen (Lightmaps) hinzu und schon hast du über ein GB an Grafikdaten. Die sind im Build aber nicht da! Die Meshes, Materials und Animationclips, die du da aufgezählt siehst haben erstmal nichts mit der Szene zu tun. Was die genau anzeigen ist mir selbst nicht klar. Die Zahl schwankt zudem. Kannste also komplett ignorieren. Zu den Gameobjects und Objects in der Szene. Wohlgemerkt: Objects sind nicht GameObjects!!! Alles was in deiner Szene ist, wird als Gameobject gezählt. Hast du z.B. eine neue leere Szene auf, in der nur die Camera und ein Directional Light zu sehen ist, wirst du einGO Count von 4 Bei Fullscreen, bzw 8 wenn du Editor Und GameView siehst haben. Du fragst dich sicherlich warum da 4 oder 8 steht, wo doch nur 2 GO's in der Szene sind. Die Szene selbst ist ein GO und das Anzeigefenster auch! Klickst du (wenn dein EditorWindow und dein Gameview beide zu sehen sind) auf die Kamera tut sich ein neues Fenster mit Cameraview im Editorfenster auf und schon hast du ein weiteres GameObject. Die GameObjects, die angezeigt werden, sind also abhängig von der Anzahl der Screens die du gleichzeitig siehst und Unity eigene Dinge gehören dazu. Im Fullscreen wirst du also nahezu genau die Anzahl an GOs sehen, die auch wirklich da sind. Objekte sind etwas ganz Anderes!! Da wird alles mögliche gezählt. Selbst n dieser fast leeren Szene wirst du mehrere 100 Objects sehen. Das sind interne Dinge, die du einfach ignorieren kannst. Der Total Object Count ist genauso. Da wird alles mögliche aus deinem Projekt gezählt. Also der Speicherbereich vom Profiler bringt dir fürs Optimieren erstmal nicht so viel. Wenn du darüber aber mehr erfahren willst, dann klick unten auf Simple und stell auf Detailled um. Dann klickst du gleich daneben mal auf Take Simple Editor und schon hast du eine Liste an Daten, die etwas mehr aufschluss geben. Das sind aber Daten im Editor und sind nicht die Daten, die beim Build dann da sein werden! Der einzige Bereich, der dir gute Daten anzeigt, ist der Oberste! Dort siehst du, wieviel Zeit für was gebraucht wird. Natürlich wird der Profiler selbst auch mitgezählt. Wenn du da jetzt noch Deep Profilig aktivierst, dann siehst du noch viel genauer, wo Power verbraten wird. Das ist ein mächtiges Werkzeug! Der Rest im Profiler ist für die meisten Leute nahezu egal.
  25. 2 points
    Time.time "This is the time in seconds since the start of the game." In der zweiten Szene bekommst du also nicht die Zeit seit dem Beginn des 2. Levels, sondern seit Start des Spieles. Ich würde einfach jeden Frame die vergangene Zeit seit dem letzten Frame zu 'zeit' addieren. Also: zeit += Time.deltaTime;

Announcements

Hy, wir programmieren für dich Apps(Android & iOS):

Weiterleitung zum Entwickler "daubit"



×