[Opensim-dev] Baked Texture persistence?

Latif Khalifa latifer at streamgrid.net
Mon Oct 3 19:52:18 UTC 2011 

Forgot to add. So the sim would have associate CacheID from
the AgentSetAppearance's WearableData block with texutre IDs provided at
that specific bake indexes of the TextureEntry in the same packet and
respond accordingly in AgentCachedTexture/AgentCachedTextureResponse
response excahnge.

What does opensim do currently when it gets AgentCachedTexture message?

On Mon, Oct 3, 2011 at 9:46 PM, Latif Khalifa <latifer at streamgrid.net>wrote:

> 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/47da6a4b/attachment-0001.html>

More information about the Opensim-dev mailing list