Plan for Stefan Beffy Moises
by Stefan Beffy Moises · 05/15/2004 (2:21 pm) · 7 comments
Hi again, just a quick update to the AI navigation stuff I'm currently working on... I've been playing with Ken Finney's sweet little fxSurfaceReference object.
While it's designed to be used for foliage replication mainly, I thought why not use it for the navmesh generation for our AI pathfinding... so that the level designer could just paste a certain texture onto the terrain to make the AI "avoid" this area (in addition to the "blocker" markers I've mentioned in my last .plan).
So I went ahead and implemented it into our navmesh generation code and it seems to work quite well - I've tried it with a simple grass texture, which doesnt really make sense, but I only wanted to have a "proof of concept" that this idea is actually working:
So now we dont have any nodes created at spots where it finds exactly that texture - nice :)
It does, however, create the links between nodes around those "spots", so, while there is no node on that texture, sometimes the link/edge goes over the texture, so it cant be guaranteed that the bots really dont touch the texture... not sure yet how to prevent this...
one workaround is to only link nodes that arent more than X world units apart from each other, so chances are that if you have larger spots covered with your "avoid texture", nodes around the spot wont be linked across it... but that isnt the ideal solution here I guess...
Anyway, I think its an interesting concept and can help the leveldesigner configure the auto-generated navmesh...
JiuQ had the idea to use a heightmap as an alternative, where you would mark the unpassable areas witch black/gray and the passable areas in white e.g. - would be interesting, too, I think... :)
but I find the texture painting to be easier / more precise... what do you think?
While it's designed to be used for foliage replication mainly, I thought why not use it for the navmesh generation for our AI pathfinding... so that the level designer could just paste a certain texture onto the terrain to make the AI "avoid" this area (in addition to the "blocker" markers I've mentioned in my last .plan).
So I went ahead and implemented it into our navmesh generation code and it seems to work quite well - I've tried it with a simple grass texture, which doesnt really make sense, but I only wanted to have a "proof of concept" that this idea is actually working:
So now we dont have any nodes created at spots where it finds exactly that texture - nice :)
It does, however, create the links between nodes around those "spots", so, while there is no node on that texture, sometimes the link/edge goes over the texture, so it cant be guaranteed that the bots really dont touch the texture... not sure yet how to prevent this...
one workaround is to only link nodes that arent more than X world units apart from each other, so chances are that if you have larger spots covered with your "avoid texture", nodes around the spot wont be linked across it... but that isnt the ideal solution here I guess...
Anyway, I think its an interesting concept and can help the leveldesigner configure the auto-generated navmesh...
JiuQ had the idea to use a heightmap as an alternative, where you would mark the unpassable areas witch black/gray and the passable areas in white e.g. - would be interesting, too, I think... :)
but I find the texture painting to be easier / more precise... what do you think?
#2
05/15/2004 (6:00 pm)
The texture painting sounds best to me.
#3
05/15/2004 (6:33 pm)
Perhaps you could do a raycast at the center of the path to see if it's crossing forbidden territory...
#4
Extending that thought; maybe more than just the mid-point of that vector should be checked because those vectors are kind of long in more open areas of the terrain.
There is some commented out code at the end of AINavGraph::filterLink() which may be useful here. It's the last block of commented code in that function titled "check to see if there is enough room".
I was originally trying out an idea for filtering links based on slope changes between the nodes. That really didnt work out but I left the code in there because I thought it might be useful later down the line.
The code will break up a vector into one unit intervals; casting a ray from each interval location down to the terrian. In this case it checks the distance from that interval point to the terrain, which you won't really need. The code which walks a vector, casting rays to the ground however might be useful.
Anyway, cool stuff. I'm actually going to rate this plan - awe yeah.
05/15/2004 (9:55 pm)
This is sweet Stefan. As I was reading the post, I was thinking the same thing as Ben; bisect the vector between nodes and cast a ray from that mid-point down to the terrain. I believe you can get at the material information for the collision point (RayInfo struct) and check the texture (I'm pretty sure).Extending that thought; maybe more than just the mid-point of that vector should be checked because those vectors are kind of long in more open areas of the terrain.
There is some commented out code at the end of AINavGraph::filterLink() which may be useful here. It's the last block of commented code in that function titled "check to see if there is enough room".
I was originally trying out an idea for filtering links based on slope changes between the nodes. That really didnt work out but I left the code in there because I thought it might be useful later down the line.
The code will break up a vector into one unit intervals; casting a ray from each interval location down to the terrian. In this case it checks the distance from that interval point to the terrain, which you won't really need. The code which walks a vector, casting rays to the ground however might be useful.
Anyway, cool stuff. I'm actually going to rate this plan - awe yeah.
#5
But your "walking a vector" and breaking it down to multiple checks is awesome, Justin, gonna try that tomorrow when I'm back home :)
And yeah, I like the terrain texturing best, too, since thats really easy to do :)
thx for your thoughts everyone!
05/15/2004 (11:16 pm)
Hehe, thats almost exactly what came to my mind when I was driving to my parent's home tonite for a jam session after I posted this plan... I thought: "I could just check which node is higher, then elevate its z-value even more, lower the other nodes z value and cast a ray from one to the other and check the terrain texture inbetween" :)But your "walking a vector" and breaking it down to multiple checks is awesome, Justin, gonna try that tomorrow when I'm back home :)
And yeah, I like the terrain texturing best, too, since thats really easy to do :)
thx for your thoughts everyone!
#6
And of course, you dont have to exclude textures, you can also restrict the navmesh to a certain texture like this:
Sweet! Thanks a lot to Ken C. Finney for this nice tool! :)
05/17/2004 (5:46 am)
Alright, did a few improvements (e.g. the terrain check was failing in some places cause I started the rayscans to near above it) and added a quick check from above the upper node to below the lower node as mentioned above (didnt get the "vector walking" in yet) and the results are really good now:And of course, you dont have to exclude textures, you can also restrict the navmesh to a certain texture like this:
Sweet! Thanks a lot to Ken C. Finney for this nice tool! :)
#7
since we are generating the navgraph on the server only and the process is taking place at the start of the mission loading, unfortumately we can't really use Ken's twSurfaceRef object (since that works entirely client-side and requires the objects being ghosted already etc.)... so I wrote a new object, a SurfaceMarker (based on Ken's stuff) ... you can now add up to 16 of those to each mission (and therefore distinguish between 16 surface types / texture blends) and configure in the navgraph if it should avoid the marked surfaces/textures OR generate Nodes on these surfaces exclusively... it's basically just an invisble marker object which stores the texture information at its position:
Works very well in Multiplayer it seems (gotta test it on a dedicated server still though, but I don't see a problem there either)
05/19/2004 (11:48 am)
Another update after struggling with some code for a while now...since we are generating the navgraph on the server only and the process is taking place at the start of the mission loading, unfortumately we can't really use Ken's twSurfaceRef object (since that works entirely client-side and requires the objects being ghosted already etc.)... so I wrote a new object, a SurfaceMarker (based on Ken's stuff) ... you can now add up to 16 of those to each mission (and therefore distinguish between 16 surface types / texture blends) and configure in the navgraph if it should avoid the marked surfaces/textures OR generate Nodes on these surfaces exclusively... it's basically just an invisble marker object which stores the texture information at its position:
Works very well in Multiplayer it seems (gotta test it on a dedicated server still though, but I don't see a problem there either)
Torque Owner Steven Jackson