Search Unity

  1. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  2. Unity 2020 LTS & Unity 2021.1 have been released.
    Dismiss Notice
  3. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Unity dynamic navmesh generation built in!

Discussion in 'General Discussion' started by Tomnnn, Jan 1, 2014.

  1. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,156
    "Gossip" sounds like a great forum location to post my hopefully new find. I've been allllll over google trying to find this, and viola, unity pro has built in dynamic mesh gen and people don't even know it! Or some do, but none post about it in a way findable by google.

    Nav obstacles. Big ugly cylinders, right? Wrong! (at least, if you have pro, wrong)

    I attached those big ugly tube blobs to my wall prefabs and when my scene loaded them in... they carved holes into navmesh. BUT it ignored the shapes and used the prefabs themselves to carve the nav mesh! I tested this with a monster in the scene. It went right through walls that had no obstacle component, but went around the walls that did. And the walls that did have the obstacle radius set to only 0.06 yet the monster went around the entire wall. I've attached some screenshots for you to see for yourselves. It would appear that when you attach an obstacle component to a prefab in unity pro and enable carving, it uses the object's collider to do the actual carving!

    How many people knew this? Why isn't this everywhere? In the screenshots, the first one shows without my walls in. The second shows with 2 walls that have the obstacle on them and as you can see, the carving is around the box collider rather than the obstacle shape itself. If you look closely, you can even see the lines/triangulation/proper technical term being added in to the navmesh!

    In conclusion, for people who filled their fences and doors with little obstacle shapes to approximate the shape, don't waste the effort, it will use the colliders instead :)

    --edit
    Oh darn, it seems it's based on the mesh instead of the colliders. Still not too bad.
    Concept: Bake the navmesh as a giant square. Anywhere you want someone not to walk, place an obstacle onto a mesh that is the shape of the area or object you're using as the obstacle and enable carving. The navmesh will change.

    $Screen Shot 2013-12-31 at 9.06.15 PM.png $Screen Shot 2013-12-31 at 9.06.26 PM.png
     
    Last edited: Jan 1, 2014
  2. jmatthews

    jmatthews

    Joined:
    Jul 27, 2011
    Posts:
    199
    S as a workflow you'd just add the nav obstacle to all of your placeable objects. Then bake a square and place your objects correct? It seems the end product is the same as placing your objects and then baking, except when you're doing iterative testing or development.
     
  3. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,156
    Yes, except I added them at runtime and got the second image. My game generates a room which is a big empty room prefab with the navmesh baked, and then it adds in additional parts of the room which are prefabs that have nav obstacles on them. Then as you see in screenshot 2, the navmesh is recalculated.

    So for procedural open worlds, make your chunks prefabs with baked navmeshes, and then add your objects with obstacles in them and it will use their mesh to for the carving.

    I've run through multiple rooms now to be sure and it definitely seems to be working. I enter a room without any obstacles, it has the navmesh from screenshot#1. I enter a room that generated the inner walls to look like a different room, the navmesh appears as it does in screenshot#2.
     
  4. jmatthews

    jmatthews

    Joined:
    Jul 27, 2011
    Posts:
    199
    Got it. One concern would be that Nav obstacles are treated essentially like another navmesh agent with a high avoidance setting. This means that your navmesh agent(your player or mob ai) could be pushed into or through a wall via another actor.

    I'm building a MOBA-like game for a monthly game challenge and I needed to use a similar solution. thus far it hasn't been an issue but you'll notice oddness when your navmesh is moving around a navmesh obstacle.

    It's a nice hack though. Good find and best of luck with it.
     
  5. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,156
    so far so good lol. I actually modified the idea to have the collider not on the object but to make objects with meshes but no mesh renderers and put the obstacle on them. Then you get a better shape. The gap around the walls is now much wider so the ai have a very short path to walk through to avoid the monster having his huge arms clip through the walls when turning.

    If you're going with a moba, I would suggest making your own node system. In fact, I'd recommend nodes in just about any case. I only used the built in nav mesh just to try it out. Instead of packing obstacles onto my prefabs that make up the rooms, I think I'd rather put path nodes (empty transforms) around them. Just periodically place empty transforms along your lanes so the fodder can get through. Then maybe use the navmesh only for heroes since there will be fewer of them. Or you can probably just have colliders on your terrain and use a character controller type thing to move them. Either should be fine if your moba has a few heroes in game at once.
     
  6. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,514
    Last I checked a NavMesh was an essentially static part of a scene - you could only have one, and it had to be a part of the base scene (ie: if you load additively no NavMesh data is included). Is that still the case?

    It's very useful, but with some of the limitations last time I used it it was only good for very specific use cases. So it's great to know they're still working on it, and thus expanding the cases where it'll be useful.
     
  7. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,156
    NavMeshes are baked and static. But they can be baked onto prefabs. I don't know if multiple baked NavMeshes can be saved onto different prefabs, but the strategy for now is to make a large baked square that is the largest chunk you'll have in a procedural world and then carve down the NavMesh at runtime with a series of obstacles. For circular holes, attach a navmesh obstacle to a mesh that is a circle. Just disable the renderer and you'll have a hole in the navmesh.

    My game worked out as 5 combinations of walls inside 1 static room. My scene is empty before the static room is added at runtime. I haven't setup any "scenes" to be static. If anything, I arrange everything onto a big prefab and then instantiate that. It might be more overhead or something but I prefer this in all cases so far. I'll try making an arpg with a series of prefabs and see if I can get the navmesh on there somehow. I'll post back with results in a few days or at least before the 21st when college resumes.
     
  8. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    1,604
    You know release notes are a wonderful thing ;)

    But yeah no-one ever really reads them and even if you do they are frequently so generic that cool new features can be hard to interpret.

    A little digging in the script reference reveals.

    Plus some other useful information.

    Of course the question here is what is the bounding volume? A cylinder, a axis-aligned box, a OBB (orientated bounding box), a convex hull? I guess the assumption would be a cylinder, but from what you've said it may be a axis-aligned box, though it would be great if it were a convex hull.

    Its not clear from your OP, but have you tried different shaped meshes? Your screenshots strongly suggest axis-aligned boxes, which would be a shame, but better than nothing.


    This is one of my biggest issues with UT releasing unfinished features. I put a fair amount of experimentation into navMeshes when first released, but like many others quickly came up against issues, missing features etc and just put them to one side. Unfortunately I rarely get the time to revisit such features and so tend to miss out when they have been improved like this.

    So I just wish UT wouldn't release a new feature until it is deemed feature complete.


    EDIT:
    Ah, very interesting, I wonder does it go as far as producing a 2D projected convex hull then? I.e. the mesh can be any shape and a convex outline is created from it?

    Any chance you could package up your test scene so others could play around with it without having to build the whole thing themselves?
     
    Last edited: Jan 8, 2014
  9. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,156
    Oh.. yea, I guess that wasn't clear. It met my needs so I wasn't sure haha. I don't have many complex shapes to test with, but I threw these in. I got box-ish shapes. I rotated them randomly and got the results you see. I guess they are boxes, whoops. The sphere I added did not give me a circular hole, just a bounding square hole.

    As you can see in the second picture, however, they are not axis aligned. Also, if you rotate the objects a bit and raise/lower them, you can get more complex shapes. I got a circle-ish thing by rotating the circle a bit and lowering it into the nav mesh. It's even hackier now, but it works as previously described :D Sort of. I guess you'll have to parent those objects together under a gameobject and save that as a prefab to make certain shapes haha. But it is just a nav mesh, whether circular or square, the ai is going to wonky-walk around the gaps anyway.

    -edit

    I only baked a mesh on a big plane and then shoved random geometry with obstacles into it. This is made more clear by the latest screenshots :D


    $Screen Shot 2014-01-07 at 8.01.31 PM.png

    $Screen Shot 2014-01-07 at 8.07.26 PM.png
     
    Last edited: Jan 8, 2014
  10. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    1,604
    Interesting, though I can't really see any consistency in terms of the bounding shape in those screenshots. As you say its not axis-aligned boxes, its not even orientated bounding boxes, but its not a convex hull either. Strange, i'll have to take a look at it sometime as it does seem to make NavMeshes far more appealing for procedural games.
     
  11. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,156
    as you see in screenshot#1 (in the second set of them), the unstretched blue thing had a square under it. When I stretched, it got a rectangle carving under it. Seems to be as expected. but then...

    I started to rotate the other axis randomly, and the second screenshot happened. I did so a little in the first as well, but in the second you can see the same stretch but different rotation produced a completely different shape. Mid rotation, the corners got flattened, so I duplicated that, moved it over, and rotated the other axis and got that diamond shape haha.

    Make a strange mesh. Rotate it to get the carve of your liking. Save rotations and transformations of the object in a prefab. Use said prefab to carve the mesh in your scene.

    Hopefully that's clear to anyone else, if they have read the previous posts. But again, whether your navmesh is a square or a perfect circle is going to make little difference. The movement is still gonna wonkify the whole path so you snake around it and rotate strangle. It's ok for my purposes because the monster itself has unusual behaviors, but in an rts/moba/arpg the movement might be a little stupid looking.

    Also, please let me know how that turns out.
     
  12. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    13,514
    I think that roadmaps are a better option here. There's absolutely nothing wrong with releasing the NavMesh functionality as it was, and there's certainly no reason to have held off until they'd "fixed" limitations specific to my use cases. There are other projects where I've used the functionality and it's been of great use because the additional functionality wasn't relevant there. So what is "unfinished" to one person/project may be perfectly fine for another.

    What would be better is improved documentation about this stuff. It took me several hours to discover that NavMesh data couldn't be loaded dynamically/additively, which is something that a line in the documentation could have fixed. Knowing it ahead of time I could have planned around it from the get go and it never would have been an issue. As it was, I was pretty frustrated by the process. However, it still ultimately got done far faster than if I'd started by writing or finding and integrating a 3rd party solution, so it was still a win, and I'd still have been worse off if Unity had held it back until it did more.
     
    Last edited: Jan 8, 2014
  13. luciferzsw

    luciferzsw

    Joined:
    Jan 20, 2015
    Posts:
    1
    I have the same problem with you, you can add some child objects and add the "Nav mesh Obstacle" on them. Sorry for my poor English
     
unityunity