I’d like to know if there is any way to synchronize the Light Function Atlas time and the BP “GetRealTimeSeconds” or any other way of getting time in a BP.
We need to be able to synchronize the light function with other elements, such as sound and VFX, and we have found there is a mismatch between the two.
Is the only option to forgo the new system entirely?
Hey there! UMaterialExpressionTime is giving you the View.RealTime value, which is “Time since the level started, but is not affected by time dilation or paused”, which might be where some of the discrepancy is coming from.
UKismetSystemLibrary::GetGameTimeInSeconds is returning UWorld::GetTimeSeconds, which is dilated and paused.
The good news is that there is a view parameter that maps to the Blueprint-accessible version, View.GameTime (as opposed to View.RealTime). You should be able to access this in a Custom expression.
That said, this might be a bit more challenging to test out in the editor since “Since the level started” can mean a lot of different things based on the UWorld.
Worst-case scenario, you can always create a Material Parameter Collection that you’re writing to with your blueprint-accessible time and sampling that in your material instead of relying on the view parameters.
Thoughts?
I’ll give you more context.
We have lights inside Blueprints, and what we want to do is synchronize the light flickering, which is done via Light Function with a sound/VFX cue.
The way we calculate flickering is deterministic, so using the same function in both the BP and the Material we should be able to synchronize them.
We do it this way because we want to use the new Light Function Atlas system.
Having every BP set the intensity inside the Light Function Material would create too many instances that would fill up the atlas. For this reason we stopped doing it that way, and thus lost the synchro. We want the light function to be able to preview the flickering as well, without having to play the scene each time.
While light function atlases do enable you to use light functions more efficiently, I still don’t think it’s wise to use them for uniform effects like flickering. I’d rather you just set the intensity of the light directly in blueprint if there aren’t a lot of them. I’m not sure there’s going to be a great way to synchronize the flickering to the cues in a way that lands in the sweet spot between “unique and fully synchronized flickering behavior per-light” and “performant”. There’s going to be tradeoffs somewhere, either in having separate MIDs per-light (still keying off the same MPC-provided time value from blueprint, so at least you don’t have to set a parameter on each MID every frame) or driving intensity via the light component itself so you’re more likely to be properly synced.
Thoughts?
Three thoughts :
First, we have enough lights that we saw a 1-2ms increase in performance by switching to the light function atlas. And they do not need to be unique, we have a set of different light functions instances, less than 10, for the whole map, so the atlas is not full and we don’t need more slots or resolution.
Second, lights with 0 intensity do not cast shadows, thus the question: won’t have them flicker by setting the intensity to 0 invalidate VSMs and force them to be recalculated? Simple solution is just go to extremely small intensities, but still.
Third, we use masks to fake very large penumbras generated by the light prop itself, which we set to not cast shadows. We’d lose the volumetrics the “fake” shadow casts, since non-light function atlas light fucntion do not interact with volumetric fog.
To get back to your original question, , have you tried accessing View.GameTime in a Custom expression to get the same value between game and rendering? In some local testing with a blueprint and a material the two values do seem to line up.