Re: [opensource-dev] Upcoming server side avatar baking
On Sat, 12 Jan 2013 02:56:53 +0100, Latif Khalifa wrote: On Fri, Jan 11, 2013 at 9:13 PM, Henri Beauchamp sl...@free.fr wrote: Nevermind (though, having a propely built Linux Sunshine-viewer would still be a good thing), I figured out the bug (race condition between links creation in COF and rebake requests). How do you work around that? When I was implementing this in Radegast it seemed that the service would respond to link creation request and it would still sometimes fail with COF mismatch as if the baking service didn't get the message. Well, my COF implementation is entirely different from LL's... For example, it only uses 3 functions and one callback to sync the COF (and that's because I also implemented *optional* attachments links syncing; without the optional part, i.e. with systematic attachments syncing, it'd take only 2 functions and one callback) and entirely avoids LL's (ridiculously) convoluted code; so it's hard to describe in a message... But to avoid the race conditions, I also modified the requestServerAppearanceUpdate() function and its callback (RequestAgentUpdateAppearanceResponder) so that only one such callback is active at any time (i.e. if other rebake requests are done before the last rebake is completed (or failed), the requests are queued (or more exactly, a mNeedsServerSideRebake flag is set and tested for to fire a new rebake on completion of the ongoing one). I also use a timer (gUpdateCOFTimer) that is reset each time a new link is created and tested for before requestServerAppearanceUpdate() is called (the latter being called in one place only, based on the mNeedsServerSideRebake flag and on the timer value). You'd better have a look at my code (at the end of llappearance.cpp) for full understanding of how things work; note that I since found a bug in it: in requestServerAppearanceUpdate(), the test for RequestAgentUpdateAppearanceResponder::isActive() should be moved inside the if (!responder_ptr.get()) block. The bug only affects rebakes when a request fails and is retried within the RequestAgentUpdateAppearanceResponder callback (which didn't seem to happen so far on Aditi, given the very low load on the server-side rebaker). Note that there seem to be a server-side race condition as well: sometimes, the rebake request succeeds (with matching COF versions) and the viewer does recieve the UUIDs for the baked textures, but when it attempts to fetch the corresponding textures too soon (with 150+ FPS in the testing sims, the delay between the request acknowlegment and the texture fetch that happens at next frame can indeed be very short) the texture fetch fails with a 404 error: if you retrieve it later from a browser using the failed cap, you however do get the corresponding texture, meaning that the rebaker replied ok to the request before the texture could be made available by the texture server... 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
Re: [opensource-dev] Upcoming server side avatar baking
On Wed, 9 Jan 2013 17:26:51 +0100, Henri Beauchamp wrote: The Linux viewer available for download from Sunshine's Wiki page has alas been compiled with a way too new glibc end refuse to run on my system (Mandriva 2010.2, glibc v2.11.1), aborting with: bin/do-not-directly-run-secondlife-bin: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by bin/do-not-directly-run-secondlife-bin) Could we please get a viewer compiled on the same build system as the one used for LL's other viewers ? Thank you. Henri. PS: I'm currently testing a server-side baking compatible Cool VL Viewer and trying to figure out a COF version missmatch issue (which ressembles this one: https://jira.secondlife.com/browse/SUN-3) that could be due to the inventory issues on Aditi: without a known, working viewer to compare with, it's hard to figure out if it's a bug in my backport or a bug in Aditi's inventory server... Nevermind (though, having a propely built Linux Sunshine-viewer would still be a good thing), I figured out the bug (race condition between links creation in COF and rebake requests). The of the Cool VL Viewer v1.26.7.5 (experimental branch) has been released today with server-side baking support. 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
Re: [opensource-dev] Upcoming server side avatar baking
On Fri, Jan 11, 2013 at 9:13 PM, Henri Beauchamp sl...@free.fr wrote: Nevermind (though, having a propely built Linux Sunshine-viewer would still be a good thing), I figured out the bug (race condition between links creation in COF and rebake requests). How do you work around that? When I was implementing this in Radegast it seemed that the service would respond to link creation request and it would still sometimes fail with COF mismatch as if the baking service didn't get the message. The of the Cool VL Viewer v1.26.7.5 (experimental branch) has been released today with server-side baking support. Great! ___ 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
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. The Linux viewer available for download from Sunshine's Wiki page has alas been compiled with a way too new glibc end refuse to run on my system (Mandriva 2010.2, glibc v2.11.1), aborting with: bin/do-not-directly-run-secondlife-bin: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by bin/do-not-directly-run-secondlife-bin) Could we please get a viewer compiled on the same build system as the one used for LL's other viewers ? Thank you. Henri. PS: I'm currently testing a server-side baking compatible Cool VL Viewer and trying to figure out a COF version missmatch issue (which ressembles this one: https://jira.secondlife.com/browse/SUN-3) that could be due to the inventory issues on Aditi: without a known, working viewer to compare with, it's hard to figure out if it's a bug in my backport or a bug in Aditi's inventory server... ___ 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
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
Re: [opensource-dev] Upcoming server side avatar baking
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
Re: [opensource-dev] Upcoming server side avatar baking
On Mon, 17 Dec 2012 05:35:06 -0800 (PST), Nicky Perian wrote: 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 I'm afraid it doesn't help. What I need to avoid wasting my little free time in this period of the year, is a clean diff with only the *relevant*, *minimal* changes in it. The fact you could merge the sunshine branch with another v3-based viewer doesn't help (you simply merged stuff that is still not validated/adopted/committed to the viewer-development and viewer-beta banches together the (soon) mandatory server side baking code). 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
Re: [opensource-dev] Upcoming server side avatar baking
I fail to see how anyone's time (LL devs included) is more or less valuable during the upcoming holidays. You can work this through to diff using hg by: clone the sunshine repo. find the point of first sunshine commit. update to it give it a sunshine bookmark or branch. doesn't matter which update to tip and do a dummy commit (may not be needed) clone viewer-development pull the sunshine branch into v-d do not update or merge the branch hg graft the beginning to end sunshine branch change sets resolve the merges as you go once done the sunshine branch will be re-based to the front of v-d change the phase of all the cs, if not allready, to draft import all to mq un-apply all but first fold all the un-applied to the first export a patch/diff. this is more or less the procedure i have used to cherry pick. From: Henri Beauchamp sl...@free.fr To: opensource-dev@lists.secondlife.com Sent: Monday, December 17, 2012 9:54 AM Subject: Re: [opensource-dev] Upcoming server side avatar baking On Mon, 17 Dec 2012 05:35:06 -0800 (PST), Nicky Perian wrote: 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 I'm afraid it doesn't help. What I need to avoid wasting my little free time in this period of the year, is a clean diff with only the *relevant*, *minimal* changes in it. The fact you could merge the sunshine branch with another v3-based viewer doesn't help (you simply merged stuff that is still not validated/adopted/committed to the viewer-development and viewer-beta banches together the (soon) mandatory server side baking code). 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
Re: [opensource-dev] Upcoming server side avatar baking
On Mon, 17 Dec 2012 09:18:04 -0800 (PST), Nicky Perian wrote: I fail to see how anyone's time (LL devs included) is more or less valuable during the upcoming holidays. You can work this through to diff using hg by: clone the sunshine repo. find the point of first sunshine commit. update to it give it a sunshine bookmark or branch. doesn't matter which update to tip and do a dummy commit (may not be needed) clone viewer-development pull the sunshine branch into v-d do not update or merge the branch hg graft the beginning to end sunshine branch change sets resolve the merges as you go once done the sunshine branch will be re-based to the front of v-d change the phase of all the cs, if not allready, to draft import all to mq un-apply all but first fold all the un-applied to the first export a patch/diff. this is more or less the procedure i have used to cherry pick. Excepted that: 1.- the initial sunchine repo (from which the server baking branch was forked: sunshine-internal ?) is not public; 2.- the first changes happened months ago and now that sunshine-external was merged with viewer-develompent, it becomes impossible to distinguish what commit was applied to what branch (repos are a mess ! I always hated them !); 3.- I don't have the time to browse some 850+ pages of commits to see when and which commit is relevant to the new code or not (it would be simpler and faster for me to clean up by hand the diff between viewer-develompent and sunshine-external) ! It would be MUCH simpler for LL to just clone the original repo (*they* know when the repo was branched and what was the first commit to it), merge the viewer-development commits into it (the same commits they merged in the sunshine-external repo) and make the clone public. I would then just download the sources for that clone and diff it with sunshine-external: done ! All changes at hand in a single diff, and all relevant to the actual task at hand. 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
Re: [opensource-dev] Upcoming server side avatar baking
On 2012-12-17 03:43 , Henri Beauchamp wrote: 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) ? No, we can't, sorry. That project has been in development for some months. They have done very significant refactoring in order to better organize the code around avatar appearance, and have merged out from viewer-development a number of times. The entire history is in the repository you can see, which is ultimately derived from an earlier version of viewer-development (you're just as capable of finding that fork point as anyone else is). Yes, there are lots and lots of changes here. 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. I'm sure that there were any number of fundamental design decisions that could have been made differently, but our purpose here is not to either revisit those debates or to explain why we made the choices we did. The fundamental design decisions have been made, and we're going to proceed with the design we've got. If you have questions about how the code works, and especially the new messages exchanged regarding avatar appearance, ask them here and we'll do what we can to help. ___ 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
Re: [opensource-dev] Upcoming server side avatar baking
On Mon, Dec 17, 2012 at 10:18 PM, Oz Linden (Scott Lawrence) o...@lindenlab.com wrote: I'm sure that there were any number of fundamental design decisions that could have been made differently, but our purpose here is not to either revisit those debates or to explain why we made the choices we did. The fundamental design decisions have been made, and we're going to proceed with the design we've got. People who don't fancy themselves to be the infallible gods of system design often find it beneficial to hear the feedback, especially in opensource projects. It might even lead to (gasp) more reliable system and better customer satisfaction. Whenever I relapse into using my time to help improve Linden Lab's products by doing testing, filing bug reports and repro cases, Oz Linden's attitude quickly convinces me that it's not worth it. (This email started as my feedback about some timing issue with network messages that could potentially cause bake fails, but then I saw all-knowing Oz dismiss any need for it) ___ 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
[opensource-dev] Upcoming server side avatar baking
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. ___ 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
