Question: NavMesh about yuka HOT 8 CLOSED

No steering behavior can ensure that a game entity stays on a navmesh. The follow path and on path behavior (which are normally the steering behaviors that you combine with a navigation mesh) also just follow the navigation path but without any collision detection.

One way to solve this issue is to compute the new position of a game entity per simulation step and then check if this point lies on the navigation mesh. If so, the translation is allowed. If not, the app has to react in some way (e.g. by moving the entity into a different direction).

This kind of approach is used in one of the official showcases to ensure the bots do not leave the level when dodging the opponent's attacks.

https://github.com/Mugen87/dive/blob/7176136cf6c29eddfd620df2bf0d09a532680763/src/entities/Enemy.js#L777-L795

from yuka.

Alternatively, one can use the method NavMesh.clampMovement() to restrict the movement of a game entity. However, this approach is not necessarily the best for autonomous agents since normally you want a change in behavior (e.g. moving in a different direction) instead of sliding along the edges of the nav mesh.

NavMesh.clampMovement() works best when restricting the movement of human players.

from yuka.

TBH, I don't know^^. I've never tried to combine the forces of a physics engine with the steering forces. This might work to a certain extend but could produce weird behaviors if the forces do not match in their scales.

You definitely hit a common problem in game development and even AAA games do not solve this properly in all cases. I guess you have to try things out until you find a solution that works for your app.

from yuka.

Thank you. Okay, this ^ is what I started doing. The other approach that I was considering is using the physics engine (ammo.js in my case) to combine resulting forces with those generated by the steering behaviors to arrive at a solution that cannot walk through walls or the ground.

Pro: This has the advantage of not needing to do a path query at every step of the simulation.
Con: But this also has the weird effect of the AI traveling paths that are not entirely the result of their driving behaviors and I don't know how that behavior will affect the quality of the steering behavior output.

What do you think?

from yuka.

I'll continue testing things out, and if the performance I get is good enough given the approach you suggested I think I'll stick with that. I really do appreciate quick feedback. It's hard to make decisions going forward without knowing what the consequences might look like.

from yuka.

Hey so I was wondering if you knew off-hand what the practical performance constraints of the NavMesh class are. For example, if I try to create a NavMesh from this model here:
https://playground.babylonjs.com/#2JBSNA#149
which has 285481 vertices, it seems like the call to load in the nav mesh just never finishes, but the browser does not blow up on memory usage either so it's hard for me to say that it's actually a memory/size of mesh issue.

from yuka.

This part of the code:

/**
	* Creates the navigation mesh from an array of convex polygons.
	*
	* @param {Array<Polygon>} polygons - An array of convex polygons.
	* @return {NavMesh} A reference to this navigation mesh.
	*/
	fromPolygons( polygons ) {

		this.clear();

		//

		const initialEdgeList = new Array();
		const sortedEdgeList = new Array();

		// setup list with all edges

		for ( let i = 0, l = polygons.length; i < l; i ++ ) {

			const polygon = polygons[ i ];

			let edge = polygon.edge;

			do {

				initialEdgeList.push( edge );

				edge = edge.next;

			} while ( edge !== polygon.edge );

			//

			this.regions.push( polygon );

		}
		

This part here is what seems to be the hold up. Each iteration through the for loop takes longer than the previous, as the the variable initialEdgeList grows in length, the inner while loop takes longer.

This code is invoked by the code here:

	_buildRegions( edgeList ) {

		const regions = this.regions;

		const cache = {
			leftPrev: null,
			leftNext: null,
			rightPrev: null,
			rightNext: null
		};

		if ( this.mergeConvexRegions === true ) {

			// process edges from longest to shortest

			for ( let i = 0, l = edgeList.length; i < l; i ++ ) {

				const entry = edgeList[ i ];

				let candidate = entry.edge;

				// cache current references for possible restore

				cache.prev = candidate.prev;
				cache.next = candidate.next;
				cache.prevTwin = candidate.twin.prev;
				cache.nextTwin = candidate.twin.next;

				// temporarily change the first polygon in order to represent both polygons

				candidate.prev.next = candidate.twin.next;
				candidate.next.prev = candidate.twin.prev;
				candidate.twin.prev.next = candidate.next;
				candidate.twin.next.prev = candidate.prev;

				const polygon = candidate.polygon;
				polygon.edge = candidate.prev;

				if ( polygon.convex() === true && polygon.coplanar( this.epsilonCoplanarTest ) === true ) {

					// correct polygon reference of all edges

					let edge = polygon.edge;

					do {

						edge.polygon = polygon;

						edge = edge.next;

					} while ( edge !== polygon.edge );

					// delete obsolete polygon

					const index = regions.indexOf( entry.edge.twin.polygon );
					regions.splice( index, 1 );

				} else {

					// restore

					cache.prev.next = candidate;
					cache.next.prev = candidate;
					cache.prevTwin.next = candidate.twin;
					cache.nextTwin.prev = candidate.twin;

					polygon.edge = candidate;

				}

			}

		}

from yuka.

Let's discuss the above issue in the new thread.

from yuka.