Sgt_Baker

Computationally it's not exactly rocket science to implement a real-world simulation of IR rendering/interpretation. Given that we're talking about tanks, aircraft, humans: Simplistically assign their model a single float defining their average temperature; assign the surrounding an average temperature; have the IR-sensor pixel shader calculate the contrast between the two. Could the "difficult" complaints merely be the hassle of going through every model and assigning them a temperature? Of course, making engine compartments "glow" and vehicle tracks do the same is much more involved, but that's not what we're asking for here, is it? What we're asking for is thermal imaging: Imaging where a tank in full battle should stand out like a nuke in an IR image. Not this silly reprocessing to B&W of the visual image that we currently "enjoy". (Or at least that's how it looks to me) --Baker

On the contrary, it's a universal renderer. It's coded in such a way that it's relatively easy to port old-style displays over without too many headaches. That's why I've taken my sweet time implementing the new system: Making sure I avoid brain tumours further down the line. The reason I chose the A-10C CDU first is that it's by far the most complex and demanding display currently in the uMFCD system.

Roger that. I've been on something of a holiday from the ol' bug hunting. Starts messing with your mind after a while, you see. I'm going to release the new renderer/CDU in to beta, then get back to proper testing/bug-squashing on this end. --Baker Edit: Really what I need is a biological robot to collate, categorise and make initial sense of the initial bug reports. :D

It it the only one working in the KA-50 or the only one working full stop?

We have ignition, so to speak!

Hi Regi, Exactly which versions of UltraMFCD, DCS and Windows are you running? I've tested the scenario you mentioned on this end and everything works as one would expect. A couple of things you might like to try: 1) See whether using the latest beta version makes any difference. 2) Complete a Diagnostics Package and post it back here or to the uMFCD forum. Cheers, Baker

Well... the new efficiency drive is proving fruitful. The previously mentioned CDU MkII is now so efficient that my AMD 7970 Black Edition (not exactly the greatest of cards these days) not only registers 0% GPU use with the CDU running in isolation, but even sees no need to switch out of its lowest power state. Should now be able to apply this system to every display that doesn't render video (targeting pod) data. --Baker

Thorough planning has already taken place regarding multi-machine implementations of uMFCD. Additionally, the removal of Windoze "black box" rendering is critical to making that happen properly. We are, of course, heading rapidly in the direction of niche applications. :) --Baker

The new effort is precisely about that. In the old days, DCS's DX9 rendering system was so crappy that any decent GFX card was left 60% idle. That changed with DCS's move to DX11, resulting in uMFCD and DCS competing directly for GPU resources. Obviously a mod that adversely affects the fundamental performance of DCS isn't exactly ideal, hence recent efforts to reduce uMFCD's interaction with the GFX card to the minimum possible. Then again, and I'll say this with a stiff, British upper lip: DCS's DX11 rendering engine isn't exactly a Ferrari... more like a last-legs banger of a car. I'm removing every last redundant or unnecessary GPU/CPU call from my software for identical or better effect. Hope ED might some day do the same. :)

Ah, yes. That XamlParse thing. We dealt with and squashed this one once before. Can't remember off the top of my head what it was, but there are lengthy written records to pore over. The current state of affairs is such that I NEED to finish "fresh" development without getting bogged down in chasing and eliminating bugs that affect a minority of users. Without delineating blocks of time to concentrate on the future, we'd still be stuck with two MFCDs and nothing else. Believe you me, chasing bugs can consume ALL of one's time and effort. Ironically, yet positively, the new CDU rendering stuff is a complete move away from M$'s often unpredictable XAML way of things. The old CDU, which was rendered mostly in XAML was uncontrollably spewing so much weird stuff at the graphics card that things HAD to change. Hence my relative silence of late - developing a pure DX11 rendering system that still works in a window, you see. So I'll leave it at this: Let me finish things on this end where the stake in the future-ground is concerned. Then I'll get back to bug chasing. Regards, Baker

Have now finished work on the new CDU's rendering system. Now just a matter of wiring up all the keys so they actually do something. :) --Baker P.S. The Dim/Brt buttons will now function: Switch between day and night modes.

Hi Terrovogel, It probably is something to do with the massive res/number of screens/number of adapters. As it so happens I discovered a potential cause for this bug the other day. We previously had a problem whereby DCS and uMFCD could end up running on separate graphics cards (not good). While developing the new CDU I discovered that the code I'd put in place to attempt to avoid that wasn't as foolproof as it could be. That said, I was never able to reproduce said bug locally, so it was a shot in to the dark. Obviously with that number of cards the likelihood of things getting out of whack is much higher. On a side note, it's good that you already have the MFCDs set to render on the main card. This avoid transferring real-time uncompressed video (which is essentially what the main MFCDs are) over the PCIe bus, which comes with an obvious performance penalty. I'm just finishing up the new (and very pretty) CDU, which in and of itself has brought with it a 100% custom DirectX rendering solution. It needs to be done /right/ as opposed to hastily. :) Once that's ready for beta testing I'll be in touch to see whether we can get to the bottom of thus multi-adapter problem. Regards, Baker

UltraMFCD isn't like other mods. It's only active when you're running the EXE - it makes zero changes to your install even when it's running (even if the entire system crashes, your DCS install is untouched), so by definition there is no uninstallation process other than deleting the uMFCD files, wherever you put them. Hope that makes sense! --Baker

...Thinking about it, it may be possible to fiddle with the internals of the TGP/Shkval to emulate recon point-of-view, but I'm not certain how DCS would respond to the desire to switch between the two. It's an interesting question. :)

That's actually something I've thought long and hard about. In the first instance, the answer is a resounding NO. In order to render completely independent views, and have them arrive in useful memory, action is required at the source code level of DCS. There's a long-winded explanation behind this, but it boils down to each view requiring a complete pass of the rendering engine. A bit of background: So, when you switch on that TGP/Shkval and your framerate tanks? Obviously it does. The graphics engine is rendering everything from the Pilot's point of view, then re-rendering (part or perhaps nothing) of the scene from the sensor's PoV. If it's a wide-angle sensor, it's more or less like rendering everything like-for-like twice, or worse, rendering a completely different scene in the sensor is looking backwards. UltraMFCD can fiddle with rendering passes as they happen, but can't magic new passes out of thin air. HOWEVER! I may be a slow-moving modder at times, but I already have a design and pre-alpha system for sending sensor images from one instance of UltraMFCD to another. Thus, in multiplayer, the role of a FAC would be enhanced immensely. Does this make sense? --Baker

It doesn't need to be installed anywhere in particular. Just launch the EXE and it should take care of the rest. Are you running any other mods such as SweetFX, perchance? --Baker

I also think it's something people take for granted. While, say, adding a new aircraft might appear trivial - this is a flight sim, right - the devil is always in the details. And then, as Pikey said, along comes a patch and ruins everything overnight. All modders must be mildly insane by definition. Respect them - you really don't know what they're capable of. :D

No information is transmitted from your install. Information such as the current version etc. is retrieved from ultramfcd.com. Hope that alleviates the paranoia. :)

I should point out that the previous image is exactly what the CDU in the non-VR versions will look like.

It's on the way, yes. What you see above is a photo-realistic rendering of a full-fat 3D model of the CDU. I'm slowly working on a rendering engine that is extremely efficient where instruments are concerned. Once that's done there's really not much preventing rendering directly in to DCS's "space" using the technology we already have pulling data the other way. --Baker

Hey folks, Took a much-needed holiday away from chasing uMFCD/DCS interoperability bugs and instead performed some work on a much-needed visual revamp, along with the first steps towards full 3D/VR rendering. --Baker

UltraMFCD Beta 2.5.8 available here. Hopefully fixes latest issues mentioned in this thread. --Baker

Hi majapahit, Just a hunch, but what happens if you disable VoiceAttack and any screen recording software like FRAPS? Additionally, are you perchance running SweetFX or anything similar? --Baker

There are actually a lot more problems with the latest update to 1.5.x. Specifically "Mouse cursor will not be moved outside of DCS window when game window resolution less then desktop resolution" in the DCS changelog is completely messing with us at the moment. Man... can I not have two weeks without something changing? --Baker Edit: The cursor positioning problem is fixed on this end and will be patched in the next uMFCD release.

Yeah, that's a failed experiment right there. What I was trying to do was make uMFCD a little more greedy with the gfx card when it gets close to 100% load, since it's presently throttling back a little too aggressively. Think I'm definitely going to have to revert that change, since there are many reports of precisely the behaviour you're experiencing. --Baker