Is LL ever going to invest in updating the graphics of their game?

[Brynn Ametza]

          Hi Deej,

     I'm a huge fan of improving the avatar mesh. trust me, I would love for it to be more detailed. There is one small problem with "simply" increasing the counts in key ares. You'll render (no pun intended) a vast amount of clothing unwearable. You have to remember that those amateur content creaters spent a good bit of time trying to make that texture look as good as possible on that mesh. Change the mesh..change the texture.

       Brynn

[Dana Hickman]

Interesting and informative discussion. One thing I noticed however, is that during all these comparisons made between graphics of this game and that game, NObody has given weight to the fact that everything you see in SL has to come down the ethernet cable before you can see it. That is NOT SO in every game mentioned or compared to so far. The entirety of the content in those games ALREADY resides on the users computer, in the form of either a fixed, precomputed environment, or made available through PRE-loading of update packages before runtime. It is NOT streamed live at connect time like SL is. The only things that SL reads locally is the avatar mesh, a few of the simpler effects and settings, and whatever cached content you might have. The burden that places on ones entire system, not just rendering, is many times that of other games. Of course those other games will run many times better than SL does on most systems... duh.

With all the talk of non-professionally made content in SL, you'd think that it's a pro game design firms worst case scenario, when in fact such cases of gross / widespread ineficiency and misguided use in SL are pretty rare. Of course one can point to an example of such here or there, but that in no way indicates that all, most, or even a lot of the content in SL is to blame for ones poor performance.

The differences to be had by eliminating much of the user-created inefficiency you see is not as large as some may think, because the issue lies not in the content but in the underpinnings of  WHY user-created content can potentially cause such issues. Two terms... zoning & world space occlusion. Everyone else has them, and has had them for at least 10 years... SL does not. As it stands, SL forces you to download and process every single thing within your draw distance and between the edges of your POV render area, regardless of whether you're overlooking an open valley or standing nose-up to a mountainside and fighting the content that exists on the other side of it. It is precisely why skyboxes get better framerates than the same box would if it was on the ground in a crowded neighborhood, even if it has no windows.

Every major game developer programs into their game so that the enclosed space within the 6 (or however many) sides of a primitive shape has a positive world space attribute.. it has positive volume (Unreal engine is backwards but functions the same way in reverse). It is used to differentiate the space inside from stuff outside of it (which would be negative space, or negative world space attribute), and that's what a zone is. They can have multiple properties or attributes, but for sake of this discussion, the important one is "occlusion = true". SL already calculates the POV, and what objects are inline with the POV and within the draw distance. The only thing missing is an additional prim properties flag that tells the viewer that anything that's completely hidden behind it is "do not process". The viewer sees it and immediately does not process geometry or textures that are 100% obscured by the object, for the cameras current point of view. Such calculations are not heavy at all, done 99.5% client side, and are routinely done on the fly as an industry standard "trick", so to speak. LL land and land patches could easily use a flag such as this so that the viewer doesn't have to process stuff that's below the ground or hidden by it, as in the case of a mountain or hillside. Prims used to make structures, like walls, floors, ceilings and such, could easily be set to occlude what's inside.. that way someone standing outside facing the building will NOT have to process everything inside of it, or what's behind it that he cannot currently see. Those inside wouldn't have to process or render any part of the outside world until they encountered a prim or window that doesn't block their POV with an "occlude" flag. Prims with transparencies, of course, cannot be set to occlude, and prims smaller than 2m should not be allowed to be set to occlude, because that can cause issues in and of itself. Only two additional numbers ("flags", values of 0 or 1) would get sent by the server along with the prim infomation, one is for positive or negative space, the other is for occlusion on or off. This is not the same thing as normal occlusion, which is what lets one object appear to be behind another, this is complete render and process occlusion (basically exclusion), which means the system forgets about it entirely (except where it is) until some part of it becomes visible.

We were doing this process more than 10 years ago with the Unreal and ID Quake engines so that the players didn't have to compute and render an entire level all at once. It's not some pipe dream, and the savings in terms of performance are HUGE.. with a capital H. Make no mistake, it can be done here, and most of it is already done. It's the lack of this standard feature in SL, not someones poor building or texturing skills, which is 90% at fault for your viewers getting hammered down by too many polys to render at one time. Don't blame peoples inefficient content, because you're yelling at the tip of the iceberg on this one.

[Penny Patton]



---

Dana Hickman wrote:

... One thing I noticed however, is that during all these comparisons made between graphics of this game and that game, NObody has given weight to the fact that everything you see in SL has to come down the ethernet cable before you can see it. That is NOT SO in every game mentioned or compared to so far.

________________________________________________________________________________________________

This doesn't affect performance so much as load time.  There's certainly a CPU hit as streamed content is processed, but it's fairly minor compared to other issues.

 

________________________________________________________________________________________________

With all the talk of non-professionally made content in SL, you'd think that it's a pro game design firms worst case scenario, when in fact such cases of gross / widespread ineficiency and misguided use in SL are pretty rare. Of course one can point to an example of such here or there, but that in no way indicates that all, most, or even a lot of the content in SL is to blame for ones poor performance.

________________________________________________________________________________________________

Actually, no, inefficiently made content and misguided use of content is extremely widespread. A part of that is merely the way SL is made. Using prims to construct environments is horribly inefficient compared to creating an environment with mesh, and most people use prims in an extremely inefficient way, using far more prims than they need to achieve a level of detail well below what they could.

Go check out the sim Doomed Ship some time.

It's a huge sim, easily spanning enough area that one could be forgiven for believing it's 2 or 3 sims in size. It's also fairly well detailed;

There is maybe only 200 prims visible in this shot. 

When you wander the sim for an hour or so, realizing you haven't yet seen the whole place then here's another tidbit.

The actual Doomed Ship build uses only about 2/3 of the sim's currently used prims. 

 

In contrast to that, most people up-scale their builds by about double scale. Houses and other already large structures beging to soak up prims when you scale them up that much. A 2 prim wall may look the same as a single prim wall, but it is twice as many polygons you are rendering A double scale house also takes up four times as much area.

This means you get a less detailed environment, capable of holding only 1/4th the amount of content, but takes four times as much processing power to render as the same environment constructed efficiently.

________________________________________________________________________________________________

The differences to be had by eliminating much of the user-created inefficiency you see is not as large as some may think,

________________________________________________________________________________________________

Correct, they are

much greater

than most people imagine.

________________________________________________________________________________________________

Two terms... zoning & world space occlusion. Everyone else has them, and has had them for at least 10 years... SL does not.

________________________________________________________________________________________________

Actually, unless I'm mistaken, SL has had occlusion for some time now. This is why in places like the above mentioned Doomed Ship, you actually achieve greater framerates despite the level of detail in the environment.

 

Zoning would be a fantastic addition, tho.

________________________________________________________________________________________________

. Don't blame peoples inefficient content, because you're yelling at the tip of the iceberg on this one.

---

I agree there are technical areas that could be improved, but you are severely underestimating the impact of just how poorly most people, even some otherwise really talented people, tend to build in SL. When you use several 512x512 textures for an object that should be a single 256x256 texture total, that's a processing hit. Fill the world with such objects and that processing hit becomes huge. Using 2, 3 or 4 times more prims than you need to achieve a level of detail and that's going to be a huge hit to performance and a huge hit to SL's overall visual quality, yet this is how nearly everyone, even many of SL's most talented builders, work.

 I'm not laying the blame for this entirely at the feet of eager SL hobbyists, LL could have done a much better job with many of the content creation tools which have, due to many cases of short sightedness, wound up encouraging bad building habits.



---

Brynn Ametza wrote:

          Hi Deej,

     I'm a huge fan of improving the avatar mesh. trust me, I would love for it to be more detailed. There is one small problem with "simply" increasing the counts in key ares. You'll render (no pun intended) a vast amount of clothing unwearable. You have to remember that those amateur content creaters spent a good bit of time trying to make that texture look as good as possible on that mesh. Change the mesh..change the texture.

       Brynn

---

The thing to remember is that LL should not remove the old mesh, they should provide a new mesh. We should be able to 

switch between new and old meshes just like we can currently switch between the male and female meshes. After the new mesh has been available for some time, LL should begin to start off new users using the new mesh.

[Dana Hickman]

---

Penny Patton wrote:

This doesn't affect performance so much as load time.  There's certainly a CPU hit as streamed content is processed, but it's fairly minor compared to other issues.

---

That's correct, which is why that paragraph about what I didn't see mentioned so far was seperated from the rest which is about performance. It's an observation only. Your answer above though, is exactly my reply to what you said regarding the misuse of multiple large textures where one 512 would do. Just like you say, it's many times more a LOAD TIME hit, not processing, and so all the mumbo about texture misuse translates directly into network and latency issues, and not anything tangible relating to render performance.

 

---

Penny Patton wrote:

There is maybe only 200 prims visible in this shot.

---

That's great! A good example of how prim efficiency can make some minor improvements on the rendering workload. Now go back to that same sim and go into wireframe or turn off texture use. THAT is how many vertices your renderer is processing, not just what's "in view". Why are all the prims and vertices that are behind the visible walls and large objects, all the way out to the end of your draw distance also being processed? Because there IS NO zone occlusion in SL. If there was, showing the wireframe mesh and vertices like that would ONLY show specifically those ones that are directly in your line of sight and not hidden behind an occluding object... everything else would be void or blacked out, and moving your camera around would cause some objects to pop into processing and some to blink out as the system dynamically decides which new prims to start processing and which ones now out of "line of sight" to stop processing.

Like I said prior, "processing" or zone occlusion is not the same as "regular" or render occlusion. Render occlusion is what decides which objects to partially display so they appear to be behind nearer ones, or to not display at all because it's hidden behind something else, and without it SL could not function at all in any 3D sense. One needs to understand that the displaying of an object is only the last step in a long sequence of pre-render calculations, and it's those calculations that cause the big burden. Zone occusion is what keeps all the unnecessary calculations on objects not even being displayed yet from taking place until they are needed. SL does NOT do this and the proof is right in wireframe, or the skybox test scenario I posted earlier. With zone occlusion, being in a closed skybox would get you exactly the same framerate when the box is placed in the middle of sculpty hell as it would in the same sim at 4000m. We all know SL doesn't behave that way, and it's because there's no zone occlusion that it acts the way it does.

You make a case for inefficiency, and that's fine. I don't disagree that it can cause problems. MY point, however, is that whatever prim inefficiency that exists wouldn't wind up being the straw that broke the camels back if we weren't already having to process and pre-render every hidden object as well as the ones that are visible. Eliminate the inefficient workload instead with zone occlusion and the prim inefficiency now becomes mostly a non-issue, because now you have the extra horsepower to take the much smaller bumps that poor prim use gives you in stride.

[leliel Mirihi]

What you're talking about sounds like a form of occlusion culling known as portals, it's a very good system for occlusion culling that was first used in Quake I believe. The problem is that it only works on static geometry, you have to pre compute all the data for it. Obviously this won't work for SL.

Anyway the viewer does do real time occlusion culling using the standard feature present in every GPU made in the last 10 years. The reason why it doesn't work very well is two fold. First is because of prims, the gaps in walls will cause the viewer to not occlude objects that should be, mesh will "fix" this. Second is latency, doing the occlusion test on the GPU then reading back the results over the PCIe bus to do the culling on the CPU just takes too long. This is why modern games have switched to either a fully GPU based system (usually something like hierarchical-z map), or just doing good frustum culling on the CPU and relying on the back face culling and early Z culling on the GPU to catch most of the rest.

[Dana Hickman]

---

leliel Mirihi wrote:

What you're talking about sounds like a form of occlusion culling known as portals, it's a very good system for occlusion culling that was first used in Quake I believe. The problem is that it only works on static geometry, you have to pre compute all the data for it. Obviously this won't work for SL.

---

Yes, it was Quake, but it's not portals. Portals were used to link areas and condense the physical geometry of a location, so that the entire area didn't have to be built out in visible space. They do use culling tied to POV, but that's only an add-on so they can appear non-existant while seamlessly linking multiple geometries together over a distance. Yes portals need to be precomputed, there's just too much math, but what I speak of is akin to the POV culling add-on used standalone, and it's not why portals need precomputing. One can easily see this by using game editors and just placing occlusion zones in the geometry somewhere. Live and in real time you can see portions of the geometry disappear based on the cameras POV, and if the affected area is large enough (or your system is weak enough), you can also watch the associated workload drop dramatically. This again is live, well before a single thing is ever compiled. There is no reason why it can't be brought to SL, the ground work is already in.

The viewer uses render culling, yes, but it does not take advantage of that to also drop the associated processing of what's already been completely culled, and that is where the issue lies. SL already does those high latency tests you speak of when it render occludes and computes POV in the first place, and what I mention is only a branch off of that, not a completely new thread. Certainly many newer techniques can be adapted and used, and in fact those are preferrable because of their efficiency, but that still doesn't change the fact that SL doesn't do this at all and most others do, which is my point. It needs to get here for hardware performance reasons above all else.

What you mention about zone gaps in walls only applies if one is trying to completely occlude every single thing, and such precision is not necessary to still acheive major reductions in the number of prims the viewer is having to think about at one time. It matters not that a thin slice between adjoined prims may indeed allow a handful of objects to be seen from straight on when it really doesn't want to, it's only the total number that matters in this case. All the builder need do is add a single invisible phantom "sheet" prim inside the wall interior to block the gaps and thus occlude the entire walls area with 1 prim instead of many. It doesn't get any more efficient than that.

[Annette Collas]

Oh God wouldn't it be wonderful!!! I am soooo tired of editing the lumps out of my graphic novels. Takes forever and makes making the books a chore.

 

 

[Shelby Silverspar]

Welcome to the forum, Annette. There might be an award for posting your very first comment to an almost two-year-old thread. :matte-motes-big-grin-wink:

[Briana Sirbu]

The heck, oo yess all helpers course they run for LL help, making lobby, but not help SL users.

The more they do, the less good experience i get. My major complain: who the hell brough mesh to sl? How manny people or creators, even creator who play with templates made by others know how much lagg a mesh can add to SL?

I've been in SL for over 6 years, and to be honest im happy with what i have achieved. Not  being welthy... lol

Thou, even we seem to upgrade, to me its a sorta downgrade, more lagg, more issues and bugs and glitches... Yes windlight is lovely, my graphic card its not recocnized by sl, my fault... so because Lindens does not recocnize NVidia, i have issues with my only 2 year notebook.

The ones complaining that people has old computers, i tell you one thing: if computers would be as cheap as the +period they live, everything would be perfect, but right now, there are people, who does live or not in USA, who cannot afford to buy a new one every 2-3 years. So back off.

You helpers, who have reached a level, better plead for users and not LL employees....

[Drake1 Nightfire]

---

Briana Sirbu wrote:

The heck, oo yess all helpers course they run for LL help, making lobby, but not help SL users.

The more they do, the less good experience i get. My major complain: who the hell brough mesh to sl? How manny people or creators, even creator who play with templates made by others know how much lagg a mesh can add to SL?

I've been in SL for over 6 years, and to be honest im happy with what i have achieved. Not  being welthy... lol

Thou, even we seem to upgrade, to me its a sorta downgrade, more lagg, more issues and bugs and glitches... Yes windlight is lovely, my graphic card its not recocnized by sl, my fault... so because Lindens does not recocnize NVidia, i have issues with my only 2 year notebook.

The ones complaining that people has old computers, i tell you one thing: if computers would be as cheap as the +period they live, everything would be perfect, but right now, there are people, who does live or not in USA, who cannot afford to buy a new one every 2-3 years. So back off.

You helpers, who have reached a level, better plead for users and not LL employees....

---

The helpers do not work for LL.

You replied to a post from 2 years ago.

Mesh does not add lag to a sim. Lag is a property of your personal computer. two different people will have different levels of "lag" on the same sim.

Which graphics card do you have? at only 2 years old it should work fine. Have you asked suport for help?

Notebooks were not designed to ever run something as graphics heavy as SL.

My PC is 5 years old.. i upgraded the graphics card and memory, it runs SL at ultra just fine.

[Briana Sirbu]

Well thank you, but lemme tell you one thing. Since the body meshes were introduced the lag increased and when you go to a venue being normal avie you can see at first: parts of avies, either hair, foot, hand and so on and untill they rezz fully, it takes a while and rezzing them, makes my notebook running slow, and my experience in sl is worse. But since firestorm has updated to the newest Phoenix-Firestorm-Release-4-7-9-50527, people are now jelly shadows, which is much better, since my notebook doesn't need to work too much to render all impostors... Here is the site: http://www.firestormviewer.org/ All my best Briana Sirbu

[Alwin Alcott]

as last time in this thread you reply to a post thats 3 yrs old... don't you think the technical changes in SL make everything you add to this a tiny bit irrelevant?....

 

If you want a discussion about the current state... why not open a new post?