ChimeraX docs icon

Command: meeting

Usage:
meeting  start  [ name  participant-name ] [ color  pointer-color ] [ headImage  image-file ]  other-options

Usage:
meeting  host  [ name  participant-name ] [ color  pointer-color ] [ headImage  image-file ]  other-options

Usage:
meeting  send

Usage:
meeting  close

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 a head 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 169.230.21.39).

Each participant can specify a name to serve as an identifier within the shared environment, a headImage 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.

Options

name  participant-name
Name to show for a participant's pointer and head-image models in the Model Panel.
color  pointer-color
Color for the cones representing a VR participant's hand-controller pointers (or non-VR participant's mouse pointer).
headImage  image-file
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.
port  N
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.
updateInterval  M
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.

Limitations and Potential Developments

After the initial scene is shared, the only changes that are automatically propagated are 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.

An audio connection is not provided, so it is necessary to set up a separate audio link for remote participants.

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.


UCSF Resource for Biocomputing, Visualization, and Informatics / October 2018