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

Major Systems

Animation - avatar motions
Asset System - transport for animations, sounds, notecards, scripts, etc.
Avatar Appearance - appearance is constructed from a mesh, parameters to deform the mesh, and textures to describe clothing
Avatar Profiles
Culling - octree and occlusion based culling to speed rendering
Error Logging System - command and control of debugging output
Groups
Image System - prioritizes and decodes JPEG2000 images into OpenGL textures
- Texture cache - used for reading and writing texture data to the local disk cache
- Image Pipeline - fetches textures from the servers and decodes them
Inventory - server-side storage of assets for each user
L$ System
LLMedia API - arbitrary media on object surfaces
Message System - reliable and unreliable transport over UDP
Muting Objects and Agents - How the viewer manages the muted object list
Rendering System - from viewer object to drawable to face to vertices to graphics card
Selection Manager - holds extended information for selected objects and allows editing
Sound System - cross platform audio based on FMOD
Tools - anything that takes effect when you click your mouse on the world view.
UI Widgets - cross platform buttons, scroll bars, etc.
UI Floaters - dialogs and windows built from XML files
VFS - cached data is held in two "virtual file systems" in large files on the client
Viewer Object System - objects in scene for rendering and editing
Web Browser - the integration of the viewer with the web.

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 responsible 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

Initialize - newview/viewer.cpp :: main()
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
Shutdown

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

Startup and initalisation

(updated for 1.20.14 code)

The main() function for the viewer exists in either llappviewerlinux.cpp, llappviewerwin32.cpp or llappviewermac.cpp depending on your platform. This creates the instance of LLAppViewerLinux, LLAppViewerWin32 or LLAppViewerMac which all are derrived from LlAppViewer. The initial platform dependent code sets up the various error handlers to handle a viewer exception (crash condition). The reset of the platform dependent appviewer classes are related to crash handlers.

The initialization then occurs in LLAppViewer::init() this is the real low level setup and class creation and does things including :-

Sets up application directory locations
Sets up logging
loads configuration
sets up Curl
Creates worker threads
Creates the LLUI system
loads saved/default settings
initalises the cache system
sets up the viewer window
Checks the CPU type and features
checks memory and graphics card
Initalises joystick

Then the LLAppViewer::mainloop() is started

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.net
Known defines
Godmode - what Lindens can do