I have been experimenting with unity 5 and the new WebGL builds. In order to do this i downloaded the latest beta pro version of the pathfinding project in order to get it to work in the first place.
However i have been running into a problem for the specific platform. Whenever i generate my recast graph at the start of my level, the browser assumes that unity has “locked up” and starts throwing unresponce script error at the user. Prompting them to stop the game/code.
Looking for the problem i figured out that the code just simply “takes to long”. Due to many compromises already being made to work for all the different platforms we deploy on, i am not willing to tune down the graph to get a faster build time either.
The generation code for some reason does not use coroutines. Changing the code to a coroutine helps inmensly (in that it works in WebGL, and doesn’t lock up the code) but causes nullpointers all over due to the code expecing the graph creation to be “done” after it was called.
My suggestion is that the graph scanning code starts using coroutines in order to prevent WebGL from locking up on it. (which happens really cast i might add). And using a coroutine whould be better in general, unless a seperate thread is available to the user (which WebGL does not support).
Any ideas on this and/or if this is going to happen at all?
Due to the nature of the long process i also made the RecastGenerator.ScanAllTiles method a coroutine to be able to yield return inside the tile generation for loop. This caused me to write all the way up to ScanInternal, making those ALL coroutines (everything in between! look it up it’s like 3 methods and then through the base class etc. quite a mess)
It seems to work… almost. But at the end of the whole thing i get an error on AstarPath.InitializeNode (it throws that exception there) that somehow it tried to initialize a node when something was locked/busy, i am not sure what since most of the thigns in that statement go into the magical world of threading (which is disabled at this point).
So at this point i am not sure where to go. I am fearing that the project is going to fail if i cannot resolve this issue. But i just can’t get it to play nice with the coroutine. If you have any idea what is going wrong, i would like to hear it.
EDIT: I would like to point out that it starts going wrong inside RecastGenerator.ScanAllTiles upon calling BuildTileMesh();
It crashes in there with the InitializeNode thing. Hope that helps?
EDIT2: The method should work exactly the same being a coroutine, i do not get this at all. I made sure i used Yield return startCoroutine as well. I am at a loss.
EDIT3: More testing shows that this only goes wrong after 118/119 out of 256 tiles. I am not sure if something is on a timer or on a wait, but that doesn’t make a whole lot of sense.
EDIT4: It seems to break in RecastGenerator.CreateTile, in the loop where the comment reads: //Create nodes and assign triangle indices
on this loop it has more then 0 length, and then crashes on creating the TriangleMeshNode. Any idea why this is?
Hm, I think I know what it is.
During Update(), the AstarPath class will run PerformBlockingActions to process any graph updates and similar, however after that it will always unblock the pathfinding, which obviously will cause problems if you are scanning at the same time.
So I think that you should try to put the contents of the Update method (in the AstarPath class) inside an if checking for if isScanning is false.
Ok, so after testing we have made the following discoveries:
We can’t seem to build with navmesh enabled but Exception catching off.
Wish Exception catching on full, the functionality is fine
Loading time from the game went from 20 seconds to 5 minutes and 40 seconds
5 minutes of said loading time is navmesh generation in WebGL
path calculations went from 5ms tot 50ms averages on WebGL as well (not that bad in usage though)
Multiple seekers on the navmesh calculating a path every 0.5 seconds (to find an exit it checks every so often gets very very very slow. We assume this might be debug logs about those paths being recalculated. But we have not tested this further.
We hope you can ammend these problems in the future, so please keep us up to date with any developments in this area or any suggestions you might have to improve on the code.
As for the changes we made to make the generation work for us on WebGL, if you are interested we can send you the files as is, since they are your classes, we assume you know what to do with them from that point.
Yeah, this should definitely be improved if turning on exceptions is that slow.
Is it possible for you to see what exceptions cause it to fail? I cannot think of any exceptions that happen when scanning the graph.
As for the exception on/off thing, i cannot find the exact post. But it seems to be common for exceptions ON == nothing is wrong. And exceptions OFF == some error/exception that crashes it which is not catched. It is pretty horrible at this moment.