Transferring Shape Keys & Technical Debt in the Codebase

I’ve spent a few hours trying to get some code to work properly.

Prior to calling the following function, my code re-opened every object’s DSON file to extract the content_type property (see #2185). This allows me to sort objects programmatically. For my initial tests, I focused on facial attachments. The following function takes the context from the operator, an "Actor" content_type (i.e. a Genesis 8 figure), a list of objects with the "Follower/Attachment/Head/Face" content_type (eyelashes and eyebrows, in this case), and finally the bodypart as an enum string ('Face').

def transfer_shape_keys(context:Context, source:Object, followers:list[Object], bodypart:str) -> None:

    actor_context:dict = context.copy()
    actor_context["object"] = source
    actor_context["active_object"] = source
    actor_context["selected_objects"] = [ source, *followers ]

    mapped_morphs:dict = import_daz.selector.classifyShapekeys(source, source.data.shape_keys)

    morphs:list = list()
    for key in mapped_morphs:
        if mapped_morphs[key] == bodypart:
            morphs.append(key)

    import_daz.set_selection(morphs)
    with context.temp_override(**actor_context):
        bpy.ops.daz.transfer_shapekeys(
            bodypart = bodypart,
            needsTarget = False,
        )

    return

However, this code does not work.

Leaving aside the problem of having to extract the bodypart property from an undocumented internal function (which I touched on in ~~#2186~~), Diffeomorphic’s code has several issues.

Blender allows you to specify a context override (actor_context, above). Essentially, you take the current state of the program and substitute new data for an operator to operate on. In the case of the preceding code, even though nothing is selected in the viewport, the overridden context tells the program to act as if the Genesis figure is the active_object and the follower objects are the selected_objects. This is a documented part of Blender’s Python API, so this functionality should ideally be supported.

https://docs.blender.org/api/current/bpy.ops.html#overriding-context

However, in the case of the Diffeomorphic importer, it creates a copy of the Genesis mesh, named “_TRIHUMAN”, and adds it to the scene so that it can enter into Edit mode. Looking through the code, it seems like after the transfer_shapekeys operator is called, the code then does some global selecting/unhiding. Whatever this does, it appears to circumvent the context override that I created. This causes the operator to complain RuntimeError: Operator bpy.ops.mesh.reveal.poll() failed, context is incorrect and fail.

If I remove the context override (with context.temp_override(**actor_context)), then it works. However, that requires me to select the objects in the viewport like normal, which defeats the purpose of automating the exporter with the content_type property.

Furthermore, I’m not sure what the purpose of the _TRIHUMAN mesh is (there’s no comments, for starters). It seems like it’s used to detect what faces to extract shapekeys from. But Blender has a built-in data structure for that, the BVHTree.

https://docs.blender.org/api/current/mathutils.bvhtree.html

All you need to create a BVHTree is a set of vertices and the vertex indices that constitute its faces. You can just take the shapekey data directly from the base mesh, create a BVH in Python, and use that to detect locations on a mesh without needing to create a disposable _TRIHUMAN object that needs to be added and deleted from the scene tree and which interferes with context overrides.

Currently, the codebase has some major technical debt due to its age (Thomas said it’s ten years old) and not following best/latest practices. Every time I try and follow what it’s doing, the lack of comments and the use of multiple inheritance leaves me confused. So what can be done to fix up the codebase and make it more modular and robust (thereby allowing content_type automation)? Or would it be easier to just restart development from scratch and design it with automation in mind?

Comments (7)