Summary
Since 42.30 (++Fortnite+Release-42.30-CL-58557680), a perspective_camera_component that moves with a fast keyframed_movement_component entity renders from where that entity was roughly one frame earlier, while meshes on the same entity render at its current position. The camera visibly trails the geometry it is attached to, by a distance proportional to speed (about 1 m at ~20 m/s), so geometry that should sit behind the camera slides into view. The same setup rendered correctly on 42.20, with no visible offset at any speed.
Please select what you are reporting on:
Verse
What Type of Bug are you experiencing?
Scene Graph
Steps to Reproduce
- Create an entity with a keyframed_movement_component and a mesh_component.
- Give it a keyframed_movement_delta array that moves it quickly (20+ m/s) and play it.
- Add a camera, either:
(a) on a child entity of the moving entity (perspective_camera_component, a small local offset, parented before the entity is added to the scene, published with SetPresentableToPlayers), or
(b) directly on the moving entity itself. - Bind it to a player with camera_director_component.AddCamera on the player’s agent entity.
- Watch through that camera while the entity moves fast, with the entity’s mesh in view.
Expected Result
The camera stays rigidly attached to the entity: the view and the entity’s own mesh move together at any speed, as they did in 42.20.
Observed Result
The view lags the entity’s mesh by about one rendered frame (~35 ms measured with a 30 fps client). The offset grows with speed and is not visible below roughly 15 m/s. It happens with the camera on a child entity and with the camera component on the same entity as the mesh, so it does not look like a parenting or origin issue - the rendered view itself seems to use a stale transform. The log shows the camera bound once and never switched.
Platform(s)
Windows PC (UEFN edit session, client at 30 fps). Not yet tested on console or mobile.
Additional Notes
Workaround in use: giving the camera entity its own keyframes (one per keyframe of the moving entity, same durations and easing) that push it forward along the direction of travel by speed x 0.035 s hides the offset. It depends on frame rate, so it is only a stopgap.
A side-by-side video of the same setup on 42.20 and 42.30 has been shared with Epic directly.