Jump to content
Chic Aeon

Too Many 1024 Textures and the NEW (please hurry) Land Impact rules

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

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

Recommended Posts

1 hour ago, Callum Meriman said:

It can be demonstrated as mentioned above, texture a prim at 1024x1024, shrink to a pinhead and duplicate, swing the camera around. Do the same at 512x512 and lower.

Ouch, yes. Current texture loading policy seems to be to load full-resolution textures into VRAM even for things too far away to need them, if enough VRAM is available. Cards with a lot of VRAM but not extreme texture fill rates bog down.

From what Oz Linden said about Project Arctan, the original land impact limits came more from the limitations of serving textures from the servers that ran the sims. Now that assets are served from completely separate machines, the limits were raised. So now the viewer / graphics card can choke on texture fill rate.

Lots of little objects, and you choke on draw calls. Objects with big textures, and you choke on fill rate.

Share this post


Link to post
Share on other sites
8 hours ago, CoffeeDujour said:

*decoding also does not give up on a task until it has been completed, even if the asset that spawned that task is no longer visible because you cammed passed it. There is an assumption that when you arrive at a location, you will hang about and wait for it to rez, not immediately scoot your cam to the other side of the region and get upset that a vendor you were looking at on a previous visit is refusing to load.

It sounds like anyone building a forced landing point entry needs to be really careful what they're doing then. Good use of texture repeats and mesh instances on an entry hub for an RP sim would be ok enough, but that whole thing about making us walk through a shopping mall of things we're not interested in to get to the main store is just causing problems.

Share this post


Link to post
Share on other sites
1 hour ago, Bitsy Buccaneer said:

Good use of texture repeats and mesh instances

Big problem: there is no instancing method in SL. Assets that are copied over and over point to an original UUID from the first upload, but then each copy gets its own UUID, making it a full object, and no instance. If copying an object was actual instancing, a texture parameter on any of the copies should automatically update the others, for how objects are managed in SL.

Edited by OptimoMaximo
little correction and specification
  • Thanks 1

Share this post


Link to post
Share on other sites
12 hours ago, CoffeeDujour said:

I believe it's run on Amazon servers.

No, it's hosted by Akamai. Sansar was on Amazon at first and believe it still is. Second Life used Highwinds at first but switched to Akamai:

https://community.secondlife.com/forums/topic/416895-please-fix-the-sl-servers-they-make-random-mistakes-in-the-alpha-mode-for-textures-after-restart-for-years-and-years/?tab=comments#comment-1708224

 

7 hours ago, Klytyna said:

MORE THAN A PETABYTE!

You may underestimate it actually. Think of all the textures that have been uploaded over 15 years - it may well add up to an exabyte.

In any case, the sheer amount of data is more than enough to explain why it can't all be stored on the cloud servers. I believe that was animats' main poitn and something you all seem to agree about.

 

7 hours ago, Callum Meriman said:

But yeah, we all got reamed recently by the sweet Patch for commenting on things we dont know jack about. :S

That was a discussion about LoD models, not textures. I don't think he'll be offended this time. When it comes to texture optimization, the Moles really, really know what they're doing.

Edited by ChinRey

Share this post


Link to post
Share on other sites

I remember Ebbe saying in the old Sansar Slack channel that there were over 25 billion assets stored in the SL asset servers. :o

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, Bitsy Buccaneer said:

It sounds like anyone building a forced landing point entry needs to be really careful what they're doing then. Good use of texture repeats and mesh instances on an entry hub for an RP sim would be ok enough, but that whole thing about making us walk through a shopping mall of things we're not interested in to get to the main store is just causing problems.

There was actually a case EXACTLY like this a couple of years ago. I went over to the RP hub and ALL the shops were packed full and OPEN so everything was in view from the landing point and it was NASTY for movement. The landlord, not wanting to lose his rental income did see the problem and was planning on enclosing the shops some and getting folks to get rid of some not needed scripts.  

Share this post


Link to post
Share on other sites
4 hours ago, OptimoMaximo said:

Big problem: there is no instancing method in SL. Assets that are copied over and over point to an original UUID from the first upload, but then each copy gets its own UUID, making it a full object, and no instance. If copying an object was actual instancing, a texture parameter on any of the copies should automatically update the others, for how objects are managed in SL.

Are we SURE that is true because I have been told that TEXTURES once in cache don't have to load again in the viewer (until of course the texture cache gets used up). This by someone who apparently knew what they were talking about -- maybe even a few folks.  Not talking about the MESH, I do understand that doesn't instance.  

Things may have changed when the viewer and our computers took over the work from the server.   Just want to actually understand how it works.

And TO THAT UNDERSTANDING --- from the techier folks in the group --- there has been a long time argument  whether it is better for the viewer to have say four 512 textures or one 1024. The loading once versus the larger texture size. Obviously it is better to have ONE 1024 texture than FOUR of the same size, but what do we know now about the loading that might have changed? 

EDIT:   Shouldn't all this info be in a knowledge base article or wiki?   IS IT?  

EDIT: Shouldn't creators have the info they need (as soon as possible) for the new land impact rules rather than that fiasco we had last time?  

I still contend that we really need some changes IF folks with lower end computers are going to be able to use Second Life (hence the possible future growth). And if we knew about the changes (like bakes on mesh which will impact some creators a lot) then we can adjust and not be shocked when it happens. 

I am hopeful that those of us who have been trying to make game asset mesh won't have too much to deal with. 

Edited by Chic Aeon
adding info

Share this post


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

Ouch, yes. Current texture loading policy seems to be to load full-resolution textures into VRAM even for things too far away to need them, if enough VRAM is available. Cards with a lot of VRAM but not extreme texture fill rates bog down.

Current texture policy does not downgrade a texture once it has been loaded it at 1024 if VRAM is not under pressure, it does not load 1024's for distant objects.

If you zoom in to a distant object it will load at full rez. The viewer will then keep that one around a little so when you zoom in again to check..  its still 1024.

Camming around and inspecting everything is a great way to force the viewer to max out your texture ram. Just like having the texture console open to watch it work has a significant impact on the decode pipeline. As is cranking your LOD to the max ...

Share this post


Link to post
Share on other sites


Right. More generally, the viewer doesn't try to keep the frame rate up by reducing quality. (There's a frame rate setting in graphics preferences, but it's a maximum, not a minimum. It can be useful if you're running out of CPU time on the main thread in the viewer, but otherwise doesn't seem to do much.)

Do SL viewers use the OpenGL mipmapping features? Documentation says yes. All the heavy machinery is supposedly there. Those came in around OpenGL 3, in 2009, so they postdate the original SL. But the current system requirements for SL imply OpenGL 3 support. If you have a full set of mipmaps loaded into VRAM, a smaller version of a big texture is supposed to be used by the graphics card when the texture image is bigger than the on-screen area of the target polygon.

OpenGL doesn't tell the program much about what's going on in graphics card performance. Too many draw calls? Too many vertices? Out of time on texture fill? Shader programs running too long? Hard to tell. Because SL is so dynamic, there are things the viewer can do, but lacks the information to decide what to do. There are non-portable platform specific and graphics vendor specific hacks to find out, but the SL viewers are mostly standard OpenGL for portability.

Unreal Engine has an emergency mode which, when the frame rate drops below 10FPS, starts cutting detail. SL lacks that.

Edited by animats

Share this post


Link to post
Share on other sites
3 hours ago, Chic Aeon said:

Are we SURE that is true because I have been told that TEXTURES once in cache don't have to load again in the viewer (until of course the texture cache gets used up). This by someone who apparently knew what they were talking about -- maybe even a few folks.  Not talking about the MESH, I do understand that doesn't instance.  

For mesh items, that's a fact. For textures, instead, the behavior is a little odd: as long as a texture is reused in the same linkset, it gets called once and all prims/sculpts/meshes that use it will get that one. However if more than one linkset (separate assets) get to use the same texture but they're not linked together, each asset does its own call for that same texture. The texture gets to the viewer at the same time, but the assets using said texture produce separate calls, so i've been told and could understand looking at the viewer code i was pointed to. So as far as UUIDs go, the texture is an instance from server, but it is being treated as part of a single asset which calls for it separately from the other assets that use it. If this behavior proves to be true, it's not true instancing.

  • Thanks 1

Share this post


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

Unreal Engine has an emergency mode which, when the frame rate drops below 10FPS, starts cutting detail. SL lacks that.

That is on an empty engine to program a preloaded array of assets and has all the features to detect what's wrong, and this emergency mode is mainly a Editor window feature, not a runime method, to avoid crashes and troubleshoot optimization issues. We can't compare UE4 to SL because of their very natures: one is a game engine with features for developers to optimize a final release, SL is a platform where the core is more or less established and assets are being added by hordes of random users.

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, OptimoMaximo said:

For mesh items, that's a fact. For textures, instead, the behavior is a little odd: as long as a texture is reused in the same linkset, it gets called once and all prims/sculpts/meshes that use it will get that one. However if more than one linkset (separate assets) get to use the same texture but they're not linked together, each asset does its own call for that same texture. The texture gets to the viewer at the same time, but the assets using said texture produce separate calls, so i've been told and could understand looking at the viewer code i was pointed to. So as far as UUIDs go, the texture is an instance from server, but it is being treated as part of a single asset which calls for it separately from the other assets that use it. If this behavior proves to be true, it's not true instancing.

OK. So if I understand this correctly ---- if you have four bushes with the same textures and you LINK them to be one object, then the texture IS reused without a separate call for each bush.  Otherwise not. 

If someone else can verify this I would be very grateful as I could easily link things together at LEA6 to get better framerates. Framerates are very good, but better is BETTER.  Thanks.  I have been reusing the same assets because I was told (by many) that this would be better for the texture downloads, but if not then little point.   There is always plenty of misinformation going around so filter through to the actuality is often difficult. 

 

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
3 minutes ago, Chic Aeon said:

OK. So if I understand this correctly ---- if you have four bushes with the same textures and you LINK them to be one object, then the texture IS reused without a separate call for each bush.  Otherwise not. 

As far as i could understand, yes, assets call for that same texture, and if another asset got it in the viewer cache previously, it is shared and loads faster in the viewer for the other assets tot, but the call from the other assets is in place anyway, so it becomes a network issue. I'm not good at C++ and i may have misunderstood that code i was shown at the time along with the explanation given to me, again i would like actual viewer devs to confirm or confute it once and for all as you do as well, so to get some clarity about it. 

  • Thanks 2

Share this post


Link to post
Share on other sites
4 hours ago, Chic Aeon said:

OK. So if I understand this correctly ---- if you have four bushes with the same textures and you LINK them to be one object, then the texture IS reused without a separate call for each bush.  Otherwise not.

Ouch. I can see why, though. Textures are property in SL, and they have ownership information attached. You're not allowed to take a texture from an object and move it to inventory, then reuse it in another object. Texture storage may reflect that. Sharing would be good for texture loading, but bad for property rights management.

If the UUID of a texture was simply its hash (computed with something like MD5 or SHA256), then all identical textures would be folded into one unique UUID. That's the optimal solution for texture loading, but if you can find out the UUID of a texture, you can reuse it anywhere.

Edited by animats
Clarify

Share this post


Link to post
Share on other sites
On 7/8/2018 at 7:36 AM, Chic Aeon said:

One thing worth noticing, is that according to Firestorm there is no difference in VRAM usage between 24 bit (non-alpha) and 32 bit (alpha) textures and the numbers are conistent with the raw data requirements for alpha textures. If this is correct, it the viewer is reserving up to a quarter of the VRAM for non-existent alpha channels.

I'm not sure I trust Firestorm on this. I know the people who developed that tool and offered it to Firestorm. They had to really push to get Firestorm to accept it at all, and when they did one of their coders messed around with it, changing things seemingly at random.

They also removed one of the best parts, the ability to jelly doll avatars with excessive texture memory. Yeah, the texture load for sims is horrendous, but there's also avatars walking around with nearly a full GB of textures. That's the extreme, sure, but there's a lot walking around with 200-500MB and that's still really, really bad for framerates, bandwidth and load times.

The good news is that the tool was also offered to LL and the Lindens seemed to love it. So we just gotta wait and it will hopefully, eventually, make it into the main viewer.

Share this post


Link to post
Share on other sites
1 hour ago, Penny Patton said:

I'm not sure I trust Firestorm on this. I know the people who developed that tool and offered it to Firestorm. They had to really push to get Firestorm to accept it at all, and when they did one of their coders messed around with it, changing things seemingly at random.

They also removed one of the best parts, the ability to jelly doll avatars with excessive texture memory. Yeah, the texture load for sims is horrendous, but there's also avatars walking around with nearly a full GB of textures. That's the extreme, sure, but there's a lot walking around with 200-500MB and that's still really, really bad for framerates, bandwidth and load times.

The good news is that the tool was also offered to LL and the Lindens seemed to love it. So we just gotta wait and it will hopefully, eventually, make it into the main viewer.

Just noting that it wasn't actually ME that said that LOL.  WAY above my techie pay grade.

 

Share this post


Link to post
Share on other sites
1 hour ago, Penny Patton said:

They also removed one of the best parts, the ability to jelly doll avatars with excessive texture memory.

because it does nothing. You see a jelly doll .. but the viewer is still going to fetch all the assets, textures and stuff them into VRAM. You get a fps boost by not having to render them.

Share this post


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

because it does nothing. You see a jelly doll .. but the viewer is still going to fetch all the assets, textures and stuff them into VRAM. You get a fps boost by not having to render them.

Regarding the technical part here, fetching assets: I'm not sure that's true, it seems the viewer only downloads up to where it hits the cap then it stops downloading. Of course I'm basing that on observation I don't know what it's doing under the hood.

Now, about it doing "nothing"? You need to think about this while keeping in mind that there are actual people using the software. People too often forget the social/psychological side of things. Toss in a feature like this in a viewer so people can see just how much texture memory is being used, and it's impact on performance (regardless of where the fps boost is coming from), and that will push content creators to start changing their creation habits. We saw the same thing when LL introduced Jelly Dolls. As time went on there was a serious drop in the average avatar draw weight. This, over time, results in fewer avatars being jelly dolled and you still retain a significant performance boost even with fewer jelly avatars due to better optimized content.

 

Edited by Penny Patton

Share this post


Link to post
Share on other sites

Set your avatar rendering really low so everyone is a jelly, go to a sim with people you wont have seen before .. wait 10 mins .. disable jelly dolls. Pop .. they all fully rez, instantly.

  • Like 1

Share this post


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

Set your avatar rendering really low so everyone is a jelly, go to a sim with people you wont have seen before .. wait 10 mins .. disable jelly dolls. Pop .. they all fully rez, instantly.

Except that's NOT what happens. They pop in partially rezzed, sure, but then the rest of their textures and attachments slowly load in while their draw weight and VRAM use numbers increase. At least in the viewer I tried with the texture jelly doll feature. Again, fully admitting ignorance on what's going on behind the scenes, just relating what I observe.

But don't bury the important part here, the main purpose of such a feature is to inform and guide users. If it pushes content creators to optimize their work better, then it's working. That's why the regular jelly doll feature wound up having a positive impact on SL despite being clunky and optional. Content creators saw a need to push the draw weight of their content down to remain competitive. Content creators even began releasing optimized updates of some pre-jelly doll content.

Share this post


Link to post
Share on other sites

Ok, but again, if it pushes people to optimize their work, then it's still working. But I'd also agree it's not the best way to tackle the issue of textures on avatars. In addition to Land Impact needing to take textures into account, avatars should have a similar not-optional resource cap. For both I'd suggest LL do it in stages.

First, show the new LI and new avatar resource cap without actually implementing them. For the latter maybe tie it to jelly dolls so people can visually see at a glance what is over the cap and what isn't. Tell people "these are the new Land/Avatar Impact calculations, they'll go into effect a year from now." (Or maybe 6 months, or maybe 2 years, the important thing is giving content creators time to release new and updated content before the new limits go into effect.)

 

Edited by Penny Patton

Share this post


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

First, show the new LI and new avatar resource cap without actually implementing them. For the latter maybe tie it to jelly dolls so people can visually see at a glance what is over the cap and what isn't. Tell people "these are the new Land/Avatar Impact calculations, they'll go into effect a year from now." (Or maybe 6 months, or maybe 2 years, the important thing is giving content creators time to release new and updated content before the new limits go into effect.)

I was thinking about this today over on the beta grid (well Lani was on the beta grid).  BUT FIRST do we KNOW that the new LI impact is in connection with an AVATAR IMPACT?  I had not heard that before  --- so sourcing the info would be good. Thanks.

BEYOND that :D.  I do agree that the last LI change was a mess for many  folks (happily not for me as I hated sculpts from the start).  SO THIS TIME -- wouldn't it make sense to have the new LI parameters on some of the beta grid sims (like at least one of the MESH sandboxes)?  Then we could test what we have been making and adjust to what we need to make (if adjustments are needed). 

Granted there are a ton of creators that never go to the beta grid (or test actually) but SOME of us would appreciate the opportunity to see what was coming. 

Share this post


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

I did verify this was the case before posting ... 

I confirm. I always go to events with complexity at the lowest slider, after I finish camming all the vendors I bump up the slider to look at people, and they all pop in immediately without the usual "body bits everywhere" effect.

This is further confirmed with a lot of jellydolls starting as visible then snapping into jelly after a few things load.

It would be nice of the viewer to stop loading an avatar once it hit the chosen limit, but right now, it's loading it all with all that often wasted bandwidth.

  • Thanks 1

Share this post


Link to post
Share on other sites
3 minutes ago, Chic Aeon said:

BUT FIRST do we KNOW that the new LI impact is in connection with an AVATAR IMPACT?

No, no! Sorry if I wasn't clear. I think "Avatar Impact" should be a thing. LL has never said anything about it and I don't believe they're considering it. 

5 minutes ago, Chic Aeon said:

I do agree that the last LI change was a mess for many  folks (happily not for me as I hated sculpts from the start).  SO THIS TIME -- wouldn't it make sense to have the new LI parameters on some of the beta grid sims

Totally! LL shouldn't rush into any Land Impact changes. I'd much rather they take the time to do it right, even if it pushes it down the road. I think it would eventually need to come to the main grid without being enforced. I think they'd get the most feedback that way. Like you say, tonnes never go to the beta. But I think when it does come to the main grid it shouldn't be enforced right away. Give people plenty of time to change their habits.

Share this post


Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 714 days.

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

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...