KhronosGroup / KhronosGroup/glTF

Considering adding new extension to allow telemetry input

Open
#2,194 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
HTML
Stars
7.8k
Forks
1.2k
Avg merge
17h 26m
Merged PRs (30d)
5

Description

Hello,
Following the new expected [KHR_behavior](https://github.com/ux3d/glTF/tree/extensions/KHR_behavior/extensions/2.0/Khronos/KHR_behavior)
i was wondering to include a new way to add telemetry (in the sense of IOT sensors input) input as extension of [event node](https://github.com/ux3d/glTF/blob/extensions/KHR_behavior/extensions/2.0/Khronos/KHR_behavior/schema/event/eventNode.OnValueChanged.schema.json).
for the purpose we may first define a specific extension to register possible DataSource under the scene
```
"KHR_telemetry_sources" : {
"streams": [
{
"name" : | "guid":,
"displayName" : ,
"description" :
"channels" : [{

}]
}
]
}
```
and use event node pointer to bind sources.
`pointer = "extensions/KHR_telemetry_sources/streams/0/channels/0"`

We may also add a KHR_telemetry_event to node pointer extension to control the behavior of the source (properties, frequency, threshold..)

```
"KHR_telemetry_event" : {
"value":,
"frequency": ,
"threshold" : ,
...
}
```

`Channels` may contains any, non sensitive, informations from vendors (MSFT IOT, AWS IOT, Google Cloud IOT, etc.. ), allowing players to open telemetry stream if they support it (similar to extensions behavior).
The name will be unique within the telemetry namespace, uniquely identify stream `"MSFT"`, `"AWS"`, `"GOOGLE"`, `"META"`, `"guid:49364490-fabd-4c38-b6b0-d8dd70721934"`, etc..

I will make a try within the Babylon JS engine to support first the `KHR_behavior`, then add this extension.
G.

Contributor guide

Open the contributing guide

Research direction

Start by reading the linked KHR_behavior extension and extensions/2.0/Khronos/KHR_behavior/schema/event/eventNode.OnValueChanged.schema.json, then compare the proposed telemetry pointers and fields with existing extension conventions. A complete outcome would require an agreed telemetry-source and event design plus the proposed Babylon JS support; the issue does not define tests or acceptance criteria.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
computer-graphics
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.