None Type error upon committing armature updating actions as a result of Daz importer looking for old shape key data

[Jake]

I’ve now had multiple times the error that ends with “None Type” after converting to MHX or doing some kinds of updates to the body. Importing units while the error is in effect doesn’t give the errors (I got the latest error after I was ready to convert the model to MHX). I suspect that the error is caused by shape keys' drivers that are probably referring to data that no longer exists, because the objects have been appended from another scene or because you imported a new main body from Daz and linked the bugged objects to that, which were connected to the old body originally and because Diffeomorphic is somehow unable to replace that data with new references.

I’ve got it now three times: first time it happened I was clueless as to why it happened, though I suspect it’s because of similar reasons explained in this thread. But the second time I got it, I resolved it by transferring all custom shape keys to a duplicate mesh of the main body and importing fresh JCMs to it again. At the time I had no other driven shape keys, other than the official JCMs, that were driven by the main armature, but rather custom shape keys that were driven by 3rd party objects I had created. Then a third time it happened, because a single shape key’s driver on the main body was somehow broken, though the driver looked absolutely fine (it was referring to an outside object that had no relation otherwise to the main armature). That too got resolved by either A. deleting it and adding the exact same values back or B. copy and pasting the exact same driver on top of the same shape key. The weird thing is that the driver menu screen was showing no errors or missing links when it was bugged.

Now, on my current alternative scene of the main one, that mind you works just fine before I start appending or editing features, I’ve imported some custom clothing that I had linked to a deprecated version of the same scene. So naturally I should just be able to append the collection containing the clothing objects to the new version, then re-transfer morphs from the main mesh to them as I’ve done always without issue, right? Well, I did that on top of the old morphs, but it too was giving me the yadayadayada-None Type error code. The error disappears completely when I delete the collection containing the appended clothing objects, and I reckon it probably doesn’t appear either if I leave the old shape keys' links broken and don’t reference the new armature or just delete the shape keys completely. I’m not sure if it’s just one object or all of them in the collection being affected and also what shape key driver is now acting up, but since there’s so many of them, it’s difficult to determine which of them is causing it. And I suspect it’s the same thing as explained in the previous paragraph.

So now I’ve come to the conclusion that when this appears, Diffeomorphic is trying to find the old data where the shape keys' drivers were linked to, even if you properly replaced them with the new ones from the new main body with transfer shape keys, that is if you appended those objects from another scene or imported a new main body. Not sure if this could be prevented by using the change armature feature that should retarget drivers, which mind you doesn’t work at all, at least the driver retargeting part. It also might be related to the transfer shape keys function somehow or that’s the one that’s broken in some ways. It doesn’t seem to happen with freshly imported objects that never had shape keys or drivers.

I don’t recall this ever happened before Blender 4.0 and I already had a number of hours put into the same scene’s older iterations before it and transferred multiple times new, exact same shape keys on top of old ones. And now I’ve redone the scene from scratch multiple times and yet it’s still giving me the error, now due to multiple reasons. Would really like to get it fixed even if I can get it away for a moment by deleting drivers.

Also, the new “remove corrupted drivers” function doesn’t help when this specific error happens, it just gives the same error when the none type error is present at all, so I don’t think it’s just a part of MHX conversion then but, rather a thing affecting the main armature as a whole. Also, the error code was originally different in 1.7.3. I had it on display in the first thread, but now, it’s saying something about “cleandrivers” at any time the error appears, be it either when converting to MHX or when cleaning corrupted drivers. Here is the new error from 1.7.4:

Python: Traceback (most recent call last):
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\error.py", line 223, in execute
    self.run(context)
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\driver.py", line 1256, in run
    cleanAllDrivers(context.object)
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\driver.py", line 1265, in cleanAllDrivers
    cleanDrivers(ob.data.shape_keys)
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\driver.py", line 1298, in cleanDrivers
    if prop not in trg.id.keys():
AttributeError: 'NoneType' object has no attribute 'keys'

I’ll see if I can find the first thread from 2 weeks ago that had the first error code from v1.7.3.

Edit 2: Actually, it does give me two variations if I use the remove corrupt drivers and convert to MHX. Above is for the remove drivers, this is for converting to MHX:

Python: Traceback (most recent call last):
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\error.py", line 223, in execute
    self.run(context)
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\mhx.py", line 643, in run
    self.convertMhx(context)
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\mhx.py", line 656, in convertMhx
    cleanAllDrivers(rig)
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\driver.py", line 1265, in cleanAllDrivers
    cleanDrivers(ob.data.shape_keys)
  File "C:\Users\yeehaw\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\driver.py", line 1298, in cleanDrivers
    if prop not in trg.id.keys():
AttributeError: 'NoneType' object has no attribute 'keys'

‌

[Jake]

Not exactly certain how this could be replicated though. Maybe importing a body, that has custom shape keys with drivers. Then transferring them to any sort of 3D object in range of the shape keys. And I’m not sure if the bug even happens because of one single driver or as a result of multiple shape keys affecting each other when transferring from main to sub-object (conflict?)

I’ll try experimenting outside of the main scene.

[Jake]

Oh and I still have a copy of the older scene instance, where the single shape key’s driver was causing the error, where removing and readding the same driver fixed it. Not sure if it’s any help.

Though, in that scene’s case, I get this error:

Python: Traceback (most recent call last):
  File "C:\Users\blob\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\error.py", line 223, in execute
    self.run(context)
  File "C:\Users\blob\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\mhx.py", line 643, in run
    self.convertMhx(context)
  File "C:\Users\blob\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\mhx.py", line 656, in convertMhx
    cleanAllDrivers(rig)
  File "C:\Users\blob\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\driver.py", line 1264, in cleanAllDrivers
    cleanDrivers(ob)
  File "C:\Users\blob\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\Diffeomorphic-import_daz-d3d55a6493c3\driver.py", line 1298, in cleanDrivers
    if prop not in trg.id.keys():
AttributeError: 'NoneType' object has no attribute 'keys'

‌

[Jake]

Here’s the original error code that appeared in 1.7.3:

Python: Traceback (most recent call last):
File "C:\Users\HELLO\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\import_daz\error.py", line 223, in execute
self.run(context)
File "C:\Users\HELLO\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\import_daz\mhx.py", line 625, in run
self.convertMhx(context)
File "C:\Users\HELLO\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\import_daz\mhx.py", line 704, in convertMhx
self.fixBoneDrivers(rig, rig, MHX.BoneDrivers)
File "C:\Users\HELLO\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\import_daz\fix.py", line 248, in fixBoneDrivers
changeTargets(ob.data.shape_keys, rig, rig0)
File "C:\Users\HELLO\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\import_daz\fix.py", line 220, in changeTargets
self.changeTarget(fcu, rna, rig, rig0, assoc)
File "C:\Users\HELLO\AppData\Roaming\Blender Foundation\Blender\4.0\scripts\addons\import_daz\fix.py", line 271, in changeTarget
for var in fcu.driver.variables:
AttributeError: 'NoneType' object has no attribute 'variables'

I’m pretty sure this was due to the same issues happening now.

[Jake]

The actual shape of the shape key doesn’t matter, what matters are the drivers on them. And I’m guessing custom, user generated drivers on them.

JCM or FACs are not part of the issue from my current understanding.

[Thomas Larsson]

All errors happen at line 1298 in driver.py, because the target id is not set. In the last commit the plugin tests for that, and if there is no target id the driver is corrupt and deleted.

[Jake]

Is there anything that can even be done about the error, since I doubt these are the only times it’ll happen?

Would it be possible to make it so that daz importer shows what shape keys' drivers are corrupted if nothing else?

[Alessandro Padovani]

@Jake, if you want it fixed it is essential that you can provide the exact steps to reproduce the issue, as simple as possible. Otherwise, of course, Thomas can only catch the error to avoid the crash. Then it may also be that it is your fault when you append or link, if you’re using features not as intended.

p.s. Particularly, I don’t advise to mix blender 3 and 4 scenes with append and link, since blender 4 is fundamentally different. You better keep your old blender 3 projects in blender 3 and make new projects in blender 4, but personally I’d wait 4.2 LTS for that.