Animated viewport preview in Node Materials

[peter_horvath]

I'd like to add support for animated previews in my custom node space. I assumed, that enabling Animate Preview on the Viewport tab of the material means that the GetMaterialParameters() function of my viewport material is called every time the frame changes in the scene.

However that does not seem to be the case, nothing happens when moving the timeline. Am I missing something? Do you have an example of how to support animated previews?

[ferdinand]

Hey @peter_horvath,

Thank you for reaching out to us. To make it quick, I have been working on this but I have not yet an answer, as this is non-trivial. To clarify this for me:

I'd like to add support for animated previews in my custom node space. I assumed, that enabling Animate Preview on the Viewport tab of the material means that the GetMaterialParameters() function of my viewport material is called every time the frame changes in the scene.

I assume you mean the case that a material/shader is implicitly animated, as for example the Redshift Maxon Noise shader is when the user sets the "Animation > Speed" to a value larger than one. Because explicit keyframe animations do work for me properly and also cause MaterialExchangeInterface::GetMaterialParameters to be called for each frame. For the implicit case I tried the obvious thing like manually animating the time stamps and setting values to non-const when inserting them via MaterialExchangeInterface::Insert but this did not change anything about the frequency of ::GetMaterialParameters, ::ConfigureTextureProviderRequest, or texture provider calls.

What is also noteworthy is that the noise in the standard renderer node space does not support this. I also found comments in our code base which indicate that the whole viewport material parameter caching is not meant to be animated from this side, as the whole structure is reinitialized on graph change events. I already asked Redshift how they did this, but they do not know/claim this works out of the box (the interesting thing is however that GetMaterialParameters is being called on each frame for them). For me this looks more and more like an intentional/unintentional hack from their side which flags their graph dirty on each frame (which would then cause the whole MaterialExchangeInterface thing to be unrolled again). I probably could try to cook up here a hack for you with an observer which hooks into EVMSG_CHANGE or something like that, but before I do this I would like to make sure that there is not some weird attribute on a graph or a node template which you can set (already checked but could not find anything).

Cheers,
Ferdinand

[peter_horvath]

Hey Ferdinand,

Thank you for looking into this. Yes, this is about implicitly animated shaders, like the noise you mentioned, or an image sequence in the Image/Texture shader. You are right, it does not work in the Standard node space, only in Redshift, so might be indeed some custom solution there. What is the Animate Preview checkbox for then, if you don't mind me asking.

I was also thinking about a workaround that triggers an update in the graph explicitly upon frame changes, if no standard solution exists. Don't worry about putting that together, I think I'll manage.

Cheers,
Peter

[ferdinand]

@peter_horvath said in Animated viewport preview in Node Materials:

What is the Animate Preview checkbox for then, if you don't mind me asking.

Well, a node material is just a heavily modified Mmaterial that really goes to town with its description at runtime. What happens under the hood, is that in Material::GetDescription we check if the material has a NimbusRef, i.e., is node based and then just jam the description of the NimbusRef into the material. At the end, we then do this, we just hide almost everything from the standard material (the comment is not correct, the Viewport section is not being hidden):

So, the underlying question is how intentional it is, that the classic API feature "Animate Preview" made it into node materials. My guess would be that they planned to support it, but it never came to fruition. The problem with material previews is that they are not really owned by any developer anymore, which is why I have to play detective rather than being able to just ask the developer.

There is one more route I can try to figure this out, I will give you here a heads-up about the outcome once I am done (might take a few days).

Cheers,
Ferdinand

[ferdinand]

Hey Peter,

so, I found out why this works for Redshift: Because we deep down in our API wrote a custom handling for it (without Redshift being aware of that extra treatment they got ). The caveat here is that :: GetMaterialParameters has been called for each frame in the past, but the Viewport Team deliberately turned that off as it made things very slow. I doubt that it will be easily or at all transferable for public API users what we do for Redshift. I haven't had time yet to look at all the code but Viewport labeled it as "very internal".

Viewport also said we could turn on again ::GetMaterialParameters being called every frame, but that would then impact all third party render engines at once, or more precisely all render engines where we do not have custom handling internally. I will try to sort this out in the next weeks, to see where we will go with this, as this is still all a bit opaque for me. I only have talked with engineers right now, did not talk to any PMs/SDMs about where we stand regarding support for animated material previews for third parties.

Given the problems we had with this (Viewport talked about single digit FPS when polling every frame without a cache), I would for now advise against hacking things by flagging the graph dirty all the time. What I also do not understand, is why normal parameter animations do not cause this sluggishness too.

Cheers,
Ferdinand

PS: Feel free to reach out to us via mail, in case you want to talk about this beyond the purely technical side of things.

[peter_horvath]

Hey Ferdinand,

Thank you for investigating and digging deep on the topic, much appreciated. I'll handle this as a limitation for now, until an official solution exists. But don't worry, it's not a high priority for us at the moment.

Thank you,
Peter