Hi, was wondering if anyone has looked into procedural generation,
and then specificly with Unity Navmesh…
I wanted to try and make some random levels, or endless levels,
but from what i can find, unity does not support realtime navmesh baking,
only seem to be able to bake NavMesh in the editor…
Did find this on forums from other people trying the same;
But from the looks it supports only 2020.1, alas im using a newer version…
Also saw an asset which makes unity support realtime mesh baking,
but that really kills the FPS i read, so does not sound very performant…
Does anyone happen to know of another solution i just did not run into?
With the NavMeshTools package you’ve linked, you can indeed generate the NavMesh in runtime. I’m using the latest version of the tool (2020.1) in a 2021.2 3 project.
With the tool, there is a slight change to the workflow. You don’t bake at all in the Editor window. Instead you put a NavMeshSurface on a GameObject within the scene. Baking is still not automatic, you have to call a method to bake the Mesh. In my project, I generate the entire level procedurally (using an asset called DunGen). Once the level is built, I call the bake method on the NavMesh and then tell the Fader to FadeIn. By the time the Fader is done and control is released to the player, the mesh is usually baked.
The plus side is that you can have multiple NavMeshes in a scene, and you can use multiple agent types. This means you can have different sized characters, some of which cannot go through certain doors, etc, depending on settings and size. Handy if you want to have an Ogre in the scene who shouldn’t be able to fit through the door.
It also allows you to do things like doors that can be opened or closed, by rebaking the NavMesh. If you’re planning on doing things like that, make sure your scene isn’t massive, because baking those meshes isn’t cheap. On a small scene (like the ones in the Course project), the baking is fast, and you don’t really notice it. Every doubling in scene size, however, causes the mesh generation to take four times as long.
Oh that does sound great, would open alot of options!
I was at this point even thinking about dropping NavMesh and trying for other pathfinding solutions…
Alright thanks again Brian, if it works on newer versions of Unity too,
then i will just import the package and test it out after all!
I’ve done both at times. In a turn based/tile type game, rolling your own actually works better, since the NavMesh doesn’t respect the centers of tiles. I did that in an older project, a turn based hex tile RPG. Rolling my own let me change the color of each tile based on whether or not you could move to that position this turn. For open navigation scenes like we present in the course, however, you’ll be banging your head against the wall trying to roll your own. You’ll never beat the NavMeshTools because they have access to lower level optimzed code that you don’t.
Yeah thats probably true, im not at a level of programming where i could beat that lol.
Tile based seems indeed doable, also did a little of that in the 3d course, breadth first search.
Since the NavmeshTools works, its no longer an issue luckily,
i havent run into other “downsides” of unity’s standard A*
Also tried just lookAt and MoveTowards, but that is really boring gameplay,
if you dont add some kind of intelligence to it.
And an AI asset i got in a bundle at some point;
which is either transform based or physics (RB) based.
Then i tested the Polarith AI and Unity’s standard A*,
the polarith ran at half the FPS with 100 enemies of both.
So that might only be nice for a limited amount of enemies, if you dont want to use a navmesh,
not for what i have planned.