Second Life Still Struggling With a Crisis of Poorly-Optimized Mesh Items — But Here’s How Linden Lab Could Start Solving the Problem
Content Creation Blog Which Also Corrects Misinformation
First is education, which a lot of people dismiss because education by itself won’t do much.
But you need to put the information out there so people can understand the other steps you take. I’ve always felt Linden Lab should create an official blog of sorts that focused on content creation. Showing good examples, creating bad examples and explaining why not to to do that, holding contests to encourage the community to get involved, that sort of thing.
Importantly this would serve as an official source those who understand the importance of optimization could point people towards when we see misinformation being spread.
Plenty of content creators in SL, either out of ignorance or laziness, will try to tell you their high-poly, VRAM bloated content doesn’t impact performance and right now there is no official Linden source to contradict that. It’s also important that having LL coming forward about content and performance would help spark a broader community discussion about the issue.
Better Tools and Optimization Warnings in the UI
Residents need better tools, both to manage their own resource use, but also tools to better understand where the lag, FPS drops, and other performance issues they experience are coming from.
For example, if I attach an item with an excessive amount of textures or polygons, maybe there should be a warning about the performance impact? Perhaps if my avatar in total exceeds a certain amount of triangles/VRAM I could get a warning about that?
“Your avatar is using over 200,000 kb textures, this can result in lower FPS and longer rez times for yourself and those around you.” and this warning could escalate the larger your performance impact is. If avatars around you are the problem, perhaps the viewer could recognize that and suggest you enable the “jelly dolls” feature, or lower the caps on it.
If the environment is the problem, perhaps the viewer could suggest capping texture resolution at 512×512. Give people the information they need to understand the problem, and the tools they need to deal with the problem.
System Limits on Poorly Optimized Content
Finally, and this is the one everyone hates to hear, but we need hard caps on resource use.
There is absolutely no reason any avatar should be walking around using 500,000 kb of VRAM, let alone 1,000,000. Ideally avatars wouldn’t use more than 100,000 kb but I don’t think Linden Lab should be that strict. I’d give avatars 200,000 or even 250,000 kb.
But what happens when you reach that cap? I don’t necessarily believe you should be prevented from wearing any more beyond that. Instead SL could put a maximum texture cap on just your avatar. Reducing the maximum texture size of your avatar’s textures until you fall below the cap.
For most people, this would be a 512×512 cap and they’d probably never notice. For more excessive avatars it would become more obvious as they hit 256 or 128 caps. For triangles we’d probably need a system more like Land Impact.
It’s important to note that Linden Lab is currently working on rendering pipeline improvements that will give us some substantial framerate improvements. We’re talking double the framerates you currently see.
But if you’re typically seeing 10-15 FPS that still only means 20-30FPS with the new pipeline. And that FPS can still drop when you’re moving around as opposed to standing still.
So, at this point, I still believe encouraging optimization is something Linden Lab needs to take seriously.
Hard agree. Linden Lab’s own efforts to optimize Second Life with cloud rendering and so on are regularly undermined by poorly optimized user content.
window.fbAsyncInit = function() {
FB.init( { apiKey: ‘a279adbe87e2b3c505e777af99a5260d’, xfbml: true, version: ‘v2.8’ } );
};
( function() {
var e = document.createElement( ‘script’ ); e.async = true;
e.src = document.location.protocol + ‘//connect.facebook.net/en_US/sdk.js’;
document.getElementById( ‘fb-root’ ).appendChild( e );
} )();
Source link