Stable version 1.3

Finally, stable version 1.3 has been released.

Documentation: https://diffeomorphic.blogspot.se/p/daz-importer-version-13.html
Download: https://www.dropbox.com/s/6q9gf2fw24p3ash/import-daz-v1.3-20180425.zip

Changes from previous version:

• Unlimited number of facial expressions using custom driver functions.
• Posing works correctly for all character types.
• Corrective shapekeys for better deformation.
• Automatic transfer of corrective and other shapekeys to clothes.
• Material improvements.
• Principled shader option.
• Support for the new Blender 2.79 Rigify.
• Many bug fixes.
• User interface improvements.
• Tested on Linux.

The add-on was developed on Windows 7. It has not been tested on Mac because I don't have access to any, but it does work under Linux. Hence earlier Mac problems due to case-sensitive file names should be solved.

Linux

DAZ Studio is available for PC and Mac, but since I don't have access to any Mac the code has only been tested under Windows; more precisely, Windows 7. From user comments I have understood that there are problems to run the DAZ Importer under Mac, mainly because file paths are case-sensitive on Mac (?) but not on Windows.

As I said, I have no Mac to test on, but I do have a dual-boot machine with Windows and Linux. Linux is not really an interesting os for the DAZ importer, since DAZ Studio is not available on it, but it provides a testing ground for what happens with  a case-sensitive file system. In fact, somebody provided code for fixing problems with case sensitivity long ago (apologies for forgetting who), but the patch caused some obscure problems on Windows so I disabled it.

In the most recent unstable versions, the patch has been reinstated and I have managed to import DAZ files from my Windows hard drive under Linux. On Linux, it is crucial that the option Case-Sensitive Paths is enabled; it is found in the General section of the Settings panel. This option should be automatically enabled on Linux and Mac, and disabled on Windows, but because of some earlier confusion the default settings were switched. This bug is now corrected, but make sure that the settings are as in the figure below:

Here the same character has been imported and rendered under Windows and Linux. The lighting conditions and Blender versions are also different (2.79a vs 2.78), but the conclusion is that the add-on now works under Linux, at least for many characters.

Since the DAZ Importer seems to work under both Windows and Linux, it will hopefully work on Mac as well.

Custom driver functions

In Genesis 3 and 8 characters, facial expressions are implemented as poses of the face rig. To be able to easily set a face pose, the expressions are driven by rig properties displayed in the Daz Runtime tab in the T panel. E.g., the bone lUpperMiddle may be driven by a scripted expression like

(-16*A-32*B+4*C-13*D-23*E-20*F-7*G+9*H+22*I-5*J-10*K-7*L+5*M+1*N+8*O-10*P-13*Q-24*R-46*S-10*T-37*U+8*V-10*W-13*X+13*Y+0*Z+1*a+50*b-39*c-21*d-29*e+9*f+7*g-45*h-9*i-40*j)/1000

where A-j are driver variables, one for each rig property. In this case the data path of the A variable is ["DzVEE"], so A is the value of the rig property DzVEE, corresponding to the viseme EE. The problem is that in Blender the length of scripted expression is limited to 256 characters. If we load many face units, expressions and visemes, this limit is easily exceeded.

To circumvent this problem, about a year ago I introduced handlers, which are functions that are called every time the scene is updated. Instead of directly driving the bone locations by rig properties, the rig properties drive a number of intermediate bone properties, and the bone locations are then updated by the handlers. The advantage of this method is that each intermediate property is only driven by part of the original rig properties, so the length of the scripted expressions can be kept under the 256 character limit.

However, handlers introduce new problems of their own. It does not seem possible to combine handlers with other drivers, because the handlers are not drivers. This becomes a problem e.g. for eyelids, which are driven both by the eye rotation and by face units such as Eye Close. But the most severe problem with handlers is that they slow down the viewport. All handlers are called each time a scene is updated, which is very time consuming.

Following a suggestion by Alec Vallintine I have introduced yet another way to drive bone locations: using custom driver functions. This method seems to solve all the problems with the previous two methods:

1. There no limit to the number of driving properties.
2. Driver functions can be combined with other drivers.
3. Performance is much better than with handlers.

Since a few days ago, drivers for facial expressions are implemented using this new method.