[Bug] Deleting NavMesh Holes causes Argument OutOfRange Exception

HarryOminous

Unity 2018.2.15f1, AC 1.65.2

Easy enough to recreate:

> Load up the 2d Demo

> Create a dummy GameObject, and add a Polygon Collider2D to it

> From the NavMesh, "Create new Hole", and add the newly created Polygon Collider to it

> Press "-" to delete the hole, and Unity will throw an Argument OutOfRange exception

https://postimg.cc/QBVCvybc

(The Object appears to be deleted, but after pressing Play it re-appears in the list)

As a small supplementary question, on the subject of NavMesh holes, while I'm here:

I'm currently working on a 2d isometric game using AC. I'm at an early stage, but I've got the core mechanics working, and it relies very much on carving holes in the NavMesh to make the 2d environment appear 3d (I know, I know, it would have been SO much easier if I'd just blooming well used 3d in the first place!)

Anyway, one thing I'd like some advice on, before I get too deep into level design, is what kind of likely limits are there on the number of holes you can carve before it starts to adversely affect game performance?

I appreciate that this is a bit of a "how long is a piece of string?" question, as it will be dependant on a whole raft of different parameters, but I've got the choice at this early point, of trying to create one large top level map (which I'd like to do, because it makes the game world more immersive), or split it down into a whole series of smaller interlinked ones

So, let's say a large scale map would have scores of buildings and objects, each with their own "hole" to carve in the NavMesh. Maybe a 100 or so objects. Does that seem feasible? I've got a sneaking suspicion that it's probably too much to ask, even with modern systems, and keeping the number of points on each Collider down to the barest minimum, but I thought I'd ask the question anyway

ChrisIceBox

Recreated - thanks for the clear steps.

Assuming that each object has 4 vertices, that'd be 400 verts added on top of the base polygon.  AC caches nav data where possible, and does offer a few options to reduce complexity - by way of disabling Character Evasion and reducing the Accuracy slider - but my gut tells me you'd still likely be dealing with too many vertices.

HarryOminous

thanks for the feedback chris. i'll go with your gut feeling and opt for the safer option then - cut the map into smaller chunks, each on their own screen

HarryOminous

Just a very quick follow-up. I've created a few smallish maps now, and already I'm seeing issues getting the player to move smoothly

Here's a screenshot of a park scene, with just 10 or so elements contributing to the NavMesh (I think I could probably simplify some of the shapes a bit further)

https://postimg.cc/vDbDxQC3 

If I have the Accuracy level set to 1 and Character Evasion set to All Characters, the player's pathfinding becomes noticeably laggy. With it set to 0.5, or even with it set to 1 and with Character Evasion set to None, it does become smoother

However I think my original idea of having one large world map would almost certainly not have been practicable

ChrisIceBox

Indeed - character evasion contributes a lot to performance.

It may be worth experimenting with 2.5D mode, as you can then rely on baked NavMeshes for your pathfinding.

HarryOminous

Thanks for the suggestion. I took a copy of my project and tried converting it to 2.5D, but although I can see how it would work for 3D characters moving on a static pre-rendered background, my use case is 2D sprites moving around other 2D sprites, and although I can conceptually see how that might work using a baked Unity NavMesh I couldn't quite get my head round how to get it working for real

I may come back and try again at some point, but as I've got things working in straight 2D mode (albeit with slightly smaller maps than I'd have liked to have) I'll probably stick with that approach for this particular game