Well, it's like this: LOS mipmap settings, which I've been using since NanoBlobs, to speed things up, produce some odd behaviors. I noticed this with NanoBlobs, but neglected to make any noise about it, because it didn't matter then (unit spam, play speed, etc., made it pretty much meaningless).
However, with PURE, it's a major issue. I'd like to continue to use at least level-2 mipmapping, because the CPU cost savings on LOS checks are considerable. But it's causing some fundamental problems, which will undoubtedly make PURE more "hardcore" than I'd like, for newbie players, and will probably turn people off, if not addressed.
Very simply put: if you use LOS mipmapping > 1, when LOS is established, using the coarser heightmap to determine relative LOS, then every Unit that is within LOS should then be drawn in full.
Instead, what my tests have shown is that the Unit has LOS, in terms of firing solutions, but the rendering engine does not report LOS! This means, among other icky things, that I have game characters firing at invisible targets all the time, because of the way that targeting and movement currently works (i.e., if already at range, don't move forwards unless ordered, etc.) plus I have certain units that do not move at all when aiming / firing, and they have this problem in even greater abundance.
So, either this mipmapped LOS code isn't currently being applied correctly to the rendering engine (i.e., stuff is getting culled, when it should not be, suggesting that this part of Spring is not even properly using the coarser mipmap to begin with)... or some other basic-but-major problem is occurring here.
This is probably a very simple thing to address. Ideally, if LOS is established, regardless of mipmap detail, then the object is drawn. Is this going to cause the per-"pixel" figures for SightDistance to be wrong, by greater and greater amounts as mipmap detail goes down? Well, yes... but that's just fine. What's not fine, imo, is that right now... a good player, playing PURE against a newbie, is going to have the immediate advantage of good ol' OTA "shoot ahead of your sight radius" skills, whereas newbies are going to have some pretty terminal problems in that regard, because what they see, and what their Units can see, aren't equivalent.
At any rate, if anybody has time and can run this down, I'd appreciate it. If you need me to research code and try to run this down, I'll get to it when I'm back home Monday and can pore over the source a bit. It's probably something minor missing from a single line somewhere, honestly, but it'd make a big difference in terms of feel, allowing us to use really coarse mipmap levels (4... even... 8?), save huge amounts of CPU, without causing much in the way of perceivable discontinuity for players.
LOS mipmap settings and game behavior
Moderator: Moderators
I don't really see why a unit would not render when it's inside LOS, since the unit LOS status is directly read from the LOS map every SlowUpdate, IIRC.
It could be that the interpolation in the rendering of the LOS maps makes it less clear where the exact LOS boundary is.
Also it sounds like the more general problem of units sometimes firing on stuff outside LOS.
It could be that the interpolation in the rendering of the LOS maps makes it less clear where the exact LOS boundary is.
Also it sounds like the more general problem of units sometimes firing on stuff outside LOS.
Yes. I have Units shooting at things that the player cannot see. Compound that with the fact that all CEGs seem to be using the AirLOS setting, and that means that frequently, I'll have firefights where I can see flares and ground-lights generated through CEGs, but I do not see the Units being drawn. It's not the end of the world, but it will give the hardcore player, who's perfectly willing to trace back the line of fire and shoot at the ground, a major advantage over newbies. This isn't entirely preventable, nor should it be- speculative fire is a big part of an RTS. But it gives those players an immediate advantage, because they can do so more accurately than usual.I think Argh is saying that his units will consider such a target in LOS while his display won't.
I wasn't aware this was a problem. I would think that unless Target was within LOS, Radar, or Seismic Distance, then it would not be a valid target.Also it sounds like the more general problem of units sometimes firing on stuff outside LOS.
<laughs> assume nothing. My feelings about performance in general are responsible. With correct settings, I rarely see less than 60FPS, even with large battles and lots of units per side, playing with 3 AIs. It's not NanoBlobs. My main issue here is that this is one of the things that can really help performance during events that are usually rather draining, such as large attacks by aircraft. I want the game to play smoothly at all possible levels of load, instead of smoothly only under "most conditions", like most Spring games do. XTA / BA / etc. all have that problem, when large numbers of explosions happen, for example, so I've made it a priority to see whether it's possible to optimize things to the point where this quits being a problem. That's all.Argh if you are indeed using this to improve performance then something is seriously wrong with your game design.
Argh that's the problem this isn't intended as an optimization, and the corrct optimizations do not lie here, they lie in aircraft handling code and path finding. That is where the potential for optimization is vastly greater.
Optimizing this way is not optimization, its a kludge and its not really giving you what you want from it.
At the end of the day all engines have limitations and if your game mechanic is inherently laggy its the game mechanic that must adjust in order to compromise with the limit of engine optimization.
Optimizing this way is not optimization, its a kludge and its not really giving you what you want from it.
At the end of the day all engines have limitations and if your game mechanic is inherently laggy its the game mechanic that must adjust in order to compromise with the limit of engine optimization.
No, AF, you're not getting what's wrong here. And you're waaaaay off-base about the cost savings, if this was being done correctly. LOS searches are one of the big CPU-suckers in Spring.
Here, lemme make a quick visual aid:
Here's a full-resolution, 512 circle LOS map:
The red dot represents a game character. The black LOS map intersects the game character, therefore we should be drawing the character, and it is a valid target, if in range.
Now, let's take that circle and apply a mip-level of 4:
As you can see, this game character should still intersect the LOS map, and be drawn, even though we have quartered the number of pixels in our LOS map, at a huge savings in CPU.
What is happening is that when you drop the mip-levels down, either the effect of blocking objects is getting screwy, and is actually changing the angles at which things are blocked, or that when we drop the mip-level down, we're causing the size of the map to actually shrink. It's gotta be one or the other, because what's happening is that lower LOS-map values cause game characters to fire at game characters that they cannot see on the LOS-map.
It's a huge problem, frankly. Game characters should not be able to fire at each other unless they can see each other on the LOS map, or on the radar map. What is happening, instead, is that they cannot see on the LOS map, but the combat code, which is apparently not using the LOS map at reduced resolution like it should be... sees a valid firing solution, and opens fire.
Lowering LOS mipmap settings needs to effect all forms of targeting. As my example should show you, we're really not losing a great deal of real resolution here- maybe 50-60 pixels dropped, in my example. And the combat code, which is where I was hoping to see the real fruits of this cost savings, is obviously using a non-mipped LOS map, which means that a full-resolution LOS map must be getting generated every frame, which is what I wanted to prevent in the first place, because it's expensive
Even a level-2 mipmap, which involves hardly any change in working resolution at the borders, would save lots of CPU time per frame. It's obvious after testing all this stuff again tonight that this is not what's happening- reducing the mip levels only seems to affect drawing of Units, but does not affect targeting, and it seems to be causing problems with blocking as well.
Here, lemme make a quick visual aid:
Here's a full-resolution, 512 circle LOS map:
The red dot represents a game character. The black LOS map intersects the game character, therefore we should be drawing the character, and it is a valid target, if in range.
Now, let's take that circle and apply a mip-level of 4:
As you can see, this game character should still intersect the LOS map, and be drawn, even though we have quartered the number of pixels in our LOS map, at a huge savings in CPU.
What is happening is that when you drop the mip-levels down, either the effect of blocking objects is getting screwy, and is actually changing the angles at which things are blocked, or that when we drop the mip-level down, we're causing the size of the map to actually shrink. It's gotta be one or the other, because what's happening is that lower LOS-map values cause game characters to fire at game characters that they cannot see on the LOS-map.
It's a huge problem, frankly. Game characters should not be able to fire at each other unless they can see each other on the LOS map, or on the radar map. What is happening, instead, is that they cannot see on the LOS map, but the combat code, which is apparently not using the LOS map at reduced resolution like it should be... sees a valid firing solution, and opens fire.
Lowering LOS mipmap settings needs to effect all forms of targeting. As my example should show you, we're really not losing a great deal of real resolution here- maybe 50-60 pixels dropped, in my example. And the combat code, which is where I was hoping to see the real fruits of this cost savings, is obviously using a non-mipped LOS map, which means that a full-resolution LOS map must be getting generated every frame, which is what I wanted to prevent in the first place, because it's expensive
Even a level-2 mipmap, which involves hardly any change in working resolution at the borders, would save lots of CPU time per frame. It's obvious after testing all this stuff again tonight that this is not what's happening- reducing the mip levels only seems to affect drawing of Units, but does not affect targeting, and it seems to be causing problems with blocking as well.
You have too much resolution in your pic, of course going down to 1/4th won't do much then. I think the default resolution is 1:1 footprint so an average unit would be 2 pixels.
I think LOS drawing isn't limited by the LOSmap either, you often see stuff that just came in range long before the LOS map gets updated.
I think LOS drawing isn't limited by the LOSmap either, you often see stuff that just came in range long before the LOS map gets updated.
@KDR: Well, I shrank it to 128, then blew it back up to 512 and eliminated the non-pure black pixels. At any rate, I'm not arguing about whether it's accurate within any given percentage, but whether it works the way that is expected. I was hoping that this would do what it says it does:
"//MipLevel defines the resolution for LOS calculation, higer MipLevel means lower resolution.
//An increase by one in MipLevel means half the resolution of the LOS map in both x and y direction.
//One miplevel higher leads to less CPU usage for same sightdistance and twice the sightrange possible."
So, the real LOS, i.e., what a player will see drawn, is only updated every SlowUpdate? That seems rather strange, but I guess it probably doesn't matter much for online play.
@Tobi:
So, they're a point, not a pixel? Odd, I would have thought they'd be a pixel apiece- it seems weird / redundant to use pixels on the heightmap / losmap one place, then use a point-based formula elsewhere for true LOS, no doubt with map geometry and other stuff taken into account.
Is that really more efficient, or could all of this be combined within a single function, using the bitmap? It just seems like what we've got neither works as expected, and is redundant, to boot.
"//MipLevel defines the resolution for LOS calculation, higer MipLevel means lower resolution.
//An increase by one in MipLevel means half the resolution of the LOS map in both x and y direction.
//One miplevel higher leads to less CPU usage for same sightdistance and twice the sightrange possible."
So, the real LOS, i.e., what a player will see drawn, is only updated every SlowUpdate? That seems rather strange, but I guess it probably doesn't matter much for online play.
@Tobi:
So, they're a point, not a pixel? Odd, I would have thought they'd be a pixel apiece- it seems weird / redundant to use pixels on the heightmap / losmap one place, then use a point-based formula elsewhere for true LOS, no doubt with map geometry and other stuff taken into account.
Is that really more efficient, or could all of this be combined within a single function, using the bitmap? It just seems like what we've got neither works as expected, and is redundant, to boot.
The losmap is probably just a visualization and it's updated slowly since you have to check LOS to every point on the map instead of only the things that actually need LOS (i.e. units). The units are partitioned into quads and stuff so there's not much waste on units that aren't near the LOS. Therefore the "what can I see" calculation can run much more frequently than the losmap. No idea why units pick targets that aren't considered in LOS, though.
That's that part that's really bugging me- it feels like units are using one LOS check for shooting, and another one for what's being drawn, when they should both be using the same thing. I've seen whole firefights where all my robots could see was the occasional flare, unless I forced them forwards well beyond their supposed LOS
Units are a point on the LOS map and not a pixel because units are not on the LOS map. Units check whether they are in LOS by looking at a place given by two floating point numbers (ie. a point, not a pixel) in the LOS map.
(Of course due to rounding it doesn't make a difference whether the unit is at position 1.3 on the LOS map or 1.4...)
But in the end it doesn't really matter whether you see them as point or as pixel... After all a pixel is the best representation of a point on a bitmap.
(Of course due to rounding it doesn't make a difference whether the unit is at position 1.3 on the LOS map or 1.4...)
But in the end it doesn't really matter whether you see them as point or as pixel... After all a pixel is the best representation of a point on a bitmap.
-
SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Argh: Real LoS is spherical, the LOS field drawn can't be spherical because there is no good graphical way to represent that and people wanted something that looked like OTA, so the represented system is a 2D mipmapped circle, but the real system is spherical, and spherical calculation is cheaper in 3D than any alternative.