Where there are important places like entrances, exits, stairs you will need clickable meshes. Corners and splits in the path just need vector3s for there position. These meshes will have positions. Form your nodes as a list of vector3s including clickable meshes positions plus corners and splits.
Hi guys. John, that would be a âpre-ordainedâ path followâŚpre-determined âpathwaysâ between important nodes.
One problem with that⌠is⌠if you change the model, you must update the pre-made âhighwayâ paths.
Other problem with that⌠scene-code will need to find the path⌠to GET-TO the highway, too (an on-ramp). We never know where the nav-mesh will be standing. It could be far from the highway, standing upon a desk, in some back-office somewhere.
Better⌠to have âarbitraryâ system, one would suspect. Not easy, I assume.
Letâs say⌠all walls⌠had actionManagers⌠checking for onIntersectEnter⌠of an invisible sphere that surrounded the player. Then anytime that triggered, the âsmart-wallâ would push-away the player⌠somehow. Possibly surround player with 4 invisible spheres, and smart walls watch for intersect on all 4 spheres⌠so it knows which direction to push player âawayâ from wall.
SO, when standing-on-a-desk-in-some-back-office user ⌠says âtake me to the foyerâ⌠the navMesh simply heads-off in the bee-line direction⌠but the walls keep forcing the player-in-an-invisible-bubble⌠(or surrounded by 4-8 intersect sensors) along ONLY âhallwaysâ. The player would NOT appear to be bouncing off the walls the entire trip, because the surrounding âintersect encasement bubbleâ is larger than the player, yet still not too large to travel hallways/doorways.
Still might be problem for low-height and hanging-from-ceiling obstacles⌠as the surround-the-player intersect sensors⌠would probably be âaround their waistâ and maybe spherical. But maybe better⌠4-sided cylinders (vertical sticks). Then a low street-curb could be seen as an obstacle, and so could a hanging planter. 8 invisible sticks, and each wall has 8 onIntersectEnter triggers on its actionManager⌠for knowing which way to push-away player⌠in its executeCodeAction intersect-handler. Wow!
Likely over-kill for Anesâ project.
Nah, that would never work, but itâs fun to think-about. Ray-radar, I suppose. erf. Ray-radar really gets perf-expensive when navMesh must go over and under things, and not only lateral path-finding. I donât want to think about it. sigh.
MeshDoppler 1.0 erf. 
Use Jeromeâs basic-intersect power for SPS⌠and spray invisible SPS triangles (facets) out in-front-of the moving player, and watch them for intersect with obstacles? heh. hmm. Maybe just a âburstâ of particles at move-start-time and at change-room times⌠to get a âvirtual modelâ of the room? I dunno.
You are correct. I like to keep it simple, like me. A here is a maze find all possible routes, save as a network graph then do paths between points is an all together different ball game.
I was definitely thinking of here is my model and its not going to change for some time situation.
I think Anesâ metro station is not going to change quickly Feasibility of a 3D interactive visualization under babylon.js
@JohnK even if I made clickable meshes I canât click them if I âSubmergeâ my station with small cubes like this :
where the yellow path is from the start to goal node, so I said that I will âcoverâ my station with small cubes like magic cube and then mark the places where there is no possibility to draw paths with black color and I make the roads and stairs where I can walk with white color and then hide this big magic cube, the a* algo is implemented inside.
the problems are :
- it is not pratical to cover all the hole station with small cubes (the idea with small cubes that there is no edges or in other words each time the edge is the currentNode + 1, because the nighbors in 3d are 6 at x+1, x-1, y+1, y-1,z+1,z-1 so the nighbors g is always the current g + 1 and then the drawing path will be a liste of the nodes themeselves, there is no edges between them or let us said that there is unitary edges).
- the second problem is that if I cover all the station with cubes, even if I hide them all, I wont be able to click the ground because hiding meshes exist physicaly in the station
Anes, I think John implied earlier, that you use NO boxes/cubes⌠but store an array of vector2âs or vector3âs⌠of the POSITION where each yellow path-box was located. (Ya really only need to store X and Z values, and always keep Y at zero or at center-height of player.)
So, no boxes/cubes⌠but instead, build a database (array) of ânodesâ⌠positions. Now your floor can be clicked again.
When floor is clicked, grab the position of the click, and then iterate (for/next) thru your list of nodes⌠to find the one that is closest to the player (Vector3.Distance()?). Just after the floor-click, you might need a thing⌠um⌠unProject() ? ⌠to convert a scene pick-location (x/y)⌠into a world coordinate (x/y/z). Not sure.
Then animate the player to that closest node (which COULD take the player thru a wall or two, if not careful, unfortunately), and then the âmoving sidewalkâ system takes the player the rest of the way. Once the player gets-to a node on the highway (in your array)⌠the highway itself moves the player to the wanted location.
But, if I remember correctly, you want to SHOW the user⌠which way to walk, to get-to their wanted new location. So, no auto-moving highway/sidewalk, but lines-mesh or similar⌠could âshow the highwayâ. I would use floor-dots/markers⌠instead of lines. One marker per stored position in the positions array.
At least I THINK thatâs what John implies. Work with an array of positions, and not actually mesh.
Perhaps decals⌠would work nice⌠if you want to âshow highway nodesâ for player or self. Decals put a decent image⌠onto the surface of another mesh, even if that mesh is already textured. So, being able to activate a âdecal dotâ (marker) at every position in your highway array⌠might be handy for you, and useful for player, later.
These decals MIGHT be clickable or actionManager-able, but⌠I doubt it. Itâs not in their nature⌠not without putting a thin "disk mesh " beneath. And if you need a little disk-mesh, might as well say goodbye to decals, and just make a bunch of instances of a low-height cylinder/box⌠to place on the floor as node-dots. That might be a better idea than decals, but IF dots are pickable, floor beneath dots wonât be pickable without using âmulti-pickâ operations.
This is similar to your many-cubes idea, Anes⌠but just little boxes/disks, very very low-height⌠with some space between them. A good SPACING rule-of-thumb might be: When user stands upon ANY marker/node, user should be able to âseeâ at least ONE other marker/node.
Spot on.
Hi again @Anes, hopefully you may have found a solution to you path problem using the navigation mesh.
For future clarification on the method I was suggested I have produced a PG. It is rough and ready and for proper use it will need refinement.
https://www.babylonjs-playground.com/#BC8IWV#9
Set the start and end points (0 to 10) on lines 278, 279
The design process is
Create the buildings (or maze or whatever) with access points - red objects in the PG.
Number the access points.
Draw a plan of access points and possible paths. Number the corners, (way points, junctions, decision points or whatever you want to call them). The are the nodes for the Dijkstraâs algorithm.
Form a list of nodes.
Using the node points form a list of edges, ie pairs of adjoining neighbours.
Form the graph from the nodes and edges, set a start node and end node and build a path from node to node.
2 Likes
@JohnK thank u so much for ur effort,
Yes, so I build a graph and I use A* algorithm to find the optimal path here is the PG : https://playground.babylonjs.com/#3KUQ1L#18
donât be angry if I used spheres 
just to see them in 3d.
now since it works fine, Iâll update the nodes in my station and see what it will done.
Thank you guys
1 Like
Glad you found a solution. Fine to use markers (spheres) for testing 
. Well done.