The Time material node returns editor up-time instead of game time if the material is set to the material domain User Interface.

Development Rendering
, , ,
1

I am having an issue where the Time material node returns the incorrect time if the material is set up for use in the UI. All other uses of the Time material node return the game time in seconds but if you set the material to the user interface domain it returns the editor time in seconds. This means I am unable to do basic triggered time based changes within a UI material. (like fading out now)

I have attached a test project where two identical materials set to two different material domains are in scene and show different times.

UITime.zip

2

The solution was already posted by RyanB and can be found here

3

Unfortunately that does not work. The GetRealTimeSeconds blueprint node returns the same value that a Time material node does UNLESS the material is set to the user interface material domain. There is no way I can see to get the same time that the Time material node does in this setup from blueprints thus making it impossible to sync them up.

4

I think we talk past each other. You don’t want to use the material time node, you want to make it a parameter and change it and you update this parameter in your Blueprint or UI by getting the time there and passing this value to the material. Because that’s what RyanB said here:

If you want to fade with timing on spawn, you need to create a material instance dynamic. Once you have an MID created by the blueprint you can use one of two ways to control the fade. One is via timelines where you manually control a scalarparameter and set the “time” as the value output from the timeline. In this case, the output pin of the timeline DOES tick and update the MID. There is some cost however small to this method.
The second method is to simply create a scalarparameter called “spawntime” and on spawn, create an MID and set the scalarparameter to the value of real time.

If I misunderstood you, I’m sorry <3

5

I think the main issue here is that if you wish to do real time based work within a material (not forcing it to update every tick externally) then you need a shared time reference between the material and the blueprint triggering it so they can be synced up. Setting a scalar parameter on spawn can’t work unless I can tell the material to save internally whatever its Time node currently contains with an external trigger. I don’t believe a way of storing internally derived values like that that exists but I could be mistaken.

For all material setups except one, the material node you can use is the Time node. We use it in several places in our project with dynamic materials and it works perfectly for hit flashes and invulnerability effects and things like that. The only thing we can’t use it for is dynamic user interface materials because in that one situation it operates differently. I would even argue it operates incorrectly because editor time is a basically useless value.

Even if there is a way to do an internal storage of editor time triggered externally on spawn, that is just saying that for all uses of materials and time except one do this simple thing and in this one do something much more complex for no apparent gain.

6

Now I understand you. The only thing left I can think off is using a MaterialParameterCollection on every single material. But depending on the size of your project, that’s gonna be fun.

I’m not even sure if you can call it a bug, there is high chances that materials with the UI domain work differently, because they are used in UI which is closer connected to the blueprint system. I’m sorry I can’t help <3

7

I definitely think it is a bug because one node gives different information if you change something unrelated.

Sadly the fix may be to block the Time node from being used in UI materials, but I hope not. =P

8

This issue is still outstanding and hasn’t seen a working solution yet. Is there any additional information I can provide that will assist on getting either an answer or a bug report?

9

Hello blobdole,

I was able to reproduce this issue on our end. I have written up a report and I have submitted it to the developers for further consideration. I have provided a link to the public tracker. Please feel free to use the link provided for future updates.

Link: Unreal Engine Issues and Bug Tracker (UE-48496)

Make it a great day

10

This can be resolved by using:

float RealTimeSeconds = FPlatformTime::Seconds() - GStartTime;

or

float TimeSeconds = FApp::GetCurrentTime() - GStartTime;

as slate’s FSlateRHIRenderingPolicy does not respect the UWorld’s concept of time.

2 Likes
11

Any idea if there is a way to do this with existing material blueprint functions? If not, maybe I can figure out how to make a custom material blueprint function in C++, assuming that is possible.

12

You’d just want to use one of those values as your scalar parameter to denote start time in the case of a UI material.

13

Ah, if I run it in backwards (send in the “bad” time) I only need to make a regular custom blueprint function (for convenience) instead of having to figure out if I even can make custom material blueprint functions. I wonder how that will work playing in editor vs playing in a cooked build? Hopefully the same?

14

Thanks for the solution !

Made it work with a custom BP lib → now BP and mat are in sync.

.h

UFUNCTION(BlueprintPure, Category = "Time")
static float GetFuckingEditorTime();

.cpp

float UShipsBPLibrary::GetFuckingEditorTime()
{
	float TimeSeconds = FApp::GetCurrentTime() - GStartTime;
	return TimeSeconds;
}
2 Likes
15

Just wanted to say, after spending hours on this stupid problem, your function name is spot on.
Worked like a charm.

16

Initial testing using “Get Accurate TIme” is working. Havent confirmed in a packaged build yet though ( returns and int and float so you ll need to add em together )

1 Like