Camera API Discussion

[Arzop]

Hi

I wish you all a Happy New Year! Glad to see so many feedback

Here is a first set of answers:

What is being done in WASM or through SimConnect to ensure our camera code can access the latest aircraft data (and AI traffic data for tracking shots) after it was processed for the next frame but right before the camera positions are sent to the GPU? The current standalone update in WASM modules happens after the camera is sent to the GPU and would always lead to data being processed 1 frame late.

The Wasm update function is always called before the draw phase and is awaited before the start of any GPU configuration. I suspect that the update function is called too early, so the position is modified afterward. We are thinking about this and will come back later.

Will TrackIR, Tobii & VR offsets be added on top of the position injected by the camera?

Exactly, the position of the camera is setup programmatically by the addon and then, the user’s offsets will be computed based on that.

Are there any way we would trigger those (Node Visibility) through WASM/SimConnect based on a node name we specify?

It is not planned to give the ability to display/hide any node in a model. However, if it is possible to hide the yoke of a plane, it is also possible to trigger this behavior using Wasm/SimConnect by triggering the right Input Event.

If the user presses a button to go to Drone mode in our camera system but it’s also assigned in the sim, will the sim kick us out in favor of the default drone camera?

Drone camera is part of the same camera category as the Cockpit Camera, External Camera… Therefore, trying to switch to those cameras is not allowed as long as an addon has acquired the Camera.

If a custom camera system is developed using this API, Will there be a change to allow 3rd party in-game panels while in missions, careers and activities?

Planned for SU5

It should be opened for Career, Trainings, Certifications and Custom Content. It should stay forbidden for Challenges.

Instead of only orientation (PBH), some APIs allow specifying a “look-at” point in world coordinates.

Good idea!

Will we be able to enable the flashlight in all camera modes with new API touches?

Unfortunately no. Flashlight is deeply linked to Cockpit Camera and it won’t change for the first stages of this API. Feel free to request it in the global wishlist.

Is there any possibility this will ever be back-ported to 2020?

Not planned at the moment

Multi Monitor questions

instead of just one, with the ability to

• create (and destroy) those dedicated cameras, control them via an ID that you received upon creation

• assign these dedicated cameras to render windows

Are you talking about having multiple renders at the same time? Or are you referring to save multiple configurations and switch from one to another at runtime? @xocuv

Select which of the pre-defined cameras is shown in a specific render window, this was previously done by selecting a camera via name from a dropdown menu

Where does this list come from? Are you talking about Camera Definitions? (If yes, we have added a call to list all of them but maybe we can go even further and add a function to set the camera configuration based on those definitions). If not, can you elaborate? @xocuv

I would like to know more about how it works when multiple add-ons will try to claim the custom camera: which one will get it ? By loading order ?

If the user has full authority about cameras, this means if we have 2+ add-on all requiring camera access, if the user doesn’t do anything to sort the situation, other add-ons that didn’t get the camera initially, will never get the chance to use it ?

The first addon that acquires the Camera will keep it until he releases it. So yes, if multiple addons need it and are installed at the same time, some of them won’t be able to work as expected (but they will know it and behave accordingly). I am thinking about improving the acquire system to give an Id while acquiring the Camera so the user knows about who is using the Camera (and block it if necessary).

Can the addon‑controlled camera use effects (e.g., drone focus, night vision, etc.)?

Will see what I can do. No promise for now

What is the supported FOV range? I would like to have 5° to 150°if possible.

The current limitation is 1° to 160°

Best Regards

Maxime / Asobo

[xocuv]

Thanks for your feedback Maxime, and happy new year as well!

Are you talking about having multiple renders at the same time? Or are you referring to save multiple configurations and switch from one to another at runtime?

Sorry for the confusion, could have formatted that more clearly. Everything in my post was referring to operating multiple render windows at the same time.
For this you would need multiple “dedicated” controlleable cameras instead of just one. Previously in FSX / P3D…

Where does this list come from? Are you talking about Camera Definitions?

that was done by camera definitions. In the past I could define my custom camera definition X in a cameras.cfg file. In-sim I would then open a new additional render video, drag it to my second monitor, select from the dropdown within that new window what should be displayed, selecting my custom X. Then via SimConnect_CameraSetRelative6DofByName, referencing X, I could control the camera movement in that second window completely separately from the main window (which was running / displaying the Chaseplane main camera at that time) and thus run two cameras at the same time. The name X that was specified in the camera definition became the reference for SimConnect_CameraSetRelative6DofByName to control the second camera.

But your approach with the dedicated camera(s) sounds much more streamlined.

If yes, we have added a call to list all of them but maybe we can go even further and add a function to set the camera configuration based on those definitions

Sounds great! Actually all of your proposed functions sound great. My request is just to add an optional “render view index” input parameter to all of them, specifying which of the render views you want to address. (For example defaulting to 0 for the main render view, 1 for the second render view if one is open, 2 for the third, and so on.)

This would finally provide control over the additional renders and uncouple those from the main view. The wishes that correspond to this are “Allow different camera views in multiple windows” from Jul 23 and “Better Multi / Triple Monitor Support (2024)” from Nov 24. (Sorry, not allowed to post links apparently.)

Hope that clears it up a bit more?

Best wishes!!
Seb

[Umberto67]

@Arzop

The first addon that acquires the Camera will keep it until he releases it. So yes, if multiple addons need it and are installed at the same time, some of them won’t be able to work as expected (but they will know it and behave accordingly). I am thinking about improving the acquire system to give an Id while acquiring the Camera so the user knows about who is using the Camera (and block it if necessary).

May I suggest a different approach, to not have to necessarily rely on user intervention (but still make it possible) ?

What if there was a way to track the various request to obtain the custom camera from various add-ons, and restore the camera to the addon that previously had it, or just return to the sim if nobody else asked for a camera ?

For example:

The sim starts, and loads addons A, B and C, all requiring access to the custom camera. Depending on the loading order, they might request/release the custom camera at different times, so let’s make an example:

• Addon A starts before the others, and asks for the custom camera. Since it’s the first add-on requesting it, the “previous add-on” tracked (the one we should give back the camera control to ) would be the simulator itself.

• Addon B starts after A, and it also asks to control the custom camera. Now B has control of the camera, and the system should know that, when B releases the camera, it should now give it back to A, unless A already released it, so the camera control should go back to the sim.

• Addon C starts after B, it asks for the camera, and it gets it, so now when C release the camera, the system will give back control to B, unless B already released it, so it will go to A, unless A already released it, so it will go back to the sim.

Basically, it’s a kind of “camera control queue”, so that add-ons could momentarily take control of the camera and give it back to either other add-ons or the sim itself, without having one blocking the custom camera for everybody else. The tracking should be automatic: add-ons should just release the camera, the camera system should decide to whom it should be given back.

Now, what if one of more add-ons asked to control the custom and none ever relinquish it ? We might have some control panel to indicate which add-ons currently has the camera, and let the user either override it, or possibly block the add-on from ever getting hold of the camera.

[runshotgun]

I like the queue idea!