Question: NavMesh

[arcman77]

I have some vehicles that are controlled by steering behaviors, I'm not sure how to combine this with mesh navigation such that the vehicles steering behavior is bounded to the surface of the heightmap mesh I'm using. Is this possible and is it a supported behavior/usecase?

For example, the steering behavior pursuit follow and wander create a force that drives each vehicle, but does that produce a target that I can use the the on path steering behavior with?

From the looks of it, there is a target that I can use to combine with the on path steering?

[Mugen87]

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

[Mugen87]

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.

[arcman77]

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?

[Mugen87]

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.

[arcman77]

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.

[arcman77]

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.

[arcman77]

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;

                }

            }

        }

[Mugen87]

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