Jump to content
Penny Patton

How Much Does Unoptimized Content Actually Affect Us?

Recommended Posts

29 minutes ago, NaomiLocket said:

Yet it might mean something,

On second thought, it may actually. If the early LL developers chose to use triangle strips for the ground it must mean they deliberately chose not to use them for prims. Cory Ondrejka brought in Avi Bar-Zeev to develop the prim system and if you think some forumites are obsessed with optimisation, you don't know Mr. Bar-Zeev.

I think we have to keep in mind that it's not at all clear that triangle strips offer improved performance. I don't know much about it myself but it seems most experts agree that indexed triangle lists usually render just as fast or even faster.

When it comes to polylist meshes there's also a question how to convert them to efficient triangle strips. That's a complicated business even under the best of conditions and the triangle and vertice lists the SL viewer has to deal with aren't even sorted in any meaningful way.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

Triangle strips are mostly about consolidating that index into the shortest size in as few drawcalls. It doesn't mean we don't have an index of verticies, however. There may be other reasons behind why strips are not working presently or maybe appear to not optimise like they are supposed to. I still feel it is a grave error that they are not seemingly to work or be used. (perhaps the sorting is the first place to look)

Edited by NaomiLocket

Share this post


Link to post
Share on other sites

 

2 hours ago, ChinRey said:

When it comes to polylist meshes there's also a question how to convert them to efficient triangle strips. That's a complicated business even under the best of conditions and the triangle and vertice lists the SL viewer has to deal with aren't even sorted in any meaningful way

As an experiment I uploaded a rigged avatar upper body mesh, rezzed one copy on the ground and wore the other. With RenderUseTriStrips enabled this is the result:

RenderUseTriStrips.thumb.png.94b3a08e609e6b6b5e2a6d94c10cb480.png

 

Either worn rigged mesh is somehow managing to sort the triangles into an order so that it can use triangle stips or rigged mesh is excluded when Use Tri Strips is enabled.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, Aquila Kytori said:

Either worn rigged mesh is somehow managing to sort the triangles into an order so that it can use triangle stips or rigged mesh is excluded when Use Tri Strips is enabled.

It's the latter. What it shows that it tries (and fails) to convert rezzed mesh into triangle strips but ignores worn fitted mesh. That's rather interesting in itself considering that the code predates not only fitted mesh but SL mesh as a whole.

The bugs in RenderUseTriStrips has nothing to do with sorting order or the actual conversion of mesh into strips. What happens is that the code as it is ignores the necessary steps to flip the normals of some triangles and to cull the connectors between substrips. Both are early alpha stage teething problems and the fact that they're still there nine years later must mean that the porject was never followed up.

Edited by ChinRey
  • Thanks 1

Share this post


Link to post
Share on other sites
6 hours ago, NaomiLocket said:

Well maybe someone can. I heard a rumour someone supposedly compiled under Vulcan and got twice the rate.

Vulkan isn't as simple as replacing opengl calls or using a different library, it's a fundamentally different architecture and the work involved is more like 'throw everything we have over the side' followed by 'start from scratch'. While it can deliver significant performance gains, those are only possible if you design for vulkan from the ground up.

8 hours ago, NaomiLocket said:

Also if I remember from previous readings on complexity and display metrics. There was no mention of it actually representing the work "your" card load is doing

Windows 10 task manage will show the utilization of various portions of your GPU. Needless to say, in SL's case it's ability to use your hardware effectively is heavily stunted. The GPU is barely used,. The only advantage newer hardware brings is IOPS and raw boost speed, which helps a little, but does not in anyway allow your GPU to truly get out of bed.

For example I can run SL on one screen 1080p everything on .. and then run an actual game on my main ultrawide and see only a few percent fps drop in SL (that's more connected to bus and memory bandwidth), likewise the game might be a couple of fps slower for the same reason. (RTX2060).

As with most things, there is supposed to be render performance code from LL soon, how much it's going to boost things by is a wait and see.

5 hours ago, Da5id Weatherwax said:

We all love to roundly castigate the Lab, of course, but if we continue having a productive and respectful discussion like this I would bet that at least one or two Lindens will be reading it with interest and paying attention to any possibilities we uncover.

LL are well aware and have been looking for a Senior Graphics Engineer for months now.

https://hire.withgoogle.com/public/jobs/lindenlabcom/view/P_AAAAAAHAACnF00jkV3wCcw

With the best will in the world and a laundry list of easy changes, there is nothing much they can do without the having the staff on hand to work on the problems. The best help we can be is to get that link out as far and wide as we can.

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, ChinRey said:

The bugs in RenderUseTriStrips has nothing to do with sorting order or the actual conversion of mesh into strips. What happens is that the code as it is ignores the necessary steps to flip the normals of some triangles and to cull the connectors between substrips. Both are early alpha stage teething problems and the fact that they're still there nine years later must mean that the porject was never followed up.

As with many attempted render optimizations in SL. They were roughly prototyped, tested in a live viewer, found to not deliver the boost expected and further dev time was subsequently not scheduled. They didn't even schedule time to back out the code. 

The viewer is a graveyard of failed attempts to grasp low hanging fruit.

The video card is not the bottle neck.

Edited by CoffeeDujour

Share this post


Link to post
Share on other sites
5 minutes ago, CoffeeDujour said:

LL are well aware and have been looking for a Senior Graphics Engineer for months now.

https://hire.withgoogle.com/public/jobs/lindenlabcom/view/P_AAAAAAHAACnF00jkV3wCcw

With the best will in the world and a laundry list of easy changes, there is nothing much they can do without the having the staff on hand to work on the problems. The best help we can be is to get that link out as far and wide as we can.

They're not looking very hard. They were not recruiting at the Game Developers' Conference in San Francisco.

Share this post


Link to post
Share on other sites
8 minutes ago, animats said:

They're not looking very hard. They were not recruiting at the Game Developers' Conference in San Francisco.

Well, unless you, personally, are going to pull the viewer apart and re-implement the render pipeline, having a dig isn't really productive.

If it turns out they need our help, then so be it. Helping LL find a highly skilled candidate is in all our interests.

  • Like 2

Share this post


Link to post
Share on other sites
On 7/5/2019 at 10:06 AM, CoffeeDujour said:

Pixel packing is not taught and considered bad practice, in the same way that unrolling loops and inline functions in LSL isn't taught. Creating UV maps with minimal face distortion that are meaningful for a human to work on is the industry standard.

From a processing processing perspective bigger textures are better. There are currently threaded decode options available but right now SL textures are too tiny and we only managed to make the CPU run hotter for a slower total decode time, despite the math looking good.

One big texture with multiple parts is significantly better than a dozen tiny 'optimally sized' textures. The drum to beat isn't smaller textures, it's fewer textures.

 

Here again, you're confused. I'm not talking about distorting textures to maximize the amount of pixels used and I'm not saying people should be using more tiny textures.

I'm talking about the fact that too many textures in SL look like this:

bad+texture+wrapping.jpg

When they should look more like this:

good+texture+wrapping.jpg

Combined with textures from other parts of the model that are also only using a fraction of their actual texture.

In SL content creators often give each part of the model it's own texture, that texture using only a tiny fraction of the pixels, when they could easily be combined into one large texture without sacrificing any detail, because they'd just be combining their textures in a way where they're not eating up 16MB of memory on four 1024x1024 textures where 3/4 of each are blank empty space and instead using a single 4MB of memory on one texture where the whole texture is being used.

Share this post


Link to post
Share on other sites

For what it's worth, I do agree with Coffee that expecting the average SL resident to understand  why some content is bad for SL is unreasonable. However, I disagree that it is 100% on the heads of content creators alone, because most SL content creators are themselves simply SL enthusiasts who got into creating content for SL and were never exposed to proper content creation habits like you'd find in a game design course or game modding communities. This is why LL needed to step in from the beginning, and why the only way real change will happen will be if LL steps in now.

LL needs to better communicate to both creators and non-creators alike how unoptimized content impacts performance. A blog laying it out in layman's terms with examples would be more effective than a wiki page in this regard.

LL needs to provide content creators and consumers alike with better tools for recognizing badly made content. In the stock SL client you cannot easily see how much VRAM or triangles your avatar is using. It is especially difficult to track down individual problem attachments. It is entirely impossible to know how content sold on the marketeplace fares in this regard, unless the creator volunteers that information. LL should figure out how to encourage that in more product listings.

  • Like 2

Share this post


Link to post
Share on other sites
3 hours ago, Penny Patton said:

LL needs to better communicate to both creators and non-creators alike how unoptimized content impacts performance. A blog laying it out in layman's terms with examples would be more effective than a wiki page in this regard.

And this is another area where a skilled content creator at the Lab could make a huge difference. They could make "something" - and it doesn't really matter what - in two versions. One optimized and the other demonstrating a few of the more common gaffes in this regard present in current content. It could be demonstrated that one doesn't look bad compared to the other, that one loads faster, causes less strain on the viewer etc. Heck, they could even be rezzed side by side somewhere so that folks could go and look for themselves, with their viewer running their settings. But because they are NOT the product of any established SL creator but made as a demonstration by a LL employee, they are also not naming any names and thereby, quite understandably, getting creators backs up.

Share this post


Link to post
Share on other sites
21 hours ago, Da5id Weatherwax said:

And this is another area where a skilled content creator at the Lab could make a huge difference.

Thing is they never had to look very far. There have been several forums dedicated to artists in the industry as long as secondlife. The problem is more if they can be assed to go looking for an artist with the goods to be a consultant. Hell some of them have long since written custom shaders for viewports in popular 3D modelling programs. It wasn't unusual for a studio to make plugins for either Maya or 3D max as a tool directly in their pipeline for making a game. And now and then they would share their more private time things with the community. The challenge for them is if they can find someone available at the time at those places. The challenge for us is to be sure they are actively recruiting instead of hoping someone is going to bother to come to their site and request a job.

When the usual stated response to people talking to outsiders about second life is "that is still around?" as a running joke, my optimism that any of them would bother chasing down the Lab for a job stays fairly low.

Share this post


Link to post
Share on other sites

Alternatively. Nvidia have long since published titles like GPU Gems. :B

Complete with both opengl and direct x shaders for every example.
Dynamicly moving hair was as old as voodoo3 cards if I remember right at all, but for a time only tomb raider and few others ever seemed interested in implementing it.

Share this post


Link to post
Share on other sites
On 7/7/2019 at 10:24 AM, Penny Patton said:

A blog laying it out in layman's terms with examples would be more effective than a wiki page in this regard.

 

Speaking of which, I love your blog and examples of how to optimize modifiable content, and how to make the most of one's experience on mainland regions. Your blog changed the game for me and how I needed to up my hobbyist skills to do better.  So, thank you.

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
On 7/1/2019 at 11:07 PM, Profaitchikenz Haiku said:

I just tried and with an un-crashed viewer, yes, you can change it. What I don't know is if a crashed viewer would be unable to display the screen at all, or the preferences, because it's the same rendering engine driving the UI as drives the inworld view? (in the incidents where I have had the screen go to garbage I have always been able to simply restart the browser)

It might not be the ideal solution, maybe a last-resort one to do with support guidance, but the relevant setting is likely to be in one of the preferences files which can be edited while the viewer isn't running. Looks like it's in user_settings/settings.xml and search the file for "TextureMemory". Either I am in totally the wrong place, or setting the value to 512 would fix it.

Is it really that simple to fix?

Share this post


Link to post
Share on other sites
On 7/7/2019 at 6:56 PM, CoffeeDujour said:

It would get subcontracted out to a mole (aka a resident) 

What has started me off is the lousy optimization to the Mole-attributed items of the SL16B freebie outfits, up to five 1024-size textures for a pair of shoes, with two of those textures for the inside of the shoes, not visible while they are worn.

It might be the poor mole was only responsible for loading the versions distributed, but somebody at the lab signed off on this crap, and they couldn't even be arsed to upload a smaller version of the usually invisible textures.

This solution depends on finding somebody competent. I doubt I would be up to the job, but on the evidence I don't think a Linden would recognise competence if it sat on their face!

Share this post


Link to post
Share on other sites
2 hours ago, arabellajones said:

This solution depends on finding somebody competent. I doubt I would be up to the job, but on the evidence I don't think a Linden would recognise competence if it sat on their face!

I used to say something like that myself (although I usually was a bit more diplomatic about it) but I'm not sure anymore. Look at this:

1855753793_Skjermbilde(2303).thumb.jpg.2d5af74121ad3abfc891028fbac9271c.jpg

This is the latest premium gift and it was made by a new Mole - Paranor - who joined the LDPW only four motnhs ago.

It's not perfect, there's some seriously dodgy noobish physics handling and both land impact and display weight are twice what they ought to be. But it's still a huge improvement compared to any Mole meshes I've seen before and I can only think of about half a dozen or so independent mesh house builders who would have done a better job. I was actually seriously considering fixing some of the easiest to correct mistakes and use it on my own land. I decided not to but that was mainly because the style doesn't fit my build.

Now, there's an old saying that one swallow does not a summer make but if this is representative of our new Mole's skill level, if the old ones can catch up and if they can develop from there, things are beginning to look really good.

  • Like 2

Share this post


Link to post
Share on other sites
On 7/3/2019 at 6:45 AM, Penny Patton said:

Don't add hidden pieces to your objects. Mesh hair doesn't need a root prim with a store logo on it.

To be fair, plenty of uses for having something like hair linked to a basic cube as the root. Like if it's made of unrigged pieces, it's easier to position if it's root is a simple cube, and if it's rigged, well surely we've all had issues at one point or another trying to right click on a model and just ending up selecting everything else but the model. Having a simple plain prim cube is much easier to aim for since it won't be as effected by that same issue.

  • Like 1

Share this post


Link to post
Share on other sites
On 7/12/2019 at 1:41 PM, ChinRey said:

I used to say something like that myself (although I usually was a bit more diplomatic about it) but I'm not sure anymore. Look at this:

1855753793_Skjermbilde(2303).thumb.jpg.2d5af74121ad3abfc891028fbac9271c.jpg

This is the latest premium gift and it was made by a new Mole - Paranor - who joined the LDPW only four motnhs ago.

I like diners so I gave it a look. Yeah, that LI is far too much, and when you look at the LOD it's pretty obvious why.For every piece I examined of this diner, the Medium LOD uses the High LOD and the bottom two LOD levels are gutted. This is the type of thing LL should be on the lookout for when working with the moles. There should be someone at the lab who can guide the moles beyond mistakes like this and bring the their skills up to that next level.

I like that LL hires SL residents to create content, but it's on LL to bring out the best in those residents.

Share this post


Link to post
Share on other sites
5 minutes ago, Penny Patton said:

I like diners so I gave it a look. Yeah, that LI is far too much, and when you look at the LOD it's pretty obvious why.For every piece I examined of this diner, the Medium LOD uses the High LOD and the bottom two LOD levels are gutted. This is the type of thing LL should be on the lookout for when working with the moles. There should be someone at the lab who can guide the moles beyond mistakes like this and bring the their skills up to that next level.

As you're perfectly aware of, there ain't nobody gonna tell no Mole how to build because they always know best. So they have to figure it out for themselves.

Yes, they still need to learn the basics how to make efficient LoD models and physics models but this diner is still a big step forward from any Mole meshes I've seen before. Perhaps most important, the texturing is back to old Mole quality. Well, maybe not quite but then again, the texturing skills of some of the early Moles - Crazy Mole in particular - were spectacular. Very few content creators anywhere can match that.

  • Like 1

Share this post


Link to post
Share on other sites
4 minutes ago, ChinRey said:

As you're perfectly aware of, there ain't nobody gonna tell no Mole how to build because they always know best. So they have to figure it out for themselves.

Right, I'm just saying how it should be. And you're right, this diner is far better than some of the mole content I've seen in previous premium gifts. I'm also very pleased to see that it's modifiable.

But it always bears repeating that LL has an enormous blind spot when it comes to content creation and how it relates to nearly every aspect of the platform. This is a mistake that has gone without correction for the past 20 or so years and it boggles the mind that LL still doesn't understand why it's such a huge problem for them.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
18 hours ago, Penny Patton said:

 it boggles the mind that LL still doesn't understand why it's such a huge problem for them.

Yes, it's really weird.

Ebbe talked about it during the NWN interview in April this year

Quote

The challenge of improving Second Life performance when user-generated content is often so poorly optimized, it almost becomes (as one Linden vet put it) like a DDOS attack. Ebbe says it's ultimately up to users, not the company, whether they use resource-heavy content. ("Users are going to do what users are going to do.")

(https://nwn.blogs.com/nwn/2019/04/ebbe-altberg-linden-lab-sansar-second-life-social-vr.html)

They're aware of the situation and they see it as a huge problem but they believe there's nothing they can do about it when in fact their actions (or lack of such) are by far the most significant factors.

Edited by ChinRey
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Let's face up to one unpleasant fact. Those of us that successfully sell "products" in SL are pretty good at peddling snake oil. We have to be in order to make a go of flogging the intangible for what is equivalent to real money, for all the legal nicety that the L$ is an "in-game token." I say this not as a criticism, but from the honesty born of having been moderately successful at doing it in the past. Most of us have encountered situations  where we can achieve the effect we want but our skills and knowledge are only up to doing it in a way that isn't "kind to the machine" and we are salesmen as much as we are artists so if we can talk that up into a feature rather than a detriment, we tend to do so. I know I was guilty of that on a couple of occasions. My knowledge and skills have improved since then and I'd hope I would not fall into that trap again but if all were being honest I think most would admit to at least a few instances of it in their history.

And because we are good at peddling snake oil, folks buy into those sales pitches. You see it in software too, horrible kludges being marketed as a feature until even developers that know better have to hold their noses and implement it to stay competitive.

You will never convince folks that have bought into it that way that it's bad so consumer choice will never fix this. That's why LL have to if it's ever going to change. They just don't think that the pain it will cause to the userbase is worth it, so they don't do it. They don't even incentivize merchants and creators to make improvements in this regard for new products, let alone update older ones. Without both the stick and the carrot, way too many of those merchants and creators just ain't gonna change what they are doing.

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)

The flip-side of equation, I consider this "unoptimized also and why NEVER BUY ANYTHING UNLESS YOU CAN DEMO.

This is with the *default* LOD setting in Firestorm (which, if I recall, is the same default setting in LL and Catznip):

Emporer's+Clothes.gif?v=9fa9c8ff07aa2a51

Edited by Alyona Su

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...