It has been noted that Mari can sometimes experience slower than expected performance. Whilst often this is related to the graphics card being overloaded with projects of large sizes, there are some other cases and reasons for slow performance that the user can address before changing hardware. This article will aim to cover some of these cases and offers troubleshooting suggestions.
SYMPTOMS & RESOLUTIONS
- Your project contains multiple objects
Mari is optimised to work on a single object. Having multiple objects in your project (regardless of visibility) can cause performance penalties. These penalties will increase with the amounts of objects in your scene.
NOTE: 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 using many Layers, it is recommended to cache these "finished layers".
Make sure that you are using resolutions and bit depths in an efficient way. If you are painting - 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 the shaders and models. More complex shaders will 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, Mari will have to render more pixels in the viewport than on a conventional HD monitor. As this is the case, rendering times in the viewport may 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 pass through to two displays simultaneously.
- Mari often freezes on Windows
In the past this has been associated 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. Saying this we do not recommend editing the any registry without fully knowing what you are doing.
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 (bit-depth 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 occurrence that the Image Manager can fill 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.
NOTE: 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.
ADDITIONAL INFORMATIONIf you are still encountering 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.
We're sorry to hear thatPlease tell us why