Before You Start
Introduction
OmniStream is ZeroLight's enterprise cloud streaming product. To get in touch with us to find out more about getting started with OmniStream, contact your ZeroLight Account Executive if you have one, or reach out to us here. OmniStream has native integration for Unreal Engine, Unity and VRED, and generic support for any Windows application.
Using OmniStream
Once you have an OmniStream account getting set up and streaming is simple:
1. Integrate
For Unreal and Unity there are OmniStream plugins, that integrate OmniStream streaming in your project and upload packaged builds of your application to OmniStream. For VRED and Windows there is a standalone OmniStream application that is used to configure settings and upload your built application to OmniStream.
Only your packaged application builds are uploaded to OmniStream - the source project stays within your system.
2. Build & Upload
Build your application and then use the plugins/standalone OmniStream application to upload to ZeroLight's customer Portal.
3. Deploy
Login into Portal, select your build and deploy it.
4. Stream
Once your application is deployed you can view the stream using the link from Portal, integrate the stream in your own site using an iframe or for more complex integrations there's a JavaScript library to allow greater flexibility and control.
5. Iterate
As you go through development and make iterative changes to your application you can steps 2 - 4 until you're ready to go live and give the link to your customers.
Understanding OmniStream
To help you when building an application for OmniStream there are some useful topics and things to understand that might influence some of your development choices.
1. Input Keys
For security reasons OmniStream does not just pass through all keyboard input straight to your application (this would allow key combos like Alt+F4 or Ctrl+Alt+Del, which we need to restrict). By default, some basic keys (WASD, the arrow keys and a few others) are added, and whichever keys you require can be added in the plugins/standalone OmniStream application.
2. Window Resizing
OmniStream resizes your application window to match the size of the element displaying the stream on the integrating website. You should avoid resizing your application window as mismatches between the application window the stream element on the web page will cause artifacts such as sections of the application being cut off or stretched. Depending on your web integration your application also needs to be responsive to resizes and make sure all UI elements, for example, remain onscreen and usable. This is something to consider when doing your web integration - do you want to allow users to change the size of their stream window, or go fullscreen or not?
3. Scheduling
Applications are deployed to your OmniStream Render Service(s), which users connect to access streams. In order to deliver precise and flexible budget controls, Render Services deliver streams through schedules. Schedules allow for the number of streams running to be fixed or flexible to meet demand with a configurable cap to control costs. To learn more, see scheduling.
4. Application Lifecycle
When OmniStream applications are started, they might be being launched for a waiting user who will be connected as soon as the application is ready. They might also be launched by a schedule ahead of a user requiring a stream. Also when a user disconnects from OmniStream the application is not terminated by default - instead it is left running with the application able to decide what the most sensible course of action between users is.
When developing an application for OmniStream, it is worth keeping this in mind. Depending on your application the right actions here will be different.
If your application needs to show an intro sequence you might want to hook into the Connected event so you can trigger this. If you just need to display some static instructions the user can click through, then doing this on start could be sufficient as it will stay there until a user connects.
Likewise, you might want to hook into the Disconnected event so you can reset your application as quickly as possible, ready for the next user. If that would be too complex, then you can select the option to have OmniStream automatically restart your application on disconnect for you.
There are no right or wrong answers here and OmniStream offers you the flexibility to do what makes most sense for your application.
5. State Management
For many applications, allowing the user to interact directly with the scene is sufficient, and they don't need to worry about the advanced state management offered by OmniStream. If you wish to send commands to your application from the integrating website or use image mode, then ensuring that both the web front-end and the application doing the rendering have a shared understanding about the current state of the application is key. OmniStream supports a flexible approach using JSON to specify state with useful tools to help debug issues arising from divergence of state.
6. Connection Modes
OmniStream has two connection modes, which mode(s) you use will depend on your use-case. In Video mode each user receives a one-to-one video stream from a running version of the uploaded application. In Image mode users receive a series of rendered images that are rendered on-demand based on the changes they request. In Image mode the application can serve requests from multiple users simultaneously, rendering these images, returning them to the users and storing them in a cache so they do not have be be generated again if a request for the same content is made again.
If, for example, your application is an interactive training application then almost certainly you'll want to exclusively use Video mode. If you're building a product configurator then both Video mode and Image mode might both be useful. OmniStream documentation is generally agnostic of mode, where there are implementation differences these are noted expressly.