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
• Adding a cursor
• 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
• How preferences work

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
• Message System - reliable and unreliable transport over UDP
• Movie System - QuickTime-based video on object surfaces
• 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

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 menus (Ctrl-Alt-D) then Client->Consoles->Fast Timers (or Ctrl-Shift-9) and expand the entries in the caption.

see also: AW Groupies protocol and login documentation links

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

See also

• Viewer Roadmap - how everything you read here could be changing or might have already changed.