Using NavMeshes instead of waypoints?

This gets harder and more complicated the more I read about it. On the other hand it gets clearer and not that magical any more. So to implement path finding in you game, merely path finding won't be enough. You have to translate the calculations into movements, meaning that you have to take into account that the NPC will navigate, hopefully, towards the right direction, and how it navigates, that's the really hard part where many have failed to implement.

I have read a little about waypoints, points that are placed in the environment and act as nodes on a graph, which defines the paths that an NPC may use if told to. One of the issues I'm trying to find a solution to, is how to make an NPC move elegantly enough when crawling on a wall. Yeah, the plan is that we'll have atleast one kind of wall crawling NPC that reaches for the player from a Z-direction (it's a platformer game, with 3D models and some use of the 3D environment). The problem is that the NPC could be anywhere on the wall and will probably crawl diagonally downwards to the player. Since the player is moving, the NPC will probably change direction all the time, due to the A* calculating a new fastest path to the player.
To achieve some kind of elegant navigation, I would have to place waypoints all over the walls, and that would be both computationally expensive and riddiculously unnecessary since the NPC won't use all of the waypoints.

Today I came across a very interesting article about using a navigation mesh instead, which seems so much more convenient, especially for 3D environments and for the wall crawling NPCs. One of the first questions that popped into my head had apparently allready been answered:
"But isn't it slower to do pathfinding on a navigation mesh?

Not at all. A navigation mesh is a graph, just like a waypoint graph is, and the core pathfinding routines are very similar. The difference is that a navigation mesh has a polygon associated with each graph node."

Navigation meshes have much more pros when compared to waypoints, and seems to be the better way for using path finding in games. I don't know when it began to be used, but although this article was written in 2008, a lot of games still use waypoints. I don't know if it's due to waypoints being more convenient for them or due to unawareness of navMeshes, so I need to read a lot more about this.

What's more to take into account is, how this will affect the collision. There're collision meshes especially for collision, and even if it's possible to use them for the path finding it's really not recommended. I won't pretend I know everything, but from what PaulT (the writer of that article) is saying about collMeshes, I get the picture that we'd be better off using simple waypoints.

And lastly but maybe the most importantly: how advanced is this? Am I diving too deep now? Will I even get this done in time? I tend to be naïvely positive about everything, which often makes it very hard to put my plans into effect.

Last week, one of my teachers lended me a book called AI Game Programming Wisdom, by Steve Rabin. I have to say that it's an awesome book! Totally worth every crown (well I do live in Sweden). There is a lot to read about path finding, especially A*, in this book, and there's at least one section/chapter about navigation meshes. More about important information sources in a later blog, but I hope to get a bit wiser after reading this book.