Tracking dead targets?

[DMarkwick]

Last night I noted that I couldn't obtain a target acquired on a tank, only to discover that it was dead, having previously been dispatched by me a while back. The fires were out & it was no longer smoking :)

 

Which led me to think - what exactly is the criteria for the system to acquire a track? I would have thought that it would track anything I decided to track, whether it was "alive" or "dead".

Edited May 12, 2009 by DMarkwick

[DMarkwick]

Bleah. Wrong forum :) can a kindly moderator please move it? :)

[SuDepp]

.....it is said before --> seems to be a weakness of the engine - in real life the lock will stay after finishing the targets and the stay lockable for sure!

Within BS the targets wonґt be targets anymore after being destroyed......

 

Never forget - it is a simulation! If U want real life - open the door and go outside ;)

 

Greets

S@uDepp

[Boberro]

Member above is right. Engine limit or\and too many counts to do for processors.

[DMarkwick]

Member above is right. Engine limit or\and too many counts to do for processors.

 

I don't see how that could be the case, seeing as they're all valid targets when "alive" there cannot be a CPU limit for them to remain a valid target when "dead" :)

 

It might be something as simple as a geometry issue, I often see vehicles traveling through "dead" vehicles which indicates to me that there's no collision geometry for the AI to process. Maybe it's this collision LoD that the sim is targeting. In that's the case the simple fix would be to apply a simple collision LoD even if it's a basic cube or something.

[pitbull]

Correct me if i'm i'm wrong, but IRC, dispatched targets "disapear" from the AI, all you see is a unlockable target. that is why we cannot lock a dead target. and teh reasoning behind this is to lessen the load on the engine.

[Boberro]

I don't know if I understood correctly but in DCS there is too much work for CPU to make real image processing like in real Ka-50. So it is simplified to dead or alive. 0 and 1.

[DMarkwick]

I don't know if I understood correctly but in DCS there is too much work for CPU to make real image processing like in real Ka-50. So it is simplified to dead or alive. 0 and 1.

 

This is sort of what I was trying to get at in the OP, what is the criteria. I guess I should ask: what is the criteria in DCS vs what is the criteria IRL?

 

IRL, is the tracking purely image analysis?

[sobek]

IRL, is the tracking purely image analysis?

 

Tracking by means of contrast, just like every optical system works.

[Hobnail]

I don't know if I understood correctly but in DCS there is too much work for CPU to make real image processing like in real Ka-50. So it is simplified to dead or alive. 0 and 1.

 

But on the flipside there are 100's of buildings and static objects strewn across the map that can be locked up at any time, they're not invested with AI. If optimising the engine was the reason then why leave that in?

[viper169th]

Hi DMarkwick,

I'm glad to see you made it to BS I think the reason why is the added objects because you can spawn units using the editor when you make a mission that means you had 50 units killed them added 50 more ect... eventually it would overpower the work load on the processor depends on the mission how many fps would be lost sort of like the arma multi-player clean up dead units scripts ;)

 

Sincerely,

Viper169th

[DMarkwick]

Hi DMarkwick,

I'm glad to see you made it to BS I think the reason why is the added objects because you can spawn units using the editor when you make a mission that means you had 50 units killed them added 50 more ect... eventually it would overpower the work load on the processor depends on the mission how many fps would be lost sort of like the arma multi-player clean up dead units scripts ;)

 

Sincerely,

Viper169th

 

Hi there Viper :) BS was always going to happen to me sooner or later... I was just waiting on an appropriate release format & DRM setup :)

 

You might be (partially ;)) right with your assessment there, I think the devs have not nothered to give the wrecks any collision LoD and I think the engine possibly uses that geometry for its targeting. So I guess a mod that replaces the wreck model but has the inclusion of a very simple collision LoD might very well fix it. A simple cube would be fine, roughly the size (or a little smaller) than the geometry bounding box say.

 

I think you're right in that the collision geometry is taken into account for AI pathfinding by the looks of it (buildings are avoided, trees are not) but I think given the huge amount of collision objects already existing, and the likelyhood of AI being overly confounded by wrecks laying about the place, I'd rather have the ability to target destroyed vehicles. It's a battlefield FUBAR I know, but it's realistic I think. At least until longer lasting wreck smoke can be modded in ;)

[goldfinger35]

While we are on this subject:

Is there a way to UNLOCK a target (without destroying it)?

I sometimes lock a "wrong" target and the only way of unlocking is to reset (backspace).

[slug88]

While we are on this subject:

Is there a way to UNLOCK a target (without destroying it)?

I sometimes lock a "wrong" target and the only way of unlocking is to reset (backspace).

 

Just hold down the LOCK button while moving the SHKVAL cursor to the preferred target.

[goldfinger35]

I have tried that - very clumsy when i try that with my X52 joy. I guess I will have to remap some of my keys.

Thanks.

[Bluduh]

Yeah, it took me a while to get used to that "hold down and slew" on my X-52. But you only have to slew enough to achieve a "break lock". Then, you can slew normally to the target you want, then hit the "lock" button again to re-acquire the lock on the target you really wanted.

[nemises]

Hi there Viper :) BS was always going to happen to me sooner or later... I was just waiting on an appropriate release format & DRM setup :)

 

You might be (partially ;)) right with your assessment there, I think the devs have not nothered to give the wrecks any collision LoD and I think the engine possibly uses that geometry for its targeting. So I guess a mod that replaces the wreck model but has the inclusion of a very simple collision LoD might very well fix it. A simple cube would be fine, roughly the size (or a little smaller) than the geometry bounding box say.

 

I think you're right in that the collision geometry is taken into account for AI pathfinding by the looks of it (buildings are avoided, trees are not) but I think given the huge amount of collision objects already existing, and the likelyhood of AI being overly confounded by wrecks laying about the place, I'd rather have the ability to target destroyed vehicles. It's a battlefield FUBAR I know, but it's realistic I think. At least until longer lasting wreck smoke can be modded in ;)

 

Allthough, the AI pathing does avoid wrecks as well..or at least for a period of time (while emiting smoke?) ... so by that reasoning, we can assume that wrecks do (possibly) have a collision box, and that the inability to target them with Skval is another property alltogether.

 

Also, consider the Skval cannot lock targets once it gets too dark...this is done dynamically, and I cannot imagine it is achieved by removing collision properties ...

 

My guess is there is some rudimentary ray casting to detect an object , and that, if destroyed, or if after/before a certain hour of the day, the object no longer recieves ... seems like something that might be moddable though, assuming the "recives Shkval rays" property is exposed ?

 

Perhaps Ulrich or someone can elucidate?

[DMarkwick]

Allthough, the AI pathing does avoid wrecks as well..or at least for a period of time (while emiting smoke?) ... so by that reasoning, we can assume that wrecks do (possibly) have a collision box, and that the inability to target them with Skval is another property alltogether.

 

I just tested this out: before destruction a target has collision. After destruction, the target does NOT have collision (lost a few nosecones testing that :)) I tested by both colliding my helo into vehicles, and by observing traffic on roads passing right through.

 

Also, consider the Skval cannot lock targets once it gets too dark...this is done dynamically, and I cannot imagine it is achieved by removing collision properties ...

My best guess (which is all it is :)) is that targeting in the dark is partially dependent on ToD. Or at least a value that represents light levels.

 

To examine more fully a previous poster's assertion that the real-life counterpart's tracking method is based on image analysis & contrast, I completely dropped the contrast & brightness on the display & still achieved a lock. This either means that the targeting in the sim is based on something other than image, or that the settings on the visual display do not affect the system's image, or both.

 

My guess is there is some rudimentary ray casting to detect an object , and that, if destroyed, or if after/before a certain hour of the day, the object no longer recieves ... seems like something that might be moddable though, assuming the "recives Shkval rays" property is exposed ?

I would say that's a definite, so I guess the question is what LoD geometry is the raycast tested on? My current thinking is still the collision LoD :) and if so, then it would be a simple fix to just add a basic cube to wreck model geometry.

 

It would be nice for the sim to actually have an image analysis solution to the tracking if that's what the KA-50 really does, but I'm not going to get all panty-bunched by the notion that the behavior is simulated using another method :) I do think however that the tracking of dead objects should be allowed for, as otherwise it's a minor help mechanism for determining the unit strength etc.

 

Another factor, although a minor one, is that, so far in my experience (which isn't a lot I'll grant) setting an inappropriate target bracketing size doesn't have an adverse effect. I would imagine that in a purely image-based analysis tracking method it would be much more important to get this part right.

Edited May 15, 2009 by DMarkwick

[Scrape]

To examine more fully a previous poster's assertion that the real-life counterpart's tracking method is based on image analysis & contrast, I completely dropped the contrast & brightness on the display & still achieved a lock. This either means that the targeting in the sim is based on something other than image, or that the settings on the visual display do not affect the system's image, or both.

 

I would say that's a definite, so I guess the question is what LoD geometry is the raycast tested on? My current thinking is still the collision LoD :) and if so, then it would be a simple fix to just add a basic cube to wreck model

Another factor, although a minor one, is that, so far in my experience (which isn't a lot I'll grant) setting an inappropriate target bracketing size doesn't have an adverse effect. I would imagine that in a purely image-based analysis tracking method it would be much more important to get this part right.

 

 

The contrast and brightness of a display is not the same as the logic that the targeting system understands. Lowering the brightness on your TV doesn't affect the signal coming through the wires it mearly affects the translation of that signal.

 

The targeting box tells the computer where to look. What area to cover when attempting to locate a target. When a definitive shape has been identified then the computer will initiate a lock. Having the box set too big or too small will not affect this process only the scope and azimuth of the "search area". Think of it as a "look in here" box. Most of these systems resize the box to the locked target (not 100% about the BS) automatically. This avoids relocking or target switching say when a person (target) walks infront of a building then the building could become the new target. This could happen if the box remains large enough.

[DMarkwick]

The contrast and brightness of a display is not the same as the logic that the targeting system understands. Lowering the brightness on your TV doesn't affect the signal coming through the wires it mearly affects the translation of that signal.

 

Well if that's true then fair enough. But I would have thought that manual manipulation to allow for a more accurate tracking solution would have been implemented. However I can accept that that's part of tests & adjustments as part of preventive maintenance :)

 

The targeting box tells the computer where to look. What area to cover when attempting to locate a target. When a definitive shape has been identified then the computer will initiate a lock. Having the box set too big or too small will not affect this process only the scope and azimuth of the "search area". Think of it as a "look in here" box. Most of these systems resize the box to the locked target (not 100% about the BS) automatically. This avoids relocking or target switching say when a person (target) walks infront of a building then the building could become the new target. This could happen if the box remains large enough.

 

My understanding is that effective bracketing frames an area of video that the system will look for on the next frame, you're right in that too small a bracket would still give an effective track, however I believe a small bracket tracking a dark pattern on a dark larger target would incur small errors, but too large a bracket allows for larger incremental errors over time. I don't see that activity when I artificially increase the bracketing box even with a lot of lateral tracking with confusing surrounding imagery.

 

I'm assuming that the tracking system is an analogue solution not a digital solution, which is why I think proper bracketing is required.

Edited May 15, 2009 by DMarkwick

[CE_Mikemonster]

It confuses me a bit, I tend to simply use the TD box as a 'snipers crosshairs', smaller the better.