So, im considering bying this, but i want to know for sure it would work for my project. Im currently doing a procedural dungeon generator, for something of like a 3d rougelike game, so im more or less only interested the recast graph feature. my dungeon layouts is of course 3d, i have rooms and corridors going above and under eachother.
this works fully at runtime, can i make a new navmesh in my scripts whenever i want?
im presuming this, but will it work for any layout of rooms and corridors in 3d space?
can i generate a navmesh from anykind of meshes? im mean, is there any requirement, like they have to be welded together or will it accept small offsets between say room and corridor edges?
whilst typing i saw this question has been asked before, but i would still be happy to get some answer, so i can buy the pro version without worriyng.
last question; read that bying this will give me free updates to all 3.x versions. is there any reason to wait for 4.0 instead?
For the recast graph: any kind of meshes will work (also colliders, which may be faster to use when generating the graph since they often have fewer polygons). For layered grid graphs any colliders will work.
You may want to separate the roof and the floor however to avoid generating a navmesh on top of the roof (depending on how your meshes look).
Note however that recast graphs can take some time to generate, so depending on your game and world size, that may or may not be acceptable. Layered grid graphs are generally faster to scan, but you will get a higher quality graph by using a recast graph.
I do not currently have any concrete plans for a 4.0 version, and even if it would be released soon you would of course get an upgrade discount.
i managed to get the recast graph working for my procedural dungeon, am really happy with how its looking. i have problems/questions though;
high slopes seem to cause stuttering for the agent whilst walking upwards, and i need to put the gravity to 90 to get it not floating whilst walking downwards. im having like 50 degrees slopes, and are using the richAI.
what is the gravity based on, i mean, what weight does it use? and how can i get rid of the stuttering?
2 how do i get the local avoidance working togheter with the ricAI? i just added them both to the character, but it gets stuck om some slopes and corners.
I am not sure what could cause that.
It depends on what type of controller that you are using. If you are using the character controller, make sure that the max slope is set high enough. The gravity is based on the normal unity gravity.
Just adding it to the same component should work (make sure you remove your character controller). You may want to add some wall force on the RichAI component (but make sure the wall distance is at a relatively low value so that it is not affected by the force even when it is far away). Alternatively you can try disabling the wall force completely and see if that improves things.
im not using any controller only the richAI. the stuttering is very random it appears everywhere sometimes, and somethimes not at all. ill try to narrow it down.
i added the rvo stuff, and it works somewhat. but the richAI seems to override the rvo. what i mean is, the force to go to the richAI target is way stronger that the avoidance so all my agents end up in a small lump. they dont care if they intersect eachothers collision if richAI is active. when i disable it, they all spread out like they should. so how do i go about the get proper avoidance, for example if they all want to go to the same target?
EDIT:
they actually spread out like they should whilst moving towards the target. but when they reach it, they lump together.
i cant get the RVO to work together with the RichAI. the agents dont seem to care much about the avoidence when they have RichAI. as soon i disable it, they separete from themselves and obstacles like they should.
what am i doing wrong? maybe these 2 arent compatible? do i have to write my own ai? there is similuar threads with the same problem here, that havent been answered and are more than a year old, which worries me. grateful for any response, even if there is no solution.
Yeah, I did investigate the issue and it seems there are some problems with the interactions between them, especially close to edges of the navmesh. If the agent moves outside the navmesh just a tiny bit the RichAI component will move it back, this may cause the RVO Controller to detect that as a teleport and will disable avoidance during that frame. I don’t think all the components behaved the exact same way when I originally implemented it, which is why I thought it would work out of the box.
There may also be other cases where the components do not cooperate properly.
I will continue to investigate the issue, but currently I am afraid there is no quick fix for the problems.
thanks for the fast reply.
do you have any recommendation for a work around? what is the closest i can get to these behaviors by using some other scripts? what im looking for is the typical rts ai, that will walk towards a target but avoid other units and obstacles, obvouisly on a navmesh. im prepared to write my own ai, i just dont want to do uneccesary work.
in the example scene “RVO”, the behavior seems to work fine. what do i lose by using such a solution, and not the rich AI?
EDIT: from reading around in other threads i found out the RVO controller has to be added before any AI, for the AI to recognize the RVO. i tried it, and now it behaves a lot differently, more like it should. going to try it out and see how it works now. maybe worth noting in some documentation somewhere that the order in which they are added matters for the behavior
EDIT2: still get unwanted behavior, the agents get stuck in namesh borders and such, and if i disable richAI they get loose. they have trouble getting through narrow spaces, not really moving as nicely as with only the richAI.
If you are adding the components when not in play mode it should not matter, however if you are adding them during runtime it does matter because the scripts will only look for other components during Awake for performance.
Not that much, the RichAI component does have some smoother and nicer handling of paths and links, but I doubt that will matter that much for you. It also constrains the agent to always be on the navmesh.
i tried it out some more and i have better results now. still having issues though.
the richAI doesnt seem to work, as you say. enforcing always staying on the navmesh makes besides the other issues, the agents to have very stuttery movement when they collide with eachother and walls. in a doorway for example.
i had better luck with the aipath. but it happens a lot, that agents go trough walls. sometimes when they crowd up around doorways some slip trough the wall instead. i have a kind of officy, wall to wall kind of rooms so my walls arent very thick, like 0,2 units. lowering the rvo wall thickness doesnt help. i would prefer if the penalty for going througho walls was higher than intersecting with eachother. is there a setting for that?
i also dont understand how the obstacles should work. the example square collider script is not working well. the agents go half way into it, get stuck sometimes and largerly doesnt care about the bordes of it.
EDIT: the going through walls issue might be beacuse of the AIpath and not the rvo. AIpath doesnt care much about thin walls apparently.
I am currently doing a major restructuring of the RVO code (partially motivated by this thread). I think this issue should be able to be resolved when it is done.
If you want to try it out you can ping me in a few days (so I don’t forget) and I can send you a preview version.
