Інсталювати Steam
увійти
|
мова
简体中文 (спрощена китайська)
繁體中文 (традиційна китайська)
日本語 (японська)
한국어 (корейська)
ไทย (тайська)
Български (болгарська)
Čeština (чеська)
Dansk (данська)
Deutsch (німецька)
English (англійська)
Español - España (іспанська — Іспанія)
Español - Latinoamérica (іспанська — Латинська Америка)
Ελληνικά (грецька)
Français (французька)
Italiano (італійська)
Bahasa Indonesia (індонезійська)
Magyar (угорська)
Nederlands (нідерландська)
Norsk (норвезька)
Polski (польська)
Português (португальська — Португалія)
Português - Brasil (португальська — Бразилія)
Română (румунська)
Русский (російська)
Suomi (фінська)
Svenska (шведська)
Türkçe (турецька)
Tiếng Việt (в’єтнамська)
Повідомити про проблему з перекладом
Правила і настанови обговорень
Поскаржитися на цей допис
Basically every time a region has to be loaded from disk, the Navmesh is loaded faulty.
It seems that once it has been loaded and then repaired, it stays repaired as long as it stays cached in memory.
I did not yet have a single missing recruit or shopkeeper since I started asuming "broken on load" and manually fixing it.
I asume part of it is saved in the Savegame itself, wich does make some sense (especially for the palyers base).
Ogre3d in Kenshi might be automagically generating a navmesh on load. I dunno. And, the Rebuild Navmesh script probably does generate a navmesh that overides it in memory, but it could also be using an entirely different, maybe even purposefully more accurate, algorithm to do that. (Recast?)
Question: Have any of you encountered an obvious navmesh/collision mesh issue that only involves what appears to be the base terrain? IOW, not one of the embedded rocks/trees/whatever, but just what appears the contiguous mesh of the base terrain?
(Yes, it could be kind of hard to determine what that is. Just rotate the camera and finagle it until it dumps itself below the terrain. :) It's pretty easy to tell at that point. Stuff poking through ain't it... probably.)
<Safe to ignore the below, thinking out loud here without much true knowledge of Ogre3d.)
AFAIK, which isn't much, every time your view encounters something new, it's built in real time and all the navmesh, etc as well. And, when you leave an area/chunk, it's unloaded. When you re-enter an area, it's entirely rebuilt. AFAIK, Ogre3d can use stored navmesh data/file info. But, stated also in ignorance, it doesn't have to and/or can or will autogenerate that information.
As any gamer knows, collision meshes/navmesh/valid pathfinding data can be "wonky." And, typically, it's due to the density of the data in "that one place I always get stuck" in a game. A particularly dense object/area, a buch of vertices crowded together at an intersection, etc. And, "measurements" often matter. Everything's relative, so scale is necessary as a standard. ie: 1 meter = xx. And, if things break down to centimeters in your 1 meter only world? Ungood. And, if you're using inches, your planetary probe's chute will open after it impacts the ground instead of before...
Doorways are pretty complex things... Stairs are worse. And, combining them? Well, there's a tiny door and narrow stairs. So, there's a navmesh that gives a set of numbers for possible paths and then there's component that provides borders to keep characters from inadvertently getting stuck on an edge. With some building models, I notice constant issues with impossible paths, resulting with stuck characters that haven't been discouraged from taking those paths by a border element. Maybe it's too tiny an area for the chosen scale for the algorithm to calculate effectively?
Wearing a Wooden Backpack in some stair/door configs seems to increase the likelihood of getting stuck during AI-only controlled path generation....
AFAIK, Recast is an open-source additional navmesh/pathfinding generating algorithm from a Crysis developer. It is very accurate. Again, I'm ignorant, but maybe CTRL SHIFT F11 is a kludge to use the Recast algorithm instead of whatever is native for "automagic" Ogre3d (whatever version the devs used) navmesh generation? The current focus navmesh gets saved in the saved game file, the rest does not and is generated by the internal Ogre3d library on load? (Going to experiment, here, to see if CTRL SHIFT F11 bloats the saved game file with some saved, more accurate, different navmesh...)
And, why the thoughts? I'm wondering what the best way is for me to create "clean" 3D buildings/objects and terrain additions for Kenshi in considering how it creates/uses a navmesh. I don't want people to get "stuck" on anything. I want to understand how best to provide it what it needs if I have to rely completely on its navmesh generation.
After that all Navmeshes (broken or not) seem to be stored into the savegame. I never had a Navmesh recreated faultily from Disk.
When the Navmeshes are saved broken, they are broken enough that Shopkeepers and other NPC seem to outright vanish. I asume something like "falling through the ground". But even since I noticed they seem to start broken and go out of my way to fix them, there isa whole lot less characters vanishing. And I actually met a bunch of new Characters (people I asume had vanished in my Previous games before finding them).
I have not yet tried to run 2 ingame weeks around a city to treally stresstest if that is the cause, but I will try that next.
First, this:
I knew it! I knew that tool wasn't reporting what it said it was reporting... I had written my above post several times. I guess I left out that bit. Anyway, my original thought for posting was to point out that before one can believe what a tool reports back to you, you have to know what its doing. IOW - You have to be measuring what you intend to measure. (Principle of experimental design, etc..) The CTRL SHIFT F11 tools reports back on "buildings fixed" but that's junk reporting, the equivalent of "Did stuffs, keep playing." ie: I'm certainly not taking it on its "reported" words without knowing what the words mean. :)
How do you know the navmesh saved in the saved game information is not "faulty?" Are you sure it's saved to the saved game files? That seems a bit strange. I'd assume that it could be a QOL issue for one's first load of a saved game, reducing the time that the current focus viewpoint needs to be taken for enabling play by supplying a navmesh/patfhfing. But, that's something the engine should do anyway every time an area is loaded, so it doesn't really take very long.
(For an "all shortest route" thing, exposed chairs, tables, would be needless and clunky. An "area" would be excluded as being inside a "building.". For raytracing, the presence of the building walls would simply block that ray and the interiors would never be considered no matter what they contained. It also responds quickly to new obstructions no matter what's "behind" them on its path.)
I don't know how Ogre3D works, so anything I say is in ignorance and should be viewed as completely BS. But... :)
I read a little on it, here and there, this afternoon. Let's say you never leave a chunk of the game that gets unloaded. No additional navmesh will be built and the one you're using right now will never change, ever. (Without verification, I don't know that any navmesh info is saved with the saved game files, unless you're saying you've looked at the data.)
However, unlike a great many games, one can have multiple focus windows that can be viewed. (Perspectives of characters) Something in a 3D engine, somewhere, is going to calculate a bunch of "extra" things when a focus window is used for the first time on an area. AND, every single time an area is loaded in the game, it's "the first time." It's all "brand new" even if it's the same road you've been traveling back and forth on from The Hub to Squin all day, today.
<wrote a bunch of stuff, deleted it>
I don't know everything the navmesh generator is using for each required task... IOW, I think the game forces a new navmesh to be generated any time an area is loaded, no matter how many times you travel through that area. And, there's a different LoD that supplies that data or, certainly, something with less rigor for unviewed travel. No need to generate more exactitude than necessary to get the job done.
I don't know that it's possible to "fall through the ground." I haven't seen it happen and I don't know that Ogre3d/Physx/whatever would do that. It might be possible to get "trapped" by clipping through and then running into collision objects, though.
The primary takeaway right now is that the Navmesh Rebuilding Tool is NOT reporting what you think it's reporting. :) (What "we" thought it was reporting, even though I thought it was lying about that the whole time. I just couldn't prove it.)
When it says it's found umpty-buildings done wrongly and that are now fixed, that isn't about fixing collisions, navmesh, or pathfinding, necessarily. It's about fixing what's visible, either to the player, display engine, or, perhaps, to the pathfinding engine. For pathfinding, if the player doesn't have to go into a structure, you don't want the engine having to include the structure and all its contents for pathfinding considerations, since that could be slow things down depending upon what pathfinding algorithm they're using. It's a bit of code that got added that generates those "values" as in "number of buildings "fixed."
They're going to be updating to a newer version of Ogre3D and including some new pathfinding stuffs.
SOooooo... the issue we may be seeing now may magically go away. Or, at least be reduced in severity. Look for an upcoming patch that's fifty-eleven jiggabits huge and that'll probably be it. :)
I know this isn't very cohesive, but I need to read up on some stuff in order to avoid making a bigger idiot out of myself in public than I usually do... And, I want to experiment a bit to see how the game "appears" to act when it's doing stuff. For one - Does it appear to get confused when generating a navmesh, heightmap, etc, as different levels of detail are required? Does something seem to hang out in memory and end up borking something up during the engine's regeneration of a navmesh? What's the scale being used? Is THAT the only difference between different states, unviewed travel vs viewed travel? And, what about "extremes?" Why did that group of traveling npcs warp/disappear when I finally got near them? Across a different chunk and despawned or warped when it fully loaded? I dunno. And, when I first meet them, they're using a different heightmap and have confused pathfinding, too, until the focus settles down and loads everything up correctly. Why? /shrug :)
PS - I don't know if it's possible for the game to "disappear" a generated NPC due to a "physical" problem, like heightmap, collisions or navmesh/pathfinding issues. It is certainly possible, though, to "warp" any mobile object that interacts with these things. But, as in Shidan's quote above, we can assume that most building interiors are intended to not be loaded up and working on all cylinders at all times, so NPCs in there wouldn't be acted upon by anything. At least, the intent is that they shouldn't and, so far, what I've seen in game behavior seems to confirm that. The rebuild navmesh added script may be a fix for problems where this happens, though.
Fix Navmesh does something it finds worthy of reporting.
A lot less of the Race Condition looking "NPCs vanish" happens.
Even if correleation does not imply causation, it can at elast help figuring out the cause of the race conditon.
Facts I got from observation:
- multiple starts in the same region always come with a faulty Navmesh from the start. Like "on the Character Creation Screen"-from-the-start. So it is not stored application wide
- revisiting a area does not regenerate the Navmesh from the source that requires the fixes.
- the state of the world is modifiable. Both Town Overrides and Player Bases require a different Navmesh from then on. So storing the navmesh in or with the savegame just makes sense.
Adding functionality like this when it seem sensible is part of the job of a Programmer.
As I said: It makes a ton of sense to store this data in or with the savegame. If I had a programm like this, storing it there would at least cross my mind.
And as long as Ogre3D supports extracting and injecting Navmeshes and related data, I can do it.
It is the logical solution to a specific Problem encountered by the Application I had built.
Of course. All I was saying is that the tool appears to report it fixing buildings and it's called the "Rebuild NavMesh Tool." However, apparently the "number" of buildings fixed isn't directly related to the most often interpreted function of the tool. So, if it finds and fixes "12 buildings" it doesn't mean those 12 buildings had bad NavMeshes. It means there are 12 buildings/objects inside that were not properly hidden and it fixed that, the reported number generated by a script added later. (If I understand that quoted post correctly)
A stored navmesh for a default start configuration makes sense. But, from what I read of Ogre3d, it rebuilds the Navmesh for areas that are not currently loaded. The Player Base "might" always count as one of those, but I would think that, instead, it's only considering where player-interaction mobile objects are located. (A base might be coded like that for some other reason, though.)
AFAIK, the focus area and the immediately surrounding regions are loaded, with the highest detail being current camera positions and the surrounding areas will be generated with events, basic LoD stuff, etc. It's possible it's generating navmesh for those for some reason, but dunno why.
Understood. Fast load is a priority and it makes sense for recorded positions. But, it wouldn't make sense for some region that wasn't currently in focus or in the boundary regions around that.
[quote[As I said: It makes a ton of sense to store this data in or with the savegame. If I had a programm like this, storing it there would at least cross my mind.[/quote]
Maybe, but storing it "all" would just be redundant from what I read of how Ogre3d works. BUT, it could have always have changes made to that by the devs.
Last post on page 1 by Duststorm: https://forums.ogre3d.org/viewtopic.php?t=70799
In effect, "yeah but why" I guess? Some specific instances, though, like fine-tuning doorways and stair collisions maybe. (That was my main concern when considering modeling and navmesh issue experienced in Kenshi so far.. Creating a buffer area in such a tight space to keep characters from "sticking" to the doorway/stair intersection.)
If you could access it or figure out what sort of conventions could be done,/ yeah. I don't know what we actually have access to, though. Ogre3d can do it, but can Kenshi? /shrug
It helps with the rather common case of Town overrides and Player Bases.
And it is just normal caching implementation to first look for a resource in nearby source (like the savegame). And either deliver it from memory or create and then save it. Especially if the creation has any CPU load, this can be interesting.
Caching as your Webbrowser is doing (both your normal Webbrowser or the one Build into Steam).