Streaming Interface (Notes fm WP Performance)

[ThomasNaderBMW]

Challenge:
How to provide information with different timestamps?

Actual Approach:

[ThomasNaderBMW]

Notes 26.01.23 WG Performance:
https://github.com/OpenSimulationInterface/open-simulation-interface/blob/feature/pp/visualization_interface/osi_streaming.proto
As a first draft.

Architecture so far (just slide 4):
Visualization interface.pptx

[raue]

Just thinking about of how to get along w/ 'disappeard' object.
So far, based on the architecture provided above, the graphics engine need to know which object should be pulled out of the content DB. If it's a car then probably classification would be set to TYPE_SMALL_CAR or seomething similar. But how should a TYPE_UNKNOWN be handled by the graphics engine? Would it come up w/ a box, a ball, a roundabout, or what? Why not making the object disappear be setting the type from what it was during the visible phase - e.g. TYPE_SMALL_CAR - to TYPE_UNKNOWN? Of course, in case TYPE_UNKNOWN is the best guess of the sensor classification, you want to show something anyway. Therefore another idea, why not using a model reference value which points to e.g. 'INVISIBLE' ?

[globberwops]

Proposal for the message name: PartialTrafficUpdate.
TrafficUpdate is already taken, and 'delta' does not quite hit the point, since we do not want to send relative updates in the sense of differences between old and new data.

[globberwops]

Just thinking about of how to get along w/ 'disappeard' object. So far, based on the architecture provided above, the graphics engine need to know which object should be pulled out of the content DB. If it's a car then probably classification would be set to TYPE_SMALL_CAR or seomething similar. But how should a TYPE_UNKNOWN be handled by the graphics engine? Would it come up w/ a box, a ball, a roundabout, or what? Why not making the object disappear be setting the type from what it was during the visible phase - e.g. TYPE_SMALL_CAR - to TYPE_UNKNOWN? Of course, in case TYPE_UNKNOWN is the best guess of the sensor classification, you want to show something anyway. Therefore another idea, why not using a model reference value which points to e.g. 'INVISIBLE' ?

While I like the idea of reusing an existing field, I believe it would be hard to justify reserving e.g. the value 'INVISIBLE', since model_reference is entirely implementation specific.

I still think we need a more robust solution than a list of entities to be deleted, that is probably sent only once.

Consider the following sequence of partial updates:

1. Entity is instantiated (in init?)
2. Entity is continuously, partially updated
3. Entity is added to the list of entities to be deleted from the scene
4. The simulation keeps partially updating the entity (either by error, or bc. the entity should reappear?)
   • Does the application (e.g. graphics engine) need to keep track of the 'deleted' state of each entity by itself?
   • Does the application also need to keep the attributes of deleted entities in store in case it should reappear?

In my (current) opinion, the most robust solution would be, if its visibility was an attribute of the entity itself that could then be partially updated.

[globberwops]

After yesterday's discussion, we know that we're talking about a symmetric delta. Maybe that'll help with the message name.

Also, the discussion was leaning towards adding an attribute, probably to StationaryObject and to MovingObject respectively, indicating to the receiver of the symmetric delta, that the object has been "removed by the sender".