I disabled the push code but other stuff acts up :\Kloot wrote: IMO not really, and that's what this thread is primarily about. In large groups the pushing code can actually cause units to get stuck inside one another and become immobile, etc. The default stop-go behavior of ground units doesn't help much either.
So how about that pathfinder?
Moderator: Moderators
Re: So how about that pathfinder?
Re: So how about that pathfinder?
Um.
1. The predictive part of the path-follower needs tuned very badly. I discussed a simple concept to build a better predictive system for units making short-term decisions quite awhile ago, on jcnossen's 'site. K-Man thought it was interesting, so it may even be workable.
Long story short- represent the heightmap with a small grayscale. Units that are have already planned a path through an area put down a value of gray dots where they'll (probably) be passing through, and white where they (think) they'll arrive, assuming that no collisions occur.
If a square is already gray, it's bumped up in lightness by further overlays until it's white. White squares cannot be used as targets by any units further back in the queue, period.
Whether this uses 2 values, 4 values, or 8, it's a better way to see the interaction of units and would allow them to at least time their flow better.
I'm not putting up the drawings again, as the few people around here smart enough to get it are the same ones who can go look up my original description anyhow.
2. The map-deformation system is something I'd happily lose, if it meant the pathfinder worked better. +1 to that. However, the last time we talked about this, it was said that this wasn't a significant area of concern.
I did some tests a few months ago, and I still disagree with that assessment. For example, CA's hills can easily be used to make an area effectively impassible, even though valid paths do exist. Units just sit there, stuck. They don't seem to find a local path even with dumb A* when confronted with loose collections of changed heightmap.
Basically, what's happening is that because of the resolution being lower, porous areas become walls. There are inverse issues as well- which is why people hate trees so much. If you check, you can see that many trees (1-footprint objects) don't register on the blocking map at all.
So... eh. If it's a choice between an accurate blocking map at proper resolution... and dynamic heightmaps... well, I'd rather have an accurate blocking map. I don't know whether that's a valid choice, but it may be.
I'm not going to re-argue this one. Test it yourselves.
3. I'd say that the pathfinder has a fairly serious problem, when it, like the follower, doesn't take traffic into account. See idea no. 1, or use an even more simplistic representation- if over X units on a given AllyTeam in a given sector, consider that sector closed to traffic and route stuff around that area if at all possible.
I think that combining some or all of these approaches would result in significant improvements in the behavior of the engine in regards to this stuff.
It's not a feature... that units don't spread out and use more of the valid space.
It's not a feature... that there's massive congestion somewhere with valid paths nearby that won't get used.
It's not a feature... that messing with the heightmap either produces the wrong behavior because the resolution doesn't allow for correct behavior (jamming on trees, "blocked" areas that actually have valid solutions).
And it's really retarded that Units can enter each other's footprints and actually pass through each other. Happens more frequently than you'd think. This would be prevented fairly well with the grayscale concept. I just don't know if that can be made to run quickly enough with lots of units- we're talking about a huge number of pixels in the end. Perhaps some clever way can be found to not search any but the bare minimum.
Meh. Tired of this topic. I told you guys... halve the fucking heightmap resolution, give us a new map format that uses shaders and looks decent, if lower in mesh resolution (mappers will bitch, until they see that normalmap / depthmaps can make it appear to have even better rez than it does now).
That would solve a lot of problems. We could have 1:1 heightmap / path resolution, for one thing, which would make it easier to arrive at decent solutions for the rest.
No commercial engine I've played in the last year had Spring's heightmap resolution. I'm talking true rez, not apparent, btw.
All of them are using something like that splatmap concept I described elsewhere, or they're using a 1:16 format (as opposed to 1:8) that's basically SMF with a normalmap pass. And they all look better than SMF by quite a bit, despite the softer terrain.
Heightmap resolution is a terrible solution to the problem of map detail, basically. Suggest it with shaders instead. Let the GPU do the heavy lifting.
If we can't have the splatmaps, fine... if I can't get anybody to sit down with the traffic-routing concept... fine... just give us an alternative version of SMF that triggers an alternative pathfinder, with numbers doubled here, halved there. Should take somebody a day or so, and then we can test it and see for ourselves what advantages pertain.
The only hard part's going to be getting a new MapConv made, and sticking in normalmap / depthmap support (which we have the GLSL for).
1. The predictive part of the path-follower needs tuned very badly. I discussed a simple concept to build a better predictive system for units making short-term decisions quite awhile ago, on jcnossen's 'site. K-Man thought it was interesting, so it may even be workable.
Long story short- represent the heightmap with a small grayscale. Units that are have already planned a path through an area put down a value of gray dots where they'll (probably) be passing through, and white where they (think) they'll arrive, assuming that no collisions occur.
If a square is already gray, it's bumped up in lightness by further overlays until it's white. White squares cannot be used as targets by any units further back in the queue, period.
Whether this uses 2 values, 4 values, or 8, it's a better way to see the interaction of units and would allow them to at least time their flow better.
I'm not putting up the drawings again, as the few people around here smart enough to get it are the same ones who can go look up my original description anyhow.
2. The map-deformation system is something I'd happily lose, if it meant the pathfinder worked better. +1 to that. However, the last time we talked about this, it was said that this wasn't a significant area of concern.
I did some tests a few months ago, and I still disagree with that assessment. For example, CA's hills can easily be used to make an area effectively impassible, even though valid paths do exist. Units just sit there, stuck. They don't seem to find a local path even with dumb A* when confronted with loose collections of changed heightmap.
Basically, what's happening is that because of the resolution being lower, porous areas become walls. There are inverse issues as well- which is why people hate trees so much. If you check, you can see that many trees (1-footprint objects) don't register on the blocking map at all.
So... eh. If it's a choice between an accurate blocking map at proper resolution... and dynamic heightmaps... well, I'd rather have an accurate blocking map. I don't know whether that's a valid choice, but it may be.
I'm not going to re-argue this one. Test it yourselves.
3. I'd say that the pathfinder has a fairly serious problem, when it, like the follower, doesn't take traffic into account. See idea no. 1, or use an even more simplistic representation- if over X units on a given AllyTeam in a given sector, consider that sector closed to traffic and route stuff around that area if at all possible.
I think that combining some or all of these approaches would result in significant improvements in the behavior of the engine in regards to this stuff.
It's not a feature... that units don't spread out and use more of the valid space.
It's not a feature... that there's massive congestion somewhere with valid paths nearby that won't get used.
It's not a feature... that messing with the heightmap either produces the wrong behavior because the resolution doesn't allow for correct behavior (jamming on trees, "blocked" areas that actually have valid solutions).
And it's really retarded that Units can enter each other's footprints and actually pass through each other. Happens more frequently than you'd think. This would be prevented fairly well with the grayscale concept. I just don't know if that can be made to run quickly enough with lots of units- we're talking about a huge number of pixels in the end. Perhaps some clever way can be found to not search any but the bare minimum.
Meh. Tired of this topic. I told you guys... halve the fucking heightmap resolution, give us a new map format that uses shaders and looks decent, if lower in mesh resolution (mappers will bitch, until they see that normalmap / depthmaps can make it appear to have even better rez than it does now).
That would solve a lot of problems. We could have 1:1 heightmap / path resolution, for one thing, which would make it easier to arrive at decent solutions for the rest.
No commercial engine I've played in the last year had Spring's heightmap resolution. I'm talking true rez, not apparent, btw.
All of them are using something like that splatmap concept I described elsewhere, or they're using a 1:16 format (as opposed to 1:8) that's basically SMF with a normalmap pass. And they all look better than SMF by quite a bit, despite the softer terrain.
Heightmap resolution is a terrible solution to the problem of map detail, basically. Suggest it with shaders instead. Let the GPU do the heavy lifting.
If we can't have the splatmaps, fine... if I can't get anybody to sit down with the traffic-routing concept... fine... just give us an alternative version of SMF that triggers an alternative pathfinder, with numbers doubled here, halved there. Should take somebody a day or so, and then we can test it and see for ourselves what advantages pertain.
The only hard part's going to be getting a new MapConv made, and sticking in normalmap / depthmap support (which we have the GLSL for).
Last edited by Argh on 21 May 2009, 12:35, edited 1 time in total.
-
Google_Frog
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
Re: So how about that pathfinder?
By the way changing the heightmap via lua doesn't repath the edges. CA had this bug for a while until I fixed it by adjusting the heightmap by 0 16 elmos around the terraformed area.