Does AIPath controlling a Rigidbody have any provision for handling (climbing) steps? Obviously CharacterController handles it automatically.
(Next post will contain background in case anything you’d advise)
Thx, R.
Background:
I’m finally updating my project from ‘old’ A* to ‘current’ and from Unity 5.6 to 2018.2 (soon .3).
One of these two is causing my AI mob to moonwalk when legacy AIPath tries to move its CharacterController due to there being a kinematic Rigidbody on the object. (yeah shockingly it used to work and I knew then it was a bit kludgey. I need it there so I can swap the AI from AI+CC to non-kinematic Rigidybody being thrown when then player throws them!) Conclusion: I decided to switch them to purely RB.
I previously extended (now legacy) AIPath so need to entirely update my approach. New AIPath moves RB nicely (great job so far 
). I’ve only just started reading the new code to figure out what I need to do to add my extensions. Any tips would obviously be super helpful. My extension class adds the following:
- strafing : my AI can run sideways at reduced speed while firing at its target
- moving platforms : based on a long-ago recommendation which has worked fine ever since.
- root motion-based movement : some of my AIs used this type of animation (is this at all handled in new? hey, I can ask!
) - Behavior Designer interface : some convenience for calling from BD including feedback on being blocked
Obviously I’ll have to add provision for climbing steps if that’s not in there too. I noticed IMovementPlane movementPlane and wondered if it might provide a quick solution – maybe contrive an artificial plane when on a set of stairs to add verticality – but depending how it’s used could cause mayhem with other uses!
Thx, R.
(quick WIP FYI)
First take: looks like I might be able to cheekily pervert ClampToNavmesh() to have it step up and forward.
I’ve implemented stepping-up functionality for AIPath controlling a Rigidbody using override in ClampToNavmesh(). I could make it more general and offer back if it’d be useful (I imagine it’s a pretty common desire). Best done inside AIBase I’d guess?
However certain paths in certain world geometry cause problems where the agent cuts the corner too tight. I’m only on 4.1.16 atm and noticed there’s a fix in 4.2 “Added a height and radius for the AIPath and RichAI movement scripts.” so I’ll work on upgrading again (glad to hear the asmdefs and extra-assembly graph type loading are built-in now!) Hopefully it’ll fix the problem but, in case not, I’m reporting in case you can offer other suggestions:
hmm… 1986kb GIF won’t upload telling me it’s bigger than 8192kb. Um.
Posted GIFs to twitter:
If fixed in 4.2.x, great. Otherwise, what’s the best way to get agents to check width validity and/or swing wide of corners?
Thanks
Just remembered the Left4Dead workaround for this – they said they do local avoidance for this sort of thing. Slide 14+ from https://steamcdn-a.akamaihd.net/apps/valve/2009/ai_systems_of_l4d_mike_booth.pdf
Guess I’ll give that a try if not included.
Hi
For rigidbodies the package just moves the agents using physics, there is nothing specific to steps done for it. CharacterControllers and when not using any physics at all can handle steps well though.
thx @aron_granberg
-
re. steps, NP. Would you be interested in integrating my modification that adds it? (else I won’t bother porting into AIBase since it’s just another thing to patch on update.)
-
Any feedback on the “blocking at that corner” thing? (post 4 in this thread)
Re 1. Depends on how complex and generic it is. I will consider it if the change is small, performant and is/can be made very generic.
Re 2. It looks your graph doesn’t really have any margins. Remember that the graph surface is the surface where it should be valid for the agent’s center/feet to be, while in your case that would often cause it to be half inside walls. I would recommend setting the ‘erosion’ setting in the grid graph to 1 (possibly you will have to increase the resolution a bit if this cases the agent to not be able to pass through some openings).
Re. 1: OK, I’ll have a look at it. Current (override ClampToNavmesh()) version is about 40 lines of actual code which does one SphereCastNonAlloc() as its main cost.
Re. 2: Margins. Yes, that’s what’s needed here.
2.a:
Erosion could be a way. How bad is the performance cost of using “erosion” especially in a runtime updated GridGraph? (I’ve never used due to “seriously slow down graph updates during runtime”.)
Background:
My game uses one custom GG over a voxel surface that gets changed when shots land, etc. That same graph is used by different agents with different sizes.
2.b:
Alternatively / if too expensive, I’d have expected the “Collision testing” to have provided some margin anyway. I have Capsule, diameter:1, Height:2 and “Max Climb:0.55”. That seems to be fine when the obstacle is sufficiently tall. I’ve not yet checked the code but guess that “1 unit” step up might be being lost within the bottom curvature of the capsule?
The effect of using erosion is essentially that if an AxB region of the graph is updated, then with an erosion of 1 it needs to actually update a (A+2)x(B+2) region (+1 node in each direction). So a high number of erosion iterations can be really expensive, but a value of 1 is usually not very expensive.
Thanks.
Any thoughts on the “collision testing” part?
(sorry, I edited to explain: sure it’s not too expensive but do I really want to remove other actually valid nodes from the graph just for the sake of this? There could be valid narrow paths lost. I’d rather generate a correct corner here.)
It will provide a margin if it actually hits an obstacle. However your wall might not be in the collision layer mask.
Note that you would need a diameter > 1 to make that work, otherwise it will just be a capsule with the same diameter as the node.
Thx for the reply. It made me return to investigate the collision testing settings and I realised I had a mistake! I had offset left at the default (0). I guessed that offset might be relative to the height of the collider which I had as 2 so I tried 1.1 and it’s now much better! Thanks!
I got the stepping-up functionality into the AIBase and tested successfully for GridGraph + AIPath. It needs a little tweaking to use MovementPlane rather than assuming Y-up. Once done (maybe after Xmas), shall I message you with a diff / whole thing?
Nice!
Sure. You can send it. I’m not sure if I will include it or not, but it doesn’t hurt to have a look at it.