Technology Preview of new Data Input API

This epic collects together all ongoing tasks that relate to code-design integration (Qt Quick runtime component and the design created by the artist) changes in Qt 3D Studio.

Data passing from QML to Qt 3D Studio content is badly defined today. The API relies on setAttribute(elementPath, value) JavaScript method where elementPath directly maps to the visual design hierarchy in the Qt 3D Studio content. While this "works" it defines absolutely no contract between the programmer and the artist/designer.

Issues with current API

The programmer can break the intended design by accessing any property of any element and taking over the artists intended behaviour.

Artist can break the program if he:

• Renames any of the elements included in the elementPath
• Moves any of the elements in the elementPath to different part of the scene hierarchy
• Deletes the targeted element or any of the elements in the elementPath.

The mapping from a value to a visual effect is also limited to 1:1 (one setProperty call per visual value e.g. rotation of element, color of element etc.).

Customer input
All of the above limitations are show stoppers and our customers have indicated this is not acceptable target state for the API. The API must allow for flexibility where the visual design is not related to the passing of the value and where one numerical value (e.g. RPM) can affect any number of visual elements in the content.

Solution for getting values to visual design
Artist needs to be able to get inputs from the code and then decide how the visual 3D content behaves based on the input values (e.g. define how fuel level is shown in the UI).

A solution is to define a new "data input" API that allows defining specific named data input "slots" in the root of the scene hierarchy. These slots define the explicit contract between the artist and the programmer. In first iteration we need to allow for controlling any timeline (component, subpresentation or presentation) from these data inputs as this allows one input to control multiple things in the scene in a natural manner. In addition being able to pass text for text fields is critical to enable showing dynamic values numeric or textual values in the design.

In the first iteration the artist would create one data input per expected input value (for example: rpm, fuelLevel, speed, leftIndicatorActive, rightIndicatorActive etc.). In the future we can look in to options for importing the API definition from external sources so that both artist and programmer are given the defined API from a 3rd instance (or it can be defined in a joint meeting between design and implementation and then "locked").

The programmer then uses these named data inputs with fixed position (scene root) and well defined name to set the values from the code to the design. In optimal case these values would be exposed as QML properties from the Presentation QML element that loads the presentation project.

Solution for allowing programmers to modify visual design
In some cases the artist wants to allow the programmer control over an object (meaning any properties of an object) or selected property/properties of an object (e.g. color, rotation). In this case the programmer needs to have a elementPath name for the object/property so that the contract between the artist and programmer stays valid even if artist changes the hierarchy of the visual design.

A solution for this is to allow the artist expose selected objects or properties as aliases that are located always in a fixed location.