Viewer Architecture

The Second Life client (also known as the "viewer") is a complex piece of software. It can be visualized as a streaming media client like RealPlayer, a game engine like Quake 3, or a web browser.

First you'll need to learn some terminology like "agent", "sim", and "region" in the glossary.

Learn by Example

• Adding a menu item
• Adding a dialog
• How movement works
• How the camera works
• How login works
• Hegemons Login Analysis
• How keyboard processing works
• How scripts work
• The lifetime of a session
• Adding a preference

Major Systems

• Message System - reliable and unreliable transport over UDP
• Image System - prioritizes and decodes JPEG2000 images into OpenGL textures
• Viewer Object System - objects in scene for rendering and editing
• Rendering System - from viewer object to drawable to face to vertices to graphics card
• Culling - octree and occlusion based culling to speed rendering
• UI Widgets - cross platform buttons, scroll bars, etc.
• UI Floaters - dialogs and windows built from XML files
• Asset System - transport for animations, sounds, notecards, scripts, etc.
• Inventory - server-side storage of assets for each user
• Sound System - cross platform audio based on FMOD
• Movie System - QuickTime-based video on object surfaces
• VFS - cached data is held in two "virtual file systems" in large files on the client
• Selection Manager - holds extended information for selected objects and allows editing
• Avatar Appearance - appearance is constructed from a mesh, parameters to deform the mesh, and textures to describe clothing
• Web Browser - the integration of the viewer with the web.
• Avatar Profiles
• Groups
• L$ System
• Tools - anything that takes effect when you click your mouse on the world view.

Threads

The viewer is a single process with a few threads:

• Main thread -- The input/output main program function (including rendering).
• VFS thread -- Thread responsible for reading/writing to the local virtual file system.
• LFS thread -- Thread responsible for some reading/writing to the local native file system.
  • Used by the Threaded_Image_Pipeline project
• Image thread -- Thread responsible for requesting and decoding image data
  • Used by the Threaded_Image_Pipeline project
• Error Thread -- Thread resonsible for catching exceptions, calling the (currently unused?) error handler, and retiring
• Worker Threads -- Threads designed to do cpu intensive background tasks
  • These threads may be paused during rendering so as not to reduce performance (design in-progress)

Program Flow

1. Initialize - newview/viewer.cpp :: main()
2. Loop - newview/viewer.cpp :: main_loop()
   • Gathers keyboard and mouse input
   • Pumps the TCP i/o
   • idle()
   • Render the frame
   • let filesystem and worker threads process
3. Shutdown

One way to see what goes on in the main loop is to bring up the Debug console (Ctrl-Alt-D) then Client->Consoles->Fast Timers (or Ctrl-Shift-9) and expand the entries in the caption.

Sources of Input

• The Message System.
  • Assets through the Asset System, transmitted using the Transfer Manager, and extracted from the VFS.
  • Files through Xfer Manager.
• Files copied out of a VFS into local file store and read through c/c++/ll file API.
• XMLRPC calls such as login and Buying Land and Currency.
• HTTP GET/POST to the Backbone. This is not yet in use.
• Streaming music and videos.
  • Quicktime.
  • FMOD.
• The web browser.

User Guides

• Viewer coordinate frames.
• Known Client_parameters
• Known Client Parameters on LSLwiki.com
• Known defines
• Godmode - what Lindens can do