3D Pathfinding Points Of Visibility

I'm not sure what you're asking. aren't the start and end nodes determined by where you are and where you want to be?

start: closest node to which you have a clear LOS
end: closest node from which your dest has a clear LOS.

I suppose you could have some spatial partitioning algorithm in place to hold your nodes and thereby search the local area first. Typically the number of nav nodes though will likely be small so a simple iteration to find start and end shouldn't really be that big a performance hit.

-me

As Palidine suggested, using the closest visible (existing) nodes is usually sufficient. However, it requires some post processing ("string-pulling"). In addition, it may not always provide optimal or natural paths.

If you really need to create new nodes for the start and end locations, here are some ideas:
- You can create the end node while searching. Every time your A* selects a node to expand, check if it's visible from the end node.
- In visibility graphs, nodes are located to the convex corners of obstacles. You don't have to check the visibility if the start/end node is behind the walls of the corner.
- There are some algorithms for constructing visibility graphs fast. Those might help checking the visibility between new start/end nodes and the existing nodes. However, those algorithms are usually limited to 2-D binary (traversable/non-traversable) visibility graphs.

-Jarmo

If you use a portal/sector based level structure and divide your level well, simple raycasting brute force should be plenty fast.