Jump to content
Unity Insider Forum
  • Announcements

    • Lars

      Allgemeine Forenregeln   03/13/2017

      Forenregeln Nimm dir bitte einen Moment um die nachfolgenden Regeln durchzulesen. Wenn du diese Regeln akzeptierst und die Registration fortsetzen willst, klick einfach auf den "Mit der Registrierung fortfahren"-Button. Um diese Registration abzubrechen, klick bitte einfach auf den "Zurück" Button deines Browsers. Wir garantieren nicht für die Richtigkeit, Vollständigkeit und Brauchbarkeit der Nachrichten und sind auch nicht dafür verantwortlich. Die Beiträge drücken die Meinung des Autors des Beitrags aus, nicht zwangsläufig das, wofür die Forensoftware steht. Jeder Nutzer, der denkt, dass ein veröffentlichter Beitrag unzulässig bzw. störend ist, ist aufgefordert uns unverzüglich per E-Mail zu kontaktieren. Wir haben das Recht störende Beiträge zu löschen und bemühen uns, das in einem realistischem Zeitraum zu erledigen (sofern wir beschlossen haben, dass die Löschung notwendig ist). Du akzeptierst, durchgehend während der Nutzung dieses Services, dass du dieses Forum nicht dazu missbrauchen wirst, Inhalte zu veröffentlichen, welche bewusst falsch und/oder verleumderisch, ungenau, beleidigend, vulgär, hasserfüllt, belästigend, obszön, sexuell belästigend, bedrohlich, die Privatsphäre einer Person verletzend oder in irgend einer Art und Weise das Gesetz verletzen. Des Weiteren akzeptierst du, dass du keine urheberrechtlich geschützte Inhalte ohne Erlaubnis des Besitzers in diesem Forum veröffentlichst. Mit dem Klick auf den "Mit der Registrierung fortfahren"-Button, akzeptierst du zudem unsere Datenschutzerklärung und stimmst der Speicherung deiner IP-Adresse und personenbezogenen Daten zu, die dafür benötigt werden, um dich im Falle einer rechtswidrigen Tat zurückverfolgen zu können bzw. permanent oder temporär aus dem Forum ausschließen zu können. Es besteht keine Pflicht zur Abgabe der Einwilligung, dies erfolgt alles auf freiwilliger Basis.   Zusatzinformationen Der Forenbetreiber hat das Recht, Nutzer ohne Angabe von Gründen permanent aus dem Forum auszuschließen. Des Weiteren hat er das Recht, Beiträge, Dateianhänge, Umfrage, Blogeinträge, Galleriebilder oder Signaturen ohne Angabe von Gründen zu entfernen. Mit der Registrierung verzichtest du auf alle Rechte an den von dir erstellten Inhalten, bzw. treten diese an das Unity-Insider.de und Unity-Community.de ab. Dies bedeutet im Klartext, dass das Unity-Insider.de und Unity-Community.de frei über deine Texte verfügen kann, sofern diese nicht wiederum die Rechte anderer verletzen. Es besteht weiterhin kein Anspruch von registrierten Nutzern bzw. ehemaligen registrierten Nutzern darauf, dass erstellte Inhalte und/oder die Mitgliedschaft (User) wieder gelöscht werden (Erhaltung der Konsistenz dieses Forums).   Einwilligungserklärung Wenn du mit der Speicherung deiner personenbezogenen Daten sowie den vorstehenden Regeln und Bestimmungen einverstanden bist, kannst du mit einem Klick auf den Mit der Registrierung fortfahren-Button unten fortfahren. Ansonsten drücke bitte Zurück. Stand: 07.03.2011

Life Is Good

Members
  • Content count

    650
  • Joined

  • Last visited

  • Days Won

    7

Life Is Good last won the day on October 29 2017

Life Is Good had the most liked content!

Community Reputation

62 Excellent

About Life Is Good

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Köln

Recent Profile Visitors

3,371 profile views
  1. "Assembly-C-Sharp" ist die Assembly, in die dein ganzer eigener Code geladen wird, also kein Unity stuff wenn ich mich recht erinnere. Unity hat also irgend ein Problem damit, was von deinem Code zu laden. Das könnte beispielsweise durch Zugriff auf korrupten Speicher (Access Violaation) passieren. Sprich: irgendeine deiner Dateien ist eventuell beschädigt oder ähnliches.
  2. GC Performance verbessern.

    Ich hab bloß drüber gelesen (also keine Benchmarks gesehen). Aber der Unterschied zwischen List<ReferenceType> und List<ValueType> sollte ja jetzt auch nicht die Welt sein, also könnte ich es mir vorstellen.
  3. GC Performance verbessern.

    @Sascha Der Speicher deines Struct wird ja aber dennoch vom GC verwaltet. Dein Geschwindigkeitsvorteil ist doch auch wieder dahin, wenn du (wie in @Helishcoffe Fall) deine ganzen Structs in einer Collection hast, weil die zu System.Object ge-boxed / unboxed werden müssen.
  4. GC Performance verbessern.

    Die Aussage ist auch Blödsinn. Sobald dein Struct auf dem Heap laden soll, fällt das selbstverständlich unter den Aufgabenbereich des GC. Und wenn wir es ganz genau nehmen, stimmt das hier auch nicht Der Garbage Collector ist nämlich nicht bloß für's Überwachen & Freigeben von Speicher, sondern auch für's Allokieren zuständig. Allgemein als Tipp noch dazu: Wenn du dich nicht im unsicheren Code wohlfühlst (Ich weiß ja nicht wie es da um deine Kenntnisse steht), solltest du damit auch nicht in Unity rumhantieren. Damit richtet jemand der sich nicht auskennt höchstwahrscheinlich mehr Schaden als Gut an.
  5. GC Performance verbessern.

    Das könntest du machen, ja. Dass deine Daten auf dem Stack landen ist bei 0,25mb / chunk sowieso schonmal ausgeschlossen, also lungern die dir sowieso irgendwo auf'm Heap rum. Allgemein zur Speichermenge: Das kommt drauf an wie deine Chunks so aussehen. Bei Voxel Strukturen z.B. greift man oft gerne zu Octree's um Speicher zu sparen. Das ist dann bloß sowas wie ein LOD System. Was du gerade nicht brauchst, braucht auch nicht im Speicher sein.
  6. Unity 2017 und .NET 4.6

    Ich glaube nicht, dass er das meinte, sondern, dass MoveNext() in Update statt findet. In diesem Sinne ist deine Coroutine schon ein wenig davon abhängig. Ansonsten scheint await nicht sonderlich davon abzuweichen. Der Compiler generiert eine Statemachine, die von der Struktur ähnlich wie IEnumerator & yield aussieht. Der Unterschied ist, das MoveNext() dort über Callbacks (sobald die Arbeit verichtet wurde) aufgerufen wird. Wie das aussieht, wenn auf dem selben Thread gewartet wird hab ich jetzt auf die Schnelle aber nicht herausgefunden. https://weblogs.asp.net/dixin/understanding-c-sharp-async-await-1-compilation Wenn du mit "Kernel" CPU Kerne meinst, das übernimmt für gewöhnlich das Betriebssystem. Vermutlich liegt der Unity Main Thread einfach auf dem 1. Kern. Mit https://msdn.microsoft.com/en-us/library/system.diagnostics.process.processoraffinity.aspx könntest du allerdings Threads auf spezifischen Kernen starten.
  7. Unity 2017 und .NET 4.6

    Ahhh, jetzt versteh ich worauf du hinaus willst. Naja, dafür müsste man sich async / await mal genauer anschauen. Wie genau die das intern machen weiß ich gerade nicht. Aber das Prinzip bleibt ja das selbe Da stimme ich zu, also lass ich's mal so stehen.
  8. Ich hab mal ein wenig Code auf mein GitHub profil hochgeladen.
    Simple, leichte und (relativ :) ) saubere Implementationen von A* und Flow Fields pathfinding (bei A* fehlt noch ein kleines Video oder so...)
    Mir ist aufgefallen, dass gerade zu A* ziemlich verwurstelte Code Beispiele bei Google rauskommen :D
    Wen sowas interessiert, der kann ja mal reinschauen. Vielleicht schreib ich auch mal 'ne Tutorial oder so dazu.

    A* https://github.com/GoGreenOrDieTryin/Unity-A-Star
    Flow Fields https://github.com/GoGreenOrDieTryin/Unity-Flow-Fields

    1. Djeurissen

      Djeurissen

      Darf man Kritik äußern xD? Warum übergibst du den Start/Ende/Grid im Konstruktor. Jetzt musst du jedesmal ein neues A* Objekt erzeugen wenn du ne neue Suche machen willst...

      Ansonsten wenn du mehr Performance haben willst nutz nen Heap. Der sorgt dafür das du nicht immer durch die ganze Liste iterierst wenn du den besten Knoten haben willst.

      Aber ansonsten ne schön einfach zu verstehende A* Implementierung. Aber weil ich angeben will hier ist meine https://github.com/Djeurissen/SmartAI/blob/master/SmartAI/Search/AStarSearch.cs

    2. Life Is Good

      Life Is Good

      Klar ! Es kann nie sauber genug sein :)

      Dabei hab ich mir ehrlich gesagt nichts besonderes gedacht, einfach so simple wie möglich gehalten.
      Eigentlich hätte ich start & ende auch einfach public machen können, um die dann über den Inspector zu zuweisen.

      Zum Speicher:
      Absolut. Ich halt meistens bloß so viel wie möglich lokal. Wenn man daraus was größeres machen würde, könnte man allein dadurch noch gut was an Performance rausholen.

      Dein Code gefällt mir übrigens auch gut.

    3. Kuxii

      Kuxii

      Muss ich doch Glatt mal Testen, Suche schon lange was gescheites^^ Meine versuche Schlugen leider fehl und ergaben das die KI 6754374 meter neben den Pfad rumm eierte^^

  9. Unity 2017 und .NET 4.6

    Hmpf. Ich versteh nicht ganz warum du das jetzt schreibst. Kann man das als zusammenfassen und interpretieren ? Wenn du einen Thread entlasten willst hast du bloß 2 Möglichkeiten (so funktionieren CPUs nunmal) entweder du verteilst die Arbeit über mehr Zeit (So wie Coroutinen) oder du lagerst sie auf seperate Threads aus. Da steckt keine dunkle Magie hinter asynchroner Programmierung. (Dass die Heinzelmännchen kommen, wenn du die Keywords async und await nutzt ist bloß ein Mythos ) Was du hier als "blockieren" bezeichnest ist halt die Art, wie unsere Prozessoren funktionieren. Await auf dem selben Thread macht da nichts anderes, siehe oben. Hier bin ich mal pingelig. Unity Tech arbeitet gerade an einem Entity-Component System. Entity System != Entity Component System; außerdem: Entity Component Model (oft einfach Entity Component, EC) != Entity System und Entity Component != Entity Component System (ECS) Jein. Dass Daten & Logik (Behaviour) voneinander getrennt werden ist schon DoD mäßig, das ist richtig. Aber ein ECS schließt im Grunde DoD aus. Siehe https://en.wikipedia.org/wiki/Data-oriented_design Denn 1. ist DoD das genaue Gegenteil von sowas wie ECS, EC, MVC etc. Bei DoD folgst du keinen strengen Paradigmen, und keinem festen Design Plan. 2. ist vieles am ECS (variiert natürlich je nach Implementation) ziemlich anti DoD. Beispiel: Eine super Klasse wie Unity's Object Klasse. Alle Objekte (ob GameObject oder Komponenten) erben von Object. In DoD hast du sowas nicht, weil es Datenmüll und Abhängigkeit produziert. (DoD ist vorallem auf high performance ausgerichtet, wie man dem Namen wohl entnehmen kann.) Manchmal allokiert man absichtlich überflüssigen Speicher, aber das ist ein anderes Thema. Zu deinen anderen Texten: Ich verstehe Englisch recht gut, danke Darauf wollte ich nicht hinaus. Sondern, dass du 2, statt einem Objekt hast, was wieder ziemlich anti DoD ist. Vorallem aber macht es den Code komplexer. Wie gesagt, ECS ist (zumindest aktuell) auch nicht wirklich verbreitet. Ein guter link noch http://gamedevs.org/uploads/pitfalls-of-object-oriented-programming.pdf
  10. Unity 2017 und .NET 4.6

    Das stimmt, aber async wurde vorallem implementiert, um Arbeit im Hintergrund durchzuführen. Genau das, wofür du Unity da anprangerst, hast du oben ja selbst ebenfalls als asynchron bezeichnet. Mehr machen Unity's Coroutinen überhaupt nicht. Das ist im Grunde bloß ein automatisierter Iterator. Das sieht in etwa so aus: private IEnumerator myCoroutine; private void Update { if (CoroutineIsReady) myCoroutine.MoveNext(); } Dabei wird der Main Thread nicht blockiert. Denn (wenn man's richtig macht) arbeitet man ja immer bloß ein Stück ab, und geht dann zum nächsten Stück (MoveNext) sobald man bereit ist. Das klingt zumindest auch halbwegs vernünftig, angesichts der Tatsache, dass Unity aktuell ein Entity-Component Modell implementiert (was im Allgemeinen nicht auf parallele Strukturen ausgerichtet ist !!) P.S. Auch moderne Spiele sind zum überwiegenden Teil immer noch kaum gemultithreaded. (Außnahme: Konsolen Spiele) Zu deinem ECS Hype: Es gibt aus gutem Grund kaum eine Engine / ein Spiel das derzeit auf ein Entity Component System setzt (ein Beispiel ist allerdings die Overwatch Engine.), viele andere Großproduktionen nutzen ein EC Model (Unity, Unreal, ...) oder entwickeln ihr Spiel ohne feste Architektur (Data oriented design) Der Grund ist ganz einfach, dass ein ECS zum einen deutlich die Komplexität deines Codes steigert und zum anderen ist es nicht so Cache freundlich wie DoD. (allerdings freundlicher als ein EC Model.) Du hast's ja im Video gesehen, plötzlich kommen auf alle Komponenten 2 Klassen / Strukturen (Logik / Daten seperat; Also: mehr Speicherbedarf wenn wir doch schon zählen was wir alles im RAM haben )
  11. Unreal Engine 4 Grafik besser?

    Ich würde noch hinzufügen, dass beim hinzufügen eines Post Processing Volume in UE direkt passende Post Processing Effekte mit schönen Standardwerten aktiv sind. Der überwiegende Teil der Unity Nutzer weiß nicht wirklich wofür welcher Effekt überhaupt da ist. Tonemapping beispielsweise ist einer der am häufigsten falsch verwendeten Effekte. Bei Außenszenen punktet UE durch ein viel aktuelleres Terrain System. Davon abgesehen erwähne ich noch mal, was viele überhaupt nicht wissen: Unity & UE benutzen die selbe Lösung für realtime Lighting (Enlighten)
  12. C# - Be smart [Tipp and Tricks]

    Gekürzt //... using System.Linq; //... [SerializeField] private GameObject[] gameObjects; //... gameObjects.ToList().ForEach(go => { if (go.activeSelf) go.SetActive(false); }); //...
  13. ScreenShot Weekend! (ehemals ScreenShot Saturday)

    Im Build hab ich noch nichts getestet. Und nein. Der Algorithmus ist auf ein normales Grid ausgelegt, so einfach lässt sich das nicht durch NavMesh o.ä. ersetzen. Ich plane aber sowas wie ein LOD System für's Raster zu schreiben, damit die Pathfinding Lösung natürlich auch im größeren Maß einsetzbar ist.
  14. ScreenShot Weekend! (ehemals ScreenShot Saturday)

    Zum einen hab ich alles was mit Linq zu tun hat rausgeschmissen. Wenn man so wahnsinnig oft diese Aufrufe machen muss kann man da ganz schön viel sparen. Zum anderen hab ich den Algorithmus selbst ein wenig optimiert. Zuletzt (was auch ziemlich bemerkenswert ist) hab ich den Code einfach aus Unity raus- und in eine seperate DLL reingeschmissen. Allein das war noch mal eine Leistungssteigerung von ~25% Das kann ich nur empfehlen, wenn man ein kritisches Stück an Code hat. Macht es gleichzeitig auch noch einfacher das Zeug außerhalb von Unity weiter zuverwenden.
  15. ScreenShot Weekend! (ehemals ScreenShot Saturday)

    Ich hab die letzten Tage den Code meiner CC Implementation ein wenig optimiert. Das selbe Szenario läuft jetzt mit 40-50 fps, statt, wie zu vor, mit 6-8 fps
×