Jump to content

Rendering Complexity / Quick Graphics


Linden Lab
 Share

You are about to reply to a thread that has been inactive for 2739 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I cant believe the performance of the viewer is still total garbage. Struggling to get a decent frame rate in built up areas with very decent spec's. My cpu usage is under 15% and my graphics card is only being used 30-50%. Still no SLI support for multiple graphics cards either. This really is a joke considering how long SL has been running. I would have expected a decent improvement over the years, not just a bunch of tiny UI changes. SL has such potential, but frankly I remain disappointed. Also whats with charging $1000 dollars to set up a region? Its a rip off. It only takes one person 5 minutes to configure it. Pathetic. Show some real performance improvements for all the money you are raking in. I regret ever paying to own land in this lag fest.

Link to comment
Share on other sites

I am going to be logging in and checking it out, but so far from what I've read, you are giving avatar makers just another migraine to now deal with. I still remember the older ARC system and if that is anything to go by, I'm fearful as to how this will work. Rendering Complexity being a threshold for avatars to be seen can be detrimental to some communities, even if it is made as a toggable feature. If the client was smart about this and did proper calculations, then maybe. I'll know more when I actually try it.

As for rendering settings, I think it's cool, but let's be honest and address the elephant in the room: the client needs the rendering engine to be fixed. We have AAA games being made rendering more complex things at higher framerates, some even multiplatform and cross-operating system, and yet Second Life is chugging behind. OpenGL can be very powerful, and while I don't know what is making the client so under powered, it should seriously be looked into. Quick Graphics is just a reenactment of the Black Knight scene from The Holy Grail.

Link to comment
Share on other sites

The real migraine is caused by designers that build items without any regard for render efficiency. I have a gorgeous hair that by it self has a render complexity of over 165,000. I have some beautiful eXXess hair that has a complexity of less than 3,000. This feature will push designers to learn how to be efficient. But, it does not force them to be efficient.

This feature doesn't force designers to change what they are doing. But, it does let users decide how much render load their system will handle and set the feature's limit. High end systems can turn the limit off. Low end systems can set the limit low. We can also decide what items we want to buy. Over all it should start to improve render speed in SL.

The fact is, there are actual technical limits. No matter what the Lab does it is what we the users bring into SL that determines performance. Now we will have an easy to use tool that tells us what we are doing. Just as we have Land Impact to encourage builders to be efficient and learn how to use Level of Detail, now we will have something to encourage fashion designers.

Link to comment
Share on other sites

@ The Linden Labs and the community of users,

Guess this project would not be a bad decision but this is a "technical opinion" at first. On the other hand I wonder if it won't add complexity to the experience, especially, but not only, for the newcomers. In other words : isn't this project going against the Linden Labs latest sights about the newcomers experience in Second Life ? I understand it needs to control the technical sides of the platform, but isn't the cursor going in the bad direction ?

Concerning the business side of the project : are you going to add a feature on the MP informing the customers about the complexity of the objects she/he is about to purchase ?

Link to comment
Share on other sites

The ACI feature does not require a new user to learn or do anything. So, I don't see it as complicating SL or the new user experience.

3D virtual worlds are complex. There is no easy way around that. I think all that can be done is make learning about them as easy as possible. I think this feature falls in that arena.

I like your idea of adding a Complexity field to marketplace items. Have you put that idea in as a JIRA feature request?

Link to comment
Share on other sites


Flame Swenholt wrote:

As for rendering settings, I think it's cool, but let's be honest and address the elephant in the room: the client needs the rendering engine to be fixed.

I'm pretty sure no matter how you cut it, a hairdo with larger textures and more polygons than all of Doom 3 and Unreal Tournament 4 combined isn't going to render quickly on the fly unless you happen to have a supercomputing cluster just laying around.  Sadly, that's what a lot of avatar designers are trying to make happen rather than doing the most with less.  There's a reason there's design guidelines for things like the Steam Workshop:  Just because you can make things micrometer perfect doesn't mean that's what renders quickly when the camera's usually at least 5-20 meters away at best.

Link to comment
Share on other sites

As English is not my native, maybe I don't explain things the right way about newcomers (and even old residents) and this project. Where I want to draw technicians attention is the fact that today and in the future users have to manage too many things in order to have a pleasant experience in Second Life. We introduce SL as an easy place to experience, but any user who'd like to be in the swing will have not only to manage a body mesh and everything that goes on, but also to deal with its "complexity weight", this added to the setting of the preference board and other things that don't come immediatly to my mind...

Indeed it will have to be as pedagogical as possible.

I didn't use a JIRA since a very long time, but with the new management that sounds to be asking users opinion more often, I will certainly do :matte-motes-asleep-2:

Link to comment
Share on other sites


Shinaria902 wrote:

Or, OR LL could just not bring this feature out at all, because it's going to be hugely detramental to anyone using a mesh avatar. 

Only in cases where the mesh has an exceptional number of polygons.  As with any rendering system, scenes with fewer polygons render faster.  SL is no exception, there's just no guideline-enforced limit to how many polys may be used per object like there is on, say, Steam Workshop.

Link to comment
Share on other sites


Shinaria902 wrote:

Or, OR LL could just not bring this feature out at all, because it's going to be hugely detramental to anyone using a mesh avatar. 

Isn't that a bit like saying that speed limits are bad because they are hugely detramental to anyone who wants to drive faster?

Edit: I suppose I should post more than just a flippant comment, so let's talk about the elephant in the room. No, not Flame Swenholt's imaginary elephant but the real one: mesh bodies and attachments.

We all love how they look. Or at least most of us do - I certainly do myself. And it's big business. In an interview on Hypergrid Business earlier this year, Ebbe Altberg mentioned that an unnamed maker of mesh hands and feet was making "hundreds of thousands of dollars". Mesh avatar/attachments as a whole must be a million dollar business.

So there's no wonder we don't want to see the downside of it all and no wonder why Linden Lab has been dragging their feet. But in the long run we simply have to face the fact that all that high poly mesh creates a tremendous amount of lag, so much that something just have to be done whetehr we like it or not.

I'm sure the rendering engine can be improved but if we compare Second Life to modern games it's actually performing extremely well, it's just that the load is so much heavier. Baloo Uriza was not exaggerating when he said a single mesh hair in SL can be more render heavy than an entire modern computer game. Medhue Simoni once mentioned how a pair of high poly shoes had been enough to stop a modern game dead in its track. In Second Life we take it for granted that the system can manage dozens of such objects at the same time. There is a limit to what is technically possible though and many places in Second Life are way past that limit by now.

That being said, I'm not quite convinced that the new Rendering Complexity / Quick Graphics function is the right solution and I've explained why in that other thread Whirly mentioned. I don't really know though - I try to stay away from beta releases these days so I haven't tried it msyelf. So if anybody from Linden Lab is still following this thread, can I ask a question or two?: Do you feel the visual complexity algorithm is exact enough to target the high lag avatars precisely enough? And if so, can you explain a little bit why?

Link to comment
Share on other sites


ChinRey wrote:

Do you feel the visual complexity algorithm is exact enough to target the high lag avatars precisely enough? And if so, can you explain a little bit why?

I don't think I'd use the term "exact" for anything of this kind, because different features have slightly different real costs depending on the capabilities of your system. Short of having a very deep understanding of the specific capabilities and performance characteristics of every graphics system out there (many many thousands), an "exact" formula isn't possible. So the question is "is it good enough to be useful?", and we think the answer to that is "yes". Certainly many of the Lindens who've been using this viewer for months (including myself) have decided that the feature is very very valuable.

Personally, I usually run with my limit set to about 100,000 - good enough to display most avatars in the settings where I spend time, and keeps my lag under control even in substantial crowds.

Link to comment
Share on other sites


Oz Linden wrote:

I don't think I'd use the term "exact" for anything of this kind, because different features have slightly different real costs depending on the capabilities of your system.


Yes that makes sense. Any display cost calculation will have to be an estimate of course. And despite what I said in the other thread, I'm sure the new feature has quite some value. It will catch all the avatars with sky high polycount meshes and senslessly high resolution textures of course, and that's a good thing.

Even so, I can't help noticing that the formula for calculating render weight (or should I say render complexity now?) hasn't been updated for a while and doesn't take into account recently added features. Itr's quite a paradox that an old fashioned system bumpiness map adds to the calculated render weight while a custom normal map doesn't. Same with old style shininess vs. modern specular maps of course. Alpha masking is definitely far less laggy than alpha blending but does it come with no added render cost at all? I'm sure we're all familiar by now with how messy alpha masked surfaces can look when our computers are struggling to cope with the load.

My main concern is fitted mesh though. Is it really true that fitted mesh with lots of moving vertices and polys doesn't add anything to the render complexity? If so, why can't we have flexible mesh elsewhere in Second Life too?

Let me illustrate this. Here are two pictures of my avatar with different outfits:



 



 

The first picture has a mesh body, mesh hands and mesh feet. Calculated render weight is 17875. In the second picture there is no mesh at all but lots of good old fashioned flexis. Render weight - a staggering 129891.

But those numbers are clearly lying. There is no doubt that the fitted mesh outfit is considerably more render heavy than the full flexi one. In a low lag environment like Coniston it's only noticeable if I push my graphics settings to the maximum but when I do, it is quite obvious. I have friends with less powerful computers who have asked me not to wear my mesh body when I'm with them because their computers can't cope. Nobody has ever said anything like that about the flexi loaded outfit even though its calculated render weight is seven times as high.

To sum it up and rephrase my question: I know that render cost depends on so many factors it can't really be calculated precisely so we jsut have to do the best we can. But the formula used today in SL is several years old, was made for a virtual world quite different from what we have today, does not take into account more recent features and was not really meant to be used for something liek the new Quick Graphics feature. Isn't it about time to reevaluate it?

Link to comment
Share on other sites


ChinRey wrote:


But those numbers are clearly lying. There is no doubt that the fitted mesh outfit is considerably more render heavy than the full flexi one. In a low lag environment like Coniston
it's only noticeable if I push my graphics settings to the maximum but when I do, it is quite obvious.
I have friends with less powerful computers who have asked me not to wear my mesh body when I'm with them because their computers can't cope. Nobody has ever said anything like that about the flexi loaded outfit even though its calculated render weight is seven times as high.

 

"Pushing your graphics to the maximum" involves turning on shadows, including shadows of avatars, and also including shadows of avatars and their attachments. Dynamic shadows are very graphically demanding. Some TPV's can improve graphics speed by changing how avatar shadows are processed - i.e. only showing the shadow of the hardwired base avatar rather than the shadow of the attachment-covered one. However, it isn't the polygons of the mesh itself that are causing problems.

http://realrestraint.blogspot.com/2015/06/rlv-2912.html

Link to comment
Share on other sites


Whirly Fizzle wrote:

That seems normal to me. Flexis are one of the most expensive objects to render.

Don't get me wrong, I'm not denying that flexis add a lot of render weight. Nyx Linden did some testing a while ago and found out they can be up to five times as render heavy than regular prims.

But so does fitted mesh and all observations and tests I know of, both my own and others', indicate that it adds considerably more than flexis. Yet that factor is not included in the formula in any way.

I don't know in detail how SL's rendering code works or the performance difference between path based and skeleton based flexis, but logically it makes perfect sense too: even a low poly fitted mesh body like mine has far more vertices than a hundred flexis and the sheer number of them must have quite some significance.

 


Theresa Tennyson wrote:

"Pushing your graphics to the maximum" involves turning on shadows, including shadows of avatars, and also including shadows of avatars
and their attachments.

Yes, and that should have even more of an effect on the second outift than the first and it still is the least laggy of the two.

Whether we like this new feature or not, I think we all agree that we want it to be as precise as possible. It should target the avatars that actually are unsafe to render and leave all the others alone.

Let's say a user with a moderately powerful home computer will have to set the limit so low Quick Graphics derenders ten percent of the safe avatars to be able to catch all the unsafe ones. That's not really good but it's probably worth it. Now, if we can reduce that misidentification percentage to five, it's still not perfect but a huge improvement. And yes, I do believe we can achieve that simply by reevaluating and updating the render weight formula

Link to comment
Share on other sites


ChinRey wrote:


Whirly Fizzle wrote:

That seems normal to me. Flexis are one of the most expensive objects to render.

Don't get me wrong, I'm not denying that flexis add a lot of render weight. Nyx Linden did some testing a while ago and found out they can be up to five times as render heavy than regular prims.

But so does fitted mesh and all observations and tests I know of, both my own and others', indicate that it adds considerably more than flexis. Yet that factor is not included in the formula in any way.

I don't know in detail how SL's rendering code works or the performance difference between path based and skeleton based flexis, but logically it makes perfect sense too: even a low poly fitted mesh body like mine has far more vertices than a hundred flexis and the sheer number of them must have quite some significance.

 

Theresa Tennyson wrote:

"Pushing your graphics to the maximum" involves turning on shadows, including shadows of avatars, and also including shadows of avatars
and their attachments.

Yes, and that should have even more of an effect on the second outift than the first and it still is the least laggy of the two.

Whether we like this new feature or not, I think we all agree that we want it to be as precise as possible. It should target the avatars that actually are unsafe to render and leave all the others alone.

Let's say a user with a moderately powerful home computer will have to set the limit so low Quick Graphics derenders ten percent of the safe avatars to be able to catch all the unsafe ones. That's not really good but it's probably worth it. Now, if we can reduce that misidentification percentage to five, it's still not perfect but a huge improvement. And yes, I do believe we can achieve that simply by reevaluating and updating the render weight formula

Flexiprims are completely an illusion created in-viewer and the viewer can greatly simplify them when casting shadows, which it does. Actually I doubt that the flexis are driving up the rendering cost of your high-cost avatar; it's probably sculpts. I'd guess the boots.

I turned on my fast timers and compared between adding and taking off a rigged mesh body. With ALM and shadows on there was a noticeable difference in frame time almost entirely in avatar shadows; with ALM and shadows off there was almost no difference.

Link to comment
Share on other sites


Theresa Tennyson wrote
Actually I doubt that the flexis are driving up the rendering cost of your high-cost avatar; it's probably sculpts. I'd guess the boots.


Possibly but it's the flexis that drive up the calculated render weight.

But that's beside the point. I chose those two outfits because they are rather extreme examples of what I wanted to illustrate: An avatar with a low nominal render weight can still cause considerably higher actual render load than one with a much higher nominal weight.

There's one fairly simple test anybody can do if they want to: Switch on avatar render weight display and go to a crowded area. Look around and try to notice which avatars are slow to load. Then check which avatars have the highest render weights. How well do those two groups match? That should give a really good indication how precisely Quick Graphics can identify the actual problems.

Link to comment
Share on other sites


ChinRey wrote:


Theresa Tennyson wrote
Actually I doubt that the flexis are driving up the rendering cost of your high-cost avatar; it's probably sculpts. I'd guess the boots.


Possibly but it's the flexis that drive up the calculated render weight.


 It was the calculated figure I was referring to. Have you done tests to confirm this or are you relying on what Whirly said? I have actually done comparison tests of specific items. A far more complicated flexi skirt than what that avatar is wearing only adds about 10,000 to the score. Complicated sculpted items can easily add multiple hundreds of thousands to the score.


ChinRey wrote:


There's one fairly simple test anybody can do if they want to: Switch on avatar render weight display and go to a crowded area. Look around and try to notice which avatars are slow to load. Then check which avatars have the highest render weights. How well do those two groups match? That should give a really good indication how precisely Quick Graphics can identify the actual problems.

That test is simple but it's meaningless. When the viewer renders a flexi or a sculpt, it only has to download the texture files. It does the rest of the rendering by manipulating the primitives that are hardcoded into the viewer. With a mesh, all the data has to be downloaded before it can be rendered, so mesh items will always arrive more slowly. However, it doesn't automatically follow that the work the viewer has to do after the information arrives is harder.

Link to comment
Share on other sites


ChinRey wrote:


Even so, I can't help noticing that the formula for calculating render weight (or should I say render complexity now?) hasn't been updated for a while and doesn't take into account recently added features.
Itr's quite a paradox that an old fashioned system bumpiness map adds to the calculated render weight while a custom normal map doesn't. Same with old style shininess vs. modern specular maps of course.
Alpha masking is definitely far less laggy than alpha blending but does it come with no added render cost at all? I'm sure we're all familiar by now with how messy alpha masked surfaces can look when our computers are struggling to cope with the load.


Custom normal maps and specular maps are added with textures, and adding textures increases the rendering cost.

Link to comment
Share on other sites


Theresa Tennyson wrote:

Possibly but it's the flexis that drive up the calculated render weight.


 It was the calculated figure I was referring to.

That was what I was referring to too. The flexis are what drives the calculated render weight of that avatar up. If I remove them, it drops down to a far more normal level.


Theresa Tennyson wrote
Custom normal maps and specular maps are added with textures, and adding textures increases the rendering cost.


No, they aren't.. You can add as many and as high resolution normal and specular maps as you like to an object and they don't change the calculated render weight in any way.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2739 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...