Jump to content
Unity Insider Forum

1000 of NPC's


MustafGames

Recommended Posts

Hallo,

 

mein Thema Heute ist, ob es mir Unity möglich ist 1000 von sich frei bewegenden NPC's zu machen?

Damit meine ich z.B. ein Schlachtfeld wo dann diese NPC's sich jeweils den nächsten Gegner suchen, diesen angreifen und immer so weiter. 500 gegen 500.

 

Sollte man dafür den NavMeshAgent nutzen, kann dieser das schaffen?

Welche Tipps habt ihr den, dass würde mich sehr interessieren?

 

Mfg Mustaf

Link zu diesem Kommentar
Auf anderen Seiten teilen

Unity wird dich in keiner Weise daran hindern.

 

NavMeshs sind dafür aber im Allgemeinen nicht gedacht.

Was du suchst sind z.B. Algorithmen wie Continuum Crowds http://grail.cs.washington.edu/projects/crowd-flows/78-treuille.pdf

Sowas zu implementieren wird aber nicht in ein paar Tagen klappen, wenn man sich mit der Materie nicht auskennt ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also ich habe 200vs200 ohne besondere Algorithmen zum laufen bekommen mit NavMesh, für den nähestenden Gegner nehme ich allerdings nicht das normale Vector3.Distance, außerdem läuft der Code für die AI nur aller 1 Sekunde bis 2 Sekunden und ich habe einige Optimierungen vorgenommen, außerdem solltest du versuchen ein Modell mit möglichst wenig Drawcalls zu nehmen, da die von den Charaktergeneratoren meistens sehr viele Drawcalls haben und keine LODS

 

Meine CPU Nutzung ist 40% bei 8x3,4GHZ für 400xAI

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ja ein Problem wird wahrscheinlich nicht Unity selbst sein, sondern eben einen Optimierten Algorythmus zu entwickeln, der diese Aufgabe problemlos bewältigen kann. Dafür würden Sich Coroutines zum Updaten der KI die dann immer den nächsten Gegner findet eigentlich reichen. Dafür würde ich keine NavMesh's verwenden

Link zu diesem Kommentar
Auf anderen Seiten teilen

Zitat
Also ich habe 200vs200 ohne besondere Algorithmen zum laufen bekommen mit NavMesh

Ein Mengenverhalten weisen die ja beispielsweise nicht auf. Das erkennt man schnell daran dass die alle gegeneinander laufen sobald die vordere Reihe stehen bliebt oder jemand das Ziel wechselt.

 

Wenn das einem reicht, dann spricht natürlich überhaupt nichts dagegen das auf diese Weise zu lösen.

 

Genügt das einem aber nicht, und man will, dass die KI sich beispielsweise auch untereinander erkennen kann, dann sind NavMesh's eher ungeeignet. Einfach weil der Gedanke dahinter eigentlich ein statisches Feld ist, das sich nicht ändert.

Das hat man mit crowd behaviour ja nicht mehr gegeben.

Unity's NavMeshObstacles sind da auch nur mehr sowas wie ein hotfix.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wir arbeiten auch gerade an einer KI Lösung für unser RPG "Twin Destiny". Eigentlich keine "Mass Crowds"-Lösung, aber wenn man eine Stadt mit Einwohnern bevölkern möchte, dann laufen auch schon mal so an die 100 NPCs umher. Unser (KI-)Programmierer arbeitet auch an einer Variante mit der Navmesh-Komponente. Einige Sachen wie LODs und reduzierte Zeitsteps bei den KI-Berechnungen haben wir dabei auch schon bedacht. Eine interessantes Asset ist auch ein Asset welches Animationen "baked" und man somit ohne Animationen und dem Animationcontroller von Unity auskommt, was wiederum enorm Performance einspart. Leider arbeite ich aktuell nicht selbst an der Komponente, aber es würde mich sehr interessieren, wie Sachen von anderen Leuten gelöst wurden. Vielleicht kann man sich hierbei auch einmal austauschen.

 

@QuesterDesura

Ist die Bewegung deiner NPCs Animations- oder Navmeshagent-getrieben?

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 1 month later...

Naja, wie es scheint ist es zwar mit "Unity" gemacht, aber sämtliche Komponenten sind Marke Eigenbau. Bei den Shadern angefangen, ich denke kein Unity Pfadsystem, kein Unity Animator etc. verwendet und alles extrem auf Leistung getrimmt, also KI auf 4 Kerne verteilt (Unity ist ja bislang nur auf einem Kern unterwegs) und vermutlich selbst Hintergrundroutinen in die GPU verlagert.

Aber nochmal zurück zum Thema:

- Low Poly Meshes verwenden (und möglichst nur 1 Material), ggf. nicht den Unity Standardshader verwenden (zu langsam)

- dieses Asset verwenden, es umgeht den Unity Animator und spart so extrem viel Rechenzeit: 
https://www.assetstore.unity3d.com/en/#!/content/26009

- kein Unity Navmesh fürs Pathfinding verwenden (leider kenne ich hier noch kein gutes Asset für Mass Crowds, so ein Asset sollte mit einem gebackenden Terrain, Multithreading und zuschaltbaren GPU Routinen arbeiten)
- KI Routinen in "echte" gethreadete Koroutinen auslagern:
https://www.assetstore.unity3d.com/en/#!/content/15717
- KI Routinen (Skripte) hängen nicht mehr an den AI-Gameobjekts, sondern durchlaufen alle existierenden KI-Einheiten (spart wieder einiges an CPU Rechenzeit)

Wenn du mal ein Ergebnis hast, wie viele Einheiten du damit schaffst, gib mir mal bescheid ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Warum optimiert Unity den nicht ihren Animator anhand des Assets?

Was bedeutet das genau? (KI Routinen in "echte" gethreadete Koroutinen auslagern)

und das (KI Routinen (Skripte) hängen nicht mehr an den AI-Gameobjekts)

soll das zweite heißen das jede Figur ihren eigenen Script hat oder das 1 Objekt (KI-Manager z.b.) alles berechnet?

 

Danke

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Damit meint er, dass Unity's Coroutinen im Main Thread, also bloß auf einem Kern laufen.

Die GPU wirst du aber im Normalfall für Pathfinding nicht brauchen.

Bei Algorithmen wie Continuum Crowds ist es aber so (höchstwahrscheinlich auch in der Lösung aus dem Video) dass die einzelnen "KIs" nicht mehr einzelne Akteure sind, sondern als Menge betrachtet werden. D.h. das beispielsweise alle Mitglieder deiner Menge sich mit der selben Geschwindigkeit fortbewegen und kein individuelles Verhalten aufweisen. (danach siehts im Video auch aus)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ja, genau wie Life sagt, Unitys Koroutinen laufen derzeit auf dem gleichen CPU-Kern wie Unity selbst.

Bei der GPU Verwendung bin ich mir nicht sicher, die Stärke von GPUs ist es schon 1000de von kleinen Berechnungen durchzuführen, was für eine große Menge an KI-Einheiten schon nicht verkehrt wäre, es kommt aber eben auch auf die aktuelle Auslastung der GPU an...
Wenn man allerdings den Weg geht, die KIs zu clustern - wie Life sagt -, dann braucht man es wieder weniger.

Je mehr Gameobjekts sich in der Szene befinden und an jeden Gameobjekt ein Skript hängt, desto mehr Rechenzeit wird allein dadurch "verbraten", daß Unity die einzelnen Objekte durchlaufen und ansteuern muss (inklusive dem Durchlaufen der angehängten Skripte). Wenn man allerdings ein einzelnes Kontrollerskript verwendet,, welches die Objekte in der Szene selbst durchläuft und dann Aktionen auf diesen Objekten ausführt spart wiederum einiges an Rechenzeit. Dieser Effekt wird umso grösser, je mehr Objekte sich in der Szene befinden.

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...