I was going to make a minimap, to order units to navigate with, and I noticed I would need to create a non navmesh duplicate of the navmesh and mark it static ghost in order to detect where the navmesh was, (aiming at the minimap with the mouse and clicking then casts a ray there in the main scene)*
I think in the future maybe another flag at the end that is optional of rayCast would be handy
or maybe another function so we don’t clutter rayCast or break compatibility?
I’m not sure how handy that would be, given that it would only be used in a few situations (in all my years of blending I’ve never had to detect the navMesh only). What you’re after could be achieved with the property flag and adding the property to the navMesh.
My usual method to get around having multiple ray casts and collision types is to ray cast with xray on and looking for the property ‘solid’, then all objects that need to be detected have the property solid. Then the objects have another property that determines how they are handled:
ob, hit, norm = own.rayCast(gunAim, own, 50, 'solid', 1, 1)
if ob:
if 'enemy' in ob:
#injure enemy
if 'destructable' in ob:
#damage object
Alternatively, I extend the KX_GameObject class for each object that needs to be hit by a ray cast and then define a hit() function for each, so I can go:
Well, I was going to have raycasts down from above the map through the ceiling, (x ray) and have it detect the navmesh point, and place a navTarget there to order units using a map,
I supose I will need seperate physics meshes for the floor secitons anyway, and hitting them is just like hitting the navmesh,
another thing though ? what if one wanted to place a target at a random face center of the navmesh?
how do I know what vertex are a face?
You dont, since a vertex can belong to any number of faces. Better to cycle through the polys. I’ve attached an example that cycles through an objects faces, picks one at random, finds the centre point and spawns an object there.
Forgot to add that the above example uses local coords for the verts, that works fine since the plane object it’s looping through has not been translated and sits at the world origin. If you move/scale/translate your navMesh you’ll need to convert the vertex positions to world coords.
I had a similar problem using nav meshes for a point and click adventure.
In such games you only want to be able to click on valid areas to avoid getting stuck on the scenery and since the navmesh is a valid area it would make sense to click on that. But you can’t I couldn’t get the navmesh to register collisions because it’s physics type is navmesh.