Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

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

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.


Product Version: UE 4.16
uitime.zip (2.1 MB)
more ▼

asked Jun 19 '17 at 08:36 PM in Bug Reports

avatar image

31 3 11

avatar image blobdole Jun 29 '17 at 06:57 PM

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?

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

3 answers: sort voted first

This can be resolved by using:

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


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

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

more ▼

answered Apr 17 '18 at 12:00 AM

avatar image

Sammy James
31 2 1

avatar image blobdole Apr 17 '18 at 12:38 AM

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.

avatar image Sammy James Apr 17 '18 at 05:13 AM

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.

avatar image blobdole Apr 17 '18 at 08:08 PM

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?

avatar image Cédric Schaff Jul 25 '18 at 08:47 AM

Thanks for the solution !

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


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


 float UShipsBPLibrary::GetFuckingEditorTime()
     float TimeSeconds = FApp::GetCurrentTime() - GStartTime;
     return TimeSeconds;
(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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: https://issues.unrealengine.com/issue/UE-48496

Make it a great day

more ▼

answered Aug 16 '17 at 02:45 PM

avatar image

Rudy Q ♦♦ STAFF
47.3k 545 132 525

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

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

more ▼

answered Jun 19 '17 at 08:45 PM

avatar image

4.2k 88 38 152

avatar image blobdole Jun 19 '17 at 09:10 PM

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.

avatar image Ninjin Jun 19 '17 at 09:31 PM

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

avatar image blobdole Jun 19 '17 at 09:47 PM

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.

avatar image Ninjin Jun 19 '17 at 10:05 PM

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

avatar image blobdole Jun 19 '17 at 10:38 PM

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

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question