Latest Dev Build Fails

[Midnight Arrow]

Just tried a fresh install of both Blender 4.2.1 and the importer, both downloaded literally 10-15 minutes ago. The addon got stuck in an infinite loop when I ticked the button in the menu to enable it, forcing me to kill Blender.

I fell back to the stable branch and it worked as expected.

Steps to reproduce:

• Download current Blender build
• In Preferences, add a new script directory
• Download current Diffeomorphic build
• Unzip Diffeomorphic to new script directory
• Enable the addon

‌

[Thomas Larsson]

This probably happens because the daz importer is now an extension rather than a legacy addon, cf the post on Blender Extensions and GPL.

1. Disable all diffeo addons.
2. In the Blender/4.2 directory, delete all diffeo addons, both from the addons and the extensions directories, if those exist.
3. In the Get Extensions tab, install the zip file from disk.

The addon now appears in the new extensions/user_defined folder, not in the old scripts/addons folder.

‌

[Midnight Arrow]

This is my first time using 4.2 and extensions, so I’ll stay on the stable version until I look into how to setup a custom extension folder.

But if you try and load an extension as an addon, surely it should fail with an error message rather than freeze Blender? Unless that’s Blender doing that for all addons.

[Alessandro Padovani]

I’m installing as addon and works fine here.

steps:

1. unzip and rename as “import_daz“
2. copy in the blender addons folder

‌

[Midnight Arrow]

Tried it again. The console is just hanging on “Register Daz Importer”, so the error has to be somewhere between that and the next print statement.

[Midnight Arrow]

On a hunch, I copied the addon folder to Blender’s default addon directory, “Blender 4.2\4.2\scripts\addons_core”. This time it worked.

But I don’t use the default addon directory, so this is still a bug.

[Thomas Larsson]

The daz importer now prints a line for each module that it registers, so the text in the console should now be:

DAZ loaded
Register DAZ Importer
  Register driver
  Register uilist
  ...
  Register gaze
  Register scan
Load settings from C:/Users/Comsol/Documents/DAZ Importer/import_daz_settings.js
on
Absolute paths loaded from C:/Users/Comsol/Documents/DAZ Importer/import_daz_sca
nned_absolute_paths.json

Perhaps that can pinpoint what goes wrong.

[Alessandro Padovani]

May be Midnight is trying to install the zip as addon instead of extension, which can’t work because of the manifest file. The zip is packaged as extension so to install as addon you go by hand. Or install as extension.

In any case since we have to rename the folders it makes little sense to install the zip.

[Thomas Larsson]

No, an extension does not have to be renamed, only legacy addons. The correct name of the addon is defined in the manifest file. Besides, renaming addons is only necessary if we want to use one of the dependent addons, or if we want to access the addon from a script, and the normal user probably doesn’t either.

[Alessandro Padovani]

I disagree that the common user doesn’t need the extra addons, as retargeting and exporting back to daz are very common operations. Also 2.9 and 3.6 are supported which require legacy addons, thus renaming the folders.

May be you can consider merging back the retarget and the exporter to the main importer addon, which would simplify the installation.

[Thomas Larsson]

The bvh retargeter is a stand-alone addon and has nothing to do with the daz importer. The preset exporter is dependent, and I think that was a mistake. I’ll remerge it with the main daz importer addon. The other two addons are probably not used by anobody but myself, and it may have been a mistake to make them publicly available.

[Jasper29]

I personally like the other addons, Thomas, options are great. Also, when installing the newest Diffeo builds as an extension, it already renames the folder ‘import_daz’ in user defaults.

[Alessandro Padovani]

But the retargeter is necessary to import FACS animations, which is a daz feature, also it’s specific for genesis figures it’s not general purpose, so makes little sense as a separate addon as it can’t work alone. In this sense it is essential to use the importer not an option and would make sense to merge. Of course just my opinion.

[Thomas Larsson]

Yes, but the retargeter can be enabled without the daz importer, unlike the daz exporter. The reason for the dependence is that I was lazy and didn’t want to duplicate code that the exporter needs and is already present in the importer. In retrospect it would probably be better to do that duplication anyway, considering the confusion that the inter-addon dependency creates.

The facs code was moved when Bouich pointed out that facs animations are distributed as fbx files too. The retargeter does fbx but the importer doesn’t.

[KD]

Surely duplicating code would increase the effort to maintain, if edits are needed in that code. With such fast-paced development occurring, you might be better off merging addons which have any cross-dependencies, streamlining dev efforts.

If there is a desire to have separate addons for character setup and runtime, you might need three repos: one for all the shared code (like a library without a UI), one for setup UI and one for runtime UI.

[Midnight Arrow]

It crashes in “Register main”. After taking a quick look through the code, it might have something to do with copyPresets(), which looks like it’s been hardcoded under the assumption it will always be installed in the default addon folder, rather than a custom addon folder.

The stable version works fine using this same method, though.

I’m coding a custom import pipeline, so I actually do need to be able to call the functions from a Python script. The stable version works fine for my purposes right now, so it’s not a big deal.

“In retrospect it would probably be better to do that duplication anyway, considering the confusion that the inter-addon dependency creates.”

I’ve actually been tinkering with the DSON format lately. Here’s an idea: how about instead the import-export features become a purely Python module? A self-contained black box which processes a DUF/DSF file and returns a Python object you can query for properties and data arrays. Then all the addons can rely on that centralized module instead.

I attempted something similar recently, and I understand the DSON format pretty well now, so I’d be glad to contribute.

[Thomas Larsson]

I’m not sure how you could install the addon in a non-standard location and still make Blender recognize it, but anyway. In the last commit the infinite loop in copyPresets is avoided. If the top addon directory isn’t found the factory presets are just not copied, which isn’t a big deal I guess.

[Midnight Arrow]

You add script directories in the preferences menu:

https://docs.blender.org/manual/en/latest/editors/preferences/file_paths.html#script-directories

[Thomas Larsson]

The export addon has been merged with the importer again. The exporter has been disabled, so if you update both addons there won’t be any name clashes. The shell editor and daz rigging addons remain separate. They are more of my own playground where I can add stuff without having to worry about other users (even if Jasper apparently use them).

Having the exporter as a separate addon also generated a lot of warning messages about stuff already being registred in the terminal window. It doesn’t happen for the two other dependent addons. Perhaps it was just a matter of alphabeticall order: export_daz comes before import_daz, but shell_edit and rig_daz come after.

[Thomas Larsson]

OK, thanks. But as I said above, the infinite loop should be gone, and if you use a nonstandard path the factory presets are simply not copied.

[Midnight Arrow]

Still not working.

I used PDB to step through the code. It’s still stuck in an infinite loop.

    while topdir and not topdir[-1].isdigit():
        dirs = os.path.split(topdir)
        if len(dirs) > 1:
            topdir = dirs[0]
        else:
            return

PDB says that topdir is “D:\\” and that topdir[-1] is an escaped slash (“\\”). dirs gets set to the value of (“D:\\”, ““). Since topdir takes the first entry from the array, dirs[0] equals the D: drive again, trapping it in an infinite loop.

[Thomas Larsson]

Now it should be fixed. I hadn’t understood how os.path.split works. And the topdir is now not any directory that ends with a digit, but it has to end with the correct Blender version.

[jeroen b]

Sorry for asking here, but I am confused. Until last weekend I have been working with stable Diffeo version 1.7.3 & Blender 3.6 LTS. Now I upgraded to Diffeo 4.2.0 (stable version) and Blender 4.2 LTS.

I probably missed something, but am I supposed to install Diffeo versions now only as extensions? And when I compare filesizes of the stable versions of the importer vs the dev versions, there are huge differences, how can that be?

BTW, I installed the stable versions in Blenders addons menu and it appears to work just fine.

‌

[Thomas Larsson]

Diffeo 4.2.0 is a legacy addon which is installed in the addons directory. The unstable builds and future 4.2.1 are extensions. At least they are installed in the extension directory if you install from the zip file; if you manually copy the files to the addons directory is is still a legacy addon.

Both the unstable build and stable 4.2.0 are around 1.5 Mb. The stable version at https://www.dropbox.com/scl/fi/5xh2xun51kn3c851y85ju/import_daz_v4_2_0.zip?rlkey=uapugueahv4otj7q07aliocyc. I have no idea why your file is larger, but I notice that the uncompressed folder takes up around 5.8 Mb.

[jeroen b]

Thanks Thomas, all clear now. The strange filesizes are probably just a glitch in Windows or Bitbucket, does not seem to harm anything.

[Midnight Arrow]

I’ve tested the DazAttributes branches, and both of them work fine from a custom directory. Unless there’s some major difference from the master branch I’m not aware of, then it seems like the issue is solved.