[BUG] GetSimulationElapsedTime() vs. Material Time Node Mismatch

Summary

There is a massive discrepancy between the session time returned by Verse via GetSimulationElapsedTime() and the Time node within the Material Graph.

Because these two clocks do not sync, it is currently impossible to trigger precise, GPU-driven material animations from Verse without a massive time offset. This forces creators to use Verse loop updates to drive material parameters, which caps animation fluidity at the 30Hz Verse tick rate, resulting in jittery visuals compared to native 60fps/120fps shader math.

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Verse

Steps to Reproduce

Material Time Node: Appears to track time from the moment the server instance initializes.

GetSimulationElapsedTime(): Appears to track time from the start of the specific game/round simulation.

The Delta: In my testing (and as seen in previous reports), the difference can be hundreds or even thousands of seconds depending on how long the instance has been active.

Create a Material that outputs the Time node to a DebugScalarValues node in the Base Color.

Create a Verse device that prints GetSimulationElapsedTime() to the log or an On-Screen UI every second.

Compare the two values side-by-side in a live session.

Expected Result

Both clocks should reference the same simulation start point so that a timestamp captured in Verse can be used as a StartTime parameter in a shader.

Observed Result

The values are completely out of sync, making synchronized GPU-side effects impossible.

Platform(s)

PC

FORT-1058416 has been created and its status is ‘Unconfirmed’. This is now in a queue to be reproduced and confirmed.

Sorry but this is not a bug, Time in Unreal Engine has different usages on different contexts, specially when also considering client/server, simulation start/application start, networkign and so on… :frowning:

I explained a with a little more details on this other topic:

I agree that we should have more control over time within our code and applications, but, these aspects would be a feature request for new functionality and not a bug report, since what you said about the already existing functionality is not a bug at all and already working correctly…