Henri
I was able to merge and build and verify kokua on aditi; the top 2 commits are
post merge tweaks. I don't know if that can help diff wise but, feel free to
use.
The last upstream merge to kokua was viewer-release, last Monday's merge.
Nicky
https://bitbucket.org/NickyP/kokua-sunshine-external/overview
>________________________________
> From: Henri Beauchamp <sl...@free.fr>
>To: Oz Linden (Scott Lawrence) <o...@lindenlab.com>
>Cc: opensource-dev <opensource-dev@lists.secondlife.com>
>Sent: Monday, December 17, 2012 2:43 AM
>Subject: Re: [opensource-dev] Upcoming server side avatar baking
>
>On Fri, 14 Dec 2012 16:40:58 -0500, Oz Linden (Scott Lawrence) wrote:
>
>> For any of you developing viewers that are not in the TPV Directory and
>> so didn't get the notice there....
>>
>> We have now made available the code for our upcoming server side baking
>> changes - you will need to update to be compatible with this in order
>> for users to see avatars correctly once the server side change is rolled
>> out to the main grid (some time > 8 weeks from now, but no date has been
>> set yet).
>>
>> See
>> https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance
>> for information on this new code, and watch it for updates.
>
>Alas, the said repository doesn't match any of viewer-release, viewer-beta
>or viewer-development code, making it impossible to get a clean diff of
>the actual, related, relevant changes.
>
>The diff I get against any of the three public branches of the viewer is
>over 2Mb big and contains changes to the UI, the path finding tools, the
>renderer (llrender and pipeline), the vfs, and many more cruft that seems
>(but it's hard to be 100% sure for everything without carefully studying
>the code) totally unrelated with the server side baking changes.
>
>Could you please provide a repository which is the copy of the one that
>was used to implement server side baking changes but that would be clean
>of those changes (this way, we could create a clean diff containing only
>the relevant changes, which would help immensely and prevent long trial
>and error sessions figuring out what is needed or not) ?
>
>I also deeply regret that you took the hard-coded approach (making the
>baking code rely on a hard-coded inventory tree) and used the COF
>directory to pick up the texture IDs to use in the bake (this should
>have been provided as a list by the viewer, so that the inventory
>structure is only dependent on the UI of the said viewer and on how
>the users wish to arrange their own inventory). One of the flaws of
>your approach is that your baking system can't detect when a change
>is done to a wearable that is being worn (you admit it yourself in
>the Wiki page, indicating yet another capability will be needed to
>signal such a case)... A poor implementation choice, IMHO.
>
>Regards,
>
>Henri.
>_______________________________________________
>Policies and (un)subscribe information available here:
>http://wiki.secondlife.com/wiki/OpenSource-Dev
>Please read the policies before posting to keep unmoderated posting privileges
>
>
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
