Re: Replicated textures

[Roger H. <rog...@mi...>]

On 13 Feb, 2007, at 16:01, James W. Walker wrote:

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

Can I presume the edit index of the storage object is kept up to date?

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

Ok, but you have done the same as I'm going to so maybe it
would help the next person who wants to reinvent the wheel.

Maybe we could have a method on the storage object which gives a
hash code. If we stored a cached value and the edit index (which
gets set to an invalid value in the NEW method) in the storage
object's header, then when we are asked for the hash, we compare
the edit indexes. If they match we return the cached value, if not
we update the copy of the edit index, hash the data block, store it
in the cache and return its value.

The extra information in the header would not need to be saved
on disc.

Roger