Navigation Adjustments
The Industrial game level is starting to shape up, and it features some new architecture that the AI hasn't dealt with before, including pipes that run along walkways, and others that have shown up previously, like walkways and handrails.
I placed some enemies in the level and tested them chasing me around, and I found that they would get stuck near the piped walkway - the nav system was connecting the grid points on both sides of the handrail, so the AI thought it could go through it.
This is most likely caused by the AI using swept spheres instead of capsules for the nav tests, but rather than jump into that code again, which hasn't been touched for ages, I added a feature that I think will be needed later anyway, and can be used to address this.
Tonight I made the engine pick up two new facets on static meshes, static entities and triggers to influence the navigation map.
Here is a shot of a user-created trigger surrounding the pipe mesh to make the AI avoid walking on the pipe, or pathing through it.

During the level build process, the engine finds all nav paths near the oriented bounding box of the tagged mesh, entity or trigger object, and adjusts the path costs. If the nav path crosses or is contained in the box, its navigation costs are adjusted.
The "nav_modulate" facet multiplies the factor by the current nav cost.
The "nav_add" facet adds an offset.
Nav costs < 1 are clamped to 1. A link with a Nav costs >= 100 is broken completely.
So the level designer can either add triggers to influence the path finding AI towards or away a certain route, or block it completely. Alternately, she can just add the facet to a static mesh itself to make the AI prefer or avoid it for navigation purposes.
Here is a shot of resulting surviving paths, with both the railing and the pipe mesh tagged with impassable nav costs.

A similar method is planned to identify cover and vulnerable tactical map sections.
I placed some enemies in the level and tested them chasing me around, and I found that they would get stuck near the piped walkway - the nav system was connecting the grid points on both sides of the handrail, so the AI thought it could go through it.
This is most likely caused by the AI using swept spheres instead of capsules for the nav tests, but rather than jump into that code again, which hasn't been touched for ages, I added a feature that I think will be needed later anyway, and can be used to address this.
Tonight I made the engine pick up two new facets on static meshes, static entities and triggers to influence the navigation map.
Here is a shot of a user-created trigger surrounding the pipe mesh to make the AI avoid walking on the pipe, or pathing through it.

During the level build process, the engine finds all nav paths near the oriented bounding box of the tagged mesh, entity or trigger object, and adjusts the path costs. If the nav path crosses or is contained in the box, its navigation costs are adjusted.
The "nav_modulate" facet multiplies the factor by the current nav cost.
The "nav_add" facet adds an offset.
Nav costs < 1 are clamped to 1. A link with a Nav costs >= 100 is broken completely.
So the level designer can either add triggers to influence the path finding AI towards or away a certain route, or block it completely. Alternately, she can just add the facet to a static mesh itself to make the AI prefer or avoid it for navigation purposes.
Here is a shot of resulting surviving paths, with both the railing and the pipe mesh tagged with impassable nav costs.

A similar method is planned to identify cover and vulnerable tactical map sections.
0
Sign in to follow this
Followers
0
2 Comments
Recommended Comments
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now