mipmapping Does SL Support Mipmapping? How does the system work?

[ZerahMordly]

I'm looking around to see if SL supports mipmapping, and, if it does, are the mipmaps generated by SL or do I have to generate my own to ship with my mesh?

http://wiki.secondlife.com/wiki/Image_System

This link above talks about mipmapping in SL but it doesn't really go into detail about how the mipmaps are generated if they are pre-generated, if mipmapping is viewer-dependent, and if mipmapping works how the system works in which it displays each resolution of the texture at different distances, or if it is based off the LOD? My interpretation of the wiki above was that SL switches out a mipmap based off of how space much an object's texture takes up on the screen, and the closer you are the higher detail texture provided; vice versa.

I ask because I made a house and I have 14 1024x1024 textures applied to the entire mesh on 14 objects in blender, the inspector in firestorm claims 14kb VRAM usage and it sits at 31 LI (no physics model yet) The textures are very good in detail, and on smaller objects such as rails on stairs look very odd if I'm zoomed out enough from it to the point it looks ugly, and kind of blurry. The detail is destroyed from further away, my guess is because of the absence of mipmapping. That's the only way I can explain it because textures are supposed to look their best further away not up close. Mine look best up close and get uglier further away, and when I've worked in Unity with mipmapping accidentally disabled this same phenomenon happens, another reason why it seems there's no mipmapping. If mipmapping happens to be based off the LOD I find that really odd because if I'm standing in my house it does NOTswitch an LOD to a lower version if I'm across the room from the stairs where i'll need a lower LOD of texture in order to preserve the visual quality of the rails on the stairs from further away, and a house in SL usually only begins scaling down LOD when you are outside of it or like 100 feet away from it. SL recognizes the house as one object in edit mode, but the inspector sees it as 14, so it's processing the LOD code for the house as a whole, so that's a huge problem for me if the object LOD system is what the mipmapping system is based around. The only other thing I could think to do to work around that in that case is import every individual object from my blender project for this house and put it all together in SL, resulting in this solution that had to be terribly hacked around, massive model and LI bloat, and significantly more asset storage requirements for LL. I'm really hoping that mipmapping is viewer dependent and I just have a switch turned off or something. I use the latest version of Firestorm.

I'll be able to confirm the presence of mipmapping if I open inspector on my house and zoom in and out and see if the VRAM usage from the textures fluxuates. Ill try it.

Update: No it does not.

Any thoughts?

 

Edit: Perhaps it'd be more practical and efficient to just use 512 x 512 on smaller objects since I'm not expecting people to put their nose up to the stair rails, it'll make it look visually better further away. I only did 1k because I thought giving mipmapping more to work with would make it more impressive.

Edited April 7, 2020 by ZerahMordly

[Wulfie Reanimator]

1 hour ago, ZerahMordly said:

The textures are very good in detail, and on smaller objects such as rails on stairs look very odd if I'm zoomed out enough from it to the point it looks ugly, and kind of blurry. The detail is destroyed from further away, my guess is because of the absence of mipmapping.

I believe the mipmaps are created during the upload process of the texture, by the uploader. The wiki page you've linked explains pretty explicitly that mipmaps exist and how they're used. Lower resolutions are used based on the texture coverage on the screen. I'm not sure what kind of "blurriness" you're experiencing. Do you use anisotropic filtering? Can you include screenshot comparisons?

1 hour ago, ZerahMordly said:

Edit: Perhaps it'd be more practical and efficient to just use 512 x 512 on smaller objects

Definitely. Remember that 1024 is four times more pixels than 512.

Edited April 7, 2020 by Wulfie Reanimator

[animats]

Yes, the code in the viewer supports mipmapping. When the viewer uses it, I have no idea.

The viewer has several tools for adjusting resolution. It can load a texture at reduced resolution from a progressive JPEG 2000 file. It can send a texture to the graphics card at a lower resolution than it loaded it. It can send mipmaps to the graphics card and let the graphics card do multiple resolutions. It can even replace a texture already in the graphics card with a lower resolution version. I looked at that code once, looking for a bug which was crashing self-compiled viewers. Somebody did all their homework. All the hard stuff is done.

When it does what is not clear. Some of those policy decisions are clearly not optimal. They date from an era when graphics cards had far less memory, and when the sim servers were serving the textures in their spare time. But there's no obvious place to go in there and start re-tuning the texture loader. The policy is spread over many places in the code. It's thus hard to change.

LL has talked about looking into that.

 

[Beq Janus]

SL is mixed up on this. As Animats says, the support is scattered and depends on various conditions. In general, it does work as the link you referenced says and how you appear to have interpretted it. The primary mechanism used by the viewer to control texture resolution is  the "discard level" this is pretty much the same as a mipmap, but is used to (theoretically) reduce the texture loading overhead, reduce bandwidth needs and speed things up. The theory is that based on the relative area of screen the viewer will only request a lower resolution version of the asset. This is down through progressive J2K encoding as Animats said. If an object stays far away then only the low detail version need be downloaded. This does mean that once the image is unpacked to full resolution in memory then it is using 33% extra memory, as it is holding all the discard levels in RAM too. 

The cache rewrite is on its way, it is an active project for the lab, whether it has someone assigned right now is a separate question, a lot of focus is on the cloud uplift so things are frequently put aside for that.

1) Textures do not switch based on object LOD, they do switch based on screen space utilisation. They do not therefore correlate with LOD switching.
2) The inspector looks at the linkset, it has nothing to do with the behaviour of the mesh or the textures it is simply the asset linkage in that regard. There is a debug setting to show the discard level, it is however just a developer setting and is not very useful.

Your cited numbers (14Kb) can't be right. they are either for unloaded textures or something is not reporting properly. a single fully unpacked 1024 RGBA texture is 4MB add a third to that for the discards...I can't recall if we show the compressed storage cost though, I think not.

One possible cause of blurriness is texture swapping. Your description does not sound like that is occurring but with 14x1024s on the house alone, add however many are in you avatar, furnishings, HUDs etc. some people find that they run out of texture buffers in the viewers and this results in cycling where textures are constantly blurring when they get pushed out of cache. Again, I don't think that is what you are seeing but worth a check.

 

 

 

[Wulfie Reanimator]

7 hours ago, Beq Janus said:

Your cited numbers (14Kb) can't be right. they are either for unloaded textures or something is not reporting properly. a single fully unpacked 1024 RGBA texture is 4MB add a third to that for the discards...I can't recall if we show the compressed storage cost though, I think not.

4MB? You might wanna check your numbers... Even a losslessly fast compressed 1024x1024 JPEG2000 doesn't each 1 MB.

7 hours ago, Beq Janus said:

2) The inspector looks at the linkset, it has nothing to do with the behaviour of the mesh or the textures it is simply the asset linkage in that regard.

The inspector is at least partially affected by LOD changes, the number of triangles it reports changes depending on the LOD of the object.

Edited April 8, 2020 by Wulfie Reanimator

[Beq Janus]

1 hour ago, Wulfie Reanimator said:

4MB? You might wanna check your numbers... Even a losslessly fast compressed 1024x1024 JPEG2000 doesn't each 1 MB.

decompressed texture usage is what I was stating (like I said, I don't think we show the compressed cost, I didn't check though)

8 bits @ 1024x1024 = 1MB, x 4 channels = 4MB, add 33% if you want the discards. in any case 14kb for 14 1024s is wrong

2 hours ago, Wulfie Reanimator said:

The inspector is at least partially affected by LOD changes, the number of triangles it reports changes depending on the LOD of the object.

Odd, I do not see that behaviour at all. Are we talking about different things perhaps? I checked my thoughts on both of these, see video below.

Quick video inspection of random mesh in my living room.

Here's just a simple fireplace that happened to be near me. It has two faces which are both 1024x1024 (and no, they really really do not need to be that size!) They are RGB (no alpha) and thus combined amount to 6MB, which is what the inspector shows. The VRAM cost is more as that will include the VBOs for the mesh and the textures. The creator chose to reuse the diffuse UUID as the specular thus did not incur any further texture costs there, they did not use a normal map at all, meaning that they had no cost there but also lost most of any specular effect they were after due to the lack of the specular exponent in the alpha of the normal map. Anyhow, I am digressing. We appear to be using 6MB of texture ram. As I switch LODs none of the accounting changes for me, which makes me assume I am looking at a different thing to you? Even if I force a "proper" LOD switch by pulling out, nothing changes. Note that it should switch at 50m so I moved well in excess.

 

 

[Ardy Lay]

Oh!  Don't make me do math!  😉  /me picks up a 1024 pixel * 1024 pixel * 4 channel * 8 bit JPEG2000 image file and sees it takes 128 kilobytes of filesystem storage, pulls the cord and gets covered with 4 megabytes (power of 2) of expanded data, after discarding the metadata which includes the UUID of the uploader, date-time stamp, and average color. 

"That was weird."

[Ardy Lay]

Does having the object selected elevate the applied textures in 'importance'?

[Beq Janus]

In theory yes, in practice, a little. The viewer will prioritise the texture under the cursor as it hovers, for a selected object (one level of depth only). What this does is place it higher in the priority queue that gets serviced by the texture fetcher. If there are other active things in front of it it won't help, and as far as I can see there is a boost but not an "unboost" so I think that anything you pass over on the way will also be added at high priority and not removed when you move away. The effectiveness is thus somewhat limited I believe though more than happy to be corrected in this, it is not a part of the viewer I have spent too much time in (anyone wishing to peek at it should look in llviewobjectlist.cpp to start their journey). 

Similarly, the code to boost sculpt map retrieval is still there, but it never worked that well and I have a feeling it has become less effective over time but that may simply be an overall increase in texture density in a typical scene. 

[Wulfie Reanimator]

4 hours ago, Beq Janus said:

Odd, I do not see that behaviour at all. Are we talking about different things perhaps? I checked my thoughts on both of these, see video below.

Quick video inspection of random mesh in my living room.

The inspector will use the current information at the time the object is selected. For example, but that doesn't seem to apply on textures.

Edited April 8, 2020 by Wulfie Reanimator
[REDACTED]

[Beq Janus]

5 minutes ago, Wulfie Reanimator said:

1024 * 1024 = 1048576 pixels. 1 pixel = 1 byte (8 bits, RRGGBBAA, the 4 channels). 1048 KB, not 4194 KB. I don't want to imagine a world where you use 8 bits per channel.

we do live in a world with 8 bits per channel!

each channel is 0-255. 

[Wulfie Reanimator]

2 hours ago, Beq Janus said:

we do live in a world with 8 bits per channel!

each channel is 0-255. 

Sorry, I'm one massive brainfart.

Edited April 8, 2020 by Wulfie Reanimator

[Ardy Lay]

Imagine SL on an EGA display.

[Kyrah Abattoir]

On 4/7/2020 at 5:20 AM, ZerahMordly said:

Edit: Perhaps it'd be more practical and efficient to just use 512 x 512 on smaller objects since I'm not expecting people to put their nose up to the stair rails, it'll make it look visually better further away. I only did 1k because I thought giving mipmapping more to work with would make it more impressive.

YES PLEASE.

Never use more textures/resolution that you have to.

[ChinRey]

22 hours ago, Ardy Lay said:

Oh!  Don't make me do math!  😉  /me picks up a 1024 pixel * 1024 pixel * 4 channel * 8 bit JPEG2000 image file and sees it takes 128 kilobytes of filesystem storage, pulls the cord and gets covered with 4 megabytes (power of 2) of expanded data,

Yes, that's something that's easy to forget. The textures are downloaded and stored compressed but before they can actually be displayed, they have to be unpacked and that increases the memory usage a lot.

Edited April 9, 2020 by ChinRey