Proto commits in aurora-opensource/xviz

These 37 commits are when the Protocol Buffers files have changed:

2022-08-19

add new style for texture support

2019-12-10

Add "point_color_mode" and "point_color_domain" to the spec files (#559) Fix error where lowercase constants should have been uppercase. Support both for backwards compatibility.

The documentation is generated from this commit.

Remove duplicate Link message in protobuf (#561)

Add "point_color_mode" and "point_color_domain" to the spec files Fix error where lowercase constants should have been uppercase. Support both for backwards compatibility.

Remove duplicate Link message in protobuf

2019-11-11

Transform streams (#546) This adds scene graph support to XVIZ through the use of the new *links* entry in the state_update message. - Support parsing of links - Add link support to xviz-stream-buffer - Add link support to synchronizer - Add links to protobuf and round-trip tests - Add scenario demonstrating links in "scenario-orbit"

2019-10-26

RFC: Scene Graph support for primitives (#524) Detail the addition of the **links** entry in the state_update message. The links entry relates two streams (either a primitive stream or a pose stream) in order to support position and orientation attributes to model a scene graph transform network.

2019-09-24

Update RFC to address development and comments

2019-09-08

Persistent specification updates (#507) Related to #403

2019-09-04

Persistent specification updates Related to #403

2019-07-25

Changes for better performance with protobuf.js instances (#503) Protobuf.js uses prototype object creation which has the effect of looking up the prototype chain for properties even if the instance does not have it set. This requires the use of 'hasOwnProperty()' in some places to distinguish between the instance and the prototype property. The library also assigns default values for fields, such as the empty array or a value of 0. Our parsing would look at presences to determine if a property was meaningfully set, but now we need to have additional validation due to the default values set by the protobuf.js library.

Protobuf update for style and UI (#504) - Change prototype definition for color from uint32 to bytes - Change metadata ui_config to use the Struct type for the config field

2019-07-15

Add Protobuf Envelope and change doubles to floats (#495) - default tolerance is 1e-7

2019-07-12

Add in all value types

2019-07-08

Add 'log_info' definition to metadata schema (#448)

2019-07-05

First try at a "PolygonGroup" type This is a "structure of arrays" style type that allows for much faster encode/decode and in a lot of cases use.

To make comparison easier make bulk position data float instead of double

2019-07-04

Try bytes added directly to protobuf info

2019-06-22

Fix protobuf Values documentation

2019-06-07

Change specification enumerations to ALLCAPS (#477) Follow the convention that constant enumerated values should be in ALLCAPS. This is a spec change for XVIZ, but retains compatibility with lowercase by forcing a case conversion at the appropriate places within the modules. Spec change locations: declarative ui properties - component type - layout - interactions xviz message - type - xviz/start - session_type - message_format - log - xviz/metadata - stream metadata - category - scalar type, for time_series & variables - primitive type, for time_series & variables - annotation_type, for annotations - stream style - text_anchor - text_baseline - xviz/state_update - update_type - xviz/reconfigure - update_type

2019-06-03

Lint protobuf files, move to xviz.v2 package, ensure bazel compat (#476) We are using Uber's prototool 1.7 for lint with the provided prototool.yaml setting which rules we are not following. These are not being followed so that JSON emitted and consumed by the protobuf types matches that in the JSON schema. Bazel compatibility allows other projects to pull in our source releases and use the protobuf rules directly. See the `docs/protocol-formats/protobuf-protocol.md` for more details on Bazel and lint/formatting.

2019-05-16

Rename "snapshot" to "complete_state" and clarify meaning (#404) Right now "snapshot" is close to "incremental" but now we have defined them in such a way that we can implement things properly. Further changes will implement this functionally.

2019-04-03

Spec: change Pose 'mapOrigin' to 'map_origin' to conform to snake_case (#395) Issue https://github.com/uber/xviz/issues/394

2019-03-16

Switch treetable integer type to int32 (#411) Currently it reads "integer", should be "int32" instead to match the other XVIZ types.

2019-02-18

Conformance tests for all primitives (#325)

2019-02-16

Make schema validators work in the browser (#322)

2018-12-03

(Unstable) transform_point_in_time message spec & docs (#227) The `transform_point_in_time` message gives a client the ability to ask for the latest value of a set of XVIZ streams up to a particular point in time. This is useful for generating 3D or 2D images of logs, or continuously viewing a time of interest as you reconfigure the XVIZ transform done by the server.

Session protocol docs & transform message specs (#226) This explicitly defines the XVIZ 2 session protocol and all the messages it contains. We describe in details the flow of: - connect - client sends `start` - server sends `metadata` - optional: client sends `reconfigure` - client sends `transform_log` - server sends `state_update` (many of them) - server sends `transform_log_done` - optional: server sends `error` To fully specify this we defined the follow new message: - `reconfigure` (this was just the envelope support) - `transform_log` - `transform_log_done` - `error` Also some links were fixed in the documentation page, and we fixed the `start` message schema and added more examples.

2018-11-26

Fully flesh out XVIZ stream metadata (#215) We want to be able say exactly what data is on what stream so we can inform the front end of the fact. This properly sets up a two tiered system where you define the category a field is in, like "primitive" then say what exactly it is like "circle". The one interesting choice here is that we use the "scalar_type" field to represent the type of both "time_series" and "variable" data.

Specification for reconfigure message (#216) This allows a client to adjust how a server transform the data it sends in XVIZ format. In order to make this happen I had to add support for the google.protobuf.Struct well known type to protobuf.js. The upside it lets us basically embed JSON directly into protobuf for use cases like configuration updates. It also does it in a way that is faster or more dense than raw text.

2018-11-10

Define and update TreeTable schema (#191) We have translated the documented schema into a formal JSON and protobuf schema with a set of invalid and valid examples. The schema has changed to having all column values encoded as strings for now. In the future when we can figure out a more efficient protobuf compatible encoding we'll make a backwards compatible switch to that.

2018-11-09

Update changelog and docs for 0.2.0 and clean up code (#177) The markdown protocol docs have been updated to reflect the changes made for protobuf compatibility, and all the protobuf files have been marked unstable. To cleans things up a little bit the massive test for the proto validation code has had some utility code factored out and some function move out of the test.

2018-11-01

Finalize XVIZ protobuf with session types (Part 5) (#175) All XVIZ types, except declarative UI, now have a matching protobuf 3 types. The changes needed to do this were mostly non-breaking: - `DYNAMIC` transform now specifies it's function with `transform_callback` - The 3x3 and 4x4 Matrix types can now be passed flat, because that that is how they are represented in protobuf. - `ui_panel_info` can now represent the declarative UI content as raw string because that is how protobuf will pass the JSON format of the declarative UI files. In the final section we will update all the docs and the change log.

2018-10-29

Updates variable schema & builders to match proto3 IDL (Part 4) (#172) See part 1 commit for details, but background and context, the changes here are: - `variable` not contains a `values` object instead of a `values` array, that object has sub-arrays for each type - `object_id` in variable is moved to a separate `base` object

Updates timeseries schema & builds to match proto3 IDL (Part 3) (#171) See part 1 commit for details, but background and context, the change here is: - We have a new `values` type that holds arrays of different kinds of values. - `timeseries_state` now holds an array of stream names and instance of this `values` type. Both arrays are the same length.

2018-10-26

Updates future_instance schema to match proto3 IDL (Part 2) (#169) See part 1 commit for details, but background and context, the change here is: - `future_instances` now hold arrays of `primitive_state` (ie. an object with a subfield of each type of primitive), because we cannot have a polymorphic list of objects.

Update schema and provided compatible proto3 IDL files (#168) The goal here is to increase adoption by letting people build quick clients with based on the protobuf IDL files and websocket library. Note we are excluding declarative UI because that is meant as a pure text protocol that is easy for humans to edit. The downside is we have to content with protobuf not supported: - Maps of arrays - Polymorphic types - Variant fields - No typedefs So the major changes we have to do for this is: - Move common fields from primitive, and annotation into base sub type - Replace polymorphic lists of primitives with lists per types - Add explicitly typed lists for time series and variables - (Part 2) Update future_instances to be non polymorphic - (Part 3) Update time_series to be non variant based - (Part 4) Update variables to be non variant based This also means protobuf will only ever support a subset of the JSON schema, with that subset being: - Numeric only colors (no hex or string support) - Flattened arrays only (no nested array support) (Maybe we'll even have some gRPC endpoints someday as well).