I once saw such an algorithm at https://www.redblobgames.com/​ unfortunately I cannot find it anymore.

The site is still an interesting resource about path-finding though.

Hey

Pathfinding might be an interesting subject but I`m not looking to master it (there are so many other areas to cover). I think I`m happy with dijksra, it is suited for all my current goals (the reason I`m mentioning pathfinding in my blog entry is because I really do believe that a human knows that a path can be traced between two points not by magic but as a result of some work done by the brain)

ok, so I`m saying obvious things, or at least they seem to be that way

ok, so I`m saying obvious things, or at least they seem to be that way

That's the question.
Once you try to turn your observations into code, you might see even ‘obvious’ things are not simple and require further thinking, as problems show up you did not think about before.

I realized this when i was working on physics simulation decades ago. Goal was ragdolls, but it showed even making a stable Jenga stack of capsules was a hard problem already.
My conclusion was: I know some laws of physics, and they are simple, but it does not help much. Once i try to verify our knowledge by using it in a simulation to reproduce reality, i see that i knew almost nothing, not even what the real problem actually is.

I guess your Terminator series form a closed loop of assumptions. A trial to analyze, but you never know if the outcome is just a simplification form unknown ignorance of involved problems. To break out from this loop, actually working on algorithms to replicate your models it would be the only way.

our mind will draw a straight line from the edge of the obstacle where the actor/unit is found to the opposing edge, on the other side of the obstacle in the direction where the destination is located. In the next step we will try to connect the two edges by following the outline of the obstacle.

This for example, contains a whole lot of assumptions. The simple function you describe relies on your human intelligence and association, which is exactly the stuff which is so hard to teach to computers.
What is an ‘edge’? How does your program detect or define such edges?
How do we determine the ‘outline’ of an obstacle?
And how do we differentiate an ‘obstacle’ from the ‘walkable world’? Imagine it's all just one mesh. Some soil for ground, and a tree grows out of it. If the tree is not it's own object, classifying it as obstacle is already quite hard.

That's the question.
Once you try to turn your observations into code, you might see even ‘obvious’ things are not simple and require further thinking, as problems show up you did not think about before.

Understanding means building a model out of things we perceive. It`s like building a 3d mesh out 2d images.

We perceive sounds and images and we transform that into an object in our head. The model in our head is not just the shape of the object but also various relationships associated with that object. Like if you see a car with its doors closed, you know that the car has doors (which in reality might be difficult to spot if the doors are closed, you will only see the outline of doors) that can be opened and closed, you know in your mind how that works. You have a model of a car in your mind with all it`s properties.

Our understanding of reality is actually various models that we have in our head. If the model in our mind of what we`re seeing is correct we will be able to further expand that model and link/build relationships with other models. If our understanding about something is incorrect than that`s a poor/weak model that remains isolated in our mind it`s just something that doesn`t make sense, all the talk related to that one subject is alien language we can`t understand. An example would be an salesman or mechanics engineer witnessing a discussion between two programmers about a programming related subject.

If the model in your mind is correct you should have no problems transforming it into code.