Moving to GitHub

Atlassian has decided to sunset Bitbucket issues and repos 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 that. Since staying on Bitbucket without a wiki and bug tracker is not an option, I decided to migrate to GitHub instead. Pretty much all other open source projects seem to be hosted there, so it is probably a better place to be anyway.

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

What I don't know how to handle yet is the bug tracker with 2,645 issues to date. It can be exported from Bitbucket as a huge zip file, but I don't know what to do with it if I don't move to JIRA. Suggestions are welcome. We have until August 20 to figure it out. 

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.

Face Morph Subpanels

Standard morphs are grouped into various panels, but all morphs in a group are simply listed in alphabetical order. Mickey Ho pointed out that this is not practical for animating sliders, in particular for the hundreds of Genesis 9 FACS morphs. In DAZ Studio the various FACS morphs are grouped into subpanels, which makes access more convenient.

In the last commit the FACS panel has the same subpanels in Blender. To enable this feature, enable the global setting "Face Morph Subpanels".

The FACS panel now has the same subpanels as in DAZ Studio. The morphs are assigned to subpanels which makes them better organized.

The button on the top of a subpanel only apply to the morphs in this panel. The buttons at the top of the FACS panel affect the sliders in all subpanels.

Subpanels are also generated for the head pose morphs for previous generations, Genesis - Genesis 8. Before we had two types of face morphs, Face units and Visemes. That was a completely ad hoc separation that I did long ago, and may have made sense for the first Genesis generations. In the last commit those types are replaced by a single Head type. 

There used to be another type of standard morphs called Head which were taken from another directory. That included morphs like elf ears which are normally baked into the character, so those are not considered to be standard morphs anymore. If you need such morphs you can always import them as custom morphs.

Import standard morphs with the Head option enabled.

The panel with Head morphs is now split into subpanels, which work like the FACS subpanels.

If we import morphs with "Face Morphs Subpanels" disabled, or if we load an old character into the  scene, the old style morphs appear and work as before. The new option does not change how the morphs themselves work, but only how they are displayed in the user interface.

Diffeomorphic Add-ons Version 5.0.0 Released

Version 5.0.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/8b5z3cy6kd9pcxeo17bh1/import_daz-5.0.0.zip?rlkey=udvj5mbw4f1psmvrnt8949ed5

MHX Runtime System: 
https://www.dropbox.com/scl/fi/0nf018loxjpy0nbe26zpr/mhx_rts-5.0.0.zip?rlkey=dd33350oazwagkund3puqt7up

BVH and FBX Retargeter: 
https://www.dropbox.com/scl/fi/0ftrenp005ub78ov5fek0/retarget_bvh-5.0.0.zip?rlkey=c27jhf4pxc3scpu0ffmil197d

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

The main reason for this release is compatibility with Blender 5.0. Several other bugs have also been fixed.

Conclusion

The time has come to wrap up this series of posts. I went to grad school in the early 1980s, and specialized in phase transitions and critical phenomena, often working on 2D models. A few years later conformal field theory (CFT) came along, and essentially finished my field of research. I was too young and isolated to notice at the time, but when I did notice a few years later I felt that I had missed the bandwagon. CFT explains everything worth knowing about 2D critical phenomena, but it says nothing about the much harder and physically more relevant case of critical phenomena in 3D. So I started to think that something similar might work in higher dimensions as well. It can not be conformal symmetry, because the conformal group is infinite-dimensional only in 2D. But the same group also described diffeomorphisms in 1D, and that has a natural generalization to higher dimensions.

This made me decide that a multi-dimensional Virasoro algebra had to exist and I went out to find it. That it really does exist and has natural realizations on p-jets was very satisfying, but completing this task took a long time and I ran out of funding in the process. Moreover, it is only a limited success, because important pieces of the puzzle are still missing.

• There are operators acting on a vector space, but I haven't found a nice way to identify this space with its dual. So there is no known inner product and we can not discuss unitarity.
• The vector space is too big because momenta and velocities are not identified, which they should be.
• This is a purely kinematical theory, like tensor calculus. To use it in physics we should introduce dynamics in some form, with a Lagrangian, a Hamiltonian, or equations of motion. Doing this for p-jets is surprisingly difficult, or at least it was for me.

Because of these shortcomings I haven't been able to apply this theory to physics. Nevertheless, the math exists which made the effort worthwhile in itself, and I hope that somebody will make progress on the above problems one day.

But even if much remains to be done, some physics insights can still be extracted. The Virasoro extension depends on the observer's trajectory, and therefore we need a theory with an explicit physical observer. Since the observer's position is an operator, we must measure it to know its value, and that measurements is subject to quantum fluctuations. This is really enough to rule out every approach to quantum gravity which does not take horizontal fuzziness into account, because the lack of horizontal fuzziness amounts to a hidden assumption about an infinite mass.

<Previous    <<First