Re: Replicated textures

[James W. W. <os...@jw...>]

On Feb 13, 2007, at 5:12 AM, Roger Holmes wrote:

> I have been thinking about a problem we are having with multiple
> objects having the same texture on them. They are gobbling up
> all the logical address space and also causing thrashing on
> Macs with less than 2GB of RAM.

Been there...

> At one time, when we read in objects, we would compare all
> their textures with all existing textures and all their own other
> textures. We would then make identical ones share the same
> texture shader objects. This worked fine except we had to take
> it out because users were complaining about the speed of
> reading files.

When I read an object, I compare (hashes of) its textures to each  
other and share if possible, but I don't compare to other objects.   
That's an interesting thought.

> The comparisons had the obvious speed ups of comparing
> the size etc first before comparing the actual pixels. What I
> am now thinking about is storing a hash of the pixels so
> that most of the time I will only have to compare the hash.
> When two identical hashes are found, I do not mind doing
> the comparison because the chances are very good that
> the textures really are the same and I will be saving memory.

You'd have to be careful to invalidate the cached hash if the texture  
or its storage is edited.

> The question is where to store the hashes. I could put them
> in a custom attribute. This would be fine for me, but would
> we be missing an opportunity. If they were stored in the
> texture shaders or even the storage objects, would this
> be of any use to either the renderers or the saving code
> or anywhere else?

It's not immediately obvious to me how it would be of use.