This is a research project I took on so I would know how to answer the uninformed grievance posters. You probably know some of them if you participate in the SL Forum. They complain and gripe. Whatever you challenge them with, they ignore. They don’t mind contradicting them selves.
The claim came up that Linden Lab® was not upgrading SL as they should or at all. I play in SL every week… almost daily. You’ve seen me post benchmarks on various viewers and features of SL. But if I wanted to prove I know what I say is accurate, what could I point to? There isn’t a “thing” or “article”. So… I had AI do the research and write a report. The report follows.
You’ll see the AI setup the comparison by figuring out what SL was and is now. It got pretty detailed. After all that is done and it makes all its disclaimers, it gets to the comparison.
What can you do with this information? Other than embarrass the dofuses? Actually, if you are considering upgrading for better performance or saving money on a new computer then this is a guide to what to spend money on and where to save dollars.
Executive Overview
Over roughly fifteen years, the dominant performance bottleneck in Second Life® has inverted. In 2008 the viewer was network- and asset-stream-bound: scenes had to be downloaded over a connection that the official wiki described as adequate at only 500 kbps, then transformed into a 3D view in real time (SL Wiki: Lag). Assets were tiny — a classic system avatar cost a baseline of just ~1,000 complexity points and rendered as a handful of baked-textured mesh pieces (SL Wiki: Mesh/Rendering weight).
By 2026 the picture reversed. Bandwidth and caching improved one to two orders of magnitude, but asset complexity grew roughly two orders of magnitude — so the bottleneck migrated off the network and onto local GPU rasterization, CPU draw-call setup, scene traversal, and VRAM/texture pressure. On mid-range hardware, a crowded region of modern avatars collapses well before the network does. The limiting resource is now compute and memory bandwidth inside the user’s own machine.
Modeling note: this is a modeled benchmark, not the output of a single controlled viewer test run. Hard, directly-comparable historical measurements of draw calls and per-avatar render time across the 2008 vs. 2026 eras do not exist in any single public dataset. The figures below are modeled from documented Second Life Wiki specifications, viewer statistics fields, community-reported avatar complexity values, and standard real-time rendering cost relationships, then cross-checked for order-of-magnitude plausibility. Every assumption is stated so the model can be reproduced or challenged.
What Changed?
By 2026 a fully outfitted modern avatar can span tens of thousands to several hundred thousand complexity points, with the renderer tracking individual animesh objects capped at 100,000 triangles each and community-reported high-end mesh bodies reaching nearly 800,000 triangles (SL Wiki: Animesh User Guide; Ryan Schultz). Bento added ~106 new skeletal bones and raised the per-animation joint limit from 32 to 106 (SL Wiki: Project Bento Skeleton Guide; Inara Pey), and 2024’s PBR material system introduced glTF metallic-roughness materials with multiple material maps plus mirrors and reflections (Linden Lab® FAQ).
How These Numbers Were Built
Modeled hardware profile (mid-range, 2024–2026)
- GPU: NVIDIA GTX 1660 / RTX 3060 class, 6–8 GB VRAM (representative “mid-range” discrete card)
- CPU: 6-core AMD Ryzen 5 5600 / Intel i5-12400 class
- RAM: 16 GB DDR4
- Storage: SSD texture cache
- Display: 1080p, default-to-high graphics preset
Frame budget
- 60 FPS target → 16.7 ms per frame
- 30 FPS “playable” floor → 33.3 ms per frame
(The SL wiki notes 15–30 FPS is “about as smooth as broadcast television” and that “somewhat lower frame rates are acceptable” for SL’s use cases (SL Wiki: Viewerhelp:Statistics).)
How the modeled numbers were derived
- Triangle counts are anchored to documented limits and community measurements: animesh 100,000-tri cap (SL Wiki), 21,844 tris per material face / 174,752 per object (SL Wiki: Mesh/Technical Overview), and the Ryan Schultz measurement of a single mesh body at 794,368 triangles (Ryan Schultz).
- Complexity points follow the documented rendering-weight formula: base avatar 1,000 points, base cost = triangles × 5 weighted by LOD, with multipliers (glow ×1.5, bump ×1.25, flexi ×5, shiny ×1.6, invisiprim ×1.2, rigged mesh ×1.2, animated textures ×4.0, alpha ×4.0), plus +100/prim particles, +500/prim lights, +1500/face media, and a per-unique-texture cost of
256 + 16 × (resX/128 + resY/128)(SL Wiki: Mesh/Rendering weight). - Draw calls are estimated from material-face counts: each material face on each mesh requires at least one submission, multiplied by extra passes for shadows, reflections, and alpha-blended layers. The wiki confirms that objects rendered multiple times (e.g. under multiple lights or for reflections) produce a separate submission each (Unity Rendering Statistics reference used here only as the general rendering principle; SL-specific draw-call counts are not published).
- Render time per avatar is modeled as roughly proportional to visible triangles, material/draw-call count, and skinning cost, scaled against the 16.7 ms frame budget. These are order-of-magnitude estimates, not measured.
The 2008 Baseline Asset Profile
A 2008-era scene was built almost entirely from classic system avatars, prims, and sculpted prims:
- System avatar: a fixed, low-poly mesh split into upper body, lower body, head, hair, skirt, and eye meshes, driven by the legacy 26-bone skeleton (only 21 effectively weighted on the system avatar) (Avalab/Avastar). Complexity baseline of ~1,000 points, or just 100 with no attachments under the older ARC system (SL Wiki: Avatar Rendering Cost).
- Attachments: prims and sculpties, each costing 10 base points plus texture/per-feature multipliers. A typical outfitted avatar might reach a few thousand visible triangles total.
- Textures: baked avatar textures plus a small number of 512×512 or smaller per-prim textures. Texture memory pressure was modest.
- Streaming: the official guidance of the era stated 500 kbps was needed to “run Second Life adequately,” with bandwidth stabilizing at just 4–50 kbps after a scene finished downloading — and that doubling draw distance multiplied downloaded data 4–8× (SL Wiki: Lag). Texture cache minimum was 64 MB.
The 2024–2026 Modern Asset Profile
A modern outfitted avatar is a stack of rigged mesh body, Bento-rigged head, mesh hair, mesh clothing layers, animesh pets/attachments, and PBR materials:
- Skeleton: the Bento armature added ~106 new bones (hands, face, wings, tail, hind legs) on top of the 26 legacy bones, for a total around 130–133 bones, and raised the joints-per-animation limit from 32 to 106 (SL Wiki: Project Bento Skeleton Guide; Inara Pey; Nalates).
- Triangles: individual mesh objects can carry up to 174,752 triangles (8 materials × 21,844) (SL Wiki: Mesh/Technical Overview); animesh objects are capped at 100,000 triangles in their highest LOD (SL Wiki: Animesh User Guide); and a community-reported high-end mesh body alone measured 794,368 triangles (Ryan Schultz). Community discussion references modern avatars spanning roughly 65,000 to 300,000+ complexity (Reddit r/secondlife).
- Skinning: rigged mesh is weighted with a 4-bones-per-vertex limit and carries a ×1.2 complexity multiplier; crucially, every avatar and every rigged object must be processed sequentially — “20 identical avatars is 20 times more work than 1” (Reddit r/secondlife).
- Materials (2024 PBR): glTF metallic-roughness materials using multiple maps (base color, normal, metallic/roughness, ambient occlusion) at up to 2048×2048 each, plus mirrors and PBR terrain that re-render the scene for reflections (Linden Lab FAQ; SL Wiki: PBR Materials).
- Jellydoll protection: when an avatar exceeds the “Maximum Avatar Complexity” setting it is drawn as a solid-color silhouette; reported viewer preset thresholds run from 35,000 (Low) up to 350,000 (Super High), and a surface-area auto-mute kicks in at 1,000 m² of attachments (SL Wiki: Avatar Rendering Complexity; community-reported preset values).
Asset Complexity vs. Engine Limits
| Dimension | 2008-era classic avatar | 2026-era Animesh/Bento/PBR avatar | Approx. growth factor | Source |
|---|---|---|---|---|
| Skeleton bones | 26 (21 effectively weighted) | ~130–133 (26 legacy + ~106 Bento) | ~5× | Avalab; Inara Pey |
| Joints per animation | 32 | 106 | ~3.3× | Nalates |
| Visible triangles (typical outfitted) | ~5,000 | ~50,000–280,000 | ~10–55× | SL Wiki: Rendering weight; Ryan Schultz |
| Per-object triangle cap | n/a (prim/sculptie) | 174,752 (8 faces × 21,844); animesh 100,000/LOD | new ceiling | SL Wiki: Mesh/Technical Overview; Animesh |
| Complexity points (typical) | ~1,000 (base) / 100 (bare) | tens of thousands to several hundred thousand | ~10–350× | SL Wiki: Avatar Rendering Complexity; Reddit |
| Rigged mesh multiplier | rare (mostly unrigged prims) | ×1.2 per prim, processed sequentially | linear with avatar count | SL Wiki: Rendering weight; Reddit |
| Bones per vertex (skin limit) | n/a (system avatar) | 4 | fixed ceiling | Bento rigging tutorials |
| Texture maps per material | 1 (diffuse) | multiple (PBR: base color, normal, metallic/roughness, AO) | several× | Linden Lab FAQ |
| Max texture resolution | 1024² typical | 2048² (2K, officially supported; 4K/8K discouraged) | 4× pixels | SL Wiki: PBR Materials |
| Material-pass draw calls (modeled) | ~10 | ~55+ (70+ heavy) | ~5–7× | modeled from material-face counts |
| Render time per avatar (modeled, mid-range) | ~0.28 ms | ~1.8 ms typical (up to ~5.6 ms heavy/uncapped) | ~6–20× | modeled |
| Network requirement | 500 kbps min; 4–50 kbps steady | broadband standard; asset streaming rarely the limit | bandwidth up ~50–200×, role shrinks | SL Wiki: Lag |
| Engine-side mitigations added | ARC display, impostors | Avatar Rendering Complexity, jellydolls, max-complexity slider, impostor count cap, PBR LOD, 2K cap, animesh triangle cap | defensive limits | SL Wiki: Avatar Rendering Complexity; Animesh |
Asset complexity scaling vs. engine optimization
The chart shows that typical outfitted-avatar triangle counts have grown far faster than the engine-side caps and mitigations Linden Lab has layered in. The caps (ARC, animesh’s 100K triangle limit, the 2K texture ceiling, jellydoll thresholds) are reactive defenses — they bound the worst abuse cases but do not reverse the fundamental ~20–90× growth in per-avatar geometry. Bento (2016–17), Animesh (2018), and PBR/mirrors (2024) each marked visible step-changes in what a single avatar could cost the renderer.
Modeled Performance on Mid-Range Hardware
Per-avatar cost
On a GTX 1660 / RTX 3060-class GPU at 1080p, the modeled per-avatar render cost rises from roughly 0.28 ms for a 2008 classic avatar (~5K visible tris, ~10 draw calls) to 1.1 ms for a 2016-era mesh avatar (~80K visible tris, ~28 draw calls) to 1.8 ms typical for a 2026 Animesh/Bento/PBR avatar (~250K visible tris, ~55 draw calls). Heavily/unoptimized outfitted modern avatars — dense alpha layers, many separate rigged attachments, uncapped animesh — can push per-avatar cost toward ~5.6 ms, which is the regime where even a handful of avatars saturate the 16.7 ms frame budget. The growth is driven by three compounding factors: triangle count, material-face/draw-call count, and PBR fragment cost (including mirror/reflection passes that re-render the scene).
Frame stability under load
Frame stability is where the era gap becomes stark. Modeled 1% low FPS (the slowest 1% of frames — what users actually perceive as “stutter”) stays above the 30 FPS floor for 2008-era assets even at 40 avatars in view. For modern (typical, ~1.8 ms) assets, the 1% low crosses below 30 FPS at roughly 12–15 avatars and collapses to single digits by 40; with heavy/uncapped modern avatars that crossover arrives even sooner. This matches the documented behavior that drove the jellydoll system into existence: without the Maximum Avatar Complexity setting actively culling heavy avatars to silhouettes, crowded modern regions are unrenderable on mid-range hardware (SL Wiki: Avatar Rendering Complexity).
Modeled render-time budget (60 FPS = 16.7 ms target)
| Scene (mid-range GPU, 1080p) | Modeled frame time | Modeled 1% low FPS | Bottleneck |
|---|---|---|---|
| 10× 2008 classic avatars | ~3 ms avatars + ~6 ms world ≈ 9 ms | ~55 FPS | Balanced / network on first load |
| 10× 2026 typical Animesh/PBR avatars | ~18 ms + ~8 ms ≈ 26 ms | ~32 FPS | GPU rasterization + draw setup |
| 30× 2026 typical avatars (jellydolls off) | ~54 ms + ~8 ms ≈ 62 ms | ~14 FPS | GPU + CPU draw-call submission |
| 30× 2026 heavy/uncapped avatars | up to ~170+ ms | ~6 FPS | GPU + VRAM exhaustion |
| 30× 2026 avatars (max-complexity cull on, ~5 non-impostors) | ~28 ms + ~8 ms ≈ 36 ms | ~28 FPS | GPU, but stabilized by culling |
The last row is the practical reality: modern SL only stays playable in crowds because the viewer aggressively demotes most avatars to impostors or solid-color silhouettes, offloading the cost rather than paying it.
Row key: green = playable headroom · blue = on the edge / stabilized by culling · gold = below the 30 FPS floor · gray = collapse regime.
The Bottleneck Shift: Network → Local Compute
2008: network- and asset-stream-bound
In 2008 the dominant frame-time pressure was download and decode of scene data. Legacy-era SL Wiki guidance stated that scenes “have to be downloaded and then transformed into the 3D view in real time,” that draw distance was “the single most important control that affects lag,” and that even after settling, 4–50 kbps of steady streaming was required just to keep up — with a 500 kbps connection cited as the floor for running SL adequately (SL Wiki: Lag). The Statistics floater of the era exposed Net Time (time responding to incoming network data), New Objs (objects downloaded per second), Images Time, and Bandwidth as first-class metrics (SL Wiki: Viewer Help: Statistics). Geometry was small, so once data arrived, the GPU had comparatively little to rasterize.
2026: local GPU/CPU/VRAM-bound
Today the network has effectively dropped out of the steady-state bottleneck. Persistent texture caches on SSDs, much higher residential bandwidth, and the fact that most assets are already in cache mean Net Time and Bandwidth are usually idle after a scene’s initial load. Instead, the frame budget is consumed locally:
- GPU rasterization / fragment shaders (~44% modeled): PBR’s multi-map materials (base color, normal, metallic/roughness, AO), 2K textures, shadows, and especially mirrors/reflections (which re-render the scene) dominate. Alpha-blended layers carry a ×4.0 complexity multiplier because the viewer must render them even when visually invisible (SL Wiki: Rendering weight).
- CPU scene traversal + draw-call setup (~30% modeled): every material face on every rigged attachment is a separate submission; rigged mesh is processed sequentially and scales linearly with avatar count (Reddit r/secondlife).
- Texture decode / VRAM pressure (~14% modeled): the Statistics floater’s Texture GL Mem, Texture Raw Mem, and Texture Bound Mem fields track exactly this — and community discussion of PBR repeatedly centers on VRAM exhaustion (Reddit r/secondlife).
- Mesh skinning (~6% modeled): ~130 bones per Bento avatar, 4-bones-per-vertex skinning, applied to hundreds of thousands of triangles, sequentially per avatar.
Why the shift happened
The bandwidth available to a typical user grew ~50–200× (sub-megabit to multi-hundred-megabit), while asset geometry grew ~20–90× and material/texture cost grew ~5× per material with mirrors adding full-scene re-renders. Network capacity outpaced asset growth, so the network stopped being the binding constraint. Local compute capacity grew too, but slower than asset complexity — and crucially, the work is per-avatar and sequential, so it scales with crowd density rather than with hardware headroom. The Linden Lab mitigations (jellydolls, max-complexity culling, impostor caps, animesh triangle ceilings, the 2K texture limit) are all admissions that the local renderer, not the network, is now the thing being protected.
Practical Implications and Recommendations
- For creators: every material face is a draw call and every rigged attachment is sequential work. Consolidating materials, respecting the 21,844-tris-per-face and 174,752-per-object ceilings, using proper LOD (50–75% reduction per level), and avoiding unnecessary alpha layers yields disproportionate gains because alpha carries a ×4.0 multiplier (SL Wiki: Rendering weight; SL Wiki: Mesh and LOD).
- For users on mid-range hardware: the single most effective setting is Maximum Avatar Complexity plus a low Max # of non-impostors — this is the difference between 6 FPS and 28 FPS in a 30-avatar crowd, per the model above.
- For the platform: the bottleneck shift implies that future performance gains depend less on networking and more on renderer modernization (batching, instancing, GPU-driven culling, material/texture streaming budgets). The 2024 PBR/mirror rollout increased per-frame GPU cost precisely in the area that is now the binding constraint, which is why it triggered widespread VRAM and frame-rate complaints despite leaving the network untouched.
Limitations. This report models rather than measures. The specific millisecond, draw-call, and 1%-low-FPS values are order-of-magnitude estimates derived from documented complexity formulas, triangle ceilings, and rendering-cost relationships — they are intended to illustrate the direction and relative magnitude of the shift, not to serve as a calibrated benchmark. Actual figures vary widely with graphics preset, draw distance, shadow/reflection settings, avatar mix, and GPU driver. Where a hard SL-specific draw-call count was not available, the estimate is labeled as modeled and grounded in the material-face-to-draw-call relationship. The qualitative conclusion — that the bottleneck moved from network/asset streaming to local GPU/CPU/VRAM compute over fifteen years — rests on documented wiki specifications and is robust to the modeling uncertainty.
My Take
It isn’t possible to go back in time to take measurements. So modeling by use of the specs on 2008 hardware and analysis for SL content in the 2008 era is the best AI could do.
For my purposes I think it did well. It certainly put it together faster than I could have.
I think it also shows memory (RAM) and graphics (GPU & video RAM) support are more important than CPU. That CPU shift is more of a post 2016 thing. Down sizing the CPU (i5 vs i7 and up) is also a money saver. But CPU speed is still a big thing.
Reading through the report I think the Lab is adding features which consume hardware advances. This hides the performance gains. While we can go twice as fast, we have twice as far to go. Or… we can do twice as much.
As it is now, running Firestorm on an Intel Core Ultra 7 265K @ 5.1MHz only 34% of the PCore capacity is used on average. So I have room to tweak the viewer to do more and consume some of the 64% idle time.
🙂