From hitomi.tiponi at yahoo.co.uk Mon Jul 2 09:39:41 2012 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Mon, 2 Jul 2012 17:39:41 +0100 (BST) Subject: [opensource-dev] Time flies - well in Snowstorm builds it does! In-Reply-To: References: Message-ID: <1341247181.29323.YahooMailNeo@web171002.mail.ukl.yahoo.com> I know you guys are rushing to get to your holiday but the latest Snowstorm viewer-development build (21006) is marked as completed at "03 July 2012 00:18:35 (1341271115)".? Thought you should know in case the date-stamps mess up anything in the repository. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120702/628e0762/attachment.htm From liny.odell at phoenixviewer.com Mon Jul 2 14:33:00 2012 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Mon, 2 Jul 2012 14:33:00 -0700 Subject: [opensource-dev] LLSD XML cleanup program Message-ID: If anyone is interested, I wrote a small program (total of 6 lines, not counting main() and includes) that reads in a LLSD formatted XML and writes it back out, formatting it like the saved settings version as compared to the default settings formatting, and has the advantage of putting all the settings in alphabetical order also. Don't know if this would be of any interest to anyone except for making the default settings files a little more organized. It should compile fine on mac and linux, haven't tested them though. For compiling, set the includes to the llcommon directory of the normal viewer and the include directory of the third party libs of the viewer and link it against llcommon.lib (or the equivalent on mac/linux). then make sure the libapr dll's and llcommon.dll in the same directory as the output executable and it will work on the file "target.xml" in its working directory, reading from it and overwriting it when its done. As for the license of the following code below, Public domain or WTFPL, whichever you want. I also can't and won't provide any help with it either. The full program is: #include #include "llsdserialize.h" #include #include int main(int argc, char* argv[]) { LLSD tmp; std::ifstream in("target.xml"); LLSDSerialize::fromXML(tmp,in); std::ofstream out("target.xml"); LLSDSerialize::toPrettyXML(tmp,out); return 0; } From hitomi.tiponi at yahoo.co.uk Mon Jul 2 15:04:47 2012 From: hitomi.tiponi at yahoo.co.uk (Hitomi Tiponi) Date: Mon, 2 Jul 2012 23:04:47 +0100 (BST) Subject: [opensource-dev] Time flies - well in Snowstorm builds it does! In-Reply-To: <4FF1D1A4.4070009@lindenlab.com> References: <1341247181.29323.YahooMailNeo@web171002.mail.ukl.yahoo.com> <4FF1D1A4.4070009@lindenlab.com> Message-ID: <1341266687.75209.YahooMailNeo@web171005.mail.ukl.yahoo.com> It is in the latest Snowstorm build Oz - http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/integration_viewer-development/rev/261018/index.html ________________________________ From: Oz Linden (Scott Lawrence) To: Hitomi Tiponi Sent: Monday, 2 July 2012, 17:51 Subject: Re: [opensource-dev] Time flies - well in Snowstorm builds it does! On 2012-07-02 12:39 , Hitomi Tiponi wrote: I know you guys are rushing to get to your holiday but the latest Snowstorm viewer-development build (21006) is marked as completed at "03 July 2012 00:18:35 (1341271115)".? Thought you should know in case the date-stamps mess up anything in the repository. > Can you be more specific about where you saw that date? There are in fact many possibilities.... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120702/7502a7fa/attachment.htm From fuerholz at gmx.net Mon Jul 2 15:59:48 2012 From: fuerholz at gmx.net (MartinRJ Fayray) Date: Mon, 02 Jul 2012 22:59:48 -0000 Subject: [opensource-dev] Review Request: STORM-1893: 'share' function (in friends-list) doesn't bring up the residents' IM window when it's minimized Message-ID: <20120702225948.1259.29083@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/589/ ----------------------------------------------------------- Review request for Viewer. Description ------- Repository is here: https://bitbucket.org/MartinRJ/storm-1893 I just added two calls to show() and setVisible() in LLAvatarActions::share to bring the IM window to front even when it's minimized. This addresses bug STORM-1893. https://jira.secondlife.com/browse/STORM-1893 Diffs ----- indra/newview/llavataractions.cpp 4d9106153407 Diff: http://codereview.secondlife.com/r/589/diff/diff Testing ------- Please see the test plan in the Jira. Thanks, MartinRJ Fayray -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120702/01959e26/attachment.htm From oz at lindenlab.com Tue Jul 3 08:16:24 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 03 Jul 2012 11:16:24 -0400 Subject: [opensource-dev] Oz meeting cancelled Thursday 07-05 Message-ID: <4FF30CC8.7040408@lindenlab.com> I won't be holding my usual Thursday Open Developer meeting this Thursday (heading out early for a long weekend). From annie66us at yahoo.com Tue Jul 10 14:19:36 2012 From: annie66us at yahoo.com (Anne Ogborn) Date: Tue, 10 Jul 2012 14:19:36 -0700 (PDT) Subject: [opensource-dev] broke path to plugin In-Reply-To: <4FF30CC8.7040408@lindenlab.com> Message-ID: <1341955176.83188.YahooMailClassic@web112101.mail.gq1.yahoo.com> I'm debranding a viewer, and pointing all the URL's at our servers instead of SL. When I start up, instead of seeing the startup splash page I see this message Cannot open file:///C:/development/viewer/hhpviewer/build-vc100/newview/RelWithDebInfo/llplugin: Path is a directory Displayed on the screen. It's displayed as selectable text. I assume I did something foolish with a path somewhere, but I can't for the life of me figure out where this message is coming from in the sources. unfortunately it didn't show up until I rebuilt some parts of the webkit interfacing stuff for other reasons, so I'm a bit puzzled where it came from. Any help would be massively appreciated Annie the slightly squidgy, Newbie viewer modder From jhwelch at gmail.com Wed Jul 11 16:01:15 2012 From: jhwelch at gmail.com (Jonathan Yap) Date: Wed, 11 Jul 2012 23:01:15 -0000 Subject: [opensource-dev] Review Request: STORM-1898 Add "Copy SLURL" to context menu when right clicking Landmarks in Inventory Message-ID: <20120711230115.24773.24474@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/591/ ----------------------------------------------------------- Review request for Viewer. Description ------- SLURLs get passed around frequently in SL and on websites, etc. There should be an easier way to copy the SLURL from a Landmark in inventory. Currently you must go through several steps to copy a SLURL from a landmark in inventory: 1)right click LM 2)Click "About Landmark" 3)Click "Map" 4)Click "Copy SLurl" It would be much more efficient if you could just: 1)right click LM 2)click "Copy SLurl" This addresses bug STORM-1898. https://jira.secondlife.com/browse/STORM-1898 Diffs ----- indra/newview/llinventorybridge.h 4d9106153407 indra/newview/llinventorybridge.cpp 4d9106153407 indra/newview/skins/default/xui/en/menu_inventory.xml 4d9106153407 Diff: http://codereview.secondlife.com/r/591/diff/diff Testing ------- See test plan in jira. Thanks, Jonathan Yap -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120711/fa4854da/attachment.htm From cjohndavies at gmail.com Thu Jul 12 04:09:49 2012 From: cjohndavies at gmail.com (CJ Davies) Date: Thu, 12 Jul 2012 12:09:49 +0100 Subject: [opensource-dev] Using Boost & the viewer Message-ID: <4FFEB07D.9060205@gmail.com> I'm trying to get the viewer to read data from an Arduino via serial (long story...). I'm using Boost for this. So far I have changed the Boost prebuilt in autobuild.xml to this one after a conversation with LightDrake on #opensl on freenode; https://bitbucket.org/LightDrake/public-libs/downloads/boost-1.45.0-linux-20120213.tar.bz2 then added a boost_thread line to indra/cmake/Boost.cmake & added ${BOOST_SYSTEM_LIBRARY} & ${BOOST_THREAD_LIBRARY} to indra/newview/CMakeLists.txt. This allows the .h & .cpp files that implement the serial functionality to be added to the build & successfully built, however when I try to include one of these header files in llviewerjoystick.h the build fails spectacularly. This is the file that I am trying to #include in llviewerjoystick.h --> http://paste2.org/p/2071086 This is the output of the build --> http://paste2.org/p/2071087 I assume there isn't actually anything wrong with the code & I'm just still missing part of Boost that I need. Can anybody help me identify this? Regards, CJ Davies From cinder at cinderblocks.biz Thu Jul 12 15:01:31 2012 From: cinder at cinderblocks.biz (Cinder Roxley) Date: Thu, 12 Jul 2012 16:01:31 -0600 Subject: [opensource-dev] Using Boost & the viewer In-Reply-To: <4FFEB07D.9060205@gmail.com> References: <4FFEB07D.9060205@gmail.com> Message-ID: <4FFF493B.70205@cinderblocks.biz> Hi! The warnings in your build log relate to the error_code library in the Boost.System library. They're a side effect of the design decision made in the library which I will spare you details of (more info on it here: http://www.boost.org/doc/libs/1_41_0/libs/system/doc/reference.html#Class-error%5Fcategory ) If you aren't using the definitions you're getting the warnings about, try including the following lines of code before including the header file: |#ifndef BOOST_SYSTEM_NO_DEPRECATED #define BOOST_SYSTEM_NO_DEPRECATED1 #endif| Kind regards, Cinder Roxley On 7/12/2012 5:09 AM, CJ Davies wrote: > I'm trying to get the viewer to read data from an Arduino via serial > (long story...). I'm using Boost for this. > > So far I have changed the Boost prebuilt in autobuild.xml to this one > after a conversation with LightDrake on #opensl on freenode; > > https://bitbucket.org/LightDrake/public-libs/downloads/boost-1.45.0-linux-20120213.tar.bz2 > > then added a boost_thread line to indra/cmake/Boost.cmake & added > ${BOOST_SYSTEM_LIBRARY} & ${BOOST_THREAD_LIBRARY} to > indra/newview/CMakeLists.txt. > > This allows the .h & .cpp files that implement the serial functionality > to be added to the build & successfully built, however when I try to > include one of these header files in llviewerjoystick.h the build fails > spectacularly. > > This is the file that I am trying to #include in llviewerjoystick.h --> > http://paste2.org/p/2071086 > > This is the output of the build --> http://paste2.org/p/2071087 > > I assume there isn't actually anything wrong with the code & I'm just > still missing part of Boost that I need. Can anybody help me identify this? > > Regards, > CJ Davies > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120712/9515c2b2/attachment.htm From cjohndavies at gmail.com Fri Jul 13 02:17:03 2012 From: cjohndavies at gmail.com (CJ Davies) Date: Fri, 13 Jul 2012 10:17:03 +0100 Subject: [opensource-dev] Using Boost & the viewer In-Reply-To: <4FFF493B.70205@cinderblocks.biz> References: <4FFEB07D.9060205@gmail.com> <4FFF493B.70205@cinderblocks.biz> Message-ID: <4FFFE78F.4070406@gmail.com> Thanks for your response Cinder. In the #boost channel on freenode somebody helped me track down the problem to a preprocessor collision caused by this declaration in build-/packages/include/glh/glh_linear.h #define equivalent(a,b) (((a < b + GLH_EPSILON) && (a > b - GLH_EPSILON)) ? true : false) Strangely this comes at the end of a list of #define statements that are all prefixed by the 'unique' string GLH_ so it seems odd that the declaration of equivalent didn't follow the same regime. I changed it to template < typename T, typename U > inline bool GLH_EQUIV( const T a, const U b ) { return ( b - GLH_EPSILON ) < a && a < ( b + GLH_EPSILON ); } (not my code, provided by IRC) and changed all references elsewhere in the codebase from equivalent to GLH_EQUIV & it compiles okay. I'm not familiar with the codebase however so I don't know whether this solution is the 'correct' solution, or whether your NO_DEPRECATED solution might've worked & been a 'cleaner' solution? Regards, CJ Davies On 12/07/12 23:01, Cinder Roxley wrote: > Hi! > > The warnings in your build log relate to the error_code library in the > Boost.System library. They're a side effect of the design decision made > in the library which I will spare you details of (more info on it here: > http://www.boost.org/doc/libs/1_41_0/libs/system/doc/reference.html#Class-error%5Fcategory > ) > > If you aren't using the definitions you're getting the warnings about, > try including the following lines of code before including the header file: > > |#ifndef BOOST_SYSTEM_NO_DEPRECATED > #define BOOST_SYSTEM_NO_DEPRECATED1 > #endif| > > Kind regards, > Cinder Roxley > > On 7/12/2012 5:09 AM, CJ Davies wrote: >> I'm trying to get the viewer to read data from an Arduino via serial >> (long story...). I'm using Boost for this. >> >> So far I have changed the Boost prebuilt in autobuild.xml to this one >> after a conversation with LightDrake on #opensl on freenode; >> >> https://bitbucket.org/LightDrake/public-libs/downloads/boost-1.45.0-linux-20120213.tar.bz2 >> >> then added a boost_thread line to indra/cmake/Boost.cmake & added >> ${BOOST_SYSTEM_LIBRARY} & ${BOOST_THREAD_LIBRARY} to >> indra/newview/CMakeLists.txt. >> >> This allows the .h & .cpp files that implement the serial functionality >> to be added to the build & successfully built, however when I try to >> include one of these header files in llviewerjoystick.h the build fails >> spectacularly. >> >> This is the file that I am trying to #include in llviewerjoystick.h --> >> http://paste2.org/p/2071086 >> >> This is the output of the build -->http://paste2.org/p/2071087 >> >> I assume there isn't actually anything wrong with the code & I'm just >> still missing part of Boost that I need. Can anybody help me identify this? >> >> Regards, >> CJ Davies >> _______________________________________________ >> 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 > From arminweatherwax at lavabit.com Fri Jul 13 07:47:48 2012 From: arminweatherwax at lavabit.com (Armin Weatherwax) Date: Fri, 13 Jul 2012 16:47:48 +0200 Subject: [opensource-dev] Using Boost & the viewer In-Reply-To: <4FFEB07D.9060205@gmail.com> References: <4FFEB07D.9060205@gmail.com> Message-ID: <201207131647.48769.arminweatherwax@lavabit.com> what Cinder said + for avoiding the boost/thread/pthread/condition_variable.hpp:53: warning: unused variable 'res' #include Armin From Lance.Corrimal at eregion.de Fri Jul 13 13:46:55 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Fri, 13 Jul 2012 22:46:55 +0200 Subject: [opensource-dev] havoc licensing and TPV... - TPVD meeting july 13th Message-ID: <11011096.yPryfWeF3z@sai> Hi, I've seen the question float by several times about what it takes to "qualify for sublicensing", but I seem to have missed the answer... So what DOES it take? bye, LC From oz at lindenlab.com Fri Jul 13 15:11:48 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 13 Jul 2012 18:11:48 -0400 Subject: [opensource-dev] havoc licensing and TPV... - TPVD meeting july 13th In-Reply-To: <11011096.yPryfWeF3z@sai> References: <11011096.yPryfWeF3z@sai> Message-ID: <50009D24.1030107@lindenlab.com> On 2012-07-13 16:46 , Lance Corrimal wrote: > Hi, > > I've seen the question float by several times about what it takes to "qualify > for sublicensing", but I seem to have missed the answer... > > So what DOES it take? https://wiki.secondlife.com/wiki/Havok_Viewer_Sublicense#Eligibility From Lance.Corrimal at eregion.de Sat Jul 14 00:43:28 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 14 Jul 2012 09:43:28 +0200 Subject: [opensource-dev] havoc licensing and TPV... - TPVD meeting july 13th In-Reply-To: <50009D24.1030107@lindenlab.com> References: <11011096.yPryfWeF3z@sai> <50009D24.1030107@lindenlab.com> Message-ID: <5485983.GY0sfWBJlW@sai> Am Freitag, 13. Juli 2012, 18:11:48 schrieb Oz Linden: > On 2012-07-13 16:46 , Lance Corrimal wrote: > > Hi, > > > > I've seen the question float by several times about what it takes to > > "qualify for sublicensing", but I seem to have missed the answer... > > > > So what DOES it take? > > https://wiki.secondlife.com/wiki/Havok_Viewer_Sublicense#Eligibility thanks! From Lance.Corrimal at eregion.de Sat Jul 14 00:49:27 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 14 Jul 2012 09:49:27 +0200 Subject: [opensource-dev] Building the viewer with gcc 4.7 Message-ID: <16179117.YumWBKOm3n@sai> Hi, when I'm trying to build the viewer with gcc 4.7 (openSUSE 12.2 just around the corner, comes with 4.7 as the default), I gte tons of errors and warnings, mainly about boost not defining stuff properly. Is there someone already doing something about this, or should I see what I can cook up? bye, LC From carlo at alinoe.com Sat Jul 14 10:00:06 2012 From: carlo at alinoe.com (Ale) Date: Sat, 14 Jul 2012 19:00:06 +0200 Subject: [opensource-dev] Building the viewer with gcc 4.7 In-Reply-To: <16179117.YumWBKOm3n@sai> References: <16179117.YumWBKOm3n@sai> Message-ID: <20120714190006.478f96e6@hikaru.localdomain> On Sat, 14 Jul 2012 09:49:27 +0200 Lance Corrimal wrote: > Hi, > > when I'm trying to build the viewer with gcc 4.7 (openSUSE 12.2 just > around the corner, comes with 4.7 as the default), I gte tons of > errors and warnings, mainly about boost not defining stuff properly. > Is there someone already doing something about this, or should I see > what I can cook up? Singularity compiles with gcc 4.7 since a while... So nice to reinvent the wheel over and over in this "open source" project :/. Can you say "it doesn't work"? I'm pretty pissed about the fact that LL did it AGAIN and in SECRECY behind closed doors (what else) started their project of redoing the HTTP networking code... guess what I've been doing in the past few months? This is sooo not cool. If Linden Lab would run this shit right (Hello Oz), then I'd still be working for them and it wouldn't all be duplicated work that only causes extra work and collisions. Pissed of at LL as usual (and they deserve it), Ale From geenz at exodusviewer.com Mon Jul 16 13:33:35 2012 From: geenz at exodusviewer.com (Geenz Spad) Date: Mon, 16 Jul 2012 16:33:35 -0400 Subject: [opensource-dev] Content Creation Improvement UG - Morph Target Discussion Message-ID: Hello everyone! Recently at the Content Creation Improvement meetings, we've been discussing morph targets and what they would mean for content creators on the grid. Thus far the conversation's focused on how this could benefit clothing designers; e.g., what level of control would this give them, and why it would be beneficial for them to have this feature. Thus far, there hasn't been too much developer feedback on the feature. Siana Gearz has of course posted some possibilities in the comments on http://blog.nalates.net/2012/07/10/the-consensus/, and does have a valid point that there are some technical hurdles that will need to be overcome with whatever approach that is taken. Before I get into what should be discussed, a little definition of what a morph target is: A morph target, also known as a blend shape or shape key in some 3D modeling packages, is something that defines how the surface of an object should "deform" when a value is applied. You could say that the Second Life avatar mesh makes use of morph targets to define the overall shape of an avatar as an example of a morph target. Video games now days tend to use them to define facial animation, and other animated properties that would just be far too difficult to animate using bones. In this context, we're primarily looking at them to define how rigged meshes deform, however, that being said, other general applications being discussed wouldn't be bad either. But please focus on how we can improve clothing design with such a feature as a primary goal, with other applications being a secondary goal. I'm extending the discussion to the open source dev mailing list, in the hopes to get more developer discussion going on the matter. Currently, there are a few things that need to be established through these discussions: ? What can morph targets do that existing tools can't (Qarl's deformer included) ? What problems can they solve that existing tools can't, or otherwise are difficult to solve with existing tools (Qarl's deformer included) ? What can they generally be used for, from various view points ? Ways they can be implemented ? Ways the bandwidth cost can be mitigated for those implementations Just as a note with regards to Qarl's deformer, and where this may eventually go: Qarl's deformer comes first. Thus far, it is the closest solution to making mesh clothing fit better, and it requires very little work on the content creator's behalf outside of modeling around the default "Ruth" shape. As such, morph targets are not intended to be a competitor to the mesh deformer, it's intended moreso to complement what the mesh deformer is capable of doing as a more advanced toolset in the context of clothing. Qarl's deformer has the highest likelihood of being released before the end of the year in a final form, and morph targets may not even be seriously considered by the lab until sometime next year. On top of that, having both would have benefits for content creators; some content creators may not want to learn how to use morph targets and are content with modeling clothing around Ruth, and many may want to learn how to use morph targets "later on" while they focus on more immediate results in the interim with the intention of further customizing how their clothing deforms later. So really, this should be seen as more of an advanced tool for content creators that wish to have further control over the final outcome of the clothing they design. These discussions will be brought up at the CCI meetings over the coming weeks, and it's my hope to see more developers who participate on the list pop in and contribute things to the meetings, or even just sit in and watch the discussion, as I'm sure there's other things being discussed that would be of interest to developers being brought up at the meetings. An additional note is necessary here: these discussions are informal. Because we discuss this, does not mean it will be implemented by the lab. However, we can organize things in such a way to produce a proposal to the lab, and (eventually) prototypes for consideration with LL's permission once a clear vision has been established for the feature, and its associated goals. From there, it'll be up to LL to decide if a feature is worth having, and allotting the resources to make these things possible as needed on their side potentially with open source developers contributing to the final viewer that will make use of these features. The hope is, this will increase the chances of new functionality and other improvements regarding content creation being added to Second Life. You can find the agenda for the meetings, and other information relating to them, here: https://wiki.secondlife.com/w/index.php?title=Content_Creation_Improvement_Informal_User_Group -- Geenz Spad Sent with Sparrow (http://www.sparrowmailapp.com/?sig) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120716/060b9157/attachment.htm From oz at lindenlab.com Tue Jul 17 10:02:06 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 17 Jul 2012 13:02:06 -0400 Subject: [opensource-dev] going to OSCON Message-ID: <50059A8E.7050706@lindenlab.com> Just in case anyone else on this list will be there or nearby... I'm off later today to the O'Reilly Open Source Conference in Portland OR for the rest of this week... If you're there, let me know and we can try to find a way to rendezvous in Real Life! From oz at lindenlab.com Tue Jul 17 12:14:10 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 17 Jul 2012 15:14:10 -0400 Subject: [opensource-dev] Building the viewer with gcc 4.7 In-Reply-To: <20120714190006.478f96e6@hikaru.localdomain> References: <16179117.YumWBKOm3n@sai> <20120714190006.478f96e6@hikaru.localdomain> Message-ID: <5005B982.6000603@lindenlab.com> On 2012-07-14 13:00 , Ale wrote: > I'm pretty pissed about the fact that LL did it AGAIN and in > SECRECY behind closed doors (what else) started their project > of redoing the HTTP networking code... guess what I've been > doing in the past few months? Need I point out that you didn't tell us either? I'd love it if we could just tell everyone all about everything that we might be doing, but that has a lot of drawbacks for us... we end up getting people upset both because we're working on something other than whatever they want and again if a project doesn't produce the results they want. It's something of a no-win situation, I'm afraid. From adaradius at gmail.com Tue Jul 17 13:07:49 2012 From: adaradius at gmail.com (Ada Radius) Date: Tue, 17 Jul 2012 13:07:49 -0700 Subject: [opensource-dev] Content Creation Improvement UG - Morph Target Discussion In-Reply-To: References: Message-ID: <001101cd6457$d90ccec0$8b266c40$@gmail.com> Hi Geenz, I?m not sure my comment belongs precisely in this discussion but I haven?t seen it elsewhere so here goes. I?m not a clothing designer, I design custom avatars for machinima makers lately, mostly nonhuman critters. I just spent a frustrating morning trying to find a viewer that still has Character Meshes and Morphs (an older Phoenix does) ? I need a way to export my highly nonhumanoid shapes out to PhotoShop so that I can texture them and bring them back in to use with either custom or off-the-shelf animations and the default facial expressions (I put them on a custom HUD so the actor/puppeteers can use them). I?ve been working with the SL/opensim avatar sliders, rather than mesh, because what I need are facial expressions, for machinima shots. There?s potentially a lot of commercial applications. So YES, I?m really hoping to see tools. Ada Radius From: Geenz Spad [mailto:geenz at exodusviewer.com] Sent: Monday, July 16, 2012 1:34 PM To: opensource-dev at lists.secondlife.com Subject: [opensource-dev] Content Creation Improvement UG - Morph Target Discussion Hello everyone! Recently at the Content Creation Improvement meetings, we've been discussing morph targets and what they would mean for content creators on the grid. Thus far the conversation's focused on how this could benefit clothing designers; e.g., what level of control would this give them, and why it would be beneficial for them to have this feature. Thus far, there hasn't been too much developer feedback on the feature. Siana Gearz has of course posted some possibilities in the comments on http://blog.nalates.net/2012/07/10/the-consensus/, and does have a valid point that there are some technical hurdles that will need to be overcome with whatever approach that is taken. Before I get into what should be discussed, a little definition of what a morph target is: A morph target, also known as a blend shape or shape key in some 3D modeling packages, is something that defines how the surface of an object should "deform" when a value is applied. You could say that the Second Life avatar mesh makes use of morph targets to define the overall shape of an avatar as an example of a morph target. Video games now days tend to use them to define facial animation, and other animated properties that would just be far too difficult to animate using bones. In this context, we're primarily looking at them to define how rigged meshes deform, however, that being said, other general applications being discussed wouldn't be bad either. But please focus on how we can improve clothing design with such a feature as a primary goal, with other applications being a secondary goal. I'm extending the discussion to the open source dev mailing list, in the hopes to get more developer discussion going on the matter. Currently, there are a few things that need to be established through these discussions: ? What can morph targets do that existing tools can't (Qarl's deformer included) ? What problems can they solve that existing tools can't, or otherwise are difficult to solve with existing tools (Qarl's deformer included) ? What can they generally be used for, from various view points ? Ways they can be implemented ? Ways the bandwidth cost can be mitigated for those implementations Just as a note with regards to Qarl's deformer, and where this may eventually go: Qarl's deformer comes first. Thus far, it is the closest solution to making mesh clothing fit better, and it requires very little work on the content creator's behalf outside of modeling around the default "Ruth" shape. As such, morph targets are not intended to be a competitor to the mesh deformer, it's intended moreso to complement what the mesh deformer is capable of doing as a more advanced toolset in the context of clothing. Qarl's deformer has the highest likelihood of being released before the end of the year in a final form, and morph targets may not even be seriously considered by the lab until sometime next year. On top of that, having both would have benefits for content creators; some content creators may not want to learn how to use morph targets and are content with modeling clothing around Ruth, and many may want to learn how to use morph targets "later on" while they focus on more immediate results in the interim with the intention of further customizing how their clothing deforms later. So really, this should be seen as more of an advanced tool for content creators that wish to have further control over the final outcome of the clothing they design. These discussions will be brought up at the CCI meetings over the coming weeks, and it's my hope to see more developers who participate on the list pop in and contribute things to the meetings, or even just sit in and watch the discussion, as I'm sure there's other things being discussed that would be of interest to developers being brought up at the meetings. An additional note is necessary here: these discussions are informal. Because we discuss this, does not mean it will be implemented by the lab. However, we can organize things in such a way to produce a proposal to the lab, and (eventually) prototypes for consideration with LL's permission once a clear vision has been established for the feature, and its associated goals. From there, it'll be up to LL to decide if a feature is worth having, and allotting the resources to make these things possible as needed on their side potentially with open source developers contributing to the final viewer that will make use of these features. The hope is, this will increase the chances of new functionality and other improvements regarding content creation being added to Second Life. You can find the agenda for the meetings, and other information relating to them, here: https://wiki.secondlife.com/w/index.php?title=Content_Creation_Improvement_Informal_User_Group -- Geenz Spad Sent with Sparrow -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120717/d406887d/attachment-0001.htm From richard at lindenlab.com Thu Jul 19 16:55:58 2012 From: richard at lindenlab.com (Richard Nelson) Date: Thu, 19 Jul 2012 23:55:58 -0000 Subject: [opensource-dev] Review Request: STORM-1899: Avatar hand poses randomly get stuck in spread position In-Reply-To: <20120719211141.22065.48282@domU-12-31-38-00-90-68.compute-1.internal> References: <20120719211141.22065.48282@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120719235558.21730.67768@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/592/#review1238 ----------------------------------------------------------- indra/llcharacter/llhandmotion.cpp you probably don't want to write to this memory if you are getting bad values. Best to warn and then do nothing. - Richard Nelson On July 19, 2012, 2:11 p.m., Ansariel Hiller wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/592/ > ----------------------------------------------------------- > > (Updated July 19, 2012, 2:11 p.m.) > > > Review request for Viewer. > > > Description > ------- > > A proposed solution for STORM-1899 and the issue, where the handpose of avatars randomly get stuck in the spread hand position. > > In the current implementation, this case might happen under the following circumstances: > * Avatar uses an animation with hand pose A > * A request is issued to change hand pose to B > * Before the viewer has blended pose A over to pose B, the original pose A is requested again > * In this case, the hand pose will not be properly (re)set and because mNewPose == mCurrentPose, there will be no further blending, leaving the hand in it's current pose > > The patch will properly reset the hand pose in this case and update the visual parameters of the avatar. > > > This addresses bug STORM-1899. > https://jira.secondlife.com/browse/STORM-1899 > > > Diffs > ----- > > indra/llcharacter/llhandmotion.cpp 4d9106153407 > > Diff: http://codereview.secondlife.com/r/592/diff/diff > > > Testing > ------- > > > Thanks, > > Ansariel Hiller > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120719/e6fe43e0/attachment.htm From geenz at geenzo.com Mon Jul 23 14:10:16 2012 From: geenz at geenzo.com (Geenz Spad) Date: Mon, 23 Jul 2012 21:10:16 -0000 Subject: [opensource-dev] Review Request: As Gatekeeper, I like binaries downloaded through a web browser to be signed Message-ID: <20120723211016.29379.13167@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/593/ ----------------------------------------------------------- Review request for Viewer. Description ------- OS X 10.8 brings with it a new feature named "Gatekeeper" that checks downloaded applications obtained through popular web browsers for an Apple issued Developer ID certificate. If an application was not signed with one of these certificates, then Gatekeeper will prevent its execution. Test plan is on the JIRA. This addresses bug STORM-1900. https://jira.secondlife.com/browse/STORM-1900 Diffs ----- doc/contributions.txt 4d9106153407f9228f426091f3e84061dbd837ed indra/cmake/Variables.cmake 4d9106153407f9228f426091f3e84061dbd837ed indra/lib/python/indra/util/llmanifest.py 4d9106153407f9228f426091f3e84061dbd837ed indra/newview/CMakeLists.txt 4d9106153407f9228f426091f3e84061dbd837ed indra/newview/viewer_manifest.py 4d9106153407f9228f426091f3e84061dbd837ed Diff: http://codereview.secondlife.com/r/593/diff/diff Testing ------- I've already tested to ensure that the viewer builds with these changes in place, and the resulting .app package executes without problems on OS X 10.8 when downloaded through Safari. Thanks, Geenz Spad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120723/0768668e/attachment.htm From oz at lindenlab.com Thu Jul 26 07:13:05 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 26 Jul 2012 10:13:05 -0400 Subject: [opensource-dev] pathfinding is now in viewer-development Message-ID: <50115071.6020103@lindenlab.com> The pathfinding branch has been merged to viewer-development. With this change, the old llconvexdecomposition library has been folded into the llphysicsextensions library, which is unfortunately for the time being closed source. Actually, I believe that the convex decomposition stuff didn't change, but other things were added that at present we can't publish, and it was all too entangled. In any event, there is now a stub package for llphysicsextensions - I believe that this builds cleanly, leaving just a few features inoperative. One late change that I added was three new interfaces in the llphysicsextensions API to explicitly detect whether or not you have linked with the stub (all are static): bool LLConvexDecomposition::isFunctional() bool LLPathingLib::isFunctional() bool LLPhysicsExtensions::isFunctional() I have not added calls to these anywhere yet, but the intent is that they are easy ways to do things like disable UI elements that won't work with the stub. Suggestions for places to use them are most welcome. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120726/a2805d28/attachment.htm From oz at lindenlab.com Thu Jul 26 07:14:48 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Thu, 26 Jul 2012 10:14:48 -0400 Subject: [opensource-dev] pathfinding is now in viewer-development In-Reply-To: <50115071.6020103@lindenlab.com> References: <50115071.6020103@lindenlab.com> Message-ID: <501150D8.70405@lindenlab.com> On 2012-07-26 10:13 , Oz Linden (Scott Lawrence) wrote: > The pathfinding branch has been merged to viewer-development. (I'm having a small problem getting a Development viewer built - it should build fine for you, the problem is entirely with how we create the download pages. I hope to have that sorted out later today) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120726/97f8e56d/attachment.htm From CronoCloud at mchsi.com Thu Jul 26 09:52:51 2012 From: CronoCloud at mchsi.com (Ron Rogers Jr.) Date: Thu, 26 Jul 2012 11:52:51 -0500 Subject: [opensource-dev] Nasty scrolling bug in inventory search in 3.4.0 262607 Message-ID: <20120726115251.6ecaf6fb.CronoCloud@mchsi.com> https://jira.secondlife.com/browse/VWR-29358 Prevents effective use of inventory search, because it scrolls back up to the top of the results, nasty! CronoCloud -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120726/6a78bb70/attachment.pgp From richard at lindenlab.com Thu Jul 26 16:27:57 2012 From: richard at lindenlab.com (Richard Nelson) Date: Thu, 26 Jul 2012 23:27:57 -0000 Subject: [opensource-dev] Review Request: STORM-1899: Avatar hand poses randomly get stuck in spread position In-Reply-To: <20120725221209.29382.48698@domU-12-31-38-00-90-68.compute-1.internal> References: <20120725221209.29382.48698@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120726232757.29579.85579@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/592/#review1240 ----------------------------------------------------------- Ship it! Ship It! - Richard Nelson On July 25, 2012, 3:12 p.m., Ansariel Hiller wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/592/ > ----------------------------------------------------------- > > (Updated July 25, 2012, 3:12 p.m.) > > > Review request for Viewer. > > > Description > ------- > > A proposed solution for STORM-1899 and the issue, where the handpose of avatars randomly get stuck in the spread hand position. > > In the current implementation, this case might happen under the following circumstances: > * Avatar uses an animation with hand pose A > * A request is issued to change hand pose to B > * Before the viewer has blended pose A over to pose B, the original pose A is requested again > * In this case, the hand pose will not be properly (re)set and because mNewPose == mCurrentPose, there will be no further blending, leaving the hand in it's current pose > > The patch will properly reset the hand pose in this case and update the visual parameters of the avatar. > > > This addresses bug STORM-1899. > https://jira.secondlife.com/browse/STORM-1899 > > > Diffs > ----- > > indra/llcharacter/llhandmotion.cpp 4d9106153407 > > Diff: http://codereview.secondlife.com/r/592/diff/diff > > > Testing > ------- > > > Thanks, > > Ansariel Hiller > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120726/e844e95d/attachment.htm From moriz.gupte at gmail.com Thu Jul 26 19:35:15 2012 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 26 Jul 2012 22:35:15 -0400 Subject: [opensource-dev] A rather uniquely unexpected behavior from Second Life's official viewer Message-ID: Hello, I am wondering what could be causing objects to disappear in the latest Second Life viewer 3.3.4.26 See picture of the same scene (1) in the SL official viewer, and (2) in FireStorm [image: Inline image 1] I am wondering why the SL viewer is not rendering objects? This is one strange behavior .... When I log back in, I can see all them again, regardless of whether I clear cache or not. Any clues what could be wrong. This is a show stopper for me because now am not sure what users will be seeing or not. R -- 'Consider how the lilies grow. They do not labor or spin.' *Rameshsharma Ramloll* PhD, *Research Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: 208-282-5333 Blog , LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120726/2a43ff7d/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 113592 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120726/2a43ff7d/attachment-0001.jpeg From oz at lindenlab.com Fri Jul 27 10:46:22 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Fri, 27 Jul 2012 13:46:22 -0400 Subject: [opensource-dev] New HTTP Library & Project Viewer Message-ID: <5012D3EE.7060309@lindenlab.com> The start of a unified approach to HTTP-based communications between the viewer and grid services with a goal of achieving reliability, consistency and a better overall experience on the grid. Project Viewer for testing is here: http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#HTTP Especially if you have had problems when you enable the use of HTTP, we would very much appreciate your giving this a try. We know that it does not yet solve all the problems, but we think that it solves some and provides the first steps needed for solving some more in the future. From holydoughnuts at gmail.com Fri Jul 27 13:59:18 2012 From: holydoughnuts at gmail.com (holydoughnuts) Date: Fri, 27 Jul 2012 16:59:18 -0400 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <5012D3EE.7060309@lindenlab.com> References: <5012D3EE.7060309@lindenlab.com> Message-ID: <50130126.7010007@gmail.com> On 7/27/2012 1:46 PM, Oz Linden (Scott Lawrence) wrote: > Project Viewer for testing is here: > > http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#HTTP > > Especially if you have had problems when you enable the use of HTTP, we > would very much appreciate your giving this a try. We know that it does > not yet solve all the problems, but we think that it solves some and > provides the first steps needed for solving some more in the future. I threw this at a pretty modest CPU, an Athlon II 170u single core dealie, and the difference there was pretty substantial. Under Linux, HTTP texture loads went from slightly sluggish, to feeling about the same as with them switched off. On Windows 7, the difference was much more dramatic. Mainstream viewers have been painful and jerky for a long time on that machine even with HTTP textures off. This viewer is running firmly on the "I can live with this" side, even with HTTP textures enabled. Flying around in some heavily built areas was even tolerable. From Lance.Corrimal at eregion.de Sat Jul 28 02:15:59 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sat, 28 Jul 2012 09:15:59 -0000 Subject: [opensource-dev] Review Request: STORM-1899: Avatar hand poses randomly get stuck in spread position In-Reply-To: <20120725221209.29382.48698@domU-12-31-38-00-90-68.compute-1.internal> References: <20120725221209.29382.48698@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120728091559.29379.84048@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/592/#review1241 ----------------------------------------------------------- I think the warning message should either go, or be modified to warn only once, or be changed to lldebug... the way it is now it floods the logfiles... i have 1900 repeats of that warning line in my log file, after being logged in for less than 5 minutes! - Lance Corrimal On July 25, 2012, 3:12 p.m., Ansariel Hiller wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/592/ > ----------------------------------------------------------- > > (Updated July 25, 2012, 3:12 p.m.) > > > Review request for Viewer. > > > Description > ------- > > A proposed solution for STORM-1899 and the issue, where the handpose of avatars randomly get stuck in the spread hand position. > > In the current implementation, this case might happen under the following circumstances: > * Avatar uses an animation with hand pose A > * A request is issued to change hand pose to B > * Before the viewer has blended pose A over to pose B, the original pose A is requested again > * In this case, the hand pose will not be properly (re)set and because mNewPose == mCurrentPose, there will be no further blending, leaving the hand in it's current pose > > The patch will properly reset the hand pose in this case and update the visual parameters of the avatar. > > > This addresses bug STORM-1899. > https://jira.secondlife.com/browse/STORM-1899 > > > Diffs > ----- > > indra/llcharacter/llhandmotion.cpp 4d9106153407 > > Diff: http://codereview.secondlife.com/r/592/diff/diff > > > Testing > ------- > > > Thanks, > > Ansariel Hiller > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120728/a7869438/attachment.htm From carlo at alinoe.com Sat Jul 28 20:23:15 2012 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 29 Jul 2012 05:23:15 +0200 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <50130126.7010007@gmail.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> Message-ID: <20120729052315.0a2b805b@hikaru.localdomain> On Fri, 27 Jul 2012 16:59:18 -0400 holydoughnuts wrote: > On 7/27/2012 1:46 PM, Oz Linden (Scott Lawrence) wrote: > > Project Viewer for testing is here: > > > > http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#HTTP > > > > Especially if you have had problems when you enable the use of > > HTTP, we would very much appreciate your giving this a try. We > > know that it does not yet solve all the problems, but we think that > > it solves some and provides the first steps needed for solving some > > more in the future. > I threw this at a pretty modest CPU, an Athlon II 170u single core > dealie, and the difference there was pretty substantial. Under Linux, > HTTP texture loads went from slightly sluggish, to feeling about the > same as with them switched off. > > On Windows 7, the difference was much more dramatic. Mainstream > viewers have been painful and jerky for a long time on that machine > even with HTTP textures off. This viewer is running firmly on the "I > can live with this" side, even with HTTP textures enabled. Flying > around in some heavily built areas was even tolerable. The implementation that I wrote for Singularity (not yet in the the official release) is more on the side of "blazing fast" :p. The bottleneck is entirely server-side, but I've seen download speeds of 1 MB/s non-stop till all textures were there. This code should be in the next release in about a week. I'm currently working on implementing upcoming support for connection reuse by the servers (although that will still take a long time before they will start to support that, I understood). I'd like to opt that this code will be an alternative for third party viewers, and might very well turn out to be more robust ;) -- Carlo Wood From sldev at free.fr Sun Jul 29 01:07:18 2012 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 29 Jul 2012 10:07:18 +0200 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <20120729052315.0a2b805b@hikaru.localdomain> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> Message-ID: <20120729100718.fad247e2.sldev@free.fr> On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote: > On Fri, 27 Jul 2012 16:59:18 -0400 > holydoughnuts wrote: > > The implementation that I wrote for Singularity (not yet in the > the official release) is more on the side of "blazing fast" :p. > The bottleneck is entirely server-side, but I've seen download > speeds of 1 MB/s non-stop till all textures were there. With just a few tweakings to the texture fetcher (and in particular a setting that permits up to 32 concurrent HTTP fetches), I get much more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the 10MB/s+ range while rezzing in heavily textured areas and the rezzing time is pretty low... This has been so for many months (well over a year actually) already. Henri. From Lance.Corrimal at eregion.de Sun Jul 29 01:24:23 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 29 Jul 2012 08:24:23 -0000 Subject: [opensource-dev] Review Request: STORM-1899: Avatar hand poses randomly get stuck in spread position In-Reply-To: <20120728091559.29379.84048@domU-12-31-38-00-90-68.compute-1.internal> References: <20120728091559.29379.84048@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120729082423.4289.64751@domU-12-31-38-00-90-68.compute-1.internal> > On July 28, 2012, 2:15 a.m., Lance Corrimal wrote: > > I think the warning message should either go, or be modified to warn only once, or be changed to lldebug... the way it is now it floods the logfiles... i have 1900 repeats of that warning line in my log file, after being logged in for less than 5 minutes! on second thought, this flooding might be because I screwed up my test build... ... yep, that was it. - Lance ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/592/#review1241 ----------------------------------------------------------- On July 25, 2012, 3:12 p.m., Ansariel Hiller wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/592/ > ----------------------------------------------------------- > > (Updated July 25, 2012, 3:12 p.m.) > > > Review request for Viewer. > > > Description > ------- > > A proposed solution for STORM-1899 and the issue, where the handpose of avatars randomly get stuck in the spread hand position. > > In the current implementation, this case might happen under the following circumstances: > * Avatar uses an animation with hand pose A > * A request is issued to change hand pose to B > * Before the viewer has blended pose A over to pose B, the original pose A is requested again > * In this case, the hand pose will not be properly (re)set and because mNewPose == mCurrentPose, there will be no further blending, leaving the hand in it's current pose > > The patch will properly reset the hand pose in this case and update the visual parameters of the avatar. > > > This addresses bug STORM-1899. > https://jira.secondlife.com/browse/STORM-1899 > > > Diffs > ----- > > indra/llcharacter/llhandmotion.cpp 4d9106153407 > > Diff: http://codereview.secondlife.com/r/592/diff/diff > > > Testing > ------- > > > Thanks, > > Ansariel Hiller > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120729/eb58134b/attachment.htm From Lance.Corrimal at eregion.de Sun Jul 29 01:24:30 2012 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Sun, 29 Jul 2012 08:24:30 -0000 Subject: [opensource-dev] Review Request: STORM-1899: Avatar hand poses randomly get stuck in spread position In-Reply-To: <20120725221209.29382.48698@domU-12-31-38-00-90-68.compute-1.internal> References: <20120725221209.29382.48698@domU-12-31-38-00-90-68.compute-1.internal> Message-ID: <20120729082430.4284.84505@domU-12-31-38-00-90-68.compute-1.internal> ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/592/#review1243 ----------------------------------------------------------- Ship it! Ship It! - Lance Corrimal On July 25, 2012, 3:12 p.m., Ansariel Hiller wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/592/ > ----------------------------------------------------------- > > (Updated July 25, 2012, 3:12 p.m.) > > > Review request for Viewer. > > > Description > ------- > > A proposed solution for STORM-1899 and the issue, where the handpose of avatars randomly get stuck in the spread hand position. > > In the current implementation, this case might happen under the following circumstances: > * Avatar uses an animation with hand pose A > * A request is issued to change hand pose to B > * Before the viewer has blended pose A over to pose B, the original pose A is requested again > * In this case, the hand pose will not be properly (re)set and because mNewPose == mCurrentPose, there will be no further blending, leaving the hand in it's current pose > > The patch will properly reset the hand pose in this case and update the visual parameters of the avatar. > > > This addresses bug STORM-1899. > https://jira.secondlife.com/browse/STORM-1899 > > > Diffs > ----- > > indra/llcharacter/llhandmotion.cpp 4d9106153407 > > Diff: http://codereview.secondlife.com/r/592/diff/diff > > > Testing > ------- > > > Thanks, > > Ansariel Hiller > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120729/cb004551/attachment.htm From sldev at free.fr Sun Jul 29 01:40:02 2012 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 29 Jul 2012 10:40:02 +0200 Subject: [opensource-dev] Compilation issues under MSVC2010: Windows guru help *badly* needed ! Message-ID: <20120729104002.ee87266c.sldev@free.fr> Greetings, folks ! I just ran into a problem that lets me quite clueless: I recently migrated the Cool VL Viewer build system from VS2005 to VS2010 and succeeded, two weeks ago, to compile v1.26.5.0 under VS2010. This week, I was about to make two new releases (v1.26.4.23 which is basically the same as v1.26.5.0 with just a few things added) and v1.26.5.1 which is the firts release with the v3.3.4 renderer backported (working just fine under Linux). But then I came around an issue dealing with Windows headers inclusion that I just can't figure out. When compiling (either v1.26.4.23 or v1.26.5.1), VS2010 fails for the llwindow library, with the following error (sources path edited to linden\ for clarity): llwindow.cpp linden\indra\llwindow\llwindowwin32.h(45): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(45): error C2143: syntax error : missing ',' before '&' linden\indra\llwindow\llwindowwin32.h(146): error C2061: syntax error : identifier 'COMPOSITIONFORM' linden\indra\llwindow\llwindowwin32.h(147): error C2061: syntax error : identifier 'CANDIDATEFORM' linden\indra\llwindow\llwindowwin32.h(148): error C2061: syntax error : identifier 'IMECHARPOSITION' linden\indra\llwindow\llwindowwin32.h(150): error C2061: syntax error : identifier 'RECONVERTSTRING' linden\indra\llwindow\llwindowwin32.h(177): error C2146: syntax error : missing ';' before identifier 'mWndProc' linden\indra\llwindow\llwindowwin32.h(177): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(177): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(237): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(237): error C2143: syntax error : missing ',' before '&' COMPOSITIONFORM & Co pertain to Imm.h and the errors around lines 45 and 177+ are related to undefined MSG and WNDPROC types (that seem ro pertain to WinUser.h). The weird thing is that I didn't change a single thing in v1.4.26.23 in llwindows/, neither in the cmake files when compared to v1.26.5.0 that (still) compiles just fine !!! I checked the Windows headers inclusion and they seem just fine, with, in llwindowwin32.h: ------------ #ifndef LL_LLWINDOWWIN32_H #define LL_LLWINDOWWIN32_H // Limit Windows API to small and manageable set. #define WIN32_LEAN_AND_MEAN #include #include .../... ------------ Adding #include after #include in llwindowwin32.h allows to get rid of the undefined COMPOSITIONFORM ... RECONVERTSTRING types, but adding #include doesn't solve the issue with MSG and WNDPROC not being defined, even if I use: ------------ #ifndef LL_LLWINDOWWIN32_H #define LL_LLWINDOWWIN32_H // Limit Windows API to small and manageable set. #define WIN32_LEAN_AND_MEAN #include #include #include #undef NOUSER #undef NOMSG #undef _WINUSER_ #include ------------ I always get: llwindow.cpp linden\indra\llwindow\llwindowwin32.h(50): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(50): error C2143: syntax error : missing ',' before '&' linden\indra\llwindow\llwindowwin32.h(182): error C2146: syntax error : missing ';' before identifier 'mWndProc' linden\indra\llwindow\llwindowwin32.h(182): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(182): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(242): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int linden\indra\llwindow\llwindowwin32.h(242): error C2143: syntax error : missing ',' before '&' What is totally flabbergasting is that between v1.26.5.0 (which compiles fine) and v1.26.4.23, the diff is only 300Kb and NOTHING in it touches the cmake files neither the llwindow/ files !!! Plus, llwindowwin32.cpp (which also needs and includes llwindowwin32.h) compiles just fine, unlike llwindow.cpp (and yes, I also tried to add the same Windows includes in the latter than in the former, to no avail). Finally, I tried on two different build systems (a WinXP SP3 virtual machine and a genuine (non emulated) Windows 7 Ultimate system), to no avail (not a build system issue, apparenetly, especially since v1.26.5.0 still compiles just fine). Any clue of what is going wrong with this sh*tty VS2010 ? Many thanks in advance ! Henri. From sldev at free.fr Sun Jul 29 06:11:28 2012 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 29 Jul 2012 15:11:28 +0200 Subject: [opensource-dev] [SOLVED] Re: Compilation issues under MSVC2010: Windows guru help *badly* needed ! In-Reply-To: <20120729104002.ee87266c.sldev@free.fr> References: <20120729104002.ee87266c.sldev@free.fr> Message-ID: <20120729151128.27992e9d.sldev@free.fr> Problem solved !... Man, what a sh*tty, Mickey Mouse OS Windoze (or "Windaube", in French, for puns amateurs) can be !!!!... Its UTTER stupidity and hackiness NEVER cease to amaze me ! The reasons for all my troubles were that: - windows.h contains a "#pragam once" directive (instead of standard, robust and flawless #ifndef _HEADER_NAME_ / #define _HEADER_NAME_ / ... header here ... / #endif guards), which means that the pre-processor will *never* even *try* to include twice that header in nested header invocations. - Somehow (but I didn't yet figured out it all: to be frank, at this point I don't really care any more...), #define WIN32_LEAN_AND_MEAN leads the pre-processor to only include the sub-headers (included from windows.h) that contain definitions used in the file calling the "#include " (and beacuse of the #pragma once, if another, nested file includes this file and contains other definitions requiring sub-headers that have been skipped the first time, it is f*cked up !). - In v1.26.4.23 and v1.26.5.1 I added support for private memory pools, but in a more complete way than in LL's viewer (i.e. proper memory usage functions where added for Linux and MacOS-X in llsys.cpp to be used by the private pools manager in llmemory.cpp), and this lead me to add an '#include "sys.h"' into llmemory.h. And... llsys.h itself already contains an #include ... - In llwindow.cpp, the headers where included as follow: #include "linden_common.h" #include "llwindowheadless.h" #if LL_MESA_HEADLESS #include "llwindowmesaheadless.h" #elif LL_SDL #include "llwindowsdl.h" #elif LL_WINDOWS #include "llwindowwin32.h" <-- With the problem arising here #elif LL_DARWIN #include "llwindowmacosx.h" #endif ...and it comes out that llwindowheadless.h was itself including llmemory.h, which was including (due to my modifications) sys.h, which was including windows.h. Then when llwindowwin32.h was trying to include windows.h in its turn (or winuser.h, after I tried adding it to solve the issue), it failed because of the combined effect of #pragma once and #define WIN32_LEAN_AND_MEAN. The solution was to reorder the includes in llwindow.cpp to read: #include "linden_common.h" #if LL_MESA_HEADLESS #include "llwindowmesaheadless.h" #elif LL_SDL #include "llwindowsdl.h" #elif LL_WINDOWS #include "llwindowwin32.h" #elif LL_DARWIN #include "llwindowmacosx.h" #endif // SHITTY MSVC INCLUDE ISSUES WARNING: // include llwindowheadless.h* AFTER* llwindowwin32.h, else bad // things happen at compilation time ! #include "llwindowheadless.h" Note that I'm still lucky that llwindowheadless.h doesn't need definitions from sub-includes of windows.h that are skipped by the latter when it is included by llwindowwin32.h (if you still can follow all the indirections in this reasonning, lol !)... To prevent such issues in the future, I suggest that the viewer sources are ammended so that #include is *NEVER* done from header files, but only from the *.cpp files using headers files that require windows.h's inclusion; this may lead to have to manually add a few includes (windows.h sub-includes) in the *.cpp files (that might be skipped by windows.h because of the #define WIN32_LEAN_AND_MEAN if some definitions are used in the *.h file and not in the *.cpp file), but at least those includes won't be impacted in case of nesting by the "#pragma once" that hit me hard here, since even: #undef NOUSER #undef NOMSG #undef _WINUSER_ #include could not get past it and prevented the needed winuser.h definitions to be included at all !... I can't provide a patch, since LL won't use it (not having given up my privacy to fill up their stupid "contribution agreement" form and stuff...), but you may consider this info as LGPL (or anything fancying you) and produce the patch yourself. Henri. ------------ On Sun, 29 Jul 2012 10:40:02 +0200, I wrote: > Greetings, folks ! > > I just ran into a problem that lets me quite clueless: I recently migrated > the Cool VL Viewer build system from VS2005 to VS2010 and succeeded, two > weeks ago, to compile v1.26.5.0 under VS2010. > > This week, I was about to make two new releases (v1.26.4.23 which is basically > the same as v1.26.5.0 with just a few things added) and v1.26.5.1 which is the > firts release with the v3.3.4 renderer backported (working just fine under > Linux). > > But then I came around an issue dealing with Windows headers inclusion that > I just can't figure out. When compiling (either v1.26.4.23 or v1.26.5.1), > VS2010 fails for the llwindow library, with the following error (sources > path edited to linden\ for clarity): > > llwindow.cpp > linden\indra\llwindow\llwindowwin32.h(45): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(45): error C2143: syntax error : missing ',' before '&' > linden\indra\llwindow\llwindowwin32.h(146): error C2061: syntax error : identifier 'COMPOSITIONFORM' > linden\indra\llwindow\llwindowwin32.h(147): error C2061: syntax error : identifier 'CANDIDATEFORM' > linden\indra\llwindow\llwindowwin32.h(148): error C2061: syntax error : identifier 'IMECHARPOSITION' > linden\indra\llwindow\llwindowwin32.h(150): error C2061: syntax error : identifier 'RECONVERTSTRING' > linden\indra\llwindow\llwindowwin32.h(177): error C2146: syntax error : missing ';' before identifier 'mWndProc' > linden\indra\llwindow\llwindowwin32.h(177): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(177): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(237): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(237): error C2143: syntax error : missing ',' before '&' > > COMPOSITIONFORM & Co pertain to Imm.h and the errors around lines 45 and 177+ > are related to undefined MSG and WNDPROC types (that seem ro pertain to > WinUser.h). > > The weird thing is that I didn't change a single thing in v1.4.26.23 in > llwindows/, neither in the cmake files when compared to v1.26.5.0 that > (still) compiles just fine !!! > > I checked the Windows headers inclusion and they seem just fine, with, > in llwindowwin32.h: > > ------------ > #ifndef LL_LLWINDOWWIN32_H > #define LL_LLWINDOWWIN32_H > > // Limit Windows API to small and manageable set. > #define WIN32_LEAN_AND_MEAN > #include > #include > > .../... > ------------ > > Adding #include after #include in llwindowwin32.h > allows to get rid of the undefined COMPOSITIONFORM ... RECONVERTSTRING > types, but adding #include doesn't solve the issue with > MSG and WNDPROC not being defined, even if I use: > > ------------ > #ifndef LL_LLWINDOWWIN32_H > #define LL_LLWINDOWWIN32_H > > // Limit Windows API to small and manageable set. > #define WIN32_LEAN_AND_MEAN > #include > #include > #include > #undef NOUSER > #undef NOMSG > #undef _WINUSER_ > #include > ------------ > > I always get: > > llwindow.cpp > linden\indra\llwindow\llwindowwin32.h(50): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(50): error C2143: syntax error : missing ',' before '&' > linden\indra\llwindow\llwindowwin32.h(182): error C2146: syntax error : missing ';' before identifier 'mWndProc' > linden\indra\llwindow\llwindowwin32.h(182): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(182): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(242): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int > linden\indra\llwindow\llwindowwin32.h(242): error C2143: syntax error : missing ',' before '&' > > What is totally flabbergasting is that between v1.26.5.0 (which compiles > fine) and v1.26.4.23, the diff is only 300Kb and NOTHING in it touches > the cmake files neither the llwindow/ files !!! > Plus, llwindowwin32.cpp (which also needs and includes llwindowwin32.h) > compiles just fine, unlike llwindow.cpp (and yes, I also tried to add > the same Windows includes in the latter than in the former, to no avail). > > Finally, I tried on two different build systems (a WinXP SP3 virtual > machine and a genuine (non emulated) Windows 7 Ultimate system), to no > avail (not a build system issue, apparenetly, especially since v1.26.5.0 > still compiles just fine). > > Any clue of what is going wrong with this sh*tty VS2010 ? > > Many thanks in advance ! > > Henri. > From carlo at alinoe.com Sun Jul 29 06:59:38 2012 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 29 Jul 2012 15:59:38 +0200 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <20120729100718.fad247e2.sldev@free.fr> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> Message-ID: <20120729155938.1587c348@hikaru.localdomain> On Sun, 29 Jul 2012 10:07:18 +0200 Henri Beauchamp wrote: > On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote: > > > On Fri, 27 Jul 2012 16:59:18 -0400 > > holydoughnuts wrote: > > > > The implementation that I wrote for Singularity (not yet in the > > the official release) is more on the side of "blazing fast" :p. > > The bottleneck is entirely server-side, but I've seen download > > speeds of 1 MB/s non-stop till all textures were there. > > With just a few tweakings to the texture fetcher (and in particular > a setting that permits up to 32 concurrent HTTP fetches), I get much > more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the > 10MB/s+ range while rezzing in heavily textured areas and the rezzing > time is pretty low... This has been so for many months (well over > a year actually) already. I agree that that would be an advantage for the user; but it's not clear to me if it is allowed (or will be in the near future) to have 32 concurrent fetches. The rationale that it SHOULD be allowed is that the user will download those textures anyway; so, you might as well allow them to get it quickly, in a short time: this has no influence on the average number of open file descriptors on the server. I understand that LL is afraid that once viewers can keep sockets open (for reuse) that the servers run out of filedescriptors. Of course, this is all to true. Therefore I propose to set a limit on the maximum number of UNUSED filedescriptors. However, there should be no limit or a much higher limit, on the number of connections that are actually in use. The question is then: when is a filedescriptor "unused"? Well, I'd say that for the sake of re-use, it can be considered unused if there hasn't been a new request for it for -say- a second. It's probably best to define multiple stages, that is: * Allow a maximum of 32 connections. * Allow up to 32 connections that are unused for 1 second. * Allow up to 8 connections that are unused for 10 seconds. * Allow up to 2 connections that are unused for 1 minute. * Allow 1 connection to be unused for 20 minutes (or whenever one leaves a region and it can be determined that this server won't be needed or used anymore). Of course this means that upon teleport to a new region with many unknown textures, the viewer will make 32 new SSH connections, but that is MUCH less than one new connection PER TEXTURE, as we have now. Then all those connections are reused until all textures have been downloaded (a few seconds). Other strategies are possible, like NOT immediately creating a new connection as long as the maximum of 32 connections haven't been used up yet, but waiting with that until there's a queue of requests building up. Bottom line is, I'm afraid that Linden Lab is going to take the (too) simplistic route as they often have done in the past, and do something very silly like: * Allow a maximum of 2 connections, and allow to keep them open indefinitely. I hope you see the difference :p I argue that something like that makes no sense and would hurt the user because they'd have to wait unnecessary long before everything downloads. -- Carlo Wood From sldev at free.fr Sun Jul 29 07:23:21 2012 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 29 Jul 2012 16:23:21 +0200 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <20120729155938.1587c348@hikaru.localdomain> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <20120729155938.1587c348@hikaru.localdomain> Message-ID: <20120729162321.c8a9bbc9.sldev@free.fr> I would agree with you if all decent HTTP servers (Apache, but not only), didn't have their own throttling algorithms are weren't able to just drop the excess of connections when they run out of sockets. But they do have such throttling mechanisms, so it's no issue at all and in fact, 32 is the max number of connection per IP an Apache server would accept by default (the admin can of course change this setting: it's not uncommon to encounter websites configured for up to 64 connections per IP). FYI, early HTTP fetches code was allowing up to 32 connections already, then it was lowered to 8, then raised back up to 16, and I since lost track of what maximum is currently hardcoded in LL's viewer... That's why I made it a configurable setting: if you start seeing timeouts or "busy" replies from the server in your viewer log, then you can still lower the setting. The default in the Cool VL Viewer is 16, but I have always used 32 myself and never came accross any issue, including in over-crowded sims (and I can enjoy a very fast rezzing experience): of course, you could argue that this is because everyone else in the sim is limited to 8 connections... And you could be right (hard to say: only LL could...). As for keeping only two persistent connections, this can seem a good idea, but on the viewer side it means that the free cores (on a quad core CPU, only one is always used at 100% for rendering, the three others are only (partially) used while decoding textures and for other threads, suchs as fetching/caching) are just sitting there, doing nothing as they wait for a texture to be downloaded from your only two "pipes"... and what happens when a connection stalls and timeouts ?... You loose half your bandwitdh (instead of only 1/32th) !... I would therefore recommend a higher number of persistent connections (16 sounds good and 8 an absolute minimum); alas such connections are precisely very limited (usually 4 per IP) in standard HTTP server configurations (they are considered costy, precisely because they are persistent while the traffic is only sporadic on normal web servers). This means that the grid's (SL and OpenSIM) texture HTTP servers would have to be configured specially to allow a higher limit per IP... On Sun, 29 Jul 2012 15:59:38 +0200, Carlo Wood wrote: > On Sun, 29 Jul 2012 10:07:18 +0200 > Henri Beauchamp wrote: > > > On Sun, 29 Jul 2012 05:23:15 +0200, Carlo Wood wrote: > > > > > On Fri, 27 Jul 2012 16:59:18 -0400 > > > holydoughnuts wrote: > > > > > > The implementation that I wrote for Singularity (not yet in the > > > the official release) is more on the side of "blazing fast" :p. > > > The bottleneck is entirely server-side, but I've seen download > > > speeds of 1 MB/s non-stop till all textures were there. > > > > With just a few tweakings to the texture fetcher (and in particular > > a setting that permits up to 32 concurrent HTTP fetches), I get much > > more than 1MB/s in the Cool VL Viewer... In fact, I'm more in the > > 10MB/s+ range while rezzing in heavily textured areas and the rezzing > > time is pretty low... This has been so for many months (well over > > a year actually) already. > > I agree that that would be an advantage for the user; but it's not > clear to me if it is allowed (or will be in the near future) to > have 32 concurrent fetches. > > The rationale that it SHOULD be allowed is that the user will > download those textures anyway; so, you might as well allow > them to get it quickly, in a short time: this has no influence > on the average number of open file descriptors on the server. > > I understand that LL is afraid that once viewers can keep sockets > open (for reuse) that the servers run out of filedescriptors. Of course, > this is all to true. Therefore I propose to set a limit on the > maximum number of UNUSED filedescriptors. However, there should be > no limit or a much higher limit, on the number of connections that > are actually in use. The question is then: when is a filedescriptor > "unused"? Well, I'd say that for the sake of re-use, it can be > considered unused if there hasn't been a new request for it for > -say- a second. It's probably best to define multiple stages, > that is: > * Allow a maximum of 32 connections. > * Allow up to 32 connections that are unused for 1 second. > * Allow up to 8 connections that are unused for 10 seconds. > * Allow up to 2 connections that are unused for 1 minute. > * Allow 1 connection to be unused for 20 minutes (or whenever > one leaves a region and it can be determined that this server > won't be needed or used anymore). > > Of course this means that upon teleport to a new region with > many unknown textures, the viewer will make 32 new SSH connections, > but that is MUCH less than one new connection PER TEXTURE, as we > have now. Then all those connections are reused until all textures > have been downloaded (a few seconds). > > Other strategies are possible, like NOT immediately creating a > new connection as long as the maximum of 32 connections haven't > been used up yet, but waiting with that until there's a queue > of requests building up. > > Bottom line is, I'm afraid that Linden Lab is going to take the > (too) simplistic route as they often have done in the past, and > do something very silly like: > * Allow a maximum of 2 connections, and allow to keep them > open indefinitely. > > I hope you see the difference :p > I argue that something like that makes no sense and would hurt > the user because they'd have to wait unnecessary long before > everything downloads. > From sheet.spotter at gmail.com Sun Jul 29 10:58:30 2012 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Sun, 29 Jul 2012 12:58:30 -0500 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <20120729162321.c8a9bbc9.sldev@free.fr> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com><20120729052315.0a2b805b@hikaru.localdomain><20120729100718.fad247e2.sldev@free.fr><20120729155938.1587c348@hikaru.localdomain> <20120729162321.c8a9bbc9.sldev@free.fr> Message-ID: <7AE3678A2CFD4672B0521D014CF5892B@kenb> Does increasing the HTTP connection limit also increase the burden on the server and network? Increasing the HTTP connection limit on one client might improve the experience for one person. It might also diminish the experience for everyone else on the same server. Sheet Spotter -----Original Message----- From: opensource-dev-bounces at lists.secondlife.com [mailto:opensource-dev-bounces at lists.secondlife.com] On Behalf Of Henri Beauchamp Sent: July 29, 2012 9:23 AM To: opensource-dev at lists.secondlife.com Subject: Re: [opensource-dev] New HTTP Library & Project Viewer [...] FYI, early HTTP fetches code was allowing up to 32 connections already, then it was lowered to 8, then raised back up to 16, and I since lost track of what maximum is currently hardcoded in LL's viewer... That's why I made it a configurable setting: if you start seeing timeouts or "busy" replies from the server in your viewer log, then you can still lower the setting. The default in the Cool VL Viewer is 16, but I have always used 32 myself and never came accross any issue, including in over-crowded sims (and I can enjoy a very fast rezzing experience): of course, you could argue that this is because everyone else in the sim is limited to 8 connections... And you could be right (hard to say: only LL could...). [...] From oz at lindenlab.com Mon Jul 30 10:08:18 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 30 Jul 2012 13:08:18 -0400 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <20120729100718.fad247e2.sldev@free.fr> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> Message-ID: <5016BF82.1090809@lindenlab.com> On 2012-07-29 04:07 , Henri Beauchamp wrote: > With just a few tweakings to the texture fetcher (and in particular > a setting that permits up to 32 concurrent HTTP fetches), Caution... once we begin supporting persistent connections and pipelined requests on the server side (we're working on it), opening that many connections will very likely be considered abuse of the service. Allowing a single server to have that many potentially long-lived connections to the same server would starve the file descriptor pool very quickly at the server end, adversely affecting other users. HTTP itself recommends that clients not maintain more than 2 connections to the same service [1]. I don't know exactly what limit we will decide is reasonable (I expect that 2 will be ok, but don't know whether or not some larger number will be also). Please bear this in mind as you think about your designs. I will keep you all informed as things develop. [1] RFC 2616, section 8.1.4 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120730/ffae6bec/attachment.htm From oz at lindenlab.com Mon Jul 30 10:20:33 2012 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 30 Jul 2012 13:20:33 -0400 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <7AE3678A2CFD4672B0521D014CF5892B@kenb> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com><20120729052315.0a2b805b@hikaru.localdomain><20120729100718.fad247e2.sldev@free.fr><20120729155938.1587c348@hikaru.localdomain> <20120729162321.c8a9bbc9.sldev@free.fr> <7AE3678A2CFD4672B0521D014CF5892B@kenb> Message-ID: <5016C261.9020207@lindenlab.com> On 2012-07-29 13:58 , Sheet Spotter wrote: > Does increasing the HTTP connection limit also increase the burden on the > server and network? > > Increasing the HTTP connection limit on one client might improve the > experience for one person. It might also diminish the experience for > everyone else on the same server. Exactly so. The effect is more complex than just consuming file descriptors on the server side, as well. TCP congestion control works far better when dealing with a smaller number of connections. Any packets that are not subject to congestion control that are sharing the same network path as a TCP connection increase the likelihood of a dropped packet in the connection flow, which causes the connection to immediately cut its transmission window by half. The viewer already puts a lot of UDP traffic into the same path. The handshake packets that open and close TCP connections are also not subject to the congestion control - which means that opening each new connection increases the chances that each of your existing connections will slow down by half. Opening many connections also puts additional strain on routers in the path that are doing connection tracking (which too many do), adding another possible source of problems. In general, when persistent connections and pipelined requests (having more than one request in flight on a connection at a time) are used, HTTP performs far better with a small number of connections than with more. As we begin deploying support for this way of using it on the server side, we'll be able to do good experiments to determine what the right tradeoffs are for network behavior and server load to provide optimal experience for users. From Celierra at gmail.com Mon Jul 30 11:15:16 2012 From: Celierra at gmail.com (Celierra Darling) Date: Mon, 30 Jul 2012 14:15:16 -0400 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <5016BF82.1090809@lindenlab.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> Message-ID: On Mon, Jul 30, 2012 at 1:08 PM, Oz Linden (Scott Lawrence) wrote: > > On 2012-07-29 04:07 , Henri Beauchamp wrote: > > With just a few tweakings to the texture fetcher (and in particular > a setting that permits up to 32 concurrent HTTP fetches), > > > Caution... once we begin supporting persistent connections and pipelined requests on the server side (we're working on it), opening that many connections will very likely be considered abuse of the service. Allowing a single server to have that many potentially long-lived connections to the same server would starve the file descriptor pool very quickly at the server end, adversely affecting other users. > > HTTP itself recommends that clients not maintain more than 2 connections to the same service [1]. I don't know exactly what limit we will decide is reasonable (I expect that 2 will be ok, but don't know whether or not some larger number will be also). > > Please bear this in mind as you think about your designs. I will keep you all informed as things develop. > > > [1] RFC 2616, section 8.1.4 FYI, the Firefox folks had a conversation in 2008 and decided to bump up from 2 to 6 by default at that time (partly because everyone else was raising it).[1] (And for what it's worth, I found a mention from '06 that "anything above 10 is excessive".[2]) That doesn't necessarily mean SL viewers should use the same values, but I think it probably demonstrates where people might try to push that setting, at least at first. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=423377#c4 [2] http://kb.mozillazine.org/index.php?title=Network.http.max-persistent-connections-per-server&diff=28784&oldid=28783 Celi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120730/25327bea/attachment.htm From monty at lindenlab.com Mon Jul 30 12:28:23 2012 From: monty at lindenlab.com (Monty Brandenberg) Date: Mon, 30 Jul 2012 15:28:23 -0400 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> Message-ID: <5016E057.10109@lindenlab.com> On 7/30/2012 2:15 PM, Celierra Darling wrote: > FYI, the Firefox folks had a conversation in 2008 and decided to bump up > from 2 to 6 by default at that time (partly because everyone else was > raising it).[1] (And for what it's worth, I found a mention from '06 > that "anything above 10 is excessive".[2]) That doesn't necessarily > mean SL viewers should use the same values, but I think it probably > demonstrates where people might try to push that setting, at least at first. > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=423377#c4 > [2] > http://kb.mozillazine.org/index.php?title=Network.http.max-persistent-connections-per-server&diff=28784&oldid=28783 On the limiting side of things, we have to deal with this unfortunately: http://www.smallnetbuilder.com/wireless/wireless-reviews/26843-linksyswrt54gv5reallyisalousyrouter?showall=&start=4 Finding a one-size-fits-all solution is a challenge when the consumer space performance range spans a 3000:1 ratio. I also did some tests on throughput-vs-concurrency and at 10 connections we're falling away from linear speedup. The example code in the new library happens to be a performance test framework should anyone want to play... m From dzonatas at gmail.com Mon Jul 30 12:15:13 2012 From: dzonatas at gmail.com (Jonathan Ballard) Date: Mon, 30 Jul 2012 12:15:13 -0700 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <5016BF82.1090809@lindenlab.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> Message-ID: That's two connections at the process level, so that is not the limit for each machine. For example, in hardware, each server machine may have eight network cards on PC motherboards (by what was on the market), so each card can have 12 connections for each server process, and each client process has 2 connections, and each network has 254 connections (IPv4), so there is leverage for maximum throughput up to the switch. On Monday, July 30, 2012, Oz Linden (Scott Lawrence) wrote: > On 2012-07-29 04:07 , Henri Beauchamp wrote: > > With just a few tweakings to the texture fetcher (and in particular > a setting that permits up to 32 concurrent HTTP fetches), > > > Caution... once we begin supporting persistent connections and pipelined > requests on the server side (we're working on it), opening that many > connections will very likely be considered abuse of the service. Allowing > a single server to have that many potentially long-lived connections to the > same server would starve the file descriptor pool very quickly at the > server end, adversely affecting other users. > > HTTP itself recommends that clients not maintain more than 2 connections > to the same service [1]. I don't know exactly what limit we will decide is > reasonable (I expect that 2 will be ok, but don't know whether or not some > larger number will be also). > > Please bear this in mind as you think about your designs. I will keep you > all informed as things develop. > > > [1] RFC 2616, section 8.1.4 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120730/bfd7f291/attachment.htm From kadah.coba at gmail.com Mon Jul 30 13:36:20 2012 From: kadah.coba at gmail.com (Kadah) Date: Mon, 30 Jul 2012 13:36:20 -0700 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <5016C261.9020207@lindenlab.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com><20120729052315.0a2b805b@hikaru.localdomain><20120729100718.fad247e2.sldev@free.fr><20120729155938.1587c348@hikaru.localdomain> <20120729162321.c8a9bbc9.sldev@free.fr> <7AE3678A2CFD4672B0521D014CF5892B@kenb> <5016C261.9020207@lindenlab.com> Message-ID: <5016F044.6070008@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/30/2012 10:20 AM, Oz Linden (Scott Lawrence) wrote: > Opening many connections also puts additional strain on routers in > the path that are doing connection tracking (which too many do), > adding another possible source of problems. It's a known issue that with the default concurrent setting of _4_ that many consumer level networking equipment can quickly overloaded by the viewer. This project will eventually address local open connection overloading (ie, few connection and allowing keep-alive). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQFvBEAAoJEIdLfPRu7qE2nAgH/RZvaliZ9F/7YnNmskJYwMKJ o3udee56w29zy5IRB/frL/82N8T7/MLkH6iF2en7BHgJpNG3rnN6O5mElAdwmkWN WfzbVqL1sSoiUyzI6pHDISAhjyR/4yxtX8UEJ9ofVgY9Wr/BvPfS25V/jdr1OD0r 2vMm8neGGoQ3V5RgQXTmFlAz/6BgmFH/Ov198IMD1RuIs3k46x1xzVuMz6P//zTa nNo/19O6y7Oog7/75nb/AufkvcARzjI7H6F4JlAQhKs1PA0VATsvNXAtiGSAF93K UvQ91TJtBW1A5G3lcOvXVS5w8OjRNgN6FfieFilMjary23psq000bYkMzd91CR0= =FhoG -----END PGP SIGNATURE----- From tateru.nino at gmail.com Mon Jul 30 14:03:04 2012 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 31 Jul 2012 07:03:04 +1000 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <5016E057.10109@lindenlab.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> <5016E057.10109@lindenlab.com> Message-ID: <5016F688.1080605@gmail.com> On 31/07/2012 5:28 AM, Monty Brandenberg wrote: > On 7/30/2012 2:15 PM, Celierra Darling wrote: > >> FYI, the Firefox folks had a conversation in 2008 and decided to bump up >> from 2 to 6 by default at that time (partly because everyone else was >> raising it).[1] (And for what it's worth, I found a mention from '06 >> that "anything above 10 is excessive".[2]) That doesn't necessarily >> mean SL viewers should use the same values, but I think it probably >> demonstrates where people might try to push that setting, at least at first. >> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=423377#c4 >> [2] >> http://kb.mozillazine.org/index.php?title=Network.http.max-persistent-connections-per-server&diff=28784&oldid=28783 > On the limiting side of things, we have to deal with this > unfortunately: > > http://www.smallnetbuilder.com/wireless/wireless-reviews/26843-linksyswrt54gv5reallyisalousyrouter?showall=&start=4 > > Finding a one-size-fits-all solution is a challenge when the consumer > space performance range spans a 3000:1 ratio. > > I also did some tests on throughput-vs-concurrency and at 10 > connections we're falling away from linear speedup. The example > code in the new library happens to be a performance test framework > should anyone want to play... > It seems almost everyone I know has a linksys WRT. Heck *I* have one, myself - the rev 2 - and there's three of us feeding through that. (Many of the non US models have their firmware in ROM, rather than in flash and can't be updated with DD-WRT). Heck, I know one person with two. A Belkin G *and* a Linksys WRT. Rubbish consumer routers are hard to ignore, even if you've got a good one yourself. From tateru.nino at gmail.com Mon Jul 30 14:27:25 2012 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 31 Jul 2012 07:27:25 +1000 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <5016C261.9020207@lindenlab.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com><20120729052315.0a2b805b@hikaru.localdomain><20120729100718.fad247e2.sldev@free.fr><20120729155938.1587c348@hikaru.localdomain> <20120729162321.c8a9bbc9.sldev@free.fr> <7AE3678A2CFD4672B0521D014CF5892B@kenb> <5016C261.9020207@lindenlab.com> Message-ID: <5016FC3D.7050606@gmail.com> On 31/07/2012 3:20 AM, Oz Linden (Scott Lawrence) wrote: > On 2012-07-29 13:58 , Sheet Spotter wrote: >> Does increasing the HTTP connection limit also increase the burden on the >> server and network? >> >> Increasing the HTTP connection limit on one client might improve the >> experience for one person. It might also diminish the experience for >> everyone else on the same server. > Exactly so. The effect is more complex than just consuming file > descriptors on the server side, as well. TCP congestion control works > far better when dealing with a smaller number of connections. Any > packets that are not subject to congestion control that are sharing the > same network path as a TCP connection increase the likelihood of a > dropped packet in the connection flow, which causes the connection to > immediately cut its transmission window by half. The viewer already puts > a lot of UDP traffic into the same path. The handshake packets that open > and close TCP connections are also not subject to the congestion control > - which means that opening each new connection increases the chances > that each of your existing connections will slow down by half. Opening > many connections also puts additional strain on routers in the path that > are doing connection tracking (which too many do), adding another > possible source of problems. > > In general, when persistent connections and pipelined requests (having > more than one request in flight on a connection at a time) are used, > HTTP performs far better with a small number of connections than with > more. As we begin deploying support for this way of using it on the > server side, we'll be able to do good experiments to determine what the > right tradeoffs are for network behavior and server load to provide > optimal experience for users. > > Also, a badly behaving connection (eg: one that is dropping packets) leaves the connection open longer, while delivering less data per unit time. That's basically a *waste* of server resources. If I overload my crappy consumer router with connections it can't properly handle, I'm indirectly impacting the experience of other users. Not a desirable situation. From monty at lindenlab.com Mon Jul 30 15:04:54 2012 From: monty at lindenlab.com (Monty Brandenberg) Date: Mon, 30 Jul 2012 18:04:54 -0400 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <5016F688.1080605@gmail.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> <5016E057.10109@lindenlab.com> <5016F688.1080605@gmail.com> Message-ID: <50170506.3050909@lindenlab.com> On 7/30/2012 5:03 PM, Tateru Nino wrote: > > Heck, I know one person with two. A > Belkin G *and* a Linksys WRT. There's someone who I would like to buy a drink. From liny.odell at phoenixviewer.com Mon Jul 30 15:52:58 2012 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Mon, 30 Jul 2012 15:52:58 -0700 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <50170506.3050909@lindenlab.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> <5016E057.10109@lindenlab.com> <5016F688.1080605@gmail.com> <50170506.3050909@lindenlab.com> Message-ID: On Mon, Jul 30, 2012 at 3:04 PM, Monty Brandenberg wrote: > On 7/30/2012 5:03 PM, Tateru Nino wrote: >> >> Heck, I know one person with two. A >> Belkin G *and* a Linksys WRT. > > There's someone who I would like to buy a drink. Im using my old wrt54gs with dd-wrt as a wireless access point/wired switch and set up an old amd k6 computer with 2 nics and slapped pfsense onto it and am using that as my router. Now if only I could change my ISP from ATT, but sadly, thats _all_ thats available where I live. From sldev at free.fr Mon Jul 30 16:13:52 2012 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 31 Jul 2012 01:13:52 +0200 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <5016BF82.1090809@lindenlab.com> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> Message-ID: <20120731011352.2792e1e2.sldev@free.fr> On Mon, 30 Jul 2012 13:08:18 -0400, Oz Linden (Scott Lawrence) wrote: > On 2012-07-29 04:07 , Henri Beauchamp wrote: > > With just a few tweakings to the texture fetcher (and in particular > > a setting that permits up to 32 concurrent HTTP fetches), > > Caution... once we begin supporting persistent connections and pipelined > requests on the server side (we're working on it), opening that many > connections will very likely be considered abuse of the service. > Allowing a single server to have that many potentially long-lived > connections to the same server would starve the file descriptor pool > very quickly at the server end, adversely affecting other users. Don't put word in my mouths, that I never pronounced... I was not speaking about *persistent* connections. The current HTTP fetches are not persistent connections, and that's why 32 simultaneous requests are not really an issue (and it was actually the limit in Snowglobe v1.5, thus why I kept it in the Cool VL Viewer, but made it configurable (and defaulting to 16), when I noticed that the v2 viewers changed that limit down to 8 then up to 16 and then to whatever number it is now hardcoded with). > HTTP itself recommends that clients not maintain more than 2 connections > to the same service [1]. I don't know exactly what limit we will decide > is reasonable (I expect that 2 will be ok, but don't know whether or not > some larger number will be also). I bet 2 persistent connections will not be as performant as 16 (or even only 8) transient ones... Especially for oversea users, when links go through a load of routers before the viewer can actually communicate with LL's servers (and I have seen numerous times buggy/badly configured routers dropping "persistent" connections). Not to mention the underusage of the additional CPU cores for image decode and caching threads (that will have to wait each time and will, at best, process 2 images before the next 'bunch' (if 2 is already a 'bunch') arrives). > Please bear this in mind as you think about your designs. Please, don't underestimate my thinking capacity... I also think I proved numerous times with the Cool VL Viewer that I was very careful and quite reasonnable (refusing to implement things that could overload servers: I can give you half a dozen of examples if you want). Henri. From tateru.nino at gmail.com Mon Jul 30 17:23:15 2012 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 31 Jul 2012 10:23:15 +1000 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <20120731011352.2792e1e2.sldev@free.fr> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> <20120731011352.2792e1e2.sldev@free.fr> Message-ID: <50172573.6050108@gmail.com> On 31/07/2012 9:13 AM, Henri Beauchamp wrote: > On Mon, 30 Jul 2012 13:08:18 -0400, Oz Linden (Scott Lawrence) wrote: > >> HTTP itself recommends that clients not maintain more than 2 connections >> to the same service [1]. I don't know exactly what limit we will decide >> is reasonable (I expect that 2 will be ok, but don't know whether or not >> some larger number will be also). > I bet 2 persistent connections will not be as performant as 16 (or even > only 8) transient ones... Especially for oversea users, when links go > through a load of routers before the viewer can actually communicate with > LL's servers (and I have seen numerous times buggy/badly configured routers > dropping "persistent" connections). The pipelining of requests *should* contribute a great deal to per-connection performance - there are outliers where that won't happen (stuck/stalled connections, broken connections, and so forth), but in the main properly-implemented pipelining, smartly managed by the viewer, should provide quite a boost under the most common use-cases, IMO. > Not to mention the underusage of the additional CPU cores for image decode > and caching threads (that will have to wait each time and will, at best, > process 2 images before the next 'bunch' (if 2 is already a 'bunch') > arrives). I'm not sure that's actually much of a concern. The number of textures actually *ready* for decoding at any tick of the clock when they can be scheduled is generally quite small (just one or two), even under the old UDP system - more cores for texture decoding tasks primarily benefit the slower systems where the decoding starts to eat up significant chunks of user-scale time - or if you're really sucking down oodles of data at speeds many of us overseas users can't actually pull. (I think it is generally safe to assume a median data transfer rate of 400Kbps - this is everyone's cue to jump up and tell me that the number is vastly over/under any sane view of reality) So, confining the number of persistent connections to an arbitrary X (say 2 or 3) doesn't *seem* to me like it would make that much of a difference in practical terms to many users. It will to *some*, absolutely, who could doubtless get a *heap* more performance from X+1 or X+2 pipelines. There will always be those cases, IMO. From cjohndavies at gmail.com Tue Jul 31 03:54:27 2012 From: cjohndavies at gmail.com (CJ Davies) Date: Tue, 31 Jul 2012 11:54:27 +0100 Subject: [opensource-dev] converting degrees into quaternions Message-ID: <5017B963.5000901@gmail.com> I've been struggling with this for 2 days now & am no closer to working it out (despite investigating all sorts of examples online, including the SL wiki). I have a accelerometer/magnetometer that tells me orientation via compass bearing, pitch & roll. All of these are in degrees which can easily be converted to radians via foo*DEG_TO_RAD. I want to plug these values into llcoordframe methods to control where the camera points. All of the llcoordframe stuff works in quaternions & I can't for the life of me convert properly. I've just tried following this approach --> http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToQuaternion/index.htm But this results in output like this --> http://paste2.org/p/2089138 Note how the calculated w/x/y/z values change drastically with tiny changes in the bearing/pitch/roll, eg between lines 43 & 50 (the accelerometer/magnetometer was motionless on the desk at the time!). Any help greatly appreciated. Regards, CJ Davies From sl-dev at theblob.org Tue Jul 31 05:29:35 2012 From: sl-dev at theblob.org (Sophira Crystal) Date: Tue, 31 Jul 2012 13:29:35 +0100 Subject: [opensource-dev] converting degrees into quaternions In-Reply-To: <5017B963.5000901@gmail.com> References: <5017B963.5000901@gmail.com> Message-ID: Hi, You don't convert degrees to quaternions directly. You convert vectors to rotations (which are quarternions), and you do that with the llEuler2Rot function. As for the rest of your query, you might find http://wiki.secondlife.com/wiki/Rotation helpful - I don't know much about rotations, but I bet the answer you want is probably in there somewhere. I hope my reply's been helpful, even though I personally don't know much... - Sophie. On Tue, Jul 31, 2012 at 11:54 AM, CJ Davies wrote: > I've been struggling with this for 2 days now & am no closer to working > it out (despite investigating all sorts of examples online, including > the SL wiki). > > I have a accelerometer/magnetometer that tells me orientation via > compass bearing, pitch & roll. All of these are in degrees which can > easily be converted to radians via foo*DEG_TO_RAD. I want to plug these > values into llcoordframe methods to control where the camera points. All > of the llcoordframe stuff works in quaternions & I can't for the life of > me convert properly. > > I've just tried following this approach --> > http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToQuaternion/index.htm > > But this results in output like this --> http://paste2.org/p/2089138 > > Note how the calculated w/x/y/z values change drastically with tiny > changes in the bearing/pitch/roll, eg between lines 43 & 50 (the > accelerometer/magnetometer was motionless on the desk at the time!). > > Any help greatly appreciated. > > Regards, > CJ Davies > _______________________________________________ > 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 From sl-dev at theblob.org Tue Jul 31 05:38:42 2012 From: sl-dev at theblob.org (Sophira Crystal) Date: Tue, 31 Jul 2012 13:38:42 +0100 Subject: [opensource-dev] converting degrees into quaternions In-Reply-To: References: <5017B963.5000901@gmail.com> Message-ID: Hi, To follow up on this... The easiest way to do what you want is to make a vector made up of in degrees, multiply the vector by DEG_TO_RAD, and then put it through llEuler2Rot. You should then have a good rotation that you can pass to a function that needs it. Hope this helps! - Sophie. On Tue, Jul 31, 2012 at 1:29 PM, Sophira Crystal wrote: > Hi, > > You don't convert degrees to quaternions directly. You convert vectors > to rotations (which are quarternions), and you do that with the > llEuler2Rot function. > > As for the rest of your query, you might find > http://wiki.secondlife.com/wiki/Rotation helpful - I don't know much > about rotations, but I bet the answer you want is probably in there > somewhere. > > I hope my reply's been helpful, even though I personally don't know much... > > - Sophie. > > On Tue, Jul 31, 2012 at 11:54 AM, CJ Davies wrote: >> I've been struggling with this for 2 days now & am no closer to working >> it out (despite investigating all sorts of examples online, including >> the SL wiki). >> >> I have a accelerometer/magnetometer that tells me orientation via >> compass bearing, pitch & roll. All of these are in degrees which can >> easily be converted to radians via foo*DEG_TO_RAD. I want to plug these >> values into llcoordframe methods to control where the camera points. All >> of the llcoordframe stuff works in quaternions & I can't for the life of >> me convert properly. >> >> I've just tried following this approach --> >> http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToQuaternion/index.htm >> >> But this results in output like this --> http://paste2.org/p/2089138 >> >> Note how the calculated w/x/y/z values change drastically with tiny >> changes in the bearing/pitch/roll, eg between lines 43 & 50 (the >> accelerometer/magnetometer was motionless on the desk at the time!). >> >> Any help greatly appreciated. >> >> Regards, >> CJ Davies >> _______________________________________________ >> 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 From nexiim at gmail.com Tue Jul 31 08:14:33 2012 From: nexiim at gmail.com (Nexii Malthus) Date: Tue, 31 Jul 2012 16:14:33 +0100 Subject: [opensource-dev] converting degrees into quaternions In-Reply-To: References: <5017B963.5000901@gmail.com> Message-ID: Hey Folks, The C++ codebase doesn't have much to do with LSL, so llEuler2Rot won't exactly help. What you are looking for CJ are the helper functions for quaternions, maybe this one will help: const LLQuaternion& setEulerAngles(F32 roll, F32 pitch, F32 yaw); (form llquaternion ) - Nexii On Tue, Jul 31, 2012 at 1:38 PM, Sophira Crystal wrote: > Hi, > > To follow up on this... > > The easiest way to do what you want is to make a vector made up of > in degrees, multiply the vector by DEG_TO_RAD, > and then put it through llEuler2Rot. You should then have a good > rotation that you can pass to a function that needs it. > > Hope this helps! > > - Sophie. > > On Tue, Jul 31, 2012 at 1:29 PM, Sophira Crystal > wrote: > > Hi, > > > > You don't convert degrees to quaternions directly. You convert vectors > > to rotations (which are quarternions), and you do that with the > > llEuler2Rot function. > > > > As for the rest of your query, you might find > > http://wiki.secondlife.com/wiki/Rotation helpful - I don't know much > > about rotations, but I bet the answer you want is probably in there > > somewhere. > > > > I hope my reply's been helpful, even though I personally don't know > much... > > > > - Sophie. > > > > On Tue, Jul 31, 2012 at 11:54 AM, CJ Davies > wrote: > >> I've been struggling with this for 2 days now & am no closer to working > >> it out (despite investigating all sorts of examples online, including > >> the SL wiki). > >> > >> I have a accelerometer/magnetometer that tells me orientation via > >> compass bearing, pitch & roll. All of these are in degrees which can > >> easily be converted to radians via foo*DEG_TO_RAD. I want to plug these > >> values into llcoordframe methods to control where the camera points. All > >> of the llcoordframe stuff works in quaternions & I can't for the life of > >> me convert properly. > >> > >> I've just tried following this approach --> > >> > http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToQuaternion/index.htm > >> > >> But this results in output like this --> http://paste2.org/p/2089138 > >> > >> Note how the calculated w/x/y/z values change drastically with tiny > >> changes in the bearing/pitch/roll, eg between lines 43 & 50 (the > >> accelerometer/magnetometer was motionless on the desk at the time!). > >> > >> Any help greatly appreciated. > >> > >> Regards, > >> CJ Davies > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120731/696674a2/attachment.htm From cjohndavies at gmail.com Tue Jul 31 09:01:26 2012 From: cjohndavies at gmail.com (CJ Davies) Date: Tue, 31 Jul 2012 17:01:26 +0100 Subject: [opensource-dev] converting degrees into quaternions In-Reply-To: References: <5017B963.5000901@gmail.com> Message-ID: <50180156.2020107@gmail.com> Looks like my problem was an amateur mistake - causing integer division on a float value, which when dealing with values that range between -1 & 1 is fairly debilitating! I'm now getting the right values, but in the wrong places, using the LLQuaternion(F32 x, F32 y, F32 z, F32 w); constructor. I presume this must just be because whilst SL uses E/W as +ve/-ve x axis & N/S as +ve/-ve y axis I must be assuming something else for my magnetometer/accelerometer. SL looking North - {0.0, 0.0, 0.7, 0.7} magnetometer pointing North - {0.0, 0.0, 0.0, 1.0} SL looking East - {0.0, 0.0, 0.0, 1.0} magnetometer pointing North - {0.7, 0.0, 0.0, 0.7} SL looking South - {0.0, 0.0, -0.7, 0.7} magnetometer pointing South - {-1.0, 0.0, 0.0, 0.0} SL looking West - {0.0, 0.0, 1.0, 0.0} magnetometer pointing West - {-0.7, 0.0, 0.0, 0.7} Whilst I'm at it, llquaternion.h has some confusing comments in it... (look at the order of parameters in declaration & comment closely!) const LLQuaternion& setEulerAngles(F32 roll, F32 pitch, F32 yaw); // Sets Quaternion to euler2quat(pitch, yaw, roll) Regards, CJ Davies On 31/07/12 16:14, Nexii Malthus wrote: > Hey Folks, > > The C++ codebase doesn't have much to do with LSL, so llEuler2Rot won't > exactly help. > > What you are looking for CJ are the helper functions for quaternions, > maybe this one will help: > > const LLQuaternion& setEulerAngles(F32 roll, F32 pitch, F32 yaw); > > (form llquaternion > ) > > - Nexii > > On Tue, Jul 31, 2012 at 1:38 PM, Sophira Crystal > wrote: > > Hi, > > To follow up on this... > > The easiest way to do what you want is to make a vector made up of > in degrees, multiply the vector by DEG_TO_RAD, > and then put it through llEuler2Rot. You should then have a good > rotation that you can pass to a function that needs it. > > Hope this helps! > > - Sophie. > > On Tue, Jul 31, 2012 at 1:29 PM, Sophira Crystal > wrote: > > Hi, > > > > You don't convert degrees to quaternions directly. You convert > vectors > > to rotations (which are quarternions), and you do that with the > > llEuler2Rot function. > > > > As for the rest of your query, you might find > > http://wiki.secondlife.com/wiki/Rotation helpful - I don't know much > > about rotations, but I bet the answer you want is probably in there > > somewhere. > > > > I hope my reply's been helpful, even though I personally don't > know much... > > > > - Sophie. > > > > On Tue, Jul 31, 2012 at 11:54 AM, CJ Davies > > wrote: > >> I've been struggling with this for 2 days now & am no closer to > working > >> it out (despite investigating all sorts of examples online, > including > >> the SL wiki). > >> > >> I have a accelerometer/magnetometer that tells me orientation via > >> compass bearing, pitch & roll. All of these are in degrees which can > >> easily be converted to radians via foo*DEG_TO_RAD. I want to > plug these > >> values into llcoordframe methods to control where the camera > points. All > >> of the llcoordframe stuff works in quaternions & I can't for the > life of > >> me convert properly. > >> > >> I've just tried following this approach --> > >> > http://www.euclideanspace.com/maths/geometry/rotations/conversions/eulerToQuaternion/index.htm > >> > >> But this results in output like this --> http://paste2.org/p/2089138 > >> > >> Note how the calculated w/x/y/z values change drastically with tiny > >> changes in the bearing/pitch/roll, eg between lines 43 & 50 (the > >> accelerometer/magnetometer was motionless on the desk at the time!). > >> > >> Any help greatly appreciated. > >> > >> Regards, > >> CJ Davies > >> _______________________________________________ > >> 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 > > From kadah.coba at gmail.com Tue Jul 31 18:55:39 2012 From: kadah.coba at gmail.com (Kadah) Date: Tue, 31 Jul 2012 18:55:39 -0700 Subject: [opensource-dev] A rather uniquely unexpected behavior from Second Life's official viewer In-Reply-To: References: Message-ID: <50188C9B.3030502@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see this too sometimes. What release channel is the region? On 7/26/2012 7:35 PM, Moriz Gupte wrote: > Hello, I am wondering what could be causing objects to disappear > in the latest Second Life viewer 3.3.4.26 > > See picture of the same scene (1) in the SL official viewer, and > (2) in FireStorm Inline image 1 > > I am wondering why the SL viewer is not rendering objects? This is > one strange behavior .... When I log back in, I can see all them > again, regardless of whether I clear cache or not. Any clues what > could be wrong. This is a show stopper for me because now am not > sure what users will be seeing or not. > > R > > -- 'Consider how the lilies grow. They do not labor or spin.' > *Rameshsharma Ramloll* PhD, /Research Associate Professor/, Idaho > State University, Pocatello, ID 83209 Tel: 208-282-5333 Blog > , LinkedIn > > > > _______________________________________________ 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEbBAEBAgAGBQJQGIybAAoJEIdLfPRu7qE2TUEH9217nDebcXKPhVksvyZGxyiw X17au7Z4w4oEohEjARHYEndatYm1wguvDpqaxSrbutO0oBYbPPVwJ1gF0noVAmSu h5FoTqkiz1s9cI1MaMCTNz+rCoqzTH9rHtSsebJSO9S+gqAgohtq9gRnOUG04fBy QMG3h1pqDfsEjbi6SIVA3OoiRz+uUS7OXzU/gn05A8OOc39vllhRoJFRCfb0YpBe kZUH1SjtrnI/tucQ3hTPrRCoER02TOKittTAuTzUM64ij/XGVoU6w6FDJ30zOYnR RQrHPjDcC2W8MKdCdsocruwBHNVFjGPAXaaTlyL/XZn5w7obDB0fDRkc9MXnKw== =tugn -----END PGP SIGNATURE----- From kadah.coba at gmail.com Tue Jul 31 19:03:09 2012 From: kadah.coba at gmail.com (Kadah) Date: Tue, 31 Jul 2012 19:03:09 -0700 Subject: [opensource-dev] New HTTP Library & Project Viewer In-Reply-To: <20120731011352.2792e1e2.sldev@free.fr> References: <5012D3EE.7060309@lindenlab.com> <50130126.7010007@gmail.com> <20120729052315.0a2b805b@hikaru.localdomain> <20120729100718.fad247e2.sldev@free.fr> <5016BF82.1090809@lindenlab.com> <20120731011352.2792e1e2.sldev@free.fr> Message-ID: <50188E5D.9030408@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/30/2012 4:13 PM, Henri Beauchamp wrote: > Don't put word in my mouths, that I never pronounced... I was not > speaking about *persistent* connections. The current HTTP fetches > are not persistent connections, and that's why 32 simultaneous > requests are not really an issue (and it was actually the limit in > Snowglobe v1.5, thus why I kept it in the Cool VL Viewer, but made > it configurable (and defaulting to 16), when I noticed that the v2 > viewers changed that limit down to 8 then up to 16 and then to > whatever number it is now hardcoded with). Its 8 again with the fallow comment. I tired to track down the rev, but apparently Mecurial 2.2 can't properly annotate that file for some reason, and the new UI for it in TortoiseHg2 is horrid. All of the referenced jiras around its changes are not public. //NOTE: //control the number of the http requests issued for: //1, not openning too many file descriptors at the same time; //2, control the traffic of http so udp gets bandwidth. // static const S32 MAX_NUM_OF_HTTP_REQUESTS_IN_QUEUE = 8 ; -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQGI5dAAoJEIdLfPRu7qE2HUkIAJRvKLZ9Y5MfZq4SJaCBGcOe tPG2TPamItRvGAE554xTlo4NDv8OHb0PbLoLsH4hLLNrsqLRXVuIgqi86lWrIphK JMp8r9ePCpDha9hlo3xw/DoUF3ZDJNvBoUgg12B1/eGSHVjviPPP7CFuQKofRtLK p2RrgAsa4CwNdH7sXKodmzC92+fxw6DjXKXfyn4ss6MeNr+pUtKUDklxe0sBK69k E/wvHplNfXOjBQ14cBjDINJZXxoU/D5++X8+8oe5EtvXs6jcULAuAwqhuno5v7KY vOtFo9YNGgiipaBd4Ft+duice4Z02b2T/NtWvFy5l02YaMQ1UTdz4Fnsaap6JAw= =nNko -----END PGP SIGNATURE-----