-
Notifications
You must be signed in to change notification settings - Fork 231
Frequently Asked Questions
Basic support is provided with @xviz/ros.
In general, XVIZ is a data format and ROS messages can be converted into XVIZ messages. Deeper integration into the ROS ecosystem should be possible with existing projects such as roslibjs, and we have some community development efforts such as https://github.com/uber/xviz/pull/418. We are also hoping to get some basic instructions for how to use rosbridge in conjunction with XVIZ and streetscape.gl.
ROS is an important environment that XVIZ and streetscape.gl need to support and we are working to add what we can. Ideally we are building pieces that ROS experts can adopt independently of our project.
We do not currently have a C++ library to build and manipulate XVIZ data. We do plan on adding this eventually. Currently we are targeting Linux, Clang 7+ and C++17.
It is possibly for an application to change the camera focus. A starting point for understanding camera controls would be in our current available view modes and following them in the code to see how it works.
We are working on getting a test data set and benchmarks to allow benchmarks to be ran by anyone at any time. https://github.com/uber/xviz/issues/361
The XVIZ specification currently does not provide a way to add custom data. However, it should be possible to add custom messages that a client could handle completely independently of XVIZ inside the viewing application. This requires more details of how to extend streetscape.gl and we have some documentation to get you started. See https://github.com/uber/streetscape.gl/blob/master/docs/developer-guide/custom-layers.md
As XVIZ matures we will constantly be looking at any feature or data additions that would add value or a performance improvement.
We will connect to a socket, from there the distinction between live and offline depends on the back end, specifically how fast you can convert from your native format to xviz. The limiting factor is data payload size for transmission and browser processing of the data.
We do not have a transform or rotation attribute on the individual primitive elements. For now rotation would have to be done during the conversion to XVIZ.
We do not handle streaming video. If you need a streaming solution it would have to be built custom to synchronize video data with XVIZ.
The internal development of XVIZ at the time did not choose protobuf or flatbuffers, and was smaller in scope. As XVIZ has grown we have added protobuf definitions for the messages, but we are not using them currently. There should be nothing stopping an implementation of XVIZ encoded in protobuffers served over gRPC.
Yes this can be done. We have bundled the XVIZBuilder into a front-end app based on streetscape.gl which we call the playground and you can find it at https://avs.auto/playground/index.html.
Do you plan to have support for OSI (https://github.com/OpenSimulationInterface) based on combination of OpenDRIVE, OpenSCENARIO & OpenCRG?
We are investigating these projects as they are in alignment with the spirit of XVIZ to build an eco-system the community can benefit from. External contributions related to these projects would be very much welcomed.
The best example would be to look at the code we used for the KITTI conversion. https://github.com/uber/xviz/blob/master/examples/converters/kitti/src/converters/lidar-converter.js#L41