Supported OS distributions for MistikaVR:
macOS: Sonoma, Monterrey, Big Sur, Catalina, High Sierra, and Mojave. (Newer macOS versions may work well or not, but if they do not appear here is because we do not have enough feedback to confirm full stability).
Windows: Windows 10 (64bit). Windows 11 (64bit)
Maximum render (output) resolution for MistikaVR:
Mistika does not enforce any resolution limits by itself, but each platform stablish its own limits (typically due to openGL limitations). At the date of this document:
macOS: 16k x 8k
Windows: 32k x 16k
Minimum hardware required for MistikaVR:
Requirements For basic cases only, up to 4K render resolution and few source cameras (up to 6):
- Number of CPU cores: 4
- RAM: 16 GB
- Display resolution: 1920x1080
- Graphics card model:
Windows: A discrete GPU is required. NVIDIA is recommended and it is the only certified manufacturer for Mistika VR on Windows.
macOS: Mac models from "late 2013" are supported. Mac computers older to that date will not work. (You can check your hardware build date in the Apple icon -> "About my Mac")
- Mac Intel models: Requires a discrete GPU from AMD
- Mac ARM models (M1/M2/M3...): Not supported yet, although it is working for an increasing number of projects. Support for these platforms is currently work in progress, we are actively developing it but it is not finished. If you want to try Mistika on this platform we recommend to test it with the trial version before purchasing.
Recommended hardware configuration for Mistika VR
Requirements for working at high resolutions (8K or more) or with many source cameras (6 or more):
- Most of the processing inside Mistika VR is made by GPU: Geometry adjustments, Color adjustments, Optical Flow (which is typically the bottleneck), etc. So the GPU is normally the most important component (but not always, as explained below). On Windows, a modern NVIDIA board with good specs is recommended
- In the other hand, the processes that are let to CPU processing are the decoding of camera codecs and the encoding of the render codec. With these exceptions:
* NVIDIA h264/h265 codecs are rendered by GPU (these codecs are rendered with NVIDIA nvenc encoder, so the GPU needs to be NVIDIA for those. For these cases the computer needs to be Windows, as Apple does not currently support NVIDIA ). Note that in Mistika the GPU is dedicated to internal image processing and render encoding, but not for decoding H264/H265 camera rushes (which in those cases it is done in parallel by the CPU).
The NVidia encoder uses dedicated hardware for render encoding that is not used for any other task. This means that using those codecs will not reduce the render speed. If you want to take advantage of this capability we recommend a NVIDIA model from the Pascal generation or later, as previous models are discontinued and not supported for this (and can not do hardware encoding at 8K resolution anyway. For more details about supported encoding formats: https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new#Encoder )
However, all the above only applies to the encoding of the render format. Meanwhile, reading and decoding camera rushes may still need a lot of CPU power, depending on the number of cameras, their codecs, and their resolution. Up to the point that In many cases the bottleneck is the CPU and not the GPU. In these cases Mistika VR will take advantage of as many CPU threads as possible (up to 32 core / 64 Threads, as past those numbers there are diminishing returns).
* RED R3D formats can be decoded by GPU as long as there is a modern NVIDIA GPU installed.
- Meanwhile, the decoding and encoding of uncompressed formats do not use significant GPU or CPU resources, what they need is high storage speed (but a lot of it!).
So it depends. Projects using many camera rushes based on compressed codecs or requiring heavy CPU encoding to CPU intensive formats such as EXR can take advantage of having many CPU cores at high clock speeds. Meanwhile, stitching smaller camera rigs and then rendering to NVIDIA h264/h265 deliveries will not take advantage of high end CPUs at all. We recommend to watch the Windows Task Manager or macOS Activity Monitor while playback and rendering to find where are the hardware bottlenecks for your particular case.
- Mistika VR only uses one GPU, the one where it is launched. We do not expect extra speed by having two GPUs.
Another recommendation could be this: In general, the highest end models of CPUs and GPUs only provide a bit more speed than models that are a bit inferior, but they can cost much more. In the worst cases you may need to pay 100% more for just 15% additional speed, compared with cost efficient hardware in the sweet spot.
For this reason, it can be better to use two (or more) computers with just "good" specs rather than one only super workstation with top specs, and then use shared storage and distributed render tools like Uberware Smedge for render managing.
- Regarding RAM: 8GB is the absolute minimum for very simple cases (few source cameras and rendering up to 4K). At least 16GB are recommended, and 64 GB is a good reference for relatively complex cases. It mainly depends on:
* The number of cameras and their resolution
* The number of CPU cores. Each CPU core can be working on a different frame in parallel, so using many cores requires a lot of extra RAM to take full advantage of them.
* The render resolution (obviously).
* When using network storage, the OS will normally use the unused RAM as a read / write cache, so even if Mistika is not using it directly it can help in these cases.
- Display resolution: There are no current limitations. In 4K and higher resolution displays the GUI elements may appear small initially (depending on the monitor size), but you will find scaling options in the preferences menu.
- GPU dedicated video memory: At least 8GB dedicated memory. More is recommended when there are many cameras and when rendering to high resolutions like 8K+ ).
- Storage speed: Ideally, as fast as needed to read all the camera shots simultaneously while writing the render results at the same time. Also important when rendering to uncompressed formats. Please note that rendering involves both reading and writing at the same time, so if the storage is not fast enough and the destination format is specially big (like DPX or EXR) then it can help to put the original files in one storage volume and rendering to a different one (or at least for testing if your render bottleneck is in the storage access). If you work on network drives (NAS), we recommend to test your reference project on local NVMe disks first (which is the fastest way), so that you will know how much performance is lost when using network drives.