Identifying assets in DSON files

I'm trying to import DSON files in my own (Python) software, but I can't figure out how asset IDs work in advanced cases.

I have a scene with two G8M figures using the same Modifier, but although the modifiers' parent is overridden to be assigned to the right NodeInstances (of both the figures), the SkinBinding it contains still references the base Node and Geometry. I'm not sure how to translate that to the NodeInstance and GeometryInstance of the figures they belong to.

To illustrate this, I copied the relevant parts of the DSON file below.

So my example scene has only two G8M figures, labeled "JOHN" and "ROBIN". In the DSON file, both of them are NodeInstances based on the Genesis8Male.dsf#Genesis8Male figure and Genesis8Male.dsf#geometry geometry. No problems there. Both figures them have a SkinBinding modifier based on Genesis8Male.dsf#SkinBinding. The parent values (Genesis8Male.dsf#geometry by default) are overridden to #geometry (for John) and #geometry-1 (for Robin). Thats where my question starts.

In both cases, the inherited skin binding modifier still references the #Genesis8Male node and the #geometry geometry from the Genesis8Male.dsf file. These URLS are not overridden in the example.duf file. So how would I use those Uris to reference the NodeInstance and Geometry of "John" and "Robin"? 

Relevant parts from my example.duf file:

{
    "asset_info": {
        "id": "/C%3A/Example.duf"
    },
    "scene": {
        "nodes": [
            {
                "id": "Genesis8Male",
                "url": "/data/DAZ%203D/Genesis%208/Male/Genesis8Male.dsf#Genesis8Male",
                "name": "Genesis8Male",
                "label": "JOHN",
                "geometries": [
                    {
                        "id": "geometry",
                        "url": "/data/DAZ%203D/Genesis%208/Male/Genesis8Male.dsf#geometry",
                        "name": "Genesis8Male"
                    }
                ]
            },
            {
                "id": "Genesis8Male-1",
                "url": "/data/DAZ%203D/Genesis%208/Male/Genesis8Male.dsf#Genesis8Male",
                "name": "Genesis8Male",
                "label": "ROBIN",
                "geometries": [
                    {
                        "id": "geometry-1",
                        "url": "/data/DAZ%203D/Genesis%208/Male/Genesis8Male.dsf#geometry",
                        "name": "Genesis8Male"
                    }
                ]
            }  
        ],
        "modifiers": [
            {
                "id": "SkinBinding",
                "url": "/data/DAZ%203D/Genesis%208/Male/Genesis8Male.dsf#SkinBinding",
                "parent": "#geometry"    (--> Overrides the parent from the referenced file)
            },
            {
                "id": "SkinBinding-1",
                "url": "/data/DAZ%203D/Genesis%208/Male/Genesis8Male.dsf#SkinBinding",
                "parent": "#geometry-1"  (--> Overrides the parent from the referenced file)
            }
        ]
    }
}

Relevant parts from the Genesis8Male.dsf file:

{
    "asset_info": {
        "id": "/data/DAZ%203D/Genesis%208/Male/Genesis8Male.dsf"
    },
    "geometry_library": [
        {
            "id": "geometry",
            "name": "geometry"
        }
    ],
    "node_library": [
        {
            "id": "Genesis8Male",
            "name": "Genesis8Male",
            "type": "figure",
            "label": "Genesis 8 Male"
        }
    ],
    "modifier_library": [
        {
            "id": "SkinBinding",
            "name": "SkinBinding",
            "parent": "#geometry",  (--> Overriden in the example file, see above)
            "skin": {
                "node": "#Genesis8Male",  (--> NOT overridden. How to interpret this to link to Johns/Robins figure?)
                "geometry": "#geometry",  (--> NOT overridden. How to interpret this to link to Johns/Robins geometry?)
                "joints": [
                    {
                        "id": "lIndex3",
                        "node": "#lIndex3" (--> NOT overridden. How to look in Johns / Robins armature?)
                    },
                ]
            }
        }
    ]
}

 

Comments

  • Richard HaseltineRichard Haseltine Posts: 99,500

    Things are, as far as I know, overridden in the .duf file only if they aer customised - since the skin binding isn't, it's the same (derault) for both figures, there's no override and it doesn't matter 9at least for DS) which figure is which for that purpose.

  • bt7640dj33bt7640dj33 Posts: 0

    Thank you for your quick answer, Richard.

    I realise that the skin modifier has no overrides because it doesn't need customisation. But still, without those overrides it only tells me that it describes a skinbinding between some armature based on the (Genesis8Mal.dsf)#Genesis8Male definition and some geometry based on the (Genesis8Mal.dsf)#geometry definition. The only link I have to an actual instance is in the surrounding SkinBinding modifier: It's parent attribute is overridden and pointing to Johns' geometry in the fist case and Robins geometry in the second case (and its required to override parent to a concreate instance, as it says here).

    So to apply the skin binding to the right object instances, I guess I would need to:

    1. follow the modifiers' parent link to get to the right geometry instance (say: John's), then
    2. use the parent of that geometry to get to its armature;
    3. then, to apply the skinbinding(s) that have not overrides, I guess i would need to seach the first geometry (within John) that inherits from Genesis8Male.dsf#geometry, the first armature instance (within John) that inherits from Genesis8Male.dsf#Genesis8Male (which, I think, will always be the armature from (2)), and for each joint: the first bone instance (within John's armature) that inherits from Genesis8Male.dsf#lIndex3 and so forth.

    But to do the last step, I would need to not only keep track of the asset ids during loading a file, but also of their inheritance trees, e.g. the facts that:

    • example.duf#Genesis8Male instance inherits from the Genesis8Male.dsf#Genesis8Male definition, inherits from ... (*);
    • example.duf#Genesis8Male-1 instance inherits from the Genesis8Male.dsf#Genesis8Male definition;
    • example.duf#geometry instance inherits from the Genesis8Male.dsf#geometry definition;
    • example.duf#geometry-1 instance inherits from the Genesis8Male.dsf#geometry definition;
    • example.duf#lIndex3 instance inherits from the Genesis8Male.dsf#lIndex3 definition;
    • example.duf#lIndex3-1 instance inherits from the Genesis8Male.dsf#lIndex3 definition;

     (*) since Node definitions can have a source of their own, these inheritance trees might be of arbitrary depht I think.

    But is this really needed? It seems overly complicated... But I did see that DzNode has an assetIdAliases property which stores "The asset id aliases for this node". This could serve a purpose like this, although my understanding was that ID attributes are only used during file loading and not stored anywhere in the objects...

    I hope you can shed a light on this! Thanks in advance.

  • Richard HaseltineRichard Haseltine Posts: 99,500

    I'm sorry but I don't think i can add anything useful. The assetID, and other asset members, on nodes refer to the Content Management System and so would prsumably be the same for two Genesis 8 Male figures.

  • bt7640dj33bt7640dj33 Posts: 0

    No problem, thanks for your input.

    I know skin modifiers can contain a lot of data, so I can imagine they are shared among instances, but in the end I do need to apply them and create weightmaps for the concrete instances (of geometry, armature, bones) they're targeting.

    In general, it would just be nice to understand how asset IDs are supposed to be used during load (or: how DS uses them) and more specific, if I should keep track of the instance/definition(s) hierarchy in order to apply modifications to the right instances of geometry, armature and bones. It's the only implementation I could think of right now, but maybe I'm missing something. Anyway, thanks again.

Sign In or Register to comment.