The meeting command shares a scene between two or more ChimeraX instances running on different computers. Its main purpose is to allow multi-person virtual reality (VR) sessions in ChimeraX, although it can also be used without VR. Each participant is represented by an image and hand-controller pointers (or if not using VR, the mouse pointer) so that participants can see each other pointing at atoms in the scene. See also: vr
The meeting is initiated with meeting start, which reports the hostname and IP address in the Log. Subsequently, others join using meeting host, where host is the hostname or IP address of the starting instance (e.g., descartes.cgl.ucsf.edu or 220.127.116.11).
Each participant can specify a name to serve as an identifier within the shared environment, a faceImage file, and a pointer-cone color.
Aside from synchronizing pointers, the meeting command will copy a session from the ChimeraX instance that initiates the meeting to each person who joins the meeting. This copying is done only when a person joins the meeting. Commands executed by one participant will automatically execute for the others (by default), and if a participant using VR moves the scene, others using VR will see the motion. Participants not using VR maintain their own viewing directions. If unshared changes have been made, a participant can still share his current scene with the others by using meeting send. The host can end the meeting with meeting close, or others can use it to exit the meeting individually.
The meeting command is under development and has several limitations.
Name to show for a participant's pointer and image models in the Model Panel.
Color for the cones representing a VR participant's hand-controller pointers (or non-VR participant's mouse pointer).
Image to represent a VR participant's headset position, where image-file is the pathname of a JPG or PNG file. The pathname can be absolute or relative to the current working directory as reported by pwd, Substituting the word browse for the pathname brings up a file browser window for choosing the file interactively.
copyScene true | false
Specified with meeting start, whether to copy the session from the starting instance to each person who joins the meeting (default true). This copying is done only when a person joins the meeting.
relayCommands true | false
Whether to share commands with other participants, and in turn, execute other participants' commands automatically (default true). Note that toolbar icon buttons and many mouseclick/pointer operations act via commands.
Number of the network port used to connect to the meeting host (default 52194). Unless the default is used, all who join the meeting must specify the same number as specified with meeting start.
How often to send a participant's VR headset and hand-controller positions to the other participants (every Mth frame, default 1, every frame). For non-VR users, the mouse pointer is not tracked continuously; the position is only displayed to others when it hovers over an atom.
Synchronizing changes. After the initial scene is shared not all changes made by one participant will be propagated to other participants. Changes that are propagated include moving and scaling the displayed structures and (by default) executing commands. If a participant makes any unshared changes or introduces data for which the input file is not directly accessible to others (i.e., the same open command will not work for everyone), meeting send is needed to share the updated session. This may be slow for large amounts of data.
More than two participants. The meeting command has had very limited testing with more than 2 participants. Multiple participants may cause errors or slow display updating.
No audio chat support. An audio connection is not provided, so it is necessary to set up a separate audio link for remote participants.
Firewalls block connections. Most academic institutions have firewalls that block incoming network connections, and require administrative requests to open up network ports. A more usable design for shared ChimeraX sessions would have all participants connect to a hub machine. To allow this to scale to hundreds of instances running simultaneously, ChimeraX could start a cloud-based server on demand using a commercial service that accepts the connections and forwards changes to all participants. However, this is a complex undertaking that would require accounts and payment for commercial services.
Aligning two VR headsets in one room. Two Vive or Vive Pro VR headsets can be used in the same room, each connected to its own computer. Each headset uses the same pair of base stations. A problem sometimes arises that the two headsets do not see the ChimeraX structures displayed at the same location in the room. Specifically, one headset may see the structure positions as if the room is rotated 180° relative to the other headset. This happens because the SteamVR room setup is run separately on each computer and produces a different coordinate system. For structures to have the same room position in both headsets, the room boundaries traced using SteamVR room setup should be the same for both computers. The first step of SteamVR room setup in which users are asked to point the hand controller at the screen and click is the key to avoiding 180° misorientation. At that step, it is important to point along the short axis of the rectangle defining the room bounds (that will be traced in a later step). SteamVR chooses between two coordinate system orientations rotated 180° from each other based on the direction of pointing. If pointing is along the long axis of the rectangle bounds, a slight tilt toward the left or right of the long axis produces opposite coordinate system orientations. Pointing along the short axis instead is a reliable way to make both computers use the same orientation. (The computer screen position is irrelevant.)