Second Week

Horizontal fuzziness and Quantum Jet Theory (QJT) may seem to be ad hoc ideas coming out of nowhere. However, they are an inevitable consequence of the mathematics of the diffeomorphism group in multiple dimensions. During the first week I tried to keep the math down to a minimum, but now we have reached a point when some mathematical concepts and formulas are unavoidable. This week I plan to discuss the following topics:

• Lie Groups and Algebras
• Virasoro Algebra
• Multi-dimensional Virasoro Algebra
• Divergencies
• Geometrical Formulation
• Off-shell Representations
• Multi-dimensional Virasoro Algebra and QJT

Before digging too much into the math, I would like to give a birds-eye view of results that I want to present this week. The discussion will center around something called Lie algebras (I will explain what that is tomorrow) and their representations. These are closely related to quantum physics. Essentially, the representation theory of

• finite-dimensional Lie algebras is quantum mechanics, i.e. Quantum Field Theory (QFT) in zero dimensions.
• infinite-dimensional Lie algebras living on the circle, e.g. the Virasoro or affine Kac-Moody algebras, is QFT on the circle.
• infinite-dimensional Lie algebras living on higher-dimensional spaces is not QFT in the same dimension. Instead it is QJT.

The 1980s was a time of great change in theoretical physics, with conformal field theory transforming both string theory and statistical physics. Many physicists became interested in the Virasoro algebra, and quite a few tried to generalize it to diffeomorphisms in higher dimensions, using the same methods that worked on the circle. We all failed. At this point in my life I was running out of funding, and instead of moving and trying to pursue a very uncertain academic career, it was much more attractive to get a stable income and start a family.

A few years later I came across a paper by Rao and Moody [Comm. Math. Phys. 159: 239-264 (1994)] who claimed to have generalized the Virasoro algebra and constructed representations thereof, something that I had utterly failed to do myself. In fact, Rao had already sent me a preprint of their paper a few years before, but at that time I didn't grasp what they had done. This time I realized that their work was important, but it still took years to understand their formalism and its geometrical meaning. It turns out that their construction is equivalent to a limited form of QJT, which only involves the base point. In two articles I then generalized their result to full QJT, first to zero-jets [Comm. Math. Phys. 201, 461-470 (1999)] and then to arbitrary p-jets [Comm. Math. Phys. 214 469-491 (2000)]. Unfortunately the articles are behind a paywall, but preprints are available at the arXiv [physics/9705040], [math-ph/9810003].

It is now clear why the early attempts to apply QFT methods to the diffeomorphism algebra in multiple dimensions were doomed to failed. We were trying to apply QFT to a problem that requires QJT. The extension that generalizes the Virasoro algebra to higher dimensions is a functional of the observer's trajectory, so ignoring horizontal fuzziness is not possible. Except in one dimension, where the only possible trajectory is the circle itself.

 <Previous      Next> 

Partial and Complete Observables

Today I will repeat the argument using Rovelli's language of partial and complete variables [gr-qc/0110035], which I found useful to organize my thoughts.

Rovelli distinguishes between partial observables, which can be measured but not predicted, and complete observables, which can be predicted once we know the initial conditions. In a simple mechanical system there are two partial observables:

• \(\phi\): Result, measured by a detector.
• \(t\): Time, measured by a clock.

The partial observables can be measured but not predicted. What can be predicted is the complete observable \(\phi(t)\), the reading of the detector at time \(t\). In the quantum case predictions are statistical, so complete observables are fuzzy.

Now let us turn to field theory. There are now three partial observables:

• \(\phi\): Result, measured by a detector.
• \(t\): Time, measured by a clock.
• \(x\) or \(q\): Position, measured e.g. by a ruler or a GPS receiver.

In QFT we construct the complete observable \(\phi(x,t)\), the reading of the detector at time \(t\) and location \(x\), from these three partial observables. 

Here is the problem with QFT. The experiment takes place inside a detector, and we can in fact predict its future location. The detector is part of the physical world and has dynamics of its own. Instead we can construct two different complete observables from the same three partial observables:

• \(q(t)\): The detector's location at time \(t\).
• \(\phi(t)\): The reading of the detector at time \(t\), at the detector's location.

We can think of \(\phi(t)\) as \(\phi(q(t),t)\), the value of the field at the detector's location. Since complete observables are fuzzy, we now have two types of fuzziness:  the horizontal fuzziness of \(q(t)\) and the vertical fuzziness of \(\phi(t)\). In QFT we only have vertical fuzziness.

The obvious objection is that all information about the field outside the detector's worldline is lost. However, we can add more partial observables which can also be measured inside the detector:

• \(\phi_m\): The \(m\):th derivative of the field, also measured inside the detector.

From the complete observables \(\phi_m(t)\) we can construct the generating function
\[
\phi(x,t) = \sum_m {1\over m!} \phi_m(t) (x-q(t))^m,
\]
which can be viewed as the Taylor series expansion of the field \(\phi(x,t)\). To the extent an infinite Taylor series is equivalent to the field itself, we recover the field that we started from.

Hence we again arrive at Quantum Jet Theory.

<Previous    Next>

Quantum Jet Theory

In the previous posts I argued that what is missing from Quantum Field Theory (QFT) is horizonal fuzziness. Today it is finally time to discuss how this can be implemented. Obviously, horizontal fuzziness requires that the theory has horizontal observables. QFT only has vertical observables, the values of the field at given points in space and time, and hence we can not formulate horizontal fuzziness within the framework of QFT. But there is a simple way to introduce a horizontal observable: expand the field in a Taylor series. A Taylor series has both vertical observables (the Taylor coefficients) and a horizontal observable (the base point a.k.a. the detector's position), and hence it can express both vertical and horizontal fuzziness. This is the idea behind Quantum Jet Theory (QJT). The name comes from the notion of jets in mathematics; a \(p\)-jet is locally the same as a Taylor series truncated at order \(p\). There might be other ways to include the detector's trajectory in a theory, but QJT is what naturally arises from the representation theory of the multi-dimensional Virasoro algebra that I will discuss next week.

QFT is quantum physics applied to fields, i.e. systems with infinitely many degrees of freedom. A field \(\phi(x,t)\) represents the result of an experiment \(\phi\) done at the spacetime point \((x,t)\). The result \(\phi\) is fuzzy, but the location \(x\) is known precisely at all times. Hence QFT has vertical fuzziness but no horizontal fuzziness. In QJT we expand the field in a Taylor series,
\[
\phi(x,t) = \sum_m {1\over m!} \phi_m(t) (x-q(t))^m.
\]
This formulation may seem to be limited to one dimension, but with multi-index notation it makes sense in higher dimensions as well.

The Taylor coefficients \(\phi_m\) are the vertical observables. They describe the result of the experiment inside the detector. The corresponding momenta \(\pi^m\) describe the experiment's rate of change. Here we put the index upstairs, because the momenta belong to the dual space. The product of the uncertainties obey
\[
\Delta \phi_m \cdot \Delta \pi^n \geq {\hbar\over2} \delta^n_m
\]
where \(\delta^n_m\) is nonzero only when \(m = n\). This is vertical fuzziness.

The expansion point \(q\) is the horizontal observable. It represents the location of the detector. If \(p\) is the detector's momentum, the uncertainty relation becomes
\[
\Delta q \cdot \Delta p \geq \hbar/2.
\]
This is horizontal fuzziness.

Hence by replacing the fields with the corresponding Taylor series we get a theory in which both the result of the experiment and its location are fuzzy; QJT implements both vertical and horizontal fuzziness. 

To replace the fields by their Taylor series might sound trivial, and it would be if the expansion point were a fixed point in space. But the last equation means that we expand the fields around a fuzzy point.

<Previous     Next>

Renormalization

Yesterday we argued that in a Quantum Field Theory (QFT) of gravity cannot exist, due to incompatible assumptions about the observer's mass. Today I will discuss the analogous situation for non-gravitational interactions such as electromagnetism.

An experiment is still an interaction between a system and an observer, and the outcome still depends on the observer's physical properties. Since the predictions of QFT are independent of the observer's charge and mass, we have still made some hidden assumptions, namely

• The observer's charge is zero, so the observer does not disturb the fields.
• The observer's inert mass is infinite.

What makes the situation different from yesterday is that this double limit exists. Only in the case of gravity, where charge equals heavy mass, are charge and inert mass related. For non-gravitational interactions charge and mass are independent, and we can assume both that charge is zero and that mass is infinite.

However, there is a catch. In reality the observer's mass is large but finite, and QFT is only an approximation, valid for systems where all relevant energy scales are much smaller. But this means that all energy scales must be smaller than the observer's mass, including the energy of virtual particles. So the observer's mass essentially becomes a cut-off which limits the energy of virtual particles.

The fundamental theory has horizontal fuzziness. It can be approximated by QFT without horizontal fuzziness, but too energetic virtual particles must be removed. Otherwise some of them may collide with the detector and displace it, making its location fuzzy. Once quantities have been calculated at a given cut-off, we can let the observer's mass approach infinity, making sure that the observed quantities change consistently. This process is called renormalization.

Renormalization is today a standard part of a physicists toolbox, but it was not always uncontroversal. For two decades after the discovery of quantum mechanics, applying it to fields yielded nonsensical infinite results. In the late 1940s people like Schwinger, Feynman and Tomonaga realized how to extract finite results, essentially by subtracting two infinite numbers. Older physicists like Dirac remained skeptical and found such hokus-pokus unsatisfactory, even if the recipe gives extremely accurate results. My perspective is similar to Dirac's. Renormalization is the price to pay for applying a theory without horizontal fuzziness to a situation where horizontal fuzziness is present.

<Previous    Next>

An Alternative Formulation

Today I will repeat the argument from yesterday using a slightly different formulation. 

Every experiment is an interaction between a system and an observer, and the outcome of the experiment depends on the physical properties of both. In particular, it depends on the observer's mass. Neither general relativity nor Quantum Field Theory (QFT) make predictions that depend on the observer's mass, so some hidden assumptions must have been made. It is clear what those assumptions are:

• In general relativity, the observer's heavy mass is zero, so the observer does not disturb the fields. This observer is essentially what Einstein calls a test particle.
• In QFT, the observer's inert mass is infinite, so the observer knows where he is at all times. In particular, the observer's position and velocity at equal times can be measured simultaneously to arbitrary precision.

Now the equivalence principle asserts that heavy mass equals inert mass, i.e. zero equals infinity. This is the basic problem with a QFT of gravity.

Hence quantum gravity requires that the observer's mass is finite and nonzero. Then we can not ignore the interaction between the observer and the gravitational field, and we can not ignore horizontal fuzziness.

Let us spell out the second assumption in more detail. Let \(q\) be the observer's position and \(p\) his momentum. The accuracy with which they can be simultaneously measured is limited by the uncertainty principle:
\[
\Delta q \cdot \Delta p \geq {\hbar\over2},
\]
where \(\hbar\) is Planck's constant divided by \(2\pi\). The observer's velocity \(v\) is given by \(p = Mv\), where \(M\) is the observer's mass. Hence
\[
\Delta q \cdot \Delta v \geq {\hbar\over2M}.
\]
In order to know the observer's position at all times, we must simultaneously know his position and velocity at equal times without any uncertainty. Hence the right-hand side of the equation above must vanish, i.e. \(\hbar/M = 0\). There are two ways to achieve this:

• \(\hbar = 0\). This is classical field theory including classical gravity.
• \(M = \infty\). This is quantum field theory without gravity.

Hence we can ignore horizontal fuzziness in those two limits, and only then. If Planck's constant is nonzero and the observer's mass is finite, which is the case in every real-world experiment, horizontal fuzziness is always present in principle.

<Previous   Next>

Horizontal Fuzziness

The difference between classical and quantum physics is fuzziness. In classical mechanics all quantities can be measured to arbitrary precision, but observables in quantum mechanics are subject to quantum fluctuations. There is a fundamental limit to the precision with which certain pairs of physical properties, such as position and momentum, can be simultaneously known; this is Heisenberg's uncertainty principle. Hence measurements in quantum mechanics are fuzzy.

Our most accurate theories are theories of fields, i.e. systems which depend on space as well as time. Electromagnetism, weak and strong interactions are all described by Quantum Field Theory (QFT), i.e. quantum theory applied to fields. In QFT we have the same kind of fuzziness as in quantum mechanics. The result of an experiment is fuzzy, but the location of the experiment is not. This is unphysical in my opinion. The experiment takes place inside a detector, and in order to know where the detector is located, we must measure its position, e.g. with rulers or a GPS receiver. This measurement is a separate physical experiment and as such subject to quantum fluctuations. Hence we need to replace QFT with a more general theory which takes into account that the detector's location is fuzzy.

A fundamental theory must hence have both vertical fuzziness (the result of an experiment is fuzzy) and horizontal fuzziness (the location of the experiment is also fuzzy). We expect that QFT is recovered in the limit that horizontal fuzziness can be ignored. This is the case when the detector is a classical object whose position at all times can be known without fuzziness. This amounts to a hidden assumption that the detector's inert mass is infinite.

Now it is easy to see why QFT is incompatible with gravity. The equivalence principle asserts that inert mass equals heavy mass. However, an infinitely heavy detector will interact with the gravitational field and immediately collapse into a black hole, which sucks up the rest of the universe. This is not a very good description of most experiments. 

Quantum mechanics reached its final formulation a century ago, and people attempted to apply it to gravity soon thereafter. There has been essentially no progress on this problem over the past century, and the reason is now clear. By ignoring horizontal fuzziness, a hidden assumption about an infinitely massive detector is introduced, and gravity does not work well in the presence of infinitely massive objects. There have also been other well-advertised approaches to a quantum theory of gravity. It is not clear to me to what extent they are related to field theory, but it does not really matter. Absence of horizontal fuzziness amounts to the same hidden assumption about an infinitely massive detector, and hence such theories are also incompatible with gravity.

<Previous       Next>

Dad's Theory of Physics

A long time ago I aspired to be a theoretical physicist. Eventually I came up with a discovery that I now believe is quite significant, but it took more than a decade before I started to understand what it meant. Since my postdoc only lasted four years, I ran out of funding and went on to do something else. However, my wife insists that I must explain to our children what I spent so much time on even after I had left academia. This will be done in a series of posts over the next three weeks. 

Explaining a discovery in mathematical physics is not so easy, especially not to lay-people. I could say (and have said) that I generalized the Virasoro extension of the algebra of diffeomorphisms on the circle to higher-dimensional manifolds, and discovered how to build off-shell representations thereof. Alas, that sentence is generally met with a blank stare. Instead I will try to explain the main physical ideas, initially using a minimum of formulas. This will be the topic of the first week, where I introduce the notion of horizontal fuzziness and explain why it is a necessary ingredient in any quantum theory of gravity.

In the first week I plan to cover the following topics:

• Horizontal Fuzziness
• An Alternative Formulation
• Renormalization
• Quantum Jet Theory
• Partial and Complete Observables

The second week I will describe the mathematical discovery underlying these ideas. This will require quite a bit of mathematical formalism, but I will try to introduce the necessary background material first. What should be emphasized is that the ideas introduced during the first week do not come out of thin air. Instead, they are the physical interpretation of the off-shell representations of the multi-dimensional Virasoro algebra.

The third week I will discuss some consequences of horizontal fuzziness. Just as vertical fuzziness (quantum mechanics) is different from no fuzziness (classical mechanics), we can expect that horizontal fuzziness is significant too.

 Next >  

Instances Revisited

The DAZ Importer imports most scenes correctly, but it has long struggled with instances. Simple cases have worked fine, but the DAZ and Blender scenes differed when the instance target is itself an instance, or if there are formulas that affect the locations. In the last few days I have revisited those issues and now all scenes seem to import correctly. Two long-standing issues in the bug tracker have been resolved.

Issue 479 deals with the Shipping yard construction set. It is imported correctly when the "Mesh Fitting" option is set to "Unmorphed Unique", "Morphed" and "DBZ File". With "Unmorphed Shared" all containers have the same color, which is expected since all container objects share the same mesh and hence the same materials.

Issue 2181 deals with the Medieval City Block. This is now imported correctly with "Morphed" and "DBZ File". It can not be imported with one of the "Unmorphed" settings because there are formulas that affect the locations of the instances. With the "Morphed" setting the formulas are taken into account, and with "DBZ File" the final locations are baked into the dbz file.

DAZ RESOURCES

This article assumes the reader is confident with linking and appending files to manage large projects in blender. The purpose is to show how we can eventually optimize resources with assets imported from daz studio. This is entirely optional as things work fine as they are.

https://docs.blender.org/manual/en/latest/files/linked_libraries/link_append.html

https://docs.blender.org/manual/en/latest/files/linked_libraries/library_overrides.html

The way we usually go is to create blend files with all the resources localized. That is, we import a daz asset then create all the materials and the rig. This works fine for small projects or unique scenes, where we want all the assets in the same scene. This also does work for large projects where we rather link or append data from multiple files, but of course all the local resources are also duplicated this way.

example use case:

1. in a new scene import a figure and save the blend file
2. in a new scene import another figure and save the blend file
3. in a new scene link the two figures above and make overrides

If we look at the local database in the outliner we see all the daz groups are duplicated, as well as the custom shapes and the local resources in general, because they reference the source files so "daz diffuse" in figure 1 is different from "daz diffuse" in figure 2.

A better approach would be to use a blend file to collect all the daz resources, as material groups or custom shapes for example, then we link the daz resources from there so when we import a daz asset it will use the daz resources. This way when we link assets in the scene the daz resources will not be duplicated.

To create material groups: setup > materials > debug > make shader groups

example use case:

1. in a new scene create all the material groups and save as daz_resources.blend
2. in a new scene link the daz resources and save as startup file
3. in a new scene import a figure and save, this will use the linked daz resources
4. in a new scene import another figure and save, this will also use the linked daz resources
5. in a new scene link the two figures above and make overrides

Now there's no duplicates.

Note that daz resources can also be used to replace the standard diffeomorphic resources with custom ones. For example if we want to create a custom "daz diffuse" group we can edit it leaving the same name and channels, this way diffeomorphic will reference the custom group when importing daz assets.

This also has some drawbacks though, for example the daz groups could change among different diffeomorphic versions. This means, as a rule of thumb, never import daz assets when a old scene is already loaded, otherwise the old groups are used. While we can always link assets from different versions of diffeomorphic and they will work fine.

Diffeomorphic Add-ons Version 4.5.0 Released

Version 4.5.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/hp422s4cibjtofs0w41v0/import_daz-4.5.0.zip?rlkey=48iudwd2yea9y1vw51hixzxpw

MHX Runtime System: https://www.dropbox.com/scl/fi/y4foq3hjg8i23qozdcuyo/mhx_rts-4.5.0.zip?rlkey=n15uyij9ouoclmaqqmpe5tq92

BVH and FBX Retargeter: https://www.dropbox.com/scl/fi/z140z8ai58zw89zv1cl2e/retarget_bvh-4.5.0.zip?rlkey=1cs5th0jau8tm12dc1a6ofhb3

The add-ons have been tested on Blender 4.5 and 3.0, and should run on intermediate Blender versions as well.

This is mainly a bugfix release in order to keep in sync with Blender versions. However, there are some new features:

• Better support for UTF-16 (Chinese and Japanese characters)
• The Retarger editing functions have been replaced by animation layers.

Animation Layers

After we have imported a mocap animation we usually have to edit it. There are many reasons for this: the mocap data is faulty, it doesn't fit the target character, it doesn't quite do what we want, etc. The BVH and FBX retargeter had some tools for this, but they were quite clumsy and incomplete. The natural way to edit animations in a non-destructive way would be to use animation layers, but I didn't think Blender had those. However, Alessandro pointed out that Blender always have had animation layers, but they are hidden inside the NLA editor and a bit inconvenient to use. So I decided to replace the old edit tools with animation layers, taking inspiration from this video.

Here we have imported a walk animation from ACCAD. A common problem with retargeting such files is that the collar bones tend to slope. To fix this, we add a new animation layer by pressing the plus button in the Animation Layers panel.

This creates two animation layers: the base layer which is the original animation, and a second layer where we can modify the animation.

Behind the scenes we have converted the original animation to an NLA track, and added a new empy animation on top of that. The NLA tracks can be disabled, but the last layer is always the current action.

If we now add keyframes to the collar and shoulder bones at one frame, the animation is modified at all frames.

The total animation now consists of an action and a number of NLA tracks. If we need it to be a single action, e.g. in order to export it to games, we can use the Bake Animation Layers button.

After baking animation layers, the layers list is cleared, but the animation remains the same.

The tracks are gone from the NLA editor, and only a single action remains.

Scanning the DAZ database is now obsolete

 I'm a Windows user myself, but the DAZ Importer still runs on Linux. The problem with Linux is that its file system is case sensitive, so e.g. Runtime/Textures and runtime/textures are different directories on Linux, whereas they are the same on Windows. To deal with these problem we previously had to scan the entire DAZ database, cf the post on Linux Revisited. Alas, this led to several problems. Scanning the database could take considerable time if many DAZ assets have been installed. Moreover, scanning is error prone because if you add new assets, they will not be found unless the database is rescanned.

Fortunately, these are now problems of the past. In the last commit, the relevant paths are scanned on the fly, meaning that a separate scanning step is obsolete. Having to look at several locations for an asset does have a price, but it seems to be a modest one. My initial tests indicate that importing files with "Case-Sensitive File Paths" enabled increases the load time with about 10%.

And please note that this is only an issue under Linux. Under Windows, and I believe Mac as well, file paths are case insensitive so the issue never arises.

Importing DBZ Files Directly

Getting the DAZ Importer up and running is a bit more complicated then using a normal importer. We must Copy Scripts folder to DAZ Studio, Save Scene in DAZ Studio, and Export To Blender. Those are the steps that any export script would need to do. But the DAZ Importer also required two extra steps, Save the DAZ root paths in DAZ Studio, and also Setting up the DAZ root paths in Blender. Those steps are necessary because the DAZ assets are not stored in the duf file. Instead the duf file contains pointers to the actual assets relative to the root paths. So knowing the root paths is necessary to find the assets.

However, the extra steps have been automated in the development version, which means that the DAZ Importer behaves more like a normal importer: export the dbz file from DAZ Studio and import it into Blender. The root paths are stored inside the dbz file, provided that you copy the latest version of the Export To Blender script a the DAZ Studio scripts folder. Older dbz files can also be imported, but in that case the root paths must be set up correctly first.

When we now press Easy Import DAZ or Import DAZ Manually, we notice two differences:

• The file list contains dbz files instead of duf files and pictures.
• The Mesh Fitting option is gone. 
  

The default root paths are probably not correct. Previously we had to set up the root paths manually, or export the root paths from DAZ Studio and load them into Blender. This is no longer necessary if we use the latest version of the Export To Blender script, because the root paths are now stored inside the dbz file. If we import an older dbz file it is still necessary to set up the correct root paths.

After the dbz file has been imported, the root paths are updated.

There are two new global settings that control the behaviour.

• Only DBZ Files. If disabled the file selector looks like it used to, showing duf and dsf files and images. The Mesh Fitting option is also shown.
• Root Paths From DBZ. If enabled the plugin uses the root paths in the dbz file, otherwise the root paths in the global settings are used.

Here is the file selector if DBZ Files Only is disabled. The file selector contains duf files and pictures. The Mesh Fitting options are shown.

Documentation as PDF Files

The documentation for the diffeomorphism add-ons are now available as pdf files, which can be used offline. All internal links have been removed because I didn't manage to make them work, but external links are fine.

DAZ Importer:
https://www.dropbox.com/scl/fi/p3dkh2zci2ffda8w4wkts/import_daz_wiki.pdf?rlkey=awngxzow98xrcmxaxph9he8l8&st=8r05k9e6

MHX Runtime System:
https://www.dropbox.com/scl/fi/l2d628xbkci8lkbxdl7tq/mhx_rts_wiki.pdf?rlkey=evuhhcwlv802lgvq5tly4gpy6&st=1srj059w

BVH and FBX Retargeter:
https://www.dropbox.com/scl/fi/vwu6qatiq1vtscf7508eb/retarget_bvh_wiki.pdf?rlkey=a4923d1kcm1qanxga9tu1vbxn&st=vagjam9z

Diffeomorphic Add-ons Version 4.4.0 Released

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

• DAZ Importer: https://www.dropbox.com/scl/fi/ikl7ewt2vyry4yokmexee/import_daz-4.4.0.zip?rlkey=6icungsgz5e2jf1xrfp4tu6a1
• MHX Runtime System: https://www.dropbox.com/scl/fi/wr5pe0azugvoqwx071uy1/mhx_rts-4.4.0.zip?rlkey=yj839xajudf5rzeuln9l4u1vi
• BVH and FBX Retargeter: https://www.dropbox.com/scl/fi/jp7t4j6q9r00y0b7ufhxx/retarget_bvh-4.4.0.zip?rlkey=aecabc76pafykzqh54m9d6y1v&st=ap5ywyda

The previous stable version 4.3.0 does not work with Blender 4.4 due to an API change.

Apart from working with Blender 4.4, there are also many bugfixes and some other changes.

• Internal data used by the DAZ Importer have been moved to a single complex property, to avoid unnecessary cluttering of the custom properties (http://diffeomorphic.blogspot.com/2025/01/custom-properties-cleanup.html).
• Improvements to Rigify, both for animals (https://bitbucket.org/Diffeomorphic/import_daz/issues/2350/implement-rigify-conversion-for-daz-dog) and adding extra Rigify bones (http://diffeomorphic.blogspot.com/2025/02/adding-extra-bones-to-rigify.html)
• Scripting improvements (http://diffeomorphic.blogspot.com/2025/03/scripting-improvements.html)

Scripting Improvements

I have spent a log of time developing the DAZ Importer plugin, but I rarely use its scripting capabilities. However, every button becomes an operator that can be called from a script; a list of operators defined by the DAZ Importer can be found here. These operators are defined automatically and usually work out of the box, but there are some caveats regarding operators that act on multiple files, morphs or shapekeys.

Assume that we want to import a figure with Easy Import. We select the duf file (or the corresponding .png or .tip.png file) and press Easy Import DAZ. To do the same thing programatically, we could expect that the following script would work: 

bpy.ops.daz.easy_import_daz(
    filepath = "D:/home/scenes/victoria-rocker.duf"
)

However, nothing is imported. The reason is that the Easy Import tool can import several files at once. If we select the following three files, three different figures will be imported at once.

And here are the figures in Blender.

Importing multiple character in one stroke may not seem very useful, but we may want to import thirty different props from a single directory, and then it is easier to ímport thirty files at once than to press the Easy Import button thirty times and only import a single prop each time.

The old way to import multiple files uses the api.set_selection function, which needs to be called before easy_import_daz is invoked. Functions defined by the DAZ Importer plugin are documented here.

import bpy
from bl_ext.user_default.import_daz import api

api.set_selection([
    "D:/home/scenes/aiko-basic-wear.duf",
    "D:/home/scenes/victoria-rocker.duf",
    "D:/home/scenes/michael-basic-wear.duf"])
bpy.ops.daz.easy_import_daz()

Unfortunately, this does not work very well. Under the hood the set_selection function sets a global variable, and this leads to complications for operators that invoke other operators, like easy_import_daz does. Recently I learned from Rakete that there is another way to access multiple files which does not involve any global variables.

When a file selector exists, it sets two keyword arguments: the StringProperty "directory" and the CollectionProperty "files". An alternative way to import multiple files is like this:

bpy.ops.daz.easy_import_daz(
    directory = "D:/home/scenes",
    files = [{"name" : "aiko-basic-wear.duf"},
             {"name" : "victoria-rocker.duf"},
             {"name" : "michael-basic-wear.duf"}])

Actually, importing files in this way has always worked, but I was not aware of it. The "files" argument is a bit complicated; it is a list of dicts with the "name" keyword, which is how we specify a CollectionProperty in scripts.

To import a single file we simply let "files" be a list with a single argument.

bpy.ops.daz.easy_import_daz(
    directory = "D:/home/scenes",
    files = [{"name" : "victoria-rocker.duf"}])
    
This way of importing multiple files is not limited to Easy Import. The following script imports three poses to the active object. The second line turns on automatic keying.

import bpy
bpy.context.scene.tool_settings.use_keyframe_insert_auto = True
folder = "/people/genesis 8 female/poses/base poses/"
files = ["base pose kneeling a.duf",
         "base pose kneeling b.duf",
         "base pose kneeling c.duf"]         
bpy.ops.daz.import_pose(
   directory = api.get_absolute_path(folder),
   files = [{"name" : file} for file in files],
)

This script imports three poses to consequtive frames. 

Many tools opens another type of selector, which lets us select which morphs to import, which shapekeys to transfer, which materials to modify, etc. Such selections used to be made with the api.set_selection function as well, but now the preferred way is to use the "selection" keyword. Again the argument is a CollectionProperty, which corresponds to a list of dicts with the "name" keyword in scripts.

The following script import three units morphs:

files = ["eCTRLEyesClosed.dsf",
         "eCTRLEyesClosedL.dsf",
         "eCTRLEyesClosedR.dsf"]
bpy.ops.daz.import_units(
    selection = [{"name" : file} for file in files]
)

It is thus equivalent to the following selection in the Import Units dialog.

If the "selection" keywprd is omitted, or equivalently if selection = [], all elements are selected. Thus the line

bpy.ops.daz.import_visemes()

imports all available viseme morphs. We can then set the corresponding rig properties.

rig = bpy.context.object
rig["eCTRLvAA"] = 1.0
rig["eCTRLvOW"] = 0.4

Mathjax Test

The formulas in the header.

\[\begin{align}
[{\cal L}_\xi, {\cal L}_\eta] &= {\cal L}_{[\xi,\eta]}
 + {1\over{2\pi i}}\int dt\ \dot q^\rho(t)
 \Big( c_1\ \partial_\rho\partial_\nu\xi^\mu(q(t))\ \partial_\mu \eta^\nu(q(t))\ +\\
& \qquad\qquad\qquad +\ c_2\ \partial_\rho \partial_\mu \xi^\mu(q(t))\ \partial_\nu \eta^\nu(q(t)) \Big),\\
[{\cal L}_\xi, q^\mu(t)] &= \xi^\mu(q(t)), \\
[q^\mu(t), q^\nu(t')] &= 0. 
\end{align}\]

If you use Firefox with NoScript, as I do, you need to whitelist jsdelivr.net and polyfill.io, otherwise only the uncompiled LaTex code will show up.

If anybody wonders, this is the Virasoro-like extension of the diffeomorphism algebra in multiple dimensions. e.g. on the \(d\)-dimensional torus. When \(d=1\), both terms proportional to \(c_1\) and \(c_2\) reduce to the ordinary Virasoro algebra on the circle, a piece of mathematics that is popular e.g. in string theory and statistical physics. By the way, I discovered the \(c_2\) term myself a long time ago, which is something that I am still proud of (\(c_1\) was discovered by Rao and Moody).

When I started this blog almost a decade ago I had planned to write about this and how it in my opinion fits into physics, hence the name of the blog. I never got around to do that, but that might change in the future.

 

Adding Extra Bones to Rigify

Some character have non-standard bones, e.g. a rigged hair. When we convert such a rig to Rigify, the rigified rig contains those bones, but they may be inconvenient to pose individually.

 

Here we have a figure with a rigged ponytail. The ponytail bones belong to the Custom collection.,

And here the rig has been converted to Rigify, with the hair bones still in the Custom collection. Posing each of hair bone individually can be done but is inconvenient.There are a few things that we can do to make it easier to pose the ponytail.

We can Add IK Goals. This tool is located in the Rigging > Chains panel which requires that the Rigging Tools feature is enabled.

Alternatively, we can Add Winders.

However, Rigify is a modular rigging system and we may want to use some of the Rigify types. Previously that has not been so easy to do. In principle we can first generate the metarig, then add the custom bones to it, and finally rigify the modified metarig. However, that requires further postprocessing because the vertex groups must be renamed. In the last version of the DAZ Importer there is a much simpler way. Just select a bone in the original DAZ rig and add a Rigify type to it.

Let us give the ponytail the control of a basic Rigify tail. Select the bone that we want to be the root of the tail, and assign a suitable Rigify type to it. Here we choose spines.basic_tail.

The Rigify Type panel contains various option for the bone chain. By default a basic tail can only bend along the X axis.

Once a bone has been assigned a Rigify type, it is added to the metarig together with its descendants. Any parent bones that are not part of the standard Rigify armature are also added.

Now the rigified armature has a ponytail with the extra control bones.

The entire ponytail can now be posed by rotating the target bone at the end of chain.

MHX Properties are now ID Properties

As discussed in the post on Custom Properties Cleanup, custom properties used by the DAZ Importer are now combined into a single, complex property. However, there are two exceptions:

1. Morph properties, because they are part of a web of drivers that would not be evaluated in the correct order if they were parts of a complex property.
2. Properties that need to work when the add-on is disabled, e.g. at a render farm.
   

 The custom properties used by the MHX rig belong to the second category. 

There are two types of custom properties in Blender:RNA properties and ID properties, or properties that are defined by the system or by add-ons and those that are created on the fly. The problem with RNA properties is that they do not work properly if the add-on is disabled. MHX properties have nevertheless been implemented as RNA properties, because ID properties did not worked with file linking in some earlier  version of Blender. This problem has been fixed in recent Blender versions, and therefore there is no reason to use RNA properties anymore.

This change should be backwards compatible, almost. Even if the MHX rig was created in an earlier version of the DAZ Importer, where the MHX properties were RNA properties, it should still function correctly with the latest version. This works because RNA properties are automatically converted to ID properties if the API no longer defines them. The only thing that does not work is animations with dynamic FK/IK switching.

Here are the custom properties of a recent MHX rig. The MHX properies begin with "Mha" (there was a reason why they don't start with "Mhx", but I don't remember why anymore). Note the cogwheel to the right of the property value. This indicates that we deal with ID properties rather than RNA properties, which would have "API Defined" written to the right instead. 

Pressing the cogwheel brings up the Edit Property window. Note that MHX properties are Library Overridable at the bottom of the window.

Save the scene with the MHX rig, open a new file, and link the collection with the MHX character into the new scene. To make the character useful in the new scene, choose Object > Library Override > Make.

We can still access the custom properties, but they can not be edited. When we change a linked property it turns green.

Now do the following steps:

1. Create an animation and save the file.
2. Disable the DAZ Importer and MHX RTS add-ons.
3. Restart Blender.
   

 We have now recreated the situation at a render farm, where the DAZ Importer and MHX RTS are not available. Nevertheless the animation works correctly, including the animation of custom properties needed e.g. for FK/IK switching.

Custom Properties Cleanup

The DAZ Importer creates lots of custom properties when a character is imported. These properties contain information from the duf file which is necessary for the proper function of other tools.

The add-on does not only create lots of object properties, but custom properties for meshes, materials, bones and posebones as well.

However, spamming the area with lots of custom properties is considered impolite and is frown upon. Other add-ons such as Rigify or MMD tools create a single custom property which contains all the needed information in a complex data structure.

Rigify only creates one object property and one armature property.

 

In the last commit the custom properties have been redesigned, and now the DAZ Importer also adds a single custom property. This probably comes with a small performance penalty, because accessing the data of a complex property takes more time than accessing simple properties. However, this effect should be neglible.

Care has been taken to make this change backward compatible, so old files should still work without modification. However, it is not forward compatible, so figures imported with the latest version will not work propertly in older versions of the DAZ Importer.

The Utilities panel has a new subpanel, called DAZ Importer Properties, where the components of the custom properties can be inspected. This is mainly for debugging purposes. The listing also indicates whether objects use the modern, single, complex property, and the legacy multiple, simple properties.

However, there are some situations where simple properties are still needed. One is if the figure should work correctly even if the DAZ Importer add-on is disabled or not even installed. A typical situation is if we make an animation with Simple IK and FK-IK switching. The animation should still work properly if the file is sent to a render farm which has not installed the DAZ Importer. This will work because the Simple IK properties are simple properties.

The MHX rig does not work by default if the MHX runtime system is disabled. The reason is that MHX uses RNA properties rather than ID properties, for reasons explained here. To make it work at a render farm the file properties.py  in the runtime folder must be saved with the blend file, in the same way as the file morph_armature.py must be loaded to make morping armatures work without the DAZ Importer. This is inconvenient and I intend to replace MHX RNA properties by ID properties in the future.

Finally, there is an important type of custom properties that must be simple propertes: morphs. In Blender morphs are implemented as object and armature properties that drive bone rotations, shapekeys and other properties. Morph properties can not be part of a single, complex property. That would slow down the evaluation of morphs, which already can take excessive time if many morphs are loaded. Even more importantly, it wouldn't work at all, because the morphs might evaluated in the wrong order. 

Morph properties are connected with a complex web of drivers, and it is crucial that the morphs are evaluated in the right order. This is guaranteed if the morph properties are simple properties.. There would be no such guarantee if they were parts of a complex property, and in fact that is not always the case. Besides, the morphs should work if the DAZ Importer is not enabled, otherwise we would end up with ugly faces.

So unfortunately the add-on is still flooding the custom properties if a figure has many morphs. I don't see any way around that.

Viewport Performance

DAZ meshes can be quite heavy and can slow down the viewport. Genesis 9 is worse than older generations, but clothes and especially hair can have a much higher poly-count. Add subdivisions, hair, drivers, etc. and viewport performance could become much worse.

Here are some suggestions for improving viewport performance. The suggestions are discussed in more detail below.

• Use solid view instead of rendered view.
  
• Turn on simplify and set max viewport subdivisions to zero.
• Disable drivers when when you pose, enable them when you work with morphs. The plugin can easily create hundreds of drivers that take a lot of time to update (Morphs > Disable Drivers).
• Add shapekey mute drivers to disable shapekeys with zero value.
  
• Put heavy meshes in separate collections that can be excluded during posing. Hair can be especially heavy.
• Put objects that are not in view in separate collections.
• Finalize meshes and armature in the Finishing panel. This removes some data that is needed for adding morphs etc., but improves viewport performance.
• Add a mannequin to block the animation. This a collection of meshes that are bone parented, which performs much better than a mesh with vertex groups.

This post will be updated include other optimization techniques.

Solid view instead of rendered view

This is sort of obvious. Even textured mode is more costly than material mode.

Simplify

The Simplify tab contains Blender's native tools for improving viewport speed. Usually we don't need to see subdivisions in the viewport. There is a global setting that limits the number of subdivision levels when DAZ scenes are imported, both the viewport and render levels.

 

The texture limit speeds up rendered view. However, the large textures may still take a lot of time to load, because Blender has to load the full texture before it can apply limitations. The Resize Textures tool permanently replaces textures with lower-resolution ones. Note that textures must be saved locally before they can be resized.

 

Disable drivers

Morphs are implemented in Blender as a complex web of drivers that control bone rotations and locations, mesh shapekeys, and custom properties. A DAZ figure with the standard morphs loaded can easily have many hundreds of drivers, and the evaluation of many drivers takes significant time.

The Disable Drivers button at the top of the Morphs panel disables all morph drivers, thus eliminating the need to compute the drivers. Shapekeys are also muted.

When the drivers are disabled the morphs do not function, and the Morphs panel only contains a button to Enable Drivers again

 

Shapekey mute drivers

DAZ figures often have many shapekeys, e.g. for JCMs and FACS morphs. The evaluation of those shapekeys takes time, but it is unnecessary to include zero shapekeys in the process.

The global option "Shapekey Mute Drivers" adds drivers to the shapekey enable channel, muting the shapekey if it is zero (within rounding errors). Muted shapekeys are not included in the evaluation of the final vertex locations which should lead to a performance gain.

When "Optimize JCM Drivers" is enabled some drivers related to JCMs are eliminated.

 

Separate collections for different meshes

Hair and clothes are often heavier than the figure itself, but are not really necessary when posing. We can put such objects into subcollections that are disabled during posing and only enabled again when it is time for rendering.

Here is Aiko with hair and clothes. Hair and clothes have been put into separate collections.

Here the hair and clothes collections are disabled. This does not really hamper posing.

 

Finalize meshes and optimize drivers 

The Finishing panel contains some buttons that can improve performance. However, this should be done as a final step when the figure setup is finished.

• Finalize Meshes: Removes internal properties from meshes, needed e.g. to merge geografts.
• Optimize Drivers: Optimize the web of drivers. New morphs can not be loaded afterwards. 
  

The Final Optimizations option in Easy Import tool does the same thing.

 

Mannequins

A mannequin is a collection of meshes that are parented to the bones of the armature. This improves performance because bone parenting can be evaluated much faster than the influence of multiple vertex groups. Mannequins are useful for blocking out an animation, even if final tweaking with the real mesh may be necessary. The DAZ Importer can create a mannequin for a selected set of meshes.

To create a mannequin, select the meshes and press "Add Mannequin". This tool requires that the Object Tools feature is enabled.

The original meshes are put into a subcollection called "Meshes", and the mannequin meshes belong to the new "Mannequin" collection. We can now pose the figure with the mannequin enabled, and switch to the original meshes for final tweaking and rendering