Jump to content
Unity Insider Forum

Zer0Cool

Members
  • Gesamte Inhalte

    2.040
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    145

Profilantworten erstellt von Zer0Cool

  1. So, ich habe mal ein kleines Video erstellt, in welchem man den selbst erstellten Test-Charakter sehen kann und das Unity-Terrain an dem ich gerade arbeite. Das Terrain ist noch komplett ohne Details, d.h. Bäume, Gräser, Steine etc. müssen ich noch ergänzt werden:
    https://streamable.com/bf8ua

  2. So, ich habe mal ein kleines Video erstellt, in welchem man den selbst erstellten Test-Charakter sehen kann und das Unity-Terrain an dem ich gerade arbeite. Das Terrain ist noch komplett ohne Details, d.h. Bäume, Gräser, Steine etc. müssen ich noch ergänzt werden:
    https://streamable.com/bf8ua

  3. Sag mal, Gibt es eigentlich etwas was du nicht über/von Unity Weißt? :D

  4. Ich bin mal ein wenig durch meinen Code gesprungen. An einer Stelle muss ich sehr häufig über eine kleine Anzahl an Elementen iterieren

    Foo target;
    for (int i = 0; i < 4; i++)
      if (collection[i].flags == fooFlag)
      	target = collection[i];

    Ein ganz simples Stück Code also.
    Linq sieht aber natürlich sehr viel hübscher aus, also hab ich statt des Oberen Schnipsels zu erst so was hier gemacht
     

    var target = collection.First(e => e.flags == fooFlag);

    Was ich beobachtet habe: Das 2. ist halb so schnell. Das sind 20ms, statt 10ms (wird jeden Frame aufgerufen,  d.h. zweiteres erfüllt schonmal gar nicht mehr die 60hz Anforderung, was ja heute ziemlich standard ist.... Macht also viel aus !)

    1. Zer0Cool

      Zer0Cool

      Na, das Problem existiert zumindest seit Version 5.4.1. Ich muss es mal in Unity 2017 nochmal testen, aber glaube nicht, daß an der Ecke was passiert ist:
      https://feedback.unity3d.com/suggestions/navmesh-agent-local-avoidance-recalculate-navmesh-path-when-another-agent-get-in-the-way

      Wenn man mit einer handvoll Agenten hantiert, merkt man das Problem noch nicht unbedingt, da die local avoidance auf sehr kurzen "Ausweichpfaden" noch funktioniert (also wenn nur 2 Agenten aneinander vorbeilaufen sollen).
      Ein typischer Testfall ist, du lässt 20 Agenten zu einen Ziel laufen (z.b. Spieler). Beim Unitynavmesh klumpen die Agents dann an einer Stelle vor dem Spieler (aus Laufrichtung) zusammen (und stapeln sich teilweise hintereinander auf). Eigentlich sollten aber die Agents den Spieler einkreisen. Gibt auch noch andere Probleme an engen Stellen auf dem Navmesh, wenn sich die Agents "treffen".

    2. (See 12 other replies to this status update)

  5. Ich bin mal ein wenig durch meinen Code gesprungen. An einer Stelle muss ich sehr häufig über eine kleine Anzahl an Elementen iterieren

    Foo target;
    for (int i = 0; i < 4; i++)
      if (collection[i].flags == fooFlag)
      	target = collection[i];

    Ein ganz simples Stück Code also.
    Linq sieht aber natürlich sehr viel hübscher aus, also hab ich statt des Oberen Schnipsels zu erst so was hier gemacht
     

    var target = collection.First(e => e.flags == fooFlag);

    Was ich beobachtet habe: Das 2. ist halb so schnell. Das sind 20ms, statt 10ms (wird jeden Frame aufgerufen,  d.h. zweiteres erfüllt schonmal gar nicht mehr die 60hz Anforderung, was ja heute ziemlich standard ist.... Macht also viel aus !)

    1. Zer0Cool

      Zer0Cool

      Zitat

      Die Fläche, die von einem anderen Agenten besetzt wird, einfach rauszuschneiden ist also eine recht naheligende Idee.

      Und genau das machen sie eben nicht. Es läuft ein sehr schlechter "local avoidance"-Algorithmus zwischen den Agenten und der aktuelle A*-Path wird dabei nicht neu berechnet, d.h. blockiert ein anderer Agent den Weg, dann bleibt der Agent einfach stehen. Aber du hast schon recht der A*Path ist wohl ungeeignet für viele dynamische Änderungen und daher nicht für eine dynamische Kollisionsvermeidung geeignet.

    2. (See 12 other replies to this status update)

  6. Ich bin mal ein wenig durch meinen Code gesprungen. An einer Stelle muss ich sehr häufig über eine kleine Anzahl an Elementen iterieren

    Foo target;
    for (int i = 0; i < 4; i++)
      if (collection[i].flags == fooFlag)
      	target = collection[i];

    Ein ganz simples Stück Code also.
    Linq sieht aber natürlich sehr viel hübscher aus, also hab ich statt des Oberen Schnipsels zu erst so was hier gemacht
     

    var target = collection.First(e => e.flags == fooFlag);

    Was ich beobachtet habe: Das 2. ist halb so schnell. Das sind 20ms, statt 10ms (wird jeden Frame aufgerufen,  d.h. zweiteres erfüllt schonmal gar nicht mehr die 60hz Anforderung, was ja heute ziemlich standard ist.... Macht also viel aus !)

    1. Zer0Cool

      Zer0Cool

      Ich habe ja das Gefühl, das Unity beim Trennen des Navmesh-Algos in einen statischen Part (Navmesh + Obstacles) und einen dynamischen Part (local avoidance zwischen agents) einen Fehler gemacht hat. Ich kann mir nicht vorstellen, daß man beides nicht auch intelligenter kombinieren kann. Ich vermute mal Unity wollte damit Performance einsparen und einen Pfad nicht neu berechnen, nur weil ein Agent im Weg steht.

    2. (See 12 other replies to this status update)

  7. Ich bin mal ein wenig durch meinen Code gesprungen. An einer Stelle muss ich sehr häufig über eine kleine Anzahl an Elementen iterieren

    Foo target;
    for (int i = 0; i < 4; i++)
      if (collection[i].flags == fooFlag)
      	target = collection[i];

    Ein ganz simples Stück Code also.
    Linq sieht aber natürlich sehr viel hübscher aus, also hab ich statt des Oberen Schnipsels zu erst so was hier gemacht
     

    var target = collection.First(e => e.flags == fooFlag);

    Was ich beobachtet habe: Das 2. ist halb so schnell. Das sind 20ms, statt 10ms (wird jeden Frame aufgerufen,  d.h. zweiteres erfüllt schonmal gar nicht mehr die 60hz Anforderung, was ja heute ziemlich standard ist.... Macht also viel aus !)

    1. Zer0Cool

      Zer0Cool

      Ich hatte mich letztens mit Metaballs und deren Berechnung in Echtzeit beschäftigt und hatte ganz ähnliche Performanceprobleme. Trotz intensiver Nutzung der GPU war der Berechungsaufwand einfach zu massiv. Mal ein paar Zahlen dazu. Die GPU musste für eine Auflösung von 1000x1000 und 20 Metaballs folgende Anzahl von Berechnungen durchführen:
      1000x1000x20x30

      Die Methode war eine Berechnung der Metaballs im Screenspace. Dabei steht die 20 für die Anzahl der Metaballs und die 30 für die Anzahl an Iterationen bis der Punkt der Metaballoberfläche auf dem Isosurface getroffen wurde. Bei ca. 10-30 Metaballs war die FPS noch im Rahmen, bei Werten >50 schlug der ganze Algorithmus gefühlt exponentiell um und die Framerate brach extem ein. Mit anderen Worten, ich musste feststellen, die Funktion für die Berechnung der Metaballs ist völlig ungeeignet für eine größere Menge von Metaballs. Hintergrund, ich wollte ca. 100 Metaballs als Partikelsystem darstellen. Wie man aus den obigen Zahlen auch erkennen kann, bei ca. 600 einfachen Berechnungen pro "GPU Thread" ist die Grenze des Machbaren auch bei der GPU erreicht.

      Klar man könnte jetzt sagen, wir verwenden einen Marching Cubes Algo und versuchen die 1000x1000 zu reduzieren, aber auch dies kostet wieder Berechungszeit, die mit der Menge an Metaballs wiederum zunimmt. 
      Als Beispiel, wenn man die Szene in Cubes (Basis für diesen Algo) aufteilt mit einer Auflösung von 100 pro Meter, dann hat man bei einer Szene mit 20x20 Metern:
      20x20x100x100 = 4 Mio Cubes 

      Jetzt muss noch der MC-Algo immer noch seine Arbeit leisten aber er hantiert bereits mit 4 Mio Cubes, d.h. Berechnungseinheiten.
      Im Beispiel der Screenspacemethode waren es aber nur:
      1000x1000 = 1 Mio

      Man sieht also, man tauscht irgendwie nur ein Problem gegen ein anders.
      Vermutlich könnte man über einen extrem optimierten Marching Cubes Algo und einem Mesh der über die GPU berechnet (Computeshader) wird das Problem noch halbwegs in den Griff bekommen, aber das war mir dann wiederum zu viel Aufwand. Es hatte sich bereits jemand anders daran probiert und die Performance war grausig. Ich denke der MCA war schlecht umgesetzt und die Berechnungen auf der GPU waren ebenfalls schlecht umgesetzt.

    2. (See 12 other replies to this status update)

  8. Ich bin mal ein wenig durch meinen Code gesprungen. An einer Stelle muss ich sehr häufig über eine kleine Anzahl an Elementen iterieren

    Foo target;
    for (int i = 0; i < 4; i++)
      if (collection[i].flags == fooFlag)
      	target = collection[i];

    Ein ganz simples Stück Code also.
    Linq sieht aber natürlich sehr viel hübscher aus, also hab ich statt des Oberen Schnipsels zu erst so was hier gemacht
     

    var target = collection.First(e => e.flags == fooFlag);

    Was ich beobachtet habe: Das 2. ist halb so schnell. Das sind 20ms, statt 10ms (wird jeden Frame aufgerufen,  d.h. zweiteres erfüllt schonmal gar nicht mehr die 60hz Anforderung, was ja heute ziemlich standard ist.... Macht also viel aus !)

    1. Zer0Cool

      Zer0Cool

      Ich kenne Linq nicht wirklich, aber höhere Programmiersprachen tendieren dazu, daß sie langsamer sind als Sprachen eines geringeren Levels. Und wenn ich das richtig lese, setzt Linq auf C# bzw. auf .NET auf und kann somit theoretisch eine solche Abfrage verkomplizieren (also nach dem Compilieren). Für maximale Performance würde ich also immer zu den Sprachen greifen, die näher am Assemblercode sind (Linq > C# > C > AC).

      PS:
      Du hattest doch an einer Massive Crowd Lösung gearbeitet? 
      Unity Navmesh regt mich immer noch auf, da die local avoidance zwischen den Agents nicht wirklich funktioniert. Das "A* Pathfinding Project" hat zwar eine gute Lösung, aber nur für die Proversion. Eigentlich bräuchte man eine Lösung für den Unitynavmesh. Mittlerweile haben sie den Unitynavmesh ja auch weiter geöffnet, man kann nun ja auch Navmeshs zur Laufzeit ändern. Eine Kopplung einer Pathfindung-Lösung mit dem Unitynavmesh wäre also ideal.

    2. (See 12 other replies to this status update)

  9. Die Wahrheit über Indie Game Entwickler :lol:https://goo.gl/2KeqLD

  10. hm gibt es eine Alternative zur Update Methode die vllt nur alle 20 Frames aufgerufen wird?

  11. Klassiker, aber immer wieder total witzig :D

     

  12. Hab habe gerade eine Routine geschrieben, die überprüft, in wieweit ein Collider einen anderen Collider eindringt. Unity bietet hier leider keine Standardlösung. Ich benötige diese Information um festzustellen, wie weit ein Schild-Item eines Spielers in einen anderen Collider (z.b. Capsulecollider eines Feindes) eindringt. Über die bestimmte Durchdringungstiefe wird dann bestimmt, wie weit der Spieler sich wieder vom Feind entfernen muss, damit sein Schild nicht mehr in das Mesh des Gegners clippt.
    BVBbwIE.png

    1. Zer0Cool

      Zer0Cool

      So hier mal die Routine in Aktion. Sobald das Schild des Charakters in den Gegner hineinclipped, fängt der Spieler an automatisch so auszuweichen, bis der korrekte Abstand wieder hergestellt ist und das Schild wieder vor dem Collider des Gegner positioniert ist. Dies ist notwendig, damit der Spieler mit dem Schild ordentlich blocken kann und der Gegner nicht hinter das Schild schlägt:
      https://streamable.com/ukka2

    2. (See 9 other replies to this status update)

  13. Hab habe gerade eine Routine geschrieben, die überprüft, in wieweit ein Collider einen anderen Collider eindringt. Unity bietet hier leider keine Standardlösung. Ich benötige diese Information um festzustellen, wie weit ein Schild-Item eines Spielers in einen anderen Collider (z.b. Capsulecollider eines Feindes) eindringt. Über die bestimmte Durchdringungstiefe wird dann bestimmt, wie weit der Spieler sich wieder vom Feind entfernen muss, damit sein Schild nicht mehr in das Mesh des Gegners clippt.
    BVBbwIE.png

    1. Zer0Cool

      Zer0Cool

      @JohnnyCash Diese Kontaktpunkte habe ich für die Berechnung schon mit einbezogen, sie  sind aber nur ein Teil der Lösung. Diese Kontaktpunkte sitzen zumeist nur auf der Oberfläche des eintretenden Kolliders, du weißt dann aber immer noch nichts über die genaue Position (Durchdringungstiefe) in Bezug auf den Kollisionspartner. Du kannst die Kontaktpunkte oben im Bild als rote Kugeln sehen (außer die Kugel von der die weiße Line ausgeht, diese ist berechnet)

    2. (See 9 other replies to this status update)

  14. Hab habe gerade eine Routine geschrieben, die überprüft, in wieweit ein Collider einen anderen Collider eindringt. Unity bietet hier leider keine Standardlösung. Ich benötige diese Information um festzustellen, wie weit ein Schild-Item eines Spielers in einen anderen Collider (z.b. Capsulecollider eines Feindes) eindringt. Über die bestimmte Durchdringungstiefe wird dann bestimmt, wie weit der Spieler sich wieder vom Feind entfernen muss, damit sein Schild nicht mehr in das Mesh des Gegners clippt.
    BVBbwIE.png

  15. Hab habe gerade eine Routine geschrieben, die überprüft, in wieweit ein Collider einen anderen Collider eindringt. Unity bietet hier leider keine Standardlösung. Ich benötige diese Information um festzustellen, wie weit ein Schild-Item eines Spielers in einen anderen Collider (z.b. Capsulecollider eines Feindes) eindringt. Über die bestimmte Durchdringungstiefe wird dann bestimmt, wie weit der Spieler sich wieder vom Feind entfernen muss, damit sein Schild nicht mehr in das Mesh des Gegners clippt.
    BVBbwIE.png

    1. Zer0Cool

      Zer0Cool

      "Raycast" war schlecht formuliert von mir. Es ist kein Raycast der Physikengine gegen die Innenwand des Colliders, sondern es ist eine Methode der Boundingbox des Colliders und diese benötigt einen "Ray" (ist einfach nur eine Klasse) die wohl dann intern damit das Ergebnis "berechnet".

    2. (See 9 other replies to this status update)

  16. Hab habe gerade eine Routine geschrieben, die überprüft, in wieweit ein Collider einen anderen Collider eindringt. Unity bietet hier leider keine Standardlösung. Ich benötige diese Information um festzustellen, wie weit ein Schild-Item eines Spielers in einen anderen Collider (z.b. Capsulecollider eines Feindes) eindringt. Über die bestimmte Durchdringungstiefe wird dann bestimmt, wie weit der Spieler sich wieder vom Feind entfernen muss, damit sein Schild nicht mehr in das Mesh des Gegners clippt.
    BVBbwIE.png

    1. Zer0Cool

      Zer0Cool

      Es startet mit der "OnCollisionStay"-Methode. Über diese erhalte ich ja sämtliche Kontaktpunkte der Kollision. Nun bilde ich aus allen Kollisionskontaktpunkten den "Mittelwert", also ein Punkt der zwischen alles Kontaktpunkten liegt. Auf dem BIld oben siehst du die Kontaktpunkte als rote Kugeln und den Mittelwert ebenfalls als rote Kugel (es ist die Kugel aus der die weiße Linie herauskommt)
      Nun würde man normalerweise versuchen einen Ray vom Inneren des Kollisionspartners zu senden, um die Entfernung zur Innenwand des Colliders zu bestimmen, daß geht aber nicht, da ein Ray ein Collider von innen nicht erkennt.
      Zum Glück gibt es aber eine Funktion, die diese Aufgabe für uns erfüllt namens "IntersectRay". Diese Methode ist eine Methode der Bounding Box des Colliders. Dieser Methode übergibt man nun einen Ray der in die negative RIchtung der Kontaktpunktnormalen zeigt (hier habe ich einfach den 1. Kontaktpunkt genommen). Diese Methode liefert nun die Entfernung vom Mittelwertpunkt bis zum Rand der Bounding Box the Colliders (híer ein Capsulecollider). Im obigen Bild ist die Entfernung 0.17.

    2. (See 9 other replies to this status update)

  17. Moin - ist das erste bild bei euch anderen auch zu dunkel oder wie sieht das aus ? Dazu im vergleich ein anderes angepasstes:

    testpicafterautocontrnqu11.png

    lonelyworld.png

    1. Zer0Cool

      Zer0Cool

      Ich sehe gerade es gibt beim Monitor theoretisch ein Gamma-Setting aber das ist ausgegraut (also hier kann man nix verstellen).

    2. (See 6 other replies to this status update)

  18. Moin - ist das erste bild bei euch anderen auch zu dunkel oder wie sieht das aus ? Dazu im vergleich ein anderes angepasstes:

    testpicafterautocontrnqu11.png

    lonelyworld.png

    1. Zer0Cool

      Zer0Cool

      Ja, hat meiner auch, diesen z.B. diesen Gamemodus aber der ist aus, da wird alles extrem grell und hell. Ansonsten stehen die Einstellungen auf Mittel was Helligkeit und Kontrast betrifft. Aber am Monitor selbst kann man nur Helligkeit / Kontrast / Schärfe und die RGB-Känäle justieren. Einen Gammawert gibt es nur bei den Einstellungen der Grafikkarte und (vermutlich) dem Windowssystem selbst. Und es scheint ja am Gammawert zu liegen. Man kann das unter Windows mit dem Command-Tool DCCW machen oder wohl eben auch direkt über die Grafikkarte (da konnte ich ja selber den Gammawert von 1 auf 1.5 erhöhen).

    2. (See 6 other replies to this status update)

  19. Moin - ist das erste bild bei euch anderen auch zu dunkel oder wie sieht das aus ? Dazu im vergleich ein anderes angepasstes:

    testpicafterautocontrnqu11.png

    lonelyworld.png

  20. Moin - ist das erste bild bei euch anderen auch zu dunkel oder wie sieht das aus ? Dazu im vergleich ein anderes angepasstes:

    testpicafterautocontrnqu11.png

    lonelyworld.png

    1. Zer0Cool

      Zer0Cool

      Ich glaube es liegt bei mir zumindest teilweise an meinem Bildschirm / Grafikkarte. Hier ein super Bild um die Kalibrierung des Monitors zu testen. Bei mir liegen die Zahlen 1, 2, 3 und 4 im linken Bild komplett im dunkeln. Ich muss meinen Gammawert von 1 auf 1.5 hochschrauben, um alle Zahlen erkennen zu können (leider sieht dann mein Monitorbild extrem grausig aus, von daher lasse ich den Gammwert wie er ist). Aber ich denke es ist für jeden interessant, - zumindest zeitweise den korrekten Gammawert einzustellen - wenn man ein Lichtsetup in seinem Spiel vornimmt.

    2. (See 6 other replies to this status update)

  21. Neues Video von unserem RPG "Twin Destiny":

     

  22. Ich weiß nicht, wer sich in in letzter Zeit diesbezüglich umgesehen hat, aber Unity hat einen neuen Weg in Sachen Post Processing eingeschlagen. Wie auch bei Unreal zuvor gibt es jetzt Post Processing Chains als Assets, die in eine einzelne Komponente der Kamera gezogen werden, anstatt die Kamera mit Komponenten vollzuklatschen. https://www.assetstore.unity3d.com/en/#!/content/83912

×
×
  • Neu erstellen...