A much better graphics engine!

That's what SL needs!

Don't get me wrong, as a first effort it's impressive. And I fully understand the rendering difficulty in coping with a totally dynamic world, but still: In comparison to the absolutely stunning technology behind the network programming of SL, the graphics engine falls very short.

It chugs to a crawl on simple scenes. (And I'm running on the latest ATI 9800 card.) The texture management is poor (how about more terrain texture detail on what's right under my feet instead of complicated detail on a model that's dozens of meters away!) The lighting model is almost non existant. The level-of-detail tech needs a lot of work.

I don't mean for this to sound like a rant, but as a programmer myself I'm really blown away by the incredible network/server technology in SL and at the same time so let down by the poor rendering engine. I can't help but think of how much more immersive SL could be if it had a more modern graphics engine. Sure, the challenges are unique (primarily because it's a totally player-built and fully dynamic 3D world), but I'd love to see LL apply the same effort towards coming up with a next-generation graphics engine as they have obviously put forth coming up with THE next generation massively-multiplayer server/network architecture.

Anyway, here's hoping. If LL can put a bunch of effort in, and the next major patch version of SL sports more recent/enhanced rendering technology, I think SL really has a chance of becoming a huge hit.

paulb

You're absolutely right!

Oh wait a second, this is the first graphics engine of its kind.

Hrmmm... maybe in Second Life 2?

In all due seriousness, I think that Second Life's graphics are used as building blocks. The transition from 1.0 to 1.1 upgraded a LOT of graphical things, piece by piece, rather than just overhauling.

The time will come when Second Life is as beautiful as Half-Life 2. I wholely believe this

The problem with the rendering engine isn't really a problem, it's that it's a couple years ahead of it's time.

You can have the fastest, best 3d card on the market, and still chug. Know why? Because your processor is still throwing at the card all the hundreds or primitives (that has to be rendered in full splendor, rather than just what's visible) every second. Not only that, but calculate where in world they are, in real-time, plus get the right textures and apply level of detail to them.

It's a wonder my computer can even handle it... but if I go flying around, I can almost feel my processor going into "holy crap" mode

SL's rendering engine doesn't just need a fast 3d card... it needs fast everything.

LF

It's good to hear that 1.1 was a significant upgrade to the graphics engine (I am a post-1.1 player . Hopefully they will continue to focus effort on this, since it is the one (maybe the only one!) area that is sorely lacking (compared to the "competion" of other very-good-looking games such as HL2 or others (and like I said, I fully understand that it's much more difficult to make a dynamic world look as good as a pre-designed one like HL2... but I still think there is a lot they can improve on even so.)

paulb

I wish people would get that this game doesnt HAVE "graphics". If it was a single player game like half life 2 what you would see was an empty green patch of land and then its up to you to build your own "graphics".
Complaining that SL has poor graphics is like complaining that autocad has poor graphics.

Could you tell us more about your system?

SL is primarily CPU-bound. Upgrading to a new video card will net you some improvements, but upgrading to a significantly faster CPU will net a much bigger performance increase. Let me explain some differences between SL and your run-of-the-mill online first person shooter.

UT2003, Doom 3, Half-Life 2, etc:

1. Get to do occlusion culling, since they are working from nice, pre-calculated BSP trees - this is exponentially faster across the rendering process than SL's frustum culling
   
2. Get to have most of their lighting pre-calculated
   
3. Use skyboxes for drawing the sky
   
4. Have rudimentary weather - fixed sunshine or rain or wind or whatever
   
5. Do not change the time of day during a session (i.e. a level)
   
6. Do not have to account for many changes to the structures or terrain during play, if any at all
   

SL:

1. Does frustum culling - nowhere near as efficient or speedy as occlusion culling; SL cannot realistically rebuild a BSP map of everything within your draw distance every frame (maybe if you had a 10GHz CPU)
   
2. Has to calculate lighting for textures itself, since a typical SL scene can easily have hundreds of lights - current GPUs cannot handle that by themselves, and there is no way to cull out "unseen" lights within the camera's FOV, since there is no BSP tree
   
3. Dynamically calculates the sky based on sun angle; not only do you get a moving sun and moon, but the entire sky itself is dynamically generated, and the entire landscape and everything and everyone on it are re-lit every time the sun angle changes
   
4. Uses a cellular automata system to generate clouds and wind in realtime
   
5. Allows any patch of terrain and any primitive to be changed at any time, and reflects such changes to every last "camera" looking at whatever was changed, in real time
   

Building a truly malleable virtual reality, particularly an online one, means you have to give up a lot of speed optimizations. Half-Life 2 is going to be a lot faster than SL because it has the luxury of using BSPs and other speed tricks that are simply impossible for SL. In HL2, if you stand in front of a solid wall, nothing behind that wall shows up in the BSP walk the CPU does every frame. In SL, there is no BSP, so everything behind the wall DOES get processed.

That was a great post, Huns, thanks for listing a lot of the differences that effect optimization. I know what a BSP tree is, and understand the benefit of compiling that information for a static scene ahead of time. Could you tell us how frustum culling works, roughly?

Basically, the frustum is your field of vision. It is so many degrees wide (according to the aspect ratio of your monitor) and as many meters deep as your draw distance. Since each sim is 256 meters on a side, and the draw distance has a maximum of 512 meters, this can easily encompass several simulators. Most people have a draw distance of 256 or below (I have a good fast machine and keep mine at 200).

So the viewer has to connect to several simulators at the same time, and each simulator has to figure out what amongst its objects and land and water and avatars and clouds and sprites (old particle system) and particles (new particle system) and whatever else the viewer can see.

And of course the viewer also has to talk to SL's data warehouse to load all the textures and sounds and whatever other stuff is attached to what it's in range of seeing.

On top of this, any updates have to be sent as well. Some updates are heavier than others.

Avatars are real FPS killers... you get a bunch of 'em in one place, and the simulator spends so much time sending data to all of them that it slows down. Physics will also do this... link a bunch of torii together to form a chain, and turn on physics for all the torii... it'll act like a chain, alright, but then the physics FPS drops and everyone feels like they're wading through cold molasses! (Moral of the story: don't make a chain out of physical torii.)

To get an idea of how frustum culling works, teleport somewhere and look at your mini-map. It will only load the terrain right in front of you. As you turn around, you can see it streaming in all the terrain and objects you weren't looking at before.

Thanks, Huns.

SL's appearance also suffers (in comparison to games)because of the lack of detailed, custom texturing (this is related to what Eggy was saying). Great games look good not just because of the engine but because professional artists work hard on them with the best tools. A lot of cool lighting and texturing in FPS games isn't the result of processing but of hand painting and clever baking. Many clothes in SL look better than most builds. People are motivated to spend the time on them, the Lindens provide (basically) unwrapped UVs for avatars, and users can accomplish it with Paintshop or Photoshop instead of Max or Maya. I made a sign carved in marble by modeling it in Max with about 10K polygons and using a render as a texture in SL, but I'm not going to spend that kind of time on every wall I make, much less on something with an "interesting" UV map or made of a bunch of seperate prims.

I believe your missing the fact that the SL engine is the first of it's kind, probably 3 years ahead of the rest of the world. SL is paving the way for all streaming 3d online games to come.

> A much better graphics engine!
> That's what SL needs!

Are you kidding me?!?!!!

Do you understand how ground-breaking this engine is?

Put it this way, I was trying to convince some friends/colleagues to get together and make something rather exactly like SecondLife, a couple of years ago, and no-one really believed it was technically feasible to pump sufficient content dynamically over the bandwidth available.

That it works, and works well, and you can even stick photos and stuff in, is just incredible!

Complaining about the SecondLife graphical engine is like saying Concorde is too slow.

ZHugh

Please don't misunderstand me. I think the SL engine, as a whole, is a stunning piece of technology. My original point was that it seems as though LL spent most of their time developing the network side of this technology, and less on the rendering engine.

As I mentioned earlier, I absolutely agree that their engine is a technological marvel from a network/server/sim standpoint. The point I'm trying to make, however, is that the SL rendering engine itself is not up to this level of technical mastery and I think it'd be great if they now spent their time polishing that side of things (which, as someone points out, it seems like they are doing, such as with the 1.1 patch.)

Huns, great post. I am aware of these technologies and have worked on most of them over the past few years. I still feel as though the SL engine could stand some good optimization work, as well as some aesthetic work improving their lighting/shadow model, their texture surface model, their level-of-detail routines, etc. I think, given what they've done, that LL has definitely focused on the right things up until this point (core server/network world-streaming technology, which is MOST impressive.) Now I'd love if they could spend that effort on creating the most BEAUTIFUL world possible (graphically speaking.)

Yes this means not just rendering tech, but also providing a much larger and diverse set of good art for players to use (sure, player-created art is great, but if LL can provide some more of their own professional stuff for players to use when building, then the whole world will look that much better.) And it does mean rendering tech too: The latest in texture/pixel/vertex shader technology, real-time shadows, etc (and no, it's not impossible to do this in a dynamic world like SL, it's just hard - lots of good LOD tech will be required

I know you guys love SL - so do I. That's why I want to see it improve. It has such potential because it's such an amazing framework for a player-created world - now I just want to see it become an even more *beautiful* place and I don't think that's ONLY going to come from better user-created art - I think it also needs to come from a broader set of professionally created art from LL, and continuously improving rendering technology that sports the latest advances present in other games.

Happily, it looks like they're heading in this direction already.

paulb

I'm involved in the graphics / programming industry, specifically in video card stuff and hardware, so here's my perspective on this.

The problem here is not that SL has a bad graphics engine.

Its actually pretty incredible.

For example, it runs at a blazing 10 fps when rendering almost 1000 different textures.

Modern video cards are designed to run a SMALL NUMBER of (possibly large) textures with LOTS of polygons.

Changing from one texture to another is known as a State Change, and its one of the slowest things modern video cards do. In fact, if you load 1000 textures up, and just switch inbetween them without even rendering any triangles, you drop down heavily in fps even on the top of the line video cards.

Second Life, in other words, by its very nature, is contrary to what video cards are designed for.

They are designed for small numbers (10s or 100s maybe) or precalculated textures that are uploaded to the video card ONCE, and then left there for the duration of the game.

Until next-gen video cards come out that support faster texture pipelining, there is no 'engine' that will help framerate.

HOWEVER

Textures are not the only thing that SL does much, much, much more of than any other game engine out there.

It also does an incredible amount of procedural geometry. We're talking many mTris a second here... sometimes with a different texture every 2nd triangle.

Most games wouldn't allow more than 512x512 textures either. SL allows more.

Almost everything in SL is dynamic.

BASICALLY - it doesnt matter what video card or engine you have... SL , by its very nature, is basicaly the antichrist when it comes to what video cards are meant to do

Here are some more things that video cards are NOT designed to do very quickly, and arent really present in other games:
* Large amount of fully dynamic content (textures, polygons, lights)
* Continuous upload of resources to the video card (Most other games have 'levels' 'zones' or at least some sort of area where everythign uses pretty much teh same resources)
* Continuous purging of resources from the video card (To make room for the above)
* Fully procedural geometry (Nothing static at all. No prebuilt models. Nothing that can be optimized before you connect, like Half-lifes levels, models, and in fact, everything else in the game).
* Not PVS based (also known as portalling). Generation of portals take hours for an average half-life level but unlike SL, they can do that, because its done OFFLINE. SL needs all content to be flowing and realtime.

So, yes, Second life runs at 10fps even on some of the best hardware. But I would argue that engines such as UT, and Half-Life would run perhaps 10x slower or more, because they just aren't built for the dynamic world that SL is.

HOWEVER

Thats not to say theres not room for improvement. There always is.

Its just not going to be a different engine. I believe the biggest speed gain would come from some sort of optimization sweep that runs on static objects or the geometry itself.
Basically, some sort of server, program, or algorithm that takes the antichrist-for-video-cards SL world, and makes it more palatable to them by doing some precalc.

Another improvment would be to be able to put portals down (manually). For example, when indoors, if your house is NOT translucent, you could make it so the outside world is not rendered by placing a portal marker at your doors, manually. If you held events inside indoors 'event halls' with this feature, you could gain many many FPS.

Basically, the big hand-up the other games have is their ability to be pre-computed. SL does not have that luxury BUT it could do SOME of it.

Some more things that modern video cards die from:
* Excessivley large textures
* Any kind of texture animation whatsoever
* Anytime a texture is changed after its loaded up
* Anytime a model is changed after its loaded up (ie, actual polygon change)

Notice how SL does all of that. And it HAS TO. If it didnt you'd not have any of the freedom in game that you have.


I TALK TOO MUCH.

Excellent thread! A thoroughly enjoyable read. Thanks.

Most excellent reply Mezzanine. I agree with all of your points! The kind of optimizations I had in mind for future patches of SL are precisely what you talk about: that is, where possible, doing optimizations on objects that aren't quite so dynamic (terrain, static building objects, etc) so that vis information can be precomputed, as well as giving the designers tools such as designer-placed-portals to be able to better manually optimize bad vis situations (just as you mention.)

I also think that the more "simple" things such as the shadows, reflections, water, sky box, etc could all stand to be improved, partly through some better technology, but also partly just by getting some better art in the game (im sure it'll constantly improve as we go.)

Thanks again for all the followup on this thread. I love to see the outpouring of support for SL.

paulb

about the idea of the use of portals.. you can set the view distance on chunks of land.. make it so that the area inside your building is aligned to a block of land and lower its view distance.. it works pretty well.. However there is one side effect. Anyone flying over your house is effected. now if you could set the height the feature goes up to, or maybe even a script command to set the view distance on a volume, lol..

People gotta hear what winter's saying, instead of just rushing to SL defense. You can't deny that SL is technically impressive. You also can't deny that it doesn't look as good as May Payne (to pick a random somewhat-old game).

There's two reasons for this, first as everyone's pointed out, because SL is doing something totally different, pushing lots of different objects and textures and updates at the client rather than pushing lots and lots of the same objects and textures. What's more, it's streaming them to your client over an unpredictable internet connection in real time.

Second, as Eggy pointed out, because most of the SL content is created by us, and while some of us are professional designers and artists, most of us aren't, so while the art department that works on a shrinked wrapped game can do more with less, some of the stuff in SL looks, um... hand crafted. (Which is fine, it's a hobbist's game, you use what you make and you make what you need).

This is a really long post. Is anyone reading this? I don't think so, most people I think read the first paragraph of a long post, then kinda skim the middle then wake up again for the end.

So, there are the reasons, what's the point? The point is SL needs to stress it's strengths. It's not a 200fps FPS, it's a community and a place where you can build and interact.

I think to draw new users, SL has to have professional looking art as the first thing users see (and the new welcome are is a helluva good stab at this), and to quickly indoctrinate new users with the idea that this is a user created world, and that they can do this stuff. I realize that these contradictory goals.

SecondLife may be doing stuff that current gaming videocards aren't designed for, but how would a professional video card such as a Quadro, FireGL, or SGI V12 handle them?

(Of course, porting SL to run on an Onyx3 would solve all these graphics problems, but not many people can drop half a million on a new system )

I'm currently running it on a Quadro4 and it looks exactly the same, but with a slightly better frame rate.

Sorry for the johny-come-lately post. I don't browse the forums as often as I should.

Some thoughts about improving SL (I'm sure this is all academic)
- My purely inconsequential opinion is that what SL needs is not more glitz. It's more speed. Many people turn off lots of glitz that SL can do already to have more framerate.
- I'd like it if SL could be made to run on a less good graphics card at the cost of ugliness.
- I'm impressed with the amount of shader code SL uses. A few of the lindens must be graphics gurus. This is probably why ATI cards suck so much for SL. ATI's programmable shaders have many subtle difference from nVidia's. Most of these are ATI driver bugs which are a tremendous pain to code around.
Many commercial games have identified these differences, and coded around them, which is why you don't see these problems so often. To this day, I'd rather have an nVidia card at twice the cost and half the speed.

Thoughts about previous posts:
- I'm under the understanding that even pre-built portals (and their more sophisticated cousins, tunnels) are better for best case performance, and worse for worst case. My guess is that SL's usual geometry is particularly bad for portals.
- SL uses farplane culling, which a lot of games try not to use because of visual artifacts.
- I don't see why weather cannot be made to go faster. Server rendering a skybox for you isn't unreasonable. Especially when that one rendering can be used for every client in SL.
- The thread about Adding/destroying textures is fantastically expensive on the graphics card is correct. BUT you can play tricks by writing into an existing texture, which avoids the creation/deletion step.

My observations are this:
- Things choke when there are too many people around
- Things choke when you're around too much geometry. Gibson is fantasically good for killing my framerate.
- Particles kill frame rate. I don't know why this is. Possibly way too much alpha blending.
- Order independent alpha blended object rendering is a hard problem. SL's engine doesn't handle this correctly. Possibly too much to ask from any game engine with this much dynamic content.

My thoughts:
- BSPs can build reconstructed dynamically. Witness Red Faction. The math behind this is psychotically hard. BSPs are handy for doing frustrum culling, but the help reduce overdraw, which I'm suspecting is a problem for SL. Multiple BSPs can be used to describe mostly static structures in a scene (ie buildings). They could be re-optimized when server load goes down. This would help the complex geometry problem.
- Unless I'm wrong (quite possible) avatars are always rendered with the same number of polygons, regardless of their distance. This must stop.
- I wonder if back-face culling is done in hardware or software. Potentiall gains to be had from doing it in software if the data structures are convenient.

Actually, I only see two shaders that SL uses, both are in the folder on the local computer and are .CG files.

As for ATI driver bugs, they are being blamed for a lot more than they actually cause. During the recent development of a game engine I got involved in, it turned out that whenever something looked wrong on the screen, if it was running on an ATI card, it was our fault as programmers for forgetting something... but if it looked wrong and it was running on an nVidia card, we checked the drivers first, because more often than not, it was a bug in the drivers...

After trying each of both worlds, our dev team decided individually which cards they would use for development and fun in their computers and each one independently settled with ATI cards, due to the fact that they just tended to do what you told them to, with fewer inconsistencies.

There ARE driver bugs. But they are being blamed for a LOT more than they are actually doing...

As for texture tricks, yes - you can pack many textures onto other ones.

However... the problem is that SL is dynamic. These texture packs would constantly need to change. Locking, modifying, and unlocking a texture on modern videocards video or AGP ram is more expensive than simply dropping it and uploading a whole new one, in most cases.

Not to mension that most people simply use 512x512 textures, or worse, 1024x1024s or bigger... for really small objects...

Anyways, heres some more suggestions and responses to the above post(s).

GEOMETRY PHYSICS LAG

A lot of the geometry / physics lag comes from the fact that objects are complex, and the physics engine is calculating these bundles of primitives, each and every little sphere, rail, ball, whatever.

If they added a new command that turned a primitive into a bounding approximation surface, and have that object be the 'collision surface', then things might speed up a little more

TEXTURE LAG

This one is largely up to SL's residents

* Don't use 512x512 textures for things that are going to be smaller than say, two by two meters in the game world. Bandiwdth, video card ram, and framerate are just wasted.

* Don't use animated textures which change texture, if you can at all do it using a script of moving or rolling textures or color animation instead. Remember. Textures are the video card's worst enemy.

GEOMETRY LAG

* Surprisingly enough, the latest generation of video cards (INCL RADEON 9700) have almost no framerate drop when rendering 200 instead of 100 mTri/s. In otherwords, the bottleneck is not the number of polygons.

However, it wouldnt hurt to use prims which dont create extra polygons when they are unneccessary. For example, if you are going to make a basket, dont make it out of 5000 weaved cylinders. Use a single hollow cube with a basket texture. Going to make a parachute? Dont make the 0.01 m thin cables out of cylinders. Use rectangels / stretched cubes instead.

etc etc etc.

The biggest improvement to the speed of SL may in fact come from the community itself, a sort of good neighbor policy.

Perhaps eventually people will get rated DOWN for creating 10000 little boxes with 1024x1024 textures in them... instead of getting rated up (like now).

The beauty of architecture in SL should be a balance of optimization, speed, artisticness, and practicality... not a prim count.

Here are my measurements on framerate taken during a 10-20 avatar meet in a densely primmed area. NOTE: I did not include 'viewing distance' because that uniformly increases ALL of the below. Its obvious that the more of EVERYTHING you render the slwoer its going to go.

BIGGEST FRAMERATE KILLERS

* Animated Textures that actually change texture
* Number of Primitves
* Number of Physical Objects
* Number of TExtures
* Size of Textures (number is more important tho).
* Number of attachments / other heirarchial constructs
* Shadows
* GLOW AROUND LIGHTS (Why is this so slow????????)
* Water Ripple Effect (Why is this so slow??? Its just a shader! Are shaders being run in software even though the video card can handle it?)
* Shadows
* Insufficient RAM (Second life attempts to use over 1 gigabyte of ram in some situations.)

SMALLEST FRAMERATE KILLERS

* Polygon density (The 'object detail' and 'Avatar Detail' and 'Tree DDetail' sliders had almost no impact on framerate on this machine, even when over 20 avatars were present. (~2 fps difference, running avg 24 fps)

* Anisotropic filtering (No impact. But its broke anyway. One might say driver bug, but it works in every OTHER game).

* Actual physics. 100 physical obecjts that were simple cubes did not slow things down. 100 physical objects that were extremely complex, DID slow things down... but thats under the 'complexity'.

WHAT PEOPLE CAN DO IMMEDIATELY

* Practice courteous and sane building

* Show the newbies how to be the same

* Consider the impact of what you build on others

I have to chime in on this one. I am running with an ATI Radeon 9100, with Catalyst 3.8, and I have had no problems. I don't know if this is still true, but in the "good old days," a lot of weird problems came from systems built with components that didn't *quite* mesh together properly. I found that you could build a system cheaper than an off-the-shelf one, but when you, or the computer manufacturer, buy low priced components (especially motherboards) you get what you pay for. For example, I once got a 30% increase in disk speed just by changing from a no-name MB to one with an Intel chipset - admittedly, this was back in the i486 days.

No, I don't work for ATI. Or anyone else at the present

**pulls out flame retardant monitor**

Browse around
C:\program files\SecondLife\app_settings
(or wherever your SL directory is) for more vertex shader fun.

Video driver bugs show up more often when you're playing with the programmable pipiline than with the fixed pipline, because the programmable pipeline is much much more complex than a fixed one.
My experience has been much better for nVidia than for ATI. My most recent experience with ATI was attempting to get a 255 line ARB vertex program working on ATI hardware. Getting passed 130 lines proved to be impossible despite my pleas, cajoling and screaming. Fortunately, I'm in academia, where I have no customers, and I can choose to throw my hands in the air on some hardware. But that's all anectdotal.

The qualiity of people that nVidia hires is traditionally much higher than that at ATI. However, this is changing. I still think ATI has some catching up to do.

Geometric complexity makes a difference, because SL's rendering engine is not optimized to rendering minimal overdraw. Many of us who don't have the latest, shiniest ATI Radeo 98Jillion cards are fill-rate limited, and overdraw becomes a big issue.

Also, I don't see why texture resolution should be such a big issue where the end-user should attempt to shrink their textures. The SL engine already has the capability to show lower-quality textures.

I Totaly Agree