Alright kids... Graphics Engine... time to rant.

Ok, Lindons, first off, great game, killer flexibility, great customability and programming interface. And the new gesture implementation is great as well as you guys apparently took my advice on the audio streaming...

Everything is great... except for that horrid graphics engine...

I have a monster system, why does SL still run like ass? It runs exponentially crappier than any other 3d app on my system, I've tested on two different mobo's sets of ram and both top end Nvidia and ATI cards.

Where's the bottle neck, guys?

I mean, c'mon, at 800x600 on my system, I should see somewhere in the neighborhood of 80-100fps... instead I get like 15... and everythng hasn't loaded yet. Some people get OK performance if they're willing to comprimise on very basic settings... like lighting or water waves... I mean c'mon...

Explain it to me. Why does the graphics engine suck across a multitude of platforms. I guess if you're running a Athlon XP 1800 and a GeForce 2 MX, you'd be happy with the performance because it's the same exact performance you'd get on MY machine and my friends machines...

Everything's perfect... cept for that. And it just so happy that it's the most irritating issue with SL that happens to fill my entire screen.

Here are my specs for your information.


Asus A7N8X Mobo with all updated chipset and bios software
AMD Athlon 3200+
1GB Corsair PC3200 XMS ram running in Dual Channel
ATI Radeon 9800 Pro /w 256MB option
Windows XP SP2(tested with XP1, still sucked, just fyi)
DirectX 9.0c

Couple of my friends have Intel processors with intel boards and ATI and nVidia cards. it all sucks. I dunno, maybe I expect too much... Maybe I"m just a snob. I guess other ppl are happy with it.

I think you guys have done some really great things and I have complete faith that you can answer my questions and / or provide a solution for me.

This post is by no means a slam on the software, it should be interpreted as constructive critisism with a slightly darker slant as far as my humor goes. In other words. Don't get offended.

Peace, all.

I think the confusion arises because SL has to constantly stream the contents of the world to you; there is the bottleneck as it can't even count on the world staying static long enough for you to spin 360 degrees. There are other *major* optimizations that quake can do - because the world is largely prefabricated - which aren't available to SL.

SL is not Quake. 15-20 FPS is considered by many to be suffiicient and the best than SL can afford. You can see peaks higher than that (Alt-1 for stats) but the norm is slow by FPS standards.

You can read more on the website under "about second life>technology".

Have you ever played There? very basic set of textures just like SL. Most object placement and orentation are streamed. Only complex textures are stored on the machine. Don't get me wrong, I completely understand how the technology works.


And secondly... streaming the objects into the engine has nothing to do with the speed of the engine, especially since it's OpenGL from what I've heard. If what you said was true about the streaming being the bottle neck then why is it I don't do 100fps when I stand facing a wall. openGL only concentrates on textures and objects within view of the observer.

Two guesses about your "stare at wall example": a) inefficient client code b) frame limiter because the client knows there is nothing changing in your view.

There is also tons of back-channel info flowing to your box, press Alt-4 for barely decipherable stats.

Ok, that's a good example.

Now let's fix that. I know it can be done. Thanks for your replies, mate.

Streaming isn't the bottleneck. It's the reason for the bottleneck.

If the world isn't static, you can't precompute lighting.
If the world has more than eight dynamic light sources, you can't offload lighting to the graphics card.
If the world isn't static, you can't precompute occlusion testing.
If the world isn't static, you can't reuse meshes.

Further, SecondLife has larger textures than any game -- it supports textures up to 1024x1024, and some legacy textures may be even larger.
SecondLife has more transparency than most games.
SecondLife has a wider variety of polygon meshes than any game.

Now I'm not going to pretend to have a clue what I'm talking about here, BUT I have played There and it was a humungous download compared to SL, which I thought was because of the streaming issue, I didn't think There was streamed to the PC in the same way as SL therefore it tends to run quicker.

Larissa

Ok then, well if we know why, then why don't they fix it? Find the happy medium. Don't use 1024x1024 textures for cryin out loud.. Fix it.

Well if you wanted to limit the texture size that would cause even more lag, most of the 1024x1024 textures uploaded to the SL server are progressivly downloaded, if you forced them all into lower resolutions like 512x512(like it does with the AV)load times increase because it has to re-size the file before it sends it. As for high frame rates...I'm happy with 7-10 on my evil Charter internet service and I do quite well running everything else under the sun, I don't think that frame rates will get much higher until object density decreases, or parts of SL become static, then the client file becomes larger.

Good point, friend.

I think however, that they should go ahead and comprimise the client size for better bandwidth and engine handling. Just my $0.02 on that. If that's what it takes to make the game smoother, then so be it.

well what parts are you going to make static? Linden sims? I do think a static area system might be neet though, enclose the parcel of land in an invisable boundery box, maybe have a few smaller ones that do exclustions then when the next update comes, changes made in the major boundery box are uploaded...but then you run into the problem of everyone doing it and ending up with a 20 gig client file for all the sims but it's kinda a nifty idea.

Think of it this way...

If you make the client 500MB installed and you're biggest mass is standard textures, the ones the lindens use most of, like land, sky, woods, shit like that. Then that's 480MB of shit the user doesn't have to DL. And then you use a texture cache for ppl with custom textures like signs, clothing, items, etc...

You make that cache say... 500MB as well. ok... before I get flamed, I know there's already a disk cache but apparently, if this is the bottle neck then it's not working properly.

You make this cache download ONLY custom textures and save them along with the linden standard textures. Then you make the client check to see if it already has the texture on disk when a new item enters the FOV and if it does then it reads it off disc and loads it just like any other GL game. If not, then it streams it from it's origin just like SL always does. Best of both worlds and I think as much as some ppl play this game, just like say Doom 3 or Farcry, they'd be more than willing to download a 500MB client....

At the same time... I think the 20MB download should be availible to those users who CHOOSE not to have the disk cache or the linden texture database. So that those that are already satisfied with the game may continue to do so.

How's that sound?

It's an interesting idea, I don't think I'd have much use for the linden texture base myself I rarely see them anymore but to the average user it might be worth it, the progressive texture cache is a good idea too, and it may or may not reduce lag, since I'm unsure how files are stored on the linden sever(as far as textures go)it could rename them upon upload(to a UUID number or something like that) and just tack on an extra bit in the file the that retains the name or the user/s to look at, or it could go into it's own folder under the user name then be swapped around when it's passed to users or be linked back to the folder of origin. If it's a number then you could have two textures that are exactly the same but have two different numbers(this happens a lot with me for clothing and animation revisions). If it's a folder structure though it just has to copy it...the other problem I think with keeping a non-temp user texture cache is the possibility of being able to access the data in the file and reupload textures, especially with clothing, a 3000$L outfit could be seen by someone then uploaded themself for 10$L.

ABout the outfit thing... theoretically, that's possible now while you're standing right in front of someone. You have to DL the textures to somewhere to view them.

True you can take their picture and modify the crap out of it to make it work, and yes the you could do the same thing now if you can crack open the main data file(which accually does house some of the most basic things in SL like animations and such) but having it in it's own non-cycling file seems to make it easier...

As far as I know, the disk cache gets deleted when you close SL. So it's not really a short cut for the engine.

*pokes at the file*nope still there atleast on my system, true I've only poked at it with anything more the wordpad but it's there, when SL closes the only thing that gets deleted are the .dsf files(sound files), object possition files stay there and the main data.dx2.(some random number here depending on the size)stays, and if you have crashes occasionaly you can have multiple versions of the cache, I had SL up to 9 gigs at one point

see, if it's getting to 9GB... you should see a dramatic improvement in graphical performance. Heh. Thanks for setting me straight on that info.

well SL doesn't look back at the other eight instances of cache, it only looks at the first one, and even then it is forced to check for texture updates and such every now and agian

480MB of static data? Drop in the bloody bucket. The last I heard, the SecondLife dataset was around 80GB, and that was a long time ago. Damn near every texture is custom, and people tend not to be very good at texture re-use. Every prim is unique, and even if one prim is only a KB or two of data, you may need to download 15,000 of them when you enter a sim.

The common Linden textures are the ground textures, the default "plywood" texture, the default particle, and a few assorted things like the moon. If you play for more than a few minutes, all of them will end up in the disk cache. Everything else is either custom or dynamically-generated.

Streaming the data itself is not the direct cause of low framerates. The direct causes result from the need to stream the data.

It's quite impossible to have a downloable texture "package" for SL. Stuff that's common changes so much, it would be useless.

Everything in SL is streamed. Everything.

SL is insanely ahead of its time. Wait 5 more years when even the most basic e-machine can run SL.

LF

Ok, so what you're trying to tell me is that because of this streaming silliness, my computer only FEEDS my video card 10 fps? Have they thought about using Direct 3d instead of GL?

That doesn't change the lag, it just means they have to rewrite the engine from the ground up and then you'd get lower FPS(on the whole OpenGL is usualy simpler to understand then Direct X)

DirectX would tend to work somewhat poorly on the Mac port as well.

An observation:

Bandwidth helps a lot.

I'm mentioning this because with a low end system (1.2 Athalon, Geforce 2MX and 512mb of Ram) I still get and average of 22+ fps at home. With my new 3ghz machine with 1 gig of Ram and a PCI Express X300 I average over 30 and have peaked over 60.

I suspect one of the reasons for this is I'm on one of the first cable modem nodes in the US. At this point I think I share bandwidth with maybe 4 other users, so, even though some of the equipment on the node is old, I'm consistently getting better than T1 downloads at my house.

Obviously there isn't a real solution to node bandwidth sharing except to make sure you're as clean as possible. This means don't run a P2P file sharing program at the same time as SL. Also, hosting a Counterstrike or NeverWinter Nights server on another machine on your home network will impact Second Life's performance.

Finally, I know, due to some issues with the ATI driver LL did disable AGP acceleration on the ATI cards because there was no perfomrance difference. So your 9800 may also be some of the "drag" on the system, but, ultimately, I'd guess a lot of the problems you may be experiencing are due to bandwidth limitations through your ISP, be they metering your usage and capping it, or because you're sharing bandwidth with 25 other people, 5 of whom are kids on summer break who have 80 gigs of mp3's they are sharing on P2P networks and have requested another 20 gigs to download when they come up again.