Re: Replicated textures

[James W. <ja...@fr...>]

Roger Holmes wrote:

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

Good question.  Q3Storage_SetData bumps the edit index, but there are 
probably a number of other ways to change a storage object.  For 
instance, I suppose you could use Q3MemoryStorage_GetBuffer to get a 
pointer to the bytes, and then change some bytes, and the storage object 
would have know way of knowing it was 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.
> 
> 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.

Of course, if it's a file storage, you'd have to read the file to 
compute the hash... though I don't know if anyone is likely to use a 
file storage for texture data.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>