SOLVED Triggering MatPreview update without raising dirty flags

Hi, I am trying to find a way to trigger update of MATPREVIEW parameter (included directly with Mpreview), but without raising dirty flags on the BaseShader being previewed. I tried messaging the shader with MSG_UPDATE, but this raises its dirty flags and I want to avoid that.
Is there a known way of achieving this?

A little more context - I have a shader that needs a bit more time to render and updating the preview on each change of parameter blocks the main thread, which is undesirable user experience. So I'm trying to make the calculation of the image for preview to be made asynchronously on a separate thread and only update the preview once it has been rendered. Calling:


works for triggering update of the preview, but it also raises dirty flags of the shader (and material that contains it), which on itself is undesirable, because we use the dirtyflags for registering document changes, and this is not an actual change.

I investigated in detail the header customgui_matpreview.h for any hints for updating the preview, but couldn't find anything related to what I want to achieve. Is there something I'm missing?


Hi, @Deyan sorry for the huge delay, from SDK-Team we have no solution, and for the moment we think this is not possible.,
I contacted the rendering team which also doesn't have a good hope (but since some people are still on holiday they will confirm me or not if this is not possible soon, they may have a workaround, but for the moment I can't guarantee anything.

Thanks a lot for your patience.
I whish you a very nice an happy new year,

Hi I get the next answers from our Rendering department.

@Rendering Departement:

After investigating, looking at code, debugging, we concluded that it’s currently not feasible.
With the current way the material preview updates work in the older BaseMaterial / BaseShader system, there’s no hack and \ or workaround we could find which allows us to trigger a material preview update without making the shader dirty.
A custom dirty system could possibly be implemented inside of the BaseShader / user-defined shader, but even this can be dangerous since the preview often renders a copy of the material/shader (to name one of the reasons).
Unfortunately we have to recommend not to spend significant effort on this anymore, since we’re moving away from the old system and moving into the world of nodes (where we have Copy On Write, thread safety, etc).

So unfortunately it's a limitation we are not going to fix.

Thanks for the effort Maxime (and rendering department). I suspected that it won't be possible, but still asked because I thought I might have missed something.