I downloaded armory 0.5b – and noticed the “Generate NavMesh” button actually works (although I didn’t do it right i’m sure, at least it’s showing up). In 0.6 it doesn’t seem to do anything. Someone tried to help out by telling me I just had to create a plane with obstacles, and a player, add a navagent to the player, and add a navmesh bundle to the plane’s traits, then with a node tree you could get it to walk around. Only problem is when I add a rigidbody to my player (just a cube) I can’t get it to move anywhere, and if I don’t the player doesn’t collide with obstacles.
- Did you make the rigidbody active?
- Did you check the “Animated” checkbox under Rigid Body > Settings?
- Did you add a node tree to the player with a “GoToLocation” node (with a location plugged in) or Haxe equivalent?
If you have these (as well as a NavAgent trait and a NavMesh) that’s all it should take…
Interesting thing here, when I check ‘animated’ on the player (the cube), physics no longer seems to apply. (For instance putting the cube up in the air, it won’t fall if animated is on). Whenever I add a rigid body to an object, it seems to be set to active unless you’re talking about some other setting. And yes the node tree does have a GoToLocation node.
Here is the blend file. exampleblend.blend (690.2 KB)
Keep in mind someone else made this real quick to help me out, as my original wasn’t working either. If you notice I put the cube in the air. I have animated checked on this which means i can click on the ground plane and move around, however, the cube goes completely through the other cube (the other cube is actually part of the plane mesh, which I didn’t do either). Since animated is on, physics doesn’t seem to affect it. If I turn animated off, then it won’t move to where I want it to move to, but will fall to the ground.
If this is expected behavior I would like to know that, but also, the player cube goes through again the “obstacle” that’s part of the ground plane mesh (so it’s all one mesh). It seems a “navmesh” doesn’t particularly work here since I was under the impression they were supposed to guide where an object could move to.
The final thing here is, if I create a plane, and give it a rigid body with dynamic turned off, and then go to “Scene->armory_navigation->Generate Navmesh” nothing seems to happen.
The animated checkbox will always disable its response to rigid body physics. I think it is meant to be used to allow you to step in and take control of the object manually if you want to programmatically disable its physics response.
I don’t know if that’s the expected behaviour, however from my experiments, navAgents only seem to work whith “animate” turned on. I suspect that you can basically have Bullet (the physics engine) control and object or recast (the navAgent/mesh library) control it, but not both. Even if you look at the navmesh demo file, you’ll notice that you get weird results if you lift the player character off the ground. That said, other active rigid body objects still react to it.
For example, if you add the NavFollowTree trait and the NavAgent bundle to one of the cubes in the demo, it doesn’t fall if raised up, but it does push the other cubes out of the way and go around ground objects.
It would still be cool though to have a navigation library that worked by applying forces in Bullet, even getting the character to jump if the goal was above them etc.
I’m making a 2d point-and-click adventure (operating in 3d space). You’re going to click or tap on things and the character’s are going to walk to the object, or location you clicked (or tapped). So I need it to do some pathfinding. I thought I could use the navmesh to do this for me so I wouldn’t have to write my own pathfinding code (since I’m not that well versed in that, although if I had to for my game I would, it’s just I’m thinking armory has things that make it easier or do it for me. Why re-invent the wheel right?).
The following was written first, which is why it seems this message is disjointed:
Okay, so, after re-running that example, it does seem to go “around” that other cube a bit, however, it still intersects it (as though the stationary cube had a smaller cube inside it) around the edges. It still manages to go around it though, not going through the center.
As far as gravity is concerned, for my purposes, I don’t actually need gravity (2d adventure game) however, that was the only way I knew to “set it on the ground”, that is if it falls via physics it makes sure the one object sits on top of the plane, rather than hovering above it or going through it.
Okay so now the question is, how come the Generate Navmesh button doesn’t seem to work. How do I make sure objects don’t intersect each other at all, if I’m using the navmesh? Edit: It apparently does work however it adds it as a trait to the plane and doesn’t show up anywhere.
I’m going to upload the blend file here and maybe someone can tell me what’s going on.
AdventureGameTest_00001.blend (769.0 KB)
I don’t see anything wrong with how it’s been done, @Uhfgood . I think that there’s just been a regression between 0.5 and 0.6 with the navmesh generation.
Have any idea what’s going on with my blend file (the one I just uploaded it ie AdventureGameTest_00001) ?
Hey, I am the one that created the sample file. I created it real quick and I didn’t really explained it, the idea is that you create roughly your surface with the obstacles as the navmesh, you don’t need to render this on game but use it only as a map of your “walking area”. And then put your objects over the obstacles. I have updated the example file to see if that makes sense.
exampleblend.blend (702.3 KB)
Just note that this is not probably the best use of navmesh but it was what it worked for me at the time. Although I didn’t continue that route as HaxeRecast (used for navigation) have an issue when exporting to Android. I am using a different approach (read here if you want more info)
1 Like
How is the (larger) player cube navigating around the (smaller)obstacle cube? Wait I see you did generate the “navmesh”. I don’t really have the skills to implement and use the pathfinding library into armory. Although this still seems to do the job just fine.
Still my own example seems to be doing something wrong because it’s not navigating around anything, and the size of the navmesh seems to be smaller than the plane. So in there I’m still not doing something correctly.
I should ask this, and maybe no one will answer, but could someone tell me if there’s a correct way to generate and use navmeshes?
As far as I can see, generating NavMeshes via the UI only seems to work in version 0.5 at the moment. You could try using 0.5 just to generate the NavMesh and then bringing into 0.6/0.7…
Gah. I need to file a bug. I just wish there was any easy way for a non-coder to skip forward / backward through a list of commits so I could isolate which one stopped the “Generate Navmesh” button from doing anything visible…
EDIT: Actually, after playing around more, Navmeshes do seem to work, although they no longer generate a visible mesh object when clicking “create navmesh”.
If you go into the navmesh example file and select the navmesh object (the object called “Plane” not the object called “Navmesh” 
) you’ll see that clicking “remove navmesh” stops it from working, and then clicking “create navmesh” makes it work again.
So I’m not sure why it works in the demo file and not in yours. I went through and tried to recreate the demo file and while it definitely created a navmesh for me, it seems that it isn’t aligned with the actual object. Agents go through some walls and hit invisible barriers where there shouldn’t be any. Yep. It’s definitely file a bug time.
Yeah, I noticed too that it did generate a navmesh, but it’s not conforming to the plane. I did submit an issue and included my blend file – maybe you saw it. Not sure if I did it correctly but it’s here: https://github.com/armory3d/armory/issues/1246