twojtasz
commented
4 years ago It is a fair to say that a live mode has partial support, as you have experienced.
To address your bullet points
- This is simply due to the current way the Providers and components work. Since live mode in the server isn't fully supported this is the current situation. Your choice of language helps emphasize your frustration, but does little else. The reality is live is not fully supported and does need improved. This could be done in many ways. An alternate provider could be created, or a flag could be provided to ignore the index.
- Actually, we are moving to a more flexible metadata in the live case because you may not know ahead of time what streams are available. We are looking to make metadata messages valid at any time but have not finalized it yet.
- Nice :) The server then needs to respect this and change behavior accordingly.
- Javascript is not a good choice for production work, we know this. Ideally it would be in C++ but for various reasons we have chosen to make XVIZ available with the Javascript examples and specification first, and over time add additional languages.
In general, a live mode is extremely useful, but large amounts of data exists off-line that are easier to work with and equally valuable. Priorities and resources is the name of the game.
Let me see if I can help remove some complexity for you.
You are working with the existing components, which is great build an understanding of the system, but to make it work for you I expect you to replace components that don't fit. The layers try to isolate a responsibility. XVIZSource/XVIXSink operate on a named data source, it could be from file or something else but assumes some structure w/o saying memory or file or socket or db.
The next layer is the XVIZReader/Writer. These conform to the structure you mention of index, metadata, data (0-frame.json, 1-frame.json, {2,*}-frame.??? - respectively). You could create a component that returned some minimally viable data where it is not relevant to you instance.
The next layer is the XVIZProvider, which is very concrete about Index, Metadata, Message and does not care if the underlying interface follows the convention (0-frame.json, etc) since it relies on the XVIZReader.
What this means is you could create an XVIZProvider and XVIZReader that was entirely independent of the existance of an index or metadata (just send valid but largely ignored values as necessary).
I would love to get XVIZ to a level of maturity where what you want came out of the box ready to use, but we are building to that. In the mean time we are trying to provide appropriate levels of abstraction such that most elements can be worked around while still leveraging other layers provided.
Hope this helps give you some ideas. Ping me on slack or post a PR and I can provided assistence.
VijeetBenni
enginbaglayici
didibaba
heshiwen1989
mahaogithub
xibei08
Hello, I want to generate .glb files from sensor data and directly send it to Uberviewer to visualize data in real time. I can generate .glb files but I need some ideas to visualize this data with a frequency. If it possible, what would be the steps to achieve this?
Here's what I've done and found for live mode and the results:
I'd appreciate if you provide an example or specification for live mode operations. Thanks for your interest.