Navigatieprestaties optimaliseren (2023)

Prestatieproblemen met het parseren van SceneTree-knooppunten¶

Vermijd in het algemeen het gebruik van zeer complexe geometrie als brongeometrie voor het bakken van navigatienetten. gebruik nooit een zeer gedetailleerde visuele mesh, omdat het ontleden van de vorm ervan naar data-arrays en het voxeliseren ervan voor het bakken van de navigatie-mesh lang zal duren omdat er geen echte kwaliteitswinst is op de uiteindelijke navigatie-mesh. Gebruik in plaats daarvan een zeer vereenvoudigde detailversie van een vorm. Nog beter, gebruik zeer primitieve vormen zoals dozen en rechthoeken die slechts ruwweg dezelfde geometrie bedekken, maar toch een gebakken resultaat opleveren dat goed genoeg is voor het vinden van paden.

Gebruik liever eenvoudige natuurkundige botsingsvormen dan visuele mazen, als de brongeometrie voor het bakken van navigatienetten. Natuurkundige vormen zijn standaard zeer beperkte en geoptimaliseerde vormen die gemakkelijk en snel te ontleden zijn. Een visuele mesh daarentegen kan variëren van eenvoudig tot complex. Bovendien moet de parser, om toegang te krijgen tot visuele mesh-gegevens, de mesh-gegevensarrays opvragen bij de RenderingServer, aangezien visuele mesh-gegevens rechtstreeks op de GPU worden opgeslagen en niet in de cache worden opgeslagen. op de CPU. Dit vereist het vergrendelen van de RenderingServer-thread en kan ernstige gevolgen hebben voor de framerate tijdens runtime terwijl de rendering multi-threaded wordt uitgevoerd. een paar seconden op complexe mazen.

Prestatieproblemen met het bakken van navigatiegaas¶

Het bakken van navigatienetten tijdens runtime moet indien mogelijk altijd in een achtergrondthread worden gedaan. Zelfs kleine navigatienetwerken kunnen veel langer nodig hebben om te bakken dan wat mogelijk is om in een enkel frame te persen, tenminste als de framerate op een draaglijk niveau blijft.

Complexiteit van brongeometriegegevens die zijn geparseerd uit SceneTree-knooppunten heeft een grote impact op de bakprestaties, aangezien alles moet worden toegewezen aan een raster / voxels. Als de celgrootte of celhoogte te laag is ingesteld, wordt het bakken gedwongen om een ​​overmatige hoeveelheid voxels te creëren om de brongeometrie te verwerken. Als de brongeometrie zich uitstrekt over een zeer grote spelwereld, is het zelfs mogelijk dat het bakken proces raakt halverwege het geheugen kwijt en crasht het spel. Het partitietype kan ook worden verlaagd, afhankelijk van hoe complex de brongeometrie van het spel is om wat prestaties te verbeteren. games met overwegend vlakke oppervlakken met blokgeometrie kunnen wegkomen met de monotone of lagenmodus die veel sneller te bakken zijn (bijvoorbeeld omdat ze geen afstandsveldpassage vereisen).

Schaal brongeometrie nooit met knooppunten. Het kan niet alleen resulteren in veel precisiefouten met verkeerd overeenkomende hoekpunten en randen, maar ook enige schaling bestaat alleen als visuele en niet in de daadwerkelijk geparseerde gegevens. als een mesh visueel wordt verkleind in de Editor, b.v. de schaal ingesteld op 0,001 op een MeshInstance, vereist de mesh nog steeds een gigantisch en zeer complex voxelraster om te worden verwerkt voor het bakken.

Prestatieproblemen met NavigationAgent-padquery's¶

Logische fouten en verkwistende bewerkingen in de aangepaste NavigationAgent-scripts zijn veelvoorkomende oorzaken van prestatieproblemen, b.v. pas op voor het resetten van het pad bij elk afzonderlijk frame. Standaard zijn NavigationAgents geoptimaliseerd om alleen nieuwe paden op te vragen wanneer de doelpositie verandert, de navigatiekaart verandert of ze te ver van de gewenste padafstand worden gedwongen.

Bijv. wanneer AI naar de speler moet gaan, moet de doelpositie niet voor elk afzonderlijk frame worden ingesteld op de positie van de speler, omdat dit elk frame een nieuw pad vraagt. In plaats daarvan moet de afstand van de huidige doelpositie tot de positie van de speler worden vergeleken en alleen wanneer de speler is te ver weg gegaan, er moet een nieuwe doelpositie worden ingesteld.

Controleer niet van tevoren of een doelpositie elk frame bereikbaar is. Wat lijkt op een onschuldige check, is het equivalent van een dure padquery achter de schermen. Als het de bedoeling is om toch een nieuw pad op te vragen als de positie bereikbaar is, moet er direct een pad worden opgevraagd. Door te kijken naar de laatste positie van de geretourneerde pad en als die positie zich op een "bereikbare" afstand van de aangevinkte positie bevindt, wordt de vraag "is deze positie bereikbaar?" beantwoord. question.Hiermee wordt voorkomen dat het equivalent van twee volledige padquery's voor elk frame voor dezelfde NavigationAgent moet worden uitgevoerd.

Verdeel het totale aantal NavigationAgents in updategroepen of gebruik willekeurige timers zodat ze niet allemaal nieuwe paden in hetzelfde frame opvragen.

Prestatieproblemen met het eigenlijke zoeken naar paden¶

De kosten van het daadwerkelijk zoeken naar paden zijn rechtstreeks gecorreleerd met de hoeveelheid polygonen en randen van navigatiegaas en niet met de werkelijke grootte van een gamewereld. acceptabel. Als de gamewereld versplinterd is in zeer kleine navigatienetwerken die elk kleine polygonen hebben (zoals voor TileMaps), zullen de prestaties van het vinden van paden worden verminderd.

Een veelvoorkomend probleem is een plotselinge prestatiedaling wanneer een doelpositie niet bereikbaar is in een padquery. Deze prestatiedaling is "normaal" en het resultaat van een te grote, te niet-geoptimaliseerde navigatiemaas met veel te veel polygonen en randen om doorheen te zoeken. Bij normale padzoekacties waarbij de doelpositie snel kan worden bereikt, zal de padzoeker een vroege exit uitvoeren zodra de positie is bereikt, wat dit gebrek aan optimalisatie een tijdje kan verbergen. Als de doelpositie niet kan worden bereikt, moet de padzoeker het doen een veel langere zoektocht door de beschikbare polygonen om te bevestigen dat de positie absoluut niet bereikbaar is.

Prestatieproblemen met synchronisatie van navigatiekaarten¶

Wanneer wijzigingen worden aangebracht aan b.v. navigatie-meshes of navigatie-regio's, moet de NavigationServer de navigatiekaart synchroniseren. Afhankelijk van de complexiteit van navigatie-meshes kan dit een aanzienlijke hoeveelheid tijd in beslag nemen, wat van invloed kan zijn op de framerate.

De NavigationServer voegt navigatienetwerken samen, hetzij door vertex of door randverbinding. Het samenvoegen door vertex vindt plaats wanneer de twee vertex van twee verschillende randen in dezelfde kaartrastercellen terechtkomen. Dit is een vrij snelle en goedkope bewerking. Het samenvoegen door randverbinding gebeurt in een tweede doorgang voor alle nog niet samengevoegde randen. Alle vrije randen worden gecontroleerd op mogelijke randverbindingen door zowel afstand als hoek, wat nogal kostbaar is.

Dus afgezien van de algemene regel om zo min mogelijk polygoonranden te hebben, moeten zoveel mogelijk randen vooraf worden samengevoegd door hoekpunten, zodat er slechts een paar randen overblijven voor de duurdere berekening van de randverbinding. De debug Navigation PerformanceMonitor kan worden gebruikt om statistieken over hoeveel polygonen en randen beschikbaar zijn en hoeveel daarvan niet zijn samengevoegd of niet zijn samengevoegd door vertex. inefficiënt.