SL Client Performance... What's killing it?

Just so I don't upset any fanbois that may hang out on this forum, I want to make it clear that I do enjoy SL, and that my interests are only in seeing it improve. I am new to SL, and I have just purchased my first 1024m hunk of waterfront property. I expect to be a member of the community for years to come........



I've been gaming online pretty much since day 1 of online gaming began, at least so far as modern 3D games are concerned. Hell I even played DOOM death match via modem back in the day Over the years I have always built my own gaming machines, and I have always made sure the specs of my machine well exceeded the cutting edge titles by a long shot. For example, my current computer, which is almost ready for more upgrades, features:

Athlon 64 FX-53
Gainward 6800 Ultra Golden Sample (factory over-clocked)
1 GB of Corsair TwinX XMS Ram
Sound Blaster Audigy 2 ZS Platinum
..and other goodies

I know it's not the current cutting edge, but it was a few short months ago, and I can play the most intense 3D Titles such as Half Life 2 and DOOM 3 at 1600x1200, 8X AF, 4xAA and highest model and texture quality settings with no problem. I have yet to run into a new game that slows my machine down..... until SL. For those of you who think something may be wrong with my computer, I also have another gaming machine which is an Alienware Area 51m 7700 that is only a month old, and it too gets the SL beat down while performing flawlessly with all my other games.

I am very new to SL, but I have been following 3D tech for over a decade. SL reminds me of VRML, a technology I hoped had died permanently. I have always though that the next version of the world wide web, the 3D version, would manifest out of 3D game technology. It's no secret that the dollars created by the entertainment industry drive a lot of new technology forward. For example, people will probably buy robots for the home as entertainment gadgets long before they are considered common place everywhere else. WOW.. I am digressing, bigtime...

My question is, what's the problem with the SL client? I understand that you are streaming the 3D math, and textures. Even still, on a 5Mb internet connection, and a CPU like mine, how is it that SL is using so many resources? I assume you aren't using much of my GPU (video card), because the temperature doesn't go up even a little when I'm in SL, unlike all my other games. If I even turn the graphics settings in SL up to moderate settings, it practically kills my machine. Based on this information, I have to assume that most people, who probably don't have a high end gaming machine like I do, must have to keep their settings down to almost nothing in order to enjoy any fluidity.

Do we have any idea what is being done to improve the overall performance of SL? Knowing my countless gaming friends online, I think it would be a huge turn off for a lot of them to have a world like SL, which seems pretty far behind in graphics technology, give their gaming machines the beat down like I am getting. Clearly SL doesn't really take advantage of high end GPUs and it looks to be using the CPU for nearly everything. Can anything be done, or do we just have to hang in there for 5 years while computers get more powerful?

Don't get me wrong. I am well aware that SL is not a game with static maps, textures, geometry, sound, etc which are pre-loaded from a map file like most games. However, I think SL falls short of any minimum expectation a "gamer" might have of it's 3D performance.

You may begin flaming...........now.

In a word? Textures.

SL uses an incredible amount of texture memory. Perhaps more importantly, it loads them in and out of your video card's RAM on the fly, no small task to be sure.

You're right, the client isn't GPU-bound, which limits what it can do on a really high-end video card. It's mostly the textures, though.

I have to ask, why are we so limited in primitives if textures are the real bastard?

Catherine,

I know textures are part of the problem, but what about, for example, if you are standing in a dance club in SL, and they turn a bunch of lights on? I already have all the textures loaded, and with the lights off my machine is fine. Turn a few moving lights on, and the client chokes bigtime. It's not just my computer though, cause at times like this when my frame rate seems to drop to 2fps, I can alt-tab out of the game window, and perform other functions in windows without much problem. This tells me the client isn't using the CPU very efficiently. Cause it seems to choke all by itself.

So based on what you are saying, the bottleneck for SL is memory bandwidth? That's not good at all.

Eggy, if Im taking a guess at your question, I would say that more prims = more textures. The more things people are building and displaying in the world, the more textures will be visible as well.

Does SL do anything to require compression, or does it compress them automatically? So far I have uploaded some seriously large texture files, and SL has not denied me at all.

sl compresses texture when you upload them. i think textures over a size get resized smaller too but i couldn't tell you the right size off the top of my head. maybe anything over 512x512? do a forum search because there have been threads in the past about that.

Correct. The more prims in use, the more textures being loaded. It's not "fair", but it's a very easy way for the Lindens to limit the amount of data that has to be rendered.

Also, remember that while SL uses JPEG2000 compression to keep filesizes low for storage on the server and for short download times, those images must be decompressed before they can be manipulated on the client, so the raw texture data will really eat up the video RAM.

Anything over 1024x1024. Also, textures with resolutions that aren't powers of two get resized to the nearest power of two.

thanks Eggy.

by the way if anybody's using 1024x1024 textures they are an evil person and they need to die and also stop raping kittens. a 256x256 texture with a 50% unsharp mask in photoshop looks great on a 10x10 prim with no repeats. stop killing my computer!

I don't think SL's graphics engine is cutting edge by any means, but you should also bear in mind that what SL does is way, way more complex than any PC game like Doom3. It's far more compelx than most other MMORPGs as well.

Without going into too many details, if you've ever designed a level for a 3d game you'll know that most engines have a bunch of restrictions on what you can do in order for the engine to work. It's those restrictions on the level design that lets the engine run at high speeds (the fact that it's loading of your harddrive and in most cases doesn't change during gameplay helps a lot!). SL really has no restrictions appart from the prim limits.

Not to hijack the thread, but I had to chime in here. Under most circumstances I agree with you, Zuzi, but there is a legitimate use for large textures. I almost always use textures at 512 or 256, but I do have one (just one) in use that I had no choice but to make 1024. On the floor of the Sci Fi Museum is a map of the galaxy. I tried and tried to make this texture 512, but there is simply too much information on it. The font has to be small because there are lots of star systems labeled, and going any smaller than 1024 image size makes the text illegible. 99% of the time you're right; there's no legitimate reason to make a texture any bigger than 512. Every once in a while though, it does need to be done.


Okay, back on topic. I agree with you Oceas, that from a gamer's point of view SL seems to be an incredibly sluggish resource hog. However, as you and others have pointed out, SL is doing things that no standard game does. Even Doom3 with its brilliant use of raytracing and dynamics is able to benefit from the fact that it operates entirely in a finite, predefined manner. Everything in it was desgined purpousfully by its creators so that it all works together as a seamless whole. As such, there's nothing you can make it do that will tax it. It just does what it does.

SL on the other hand is constantly changing, and its design is always at the mercy of not a team of well-trained professionals, but thousands upon thousands of individuals with varying degrees of skill and conscience in regard to making it operate efficiently. Go to a well-built private island some time and you'll see that your can significantly crank up your settings and still get a great frame rate. Go back to the mainland though, and then you're at the mercy of all the hundreds of inefficient textures, scripts, and geometry in your vicinity.

I completely agree that lots of improvements are needed (and many are on the way) in respect to the way in which the viewer operates, but there's just no way we'll ever experience the same fluidity in SL that we get in regular games. It's just not possible.

That may be a good thing by the way. If we ever reach the point where SL is "finished", it would likely get real boring real fast. The fact that our creations keep pushing the software further and vise versa is perhaps the greatest part of what makes SL so exciting.

Anyway, LL has promised a new rendering engine in the near future. Hopefully it will overcome many of the limitations of the current one. We're all wondering just how near that near future is, but all we can do is wait.

Richard,


I think you replied to my thread without reading my entire post. go back and read the last paragraph again. Thanks for joining in though

Chosen, I totally agree with you about the users pushing the software.

I'm sure LL has thought of this, but the model they are using has huge implications on the future of the world wide web / internet. I mean they are doing that VRML tried to do to some degree. If this technology can be pushed in the right direction, we may all very well be pioneering users of the true "3D cyberspace". Sounds romantic and geeky to me. I love it.

ROFL.

Also, I made a suggestion that LL looks at how SOE handles development information of Star Wars Galaxies as a model to use for communicating with the SL user base....

/18/b2/35271/1.html#post393769

I turned on the debug console (ALT-3 or ALT-4, i forget) last night during some horrendously bad performance (< 1 visual fps). To be fair, I have never seen a dual-processor sim lagged so badly (~40 sim fps) but I saw some odd artifacts.

The first was that render object was taking a constant 80% of the SL processing. This despite having turned all rendering off and "View Updates" showing nothing changing. The other oddment was that the text console was showing my bandwidth being throttled step-by-step down from 500kbps to 30kbps even though there was no network traffic, no loss, and WinMTR showed the path from here to LL well connected. Relogging didn't change anything.

Now, of course, it isn't happening. The worst bug is an unrepeatable one...

Chosen you get a special one time only Evil Person Who Rapes Kittens exemption for your museum floor. if i remember it right that's alot bigger than a 10x10 prim anyways isn't it? probably 4 of them i'm guessing.

did you ever think of making it 4 512x512 textures? i know that's the same as a 1024x1024 texture but it might make things seem to load a little quicker if it was broken up since part of the floor might finish downloading sooner than if it had to download the whole thing all together. just a thought.

the world would be so better if the SL screenshot maker was uploading at lower resolution by default

not everybody use photoshop to redo his item pictures or resise em to smaller sise
i use 256x256 for every pictures of my products ingame to keep my vendor load low

- stop using timers like crazyor use SLOW timers (not everything need realtime data processing, you can afford a delay i am sure),
- use animated texture to change prim color on a regular basis,
- do not make settext blinking or changing colort every 1/10 of second
- should not set everything to light so it look brighter.
- kill every listen that arent explicitly needed
- remove as many as possible vocal commands
- do not use 1024 x 1024 texture exepted if no other choice (like said in above post)
- learn to recycle your texture database
- stop using alphas like mad to cut down primcount (build better)
- try to work with the built in delay in script functions, not agains (multi tread)
- try to reduce the emission rate of particles generator (what look good at one speed isnt looking better if speed is doubled);
- do not use sensor repeat at crazy speeds and keep sensor ranges to the minimum necessary

You can be build great things or script cool stuffs , but if you cannot respect the system limitations and try to use as less as possible ressouirces, then your work is just plain shit that will just add lag to the already sluggish system.

To clarify, sims that show up as 0.50 CPU aren't dual-processor servers, they're single-CPU servers with hyperthreading. They're not dual-CPU, not dual-core and it doesn't mean that there's more than one sim running on the same hardware.

However, filler sims that show up as 0.25 CPU are multiple sims running on the same hardware. (Four, if you're not up on addition.)

Can you expand Kyrah? I thought using Alpha channels would be a GOOD thing for êrformance by lowering the overall number of textures and prims needed?

No, alphas require more rendering overhead and demonstrate why using prim limits to control texture usage can backfire dramatically.

eltee disagrees with that statement in that sims above 455 are duel Opterons

"3) the new hotness (these are the dual opteron systems that make up the latest hardware Their performance is absolutely outstanding even though one hardware box runs *two* sims (one on each opteron cpu) They are the sims 455 or so and above. Lusk on these runs about 1400 fps with one agent, about 800 fps with 10 agents"


Since eltee and the Lusk bunch were the ones who brought up the performance issue and worked with LL in identifying the problems by testing the sim with different servers, I kinda think they may know what they are talking about. Folks may be thinking that just because a sim is showing .50 CPU its automatically a duel processor which isn't the case necessarily.