Native navmesh generation/pathfinding

[AmriaLeiah]

Is your feature request related to a problem? Please describe.

Pathfinding through Protoflux is a very very long and tedious process with no real way to do any of it in real time. Granted the ability to make such a thing easier and more reliable will come with the collections/array update I believe some sort of dedicated node would make things far more optimized even with the aforementioned update.

Describe the solution you'd like

A pathfinding protoflux node perhaps similar in function to the trajectory node? With a FROM Float3, TO Float3, and LERP Float input?

Describe alternatives you've considered

Manual placement of navigation nodes OR a manually placed A* navmesh. This is hardly optimal in any capacity and takes a ton of time and resources to calculate.

Additional Context

Any kind of algorithm would be better than the options we have now which is nothing but manual and without arrays.

I understand that pathfinding is currently possible in Resonite however it's even less usable and accessible than vehicles which technically aren't even a properly supported thing either.

Requesters

AmriaLeiah

[Frooxius]

It actually is possible to do pathfinding with ProtoFlux in real time - in fact there was an MMC24 entry who won in the TAU category that does this.

We can consider adding built-in solutions for this at some point, but this is a lot more complex than a single node. There's a number of different ways to achieve pathfinding and number of them do require manually placing navmeshes to help structure the environment.

It sounds like you want some kind of pathfinding that doesn't require any manual work at all? This makes this even more complicated problem, because the system will now have to rely purely on colliders in the world and somehow dynamically scanning the surroundings and figuring things out, which makes this even more difficult problem to have good pathfinding without any user setup.

[AmriaLeiah]

It actually is possible to do pathfinding with ProtoFlux in real time - in fact there was an MMC24 entry who won in the TAU category that does this.

We can consider adding built-in solutions for this at some point, but this is a lot more complex than a single node. There's a number of different ways to achieve pathfinding and number of them do require manually placing navmeshes to help structure the environment.

It sounds like you want some kind of pathfinding that doesn't require any manual work at all? This makes this even more complicated problem, because the system will now have to rely purely on colliders in the world and somehow dynamically scanning the surroundings and figuring things out, which makes this even more difficult problem to have good pathfinding without any user setup.

I'll check out that MMC24 entry, thanks,

For a built in solution I wouldn't expect perfection or even "good" if it didn't have much to go on other than colliders. I regret my choice in using A* as an example, because I guess more-or-less what I meant was "collision avoidance?" It doesn't have to scan ahead that far and determine the perfect route. Ideally any good system would have nav points set up ahead of time. A way to more easily navigate point to point would be ideal which is why I mentioned the trajectory node. It's merely that at the current time there is a lot of manual calculation done for even simple navigation. A very basic bare bones pathfinder that even at the minimum avoided floating in air or walking through walls would drastically reduce the navmesh density requirements and calculations required.

Sorry for my very poor choice of words and examples there, I realize my mistake. Oopsie!

[Frooxius]

We'd need to have it a bit better defined on what you actually want from the system.

Something like trajectory node wouldn't work, because that's pure mathematical curve that can be precalculated.

Calculating a trajectory in a world with arbitrary colliders with no pre-made data is... extremely complicated even to just compute the total trajectory start to finish (and not guaranteed to be even solvable). But the other problem is that the conditions and environment also change.

[AmriaLeiah]

Yeah you're absolutely right, I'm beginning to see the problem and really how it must be simplified more on top.

Perhaps the best solution to assist with this issue in calculations would be to add the collision hit direction or even hit point to the contact nodes? Unless of course this is already possible and I am not aware?

[lxw404]

This is definitely more complex than a single node.

The way that Second Life at least approaches this is with a dynamic navmesh rebuildling system which allows the user to decide when to bake the player navigable meshes into a navmesh. It also takes into account static and dynamic colliders in the environment which affect navigation of agents which you can see directly in the collision information of an object whether it affects the navmesh.

In other game engines, this is implemented abstractly as a way to query the "walkability" of the environment, the costs of certain paths through the environment, as well as group certain agents together, etc.

• Unity NavMesh reference
• Unreal NavMesh reference
• Godot NavMesh reference
• Stride NavMesh reference

In all of these cases, there is a way for the user to update the navigation mesh itself automatically with as little user intervention as possible other than to specify the bounding volume/group of a navigable area. The behavior of AI agents with this navmesh as a query structure is then usually down to the end-user's choice and can be more finely tuned.

From Resonite's perspective, this may come down to multiple nodes or a wizard to build a navigation mesh given a slot hierarchy with navigable colliders, and represent this structure in a way for other nodes to query in various ways such as FindClosestEdge, or CalculatePath, or many of the other queries you can do (further API references: Unity, Godot, Stride).

[shiftyscales]

Updating the issue title to be a bit more broad/generic- and highlighting the underlying request - some form of engine-native navmesh generation/pathfinding.