Navmesh error

[ChinRey]

I'm not sure how clear this picture is:

but it shows the physics shape of the ground in a sim with updated navmesh and a thin red prim between the physics and the actual ground at that spot. 0.7 m difference, is that normal?

[arton Rotaru]

Looks pretty normal to me. The terrain physics mesh is much more simplyfied/optimized than the visual terrain, for performance reasons. The display of the navmesh might be even less accurate.

With Estate Manager rights you can set a more precise terrain physics mesh via the Region Debug Console (Develop > Consoles > Region Debug Console) to check if that makes any difference. I'm not sure if that still works though.

get optimize_terrain will return TRUE when the optimisation is enabled. (The default)
set optimize_terrain false will disable the optimisation. (Requieres a terrain edit, or sim restart)
set optimize_terrain true to enable the optimisation. (Requieres a terrain edit, or sim restart)

[ChinRey]

---

arton Rotaru wrote:

Looks pretty normal to me. The terrain physics mesh is much more simplyfied/optimized than the visual terrain, for performance reasons.

---

I'm, not absolutley convinced about the performance gain for two reasons. One is that in the picture I posted first, the deviation was actually created by three superfluous triangles right in the middle of a fairly smooth slope. The other reason is that since the navmesh also sometimes goes quite a bit below the visual ground, the sim also needs a more detailed ground physics model in addition to it. Here is one of my alts, Jazz, standing on the visual ground, "hovering" 0.36 m above the navmesh:

In other words, the navmesh isn't a replacement for the detailed ground physics shape but an addition to it. The server has to keep track of both, using whichever happens to have the highest elevation at any given spot as the walking surface.

I also find it hard to believe that something like this is an efficient physics model:

 

Maybe I should mention that the reson the first navmesh peak I mentioned was so noticeable was that it was right underneath a prim platform. It was hard not to notice that at one specific spot elevation height was like this:

while at the rest of the surface it was:

Of course, since the ground was covered by a platform at this spot, the easy solution was to simply lower the ground a little bit more. But it took a while to figure out what caused the problem.

[arton Rotaru]

The performance gain of the optimized ground physics mesh is the radical reduction of triangles, compared to the visual ground mesh.

The Navmesh is just a map for Pathfinding characters to tell them where to go by avoiding as many collisions as possible. Keeping their collisions basically to the ground only. And with a simplified ground physics mesh this is even more efficient. And since it has to take objects that are set to affect the Navmesh into account as well, and not just the ground, it's indeed in addtion to the ground phyiscs mesh.

That the mesh may look ugly isn't a surprise actually. It's an automated process that takes only a few seconds. It's like with LODs, if we could edit the ground physics mesh manually, we could get a much cleaner result indeed. Though, by editing it manually, inexperienced people could make it even less efficient, too. Just like with LODs. :matte-motes-little-laugh:

[Theresa Tennyson]

---

ChinRey wrote:

I'm not sure how clear this picture is:

but it shows the physics shape of the ground in a sim with updated navmesh and a thin red prim between the physics and the actual ground at that spot. 0.7 m difference, is that normal?

---

Before Pathfinding, the physics engine used a heightfield to determine collisions with the ground. The polygonal physics model came in with Pathfinding (it's probably more accurate to say that Pathfinding came in with the polygonal physics model - Andrew Linden said that Pathfinding was really more of the final excuse to use a more efficient physics model that Havok had developed.

It may well be that the viewer ground display and non-collision avatar movement over ground still uses the heightfield and it doesn't always match the new, polygonal physics model.

https://community.secondlife.com/t5/Second-Life-Server/Pathfinding-FAQ/td-p/1672699

[animats]

On 2/14/2017 at 4:45 PM, ChinRey said:

I'm not sure how clear this picture is:

but it shows the physics shape of the ground in a sim with updated navmesh and a thin red prim between the physics and the actual ground at that spot. 0.7 m difference, is that normal?

I just rediscovered that problem. I'd expect it in mountainous terrain, but it showed up in a flat part of a cow pasture in Newt.     

Ground level tester 0.1 whispers:  Hit #0: <193.00000, 126.60840, 58.60645> Ground (Walkable)
Ground level tester 0.1 whispers: Closest point on navmesh: <193.003600, 126.555200, 58.091970>
Ground level tester 0.1 whispers: Z error: 0.514477

It's a headache for llGetStaticPath, because that will insist it can't find the navmesh if the starting point is more than about 0.3m away from the navmesh. So you run llGetStaticPath from a ground level point and it won't work.

Probably have to use llGetClosestNavPoint when llGetStaticPath returns a PU_FAILURE_INVALID_START status.

Yet another obscure thing you need to know if implementing NPCs.

[ChinRey]

59 minutes ago, animats said:

I just rediscovered that problem. I'd expect it in mountainous terrain, but it showed up in a flat part of a cow pasture in Newt.

I'm not sure but I think it may have something to do with parcel borders. Apparenty SL generates separate navmeshes for each parcel rather than for each region. It is usually a holy mess along the borders and that can affect the navmesh even several meters away from them.