Welcome to
Microsoft Flight Simulator’s SDK Q&A Platform!
Please take a moment to read the platform’s guidelines before you get started!
Would it be possible to have some kind of system that lets us define additional virtual "cameras" in the sim and render them to an HTML image (kind of like synthetic vision on the Garmins does, but with more detail) ? This would be necessary to create cameras in the sim avionics, which many aircraft, including the A380, A350, SR22, etc. make use of.
It's handled fairly well in P3D and XP11 already with almost no noticeable frame impact. The virtual cameras themselves won't be used unless an addon explicitly makes use of them (and will probably have an option to disable them), and the cameras themselves are fairly low quality, both in terms of resolution and refresh rate. We don't need something perfect - even something similar to the existing synthetic vision on the sim's Garmins would work.
Hello.
This topic has been addressed during the SDK Q&A on twitch: https://www.twitch.tv/videos/1292592820
It's not in the roadmap yet because of engine capabilities and performance reasons.
So the answer is no, at least in the short/medium term.
Regards,
Sylvain
I am surprised that you "do not see any reason" since we explained multiple times already why we were not planning to offer this feature for now. It also sounds a bit biaised to claim that "competitors did it 5 years ago" since, as far as I know, they do not offer the same rendering quality as MSFS (but maybe you disagree on this point).
Best regards,
Eric / Asobo
Hello Eric, I appreciate the response. I’d like to reply to second part of your response as it shows a bigger issue in how Asobo sees MSFS.
Yes, rendering quality and end result for graphics are far superior compared to other sims. This is a fact. I’m calling “other” as even though its same market, MSFS and the way its going is not a competitor to them. Anyways, the issue I see here is the lack of commitment from Asobo. As far as I see, you do not want this to be “go-to” simulator. Things like these are important because it’s it enables more in-depth simulation. Everybody, accepts that graphically MSFS is far superior. However this is not what people are discussing here. They are discussing it for realism, more in-depth simulation etc. this is where Asobo is falling behind. A lot. I’m sorry but I understand there are contractual obligations, revenue generating features and partners in concern but when will Asobo take things seriously or provide support for more in-depth simulation? From what we see you guys are developing the sim, doing great things but its 4 steps forward and 3 steps back. For instance WXR issue. Asobo said they fixed it and provided API yet it’s no where near what its needed.
To summarize, I think there are bigger issues here. And these issues start from the fact that you guys look at things from graphical and perception point of view, not realism or actual simulation aspect of it. Which I find it interesting, name of the game is “Flight Simulator” yet Asobo does not accept feature requests from 3rd party developers that are related to improvement of simulation aspect of it.
Since my role here is to provide support to developers and not really to debate with them, I'll try to keep it short:
Best regards,
Eric / Asobo
Apart what other simulators are offering, isn't the MSFS graphic engine derived from Forza games ? All these games surely some kind of Render To Texture methods, for example in Rear view mirrors, so there must be something in the engine supporting that.
The relationship between our engine and Forza's engine is a myth - I have no idea if the person who wrote this was just speculating or if he should change his sources (maybe both).
The rear view mirror example is interesting: in most (if not all) racing games, the rear view mirror shows a (sometimes very) degraded view of what the main view could display (potential optimizations are a limited draw distance, toned down FXs, lower LODs...).
One thing to keep in mind is that these games also have control on what assets they are loading/rendering, which is not the case for MSFS.
The bottom line is: of course our engine is capable of RTT but there are other aspects that need to be taken into account (which mainly affect performance) before thinking about opening this to add-on developers.
Best regards,
Eric / Asobo
The rear view mirror example is interesting: in most (if not all) racing games, the rear view mirror shows a (sometimes very) degraded view of what the main view could display (potential optimizations are a limited draw distance, toned down FXs, lower LODs...).
Sure, mirror won't ever require to have the same amount of detail of a normal view, it's overkill and not really required and for applications like "cameras" that project over a texture, it's perfectly acceptable to have a lower resolution, with no effects and perhaps limited shading.
However, RTT camera views are just one of the possible applications for RTT, another big one would be programmatically draw on a texture surface without having to necessarily project an existing view. Something like using one of the methods available in Gauges, like NanoVG, but over an arbitrary texture in the scene that is not necessarily a Gauge in an airplane Panel, with the feature possibly accessible through a stand-alone WASM module that register to some kind of callback whenever such texture is defined ( like the $-prefixed textures available since FSX )
In that case, it will be entirely the add-on developer responsibility of being careful how complex the drawing is, exactly like a Gauge developer is already supposed to do now.
