MikuMikuDance (MMD) with MikuMikuEffect MME on Ubuntu/Linux

Copying from rejected WineHQ test result. Keywords: "MMD with MME on Ubuntu", "MME on Wine", "MME on Linux"

___

What works
----------

After installing additional libraries, can load models, motion data, pictures and video; can save motion data and pictures.

MikuMikuEffect (https://www6.atwiki.jp/vpvpwiki/pages/219.html) can be used to increase graphical quality, depending on hardware. This test result focuses on getting MME to work.

What does not work
------------------
Textures with .dds suffix (Direct Draw Surface) did not load.

Video recording doesn't work for me. Loading video for use as background worked after installing one of a number of different systems designed to help with video, maybe ffdshow or K-Lite Codec Pack (which includes it).

'Self-shadows' did not work with basic Wine install and builtin libraries.

Single-window mode doesn't work, due to some kind of graphical corruption outside of the video rendering area. When rendering stops, such as because of recording video in a separate window, refreshing the interface by resizing or moving offscreen will make the interface persist until rendering restarts.

MME does not work after following instructions for Windows users. It can be made to work for both 32-bit MMD and 64-bit MMD.

Fonts don't display in default Wine install.

Workarounds
-----------
Used 'winetricks droid' to get Latin fonts used for English interface. The interface option for Japanese language mode might work by passing environment variable LANG="ja_JP.UTF8", but some fonts may need to be installed; I'm wondering if I broke something because it seems that out of a new 32-bit prefix, a months-old 64-bit prefix, and a very old 32-bit prefix, only the old 32-bit is rendering Japanese or Chinese fonts in the Windows UI, but I thought it worked for the 64-bit one as well. Older test results may offer advice. [Japanese mode may be messed up with English locale if it wasn't set to that when the program started.]

Use menu > view > separate window to get interface to show up. [The interface specific to the rendering window, such as X,Y,Z values for the current bone, is still hidden by the too-large frame buffer or whatever.]

***SETTING UP MIKUMIKUEFFECT***

As explained by a Japanese user of Ubuntu (https://www.youtube.com/watch?v=O1qHV1zryDE), use winecfg for the appropriate prefix to set the d3d9.dll library to prefer native option, which is the dll packaged with MME. Then try one of the following:

Option 1: download the June 2010 DirectX install files (https://www.microsoft.com/en-us/download/details.aspx?id=8109), as linked by page 1 (https://learnmmd.com/http:/learnmmd.com/troubleshoot-common-error-set-up/) and page 2(https://learnmmd.com/downloads/). The Google search result, from Microsoft, for DirectX 9 doesn't work, and wouldn't install for me; the version linked from MMD's creator's site (http://www.geocities.jp/higuchuu4/index_e.htm) also failed to install for me.

This includes packages named both d3dx9 and d3dx10; I assume they all get installed no matter what version of Windows you're set to. Apparently this install doesn't replace the Wine-provided d3d9.dll, so I don't know if the version included with MME is different from the normal Windows version.

After installing this, MME should load for 32-bit MMD instead of giving an error about not being able to load the default effect and freezing. However, 64-bit MMD still crashes when it tries to use the provided d3d9.dll for MME. The benefit for 64-bit MMD is that self-shadows now work. In other words, the crash is probably related to the .dlls included with MME, and not some other part of the Wine prefix that also causes self-shadows not to work.

32-bit MMD can run with MME on either a 32-bit or 64-bit Wine prefix, as long as the above installation has been done. I assume this entire process is necessary, even though I don't remember doing it for my old 32-bit prefix and didn't know why the new one wasn't working. And of course it isn't necessary for the MMD folder to be inside the Wine prefix unless the drives in winecfg restrict access to elsewhere.

Option 2: [note: see below, did not work] Use winetricks to install DirectX and the VC++ libraries. Winetricks mentions wine bug 30713 (https://www.winehq.org/pipermail/wine-bugs/2013-August/361927.html); however, to get 64-bit MMD to have MME, the only two library overrides you need are d3d9 and msvcr90, which comes from VC++ 2008, not VC++ 2010. For the very new users, I just typed 'winetricks' to see what would happen and this was in the UI that came up.

Video encoding still didn't work, and possibly introduced by this process was a bug: 64-bit prefix Wine can run 32-bit MMD with MME, but when I tried to load an .avi as a background, one out of two failed to load properly. The second loaded. This was after selecting 'all codecs' in addition to 'ffdshow' to install with winetricks. The video that did work in this case was one that didn't play properly as background before, but this time it did decode properly without artifacts, so I still recommend doing this.

UPDATED TEST RESULTS: Option 2 does not seem to work for me. Winetricks appears to be useful for installing fonts; however, it seemed that the ffdshow provided does not allow MMD to load .avis. I still got error "002e:err:msvideo:ICLocate Required media codec 'vidc avc1 [or h264, for another video]' not found!" So another codec method like K-Lite Codec Pack is necessary, though I don't plan to use this feature.

The Visual C++ libraries winetricks gives also don't make MMD work; I had to use the specific 2008 version linked on the MMD/VPVP website. I had three different versions of msvcr90.dll, all slightly different sizes, and only one of them worked with MMD; but it only worked in the installation folder, not if I put it in the same directory as MMD. Maybe it has to be registered.

The DirectX9 version(s) provided by Winetricks also didn't work for MMD, including the 'directx9' verb which provides a Feb 2010 package; again, the one that works is the specific June 2010 version. The only library MMD appears to need is d3dcompiler_43.dll, which is 2106216 bytes (x86) and 2526056 bytes (x64). These do work if you put them in the same folder as MMD.

So testing with my fifth 64-bit prefix, to get 64-bit prefix Wine to run 32-bit MMD with MME, all you need is that single file, as well as setting the override for d3d9[.dll] in winecfg. I assume it would be the same for a 32-bit prefix. I don't think you need to install VC++ 2008, but don't want to test a sixth Wine prefix.To get 64-bit MMD with MME, you need that file (x64 version), as well as installing the specific VC++ 2008 package (not from Winetricks) and setting the override for msvcr90.

ANYONE WHO WANTS THIS TO WORK AUTOMATICALLY SHOULD FILE A BUG REPORT. I am using the latest development version as of time of writing, but my experience with open source projects is that bugs I file don't get fixed.

The directx9 install adds around 250 MB to the windows/system32 and syswow64 folders, so knowing that only a small part of it is needed saves space. I haven't completely tested this; it's possible more bugs will arise if only this library is present.

"Initialize Error: failed to load default effect file. Please check video card capability." this means the right d3dcompiler_43.dll version isn't being used. Apparently there's no need to add it to library overrides though; not sure why when d3d9 does need to be and both are present in default Wine install. Can occur after loading dlls used for MME.

"Initialize Error" by itself, for 64-bit MMD+MME only, means the correct msvcr90.dll version isn't present, or it hasn't been added to library overrides.

ANOTHER UPDATE: You also need 'directx9_43.dll' for the corresponding MMD type, 32- or 64-bit. Otherwise, when you set self-shadows to none in the accessories/lighting pane, MMD stops working correctly like it no longer displays vertices or the move/rotate icons from hotkeys X and Z. It could affect other things as well, like specific effects.

If a model has white textures because they're .dds and Wine isn't set up to read them, convert them to a different image format with programs like ffmpeg or imagemagick. This could be done with the model editors I didn't test to use the new filenames, or by replacing the .dds files since MMD will load them anyway.

If an effect can't load, it may help to use MME menu > Tool > skip device validation.

A special case of archives with MMD models that used higher-plane Unicode characters; not Wine-related, but I had to rename them from .rar to .zip for file-roller to display the filenames and extract them, even though they were .rar. On the command line, unzip and unrar both failed.

What was not tested
-------------------
Screen capturing a video at a reduced animation speed, which would alter the outcomes of the physics engine.

Lip-syncing or using motion capture from a hardware device.

Extra comments
--------------
The installed packages, Visual C++ and DirectX, installed many dlls but Wine might still be using builtin libraries. May be possible to get video encoding to work by using native libraries? Error message is "Cannot set up MUX and File Writer" or 「MUXおよびWriterフィルタ作成失敗」. Maybe the YouTube user with uploaded videos knows.

I upgraded to Wine 3.x, from 2.18, in hopes that it would improve MMD functionality. Nothing has improved, other than learning how to get self-shadows to work in 64-bit Wine prefix for 32- or 64-bit MMD.

MMD now also uses 100% of a CPU core, except when paused for a UI dialogue. Even with MMD's 'power saving' mode where it only updates the screen when the mouse moves, leading to 0 frames per second, it still uses 100% CPU with no models loaded. Previously it had a low load, maybe 10~20%. Have not tested whether Wine 3.0 does this, but it seems the latest Wine versions only have disadvantages compared to 2.x for running MMD.

Only possible improvement is that encoding options are now listed for video output as .avi. They don't work, but I don't think they were there before despite having installed K-Lite Codec Pack (before uninstalling). Previously only 'avi raw video output' was listed, which didn't work although it works for Windows users.

Use of a video as background appears to be very inefficient. Lag suggests it decodes from the last keyframe every time a video frame is requested, even if you're only going forward. This suggests inefficiency elsewhere.

___

See also https://bugs.winehq.org/show_bug.cgi?id=45072, "Enabling csmt causes 100% CPU use in MikuMikuDance"

>> CSMT is controlled through the registry key HKCU/Software/Wine/Direct3D/csmt,
>> which is a DWORD value. Setting the key to 0 will disable the feature, while
>> setting it to 1 will enable the feature.
>
>Disabling csmt returns the CPU usage to normal levels with wine-3.7.

Have identified a crash when loading an effect (in MME) after using "refresh textures", or refreshing textures when an effect is active. Not sure if it affects Windows. Another bug with using 'no self shadow' mode with model parts turned off using MME that might be specific to Wine, and an unrelated bug relating to deleting frame 0. By disabling hardware check using menu in MME, was able to load Ray-MMD, but the tested model had a display problem with (probably transparent) hair in front of face which was white. I guess when an effect is loaded, it is actually compiled, which is why it takes so long to load Ray-MMD. Didn't test more than that.

May need to use Japanese locale (but maybe can use English interface) to automatically load effects with Japanese characters in the path, such as for the model linked at https://superuser.com/questions/1319606/zipfile-character-encoding-challenge or possibly with the '.pme' effects file that's saved alongside a 'pmm' project.