Search Results for 'dynamic navmesh'

[CastorParticipant]

I would like to add to this thread.

I think the reason why people are trying to integrate both Rain and A* project is that they offer features that compliments each other weakness.

A*path project doesn’t have nice BT editor and behaviour stuff that Rain has.

On the other hand, Rain does offer decent path finding features of its own, but it lacks some of critical features that A* offers.

I am not 100% certain and Rain may support them already, but
Some of them are things like :

Dynamic Navmesh cutting
Dynamic local avoidance
Ability to save and load navmesh data to/from file

If Rain can support these and do them well enough to match / surpass in terms of performance and usability there should be very little reason why would anyone to just use Rain all together.

Also , Rain lacks documentation on “how to” write own custom stuff too. More videos would be nice as well.

But having said that Rain still offers a lot, just a bit further and it would be really cool.

• This reply was modified 5 months, 1 week ago by  Castor.

[primeKeymaster]

1) Yes, you can modify the mesh at runtime, or even create a new one. However, doing so can cause issues. Essentially, all AI that are using the mesh will need to have their Navigators reset when you do it - the Navigators do keep graph data locally.

2) Yes, it is possible to add weight to the navmesh at runtime, but currently not statically in the editor.

3) We’ve done some work on a dynamic runtime mesh for the purposes you are suggesting, but we don’t have it in a form we can release yet. (We’ve got the 80% cases working fine, but the 20% still needs work).

For the moment, RAIN isn’t a good fit for games that require dynamically changing meshes.

Just a quick question in regards to the navmesh and AI path finding

is there a way to create a dynamic obstacle within the nav mesh that will create a temporary hole in the nav mesh at the AIs location but then fill it in when the AI moves to a new location.

for example currently my AI will find their way around the rooms etc however they have a habit of running into each other and trying to push each other out the way, instead of walking around the space another AI is present in.

Thanks in advance for any help

[primeKeymaster]

@binary - Yes, there is a fair amount of overhead in the procedure I outlined. However, the construction can be done on an as-needed basis and can use features of the NavMesh to speed itself up. Once the corridor is constructed, avoidance calculations become much simpler. The global manager doesn’t interfere with autonomy; it is only used for fast lookup of relevant information (as opposed to doing raycasting and tracking all nearby moving objects).

@urpro-bas - Anything that needs to be tracked for avoidance would be registered with the global manager, including the player.

The main goal is to use relevant data that has been precomputed whenever possible. The NavMesh is a precomputed representation of collidable objects in the scene. It should be used instead of raycasting when dealing with locomotion collisions. The corridor would be calculated from the navmesh, and then avoidance calculated from only the dynamic data.

[urpro-basParticipant]

Prime,

What you suggest, sounds a lot like some acadamic papers I read, maybe you based you’re ideas on those papers. I don’t know that much about it but the results achieved there seem promising.
Regarding a global manager, that doesn’t seem like to much of a problem to me, because I would see this avoidance problem as the dynamic part of the navmesh. There has to be some medium through which all the agents communicate. It doesn’t really matter whether this is the game world (through colliders/sensors) or through a global manager.
The only part I do not fully understand yet is how the agents would avoid a player with direct controls. Maybe the player should project some kind of expected path? Otherwise all agents respond very intelligently to eachothers collision but have to apply a very ad-hoc avoidance for usercontrolled characters?

Sorry, if I am hijacking the thread, I didn’t know somewhere else to respond to this since Prime set it open for discussion here.

[binaryParticipant]

First off, the last time i did something remotely AI related was in high school, turtle programming in a maze. I’m aware that avoidance is not a trivial problem, especially on the scale of an AI engine.

My naive opinion to the solution you’re considering is, that it sounds like a lot of overhead (to be precomputed though but would be a pain during run-time if anything changes) and, more important, the agents will loose autonomy with a global manager.

Maybe calculating an escape vector on the involved velocity’s alone will be good enough. Maybe the (moving) obstacle avoidance through dynamic navmeshes you announced can be extended or not calculating the path to the very mesh edges and keep space for offsetting (lerp) the agent to the left or right of the path will work. There are so many options and you probably have already explored far more then i myself can even imagine. I’m confident you will find a good and robust solution. But, as you might have guessed by now, i personally would favor autonomy over a global tracking solution at any cost, even general performance, and tweak that as much as possible. (Btw. did you ever hear of the RoboCup RescueLeague? It’s an simulated ai contest and if i remember correctly, full agent autonomy is a requirement to qualify for World Championship).

After all, like stated above, i don’t know much about steering behaviors or ai in general, which can be easily a lifetime research field, and hope for insight by an agile discussion.

After looking for a solution for my problem for 2 days now by coding, i came up with an even easier solution without a line of code.
I manged to solve my problem by adding a walk animation that moves the character slightly to the right while walking forward and trigger that with a mecanim parameter on detection in the behavior tree ( i use root motion ). This works in 80% and at least the characters can glitch free now for the other 20. (it works in code too but this way i saved the option to animate the walk-by-high-five )

Im totally amazed (again) how powerful Rain already is. Thank you!

[primeKeymaster]

Hmm. I suspect something can be done. One of the things that makes pre-generated navmeshes tough to work with in RAIN is that we don’t currently automatically support translation/rotation/scaling of navmeshes. So you could pre-create navmeshes for rooms, halls, and other components, but you would have to manually update the mesh points after the room is placed in the level.

We have this on our roadmap - to support arbitrary (and even dynamic) positioning of navmeshes at runtime, but haven’t been able to get to it just yet.

I’ll ask @sigil to jump in and answer this one - he’s the navmesh guru.

[primeKeymaster]

Sorry, I started to reply to this email a few days ago but got sidetracked.

Unity and RAIN navigation meshes are pretty similar. Both are based on Mikko Mononen’s Recast system. Actual movement in Unity is based somewhat on Mikko’s Detour algorithms (I think), while RAIN has a different agent-centric approach to path following. Both create good meshes, have good visualizations, and work well for AI movement.

It is possible to use RAIN in conjunction with Unity’s NavMesh system. To do it, you should create a CustomMotor that hands off movement to Unity’s NavMeshAgent system.

Here are some specific differences between the RAIN and Unity navigation.

- Unity requires objects to be either terrain or marked as Static in order for them to be considered by the navmesh generator. RAIN doesn’t check the static flag, but instead considers all colliders.
- RAIN supports multiple NavMeshes, Unity supports one per scene
- RAIN AI can be assigned to specific NavMeshes, allowing you to create different meshes for different types of AI or different sizes.
- RAIN supports navigation between NavMeshes and navigation to targets that are not on the NavMesh.
- RAIN supports dynamic navmesh generation at runtime.

- Unity’s system can sometimes run a little faster since it is based on native code.
- Unity supports off mesh links. RAIN doesn’t yet support that.

[VelathoraParticipant]

Perfect,

If I was to use a form of custom approach, is there any custom action that you might suggest that would allow movement from one side of the street on a sidewalk to the other side of the street on the other sidewalk?

I.E.

Pedestrian walks along sidewalks on navMesh, gets to a corner and sees that the light is green in the opposite direction (indicating “I can cross”). Pedestrian then moves to alternate sidewalk and cannot go back unless the same condition is true.

The issue lies with the entire thing being dynamic, as the map, as I mentioned, is very large.

Would you still suggest a navMesh in this case, or multiple waypoint networks with transition? (I may reduce the area where the pedestrians will walk, as the map is large, but only 1/5th is a “city” that is usable by drivers and pedestrians.

Cheers.

[primeKeymaster]

RAIN already supports threaded navmesh creation. What specifically are you referring to with regard to “cutting”? Do you mean manual editing? Dynamic obstacles that create holes?

We are working on a version that supports real time updates based on dynamic obstacles. We have a version running here internally - just not ready for full release yet. We have manual editing on our roadmap, but haven’t started coding on that yet.

Hey everybody! I’ve been having pathing issues with my characters I hoped would be resolved by the latest update, but it just created different problems.

In my game, traversable terrain is a modular space station built by the player. So, when I add a new module, I:
1) Place it in space
2) Generate a waypoint graph inside it
3) Connect the endpoints of that graph to existing neighboring modules to make it part of the global graph
4) Generate a navmesh for the new module of sufficient size as to not only cover all the walkable surface inside that module but also overlap a little with other modules. I also ensure that the place the navmeshes overlap is where the connecting waypoint graph node is located.

I run characters through this environment by setting a target position variable equal to the position of one of the waypoint graph nodes (chosen at random) and the executing the Move action in their AI.

In the previous version of RAIN, they’d often pathfind correctly for a while, but eventually they’d get stuck on a particular node (not always the same one) and start circling around it and never would complete.

In the new version, their pathfinding is now incredibly wonky. Not only does it sometimes path through the same node repeatedly and bounce between walkable navmesh bounds but they also just decide to walk off the navmesh, straight towards the target.

I’m now at a total loss as to what is wrong with my setup. Is there something about dynamically creating graphs or navmeshes that doesn’t work? Everything else emulates the sample code almost exactly.

My scenes are generated dynamically, so I cant generate my NavMesh at design time. I need to do it at runtime.

How can I do this?

Apologies if this is obvious!

I cant find any documentation regarding and since the source code isnt available I’m having trouble working out how to use rain!

First of all Rain looks great and shows very promising features!

I would love to start porting our current AI system and navigation system into Rain, but in order to do that, we need the following features to be enabled :

1. Dynamic navigation generation
2. Dynamic obstacles
2. Local avoidance

I know the above features are “upcoming” features at the moment, but as with every other developers we need to be able to plan and schedule our work so any hint of above feature update date would be really nice.

I am all fond of using Unity and its pro features but sometimes Unity’s supposed to be pro features like navmesh stuff doesn’t really do any good job in real production. (very limited) So I am very much looking for Rain to fill in that gap.

We do blogs and features all our dev tools we use in the production so if Rain is one of them, we will definitely be writing review on it.

• This topic was modified 10 months ago by  Castor.

I’d originally thought that the BasicNavigator uses Unity’s native NavMesh system under the hood, judging by all the shared parameters. However, then I saw that dynamic NavMeshObstacles aren’t supported and also read that RAIN uses a Recast process.
I really need to use dynamic obstacles in my game, so I would like to use the native NavMesh system, but I’m not clear how to write a custom navigator to handle that. I created a subclass of BasicNavigator (as instructed in the minimal documentation on the subject), but do I also need to write custom RAINNavigationGraph as well? Also, what code would I be wanting from the BasicNavigator, rather than just subclassing RAINNavigator.

Could anyone point me in the right direction to get started with this?

[mqnguyen42Participant]

Thanks, that’s exactly what I needed. Also, dynamic obstacle avoidance is not really what I’m looking at, I need deformation of the navmesh in accordance to deformation of voxel terrain. I guess I’ll have to deal with that minuscule pause that comes with navmesh generation. That’s why I’m looking at solutions to regen the navmesh as a background process.