Noob navmesh question

[hereami]

Original Noir Penthouse navmesh looks extremely (excessively) complicated, it has tons of rays-styled triangles, where they can be replaced by a pair or so, if done manually. The question is - does it have any hidden meaning or is just a poor result of automatic generation?

Question in general: a rectangular room - will there be any benefit (pathing precision, better furniture/obstacle detection or whatever) from having dozens of tris vs having only 2 ??

 

Noir penthouse is for example, i've managed to fix broken navmesh finally and happy now anyways :smile: Just would like to know, if rebuilding whole navmesh manually isn't a complete monkey business.

 

At the same time, had a question, how rose-colored areas on the navmesh map are managed properly - do they have special meaning or not, and how to mark them as such, if neccessary? Those are found under furniture items.

 

 

Edited June 30, 2019 by hereami

[Mebantiza]

You will find overly complex, and excess triangles all over skyrim navmesh, whether it is vanilla, or modded. For myself, I always try to 'simplify' NM where practical when working on it, move vertices to better locations etc, trimming unnecessary triangles etc. Whether trimming and simplifying NM reduces any kind of overhead internally in of itself, is not something I am not entirely clear on either. If you have a perfectly square room with nothing in it, having a NM consisting of two triangles vs say, one with 4, probably wont have much functional impact if you cut the triangles down to 2 from 4. If I saw the same room with say, 50 triangles, I would probably just redo the entire thing on general principle. Keep in mind, when you finalize a cell, it will, or can, automatically add new triangles back into the NM of its choosing, even if you simplified it, and you have no real control over that.

 

When it comes to questions like this, I tend to go with the simpler and less complex, the better. A NM should only be as complex as it needs to be and no more. But, a lot of times, you will find NM that is excessively complex for what it needs to do. In cases like that, I tryto simplfy. Keep in mind, a lot of time NM is so bad, my 1st goal is to clean it up or correct errors. Simplifying the mesh is usually just a bonus. Looking at all those surplus triangles, If I were working on them, Id probably find some excuse to cut them down considerably. In some of the things I am working on, it is not unheard of for me to be able to reduce total vertices count by say, 10-15 or more %, and increase NM coverage or fix errors doing it.

 

It is probably fair to say however, the more excessive and surplus triangle you haves , the greater the overhead that imposes, even if the effect is very minor or subtle. Again I tend to go with the additive impact of simplying those things is probably beneficial.

 

To use an example, getting rid of navmesh islands that no NPC would ever travel on even if they could, reduces the size of the ESP, because of course, NM is data. While this may not apply directly to your question here, I am have a worldspace with so much excess and useless navmesh, removing it all has reduced the main ESP size by at least 1mb, if not more. That is ~2% at least of useless data doing nothing for the worldspace, but still loaded by the system when you fire it up.

A lot of the navmesh that I did keep, the bulk of it, has been simplified in a lot of specific instances and has (mostly), lower triangle and vertices counts.

Edited June 30, 2019 by Mebantiza

[KahvozeinsFang]

The pink colored tri's are Precuts/Navcuts. They are used because there are scrappable objects in the Navmesh. It disables the tri's until the object is scrapped. That way NPCs don't try walking through a couch that might not always be there.

 

You can make Precuts yourself by:

 

1. clicking a scrappable object in the render window. (Only works with scrappables)

 

2. Click the button to open the navmesh toolbar. (with the item still selected)

 

3. Then open the drop down Navmesh menu and click "create Precuts for selected objects"

 

While you can just create all Precuts at once with "create Precuts for all objects" (or something similar, I'm not on my PC right now) I prefer to do them one at a time and check for errors in between each object.

 

And there really isn't a problem with smaller triangles, just as long as there are not thousands of little tiny ones. I usually make my Navmesh by hand, and make them a medium size.

 

What's good about more triangles would be you can add preferred pathing to a specific path.

 

And stay away from making very long skinny triangles. And aways check your Navmesh before finalizing it. Saves you from errors popping up when loading your plugin and possible game crashes.

Edited June 30, 2019 by KahvozeinsFang

[hereami]

@Mebantiza, @KahvozeinsFang, Thank you!

So, it's mainly nav generation flaw, seems to be tending to reduce vertices amount, so there appear the spikes, can be very troublesome indeed, those i found in the bedroom on the left prevented npc from accessing the bathroom - they were hair-thin, somehow twisted and overlapping.

 

Curious, if any of buildable objects were made to serve as dynamic navcuts: https://www.creationkit.com/index.php?title=NAVCUT . Either none of them, or this mechanics is obsolete? (as there is need for explicit support from navmesh side, and npc always walk into runtime-placed walls, tables etc.).

Also there are Navmesh generation options on some objects, seems to be rather clear, but does "Obstacle" flag have a usage and at what stage (design time only, runtime)? Tried to set for Shack foundation e.g., hoping it must tell npc to pass around, but seems to have no effect.

PS. Hm, F4 wiki section is usually abandoned, but for STAT it says "Obstacle: Whether the game should check these references for NAVCUT data and apply it.". So, does it mean then, Shack foundation in particular has no specific data to be appied? That's quite a pity. Life could be simple otherwise.

Edited June 30, 2019 by hereami

[Mebantiza]

The occasionally helpful and infomative CK wikis navmesh section is threadbare even by the wikis rather loose standards. Even its basic information on navmesh is not very clear or helpful in some most cases. Trying to learn anything about a lot of the details of the specific navmesh related commands in the CK, is left to guesswork, trial and error, and conjecture. Unless you can find someone to reply to questions here, that has specific information. I doubt the CK wiki ever see an update again, much less with useful information.

 

 

Ive gained a lot of experience just working on and with Navmeshj, but, I still dont know what half lot of the Navmesh commands do, and I suspect some of the commands might? even be bugged and may not work exactly as advertised.

 

Try to find a detailed explanation for the differences between the 3 different auto-gen options. No one else seems to know, or if they did, arent sharing it. Which is why every just says use auto-cast, lol.

[speedynl]

 

 

Try to find a detailed explanation for the differences between the 3 different auto-gen options. No one else seems to know, or if they did, arent sharing it. Which is why every just says use auto-cast, lol.

yea well auto is mostly enough to do the job

 

for most flat ext cell's after you have placed everything auto is fast and easy, it have mostly troubles with stairs, CTRL + F is your best friend when making navmesh

 

for int cell's its mostly the same thing

 

for wat i can remember the auto object will navmesh all the things placed, but not the hole ground( kind of collision)

 

for landscape its a bit harder, but again auto will do most of the job, use CTRL + F to find the errors, run find cover, to get hidding places when a fight start

the yellow things are jump spots(if i remember right)

 

best way to find out the difrent between the generation options make a int cell(drop some stuff in it) run auto see wat it do, remove navmesh, run auto object, the other 1 is most likely for advance landscape, it have ton of options(if you know how to use them), they all have use for someting, only i can't tell you wat, because i always used auto normal and checked the stairs + errors,

[hereami]

Those auto options on objects sound self-explanatory i think, Bounding box, Geometry, Ground. But Obstacle was an intriguing one, though unfortunately appears to require mandatory NIF support. Now that i look at my Cait still walking over/into coffee table etc. - objects that were in rose Precut areas - i suppose they don't work either.

[hereami]

Speaking about navigation AI, there's quite an interesting issue i've encountered, when running battles beyond habitated map borders. There seems to be no Navmesh outside there, as npc just stand still and companions refuse to do anything, if commanded (also they always have Player-anchor to Sandbox around, unlike others), but when combat starts, they can show wonders of tactical movement and use runtime-placed objects as covers. Also curious, that not every race is able to navigate (move) in such case - e.g. Stingwing, Dogs, Eyebots and else, but Humans, Synths etc. feel just fine.

 

Is there a failsafe navigation protocol, which does rely on actual landscape surface and objects, and only engaged in combat? Or a reason, why navmesh is ignored outside combat (if actually present there)?

 

PS. Also interesting case. When map borders were enabled, Dogmeat was able to pass behind, while player couldn't. And when i built a bridge from Shack foundations towards map edge later and disabled borders, sometimes he followed me freely on that path, but sometimes refused, and always refused to go onto landscape ground.

Edited July 3, 2019 by hereami

[hereami]

Maybe these days some light could be shed on this matter, regarding unused potential of navigation AI and its inconsistency among different races?

[LarannKiar]

Maybe these days some light could be shed on this matter, regarding unused potential of navigation AI and its inconsistency among different races?

 

Pathing is affected by the Race >> General Data >> "Use Large Actor Pathing" and "Size". How differently the game treats them is unfortunately unknown because it's hardcoded.

 

As far as I know, it's better to have bigger navmeshes (within reason of course).