SUMMARY
Creative briefs are becoming more and more demanding, and with increasing complexity in geometry, texture maps need to be increasingly higher in resolution. We should also note that Mari is highly dependent on the graphics card, so heavier projects may overload it.
With this in mind, it is important to optimise and squeeze out as much performance as possible from your machine to allow as fluid as possible a painting process when using Mari.
There are many things you can do to achieve this, and this article will go through each Mari and OS feature you can use. First, we'll cover best practices to optimise your Project, then we'll move on to more technical and general aspects of Mari that will support optimal performance.
SETTING UP YOUR PROJECT FOR OPTIMAL PERFORMANCE
Nodes
Bake Point nodes: Heavy or complex node networks can take longer to compile and can reduce performance. To help maintain a good level of responsiveness in your project, Bake Point and Multi-Channel Bake Point nodes can be used to bake sections of the network and increase performance.
Procedural nodes: Use raw procedural nodes sparsely, as they require a lot of system memory to calculate and render given their high level of complexity. Wherever possible bake them in a Bake Point to increase performance.
Size and Depth: With Paint nodes, Size and Depth shouldn't be set to high values unnecessarily. Size provides resolution, while Depth prevents stepping and improves Merge calculations. But in most cases, much like with the Paint Buffer, these settings shouldn't be set higher than the Channel they are connected to.
Layers
Caching layers: A large number of layers or computationally expensive layers can decrease performance. Caching Layers that aren't being worked on can mitigate this. To cache layers, from the Layers menu select Caching > Cache Layers or right-click on the layer and select Caching > Cache Layers from the dropdown menu.
Shaders
Multiple shader setups: Create multiple shader setups and switch between them as needed. For example, the user can have a lighter setup for painting and editing, and a full, heavier setup for final preview.
Bump Mode: In a shader's settings, setting the Bump Mode to 'Fast' is also more suitable for previewing instead of using 'Final' look.
Displacement and Bump Maps: Even if you're creating a Displacement map, it is recommended to plug it into your shader as Bump for faster preview. In general, avoid having Bump or Displacement maps on while painting, and add a Bake Point right before the Channel node if you do need to view it in the shader.
Objects
Although Mari allows multiple Objects in one project, the software is designed to perform best when there is only one Object in the scene. As such, having a high number of Objects in one Project (regardless of visibility) can have an exponential, detrimental effect on performance.
Image Manager
Throughout working on a Project, the Image Manager often fills up with several hundred reference images. Each of those images is embedded in your Project and consequently needs to be saved with it. If your Project takes a long time to open and save, or if your Project is taking up a lot of space on disk, it might be that your Image Manager is increasing your project size.
NOTE: If you delete every image in the Image Manager, it will automatically restore images that are being used by procedural nodes the next time the Project is opened, as long as the images are still on disk.
SETTING UP MARI FOR OPTIMAL PERFORMANCE
Project Location
It is strongly recommended that the Projects cache is kept locally on an SSD (solid-state drive). Project Location can be changed in Edit > Preferences > Data > Project > Project Location.
Viewport
Avoiding having too large a viewport: The more pixels to render, the slower the viewport will be. In extreme cases, hiding some geometry might improve the framerate.
Monitor
4K Monitors: If you are working on a 4k monitor, Mari will have to render more pixels in the viewport than on a conventional HD monitor. Rendering times in the viewport may be slower than when using a monitor with fewer pixels.
Multiple Monitors: If your Viewport spans across multiple monitors, performance will suffer slightly as the GPU will have to pass through to two displays simultaneously.
Edit > Preferences > GPU tab
Mari makes use of the GPU for most of its processes, including critical tasks such as baking and viewport rendering. A complex shader combined with a weaker GPU will often lead to a lower frame rate in the viewport. Managing the graphics card's resources can improve performance, and this is done by editing the GPU Preferences. The user can hover over any preference to read the tooltip and understand its influence, but the following settings have the biggest impact on performance:
Baking and Projection > Mip-Map Generation - "Fast"
No linearization is performed and downsampling is done in the native colourspace of the image.
This speeds up the process of things like baking paint down from the buffer to the canvas. It can introduce errors due to the maths being non-linear, but this only affects the View, not the final textures exported out of Mari.
Shadow Maps > Allowed - Disabled
Shadow Maps can be enabled to produce more accurate shadows in the viewport, but disabling it frees up system resources.
Virtual Texture > Type - "Byte"
Controls the data type of cached channel data for display. Increasing it will improve accuracy of displayed values at a greater cost to GPU memory.
Virtual Texture > Layer Count - Low value
Controls the number of virtual texture images being used. Increasing this may resolve issues with flickering textures, and increase the speed at which tumbling a model happens.
Shaders > Compilation Mode - "Automatic"
Although the default Automatic mode is ideal for most Mari sessions, other modes might be faster for specific tasks. For more information, please refer to the following article: Q100308: Mari's Shader Compilation Modes
Windows - TdrDelay and TdrDdiDelay
Mari freezes have been associated with the TDR time (Time Detection and Recovery) set on Windows. As Mari uses the GPU intensely, some calculations can last longer than 2 seconds, which is the default TdrDelay limit. This means that Windows may cancel the operation and reset your GPU, causing a freeze or crash. To work around this you can increase the TdrDelay and the TdrDdiDelay timeout values in the registry.
For more information about the TDR registry keys and how to edit them, please refer to the following article:
Q100688: Preventing Mari freezes and crashes on Windows by increasing the TDR registry keys
Linux - 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 suited to the way Mari reads and writes Projects.
When opening or saving a Project, Mari uses a very large number of small files in its cache directory, called the Project Location. For example, the old Blacksmith Body Example had 75000 files of 10-90 kB each.
Our internal tests indicate that file systems like EXT3 or NTFS offer the best performance when it comes to managing large numbers of small files. XFS file systems are not as adequate and we've had users report that they can be slower compared to EXT. This is why Mari currently shows a warning when using the XFS file system.
Hardware
Above all, a powerful graphics card with a good amount of VRAM is strongly recommended. To learn how Mari uses each hardware component, please refer to the following article: Q100078: Mari's usage of hardware components
FURTHER HELP
If you are experiencing difficulties please create a support ticket and provide us with the information requested in this article:
Q100090: Information to send Support when reporting a Mari issue
For more information on how to open a Support ticket, please refer to this article:
Q100064: How to raise a support ticket
We're sorry to hear that
Please tell us why