I don’t know about the way this Graph is implemented, but u can use the nodes’ features for each dimension as an index to access ur data like point-coordinates or whatever u need to calculate a cost for going along a specific edge.

To do so, feed ur ‘u’, ‘v’, ‘w’ used in the nested for-loop to the creation of the Grid-Graph. Then in the def ‘dist’ use the features (should be integers) to combine them back to an index. In ur case this would be a combination of ‘u’ , ‘v’ , ‘w’…

To make this mr precise, check out ur creation of the array testgrid. The node which should associated to the features (x=0,y=0,z=0) is the same as ‘idx = u+v+w’ where (u=0, v=0, w=0) … the node-features (x=0,y=0,z=1) corresponds to (u=0,v=0,w=1) > ‘idx = u+v+w’ again…

It become tricky when u look up for a node at (x=3, y=2, z=4), which would correspond to idx=(x*v*w + y*v + z) (monday-morning-uncertainty, not 100% if this is right)

If u get the idx calculated the right way, u can easily access ur grid with testgrid[idx], where u get the features of the points. From this u can calculate the euclidean distance the same way as allready done…

It would be more easy, and more general for higher/lower dimensions if u try to create a nested array within the for-loop. If u do it the right way the accessing the testgrid become more easy > testgrid[xi][yi][zi]…

BESIDE:

The A-Star is exactly the same algorithm as Dijkstra’s. It adds only a heuristic to approach the goal in a faster way, but also with more error to the real optima solution.

I do not know about the heuristic used within this implementation, but I guess it could be the ‘Manhattan-Path’… This works fine if u want to calculate ur cost in an euclidean manner. If u want to use any other cost-function (dist in ur case) I would recommend to not use (this) implemenation of A-Star and swicht to pure Dijkstra, so u can be sure that u know whats going on. If there is a hidden heuristic in there, u never know whats going on. U could end up with amazingly wrong paths…