Q on LoD texturing and texture memory use

[Kwakkelde Kwak]

---

leliel Mirihi wrote:

Because you're plastering everything with high res textures!

---

According to whom?? I never use textures bigger than needed, I always make them fit the object.

 

---

( Your whole example sounds to me like "How can I use a high res textures for tiny objects without it increasing memory use". Maybe I'm reading more into it than there really is but that's the way it looks to me.)

---

Then you clearly don't hear what I am saying. I am talking about lowering the texture use on the lower LoDs, I never mentioned increasing the high one anywhere.

---

One atlas for more than one object, i.e. the table and chair use the same texture. This works best for non square objects that would otherwise have a large amount of wasted texture space.

---

Depends on how you use the textures. If you want 512x768 for the table and 512x768 for the chair, yes. The results would probably not be that much better than two 512x512s. And some people might want only the table, no chairs. Then you really have unused texture space.

---

The viewer only loads the low res texture when the object starts out far away, once you zoom in on the object it has to load the full texture which stays in vram even if you zoom back out

---

Point taken.... but that's how it works now, not how is has to work.

---

What makes you so shure the viewer will dump the large texture? The object is still in view after all. And this whole trick will only work if you have one copy of the object in view, if you have multiple copies at different LODs than you're now using way more vram then a normally made object.

---

I'm not sure it does, but I am sure it's possible, since a LoD change means a model change. One copy of one object is what you'll be looking at in most cases and in SL most objects have unique textures. If you build grass or trees it's probably not a wise choice. If you are building pretty much anything else you won't often see duplicates. This is very different from what you'll see in video games, where reusing textures is the norm for obvious reasons.

 

 

[leliel Mirihi]

---

Kwakkelde Kwak wrote:

---

leliel Mirihi wrote:

Because you're plastering everything with high res textures!

---

According to whom?? I never use textures bigger than needed, I always make them fit the object.

 

---

( Your whole example sounds to me like "How can I use a high res textures for tiny objects without it increasing memory use". Maybe I'm reading more into it than there really is but that's the way it looks to me.)

---

Then you clearly don't hear what I am saying. I am talking about lowering the texture use on the lower LoDs, I never mentioned increasing the high one anywhere.

---

To what end? What are you trying to save by doing this? It's the full size image that's taking up all the ram, cutting back on some image half way down the mip chain isn't going to do much of anything. We're talking about extensive modifications to the viewer to over ride how the GPU does mipmaps to save, what 5%?

ETA: It's not even close to 5%. Here's the break down for a 1024x1024 texture.

66.66% for 1024

22% for 512

7.33% for 256

2.44% for 128

0.814% for 64

0.271% for 32

Who cares about such small savings? The fastest, easiest, and biggest savings comes from using smaller textures. No amount of mipmap trickery can work around that. There are much lower hanging fruit to worry about.

---

Depends on how you use the textures. If you want 512x768 for the table and 512x768 for the chair, yes. The results would probably not be that much better than two 512x512s. And some people might want only the table, no chairs. Then you really have unused texture space.

[...]

I'm not sure it does, but I am sure it's possible, since a LoD change means a model change. One copy of one object is what you'll be looking at in most cases and in SL most objects have unique textures. If you build grass or trees it's probably not a wise choice. If you are building pretty much anything else you won't often see duplicates. This is very different from what you'll see in video games, where reusing textures is the norm for obvious reasons.

 

 

---

This just highlights the differences between sl and a real game. In a real game you can make these sorts of guaranties about objects so doing these kinds of optimizations makes sense.

---

Point taken.... but that's how it works now, not how is has to work.

---

The viewer would have to keep track of all the objects at all the time, it would need some smarts for times when people zoom in and out so it doesn't keep loading and unloading textures, etc. It's possible, but it's also an easy way to add bugs. I can see the jira issues now about the viewer being confused about how far an object is and refusing to load the high texture and so on.

 

 

[Kwakkelde Kwak]

---

leliel Mirihi wrote:

To what end? What are you trying to save by doing this? It's the full size image that's taking up all the ram, cutting back on some image half way down the mip chain isn't going to do much of anything. We're talking about extensive modifications to the viewer to over ride how the GPU does mipmaps to save, what 5%? Who cares? There are much lower hanging fruit.

---

Isn't that exactly what I said 10 times already? It not being worth the efford and it being academic...

 

---

This just highlights the differences between sl and a real game. In a real game you can make these sorts of guaranties about objects so doing these kinds of optimizations makes sense.

---

I'd say quite the opposite.

 

---

The viewer would have to keep track of all the objects at all the time, it would need some smarts for times when people zoom in and out so it doesn't keep loading and unloading textures, etc. It's possible, but it's also an easy way to add bugs. I can see the jira issues now about the viewer being confused about how far an object is and refusing to load the high texture and so on.

---

And how does the viewer know what LoD to show? Because it already keeps track of both object size and position. The loading textures issue I already mentioned and I wouldn't be surprised it's at least one of the reasons LL decided to go with an all textures for all LoDs approach.

 

 

[leliel Mirihi]

---

Kwakkelde Kwak wrote:

---

leliel Mirihi wrote:

To what end? What are you trying to save by doing this? It's the full size image that's taking up all the ram, cutting back on some image half way down the mip chain isn't going to do much of anything. We're talking about extensive modifications to the viewer to over ride how the GPU does mipmaps to save, what 5%? Who cares? There are much lower hanging fruit.

---

Isn't that exactly what I said 10 times already? It not being worth the efford and it being academic...

---

As the edit to my above post shows it's beyond academic to the point of being a waste of time to talk about.

---

Kwakkelde Kwak wrote:

---

leliel Mirihi wrote:

This just highlights the differences between sl and a real game. In a real game you can make these sorts of guaranties about objects so doing these kinds of optimizations makes sense.

---

I'd say quite the opposite.

---

Your examples I quoted say otherwise.

---

And how does the viewer know what LoD to show? Because it already keeps track of both object size and position. 

---

I already said it's possible to get it to work, just not worth the effort.

 

[Kwakkelde Kwak]

---

leliel Mirihi wrote:

 

As the edit to my above post shows it's beyond academic to the point of being a waste of time to talk about.

---

Yet you kept talking about it where I wanted to leave it a page or so ago....

 

---

Your examples I quoted say otherwise.

---

 

In a video game textures are used as many times as possible, in SL they aren't. So working with a trick or solution or technique that only works for non duplicated items would suit SL, not an optimised video game.

 

---

I already said it's possible to get it to work, just not worth the effort.

---

If you can somehow keep the high res texture out of the vid memory when it isn't used, I'd say that could be very well worth the efford. If it is cached onto your HD, it won't take that long to load it when needed aswell.

[leliel Mirihi]

---

Kwakkelde Kwak wrote:

---

leliel Mirihi wrote:

 

As the edit to my above post shows it's beyond academic to the point of being a waste of time to talk about.

---

Yet you kept talking about it where I wanted to leave it a page or so ago....

---

lol I wanted to drop it a few pages ago as well. I guess we both just like to argue. ^.^

---

In a video game textures are used as many times as possible, in SL they aren't. So working with a trick or solution or technique that only works for non duplicated items would suit SL, not an optimised video game.

---

Video games use dirty tricks like this all the time to cut down on resource usage, especially on consoles.

 

 

[Kwakkelde Kwak]

---

leliel Mirihi wrote:

Video games use dirty tricks like this all the time to cut down on resource usage, especially on consoles.

---

I'm not that familiar with video games, not at all actually, but I am pretty sure it would do wonders for SL if LL makes it possible, as you edited yourself, it would mean a 66% decrease in video memory use if the highest res could be left out and up to pretty much 100% if the object is in the far far distance.

 

 

[leliel Mirihi]

---

Kwakkelde Kwak wrote:

---

leliel Mirihi wrote:

Video games use dirty tricks like this all the time to cut down on resource usage, especially on consoles.

---

I'm not that familiar with video games, not at all actually, but I am pretty sure it would do wonders for SL if LL makes it possible, as you edited yourself, it would mean a 66% decrease in video memory use if the highest res could be left out and up to pretty much 100% if the object is in the far far distance.

 

 

---

That could work, would have to do some testing to see how well it would fit in with the viewer tho. I think using texture compression would also be good, it would give 75-87% savings across the board at the cost of image quality. It would eat up some CPU time to recompress the textures but most librarys are pretty fast. 

[Kwakkelde Kwak]

Hmm, at the cost of image quality? I don't think that's what we're after.... an 80% reduction sounds very appealing though.