We have the same problem here on a a single workstation in 2025.3.0 Broadcast DE. TRX50, Threadripper, 4090. No virtuals, keying in Aximmetry. All performance indicators are way in the green. Whenever we switch from a VCAM to a TCAM or the other way round in the 3+3 Mixed Cam compound a complete erroneous frame is inserted before the actual cut takes place. You can see it in the video at 00:14. The frame counter in the virtual background (just a 30fps loop from 0 to 510) advances smoothly until 12. At this moment the switch camera command is given. The frame counter seems to hang for a frame while the rotating flag in the real foreground keeps advancing. The next frame is rendered normally again. Then the actual switch occurs, but to a frame that is completely off both in virtual and in real. Finally (frame 15) the picture returns to normal again.

It happens again at 00:42 (frame 184 to frame 187 in the background) when we switch from TCAM to VCAM.

The biggest problem is that this used to work flawlessly in 2025.1.0, so what got broken...? We need to go back to producing normally very soon, currently we can´t use our VCAM because of this.

https://harmonicsound.wetransfer.com/downloads/e586b01d13124dd8873716d8321abb5f20251216165727/a334631924d3c965d636d8989028899020251216165737/a9741e

Hi Stefan,

did you get any response from Aximmetry?

I also wrote them but haven’t received anything back yet.

In my setup it jumps to an entirely wrong camera. I even opened an old project that ran perfectly in the version from October, and now it shows the same issues. I really hope we get some support soon and can solve the problem — otherwise we’ll have to downgrade to the previous version.

I haven´t gotten a personal response either, but I´d just give Eifert and the team some time to figure this one out. They like to discuss and communicate issues like this in the forum as it is much easier to collect user input this way.

Can you confirm that this wasn´t an issue in 2025.2.0? I need to look into how much effort it would take to convert our UE projects back down to 5.5.4 . I'd rather avoid that as I would then have to switch back to a higher version once that bug is fixed; There are some features only available from 2025.3.0 like billboards with a horizontal section that we really need to make our sets work.

Our plan B is to convert the one VCAM we have to a TCAM with VR paths. That´s going to be a bit of a challenge though as to my knowledge the VR paths currently do not have a sequencer control input and also the tracking camera recorder module does not record them. So that would mean getting my hands dirty inside the tracked camera module to graft a camera sequencer input onto it. OTOH that might be the more robust solution in the long run; Aximmetry´s dual camera model in UE has always felt a bit kludgey and rough around the edges to me, and I get the impression that UE isn´t really playing nicely with this either.

Hi Stefan,

absolutely positive. I opened the old project, updated the Unreal file, recooked it, and recalibrated the PTZ cameras since they sit lower than during the last recording.

It could also be that a preference changed somewhere and wasn’t carried over from the old version to the new one. If Aximmetry can’t help, I’ll need to take the same detour and roll everything back to the state before the January recording.

Hi,

We have identified the issue. The issue was introduced in the latest version, 2025.3.0. In version 2025.2.0, camera switching worked correctly between virtual and tracked cameras in mixed camera setups, without the 1-frame artifact.

The issue is caused by the new floor detection functionality in the virtual scene. You can fix this issue by editing the following compounds:

• [Common_Studio]:Camera\TrackedCam_Unreal\Elements\TrkCamU_Detect_Floor.xcomp
• [Common_Studio]:Camera\VirtualCam_Unreal\Elements\VCamU_Detect_Floor.xcomp

Follow these steps for both compounds:

1. Open the compound and locate the Holder module (the Output video connection passes through this module).
2. Remove the And and Delay modules that are connected before the Holder module, as shown in the screenshot below:
   
   
   
3. Connect the Not module’s Out pin directly to the Pass If input pin of the Holder module, as in this screenshot:
   
   

Note: The floor detection functionalities should continue to operate correctly after you make these changes.
Note: It is likely that this issue will not be fixed in the next release and will only be resolved in version 2026.2.0. If that is the case, you will need to apply these compound changes again after installing version 2026.1.0, as the installer will overwrite those Detect_Floor library compounds.

Warmest regards,

Thank you Eifert for that fix, it works well so far. However this seems to cause another (minor) issue with the VCAM as seen in this video:

https://we.tl/t-8dzPx72G3E

You can see it around the 0:06 mark, from frame 451 in the background onwards. There is a switch from a TCAM to the VCAM, and the billboard of the VCAM is not rendered correctly for exactly one frame. 

Hi Stefan,

Warmest regards,

reposted the link

Hi Stefan,

Nice trick with using that talent dummy accessory to simulate motion!

I noticed that the frame rate of the frames you are writing out on the virtual screen does not match the video’s frame rate and the rendering frame rate.

There are two other issues I observed after the frame you mentioned:

1. Billboard Occlusion Change:
   Between frames 452 and 453 (as shown on the virtual screen), the billboard's helper graphics change. The talent on the billboard would also have changed, but in this instance, there was nothing in front of it. Otherwise, it would have been like this between the frames:
   
   This occurs because the Allow Virtuals parameter is enabled for TCAMs but not for VCAMs. The difference in the Allow Virtuals parameter affects how objects rendered (or masked) in front of the billboard are handled.
   The two parameters of Allow Virtuals are located in different places:
   TCAM: You can find the parameter on the STUDIO panel of the TRK Inputs control board.: https://aximmetry.com/learn/virtual-production-workflow/green-screen-production/tracked-camera-workflow/scene-control-panel/#allow-virtuals 
   VCAM: The parameter is on the CAMERA & RENDER SETUP panel of the Cameras control board: https://aximmetry.com/learn/virtual-production-workflow/green-screen-production/virtual-camera-workflow/setting-up-billboards-in-virtual-camera-compounds/#billboards-in-virtual-camera-compounds-with-aximmetry-de-unreal-engine-rendered 
   Note that this actually happens for two frames, but due to the frame mismatch, frame 452 was written out twice.
   We are aware of this limitation and plan to address it in a future release. Until then, we recommend that you use the same Allow Virtuals parameter for both TCAM and VCAM to avoid this issue.
   
   
2. Reflection Change:
   From frame 452 onward, the reflections in the scene change, which affects the overall appearance of the scene. This is a known limitation in Unreal Engine’s ray tracing solutions, such as Lumen, where it often takes multiple frames to gather enough rays for accurate effects. There are various ways to reduce or hide this issue. But before addressing the issue, make sure that reflections are the cause and not something else, such as shadows or ambient occlusion (AO). If needed, I can help you diagnose this.
   There is also a recent discussion about this reflection issue here: https://my.aximmetry.com/post/4961-reflection-1-frames-delay-on-hard-camera. If you confirm that reflections are responsible, you may find useful tips in that thread.

Warmest regards,

@Eifert@Aximmetry Thanks for the workaround. It works and we will start the production like that ;)