LOS, LOF, units, and you!

[Battlefront.com]

This is a general explanation of the differences between LOS and LOF, both from the player's perspective and from the code's. The reason for this post is to clue you guys in to why there can be support of one but not the other. You can see an example of this here:

http://www.battlefront.com/discuss/ultimatebb.php?ubb=get_topic;f=52;t=000134

Player's think in terms of straight lines between two known points. Unit A is here and it can see Unit B, therefore LOS and LOF exist between the two. When LOS is not present LOF generally is not, though in theory smoke can inhibit LOS without inhibiting (in the physical sense) LOF. However, this is not how it really works because the player is skipping over how LOS and LOF are determined in the first place.

So how is it that Unit A knows about Unit B? Well, Unit A scans the map around itself, within certain parameters, to see what units are within its visual range. In order to do this it basically has to assume that any position may contain any enemy unit at any time. So it must check everywhere regardless. Units that aren't spotted yet, but are in LOS, are checked to see if spotting should occur. If so, it is spotted otherwise it is skipped over.

This LOS checking is an extremely hardware intensive thing to do. The more units you have, the more terrain to scan, the more variables to consider... the worse it is. Then there is the frequency issue... in theory a unit is usually scanning around itself constantly without interruption. EVERY unit. On BOTH sides. If you have a game with 50 units on a side, that means 100 units want to be doing LOS checks all the time. Think about that for a second... in a game that is simulated using a real time clock... how much time out of that 1 minute of game time do you think is going into LOS checks? If you think "a significant amount" you are correct! Even with lots of very clever shortcuts, with which a CM type game wouldn't work, LOS checks are damned "expensive" for the simulation.

Now, how does this relate to LOF? Well, there is no need to scan the map because the LOS function has already done this. So LOF basically piggy backs itself on the already computed LOS data. You don't get LOF for free, but it is significantly less system intensive. Since the system already knows if Unit A can see Unit B is, all the LOF function has to do is check between the established two points to check if a shot is viable (range, target type, interference, etc.). It doesn't have to figure out anything more than that.

Everybody with me so far? That LOS is a sort of broadcasted "who's out there" general inquiry, while LOF is a specific question of "can I shoot at this very specific unit"? Good! Now I will answer the question of why it might be that LOS and LOF aren't necessarily both possible.

The example in the linked thread involves moving units. Can they block LOS? No. Can they block LOF? Yes. The question is... if the system knows that the vehicle is in a specific spot, why can't it treat it like a piece of blocking terrain and therefore not see what is behind it? After all, the system knows that it can't shoot through that vehicle, so why can't it also know it can't look through it? Remember what I said above about the very clever shortcuts? Remember that I said they are essential for managing the hit to the hardware for all those LOS checks? That's where the answer lies.

One of the most important shortcuts is establishing a "LOS map" of the entire battlefield which is, basically, a precomputed LOS check. Units don't scan the terrain map directly, they scan the LOS map. So it doesn't matter what is on the terrain map, it matters what is in the LOS map. Since the LOS map is precomputed, it can't possibly know about things that move around dynamically since that would require constant recomputing the LOS map data. So much so that it would probably negate the reasons for having the LOS map in the first place. Which brings us back to the point about this shortcut being necessary for the game to run at all.

The upshot is that units can not block LOS because they are not tracked in the LOS map. Because the LOS map is mandatory for a CM type game to function, there's no room for argument.

LOF, in this case, works fine because part of the question of "can I shoot at this known target/location" involves checking what is inbetween the shooter and the target. If a vehicle is there, at that moment, then the LOF check will return a result that states it can not hit the intended target. It can afford to do this because it is a specific check and not a fishing expedition like LOS. However, cumulatively it still hits the hardware pretty hard and therefore that is why we weren't able to do it in CMx1.

So, when LOF is determined to be adequate for the shot, the unit gets to take the shot. If not, it does not. Nice and simple. What is not simple is if a unit (vehicle or otherwise) moves into the LOF at the moment after the LOF calculation is executed and EXACTLY at the spot where the outgoing round/s flightpath intersects with the unit's position. This isn't a likely or common occurrence (overall), but it does happen enough that it will be noticed from time to time.

In theory a unit being in the flightpath of incoming fire should get struck, but in order to know this the round/s in flight must know if there is something to strike in the first place. To do that the system would have to recalculate LOF every nanosecond of flight on the off chance something gets in the way. Otherwise, there is no knowledge that the two should collide because it doesn't even know it is there. If you've read this far, and paid attention , you can see that having EVERY SINGLE volly/round fired check its flight paths, all the time every time, is going to add up to a lot of CPU cycles and RAM used REALLY fast. I'm not saying it is impossible to do spare the resources for this, but with a CM style game it is pretty darned tough to do because of the quantity of fire that goes on within a 1 minute slice of time.

So there you have it... LOS and LOF are related, but not the same. LOS is far more expensive than LOF. LOS requires certain shortcuts in order for it to work, which precludes random events from being accounted for. LOF requires certain shortcuts in order for it to work, which precludes random events from being accounted for. In the case of dealing with units blocking LOS and LOF, we can afford to block LOF but not LOS. And blocking LOF is limited to things that it knows about at the time it tries to fire, not things which get in the way during flight.

That all make sense to you guys?

One thing someone will ask about... the effects of deformed terrain on LOS. Well, from what I understand the periodic updating of already known data structures, simply to change their LOS related properties, is doable. That means you can reduce a building and now have LOS through it when before you did not. Even CMx1 supported this, though with a lot less terrain to be considered. I am pretty sure that Charles can allow deformable terrain to have an effect on CMx2's LOS/LOF. At least I assume so since I haven't asked him directly in a long time.

Steve

[RCHRD]

Ok Thank you

[flamingknives]

Wow. I was right. Go me.

[Other Means]

Facinating. It's nice to see behind the curtain oh Wizard.

[Sergei]

So, no grazing fire?

[stoat]

Or fire through smoke?

[Battlefront.com]

Smoke shouldn't be a problem provided it is already present at the time of the LOF check. At least I think so!

Grazing fire, in the technical sense, is probably not possible. However, Charles did manage to do something that partially simulated this way back in CMBB. I expect that he can do at least that much for CMx2, perhaps more. Time will tell.

Steve

[hoolaman]

I don't think it is counter-intuitive to have LOS past an AFV for example but not be able to get a clear shot.

For example if you see an enemy squad behind a tank, you would know the squad is there but not be able to fire effectively on them.

Just like you can currently see a squad crouching in the woods, but perhaps only fire on them with 20% effectiveness.

I do hope there would be different LOF rules for inf and small arms as compared to a large AT gun vs a vehicle. One is a volume of fire with a % effectivness and one is a discrete hit or miss situation.

[Battlefront.com]

Yes, size of the vehicle can be taken into consideration (I think!). There is a big difference between hiding behind a motorcycle and a Maus

Steve

[Cpl Steiner]

I think LOS being more difficult than LOF is a real problem, but forgive me if I remain a little unconvinced on the LOF issue. Surely, if you create a 3D object that is a shell of one type or another, it isn't that hard to check whether or not it's coordinates intersect with any of the other 3D objects in the game?

I mean, this sort of thing happens every fraction of a second in a FPS. You just have to check each object against every other in the game to see if they intersect. I appreciate that in CMx2 there will be quite a lot of "objects" but the principle remains the same. If anyone remembers the space combat game "Homeworld", they will appreciate that the game could detect intersecting objects when several dozen objects were in play at any one time.

Please accept this comment in the way it was intended, i.e. to query design decisions in a constructive way so that we all get to enjoy a game that is the best it can possibly be when CMx2 comes out.

[aka_tom_w]

Ok, Thanks

This thread might reasonably be expected to be "stickied" to the top of the page because it is such a critical and crucial concept and so integeral to the understanding of the inner workings of the new game.

Thanks

-tom w

[ September 05, 2005, 04:26 PM: Message edited by: aka_tom_w ]

[aka_tom_w]

Originally posted by Cpl Steiner:

Surely, if you create a 3D object that is a shell of one type or another, it isn't that hard to check whether or not it's coordinates intersect with any of the other 3D objects in the game?

I mean, this sort of thing happens every fraction of a second in a FPS. You just have to check each object against every other in the game to see if they intersect. .

Um ok... you do raise an interesting point.

But Does that "really" happen in the code?

"I mean, this sort of thing happens every fraction of a second in a FPS. You just have to check each object against every other in the game to see if they intersect."

one thing for sure DOES NOT happen in any FPS or RTS game is the detailed armour pentration calculation. BUT that does not really have anything to do with our current LoF/LoS discussion.

I would suspect that the collision detection and intersect model in the FPS games you refer to are somehow "cheated" or guessitmated? OR it does actually work but the fact is there is NOT that much to detect maybe 5 -20 units (FPS players) firing laser blasts or plasma bursts or rockets or missiles at each other now and then, so there is really not all the much to track. (?) BUT yes I have seen Unreal Tournment and Doom and Marathon and all those FPS games do collision detection on the fly on ALL kinds of units and weapons and ordinance that is ALL flying all around all at the same time in REAL time. And NO, I have no idea how the game handles the collision detection in real time, but somehow I figure it must fudge, cheat or guesstimate how all that happens. :confused:

One thing I know for sure there is NO armour penetration code/model/calculation'simulation like the CM model, that I have ever seen happen in any game in real time.

But I welcome your insight and comment as to how the code works in the whacky world of the FPS. (Cpl Steiner )

-tom w

[ September 05, 2005, 05:38 PM: Message edited by: aka_tom_w ]

[Gordon]

Nice summation, thanks.

[Battlefront.com]

All things are a balance. If we wanted to make a game which emphasized collision detection... we sure could! No problem. There is no technical reason preventing it. But what happens when we start adding other stuff into the design? Whoops... where did all that extra CPU power and RAM go?

Think about an FPS game. Forgetting the massive multiplayer games, which use distributed computing as one of their tricks, what does a modern FPS game lack that CMx2 has to do? Spotting. That's the big CPU and RAM sucker right there. Ok, what next? Well... how about 100 or more units moving around in an environment that can be a complete mixmosh of terrain, weather, and other very detailed factors? Oh... and how about the fact that at any given time there might be 20 or 30 units slugging it out? And how about distances? What is the average engagement range in a FPS compared to CMx2? Well... that's at least the bulk of it, probably. Much of the rest of the stuff the FPS games and CMx2 have in common.

What this means is that CMx2 does all the basic stuff that a FPS game does, and a whole lot more. At least overall. How is CM able to do this? By clever programming that uses CPU cycles and memory better than people like John Carmak? No, by emphasizing different things and sacrificing some things for the good of others. Just like FPS games do. For us we have to cut back on LOF, for FPS they cut back on units, distances, other stuff, and most importantly spotting. So their games are geared towards shooting stuff in a small space, ours are geared toward battlefield tactics. Same hardware, but maxed out to produce different results.

Steve

[Battlefront.com]

Slight correction... FPS games don't have zero spotting. Something in there detects targets for the AI, so the AI has to be aware of location. But that is just for the AI "bots". But their spotting isn't like ours because they can make four assumptions we can not:

1. The AI can know where all the targets are and just simply "decide" to target one. By range, trigger points, etc. Actually, the trigger point is the most common thing. Ever noticed in some games where you can see the AI controlled enemy just standing around, seemingly unaware that you are there watching? Well, that's exactly the case because until you flip a trigger it isn't aware. Sometimes even shooting the enemy doesn't get it to know where you are! Why is that? Bad AI programming? Perhaps, but most likely limitations in what they do for spotting.

2. Distance. If the average engagement distance is 100m the game engine can be coded to optimize on that standard. Take it out to 1000m and the system might cease to work. Scale it down to 50m and it works better. The reason is that distance is the #1 killer of LOS and LOF. So the shorter the ranges, the faster the calcs, the more CPU cycles and RAM left over for other things.

3. Limited entities. How many entities are there in a 64 player game? C'mon now... take a guess... OOOO!!! I know.... 64 So like distance above, if you know what the max is you can tailor the system to fit it. Try making it 100 and blamo... it all falls apart.

4. Limited need for viewing results. How many FPS games allow you to sit above the entire battlefield, with dozens and dozens of guys shooting at each other in plain view, over thousands of square meters of battle space, in a variety of dense and/or open terrain? How many? Exactly So FPS games have certain assumptions about how much horsepower they need to devote to explosions, animations, other guy's results, etc. If someone is shooting someone else 2 rooms away, your system might only get the end results. CM can't do any of this.

BTW, these tricks are not just limited to FPS games. RTS games have a lot of the same issues that CM and FPS have in terms of limited CPU and RAM. So they limit what is simulated, what the AI can/can't do, the size and complexity of the battlespace, how many of what are engaging at any one time, and what the player needs to know about/see out of all of this.

Again... it is all about choosing how to max out the CPU, RAM, VRAM, etc. FPS have made one set of choices, we have made another set. Asking "Game A can do this so why can't Game B?" only works if you are comparing games that are pretty much near identical. CM and FPS might have similarities, but they are as different as night and day.

Steve

[Cameroon]

Damnit, Steve beat me to the post about FPSes

[Cpl Steiner]

I did a quick search on the web for info on collision detection and came up with the following article, which seems to be a very good summary of the problem and confirms lots of what has already been said on the matter, if anyone's interested.

http://www.ddj.com/documents/s=983/ddj9513a/

My only proviso would be that CM doesn't have to do it's collision detection in real time. In theory it could take a bit longer when it generates the action phase, but even then I concede that there are limits on how long the player can reasonably be expected to wait.

[Metto]

This thing, that moving objects(tanks etc.) only tell the units "you must not fire here", creates an exploit.

Situation 1: A tank is advancing towards a machinegun and has infantry following it, "in cover". The player controlling the machinegun gives it an area fire order ahead of the tank -> when the tank and infantry moves forward, the mg keeps shooting the spot and hits the infantry through the tank.

Situation 2: There's a light infantry gun instead of the machinegun, and the tank is a heavy tank, so the gun can't kill it. The tank is sitting in level terrain, so even a small adjustment in the guns elevation may result in the gun's rounds going very short or very far from the tank. The player sets the gun to fire in front of the tank and when the gun eventually misses above it's ground target, the shell flies through the tank and hurts the infantry.

[Guest Sgt. Emren]

Wow, really nice posts, Steve. However, I'm sure that this is a typo:

Even with lots of very clever shortcuts, with which a CM type game wouldn't work, LOS checks are damned "expensive" for the simulation.

Surely, you mean "...withOUT which..."?

[Tero]

Will a unit be able to take multiple LOF checks for different ordnance (and possibly different deployment like different elevation of the gun) ?

If for example AP shot against a HT heading behind a cover will not be possible but a direct fire or even a high arc, high kill propability, HE shot is possible ?

Also, will LOS impediments be cathegorized ?

"Soft" LOS impediment like hey, brushes or small trees will not interfere with the LOF check the same way a stone building will.

[Bonxa]

A seriously big gain in CM must be the turn based system where you compute what happens first, then you display it. Shouldn't that allow for very detailed "under the hood" effects given that RAM can keep it all in memory. The 3D movie is still limited by hardware but you don't have to do any LOS checks then, right?

[RSColonel_131st]

Originally posted by Metto:

This thing, that moving objects(tanks etc.) only tell the units "you must not fire here", creates an exploit.

Situation 1: A tank is advancing towards a machinegun and has infantry following it, "in cover". The player controlling the machinegun gives it an area fire order ahead of the tank -> when the tank and infantry moves forward, the mg keeps shooting the spot and hits the infantry through the tank.

Situation 2: There's a light infantry gun instead of the machinegun, and the tank is a heavy tank, so the gun can't kill it. The tank is sitting in level terrain, so even a small adjustment in the guns elevation may result in the gun's rounds going very short or very far from the tank. The player sets the gun to fire in front of the tank and when the gun eventually misses above it's ground target, the shell flies through the tank and hurts the infantry.

I'm not sure, but for CMBB I think if LOS is broken (by smoke, for example) then area fire stops.

No reason why broken LOF shouldn't do the same in CMx2.

[Tero]

Originally posted by RSColonel_131st:

No reason why broken LOF shouldn't do the same in CMx2.

Except for added realism.

[undead reindeer cavalry]

in my opinion a more detailed LOF modelling is essential for friendly fire modelling, and thus for giving player reasons to use more realistic formations. the current system, and IF i understand it correctly what Steve is saying then the coming CMx2 as well, rewards unrealistic formations due to limited LOF checks. IMO formations and firing sectors are crucial to realistic tactical warfare.

with tanks, it's usually too tempting to put tanks one after another in good keyhole positions, instead of side by side, because you can fire thru friendly tanks. i hate doing it, because it simply could never be done in real world, and to lesser part because it takes away many reasons for real world tank tactics.

with infantry, well, you can do everything. you don't have to worry about LOF and friendly fire at all (save for night battles and even then it's very limited). in my opinion it's a fundamental flaw in CMx1. with more detailed LOF you couldn't have friendly units just shoot thru friendly units in their LOF. you would have to give thought to firing sectors and formations, instead of having an amoeba like mass of blind firepower.

i think more detailed LOF would add dramatically to CMx2.

you don't need to calculate LOF for each nano second, because there are no units that travel in such a speed. bullets are fine with just one intial LOF check. what comes to tanks etc, that have longer firing ranges, having some LOF checks per second is no big deal CPU-wise. you don't do check for the actual 3D object that represents the flying thing, but its vector path. checking if a vector intersects with a 3D object is no biggie, and most objects can be ruled out without any detailed 3D checks.

i wish BFC still gives addition thought to LOF modelling, because i think it would add greatly to CMx2 because of its effect for friendly fire and formations.

[Cameroon]

Originally posted by Metto:

This thing, that moving objects(tanks etc.) only tell the units "you must not fire here", creates an exploit.

Situation 1: A tank is advancing towards a machinegun and has infantry following it, "in cover". The player controlling the machinegun gives it an area fire order ahead of the tank -> when the tank and infantry moves forward, the mg keeps shooting the spot and hits the infantry through the tank.

I'm not sure that this is the case. It would seem obvious that LOF must be checked each time a unit wants to fire. With infantry, I imagine that would be for each "burst".

Since units can't walk into the LOF and be affected by already fired rounds, the advancing infantry won't be hit by a burst of MG fire that they weren't the target of at the firing/LOF check. So they can't walk into the tail end of a MG burst, and the next burst that would be fired has LOF blocked by the tank.

Situation 2: There's a light infantry gun instead of the machinegun, and the tank is a heavy tank, so the gun can't kill it. The tank is sitting in level terrain, so even a small adjustment in the guns elevation may result in the gun's rounds going very short or very far from the tank. The player sets the gun to fire in front of the tank and when the gun eventually misses above it's ground target, the shell flies through the tank and hurts the infantry.

Seems far more likely to end up with a dead gun than any dead infantry, as well as being a poor tactic for the tank + infantry. If you know the IG is there and its IDed (thus why you're advancing behind a vehicle that the IG can't kill), I would expect you advance your tank to a firing position and kill the IG.

And all of that could theoretically occur in CMx1, because vehicles block neither LOS nor LOF in that engine. Hasn't been a big exploit that I'm aware of (other than tank stacking).