Problem mit Pathfinding.

[Noa3]

hi leute ich habe nen dickes problem :/

Ich breuchte eine art dynamisches pathfindig system das mit sehr grossen maps (6000x300x6000) klarkommt. dynamisch aus dem grund weil sich ständig objecte auf der map bewegen oder gar verschwinden/auftauchen.

hättet ihr ne idee was ich da bewerkstelligen kann?

für die normale mav mesh ist das zu gross da kommt ne meldung das irgendwann der ram voll sei(32gb). mit waypoints komme ich auch nicht weiter weil ihc nicht überprüfen lassen kann ob der weg dazwischen versperrt ist, oder doch?

[Sascha]

Ein so großes Grid willst du nicht erstellen. Bei so einer Mapgröße würdest du eher zu einem NavMesh greifen wollen - wenn du überhaupt das Teil als Gesamtsystem behalten willst, anstatt es aufzuteilen.

[Noa3]

Normlaerweise teile ich alles auch auf alleine wegen der performance und speicherverbrauch aber diesmal ist es nicht umungehbar.

ich werde die flächen mit weniger details bestücken und alles einfacher machen, hoffe das Unity mit den dann klar kommt.

 

derzeit ist der status so das ich zwar navMesh zwar erstellen kann aber beim testlauf das spiel sofort beim laden überfordert ist.

 

da merkt man das unity eher nur für kleine spiele geignet ist :/

ich frag mich wie sie das bei MGS:Ground Zero gelöst haben

[Mark]

Könntest du uns sagen oder Zeigen mit was für einer Umgebung wir es hier zu tun haben? Ein Navmesh was so groß ist um den Speicher vollzuballern klingt ziemlich "krass".

 

Könntest du uns dann auch die genauen Anforderungen nennen? Eventuell fällt uns gemeinsam eine Lösung ein.

[Noa3]

im grunde ist es eine (für die spielidee kleine) testmap:

 

fast jedes pathfinding programm macht bei der grösse allerdings schlapp(wegen ram) und dann kommt hinzu wenn dynamisch was auf der karte platziert wurde.

 

die spiele idee selber wollte ich nicht schreiben aber ich denke nicht das sich jetze irgendwer die arbeit macht und das nachbaut..

ich wollte eine art 3.Person/ Aufbau Spiel machen mit sehr vielen möglichkeiten. wo der spieler die möglichkeit hat seine eigne stadt aufzubauen und zum beispiel krieg gegen eine andere fraktion, mit seinen volk führen oder vileicht sich selber einer stadt anschliessen und verschiedene kleine aufgaben ausführen und nach und nach ein händler werden.

 

teile von scripten hab ich bereits fertig wie zb inventar system(wird nen baum gefält bekommt man holz usw..) oder das platzieren von gebeuden und deren verwaltung.

 

nun wollte ich mich an die NPCs wagen und brauch nen weg für deren pathfinding. danach das verhalten untereinander wird wieder was leichtes denke ich.

 

 

sry wegen rechtschreibfehler XD

[Mark]

Müssen es 6000x6000 Flächen sein (Ich nehme mal an die 300 die du noch angegeben hast ist nur eine Höhe)?

 

Würde es auch reichen nur 3000x3000 oder gar 2000x2000 zu haben? Ich meine nur fürs Pathfinding, der Rest kann ja so bleiben.

 

A* Grid Basefd Pathfinding ist im Grunde ganz gut bei sowas, ansonsten müsste man sich fragen ob die Agenten wirklich die ganze Karte kennen müssen. Wenn nicht dann könnte man die Karte per Mipmapping in gröbere Arealke unterteilen, der Agent würde dann einfach den Weg auf grober Ebene planen und wenn nötig auf eine begrenzte aber detailiertere Ebene fortführen.

[Schlumpf]

d.h. sie quasi erst mal auf der "autobahn" in das gebiet schicken und dann auf die bundesstraße und dann auf die straße im ort ?

[Mark]

So etwas in der Art machen Navigationsgeräte auch, könnte man wohl versuchen ja, oder ähnliches, ja.

[AgentCodeMonk]

Warum unterteilst du nicht in kleinere Terrains? Das ist ja ein ähnliches Konzept wie in den gängisten MMO´s... die sagen nämlich: was interessiert den Spieler das Monster am anderen Ende der Karte?! Vlt ist dir mehr geholfen, wenn du dein Terrain zerhackst und jedes Gebiet sich selbst verwaltet. (die können ja auch abgeschaltet werden, wenn man weiter weg ist... etc - Performance sparen und so) Ich meine man kann, man muss es nicht so machen... aber. Da so ein NPC ja auch nicht von einem Ende zum anderen der Welt rennen muss, können auch diese (spawnen etc) über einen Gebiets-Manager laufen... ...sry, hab nen Manager-tick;) hab ein ähnliches Sysem in Arbeit und das funktioniert ganz gut.

[Noa3]

300 ist die höhe ja.

für das bauen und die resourcen nutzung wird viel platz benötigt da ich versucht habe die produtions ketten so real wie möglich zu halten, und auch die häuser sind letzendlich nicht so klein sein das man sich reinstellt einmal dreht und kommplet durch ist.

 

das problem ist das die NPCs alle aufgaben übernehmen werden wie zb durch die ganze karte reisen um mit nen anderen zu handeln oder kurz mal zu der nächsten abbaustelle wegen arbeit verichten.

 

A* hab ich nur kenn gelernt das deren grid kommplet unflexiebel ist und statisch nur aufgebaut wird. ich denke es were ungünstig wenn ich dann genau vor nen npc der gerade wohin leuft nen haus vor die nase setze...

[Schlumpf]

d.h. quasi alles dem terrain unterordnen und deaktivieren inkl child's ?

[Mark]

Wäre nicht ungünstig, die Zellen wären belegt, wenn der NPC das mitbekommt berechnet er eben einen Umweg und ist dann weiterhin glücklich

 

Was mir da allgemein mehr sorgen macht ist die Performance, aber auch das ist lösbar.

 

Edit:

 

Die Navigationsgerät Idee von schlumpf ist hier sogar richtig brauchbar, es könnte Haupthandelsrouten geben und dann eben Nebenwege.

 

Oder du schaust dir mal Pathfinding per Potentialfields an, das klang in der Theorie recht nett.

[AgentCodeMonk]

So aus dem Bauch heraus mutest du dir da eine Menge zu ... Die Handelsroute ist wirklich ne gute Idee...Da kann man ruhig den NPC, zumindest das Mesh und sonstige Performancefresser abschalten (mal 100 Skinned Meshes in Viewport + AIScripte und allem anderen drum und drann...die können schon an der Leistung zergen) und nur die Position berechnen.

Wenn dann der Spieler wieder in der Nähe ist, Umbebung aktivieren, NPC Mesh wieder aktivieren oder spawnen, je nachdem wie man es machen will. Aber der NPC selber muss während kein Spieler in der Nähe ist auch nicht irgendwo mitgerendert werden. Sein virtueller "Alltag" kann ja weiterhin berechnet werden.

Deine Produktionskette muss ja nicht erst dann funktionieren, wenn wirklich ein NPC durch die Gegend läuft. Du kennst doch den Weg (Handelsrouten zb - dh. der Weg lässt sich ja berechnen), die NPC-Geschwindigkeit und wieviel Ressourcen der NPC pro Zeiteinheit am Ziel umsetzt... damit kannst du ja arbeiten und das sollte nicht zuviel Resourcen kosten (ich gehe mal davon aus, dass du keine 10000 NPCs hast). Natürlich kannst du dann Events einbauen wie zB. einen Angriff eines Tieres auf den NPC und diese solange einfach berechnen, bis wirklich ein Spieler diesen Kampf sehen könnte... etc pp...aber sowas später;)

Der NPC selber, besser gesagt das Mesh, kann dann aktiviert und gerendert werden, damit im richtigen Moment alles schick aussieht (Wenn der Spieler da ist Alles andere könnte dann ein GlobalRessourcesManager berechnen ...oder wie auch immer du den nennen willst. Ich hab zwar ein solches System noch nie gebaut und einiges könnte durchaus Quatsch sein, aber das wäre das mir spontan einfällt. Vlt bringt es dich ja auf eine Idee...

 

@schlumpf naja unterordnen vlt... ich dachte mehr daran, dass eine Art AreaManager alles an und ausschaltet. Alles unterordnen und abschalten halte ich für ne Holzhammermethode...aber legitim:)

[Schlumpf]

ehrlich : ordne es unter und lass es laufen bis es stabiel rennt

 

dann mach den manager

[AgentCodeMonk]

[Noa3]

der aktuelle stand ist nun das ich nen einzelnen terrian benutze was 4000x4000 gross ist und ne einfache fläche ist.

da kam nach ner navmesch berechnung das raus:

 

7,7 mb noch und unity gibt sein geist typischerweise auf :/ .

ich bin kurz vor dem aufgeben wegen sowas >.<....

[Mark]

Dann verzichte doch auf das Navmesh und nutze andere Lösungen, ist ja nicht so als ob diese hier im Thread schon mehrfach erwähnt wurden

[Schlumpf]

bei mir gings ohne probleme

 

 

Marrrk

 

welche lösung würdest du vorschlagen ?

am sinnigsten ist ja schon fast was selber zu machen weil a* naja ich weis nich

NavGrid.rar

[Mark]

Was spricht denn gegen A*?

 

Zuerst würde ich analysieren wieso es überhaupt ein solch großes Problem mit dem Navgrid gibt, ich glaube das Navgrid würde keine Probleme machen wenn nicht das ganze Terrain als Geometrie herhalten müsste, daher würde ich folgendes empfehlen:

 

Die verdammte Geometrie für das Navmesh versimpeln, man nehme einen berg den ich problemlos besteigen kann, wieso also muss für der Berg als 1:1 gemetrie beim navmesh erscheinen, das Navmesh muss den berg nur berücksichtigen wenn er nicht begehbar ist, ansonsten reicht da als Meshrepräsentation auch eine Flache ebene aus.

 

Hier muss ich aber zugeben dass ich weiß wie navMeshs funktionieren aber nicht wie Navmeshs in Unity funktionieren. Aber mal kurz zusammengefasst was ich meine, das Navmesh sollte so aussehen:

 

Und nicht so:

 

Ich hoffe man erkennt was ich meine.

 

Wenn das Navmesh dafür komplett ungeeignet ist, was ich nicht ganz glaube, dann gibts immer noch andere Wege, bei denen müsste man sich aber erstmal die Vor und Nachteile heraussuchen, aber bis es noptwendig ist und Navmeshs von unity sich als absolut unbrauchbar erwiesen haben, lassen wir das vorerst mal lieber

 

Kleine Idee zur Lösung des Problems: Eine Kopie des terrains erstellen mit niedriger Auflösung, dafür das Navmesh generieren und es f+ür das Highres Terrain verwenden, da wo evtl wege keinen Sinn machen muss bei der LowRes Variante entsprechend nachgebessert werden, arbeite mit und nicht gegen das System,

 

Grüße, Marrrk

[Noa3]

Marrrk, du hattest recht das terrian war einfach viel zu krass uneben und hatte ne zuhoch eingestellte Highmap resultuon.

habs auf 257 runtergestellt, ne deutlich vereinfachte welt erstellt und nun gibs keine probleme beim generieren eines navgrids.

 

das thema kann geschlossen werden