Ranking of most system intensive features

[Nicohk92]

As I'm diving back into Moho, and while it's a great program for some things, I am finding a few bugs and already seeing my system lagging with some operations.

Therefore in order not to get stuck later on in my project that involves many moving parts, I'm wondering what are the most demanding effect, tools etc.. on cpu and ram.

# of points, shape effects, layer effects, masking etc... Has anyone tried ranking those features as far as system burdening?

[Greenlaw]

Deforming very high-resolution images can bog down a system. In this situation, make sure GPU caching is enabled. If possible, create versions of your assets with the appropriate resolution (i.e., for wide shots, reduce the image size.) Note: Some scaling issues can occur when setting these up. There are ways to correct this; sorry, I don't have that info handy at the moment, but I believe there are discussions/scripts to address this.

In general, I display only what I need to see when animating, and enable everything for final render if I'm going to composite the project in another program. Do this by setting up a 'master' Layer Comp, and working Layer Comps with layers hidden.

BTW, for compositing, you can break out render passes using Layer Comps. You should use Moho Exporter to render the Layer Comps...Moho Exporter can break out the projects for you and render them to separate directories automatically. (Tip: use Save Profiles so you don't need to repeat this.)

[Nicohk92]

Yes layer comps are very useful. I ll keep that in mind.

[Daxel]

As I'm diving back into Moho, and while it's a great program for some things, I am finding a few bugs and already seeing my system lagging with some operations.

Therefore in order not to get stuck later on in my project that involves many moving parts, I'm wondering what are the most demanding effect, tools etc.. on cpu and ram.

# of points, shape effects, layer effects, masking etc... Has anyone tried ranking those features as far as system burdening?

You mention operations. What do you mean? There are at least two kinds of "performance" when talking about Moho.

One is related to rendering the workspace, and can be measured by the playing FPS. This is obviously sensible to the work you put on the renderer so the number of shapes, effects, masks, etc is the key here. Masking of shapes with complex effects is problably the most tasking thing for the renderer. And I have noted there is a bug with masking shapes that have gradients, as this has been the cause of an unreasonably big slowdown I had in a project. Enabling and disabling the visibility of layers and the different view options like masks, layer effects, shape effects etc while checking the playing FPS will give you the information you need about rendering performance on your project.

And the other kind of performance is more related to the operations, like moving points, opening windows... and in my experience the best way to measure this kind of performance is copy-pasting keyframes, which can be super slow if your project is not healthy. The worst I have measured was 1' 33'' to do a copy-paste. And after fixing things this was reduced to 2''. The possible causes of operative lag (yeah that's the name now) are these:

• 95% of the time, corrupted references. I still don't know how to corrupt them but usually creating them and then making a lot of changes to the original ends corrupting the reference, but I think this can happen other ways and it's very common. This is a bug, this is not a broken reference which is a different and expected thing. Corrupted references have keyframes in every single existing channel and are super heavy for Moho. For reference, the project I had with 1'33'' copy-paste lag had 5 broken references and the file size was 11.1MB. After fixing these references, the file was only 2.6MB and the copy-paste took 2''. In my opinion fixing this should be the nº1 priority for the devs. I hope one day I can help them discovering how to reproduce these corrupted references.
  
  The way to fix them is to delete them and create them again. Which is quite easy when you have unmodified references but more painful when your references have modifications, because this forces you to keep a documentation about what changes each reference has so you can remake them in case of corruption.
  
  One tip: I usually document that creating a group layer parent of the reference and I write a comment or note in that group layer explaining what is modified in the reference.
  
  Edit: A second tip to quickly see if you have this problem, useful for complex rigs where you may have a hard time finding each reference, is to use the filter by type in the layer panel in write "ref". Then save and delete all the references so you can see if this improves the performance and the file size.

• The other 5% of the time the problem is negative keyframes, which nobody knows how it happens and it seems to happen less these days but it's usually noticed as Moho doing weird things. You can solve it using Wes' script tool "Find and Delete Negative Keyframes": viewtopic.php?t=32714

[Nicohk92]

Very interesting.
I found out about masking and gradients on my own as you know, but It's very useful to learn about this reference problem.
While I have yet to experience it because I'm pretty new to references, it's a bit of a phobia.

I am embarking on a medical project where some shots have as many as 40 different cells of different types in the frame, all referenced from another file, all animated to do different things.
A broken reference would be a nightmare in this scenario, especially as you say that the only option is to recreate them.

I would much prefer not having a feature than having one that'll end up make you stress and waste huge amounts of time at the worst time. Better for planning and overall sanity.

[Daxel]

I usually use references for composition, so the originals are on the same file. I still have never used the import as reference feature because like you said I try to avoid problems so, to be precise, I don't know if imported references have this corruption problem, maybe not. I should try someday.