The Mixed Reality Forums here are no longer being used or maintained.
There are a few other places we would like to direct you to for support, both from Microsoft and from the community.
The first way we want to connect with you is our mixed reality developer program, which you can sign up for at https://aka.ms/IWantMR.
For technical questions, please use Stack Overflow, and tag your questions using either hololens or windows-mixed-reality.
If you want to join in discussions, please do so in the HoloDevelopers Slack, which you can join by going to https://aka.ms/holodevelopers, or in our Microsoft Tech Communities forums at https://techcommunity.microsoft.com/t5/mixed-reality/ct-p/MicrosoftMixedReality.
And always feel free to hit us up on Twitter @MxdRealityDev.
Pathfinding against Hololens Spatial Mesh? - Unity
Jarrod1937
✭✭✭
Admittedly, pathfinding is not one of my strong areas. From what I can tell, the path finding built into Unity is done via a NavMesh. Others (via plugins) rely on grids...etc. The one thing these have in common is that they require precomputed generation of data for the pathfinding to work.
Obviously, in the Hololens world, pathfinding needs to be 100% dynamic, as the entire environment is dynamic. Are there systems out there for this? I'd assume a bruteforce A* implementation could do this, not sure.
It looks like this may do the trick, not sure:
https://www.assetstore.unity3d.com/en/#!/content/17943
Designed for dynamic pathfinding. The script has you define your "terrain" layer which it uses, I assume this would be the same layer we assign in the Spatial Collider script?
Answers
I'm assuming your are talking about this for the game idea you brought up in another thread, if not, disregard
While any good pathfinding system should allow for dynamic environments, especially now that terrain deformation exists in a lot of games, I would think that with the Hololens, the better approach would be to have the user scan the environment first. Allow them to move from room to room simular to how RoboRaid and Young Conker work with the hololens. Build up an environment then turn the spacial mapping off while running the game, but use the saved environment for the game.
Keeping the spatial mapping enabled while playing the game might cause issues if someone walks across your field of view while playing, causing them to pop in and out of the spatial mapping at whatever interval it is scanning at. This causes even more problems when they get scanned, then you no longer look at that location. You end up with a ghost mapping of where they use to be.
Just some thoughts
Ah, that is an interesting thought. Would speed up a lot of processing as well. I'll give that a try when I get to that point... And yep, it's for my game idea, how did you guess? ;-) My work project, while interesting, isn't as challenging, so the game should be fun.
Hi @Jarrod1937,
You are correct that Unity does not offer a dynamic pathfinding solution, since their navigation system requires that you bake the navigation data first. The store app that you linked to looks promising, but you should check with the developers to see if they generate their navigation mesh based on terrain objects, or if they can use a collection of meshes instead (which is what you'll get from spatial mapping data).
Another solution from the Unity store is the A* Pathfinding Project by Aron Granberg. It looks like it has good perf, which will be critical if you are constantly updating the spatial mapping meshes. There is mention of a free version in the feedback section, but I could not find a working website with the download. From what I have read on the forums, this project will accept meshes as input, so you should be able to use it with the spatial mapping data.
Another approach is to roll your own pathfinding solution. For a side project, I planned to use A* pathfinding. I started by creating a navigation grid based on the extents of the spatial mapping mesh. Each grid cell was the size of the character's extents. I then classified each grid cell as 'walkable' or not, based on the normals of the mesh (I checked multiple points within each cell to determine if the terrain was flat enough for navigation) and also verified that the character could fit within the cell without bumping any mesh above or on the sides. Once you have a navigation grid, you can then use A* (or another pathfinding algorithm) to determine the navigation path from point A to point B. I started working on a different project though, so I have not finished the actual navigation work yet
If you plan on having users scan an area once, at the beginning of their session, then you can generate the navigation mesh at that time and re-use it. However, if you plan to use a continuous scan (updating spatial mapping every ~3.5 seconds), then you'll need to consider performance costs and decide how often and/or when to update your navigation mesh. This will be tricky, so you'll want to become good friends with coroutine.
I hope this helps,
~Angela
Great, thanks @ahillier, a pretty comprehensive answer. I read through the A* Pathfinding docs, definitely seems like a very well thought out asset. You say it can accept meshes as input, how do I grab the generated spatial mesh in code to feed it to A*, looks like the easiest is by using spatial source script from the Holotoolkit?
It looks like generating a navmesh at runtime is still slow, around 2 seconds, however a grid graph is pretty fast to regenerate... but may be more memory and processor intensive for the path finding, oh the fun of trade offs.
Apparently I can't post a link to the free version... The forum sends my post to moderation. Let's see if this works:
arongranberg dot com/astar/download
Edit: Alright, making progress. After researching, I'm going to go with the Apex Pathfinding I originally linked to. It looks like it supports generating a new path navmesh at runtime and simply has you input which physics layer is the terrain/environment. It looks like the spatial mapping collider given in the Holotoolkit for unity also exposes a physics layer for you to select, I assume for the mesh and bounds to be applied. I haven't tested it yet as I can't run the emulator (Win 10 home and not sure if the hardware meets the requirements). However, I am making progress. This is the sort of thing I'll add to the Wiki when I get it working, will save others time I'm sure.
Did you managed to get it working with Apex path? Just wondering since its not the cheapes asset jsut to try it.
No, I had to switch to another solution. The only annoying thing about developing for the Hololens is that they're using UWP, which is .NET based but not fully .NET backwards compatible. So, it can be tricky to find solutions that are UWP compatible or UWP specifically. Since a large amount of Unity assets are closed source, one cannot try and fix such issues.
The path finding solution I got semi-working is, Simply A*. It's not as nice as the Apex option, but it works in UWP and is free, just requires a lot more tweaking. I never got it fully working to my liking though. The code seems to have a built in offset, which I haven't been able to remove. If you tell it to go to point A, it will stop say, 0.3 meters from A. It has a few other oddities, but it roughly works.
In working on projects, I found it mildly annoying that so much time has to be spent working on path finding. Considering a lot of us are one or two developer teams, the premade solutions are key to getting things done in a timely manner (a gentle poke to Microsoft ;-) I actually have been working on some VR projects, and they're going much faster because of this.