PostCook causing delays in new mesh displaying

[KevinCalderone]

Problem

When a cook completes, the GameThread read back the new mesh data from the Houdini process, processes the data, and then uploads the processed data to the RenderThread to be rendered.

When testing this with an HDA that generates a reasonably sized mesh (~70k triangles), this step in the process takes ~170ms which is slower than I would expect.

Unreal Insights

Here is a capture of this using Unreal Insights with additional profiling scopes:

Suggestions

Here are some suggestions that would remove ~100ms from this critical path of the new mesh getting displayed.

FHoudiniEngine::UpdateCookingNotifications

• This appears to be creating the cook completed UI notification.
• Could this be deferred to the next frame?

FHoudiniEngineUtils::UpdateEditorProperties_Internal

• This appears to be getting executed twice redundantly?
• Can one of these calls be eliminated?

FHoudiniParameterTranslator::UpdateParmeters

• This appears to be updating all the values displayed in the parameters panel to ensure they are displaying correctly?
• Could this be deferred to the next frame?

[dpernuit]

Hi Kevin,

I'll post my answer here as well:

UpdateCookingNotif is an absurdly expensive function for what it does.
I've already done a pass previously to reduce its usage in the plugin (as it used to add minutes of delay to long cooks).
But I think the best option for us is to look at an alternative for the notifications system in the plugin, as Unreal's is too expensive.
If you don't care about them and want the fastest cook times, I recommend disabling them in the plugin settings.

UpdateEditorProperties: I agree with your findings.
We've done a pass on this function in the last couple of months that helped optimize it, as it used to be more costly.
I've taken a look at it last week and agree with your findings: that function was called redundantly (multiple times per HDAs)
but also, needlessly (for non-selected HDAs that don't need details panel refresh).
I've already committed a fix for this last week, that ensures that we call that function once per HDA (if selected).

UpdateParameters is needed as it doesn't just update the visible values of params, but also their internal state.
Those params can be dynamic - and a cook could cause extra parms to be created/deleted, etc ...
Fortunately, most of the cost of that function was in its UpdateEditorProperties call which has been solved/moved
as mentioned above.