You only allow one image, so I made one big image with all my cases. Please expand the image below to read…
These are problems I found in the first demo scene I opened.
Also, a point graph node creates unusable connections. How would you avoid this? (notice that the bottom connection crosses empty space)
Hi
Have you read the ‘Get Started’ tutorial? http://arongranberg.com/astar/docs/getstarted.php
The grid graph will use a raycast to place nodes on the ground, then it will use the physics engine to detect obstacles. For this to work you must of course specify what the graph should consider as ground and what it should consider as obstacles. This is defined by the Grid Graph Settings -> Collision Testing -> mask and Height Testing -> mask fields.
Very likely what has happened is that the grid graph thinks the player is part of the ground and thus has placed a node on the player’s head. When you changed the node size bit, no node center is overlapping with the player so the nodes are placed correctly. The walls and the ground are the same mesh in that scene, to be able to differentiate between the ground and obstacles they have be placed in different layers and the layer that the walls are in needs to be added to the Grid Graph -> Collision Testing -> mask field.
Point graphs are not supposed to avoid connections over empty space. They will disable connections that would pass through obstacles (checked using a raycast). You can remove them manually if you want (see the point graph example scene) or you can add invisible colliders to block them. However you probably want to use another graph type such as the grid graph or the recast graph.
Furthermore. If you want to see an example of how to configure grid graphs you can take a look at the examples that contain grid graphs such as Example2_Terrain and Example12_Procedural (among others).
The forum software limits new users to only posting a single image to provide some mitigation against spam by bots which is unfortunately a problem from time to time.
Thank you for getting back to me so quickly Aron, I truly appreciate it.
I have gone through the getting started tutorial.
“to be able to differentiate between the ground and obstacles they have be placed in different layers”
why? aren’t you looking at a volume for each node? Wouldn’t the existence of non-walkable polygons in the node keep the ground underneath from being traversable? With a grid based solution, wouldn’t the traversal between the grid nodes be blocked by the geometry?
“no node center is overlapping with the player so the nodes are placed correctly”
This also applies to any other object in the scene. The grid goes directly under some of the geometry (as shown above). That makes it too unreliable to use unless the objects are also constrained to a grid.
“You can remove them manually if you want (see the point graph example scene)”
How would I go about removing the undesirable connection on the left in the point graph example scene?
“If you want to see an example of how to configure grid graphs”
my point is that the grid graph code will always produce unusable graphs in certain, very common situations (like example scene 6). Either because it produces node connections where it shouldn’t, or because the smoothing algorithms will move the player onto non-walkable areas. Relying on layers for exclusion is not really workable because each object can only be on a single layer. That means there can’t be any overlap in the layers between walkable objects and non-walkable objects. You can’t, for example, use the layers to indicate the material type of the object (say for footstep sounds) because a wooden box and a wooden floor would need to be on the same layer.
You’ve obviously put a huge amount of work into this, so I’m sorry to be so dismissive of it. I really want to be able to use it. Please help me understand how to get around these issues.
also, why does the graph disappear if I uncheck rescan on start?
You typically want to differentiate between obstacles and ground because even if for example the ground was sloped or was uneven so that it would intersect an imagined volume for each node, you would still not want it to make the node unwalkable. In this case you have just specified what the ground is, but there is nothing marked as an obstacle.
In some cases you saw that the grid was blocked by those walls, what had happened in those cases was that the grid fired a raycast down to figure out where the ground was, and it found the top of the wall and placed a node there. Since there is quite a large height difference between the bottom of the wall and the top of the wall, those nodes were node connected.
Select one of the GameObjects that the nodes are created from and add a NodeLink component, set the other node gameObject as the target, then check the “Delete Connection” field. This will show up as a red arc between those two nodes.
Unfortunately the Unity Physics API only allows for filtering by using layers (unless one uses the slower versions and check for all intersections with some manual filtering). I really do not want to make a significantly slower version the default because some games require a very high performance, especially when using graph updates.
This may seem reasonable as an initial approach for this, but I would strongly suggest using a different approach. For example you can create a simple script on the object that contains the data. This will scale a lot better since you can use more than 32 different types and it will not collide with other things.
public GroundType : MonoBehaviour {
public int groundType = 0; // Just some data
}
Then when checking for collisions
void OnCollisionEnter(Collision collision) {
var typeInfo = collision.transform.GetComponent<GroundType>();
if(typeInfo != null) {
var groundType = typeInfo.groundType;
}
}
Note that this approach would unfortunately not work for the grid graph without resorting to the slower option of checking all intersections explicitly.
Do you mean “Scan On Awake”? If you start the game with that option enabled then the graph will not be generated, and since no graph has been generated it cannot display anything.
Only graph settings are saved with the Unity scene, so when starting the game or when recompiling it will lose that data and you will have to scan the graph again to see it. To quickly do this you can use the shortcut ctrl + alt + s (or cmd + alt + s on macOS).
so I would really want to set everything up, scan, then save the result. Then at runtime, reload the result. is that right?
The problem with a component as a descriptor is that you have to call GetComponentInParent to find it. And if you’re trying to use class type to denote game information, you may have to do this multiple times. Slow!!
What I’ve taken to doing is having components called GameInfoComponent which have all sorts of information. They get put into the scene, and describe anything below them. When the component is enabled, it searches for colliders below it and adds them to a singleton dictionary. The collider reference is the key and the GameInfoComponent object is the value. When I want to test something, I get a collider and then look up the GameInfoComponent in the dictionary. The GameInfoComponent has references to other important components as well as references to sound and particle effects to play in various situations.
Most games just scan the graph when the game starts. If the graph is not so large so that it takes a prohibitively long time then this is not a problem. Usually you use it with recast graphs because they can take several seconds or even many minutes to generate, which you obviously do not want to do every time the game starts.
You can save the graph data in a file and load that at startup. Take a look at the ‘Save & Load’ tab. If you click the ‘Generate Cache’ button it will scan your graph and save the data to a file. Then when the game starts it will load that exact data without having to scan the graph again. Note however that this will override any graphs that you have in the inspector when the game starts, so if you have changed some settings you have to generate the cache again for it to pick up the changes (this can be very easy to forget).
Have you actually profiled this? If you are just using this for footstep sounds I very much doubt that this takes a significant amount of time as it is just done around 2 times per second per character.
By keeping a dictionary you add significant complexity since you also have to take care of removing objects from that dictionary when they are destroyed as otherwise you will get a memory leak.
The only real issue is that it needs to know what things are obstacles. If you don’t tell it that then it will not be able to do a very good job. The grid graph is the graph type that most users use and it is applicable in a very wide range of situations.
I see. This makes sense. At least I understand the algorithm. I guess the grid graph is really only useable under very specific conditions.
I see, thank you.