Data Visualization Design Pattern Leveraging 'extras' Attribute

#1

Background: I’m opening up a discussion that will hopefully influence glTF publishers/exporters to consider data visualization requirements with 3D assets. Before opening up the specific issue detailed below with the Blender developers, I wanted to document the issue and get feedback on possible other considerations.

Use Case: 3D visual assets can be ‘data driven’ by data assets made available in at least two primary ways by a rendering engine.

  1. The data assets are statically associated with the 3D asset and incorporated into the glTF file.
  2. The data assets are dynamically associated (by referencing/lookup scheme) with the 3D asset.

This design pattern is used in a prototype application:

In this prototype, individual meshes with individual materials (not shared) are dynamically ‘driven’ with data that corresponds to the 3D images’ sub-components. The 3D images were developed in Blender and then exported with the glTF export tool.

To identify the visual sub-components associated with the data, the ‘extras’ attribute for the meshes were associated with a ‘visualize’ property. That along with the ‘name’ property was sufficient to accurately identify the sub-component and its data association. An good solution for a gen 1 prototype.

Issues/Discussion:

Experimenting with static bound data revealed some issues; at least with Blender. While it supports Custom Properties, it exports a JSON object like the following; in a format that is not immediately parse-able into a JSON object:

        "extras": {
            "visualDatum": "{cost: 5, price:8}"
        }

visualDatum’s value is a string which is not parse-able with modern browsers’ JSON method because the property names are not within double-quotes.

Recommendation(s):

  • gltF exporters should export objects that don’t need to be parsed into JSON objects.

  • Suggested property names to use for a generalized visualization design pattern:

  • “visualKey”: a value (string or number) that the rendering logic uniquely identify a 3D visual’s sub-component to be dynamically accessed.

  • “visualDatum”: an object that represents datum associated with the 3D visual’s sub-component.

#2

I think the issue here is that Blender’s Custom Properties are simply key/value pairs – it has no concept of nested data, except if you’re adding the properties through its Python API: https://easyblend.org/html/data_system/custom_properties.html#python-access

The glTF format does support nested .extras data for sure, it’s just that Blender is giving the exporter a string here.

#3

Thanks.

A Python script would be a good workaround and practical as well. I don’t see a developer manually going 1 by 1 updating the custom properties for a 3D Visualization.

I’ll try developing a script that will dynamically populate Custom Properties from a .csv file with matching ‘name’ content.

I’m going to give it shot and post back here when I’m done…assuming I have link privileges by then.

Update: Script can be found by searching github for:

  • mariodelgadosr/AddBlenderCustomPropertiesFromCSV

Related FYI:

I’ve detailed a design/programming pattern (search github for ‘mariodelgadosr/datavisual’) that utilizes the

  • Blender custom properties
  • glTF extras properties;
  • Three.js userData

(they’re all referencing value-added information) for dynamic data visualization.

FYI #2 that may affect some developers:

Three.js sanitizes name property values. So a Blender name ‘Object.001’ is sanitized to ‘Object001’. The github/documentation goes into more details about this.

1 Like