SINGLE HD MAP

The addon already provides tools to bake HD figures, so this is just an alternative setup, easy to do by hand. The advantage is this way we use a single texture, and we don't have to save local textures as required by the built-in tools. We will use as example Victoria 8 HD.

This is a general method we can use with any multires, not only daz figures. We assume the reader is familiar with the basic blender tools so this is not a step by step tutorial.

step 1. HD uv map. First we create a new uv map for the HD texture, where all the figure uvs are in the first udim. For this it is enough to create a new uv map, then go to the uv editor and pack islands. Eventually we can also scale some islands to better fit the uv space. Below we see the Victoria 8 uv map packed nicely into the first udim.

edit mode: uv editor > uv > pack islands

step 2. HD texture. Then we create a new texture to bake to, first we create the image texture then the image for the texture. It is important to place this texture as selected in all the figure materials, so cycles knows it has to bake everything there. Note that we use the HD uv map for the texture, also we set the color space as non-color as this will be a normal map, but it's the same if we want to bake a displacement.

step 3. Bake. With the new texture in place and selected for all materials, we can now tell cycles to bake the multires. Below the settings I used. The baking process takes just a few seconds in a mid-level PC.

render properties > bake

step 4. Assign the HD texture. Now we have the normal map baked from multires, we can save the image then connect the texture to the bump node in all the materials. Note that the texture is the same for all the materials and it uses the HD uv map. Of course we can apply the multires modifier as we don't need it anymore having it baked.

Yes it's that simple. The main annoyance is we have to connect the texture by hand for all the materials in the figure.

Moving to GitHub

Atlassian has decided to sunset Bitbucket issues and wikis by August 20, 2026 (https://community.atlassian.com/forums/Bitbucket-articles/Announcing-sunset-of-Bitbucket-Issues-and-Wikis/ba-p/3193882). This means that the Diffeomorphic addons have to move before that. Atlassian suggests that one should use their JIRA software, but I don't know anything about JIRA and it looks really intimidating. Since staying on Bitbucket without a wiki and a bug tracker is not an option, I decided to migrate to GitHub instead. Most other open source projects seem to be hosted there, so it is probably a better place to be anyway. The stable releases on Dropbox are not affected by this migration.

The new repos are thus

• https://github.com/Diffeomorphic/import_daz
• https://github.com/Diffeomorphic/mhx_rts
• https://github.com/Diffeomorphic/retarget_bvh

I have managed to move the wikis to GitHub. It is still the same old and partly obsolete documentation, but at least it will live past August 20. 

• https://github.com/Diffeomorphic/import_daz/wiki
• https://github.com/Diffeomorphic/mhx_rts/wiki
• https://github.com/Diffeomorphic/retarget_bvh/wiki

The bug tracker will also be removed on August 20. New bugs should be reported at

• https://github.com/Diffeomorphic/import_daz/issues 

Issues with the MHX RTS and BVH Retargeter should also be reported there, because I don't have the bandwidth to monitor several sites regularly. Old issues are still available as static web pages which can be downloaded from

•  https://drive.google.com/file/d/1QZH6hR8lqJ9r4GH4F6Ss9AhXoeqNCO_E/view?usp=sharing

Thanks to GeneralProtectionFault for scraping the old tracker. 

Diffeomorphic Add-ons Version 5.1.0 Released

 Version 5.1.0 of the DAZ Importer, MHX Runtime System and BVH and FBX Retargeter have been released. They can be downloaded from

DAZ Importer: 
https://www.dropbox.com/scl/fi/xhzuuk8b7ljc9q6e82elh/import_daz-5.1.0.zip?rlkey=dne3g99ooizo6oq5jx3w4owln&st=7jghklqg

MHX Runtime System: 
https://www.dropbox.com/scl/fi/op24pkdexyvrp5jnu7gae/mhx_rts-5.1.0.zip?rlkey=y3zsymz5duukmgxwmfbfjzwc2&st=uezatm0b

BVH and FBX Retargeter: 
https://www.dropbox.com/scl/fi/qozj9a8jfidcwjwo4g0xf/retarget_bvh-5.1.0.zip?rlkey=0aabdno78nxq7byl7fe16mqj6&st=a3aeo55q

The add-ons have been tested on Blender 3.6 and 5.1. They should run on Blender versions from 3.0 onwards.

The main reason for this release is compatibility with Blender 5.1. Apart from various bug fixes, performance has also been improved, as announced here.

Performance Boost

I recently learned about the foreach_get and foreach_set functions that makes access to Blender arrays much faster. The latest versions of the Daz Importer (5.1.0) use these functions to loop over vertices, shapekeys, polygons etc. This had led to a quite nice performance boost.

A a test case I import a Genesis 9 Female character with eyebrows card style 06 and dForce Pixie cut hair. All global settings were set to the factory values (except the DAZ root paths), and the Genesis 9 preset was used for Easy import. I imported the character twice and hit ctrl-Z inbetween. Here are the results.

Blender 4.4:
addon 5.1:    39.398 seconds    37.200 seconds
addon 5.0:    75.642 seconds    75.424 seconds
addon 4.4:    70.669 seconds    70.991 seconds

Blender 5.0:
addon 5.1:    34.721 seconds    35.120 seconds
addon 5.0:    85.280 seconds    77.256 seconds

Blender 5.1 beta:
addon 5.1:    60.276 seconds    60.069 seconds

Notes:

1. The addon is backward but not forward compatible. Newer versions of the addon can be used in old blender versions, but not vice versa.

2. Version 5.1 (development version) of the addon is significantly faster than version 5.0.

3. Blender 5.1 beta is slower than previous Blender versions. This probably only reflects that a beta is not as optimized as a proper release.

The old method of loading shapekeys used to loop over the nonzero shapekeys in Blender, whereas the new method uses foreach_set to copy a numpy array in one sweep. However, for small morphs like the FACS, i.e. morphs that a localized to a small part of the full mesh, the old method may actually be faster. A python loop is much slower than the builtin method, but it only needs to access the nonzero shapekeys. For example, for the first Genesis 9 FACS morph, facs_bs_BrowDownLeft:
Mesh size:       25182
Morph size:     661
In that case the slow python loop is actually faster than using numpy.

For this reason, there is a new global setting, "Numpy Morph Fraction". The old method is used if the shapekey size (i.e. the number of nonzero deltas) is smaller than this fraction, otherwise the new method is used.

Active Morphs Panel

In the previous post I described how the Head and FACS morphs can be organized in subpanels; this is now the default behaviour. Another change is that the currently active morphs are collected in a separate panel, in the same way as in DAZ Studio. 

Here we have several active morphs, both head morphs (brows, mouth, tongue, visemes), an expression, and even some custom morphs like elf ears. All active morphs are present in a single place. 

The data structures needed to display the active morphs are built when the morphs are imported. If you have an old character, or if the active morphs have been corrupted for some reason, you can rebuild this data structure with the "Update Active Morphs" button at the top of the Morphs panel.

The existence of the "Active Morphs" panel is also governed by the global setting "Face Morphs Subpanels". If that option is disabled, the "Update Active Morphs" button is replaced by the old "Show Used Morphs Only" checkbox. The Morphs panel now looks like it did before, where the active morphs are spread out over the various panels.

One thing that I found annoying with the legacy behaviour was that a morphs disappeared when you drag the slider to zero, and "Show Active Morphs Only" had to be disabled to turn the morph back on. With the new setup a zero morph disappears from the "Active Morphs" panel, but the slider is still available in its native location.