Jump to content
Unity Insider Forum

Leaderboard


Popular Content

Showing content with the highest reputation on 11/19/2016 in all areas

  1. 4 points
    Hallo *, mein neues Projekt nähert sich der Fertigstellung. Es geht bei diesem kleinen Spiel darum, während einer Klassenarbeit die Schummler ausfindig zu machen. Das Spiel hat 75 Level und drei verschieden schwierige Endlos-Spiele. Ein Video der Preview könnt ihr ansehen unter: Ich freue mich über Kritiken & Meinungen. Ulrich
  2. 2 points
    Ah ja, das ist einfach zu fixen. Zuerst einmal: Statt GetComponent<Transform> kannst (und solltest!) du einfach "transform" schreiben. Dann zum Problem: Transform.position ist die Weltposition. Wenn du die Position relativ zum Objekt setzen willst, dem das Objekt untergeordnet ist, nutze stattdessen Transform.localPosition. Übrigens ein Tipp: Du kannst das GameObject-Gebilde noch ein wenig ausbauen und damit das ganze eleganter machen: Parent GameObject (Bewegung, Drehung um die Y-Achse) Pitch Parent (neu, Drehung um die X-Achse) Kamera (bewegt sich nur noch nach vorne/hinten) Der Pitch Parent hat die lokale Position 0,0,0, also dieselbe Position wie das Parent GameObject. Die Kamera wird ausschließlich auf der Z-Achse nach hinten verschoben. Dann drehst du den Pitch Parent auf der X-Achse, sodass die Kamera nach oben gedreht wird. Jetzt kannst du den Zoom durch reine Bewegung der Kamera auf der lokalen Z-Achse machen, ohne dass noch die Y-Achse dabei sein muss. Das könnte dann so aussehen: var pos = transform.localPosition; pos.z = Mathf.Clamp(pos.z + Input.GetAxis("Mouse ScrollWheel") * zoomSpeed, minCameraDistance, maxCameraDistance); transform.localPosition = pos;
  3. 1 point
    Gerade unerfahrene Leute haben starke Bedenken, wenn es um die Performance in Unity geht. Sie haben aus unterschiedlichen Quellen gehört, dass Dies oder Jenes schlecht sein soll und jetzt gehen sie total ängstlich an das Projekt heran. Denen möchte ich aber sagen: Macht euch nicht verrückt! Denn wie immer ist alles eine Frage von der Menge an leistungsfressenden Dingen, dem gewünschten Resultat und der Hardware, auf der das Spiel laufen soll. Viele Dinge beziehen sich auf Hardware, die kaum noch genutzt wird, wie z.B. das iPad1, welches nicht mehr als 120MB Ram für das Spiel zur Verfügung gestellt hatte. Oder aber es bezog sich auf veraltete Techniken bei denen Unity schon längst performatere Dinge gebastelt hat, wie die unterschiedlichen Lighting-Arten. Ich will mal versuchen, die einzelnen Bereiche abzuarbeiten. Das Grafische: Alles was ich sehen kann kostet Leistung. Mal mehr, mal weniger! Je mehr Realismus ich in ein Spiel rein bringen will umso mehr Leistung wird verbraucht. Denn jedes Poygon, jedes Licht, jede Schattenberechnung und jedes Material verbraucht etwas. Diese Dinge belasten meist die Grafikkarte, denn die ist es, die das ja anzeigen und vorher berechnen muss. Habt ihr ein Spiel mit üppiger Szenerie und schaut euch zur Laufzeit mal den Profiler an, dann seht ihr, dass der Grafikbereich die meiste Leistung schluckt. Unity ist von sich aus schon bemüht, sparsam zu sein und kann gleichartige Dinge zusammen fassen, wenn sie z.B. das gleiche Material haben und auch vom selben Licht bestrahlt werden. Das reduziert die Drawcalls, die einen Großteil der Performance ausmachen. Man hat die Möglichkeit Beleuchtungen und Verschattung vor zu berechnen und die Ausleuchtung einer Szene zu backen. Das reduziert ganz massiv die Last auf der Grafikkarte, kostet aber Speicherplatz und natürlich geht die Dynamik der Beleuchtung dadurch flöten. Aber was bringt es, wenn man genau diese Dynamik haben will. Genau, es bringt nichts! Mit Shadern sieht es genauso aus. Ein einfacher Shader mit nur einer Textur ist recht sparsam. Er gibt aber auch nicht viel her. Schöner ist er, wenn er glänzen kann, transparent ist, erhaben ist und eben realistisch aussieht. Will ich das haben muss ich ihn auch einsetzen. Die Geometrie eines Körpers sollte natürlich so sparsam wie möglich aufgebaut sein. Die Zeit, wo ein Oberarm aus 12 Polygonen besteht, ist aber längst vorbei. Ich kann zwar vieles mit einer NormalMap simulieren, aber wenn die Ränder des Polygons zu eckig sind, sieht man das und es wirkt einfach nicht. Also auch da muss ich mich den Qualitätsansprüchen stellen und mehr Polygone nutzen. Ich kann sogar DirectX11 einsetzen und aus wenigen Polygonen eine Million Polygone machen. Ja, aber eben nur auf einer Grafikkarte, die das auch kann. Egal, wollt ihr die Technik einsetzen dann funktioniert es eben auch nur auf einer Hardware, die das auch kann. Lasst euch also nicht zu stark einschränken. Ihr werdet natürlich irgendwann merken, dass das Ganze zu viel geworden ist und die Framerate einbricht. Meist lässt sich das aber mit etwas geänderter Beleuchtung, LOD oder anderen Dingen schon wieder beheben. Da aber niemand genau sagen kann, wo die Grenzen liegen werden, bringt es auch nichts, wenn man vorher seitenweise darüber diskutiert. Die Physik: Die physikalischen Berechnungen kosten Leistung, die der Prozessor bringen muss. Und es ist klar, dass viele Berechnungen auch viel Leistung kosten. Trotzdem ist das jetzt kaum ein Bereich, wo man "extrem" sparen muss. Unity kann ohne weiteres mehrere 100 Objekte gleichzeitig physikalisch berechnen. Einfach schauen, dass nur die Objekte einen Rigidbody bekommen, die auch einen haben müssen weil sie der Schwerkraft oder anderen Forces folgen sollen und/oder Kollisionen auswerten sollen. Collider so einfach wie möglich halten und lieber einen Box-Collider mehr nehmen, als einen Mesh Collider zu nutzen. Meist muss es nämlich gar nicht ganz genau sein. Merkt eh keiner. Der Code: Ja, hier kann und muss man aufpassen. Denn wenige Kleinigkeiten können das System ganz schön verlangsamen. Aber macht euch auch hier nicht verrückt. Denn auch hier ist alles eine Frage der Dosis. Ein paar extreme Dinge will ich aber mal aufzählen. Als Faustregel gilt, dass jede Unity-eigene Funktion, die im Script steht, auch durchlaufen wird. Egal, ob innerhalb dieser Funktion etwas drin steht oder nicht. Die OnGUI Funktion ist die hungrigste, weswegen man so wenig Scripte wie möglich mit dieser Funktion bestücken sollte. Legt also nur die Funktionen an, die auch wirklich nötig sind, auch wenn das einsparpotential hier (außer bei der OnGUI) nur gering ist. Immer wenn aus einem Script heraus ein anderes Objekt oder dessen Komponente gesucht wird, kostet es Performance. Es hilft aber nichts. Manchmal muss man einfach nach anderen Objekten oder Komponenten suchen. Um jedoch so wenig Leistung wie möglich zu verbrauchen, sollte man nur einmal danach suchen und einfach die Referenz des Gesuchten in eine Variable speichern. Manche Befehle sind recht hungrig, wie z.B. die Entfernungsmessung über Vector3.Distance. Da sollte man sich überlegen, ob denn wirklich in jedem Frame die Entfernung gemessen werden muss oder reicht es vielleicht auch, wenn es nur wenige Male pro Sekunde passiert. So eine Messung würde ja in jedem Frame eine gewisse Grundlast verursachen, die nicht unbedingt sein muss. Und gerade wenn viele Objekte viele Entfernungsmessungen machen, ist es sinnvoll das Ganze in der Zeit aufzuteilen um die Grundlast zu verringern. So ist das natürlich auch mit komplexen Berechnungen die in einer Schleife ausgeführt werden. SendMessage ist ein teurer Befehl, der an ein gewisses Objekt und an all seine Komponenten etwas sendet. Egal ob die Komponente damit etwas anfangen kann, oder nicht. Diesen Befehl sollte man wirklich nur sparsam nutzen. Will ich einem anderen Script jedes Frame etwas mitteilen, dann ist dieser Befehl dafür total ungeeignet. Für ein einmaliges oder seltenes Senden ist er aber voll ok. Für das ständige Übergeben von Informationen bietet sich an, die Komponente, also das andere Script, vorher zu suchen und als Referenz in eine Variable zu speichern. Jetzt kann ich auf alle Public Variablen oder Funktionen des anderen Scripts zugreifen und sie aufrufen oder manipulieren. Das kostet nicht oder kaum mehr, als wenn es eine Variable des eigenen Scripts wäre. Alles das, was ich da aufgezählt habe macht sich erst ab einer gewissen Menge bemerkbar. Je schwächer die Hardware ist, desto früher merkt man es. Nur weil etwas viel Performance kostet, müsst ihr nicht darauf verzichten. Ihr solltet aber weise damit umgehen. Nur weil ich etwas jedes Frame tue, muss das nicht schlecht sein. Es kommt halt immer darauf an, was ich da tue und wie viele Objekte das gleichzeitig machen. Macht euch vorher Gedanken, was ihr für euer Spiel alles braucht und wie ihr das am besten lösen könnt. Aber lasst euch durch diese Planung nicht blockieren. Fangt einfach an. Vieles ist im Nachhinein leicht änderbar. Spiele, die auf einem PC schön aussehen sollen und können, können nicht unbedingt genauso für ein Handy übernommen werden. Es macht aber nicht unbedingt Sinn, sich auf den kleinsten gemeinsamen Nenner zu einigen. Manchmal muss man einfach mehrere Versionen für ein und das selbe Spiel bauen, weil die Qualitysettings nicht ausreichen werden. Fazit: Es ist also alles gar nicht so schlimm!
  4. 1 point
    Wie können sie denn bewegt werden? Per code oder weil sie jemand anrempelt oder wie? Wenn du sie per Code drehst/bewegst könntest du doch bei entsprechenden Methodenaufrufen das Flag setzen. Und wenn sie jemand anrempelt bzw. sie durch das Physiksystem bewegt werden, kannst du in der OnCollisionEnter Methode das Flag setzen. Oder gibt's noch andere Wege Objekte zu bewegen? ^^ Bei beiden Möglichkeiten hast du zusätzlich Zugriff auf das bewegte/gedrehte Objekt, falls das wichtig ist.
  5. 1 point
    Das ist ja alles richtig. Aber das ist genau das, worum es in meinem Post geht! Die Dosis macht's! Deswegen nicht verrückt machen und sich selbst im Weg stehen, nur weil es vielleicht eine minimal bessere Möglichkeit gibt. Wer so ans Entwickeln heran geht, wird nie fertig. Meist kommt man gar nicht in den Bereich, wo es sich spürbar auswirkt. Und wenn doch, dann kann man immer noch optimieren. Nachträgliches Optimieren gehört einfach zum Entwickeln dazu.

Announcements

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

Weiterleitung zum Entwickler "daubit"



×
×
  • Create New...