[Opensim-dev] Baked Texture persistence?

Mon Oct 3 19:46:33 UTC 2011

Yes, block ID in the WearableDataBlock AgentCachedTexture packet is a hash
of all wearables that are part of certain bake + 1 magic uuid per bake. The
way it works is:

* After login, client gets the list of wearables from the sim.
* Computes the hashes for each bake and sends it to sim
with AgentCachedTexture packet.
* Sim sends back AgentCachedTextureResponse with UUIDs of cached bakes it
has. UUID.Zero if doesn't have it
* Client creates uploads only bakes that are a mismatch
* Client sends set appearance packet and this completes the exchange

Latif

On Sat, Oct 1, 2011 at 11:49 PM, Mic Bowman <cmickeyb at gmail.com> wrote:

> this is the one where the wearables uuids are xor'ed with some "pink
> flamingo" uuid to get a hash of the wearables combination? i looked at the
> code in libomv to get an idea for how it might work. the opensim side will
> be a bit challenging to support the map to the baked textures.
>
> --mic
>
>
> On Sat, Oct 1, 2011 at 1:51 PM, Latif Khalifa <latifer at streamgrid.net>wrote:
>
>> We have client side of the cached bakes check implemented in libomv. In
>> case you are going to implement this server side you can ping me for
>> details.
>>
>>
>> On Mon, Sep 26, 2011 at 12:04 AM, Justin Clark-Casey <
>> jjustincc at googlemail.com> wrote:
>>
>>> That's great info, Mic - I wasn't aware of this message exchange.
>>>
>>> It sounds like in the future it would be a good idea to implement these
>>> messages and remove temporary assets from the asset service periodically.
>>>
>>> Justin
>>>
>>>
>>> On 25/09/11 19:38, Mic Bowman wrote:
>>>
>>>> I will carefully disagree with Justin on this one. The viewer doesn't
>>>> upload textures by default. It only uploads the
>>>> textures if it believes something has changed. OpenSim doesn't currently
>>>> respond correctly to the v2/v3 packets for
>>>> cached appearance and earlier versions of the viewer can be told that
>>>> that appearance parameters haven't changed so that
>>>> textures are never uploaded (this saves a lot of bw... remember that if
>>>> you upload textures they have to be sent out to
>>>> everyone in the scene so it isn't the upload bw... its like putting new
>>>> textures on objects every time the sim starts).
>>>> In practice, people change appearance so infrequently that the baked
>>>> textures do not fill up the asset database. And
>>>> even when the do, so long as you don't get stuck in the "assets can
>>>> never be deleted" way of thinking... (baked textures
>>>> are marked as temporary anyway)... its pretty easy to clean up the asset
>>>> db based on a reasonable set of policies.
>>>>
>>>>
>>>>
>>>> On Sun, Sep 25, 2011 at 1:25 AM, Neil Canham <neil at knowsense.co.uk<mailto:
>>>> neil at knowsense.co.uk>> wrote:
>>>>
>>>>    Ah - I hadn't appreciated that NPCs need to be cloned from a logged
>>>> in AV.  That makes sense.
>>>>
>>>>    As for the persistence, like Mic I think there is potentially an
>>>> argument for it, as an option, for closed private
>>>>    sims for example, or sims where you expect a lot of people to log in
>>>> at roughly the same time.  However, I
>>>>    appreciate that would be a big change so thanks for clarifying how it
>>>> operates now.
>>>>
>>>>
>>>>    On Sat, Sep 24, 2011 at 11:18 PM, Justin Clark-Casey <
>>>> jjustincc at googlemail.com <mailto:jjustincc at googlemail.**com<jjustincc at googlemail.com>>>
>>>> wrote:
>>>>
>>>>        For ordinary avatars, baked textures don't need permanent
>>>> persistence since the avatar uploads them on every
>>>>        login or when any body part/wearable is changed.  This will have
>>>> no effect on slow rezzing or cloudiness - if a
>>>>        viewer is in the region it should always have uploaded the
>>>> textures that it bakes.
>>>>
>>>>        Indeed, there's little value in persisting these since the client
>>>> will upload them on every login/region
>>>>        entrance. Persisting baked textures would bloat the asset service
>>>> more than is already the case.
>>>>
>>>>        An NPC, on the other hand, has no viewer from which these baked
>>>> textures are uploaded.  So they have to be disk
>>>>        persisted at the point from which it is cloned from a 'live'
>>>> avatar.
>>>>
>>>>
>>>>        On 24/09/11 19:28, Neil Canham wrote:
>>>>
>>>>            I confess that I am puzzled.  I found this fantastic
>>>> description from Mic of how 0.7 appearance works
>>>>            http://opensim-dev.2196679.n2.**__nabble.com/What-I-ve-**
>>>> Learned-__About-**AvatarAppearance-__td5655933.**html<http://nabble.com/What-I-ve-Learned-__About-AvatarAppearance-__td5655933.html>
>>>>
>>>>            <http://opensim-dev.2196679.**n2.nabble.com/What-I-ve-**
>>>> Learned-About-**AvatarAppearance-td5655933.**html<http://opensim-dev.2196679.n2.nabble.com/What-I-ve-Learned-About-AvatarAppearance-td5655933.html>>
>>>> and it
>>>>            fits with what I
>>>>            see analysing the packets against 0.7.1.  So that seems quite
>>>> clearly to say that baked textures are never
>>>>            persisted,
>>>>            and that would explain the slow rezzing and 'cloudiness' of
>>>> avatars that I see regularly.  However, the new
>>>>            npc code
>>>>            seems to require that a baked texture is available to copy
>>>> from. So are baked textures now persisted in the
>>>>            latest code?
>>>>
>>>>
>>>>
>>>>            ______________________________**___________________
>>>>            Opensim-dev mailing list
>>>>            Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**
>>>> berlios.de <Opensim-dev at lists.berlios.de>>
>>>>            https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>>        --
>>>>        Justin Clark-Casey (justincc)
>>>>        http://justincc.org/blog
>>>>        http://twitter.com/justincc
>>>>        ______________________________**___________________
>>>>        Opensim-dev mailing list
>>>>        Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**
>>>> berlios.de <Opensim-dev at lists.berlios.de>>
>>>>        https://lists.berlios.de/__**mailman/listinfo/opensim-dev<https://lists.berlios.de/__mailman/listinfo/opensim-dev><
>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>> >
>>>>
>>>>
>>>>
>>>>    ______________________________**_________________
>>>>    Opensim-dev mailing list
>>>>    Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.**berlios.de<Opensim-dev at lists.berlios.de>
>>>> >
>>>>
>>>>    https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>
>>>>
>>>>
>>>>
>>>> ______________________________**_________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>>
>>>
>>>
>>> --
>>> Justin Clark-Casey (justincc)
>>> http://justincc.org/blog
>>> http://twitter.com/justincc
>>> ______________________________**_________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/**mailman/listinfo/opensim-dev<https://lists.berlios.de/mailman/listinfo/opensim-dev>
>>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20111003/7fe49d08/attachment-0001.html>