Shkval realistic?

[sobek]

*cough* CUDA *cough*

 

I'd rather have more rendering be done by the GPU than a small feature that could cripple the whole game FPS wise.

[DarkWanderer]

Also potentially due to limitations of computing power, you don't want to leave 'wrecks' as lockable targets any longer, though perhaps that particular issue is passed and is now only a design limitation.

The problem is, if you now have a lot of spawn triggers, how do you clean up the mess of old destroyed vehicles?

Note that the wrecks remain on the field regardless of triggers or anything.

Also, I don't think testing of lockability takes more than 5-10 strings of code (and 0.5-1% total computing time) either.

 

Image processing is indeed an overshoot for a sim, but an ability to lock on wrecks exclusively added in a patch will not significantly increase computing costs, though will require some code re-working.

[Boberro]

Also, I don't think testing of lockability takes more than 5-10 strings of code (and 0.5-1% total computing time) either.

 

I could agree.

 

 

Image processing is indeed an overshoot for a sim

 

Maybe it wouldn't have been overshoot if we had a "multicored" application? Example for quad cores? Then it would be more than possible to make this than on only one core I guess.

Edited March 16, 2009 by Boberro

[DarkWanderer]

Maybe it wouldn't be overshoot if we had a multicore application? Example for quad cores? Then it would be more than possible to make this than on only one core I guess.

Well, it could be done on a modern processor like i7 or DX10 video card, but developing a brand new algorithm (which may take significant time) and using a power of a separate processor core or a considerable fraction of GPU power is a little too much for eliminating just one issue, that in fact can be solved much more elegantly.

[Made.In.China.00]

*cough* CUDA *cough*

 

Or maybe OpenCL? So ATI guys won't be left out in the cold.

[Made.In.China.00]

When you consider that merely turning the TV monitor on already hits your FPS, I am pretty confident that a real-time image analysis model is not a practical solution - at least not for ED's near future.

 

I'm sure technology and solutions will advance, but I don't think it's as easy as, "hey, let's make it do image analysis." :) ED had already considered that.

 

Of course, I'm sure that as one of the best software makers I ever seen, ED had already considered that. But I'm still curious about this: cameras can recognize faces, so how difficult image processing really is? I mean, those chips in cameras can't be very powerful right?

BTW, I do think this is not an important issue. The black shark is just so great that we only have this kind of unimportat matter to talk about.:thumbup:

[GGTharos]

Of course, I'm sure that as one of the best software makers I ever seen, ED had already considered that.

 

They have, if briefly (I recall discussing with a dev)

 

 

But I'm still curious about this: cameras can recognize faces, so how difficult image processing really is? I mean, those chips in cameras can't be very powerful right?

 

On the other hand, that is ALL they do. There's simply no comparison between a dedicated ASIC doing this sort of thing, and your simulator trying to do it. And realize that it would have to do it very, very often.

 

I would also assume, but I don't actually know for certain - that the requirements for target tacking methods and face detection (not recognition - two different things ;) ) are rather different, though you could argue that in principle they are the same thing. I'll tell you right now that my 700mhz athlon box requires 2-5 seconds to process each pair/triple of 640x480 images and track a target. (yes, I have an app that does something like that with a webcam)

[arneh]

I'll tell you right now that my 700mhz athlon box requires 2-5 seconds to process each pair/triple of 640x480 images and track a target. (yes, I have an app that does something like that with a webcam)

 

And then you have freetrack which tracks a three lights 60 times a second without using notable CPU. Image tracking isn't necessarily expensive.

[weasel75]

And then you have freetrack which tracks a three lights 60 times a second without using notable CPU. Image tracking isn't necessarily expensive.

 

Tracking bright (the brightest) spot(s) in a picture is far, *far* more easy than trying to find a pattern among lots of potentially similar patterns with considerably less contrast.

Also consider, that the original pattern (which you try to track) will change, due to the angle and distance of the tracker, changing light-conditions might also affect it.

Even the line of sight might be interrupted (trees, smoke, objects, etc), or similar objects might move in front of each other (e.g. cars passing by).

 

In the end one would write a tracking-software for information we already have (in that case: even generated!).

I think it would be easier, to not remove the destroyed objects from the list of "valid" objects for the camera/tracking ;)

[Made.In.China.00]

I agree that face, in this case, target detection, maybe very resource intensive, but as I'm not a programmer, I have no idea how intensive it actually is, in fact, not many people do. So maybe someone from ED or a professional programmer can set this once and for all. Cause all we are doing here is pure speculation.

So here's my part of the speculation::music_whistling:

There is a program called Camspace http://www.camspace.com/ It kind of does what Shval should be doing, track targets basically. And it does not use a lot of processing power. I didn't play with it for long cause my webcam can't do 30fps, so I'm not very sure, maybe someone can try it? Anyway, it's a cool app, so try it out.

 

EDIT: Even if it does use a lot of processing power, GPGPU should be a possible solution, we are not letting our GPUs work very hard anyway. CUDA, ATI Stream, OpenCL already exist , so the possibilities are there. BTW, the new engine is much more important than this, so GET THE ENGINE OUT FIRST!

Edited March 17, 2009 by Made.In.China.00

[GGTharos]

No, it doesn't. Camspace works with high contrast objects that are easy to make out from their background.

 

The shkval works with much more noise. NOISE requires plenty of filtering power. I'll remind you why radars still use doppler techniques rather than some sort of subtractive technique whenever possible:

 

Because filtering noise and 'cheating' reduces required processing power that can then be used for other things. The Shkval might not get to cheat so much - or, it might use a process that is difficult to model electronically.

 

Then again, I could be wrong, who knows ;)

[EvilBivol-1]

So maybe someone from ED or a professional programmer can set this once and for all.

One of ED's avionics programmers said this on the beta forum just under a year a go:

May be one day I will pay attention on a realistic image tracker - it is a very CPU demanding routine.

See, we told you so. ;) Edited March 17, 2009 by EvilBivol-1

[sobek]

Does that basically mean that the shkval will, under the current circumstances, track targets also in a pitch black environment? Or is the light level taken into account?

[arneh]

Tracking bright (the brightest) spot(s) in a picture is far, *far* more easy than trying to find a pattern among lots of potentially similar patterns with considerably less contrast.

 

In DCS all the objects you want to track are quite a bit darker than the surroundings, and the tracker would be somewhat helped by the pilot telling it the size of the object the shkval is trying to track (by adjusting the tracking gates). And I suspect it may actually just add to the realism if the tracker may lose track if the target gets too diffuse.

 

That said I do realize this is not something trivial to do, and it's not very important. And I perfectly understand if ED rather want to use their time on something more important. But at least TrackIR and Freetrack has shown that doing image tracking in real time without much CPU is possible on a desktop PC.

[sobek]

But GGs argument still applies, the SNR with the headtracking devices is a LOT better than any DTV image could ever be. Filtering images implies using fast fourier transformations, which can use lots of power if not run on specialised hardware.

[amalahama]

But GGs argument still applies, the SNR with the headtracking devices is a LOT better than any DTV image could ever be. Filtering images implies using fast fourier transformations, which can use lots of power if not run on specialised hardware.

 

Winamp does FFT in realtime...with very low CPU load!

 

Regards!!

[EvilBivol-1]

Does that basically mean that the shkval will, under the current circumstances, track targets also in a pitch black environment? Or is the light level taken into account?

Have you not flown any night missions? ;) Light level is currently modeled, as well as artificial lights like on-board lighting, fires, illumination flares. But these things are programmed in as arguments, not dynamic image tracking. Edited March 17, 2009 by EvilBivol-1

[GGTharos]

Please don't compare sound processing to image processing.

Yes, both are 'signal processing'. That's where the similarity ends.

 

Winamp does FFT in realtime...with very low CPU load!

 

Regards!!

[amalahama]

Please don't compare sound processing to image processing.

Yes, both are 'signal processing'. That's where the similarity ends.

 

I am not comparing anything - only say that a simple FFT is not so core-intensive. I don't know how image processing is carried out, though

 

But I doubt real Shkval do a digital image processing to lock into moving targets - I bet it do that in a simpler, analogic way!

 

Regards!!

[GGTharos]

No, it doesn't do digital image processing, and IIRC neither do AGM-65A-D.

 

It locks onto a patch of differing contrast, as far as I know.

HOWEVER, all we can do in DCS IS to use digital processing to emulate an analog process ;)

 

EDIT: And here's an example of such a system for you - http://www.google.com/patents?vid=USPAT3953669

Edited March 17, 2009 by GGTharos

[amalahama]

No, it doesn't do digital image processing, and IIRC neither do AGM-65A-D.

 

It locks onto a patch of differing contrast, as far as I know.

HOWEVER, all we can do in DCS IS to use digital processing to emulate an analog process ;)

 

EDIT: And here's an example of such a system for you - http://www.google.com/patents?vid=USPAT3953669

 

Wow, thanks you GG!

 

Regards!!

[Frederf]

Poor Tharos, having to put up with weak arguments that having realtime image analysis akin to how the Shkval really picks out tracking targets would be a 'piece o' cake.' I feel for you.

[Made.In.China.00]

Thanks, EvilBivol, that's what I was looking for.

By the way, you guys (including GGTharos) seem to know everything posted on the forum... :smartass:

[tflash]

Anywayz, dropping the "arcade" word on this board is like shouting "fire" in a crowded discobar. It is close to criminal behaviour and should get you in trouble with the realism police! Let's be careful next time!

 

But let me ask a question which goes back to the main issue: in LO:FC, I often fire a Vikhr with the Su-25T *without* locking a target, but by just having ground stabilized the schkval. This allows me to pinpoint a target quite loosely, without having to adjust target size etc.

 

It's like the "area" mode on Maverick missiles.

 

Is this possibe IRL? And is it possible in DCS:BS?

[192nd_Erdem]

No, it doesn't do digital image processing, and IIRC neither do AGM-65A-D.

 

It locks onto a patch of differing contrast, as far as I know.

HOWEVER, all we can do in DCS IS to use digital processing to emulate an analog process ;)

 

EDIT: And here's an example of such a system for you - http://www.google.com/patents?vid=USPAT3953669

 

It shouldn't be hard to program a simple image-processing script that allows locking onto "contrasted patches". You can very well represent analog processes in a digital sim ;)