So that's why the AI kicks our ass in the forest!

[metalcraze 290]

If it's true it isn't a bad solution. Dwarden can you confirm?

[gammadust 12]

Perhaps I left room for doubt regarding Old_Painless report of AI "firing through" the tree.

I was able to reproduce this exact thing by launching the AItracking.Chernarus.pbo mission and there I just, while leaning, slowly strafed left while mantaining the tree on crosshair, after some small steps, AI which had already detected you then starts firing, this was at the point where I could only see part of its arm and weapon.

Indeed bullets seem to go through the tree trunk, audio reveals bullet hiting wood, you also have the visual hit on wood effect (particles), but player is also getting shot (blood effect, heavy breath), and these are no "deflected" bullets apparently because all of them landed in player, not just some of them.

I still consider this reasonable, it only happens in a very narrow situation.

---

Regarding finding out if OA trees suffer the same problem or not and them being narrower one can test by putting player + ai in a position where multiple trees align themselves and block view/fire in a useful manner.

---

And I didn't make that spotting script, btw. It's been floating around for a while and has taught me tons of stuff about the AI.

Credits go to the great community then, for such a handy script!

---

I think domokun suggestion is in line with what I would like to see happening, it is slightly more elaborate, and there is the trouble of, while keeping good performance, figuring out what is for AI to "see" a certain percentage of the unit.

Dwarden suggests this is a all or nothing assement by AI, correct me if wrong, but I could still imagine a way where by using both multiple spread out raycasts to target and/or combined with a permanence in view timespan* to reach to a percentage. How cheap are raycasts these days? Would 10 raycasts be too taxing? 5 raycasts? The latter would give 20% increments...This would still be only required as a function of distance.

This could come into place and substitute torso+head only recognition if that is the case.

* even a trigger like, "it was there, now it is not > must be animated entity"

This would lovely work with domokun suggestion.

Edited January 26, 2012 by gammadust

[maturin 12]

Gammadust, the AI SHOULD shoot through the tree. The edges, that is, where the rounds can penetrate.

Since the trunk is only just thick enough to hide you, any strafing should result in incoming fire quite quickly.

So it sounds like the fire geometry is working admirably. Now if only it worked for Chernarus bushes the way it does for Takistani bushes.

[gammadust 12]

Done some more tests with trees and reported in CIT.

• File AItracking_various_missions.zip added
  

Aditional tests made both in Chernarus and Takistan.

Revealing the same issue were found 3 additional trees in Chernarus, 2 trees in Takistan.

Also one bush or tree is revealing the same problem, can't tell since they seem to be justaposed.

I was by no means exaustive, I randomly picked some trees to test, all revealed the issue.

AItracking_Tree4.Chernarus appears to be a special case, in that only the right most branch/trunk allows AI to perceive player, the center (widest) properly blocked view when tested.

Gallery with images from Player and AI's POV for quick reference

Ticket DH #28068 | 2

Notes:

White smoke = nearTargets returned position, Red smoke = nearTargets returned accuracy (size of smoke slightly modified for better view)

Object, Terrain and Shadow is set to "Very High", in case this matters

Tested with a basic USMC Designated Marksman also in case my PMC (Lite) version influences results

---

Gammadust, the AI SHOULD shoot through the tree. The edges, that is, where the rounds can penetrate.

Since the trunk is only just thick enough to hide you, any strafing should result in incoming fire quite quickly.

I disagree here, in the test mission in question I estimate having moved at least 50cm left maybe more until my head "sticked out", not counting to the right side. I checked AI's view in that case and this is what you get:

images

1st - Player's POV

2nd - Place from where AI was shooting

3rd - After I moved AI where Player could be seen, its significant

This depends alot on the distance AI is to the obstructing object since its should be a cone and NOT parallel lines with its width (as if AI was in infinity). The closer AI gets the more its view is obstructed, and the more AI's target is distant from the tree the more room to move without being seen.

What I can agree is that if AI is following a target's movement it may keep shooting for an instant resulting in some rounds going through the obstruction.

Even if its wood do you shoot while not having view over the target? Or do you move into a better position? I guess the latter

Now, limitations are limitations and I can agree, even find reasonable, if in an extreme case AI opts to shoot disregarding bad conditions.

So it sounds like the fire geometry is working admirably. Now if only it worked for Chernarus bushes the way it does for Takistani bushes.

This leads me to think if AI detection based on FireGeometry ("can fire") wouldn't work better...

Edited January 27, 2012 by gammadust

[maturin 12]

This leads me to think if AI detection based on FireGeometry ("can fire") wouldn't work better...

But then the AI would see through leaves and thing fences.

[metalcraze 290]

And concrete walls too, since it has no problem shooting through them with 7.62+

[maturin 12]

It would be interesting to learn what sorts of fire geometry different objects have. Since it's is exceedingly difficult to get the AI to shoot through any of them voluntarily, on account of their easily-confused motion-tracking brains.

[gammadust 12]

This leads me to think if AI detection based on FireGeometry ("can fire") wouldn't work better...

But then the AI would see through leaves and thing fences.

And concrete walls too, since it has no problem shooting through them with 7.62+

What I meant here is whatever processing is made based on FireGeometry to check if a AI unit "can fire" or not, would be applied also for "can view" equally, if nothing else for bug tracking purposes. (I am sure there is a reason for that distinction, having opened up some sample BIS models)

Also for our speculating reference:

Geometry

Defines where the model will collide with other objects.

Should be very simple, and has to fulfil the following criteria in order to work:

* Object must be named ComponentXX (where XX is a consecutive number between 01 and 99).

* Must have 'Mass' (Alt-M).

* Must be closed and convex (Validating Geometries).

Geometry objects should have a thickness of at least 0.5 meters in order to work properly.

Fire Geometry

Defines where the model will collide with bullets & rockets. If this LOD is not present the Geometry LOD will be used instead.

* Must be closed and convex (Validating Geometries).

Proxies for the driver & passenger must be present into this LOD as well (they can be copied from the Resolution LOD). Otherwise the units will be invincible. One should also do any geometry validation before adding the proxies, otherwise they will not be functional.

ViewGeometry

The visible geometry of the model.

As an example: If you have an object with this LOD properly configured, you will not be able to spot other units through the model. AI will not be able to spot other units through the model.

Enphasis are mine.

Edited January 29, 2012 by gammadust

[Dwarden 1125]

anyway the problems here are multiple

1st is why the AI spots the targets (even when it's most likely covered by the present viewGeometry in the tree model)

this might be related to something completely different what makes the AI detect via the object ....

2nd is why the AI fires when the fireGeometry is present but most likely bugged or non-operational

anyway the real issue is that these trees are A2 content and it's atm. quite less likely that will get fixed ...

hence why i asked if there are more trees/trunks especially from OA/BAF/PMC content with same problem ...

[gammadust 12]

...

hence why i asked if there are more trees/trunks especially from OA/BAF/PMC content with same problem ...

Check the CIT and the gallery, there are 2 trees in takistan revealing the same issue.

Edited January 29, 2012 by gammadust

[maturin 12]

2nd is why the AI fires when the fireGeometry is present but most likely bugged or non-operational

I don't think we can be sure that this is a problem. Not until it is proven that the AI was trying to fire through the center of the tree, as opposed to the thin edges. 7.62x39mm goes through some pretty hefty trees in real life, after all.

I know there is a bullet tracing script out there somewhere...

[gammadust 12]

anyway the problems here are multiple

1st is why the AI spots the targets (even when it's most likely covered by the present viewGeometry in the tree model)

this might be related to something completely different what makes the AI detect via the object ....

2nd is why the AI fires when the fireGeometry is present but most likely bugged or non-operational

anyway the real issue is that these trees are A2 content and it's atm. quite less likely that will get fixed ...

hence why i asked if there are more trees/trunks especially from OA/BAF/PMC content with same problem ...

Those I am experiencing are definitly distinct issues.

On AI detecting an enemy, it simply seems to ignore whatever ViewGeometry is there. The only exception to this that I found is when target lies down. Either its detection view gets blocked by grass clutter, or by whatever else may be still working regarding the tree trunks ViewGeometry. This can be validated by the fact that using the nearTargets script the red smoke after a certain ammount of time starts to spread apart.

On AI firing at an enemy, there is definetly a certain room where an already detected target can move whithout getting shot at, no need to lie down or whatever. There is also a curious thing, if I am playing in recruit difficulty, we get to see a red transparent circle on the enemy (not to confuse with the red reticle - dashed circle - which equates well with perceived target position), this transparent circle appears to equate with the FireGeometry (not ViewGeometry) since as soon as I get shot at that transparent circle comes to light (despite being out of direct view), if I move and enemy stops firing, that circle equaly disapears.

These may point in the same direction, and even the same final cause of the problem, but they are definitly different symptoms.

Edited January 29, 2012 by gammadust

[maturin 12]

Either its detection view gets blocked by grass clutter, or by whatever else may be still working regarding the tree trunks ViewGeometry. This can be validated by the fact that using the nearTargets script the red smoke after a certain ammount of time starts to spread apart.

I agree. That sounds just my experience with the view script. I can't think of any way to test it without map editing and putting a tree on a runway or something, though.

[gammadust 12]

I agree. That sounds just my experience with the view script. I can't think of any way to test it without map editing and putting a tree on a runway or something, though.

I've been trying to cook up a way to better understand AI detection/firing but AI deals differently with objects, as opposed to infantry, it actually seems ever aware of them, disregarding ViewGeometry.

Maybe someone with better script skills, in-depth knowledge of configs could put it up. The idea would be to create an array of small objects disposed in a vertical plane which one would put behind the detection/firing obstruction. Object color would react to detection as given by nearTargets data. Objects maitaining color (or some other hint) would be those undetected. One could trace the working/non-working ViewGeometry effects in sillhuette.

Unfortunately, for one to be sure to have good results it would need a vehicle which mimics several properties which AI uses to detect enemy units (ie. threat, cost, accuracy, etc). Normal objects, not belong to any side, are perceived as Civilian, and AI appears "detect" these independently if they are in sight or not, even after _object setFriendly [Civilian,0]. I tried many ways to do this but there was always some hinderance somewhere.

Edited January 29, 2012 by gammadust

[Dwarden 1125]

thanks gammadust, not read the ticket's comments so thanks for pointing Takistan trees

[gammadust 12]

It just occurred to me that the problem could be related with the direction of object face normals, in the same sense that texture jobs makes a difference to have a certain orientation of that normal and it would be drawn or not.

I am just shooting randomly by this time, but it could be the reason, vertices were there but normals, if relevant to the way the engine deals with it, would be wrongly inverted or something. This would be easier to overlook when looking at the model source if checking only for the ViewGeometry presence.

[gammadust 12]

Just updated the CIT with some more findings

Conclusions:

Found out that the issue appears somehow related with the distance between the AI and the obstruction, if close enough the issue exacerbates.

The distance from AI to targets appeared irrelevant in tests.

Check this gallery and comments: http://imgur.com/a/QE1vl

Nevertheless, there are trees which while not having showed the issue, this AI distance to obstruction has no influence.

Revisiting previsously uploaded mission (AItracking_various_missions.zip > AItrackin_Bush1.Chernarus), one can see there is really some incomplete/incorrect detection view blocking going on (check comments): http://imgur.com/a/xEgV7

Introducing the "Bunny Test"... :bounce3:

Also of interest to anyone doing tests, i uploaded a test setup to help in easily find objects with broken view detection:

AIDetection(mission+scripts).zip

The script is easy to setup, start arma with BunnyTest addon, load up the editor, create player unit, create ai unit (name it "ai"),

save mission, copy both scripts to this mission folder ("init.sqf" and "gen_action.sqf") and run. Removed magazines from units so that they don't

fire each other while teamswitching, options to move units around on-the-fly implemented (map click and menu), other facilities are accessible

through this menu (check init.sqf for more info).

Edited February 4, 2012 by gammadust

[gonk 0]

Voted

[gammadust 12]

Updated the ticket with the following:

I came across another theory (as i delved in ogre3d forums), that could apply here and being consistent with previous findings.

Teodron was giving his opinion on approaches regarding using "static geometry" vs "instanced geometry" in the context of forest creation in a "paged" approach:

"Instanced is bad because of the following reasons: several trees in a line can trigger incorrect LOD decisions since the camera and the position of the instanced geometry might be too far apart, but then again, the scattering of the objects is so wide spread that you might end up with a low poly model close to the camera (because you're actually far away from the IG's origin). In frustum queries also don't work that well. FPS is also higher (10%) in comparison with the Static Geometry. (...)"

http://www.ogre3d.org/forums/viewtopic.php?f=2&t=69359#p453759

If i get this explanation right, and arma engine indeed instances tree models, and since viewGeometry is LOD dependent, what we may be facing is a similar phenomenon. This would explain why there appears nothing wrong with the given geometry, it is just that by instancing the original mesh which later comes repeated through out might just be far away from the viewpoint of the camera*, triggering LOD, and finally making one to be in the presence of a low LOD mesh giving arise to the symptom we see. This would also definitely explain why sometimes the same tree, which as shown the issue in some tests, does not show it in others. And also why if we look into the different trees it tends to be possible finding the issue with any of them (ie OA trees).

*viewpoint of the camera, or AI position, or player position, actual entity being detected, whatever serves as the anchor position from which LOD distance is being calculated.

This also raises the issue that a "stable anchor" is required in the distance assessment, imagine in the case of the camera viewpoint used being player's, AI would detect other units (besides player) based on a LOD that is simply unrelated to the unit being detected, in other words, this "anchor" would only make sense in regards to the player itself being detected (also what about multiple players?), if any LOD dependency remained it should be in regards to the AI doing the detection.

If this would apply, the issue lies in the arma engine, not as a bug, but as an "unintended consequence" of its design. If so, and thinking about solutions to this problem, maybe just switching AI detection to one based on the fireGeometry geometry (which if i am guessing right does not have LOD, despite less precise base one) would solve the issue still being a good compromise.

Anyway, hopefully whatever its actual causes, hopefully Arma 3 won't raise the same issue.

Edited March 27, 2012 by gammadust
clarity

[suma 8]

Several assumptions are incorrect here:

Instanced is bad because of the following reasons: several trees in a line can trigger incorrect LOD decisions since the camera and the position of the instanced geometry might be too far apart, but then again, the scattering of the objects is so wide spread that you might end up with a low poly model close to the camera

This is not an issue in Arma, as we were aware of the problem and we perform LOD selection first and instance only trees for which the identical LOD is selected.

viewGeometry is LOD dependent,

This is also incorrect. Each model contains only one view geometry, and this view geometry is not LOD dependent in any way.

[gammadust 12]

There would be only one reason I would ever like to be right in this case... it would be to get the cause behind this identified.

I got the idea of viewGeometry having a LOD from some samples I opened some time ago, but maybe I am just missing the point here for some reason.

Anyways that piece of a puzzle (let me underline its Teodron's not mine's) just seemed to fit perfectly in this one. It was worth a shot.

Suma, don't take it too much as assumptions per se on my part, this is a collection of "if"s that grow with the hipothesis/explanation one is trying to come up with.

In this case the association just appeared to me too plausible, despite misplaced.

I can't say "glad I'm wrong" in this case, only "bollocks... i'm wrong"

Best regards

PS: I wasn't exacly expecting to be answered by the lead developer for this, Dwarden was doing a good job at it :) thank you for your time of course