As most other software packages, Mari can sometimes experience slow performance. Whilst often this is related to graphics cards being overloaded with projects of immense sizes, there are some other cases and reasons for slow performance that the user can address before changing hardware. This article covers some of these cases and offers troubleshooting suggestions.
SYMPTOMS and RESOLUTIONS
- Your project contains multiple objects
Mari is optimised to work on one object only. Having multiple objects in your project (regardless of visibility) will cause performance penalties. These penalties will increase with the amounts of objects in your scene.
TIP: If you assign different materials to your object before exporting it as an alembic or fbx file from your original modelling package, Mari will respect that information and use it to create Selection Sets.
- Your project is not using resources efficiently
If you are working using many Layers, it is recommended to cache "finished layers".
Make sure that you are using resolutions and bit depths in an efficient way. If you are painting 8 bit textures, you can use an 8 bit paint buffer. Make sure however, that your Paint buffer and Virtual Texture Atlas are never set to lower bit depth than the layer you are painting on.
Additional performance optimisation suggestion can be found under the following article: Q100188: Optimising your Mari projects for best performance
- Slow viewport navigation
This often depends on the GPU and complexity of shaders and the models. More complex shaders will inevitably introduce a performance decrease. This is also heavily influenced by displaying true displacements and shadows.
Disabling displacements and shadows will greatly improve performance.
If you are working on a 4k Monitor, this means Mari will have to render more pixels in the viewport than on a conventional HD monitor. Due to this, rendering times in the viewport might not be as fast as when using a monitor with fewer pixels. If your Viewport is overlapping on multiple monitors, performance will also slightly suffer as the GPU will have to serve two displays simultaneously.
- Mari often freezes on Windows
This might have something to do with the TDR time (Time Detection and Recovery) set on Windows and your GPU drivers. As Mari uses the GPU intensely, some calculations can last longer than 2 seconds (the default TDR limit). This means that Windows will cancel the operation and reset your GPU, causing a freeze. To work around this you can increase the TDR time out values in the registries.
NOTE: Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and may require you to reinstall your operating system. The Foundry take no responsibility to any damage caused to your system by modifying the system registry.
For more information about the TDR registry keys, please refer to the following Microsoft article.
- Exporting Textures is slow
This depends on various factors of the texture (bitdepth and resolution), the amount of Layers and if you export the texture flattened and the amount of patches.
If you are working on a project with a high amount of UDIMs it might be advisable to only export patches that have been changed since the last iteration. To check if a layer/channel/patch has been changed you can compare hashes at the beginning and the end of your Mari session. If there is a difference in hash, your layer, channel or patch is "dirty" and can be re-exported.
- Slow opening and saving times
It is a common mistake that the Image Manager is filled up with several hundred reference images. Each of those images are stored within your project and consequently need to be saved with it. If you have unexpectedly slow saving and opening times of projects, it might be that your Image Manager is unnecessarily increasing your project size. This can also sometime explain large project sizes when your actual model and textures used are lower in size.
TIP: If you delete every image in the Image Manager, it will automatically restore images used by procedural nodes the next time it is opened.
- Recommended file systems
Users on Linux may find that they can significantly increase performance if they use the EXT3 or EXT4 file system as it is naturally more suited to the way Mari reads and writes projects.
Mari writes a very large number of small files to its cache directory when saving the archive, and for example, one project like the old blacksmith body example had 75000 files of 10-90 kB each. From our internal tests we've noticed that file systems like EXT3 or NTFS are offering the best performance when it comes to dealing with large numbers of small files.
In comparison, we've not noticed the same performance using the XFS file system and we've had users report that this is acting rather slowly compared to EXT (EXT3, EXT4, etc). This is why Mari currently shows a warning when using the XFS file system.
STILL HAVING PROBLEMS?
If you are still seeing any issues after performing the steps outlined in this article, then please open a Support ticket and let us know the issue you are encountering and the troubleshooting steps you have taken so far. The information we require to investigate is outlined under Q100090: Reporting a Mari issue .For more information on how to open a Support ticket, please refer to the 'Using the Support Portal' article.