From tillie at xp2.de Mon Jun 1 02:52:09 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Mon, 01 Jun 2009 11:52:09 +0200 Subject: [sldev] Compiling successfully with VC++ 2008 Express In-Reply-To: <20090531200842.8b0823960ceb6a56f7ddf638f99b00cb.cbf02dfacf.wbe@email.secureserver.net> References: <20090531200842.8b0823960ceb6a56f7ddf638f99b00cb.cbf02dfacf.wbe@email.secureserver.net> Message-ID: <4A23A4C9.20802@xp2.de> jodiah at my-webhome.com wrote: > Before I attempted to compile, I updated cmake, python, Cygwin, Windows Platform > SDK, DirectX SDK, and Boost Libraries as outlined below: 1. When executing Run "boost_1_34_1\tools\jam\build_dist.bat" I get: X:\SecondLife\dev\deps\boost_1_34_1\tools\jam\src>cl /nologo /GZ /Zi /MLd -DNT -DYYDEBUG kernel32.lib advapi32.lib user32.lib /Feboo tstrap\jam0 command.c compile.c debug.c execnt.c expand.c filent.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lis ts.c make.c make1.c newstr.c option.c parse.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c s trings.c filesys.c builtins.c pwd.c class.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set .c modules/sequence.c modules/order.c 'cl' is not recognized as an internal or external command, operable program or batch file. Where belongs cl to? cygwin, cmake? I can't find it anywhere. 2. When trying to compile in VC++2008, I get this error: 1>Generating indra.y.cpp, indra.y.hpp 1>/usr/local/share/bison.simple: No such file or directory and then 2>Setting the secondlife-bin working directory for debugging. 2>Editing solution: X:/SecondLife/dev/linden/indra/build-VC90/SecondLife.sln 2>Looking for existing VisualStudio instance... 2> Didn't find open solution, starting new background VisualStudio instance... 2> Reading .sln file version... 2> Using version: VC90... 2>Value cannot be null. 2>Parameter name: type 2>Quitting do to error opening: X:\SecondLife\dev\linden\indra\build-VC90\SecondLife.sln There is no bison_simple... I tried several version of bison, comes with none of them. Tillie From schlenk at uni-oldenburg.de Mon Jun 1 04:01:49 2009 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Mon, 1 Jun 2009 13:01:49 +0200 Subject: [sldev] Compiling successfully with VC++ 2008 Express In-Reply-To: <4A23A4C9.20802@xp2.de> References: <20090531200842.8b0823960ceb6a56f7ddf638f99b00cb.cbf02dfacf.wbe@email.secureserver.net> <4A23A4C9.20802@xp2.de> Message-ID: <5F76FC1D-BA27-4D7C-A99F-E5F402E19522@uni-oldenburg.de> Am 01.06.2009 um 11:52 schrieb Tillie Ariantho: > jodiah at my-webhome.com wrote: > >> Before I attempted to compile, I updated cmake, python, Cygwin, >> Windows Platform >> SDK, DirectX SDK, and Boost Libraries as outlined below: > > 1. When executing Run "boost_1_34_1\tools\jam\build_dist.bat" I get: > > X:\SecondLife\dev\deps\boost_1_34_1\tools\jam\src>cl /nologo /GZ / > Zi /MLd -DNT -DYYDEBUG kernel32.lib advapi32.lib user32.lib /Feboo > tstrap\jam0 command.c compile.c debug.c execnt.c expand.c filent.c > glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lis > ts.c make.c make1.c newstr.c option.c parse.c pathunix.c regexp.c > rules.c scan.c search.c subst.c timestamp.c variable.c modules.c s > trings.c filesys.c builtins.c pwd.c class.c w32_getreg.c native.c > modules/set.c modules/path.c modules/regex.c modules/property-set > .c modules/sequence.c modules/order.c > 'cl' is not recognized as an internal or external command, > operable program or batch file. > > Where belongs cl to? cygwin, cmake? I can't find it anywhere. > cl is microsofts VC compiler, you should put it in your PATH so it gets found, usually by running some vcvars32.bat file first. Michael From robin.cornelius at gmail.com Mon Jun 1 04:05:57 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 1 Jun 2009 12:05:57 +0100 Subject: [sldev] Compiling successfully with VC++ 2008 Express In-Reply-To: <5F76FC1D-BA27-4D7C-A99F-E5F402E19522@uni-oldenburg.de> References: <20090531200842.8b0823960ceb6a56f7ddf638f99b00cb.cbf02dfacf.wbe@email.secureserver.net> <4A23A4C9.20802@xp2.de> <5F76FC1D-BA27-4D7C-A99F-E5F402E19522@uni-oldenburg.de> Message-ID: On Mon, Jun 1, 2009 at 12:01 PM, Michael Schlenker wrote: >> Where belongs cl to? cygwin, cmake? I can't find it anywhere. >> > cl is microsofts VC compiler, you should put it in your PATH so it > gets found, usually by running some vcvars32.bat file first. > Yes, that is an option when install ing visual studio to add it to the [HKCU] path. An alternative is to open the visual studio command prompt. If you go to the Start menu entry for the visual C++ of interest you will see a tools folder with "Visual Studio 2008 Command Prompt", this opens the command prompt AND runs the vcvars32.bar for you in a single operation so you know you have the correct environment set up. This also allows you to work with 2003/2005 and 2008 on a single system by just opening the required visual studio command prompy. Robin From sllists at boroon.dasgupta.ch Mon Jun 1 05:03:45 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon, 01 Jun 2009 14:03:45 +0200 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A200686.2020906@dragonkeepcreations.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> <4d211a610905281809i23924c88o64a9aa17c2bd6e39@mail.gmail.com> <4a1f5057.1e068e0a.01f5.5bdb@mx.google.com> <20090529111801.GB23852@alinoe.com> <4A200686.2020906@dragonkeepcreations.com> Message-ID: <4A23C3A1.8020405@boroon.dasgupta.ch> Carlo was listing the dependencies (i.e. the required software) for the single steps of the build process on a certain flavor of Linux. While this gives good hints on what could be needed on other flavors of Linux (and probably even other UNIX-like systems), I don't know how relevant it is for building on Windows XP. Was that what you wanted to be clarified? cheers Boroondas Maya Remblai schrieb: > Can you clarify, please? I did say I was new at this... > > Maya > > Carlo Wood wrote: > >> One of the problems is that the build often fails ungraceful >> when some development package is missing. >> >> I made a list for another grid (and different viewer entirely, based >> on the LL's one of course) (and for debian) of the required packages. >> This list is what is needed according/for Debian testing (squeeze): >> >> To get the source: >> [...] >> >> To run configure: >> [...] >> >> To compile: >> [...] >> >> To compile (not in Debian Stable): >> [...] >> >> To install and run: >> [...] From carlo at alinoe.com Mon Jun 1 06:04:35 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 1 Jun 2009 15:04:35 +0200 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A23C3A1.8020405@boroon.dasgupta.ch> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> <4d211a610905281809i23924c88o64a9aa17c2bd6e39@mail.gmail.com> <4a1f5057.1e068e0a.01f5.5bdb@mx.google.com> <20090529111801.GB23852@alinoe.com> <4A200686.2020906@dragonkeepcreations.com> <4A23C3A1.8020405@boroon.dasgupta.ch> Message-ID: <20090601130435.GA27798@alinoe.com> On Mon, Jun 01, 2009 at 02:03:45PM +0200, Boroondas Gupte wrote: > Carlo was listing the dependencies (i.e. the required software) for the > single steps of the build process on a certain flavor of Linux. While > this gives good hints on what could be needed on other flavors of Linux > (and probably even other UNIX-like systems), I don't know how relevant > it is for building on Windows XP. What I wanted to say is that it's extremely unlikely one has everything installed that is needed to build the viewer unless you KNOW you did install it (did considerable effort and/or found a list of what needs to be installed). -- Carlo Wood From jodiah at my-webhome.com Mon Jun 1 10:43:23 2009 From: jodiah at my-webhome.com (jodiah at my-webhome.com) Date: Mon, 01 Jun 2009 10:43:23 -0700 Subject: [sldev] CMake Error: cannot find file... Message-ID: <20090601104323.8b0823960ceb6a56f7ddf638f99b00cb.58038477ef.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090601/e2949eb9/attachment.htm From robla at lindenlab.com Mon Jun 1 10:55:15 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 01 Jun 2009 10:55:15 -0700 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption Message-ID: <4A241603.1050403@lindenlab.com> I've been doing a little asking around about 32-bit vs 64-bit Linux desktop adoption, and got the following mail. Based on one reasonably current estimate, 64-bit adoption is running at about 24.6%. I filed a feature request in JIRA as a place to gather up conversation on this topic: http://jira.secondlife.com/browse/VWR-13793 If you have other sources of data, please post them there. Thanks! Rob -------- Original Message -------- Subject: Re: [Lf_desktop] Hard numbers on 32-bit vs 64-bit Linux desktop adoption Date: Sun, 31 May 2009 23:13:37 -0700 From: Donnie Berkholz To: Rob Lanphier CC: lf_desktop at lists.linux-foundation.org On 21:15 Sun 31 May , Rob Lanphier wrote: > Hi all, > > I work on the Second Life viewer, which we make available for Linux > desktop users. One thing I've been doing a little searching around for > is hard numbers on 32-bit vs 64-bit OS adoption among desktop users. If > we could get a sense of the current share and trajectory, that would > help us plan for the shift. > > Any idea where to dig that kind of thing up? To get numbers for Fedora, I went to the Smolt page and clicked "Host based statistics" . Arch Count % of total i686 177386 75.0 % x86_64 58125 24.6 % I think Smolt is opt-in at the end of the installation process. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Attached Message Part Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090601/87dbc7d3/attachment.pgp From soft at lindenlab.com Mon Jun 1 10:58:24 2009 From: soft at lindenlab.com (Soft) Date: Mon, 1 Jun 2009 12:58:24 -0500 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption In-Reply-To: <4A241603.1050403@lindenlab.com> References: <4A241603.1050403@lindenlab.com> Message-ID: On Mon, Jun 1, 2009 at 12:55 PM, Rob Lanphier wrote: > I've been doing a little asking around about 32-bit vs 64-bit Linux > desktop adoption, and got the following mail. ?Based on one reasonably > current estimate, 64-bit adoption is running at about 24.6%. > > I filed a feature request in JIRA as a place to gather up conversation > on this topic: > http://jira.secondlife.com/browse/VWR-13793 > > If you have other sources of data, please post them there. It would also be great to see any numbers on 32- vs 64-bit performance, for any of you producing 32- and 64-bit stand-alone viewers. 64-bit would make setup easier. It would be helpful to know of any other gains. From monkowsk at watson.ibm.com Mon Jun 1 12:05:58 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 01 Jun 2009 15:05:58 -0400 Subject: [sldev] Recurring snowglobe crash In-Reply-To: <237828DB-4AC7-4B03-BB66-D41E9AE27EBC@lindenlab.com> References: <5A0F50DB-125E-49D8-9CAF-20253D0A7E14@lindenlab.com> <4A20890F.8080002@lindenlab.com> <237828DB-4AC7-4B03-BB66-D41E9AE27EBC@lindenlab.com> Message-ID: <4A242696.20704@watson.ibm.com> I haven't got a crash with 2338 yet, but I still see the sculpty messages. Did anyone go back and check for reverted merges in the Linden http-texture branch (VWR-11815)? Mike Philippe Bossut (Merov Linden) wrote: > Hi, > > On May 29, 2009, at 6:17 PM, Steve Bennetts (Steve Linden) wrote: > >> Ah, yes... this could actually be valid, we should eliminate the assert. >> I added it when I was trying to track down the problem and now >> understand why it happens. (There is an early exit in >> LLTextureFetchWorker::doWork() that can cause an abort while decoding. >> This is desired behavior, and is safe.) >> >> I'll fix this in the internal http-texture branch > > > I did the same change in snowglobe (svn rev 2338), marked the bug fixed > and started the builds. They completed with no errors and can be > downloaded here: > - > Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2338/SecondLife-i686-1.23.2.2338.tar.bz2 > - > Mac: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2338/SecondLife_1_23_2_2338_OSS.dmg > - > Windows: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2338/Second_Life_1-23-2-2338_OSS_Setup.exe From jacek.antonelli at gmail.com Mon Jun 1 13:22:59 2009 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Mon, 1 Jun 2009 15:22:59 -0500 Subject: [sldev] CMake Error: cannot find file... In-Reply-To: <20090601104323.8b0823960ceb6a56f7ddf638f99b00cb.58038477ef.wbe@email.secureserver.net> References: <20090601104323.8b0823960ceb6a56f7ddf638f99b00cb.58038477ef.wbe@email.secureserver.net> Message-ID: <105c09f0906011322k72d41996i95dd8e6aa5e852bc@mail.gmail.com> On Mon, Jun 1, 2009 at 12:43 PM, wrote: > I checked out the http-texture branch > from?http://svn.secondlife.com/svn/linden/projects/2009/http-texture/?using > TortoiseSVN. > > When I run develop.py I am getting many errors like those below: > > CMake Error: Cannot find source file > "D:/SL_SVN/indra/newview/character/attentionsN.xml" for target > "secondlife-bin" > Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp > .hxx .in .txx > > [snip] > > I looked in the /indra/newview/ path, and it appears that the /characters > folder is missing. > Did I check out the SVN code from the wrong place? The SVN repository only has the source code, so you'll also need to download the artwork and "libraries" packages. Rob Linden has been working on a script to automate the downloading and unpacking, so you could give that a try: http://jira.secondlife.com/browse/VWR-13787 Or for the manual way: the URLs for the packgaes are in doc/asset_urls.txt. You'll want to download the ones labelled as "SLASSET_ART" and "SLASSET_LIBS_WIN32". The zips have everything inside a "linden" folder, but you should move the stuff from inside the linden folder (doc, indra, LICENSE-*.txt) and put them in your SL_SVN folder instead. Hope that helps, - Jacek From robla at lindenlab.com Mon Jun 1 13:43:00 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 01 Jun 2009 13:43:00 -0700 Subject: [sldev] Repro help: VWR-13757 - Avatar rebaking problems Message-ID: <4A243D54.6020300@lindenlab.com> Hi folks, I'll send some mail later about the stability of the Snowglobe viewer and where we think we are generally, but in the meantime, a request. Check out this issue report: http://jira.secondlife.com/browse/VWR-13757 It's titled "Snowglobe: after re-logging a new user, avatar is invisible to others". However, based on some anecdotal data we have, it seems like a possible showstopper issue for our first Snowglobe release. Could folks here try reproing this problem, and see if you can come up with a solid repro case for this, perhaps narrowing down a number of variables (e.g. does this also happen in the 1.23 RC? how about 1.22?) We'd really like to either nail down the root cause of this issue, or at least figure out if it's a rare case. So, if you try to repro, and fail, a comment on VWR-13757 would be greatly appreciated. Thanks! Rob From robla at lindenlab.com Mon Jun 1 13:45:07 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 01 Jun 2009 13:45:07 -0700 Subject: [sldev] Recurring snowglobe crash In-Reply-To: <4A242696.20704@watson.ibm.com> References: <5A0F50DB-125E-49D8-9CAF-20253D0A7E14@lindenlab.com> <4A20890F.8080002@lindenlab.com><237828DB-4AC7-4B03-BB66-D41E9AE27EBC@lindenlab.com> <4A242696.20704@watson.ibm.com> Message-ID: <4A243DD3.7000806@lindenlab.com> Merov's got that second on his list of stuff to work on (top of his list being VWR-13505) Rob On 06/01/2009 12:05 PM, Mike Monkowski wrote: > I haven't got a crash with 2338 yet, but I still see the sculpty > messages. Did anyone go back and check for reverted merges in the > Linden http-texture branch (VWR-11815)? > > Mike > > Philippe Bossut (Merov Linden) wrote: > >> Hi, >> >> On May 29, 2009, at 6:17 PM, Steve Bennetts (Steve Linden) wrote: >> >> >>> Ah, yes... this could actually be valid, we should eliminate the assert. >>> I added it when I was trying to track down the problem and now >>> understand why it happens. (There is an early exit in >>> LLTextureFetchWorker::doWork() that can cause an abort while decoding. >>> This is desired behavior, and is safe.) >>> >>> I'll fix this in the internal http-texture branch >>> >> I did the same change in snowglobe (svn rev 2338), marked the bug fixed >> and started the builds. They completed with no errors and can be >> downloaded here: >> - >> Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2338/SecondLife-i686-1.23.2.2338.tar.bz2 >> - >> Mac: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2338/SecondLife_1_23_2_2338_OSS.dmg >> - >> Windows: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2338/Second_Life_1-23-2-2338_OSS_Setup.exe >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From carlo at alinoe.com Mon Jun 1 14:57:44 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 1 Jun 2009 23:57:44 +0200 Subject: [sldev] Repro help: VWR-13757 - Avatar rebaking problems In-Reply-To: <4A243D54.6020300@lindenlab.com> References: <4A243D54.6020300@lindenlab.com> Message-ID: <20090601215744.GA9687@alinoe.com> > It's titled "Snowglobe: after re-logging a new user, avatar is invisible > to others". However, based on some anecdotal data we have, it seems Looks like the effect of wearing the "cloud hair" that has been going around. However, in that case you look like smoke to yourself too. I don't know what the reason is that this 'cloudhair' makes one look like a cloud, but I can imagine it is because a null UUID is involved. Therefore, my guess would be that something went wrong where the server (the 'others') was under the impression that the his hair had this null UUID, which in turn could have been the result of some bug somewhere in which is should be reproducable, or a maybe a network quirk, in which case it won't be reproducable. -- Carlo Wood From tigrospottystripes at gmail.com Mon Jun 1 16:27:19 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Jun 2009 20:27:19 -0300 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it Message-ID: <4A2463D7.9050604@Gmail.com> they beat you too it, and did it big time http://www.youtube.com/watch?v=UkSV1rXJ0pU http://www.youtube.com/watch?v=B2r9cKjNQe4 I wish LL could buy it and then open the technology for everyone... From philip at lindenlab.com Mon Jun 1 17:40:38 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Mon, 01 Jun 2009 17:40:38 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2463D7.9050604@Gmail.com> References: <4A2463D7.9050604@Gmail.com> Message-ID: <4A247506.1000108@lindenlab.com> they are using a depth camera (basically a camera with pixel 'radar' that measures the distance to the image), which we have experimented with over a year ago (Merov worked with the same camera that is in the XBox). Using this camera will require every consumer to acquire a new piece of hardware that costs more than $100. Many of the same tricks can be done using a macbook or webcam, and that is what we are inspired about right now. It feels kind of rude to say "they beat you too it, and did it big time". P Tigro Spottystripes wrote: > they beat you too it, and did it big time > > http://www.youtube.com/watch?v=UkSV1rXJ0pU > http://www.youtube.com/watch?v=B2r9cKjNQe4 > > > I wish LL could buy it and then open the technology for everyone... > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From stickman at gmail.com Mon Jun 1 17:56:00 2009 From: stickman at gmail.com (Stickman) Date: Mon, 1 Jun 2009 17:56:00 -0700 Subject: [sldev] Snowglobe - Corrupt texture on animation preview model Message-ID: Just made a new Jira: http://jira.secondlife.com/browse/VWR-13803 It appears pinning the upload menu (File -> Upload -> "double bars" at the top) and snapping it to the upper left corner of the window will make the animation preview avatar sport a non-grey texture of some kind. 1.23RC2 doesn't seem to have this issue. Doesn't seem serious, but I figured I'd bring it up in case it's indicative of something larger and less visible. -Stickman From tigrospottystripes at gmail.com Mon Jun 1 18:03:50 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 01 Jun 2009 22:03:50 -0300 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A247506.1000108@lindenlab.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> Message-ID: <4A247A76.1050602@Gmail.com> I'm sorry, I didn't meant to be rude, it was just that it's basicly the same concepts and they have done an amaxing job from what I can see on the videos I got the impression they were using a stereoscopic camera, and not a camera that natively measures the distance of every pixel in a way separated from visible light capture, and they got the pupettering done with it and from what I saw on the videos, it is working quite well, while on that old video the guy just leans and moves the arms and such, and that is translated into somewhat completly unrelated outputs once again to clarify, I didn't meant to be rude nor offend anybody, I might have failed to expressmyself correctly and caused misunderstandings, but my original intentions were not anything negative. I got the impression they had managed to make several advancements using relatively cheap hardware while there are still discussions on SLDev on how to do very basic stuff I'm sorry if I upset anyone with my message, it wasn't my intention at all Philip Rosedale escreveu: > they are using a depth camera (basically a camera with pixel 'radar' > that measures the distance to the image), which we have experimented > with over a year ago (Merov worked with the same camera that is in the > XBox). Using this camera will require every consumer to acquire a > new piece of hardware that costs more than $100. Many of the same > tricks can be done using a macbook or webcam, and that is what we are > inspired about right now. > It feels kind of rude to say "they beat you too it, and did it big time". > > P > > Tigro Spottystripes wrote: >> they beat you too it, and did it big time >> >> http://www.youtube.com/watch?v=UkSV1rXJ0pU >> http://www.youtube.com/watch?v=B2r9cKjNQe4 >> >> >> I wish LL could buy it and then open the technology for everyone... >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From tom at streamsense.net Mon Jun 1 18:23:43 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue, 02 Jun 2009 02:23:43 +0100 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A247506.1000108@lindenlab.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> Message-ID: <4A247F1F.4060205@streamsense.net> But they did beat you to it... What's $100 when you're charging $200 a month for a quarter of a server? ~T Philip Rosedale wrote: > they are using a depth camera (basically a camera with pixel 'radar' > that measures the distance to the image), which we have experimented > with over a year ago (Merov worked with the same camera that is in the > XBox). Using this camera will require every consumer to acquire a new > piece of hardware that costs more than $100. Many of the same tricks > can be done using a macbook or webcam, and that is what we are inspired > about right now. > > It feels kind of rude to say "they beat you too it, and did it big time". > > P > > Tigro Spottystripes wrote: > >> they beat you too it, and did it big time >> >> http://www.youtube.com/watch?v=UkSV1rXJ0pU >> http://www.youtube.com/watch?v=B2r9cKjNQe4 >> >> >> I wish LL could buy it and then open the technology for everyone... >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From partners at scifipc.com Mon Jun 1 18:44:42 2009 From: partners at scifipc.com (=?us-ascii?Q?Science_Fiction_ComputerR_SCi-Fi_PCR?=) Date: Tue, 2 Jun 2009 11:44:42 +1000 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption In-Reply-To: <4A241603.1050403@lindenlab.com> References: <4A241603.1050403@lindenlab.com> Message-ID: Hi Rob, I've posted a comment on the JIRA (http://jira.secondlife.com/browse/VWR-13793) regarding testing to get Second Life running in openSUSE Linux on standardized AMD/ATI hardware. ATI has traditionally been seen as a less-preferred graphics solution in Second Life, however, my private startup company is both an AMD Solution Partner and in SL. I have already found myself offering graphics driver support to residents in-world with ATI graphics on several occasions. While residents try to get SL running on Linux boxes, is there any formal online help or support places to help them successfully do it - and not just for NVIDIA(R), but ATI as well... Any thoughts? DMC Zsigmond -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Rob Lanphier Sent: Tuesday, June 02, 2009 3:55 AM To: Second Life Developer Mailing List Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption I've been doing a little asking around about 32-bit vs 64-bit Linux desktop adoption, and got the following mail. Based on one reasonably current estimate, 64-bit adoption is running at about 24.6%. I filed a feature request in JIRA as a place to gather up conversation on this topic: http://jira.secondlife.com/browse/VWR-13793 If you have other sources of data, please post them there. Thanks! Rob -------- Original Message -------- Subject: Re: [Lf_desktop] Hard numbers on 32-bit vs 64-bit Linux desktop adoption Date: Sun, 31 May 2009 23:13:37 -0700 From: Donnie Berkholz To: Rob Lanphier CC: lf_desktop at lists.linux-foundation.org On 21:15 Sun 31 May , Rob Lanphier wrote: > Hi all, > > I work on the Second Life viewer, which we make available for Linux > desktop users. One thing I've been doing a little searching around > for is hard numbers on 32-bit vs 64-bit OS adoption among desktop > users. If we could get a sense of the current share and trajectory, > that would help us plan for the shift. > > Any idea where to dig that kind of thing up? To get numbers for Fedora, I went to the Smolt page and clicked "Host based statistics" . Arch Count % of total i686 177386 75.0 % x86_64 58125 24.6 % I think Smolt is opt-in at the end of the installation process. -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.49/2149 - Release Date: 06/01/09 17:55:00 From darmath at tpg.com.au Mon Jun 1 18:45:49 2009 From: darmath at tpg.com.au (Darmath) Date: Tue, 02 Jun 2009 11:45:49 +1000 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A247F1F.4060205@streamsense.net> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> Message-ID: <4A24844D.7040002@tpg.com.au> Thank you for posting the video links...I'm a university student in a non computer related, and very time consuming, field and often find myself getting out of touch with gaming and comptuer related news. All I can is OMG I love it and I'm so glad i finally bought myself an XBox 360 earlier this year! Thomas Grimshaw wrote: > But they did beat you to it... > > What's $100 when you're charging $200 a month for a quarter of a server? > > ~T > > Philip Rosedale wrote: > >> they are using a depth camera (basically a camera with pixel 'radar' >> that measures the distance to the image), which we have experimented >> with over a year ago (Merov worked with the same camera that is in the >> XBox). Using this camera will require every consumer to acquire a new >> piece of hardware that costs more than $100. Many of the same tricks >> can be done using a macbook or webcam, and that is what we are inspired >> about right now. >> >> It feels kind of rude to say "they beat you too it, and did it big time". >> >> P >> >> Tigro Spottystripes wrote: >> >> >>> they beat you too it, and did it big time >>> >>> http://www.youtube.com/watch?v=UkSV1rXJ0pU >>> http://www.youtube.com/watch?v=B2r9cKjNQe4 >>> >>> >>> I wish LL could buy it and then open the technology for everyone... >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > > > From secret.argent at gmail.com Mon Jun 1 19:13:47 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 1 Jun 2009 21:13:47 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A247F1F.4060205@streamsense.net> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> Message-ID: On 2009-06-01, at 20:23, Thomas Grimshaw wrote: > What's $100 when you're charging $200 a month for a quarter of a > server? Not everyone has or can afford a sim. From snowfox102 at dragonkeepcreations.com Mon Jun 1 20:42:50 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Mon, 01 Jun 2009 22:42:50 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A247F1F.4060205@streamsense.net> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> Message-ID: <4A249FBA.308@dragonkeepcreations.com> Eh. Yeah it's cool, yeah it's great for games made to use it. Me, though? Ain't no way I could play Phantasy Star Universe, or Katamari Damacy, or MOTHER3 with that. Besides, I'd collapse from exhaustion after about ten seconds anyway. So I don't see the relevance to SL, I'd never use it even if I could afford it. How would it handle flying anyway? ;) Also: Thomas Grimshaw wrote: > But they did beat you to it... > > What's $100 when you're charging $200 a month for a quarter of a server? > > ~T > Ooh, burn. ;P Maya From tigrospottystripes at gmail.com Mon Jun 1 20:58:36 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 02 Jun 2009 00:58:36 -0300 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A249FBA.308@dragonkeepcreations.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> Message-ID: <4A24A36C.503@Gmail.com> my main use for it probably would be puppetering of the avatar, at least above waist since I don't like standing up all that much, but I imagine this can be expanded to many uses, like the example on one of the vids, driving vehicles without any special controlers, and with a bit of cooperation of the coders, this could even help to provide in-world animation RECORDING, you would be able to turn your own room into a mocap studio with just SL and a little gadget, and you would be able to get live preview on the very avatar you intend to use the anim on (in the cases where a anim is meant for a specific avatar isntead of being a generic anim) I hope when that thing hits the stores it will cost at most about as much as a Wiimote and got a easy way to interface with regular PCs (isn't the XBox basicly a PC with some purpose built hardware and it's own unique OS partially inspired by Windows and the DirectX tech?) Maya Remblai escreveu: > Eh. Yeah it's cool, yeah it's great for games made to use it. Me, > though? Ain't no way I could play Phantasy Star Universe, or Katamari > Damacy, or MOTHER3 with that. Besides, I'd collapse from exhaustion > after about ten seconds anyway. So I don't see the relevance to SL, I'd > never use it even if I could afford it. How would it handle flying > anyway? ;) > > Also: > > Thomas Grimshaw wrote: > >> But they did beat you to it... >> >> What's $100 when you're charging $200 a month for a quarter of a server? >> >> ~T >> >> > Ooh, burn. ;P > > Maya > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From dmahalko at gmail.com Mon Jun 1 21:15:58 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon, 1 Jun 2009 23:15:58 -0500 Subject: [sldev] media on the clothes In-Reply-To: <4A22CCD9.7080509@Gmail.com> References: <4A22CCD9.7080509@Gmail.com> Message-ID: Wait, what? Are you able to wear an active animated movie stream, or is just a single frame captured out of the stream when it bakes? - Dale Mahalko / Scalar Tardis On Sun, May 31, 2009 at 1:30 PM, Tigro Spottystripes wrote: > Is it still possible to wear the land media stream by setting the > texture to be replaced as one of the textures used for clothes of the > av, playing the media stream and rebaking? From tigrospottystripes at gmail.com Mon Jun 1 21:40:35 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 02 Jun 2009 01:40:35 -0300 Subject: [sldev] media on the clothes In-Reply-To: References: <4A22CCD9.7080509@Gmail.com> Message-ID: <4A24AD43.6030607@Gmail.com> I don't remember if it was live before baking, but after baking it's just a single frame captured at the moment of baking Dale Mahalko escreveu: > Wait, what? Are you able to wear an active animated movie stream, or > is just a single frame captured out of the stream when it bakes? > > - Dale Mahalko / Scalar Tardis > > > On Sun, May 31, 2009 at 1:30 PM, Tigro Spottystripes > wrote: > >> Is it still possible to wear the land media stream by setting the >> texture to be replaced as one of the textures used for clothes of the >> av, playing the media stream and rebaking? >> > > From merov at lindenlab.com Mon Jun 1 23:51:22 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Mon, 1 Jun 2009 23:51:22 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A24A36C.503@Gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> Message-ID: Hi, As Philip said, this is the 3DV camera (MS acquired 3DV end of 2008) and most of those demos have been seen before at Game Developer Conferences and others since a couple of years now. The best one I've seen (and experimented myself) was made by Softkinetic (http://www.softkinetic.net/ ). Awesome feeling! But that needed pretty careful setting and calibration. Also note that the videos by MS are *not* demos (i.e. live effective code) but staged shooting. One big issue so far with those systems (especially the 3DV camera based on TOF technology, something similar to Lidar) is the ambient noise you get in a real life busy setting. With Lidar in particular the presence of a reflective surface in the field of view screws up the reading big time. If your room is a little crowded, getting the background out is not always easy and mixing several people gets you into interesting tracking problems... Plus, one very interesting and SL specific problem is "rigging": if you want the movements to be representing yourself (and not just knocking off stuff on screen), meaningful rigging is pretty hard as you need to track every joint (relying on FP/IK for untracked joint like in puppeteering gives weird results... I tried...) and you need to remap positions to keep the respective positions of end points correct (just using the quaternions for each joint for instance won't guarantee that your hands will end up on your head if you take that position in front of the camera, as small bone length differences between your skeleton and the avatar's skeleton will translate in different end positions). Keeping an expressive avatar is actually harder than just using your body as a joystick in a game (which expressivity is limited). This is a challenge they won't even try to stand up for I think (irrelevant for games) but that's very important for SL (assuming we want full body tracking one day). Well, all that to say that, no, "they" haven't beaten us to it yet. Cheers, - Merov On Jun 1, 2009, at 8:58 PM, Tigro Spottystripes wrote: > my main use for it probably would be puppetering of the avatar, at > least > above waist since I don't like standing up all that much, but I > imagine > this can be expanded to many uses, like the example on one of the > vids, > driving vehicles without any special controlers, and with a bit of > cooperation of the coders, this could even help to provide in-world > animation RECORDING, you would be able to turn your own room into a > mocap studio with just SL and a little gadget, and you would be able > to > get live preview on the very avatar you intend to use the anim on (in > the cases where a anim is meant for a specific avatar isntead of > being a > generic anim) > > > I hope when that thing hits the stores it will cost at most about as > much as a Wiimote and got a easy way to interface with regular PCs > (isn't the XBox basicly a PC with some purpose built hardware and it's > own unique OS partially inspired by Windows and the DirectX tech?) > > Maya Remblai escreveu: >> Eh. Yeah it's cool, yeah it's great for games made to use it. Me, >> though? Ain't no way I could play Phantasy Star Universe, or Katamari >> Damacy, or MOTHER3 with that. Besides, I'd collapse from exhaustion >> after about ten seconds anyway. So I don't see the relevance to SL, >> I'd >> never use it even if I could afford it. How would it handle flying >> anyway? ;) >> >> Also: >> >> Thomas Grimshaw wrote: >> >>> But they did beat you to it... >>> >>> What's $100 when you're charging $200 a month for a quarter of a >>> server? >>> >>> ~T >>> >>> >> Ooh, burn. ;P >> >> Maya >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tigrospottystripes at gmail.com Tue Jun 2 00:01:55 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 02 Jun 2009 04:01:55 -0300 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> Message-ID: <4A24CE63.5010705@Gmail.com> oh, wow, they really tricked me with those vids :/ so the interactions on those videos were all faked then? that sucks :( do you know of anywhere I can see true proof of concepts/working prototypes of that system or similar? (I mean, besides that video of the "segway control system" for SL) Philippe Bossut (Merov Linden) escreveu: > Hi, > > As Philip said, this is the 3DV camera (MS acquired 3DV end of 2008) > and most of those demos have been seen before at Game Developer > Conferences and others since a couple of years now. The best one I've > seen (and experimented myself) was made by Softkinetic (http://www.softkinetic.net/ > ). Awesome feeling! But that needed pretty careful setting and > calibration. Also note that the videos by MS are *not* demos (i.e. > live effective code) but staged shooting. > > One big issue so far with those systems (especially the 3DV camera > based on TOF technology, something similar to Lidar) is the ambient > noise you get in a real life busy setting. With Lidar in particular > the presence of a reflective surface in the field of view screws up > the reading big time. If your room is a little crowded, getting the > background out is not always easy and mixing several people gets you > into interesting tracking problems... > > Plus, one very interesting and SL specific problem is "rigging": if > you want the movements to be representing yourself (and not just > knocking off stuff on screen), meaningful rigging is pretty hard as > you need to track every joint (relying on FP/IK for untracked joint > like in puppeteering gives weird results... I tried...) and you need > to remap positions to keep the respective positions of end points > correct (just using the quaternions for each joint for instance won't > guarantee that your hands will end up on your head if you take that > position in front of the camera, as small bone length differences > between your skeleton and the avatar's skeleton will translate in > different end positions). Keeping an expressive avatar is actually > harder than just using your body as a joystick in a game (which > expressivity is limited). This is a challenge they won't even try to > stand up for I think (irrelevant for games) but that's very important > for SL (assuming we want full body tracking one day). > > Well, all that to say that, no, "they" haven't beaten us to it yet. > > Cheers, > - Merov > > On Jun 1, 2009, at 8:58 PM, Tigro Spottystripes wrote: > > >> my main use for it probably would be puppetering of the avatar, at >> least >> above waist since I don't like standing up all that much, but I >> imagine >> this can be expanded to many uses, like the example on one of the >> vids, >> driving vehicles without any special controlers, and with a bit of >> cooperation of the coders, this could even help to provide in-world >> animation RECORDING, you would be able to turn your own room into a >> mocap studio with just SL and a little gadget, and you would be able >> to >> get live preview on the very avatar you intend to use the anim on (in >> the cases where a anim is meant for a specific avatar isntead of >> being a >> generic anim) >> >> >> I hope when that thing hits the stores it will cost at most about as >> much as a Wiimote and got a easy way to interface with regular PCs >> (isn't the XBox basicly a PC with some purpose built hardware and it's >> own unique OS partially inspired by Windows and the DirectX tech?) >> >> Maya Remblai escreveu: >> >>> Eh. Yeah it's cool, yeah it's great for games made to use it. Me, >>> though? Ain't no way I could play Phantasy Star Universe, or Katamari >>> Damacy, or MOTHER3 with that. Besides, I'd collapse from exhaustion >>> after about ten seconds anyway. So I don't see the relevance to SL, >>> I'd >>> never use it even if I could afford it. How would it handle flying >>> anyway? ;) >>> >>> Also: >>> >>> Thomas Grimshaw wrote: >>> >>> >>>> But they did beat you to it... >>>> >>>> What's $100 when you're charging $200 a month for a quarter of a >>>> server? >>>> >>>> ~T >>>> >>>> >>>> >>> Ooh, burn. ;P >>> >>> Maya >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From chaosstar at gmail.com Tue Jun 2 02:17:26 2009 From: chaosstar at gmail.com (Ambrosia) Date: Tue, 2 Jun 2009 11:17:26 +0200 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <20090601130435.GA27798@alinoe.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> <4d211a610905281809i23924c88o64a9aa17c2bd6e39@mail.gmail.com> <4a1f5057.1e068e0a.01f5.5bdb@mx.google.com> <20090529111801.GB23852@alinoe.com> <4A200686.2020906@dragonkeepcreations.com> <4A23C3A1.8020405@boroon.dasgupta.ch> <20090601130435.GA27798@alinoe.com> Message-ID: <9bb32d430906020217p2210ae58w63b24902a02aa385@mail.gmail.com> Personally I have given up on boost hell and VS express 2008 a while ago. It just was too frustrating, too kludgy-hacky, and the fixes on the wiki just brought up new errors. VS 2005 worked, as usual, flawlessy, as does the Linux build. Given that VS Express 2005 isn't even offered for download anymore, and even VS 2005 is going the way of the Dodo, and VS 2010 being in beta soon..I think it might be time to update the included boost libs, and end that nightmare. From carlo at alinoe.com Tue Jun 2 05:49:43 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 2 Jun 2009 14:49:43 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> Message-ID: <20090602124943.GA14868@alinoe.com> On Mon, Jun 01, 2009 at 11:51:22PM -0700, Philippe Bossut (Merov Linden) wrote: > calibration. Also note that the videos by MS are *not* demos (i.e. > live effective code) but staged shooting. I didn't want to mention that... but I bet that those videos are plain FAKE. Those are actors that trained to do those movements, and had to redo them many times before they got it to look a bit realistic (and still fail). I'm sure they got something to work, but those videos are not prove of how it will feel or be in reality imho. Big companies have managers that make the decision: we want this product, it should do this and that by then and then; We will need advertisement and awareness: make a video that shows this and that. And then leave it to the techs to make that video. If the product simply can't deliver (yet), all means are allowed to make the video anyway. -- Carlo Wood From soft at lindenlab.com Tue Jun 2 06:09:21 2009 From: soft at lindenlab.com (Soft) Date: Tue, 2 Jun 2009 08:09:21 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <20090602124943.GA14868@alinoe.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <20090602124943.GA14868@alinoe.com> Message-ID: On Tue, Jun 2, 2009 at 7:49 AM, Carlo Wood wrote: > On Mon, Jun 01, 2009 at 11:51:22PM -0700, Philippe Bossut (Merov Linden) wrote: >> calibration. Also note that the videos by MS are *not* demos (i.e. >> live effective code) but staged shooting. > > I didn't want to mention that... but I bet that those videos are > plain FAKE. Those are actors that trained to do those movements, > and had to redo them many times before they got it to look a bit > realistic (and still fail). > > I'm sure they got something to work, but those videos are not > prove of how it will feel or be in reality imho. The first is labeled as a conceptualization (lower left toward the start). The second video looks realistic to me. Note the lag and wobbly positioning. They're not bad, but the first video would make one think that MS had solved some problems usually solved with a bunch of high precision cameras and dozens of infrared markers. From mitch at mckenzie.ws Tue Jun 2 06:37:15 2009 From: mitch at mckenzie.ws (mitch at mckenzie.ws) Date: Tue, 02 Jun 2009 08:37:15 -0500 Subject: [sldev] media on the clothes In-Reply-To: References: <4A22CCD9.7080509@Gmail.com> Message-ID: <4A252B0B.2090308@mckenzie.ws> You can wear media streams just fine.. Back in the days that Veodia Supported SL streams, my blockheads technology could stream a live feed of your realtime, real motion video of your mug onto your avatars head for all to see.... Media Hax Dale Mahalko wrote: > Wait, what? Are you able to wear an active animated movie stream, or > is just a single frame captured out of the stream when it bakes? > > - Dale Mahalko / Scalar Tardis > > > On Sun, May 31, 2009 at 1:30 PM, Tigro Spottystripes > wrote: > >> Is it still possible to wear the land media stream by setting the >> texture to be replaced as one of the textures used for clothes of the >> av, playing the media stream and rebaking? >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > > From ron at involve3d.com Tue Jun 2 08:02:20 2009 From: ron at involve3d.com (Ron Blechner) Date: Tue, 2 Jun 2009 11:02:20 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <20090602124943.GA14868@alinoe.com> Message-ID: Remember Microsoft Table? *grin* Whether the videos were demos ("fake") or whether they were proof of concept but functional, one thing I haven't seen pointed out is that the videos are filmed in a giant living room. I enjoy playing Wii games, which require 6 - 8 feet or so of space, and I'll quietly gripe about having to move a piece of furniture to get proper Wii bowling space. We all dream of the future "Virtual reality room" (a la Fahrenheit 451 or Star Trek: TNG) where the entire room is your entertainment space, but let's face it - this is a pretty high-end solution for short periods of simulation. Would you want to be standing up and using Second Life for more than half an hour? An hour, perhaps, if you're at a dance club maybe? Second Life is not a game platform; it's a 3-D metaverse platform. The distinction being that it's meant for a broader variety of uses, and doesn't have the optimizations and features that a strong game platform would really require. We don't generally log onto Second Life to go play soccer or space invaders; we log on to socialize, check out immersive educational and marketing spaces, to create, etc. And we do them all in this social, multi-user environment. This is key. Facial expressions and simple gestures are far, far more important than full-body simulation. Our common interactions in-world won't be enhanced a whole lot by being able to accurately show how badly I can dance in meatspace. It will, however, be greatly enhanced if my facial expressions can be simply translated to my avatar. It's this immersion building and person-to-person communication that's so key. And that's why I cheer on Philip when he notes: "Many of the same tricks can be done using a macbook or webcam, and that is what we are inspired about right now." Focusing on developing tech when a person is *sitting down* at their desk and from the shoulders up is absolutely a benefit-rich area to focus development on. I've encouraged Linden Lab, blogged about it, and will continue to wave the banner for this technology and implementation with Second Life. Regards, Ron / Hiro -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com On Tue, Jun 2, 2009 at 9:09 AM, Soft wrote: > On Tue, Jun 2, 2009 at 7:49 AM, Carlo Wood wrote: >> On Mon, Jun 01, 2009 at 11:51:22PM -0700, Philippe Bossut (Merov Linden) wrote: >>> calibration. Also note that the videos by MS are *not* demos (i.e. >>> live effective code) but staged shooting. >> >> I didn't want to mention that... but I bet that those videos are >> plain FAKE. Those are actors that trained to do those movements, >> and had to redo them many times before they got it to look a bit >> realistic (and still fail). >> >> I'm sure they got something to work, but those videos are not >> prove of how it will feel or be in reality imho. > > The first is labeled as a conceptualization (lower left toward the > start). The second video looks realistic to me. Note the lag and > wobbly positioning. They're not bad, but the first video would make > one think that MS had solved some problems usually solved with a bunch > of high precision cameras and dozens of infrared markers. > _______________________________________________ > Policies and (un)subscribe information available here:> http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From merov at lindenlab.com Tue Jun 2 08:23:51 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 2 Jun 2009 08:23:51 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com><4A247F1F.4060205@streamsense.net><4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com><20090602124943.GA14868@alinoe.com> Message-ID: +1 on everything you said Ron. Spot on. On the 6-8 feet of space, this is indeed a critical technical aspect of all those demos. Making the 3D reading work in the crammed space of a typical cubicle setting is very challenging. Cheers, - Merov On Jun 2, 2009, at 8:02 AM, Ron Blechner wrote: > Remember Microsoft Table? *grin* > > Whether the videos were demos ("fake") or whether they were proof of > concept but functional, one thing I haven't seen pointed out is that > the videos are filmed in a giant living room. I enjoy playing Wii > games, which require 6 - 8 feet or so of space, and I'll quietly gripe > about having to move a piece of furniture to get proper Wii bowling > space. We all dream of the future "Virtual reality room" (a la > Fahrenheit 451 or Star Trek: TNG) where the entire room is your > entertainment space, but let's face it - this is a pretty high-end > solution for short periods of simulation. Would you want to be > standing up and using Second Life for more than half an hour? An hour, > perhaps, if you're at a dance club maybe? > > Second Life is not a game platform; it's a 3-D metaverse platform. The > distinction being that it's meant for a broader variety of uses, and > doesn't have the optimizations and features that a strong game > platform would really require. We don't generally log onto Second Life > to go play soccer or space invaders; we log on to socialize, check out > immersive educational and marketing spaces, to create, etc. And we do > them all in this social, multi-user environment. This is key. > > Facial expressions and simple gestures are far, far more important > than full-body simulation. Our common interactions in-world won't be > enhanced a whole lot by being able to accurately show how badly I can > dance in meatspace. It will, however, be greatly enhanced if my facial > expressions can be simply translated to my avatar. It's this immersion > building and person-to-person communication that's so key. And that's > why I cheer on Philip when he notes: "Many of the same tricks can be > done using a macbook or webcam, and that is what we are inspired about > right now." Focusing on developing tech when a person is *sitting > down* at their desk and from the shoulders up is absolutely a > benefit-rich area to focus development on. I've encouraged Linden Lab, > blogged about it, and will continue to wave the banner for this > technology and implementation with Second Life. > > Regards, > > Ron / Hiro > > -- > Ron Blechner > Chief Technology Officer > Involve, Inc > www.involve3d.com > > > > > On Tue, Jun 2, 2009 at 9:09 AM, Soft wrote: >> On Tue, Jun 2, 2009 at 7:49 AM, Carlo Wood wrote: >>> On Mon, Jun 01, 2009 at 11:51:22PM -0700, Philippe Bossut (Merov >>> Linden) wrote: >>>> calibration. Also note that the videos by MS are *not* demos (i.e. >>>> live effective code) but staged shooting. >>> >>> I didn't want to mention that... but I bet that those videos are >>> plain FAKE. Those are actors that trained to do those movements, >>> and had to redo them many times before they got it to look a bit >>> realistic (and still fail). >>> >>> I'm sure they got something to work, but those videos are not >>> prove of how it will feel or be in reality imho. >> >> The first is labeled as a conceptualization (lower left toward the >> start). The second video looks realistic to me. Note the lag and >> wobbly positioning. They're not bad, but the first video would make >> one think that MS had solved some problems usually solved with a >> bunch >> of high precision cameras and dozens of infrared markers. >> _______________________________________________ >> Policies and (un)subscribe information available here:> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From lenglish5 at cox.net Tue Jun 2 08:46:54 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 02 Jun 2009 08:46:54 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com><4A247F1F.4060205@streamsense.net><4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com><20090602124943.GA14868@alinoe.com> Message-ID: <4A25496E.5000607@cox.net> Philippe Bossut (Merov Linden) wrote: > +1 on everything you said Ron. Spot on. > > On the 6-8 feet of space, this is indeed a critical technical aspect > of all those demos. Making the 3D reading work in the crammed space of > a typical cubicle setting is very challenging. > > In that context, I think that Apple's new patent for a distributed camera embedded in the video screen has far more potential. Can't grok the math for the optics involved, but my intuition says that near-distance mo-cap and gesture/facial-recognition will, in the long run at least, be better-handled by a camera whose aperture is measured in dozens of inches. It may not work as well at living room distances, but for cubicals and mobile phones I think it will be more useful. http://www.newscientist.com/article/dn9059-invention-apples-allseeing-screen.html http://www.pat2pdf.org/pat2pdf/foo.pl?number=20080297487 (autogenerated PDF takes forever) OR: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220060007222%22.PGNR.&OS=DN/20060007222&RS=DN/20060007222 http://aiw1.uspto.gov:80/.aiw?Docid=20060007222&homeurl=http%3A%2F%2Fappft1.uspto.gov%2Fnetacgi%2Fnph-Parser%3FSect1%3DPTO1%2526Sect2%3DHITOFF%2526d%3DPG01%2526p%3D1%2526u%3D%25252Fnetahtml%25252FPTO%25252Fsrchnum.html%2526r%3D1%2526f%3DG%2526l%3D50%2526s1%3D%25252220060007222%252522.PGNR.%2526OS%3DDN%2F20060007222%2526RS%3DDN%2F20060007222&PageNum=&Rtype=&SectionNum=&idkey=10BA1EE90563 Lawson From robla at lindenlab.com Tue Jun 2 10:37:55 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 02 Jun 2009 10:37:55 -0700 Subject: [sldev] PLEASE READ Re: Repro help: VWR-13757 - Avatar rebaking problems In-Reply-To: <4A243D54.6020300@lindenlab.com> References: <4A243D54.6020300@lindenlab.com> Message-ID: <4A256373.9040004@lindenlab.com> Hi folks, I'm hoping this doesn't get lost in the chatter. This is important. Rob On 06/01/2009 01:43 PM, Rob Lanphier wrote: > Hi folks, > > I'll send some mail later about the stability of the Snowglobe viewer > and where we think we are generally, but in the meantime, a request. > > Check out this issue report: > http://jira.secondlife.com/browse/VWR-13757 > > It's titled "Snowglobe: after re-logging a new user, avatar is invisible > to others". However, based on some anecdotal data we have, it seems > like a possible showstopper issue for our first Snowglobe release. > > Could folks here try reproing this problem, and see if you can come up > with a solid repro case for this, perhaps narrowing down a number of > variables (e.g. does this also happen in the 1.23 RC? how about 1.22?) > We'd really like to either nail down the root cause of this issue, or at > least figure out if it's a rare case. So, if you try to repro, and > fail, a comment on VWR-13757 would be greatly appreciated. > > Thanks! > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From jpirkola at gmail.com Tue Jun 2 10:50:09 2009 From: jpirkola at gmail.com (Jani Pirkola) Date: Tue, 2 Jun 2009 20:50:09 +0300 Subject: [sldev] META: Poll: Your favorite virtual world (platform)? Message-ID: <6c9557390906021050m3739f89fwa99b397136d3cdad@mail.gmail.com> Hi, I am running a poll at http://www.polladium.com/poll.php?poll_id=1&location_id=25227 to get an idea what people are using and to gather some valuable comments along the way. Please join and cast a vote! I will write an article about the results to http://maxping.org Thanks, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090602/6b80ed97/attachment-0001.htm From stickman at gmail.com Tue Jun 2 10:54:09 2009 From: stickman at gmail.com (Stickman) Date: Tue, 2 Jun 2009 10:54:09 -0700 Subject: [sldev] META: Poll: Your favorite virtual world (platform)? In-Reply-To: <6c9557390906021050m3739f89fwa99b397136d3cdad@mail.gmail.com> References: <6c9557390906021050m3739f89fwa99b397136d3cdad@mail.gmail.com> Message-ID: This is the third "META" email I've gotten from Jani since I subscribed. This one makes the least amount of sense. -Stickman On Tue, Jun 2, 2009 at 10:50 AM, Jani Pirkola wrote: > Hi, > I am running a poll > at?http://www.polladium.com/poll.php?poll_id=1&location_id=25227 > to get an idea what people are using and to gather some valuable comments > along the way. Please join and cast a vote! > I will write an article about the results to http://maxping.org > Thanks, > Jani > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From feilen1000 at gmail.com Tue Jun 2 09:55:29 2009 From: feilen1000 at gmail.com (Feilen) Date: Tue, 02 Jun 2009 11:55:29 -0500 Subject: [sldev] Custom bump map and specular mapping? Message-ID: <4A255981.1030504@gmail.com> I saw with the integration of Shadow Draft that specular accompaniment to bump maps was finally supported, and in my opinion that was the highlight of the shadow-draft branch. However, would it be possible to enable specular mapping without deferred rendering, as a regular feature? Also, another problem with the bump map in general is that there are only a set amount of bump maps that can be applied, which does not allow for user bump maps. Would it be possible to implement this as well? It could easily be placed in an 'Advanced Lighting' section of the texture map, and would make a great stride to making SL more like modern graphics computing, without forcing those with less powerful computers to render it. From brad.king at kitware.com Tue Jun 2 12:02:34 2009 From: brad.king at kitware.com (Brad King) Date: Tue, 02 Jun 2009 15:02:34 -0400 Subject: [sldev] http-texture merged into easybuild-2 Message-ID: <4A25774A.9070709@kitware.com> Hi Folks, For those interested in the 'easybuild' work, I've merged the latest http-texture branch revision (as of r2344) into the easybuild-2 branch: http://svn.secondlife.com/trac/linden/changeset/2345/projects/2009/easybuild-2 This allows the Snowglobe rebranding to be built with easybuild features. -Brad From melinda at superliminal.com Tue Jun 2 12:37:28 2009 From: melinda at superliminal.com (Melinda Green) Date: Tue, 02 Jun 2009 12:37:28 -0700 Subject: [sldev] META: Poll: Your favorite virtual world (platform)? In-Reply-To: References: <6c9557390906021050m3739f89fwa99b397136d3cdad@mail.gmail.com> Message-ID: <4A257F78.1000404@superliminal.com> It also requires you to register but only tells you that *after* you've composed your comments. How annoying! Stickman wrote: > This is the third "META" email I've gotten from Jani since I > subscribed. This one makes the least amount of sense. > > -Stickman > > On Tue, Jun 2, 2009 at 10:50 AM, Jani Pirkola wrote: > >> Hi, >> I am running a poll >> at http://www.polladium.com/poll.php?poll_id=1&location_id=25227 >> to get an idea what people are using and to gather some valuable comments >> along the way. Please join and cast a vote! >> I will write an article about the results to http://maxping.org >> Thanks, >> Jani > > From robla at lindenlab.com Tue Jun 2 13:34:37 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 02 Jun 2009 13:34:37 -0700 Subject: [sldev] Merging easybuild-2 into Snowglobe (Re: http-texture merged into easybuild-2) In-Reply-To: <4A25774A.9070709@kitware.com> References: <4A25774A.9070709@kitware.com> Message-ID: <4A258CDD.5010002@lindenlab.com> Hi folks, Having played around with this myself, I've found this easier to use. We just ran a test and found out that we have some build farm upgrades to do (CMake 2.6.2+ will be required for this, and we have at least one platform that we're only on 2.4.8 at the moment). After that, we're very, very seriously considering merging this in for the first version of Snowglobe, perhaps as early as later today (but probably more like tomorrow). If you'd like to stop this train, now is your chance. If you can give easybuild-2 a shot, we'd appreciate the feedback on how it works on your platform. Thanks Rob On 06/02/2009 12:02 PM, Brad King wrote: > Hi Folks, > > For those interested in the 'easybuild' work, I've merged the latest > http-texture branch revision (as of r2344) into the easybuild-2 branch: > > http://svn.secondlife.com/trac/linden/changeset/2345/projects/2009/easybuild-2 > > This allows the Snowglobe rebranding to be built with easybuild features. > > -Brad > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From stickman at gmail.com Tue Jun 2 14:14:42 2009 From: stickman at gmail.com (Stickman) Date: Tue, 2 Jun 2009 14:14:42 -0700 Subject: [sldev] Custom bump map and specular mapping? In-Reply-To: <4A255981.1030504@gmail.com> References: <4A255981.1030504@gmail.com> Message-ID: > feature? Also, another problem with the bump map in general is that > there are only a set amount of bump maps that can be applied, ?which > does not allow for user bump maps. Would it be possible to implement > this as well? Custom bump maps Jira opened about two years ago: http://jira.secondlife.com/browse/VWR-1155 Nyx Linden seems to be a public-facing Linden that deals with client rendering stuff. You could show up at their office hours to get some direct answers to questions or propose things. If nothing else, they can point you in the right direction. Last time I was there I heard wishes about a full materials systems. Don't know if that was a dream or what, but the very idea is awesome. Good luck! -Stickman From jan.ciger at gmail.com Tue Jun 2 14:21:17 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Tue, 02 Jun 2009 23:21:17 +0200 Subject: [sldev] PLEASE READ Re: Repro help: VWR-13757 - Avatar rebaking problems In-Reply-To: <4A256373.9040004@lindenlab.com> References: <4A243D54.6020300@lindenlab.com> <4A256373.9040004@lindenlab.com> Message-ID: <4A2597CD.6050904@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Lanphier wrote: > Hi folks, > > I'm hoping this doesn't get lost in the chatter. This is important. > I recall the same thing being reported with stock 1.23 release candidate. I am using Henri's CoolViewer and the textures do not get rebaked correctly at login neither - the avatar has only attachments visible, but not head, or the textures are messed up. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKJZfKn11XseNj94gRAq2fAKDkxzMhDG7Oy7uJ5OebVj8FkA0DGACcDPDr ajtKx1PsqEgfpXgi6wNl70o= =BVcF -----END PGP SIGNATURE----- From monkowsk at watson.ibm.com Tue Jun 2 15:03:15 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 02 Jun 2009 18:03:15 -0400 Subject: [sldev] Merging easybuild-2 into Snowglobe (Re: http-texture merged into easybuild-2) In-Reply-To: <4A258CDD.5010002@lindenlab.com> References: <4A25774A.9070709@kitware.com> <4A258CDD.5010002@lindenlab.com> Message-ID: <4A25A1A3.40603@watson.ibm.com> Rob Lanphier wrote: > If you can give easybuild-2 a shot, we'd appreciate the > feedback on how it works on your platform. Where would I find the documentation on how to use it? Mike From sllists at boroon.dasgupta.ch Tue Jun 2 15:28:13 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 03 Jun 2009 00:28:13 +0200 Subject: [sldev] Merging easybuild-2 into Snowglobe (Re: http-texture merged into easybuild-2) In-Reply-To: <4A25A1A3.40603@watson.ibm.com> References: <4A25774A.9070709@kitware.com> <4A258CDD.5010002@lindenlab.com> <4A25A1A3.40603@watson.ibm.com> Message-ID: <4A25A77D.6040809@boroon.dasgupta.ch> Mike Monkowski schrieb: > Rob Lanphier wrote: > >> If you can give easybuild-2 a shot, we'd appreciate the >> feedback on how it works on your platform. >> > > Where would I find the documentation on how to use it? at https://lists.secondlife.com/pipermail/sldev/2009-May/013941.html cheers Boroondas From infinity at lindenlab.com Tue Jun 2 15:51:40 2009 From: infinity at lindenlab.com (Infinity Linden) Date: Tue, 2 Jun 2009 15:51:40 -0700 Subject: [sldev] OGPX Request for Participation Message-ID: <3a880e2c0906021551l76476e51j7af261d62e2f41e8@mail.gmail.com> Some people might have heard that Open Grid Protocol (OGP) standardization efforts have been proceeding under the auspices of the IETF (Internet Engineering Task Force.) Last spring we formed the MMOX mailing list and BoF (Birds of a Feather) session to discuss standardization efforts across a number of different virtual worlds technology. At the MMOX BoF, a smaller number of people indicated an interest in focusing on the "second life-like" worlds currently deployed / described by Second Life(tm), OpenSim, PyOGP and RealXtend (to name a few.) The objective of this new group, called OGPX, is to define use cases, interoperability profiles and protocol for OGP. The mailing list for this group, ogpx at ietf.org, is open and anyone may participate (though we ask that discussion be limited to OGP and related topics; the MMOX list is still active for the purpose of more general VW standardization discussions.) You can subscribe to the OGPX list by visiting https://www.ietf.org/mailman/listinfo/ogpx . Current discussion topics include Reverse HTTP (RHTTP), LLSD / LLIDL and OGP. So... if you're interested in what's going on in OGP, this is the place to find out. Readers may also be interested in the set of published internet drafts: * OGP : Intro and Requirements ( http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 ) * LLSD / LLIDL ( http://www.ietf.org/internet-drafts/draft-hamrick-llsd-00.txt ) * Reverse HTTP ( http://tools.ietf.org/html/draft-lentczner-rhttp-00 ) * OGP : Foundations ( http://tools.ietf.org/html/draft-lentczner-ogp-base-00 ) * OGP : Authentication ( http://tools.ietf.org/html/draft-hamrick-ogp-auth-00 ) also... a draft charter for the OGPX group has been published to the mailing list and is archived at: http://www.ietf.org/mail-archive/web/ogpx/current/msg00005.html please don't hesitate to subscribe if you're interested. you don't have to be an OGP partisan. HyperGrid folk who want to know what we're doing are welcome; all i ask is we keep the trash talk to a minimum and keep the discussion focused to OGP. -sincerely -meadhbh hamrick (aka infinity linden) From monkowsk at watson.ibm.com Tue Jun 2 16:03:19 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 02 Jun 2009 19:03:19 -0400 Subject: [sldev] Merging easybuild-2 into Snowglobe (Re: http-texture merged into easybuild-2) In-Reply-To: <4A25A77D.6040809@boroon.dasgupta.ch> References: <4A25774A.9070709@kitware.com> <4A258CDD.5010002@lindenlab.com> <4A25A1A3.40603@watson.ibm.com> <4A25A77D.6040809@boroon.dasgupta.ch> Message-ID: <4A25AFB7.4060108@watson.ibm.com> Boroondas Gupte wrote: > Mike Monkowski schrieb: > >>Rob Lanphier wrote: >> >> >>>If you can give easybuild-2 a shot, we'd appreciate the >>>feedback on how it works on your platform. >>> >> >>Where would I find the documentation on how to use it? > > at https://lists.secondlife.com/pipermail/sldev/2009-May/013941.html That looks pretty much like the usual CMake instructions. I compile on MS Windows not Linux, so I can't be sure. The only difference I see is that you don't have to get the third party libraries. Is that right, or are there other deltas? Mike From sllists at boroon.dasgupta.ch Tue Jun 2 16:28:02 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed, 03 Jun 2009 01:28:02 +0200 Subject: [sldev] easibuild-2 build instructions (was: Merging easybuild-2 into Snowglobe) In-Reply-To: <4A25AFB7.4060108@watson.ibm.com> References: <4A25774A.9070709@kitware.com> <4A258CDD.5010002@lindenlab.com> <4A25A1A3.40603@watson.ibm.com> <4A25A77D.6040809@boroon.dasgupta.ch> <4A25AFB7.4060108@watson.ibm.com> Message-ID: <4A25B582.8000805@boroon.dasgupta.ch> Mike Monkowski schrieb: > Boroondas Gupte wrote: >> [...] >> at https://lists.secondlife.com/pipermail/sldev/2009-May/013941.html > > That looks pretty much like the usual CMake instructions. Depends on what you mean by 'usual CMake instructions'. The main difference from the previous SL build process is probably that you call cmake directly instead of via the develop.py script. That way, it got closer to the build process for 'usual' CMake based projects. > I compile on MS Windows not Linux, so I can't be sure. I only build on Linux, not Windows, so I don't have the whole picture, either. > The only difference I see is that you don't have to get the third > party libraries. Is that right, or are there other deltas? Moving the third party libraries from the libs bundle to some auto-fetching system isn't specific to easibuild2. If I remember correctly, this change was developed on the first easibuild branch. But by now it's present in trunk, snowglobe and most probably a bunch of other branches. cheers Boroondas From robla at lindenlab.com Tue Jun 2 16:29:14 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 02 Jun 2009 16:29:14 -0700 Subject: [sldev] Merging easybuild-2 into Snowglobe (Re: http-texture merged into easybuild-2) In-Reply-To: <4A25AFB7.4060108@watson.ibm.com> References: <4A25774A.9070709@kitware.com> <4A258CDD.5010002@lindenlab.com> <4A25A1A3.40603@watson.ibm.com> <4A25A77D.6040809@boroon.dasgupta.ch> <4A25AFB7.4060108@watson.ibm.com> Message-ID: <4A25B5CA.2020908@lindenlab.com> On 06/02/2009 04:03 PM, Mike Monkowski wrote: > Boroondas Gupte wrote: > >> Mike Monkowski schrieb: >> >> >>> Rob Lanphier wrote: >>> >>> >>> >>>> If you can give easybuild-2 a shot, we'd appreciate the >>>> feedback on how it works on your platform. >>>> >>>> >>> Where would I find the documentation on how to use it? >>> >> at https://lists.secondlife.com/pipermail/sldev/2009-May/013941.html >> > > That looks pretty much like the usual CMake instructions. I compile on > MS Windows not Linux, so I can't be sure. The only difference I see is > that you don't have to get the third party libraries. Is that right, or > are there other deltas? The main difference is that develop.py is completely optional. install.py is now called from CMake, so there's no prep work we're relying on develop.py for. We're planning to keep develop.py around to make life a little easier for those developers (read: mainly Lindens) who are already used to it. If it turns out that this results in develop.py becoming a semi-required step, then we may get a little more medieval on it, but hopefully, more and more people just ditch using develop.py. The other differences are going to be under the hood. For example, if you forget to install the artwork bundle, it'll at least say "you forgot to install the artwork bundle" (and now that public_fetch_tarballs.py exists, it's probably trivial to make it just fetch the artwork bundle, but maybe we'll fix that up after the merge) Rob From carlo at alinoe.com Tue Jun 2 16:37:29 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 3 Jun 2009 01:37:29 +0200 Subject: [sldev] PLEASE READ Re: Repro help: VWR-13757 - Avatar rebaking problems In-Reply-To: <4A2597CD.6050904@gmail.com> References: <4A243D54.6020300@lindenlab.com> <4A256373.9040004@lindenlab.com> <4A2597CD.6050904@gmail.com> Message-ID: <20090602233729.GA15939@alinoe.com> On Tue, Jun 02, 2009 at 11:21:17PM +0200, Jan Ciger wrote: > Rob Lanphier wrote: > > Hi folks, > > > > I'm hoping this doesn't get lost in the chatter. This is important. > > > > I recall the same thing being reported with stock 1.23 release > candidate. I am using Henri's CoolViewer and the textures do not get > rebaked correctly at login neither - the avatar has only attachments > visible, but not head, or the textures are messed up. I see that *ALL* the time, with 1.22.11. But this issue is another if I'm correct. This is about others seeing a cloud. -- Carlo Wood From jan.ciger at gmail.com Tue Jun 2 18:10:39 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Wed, 03 Jun 2009 03:10:39 +0200 Subject: [sldev] PLEASE READ Re: Repro help: VWR-13757 - Avatar rebaking problems In-Reply-To: <20090602233729.GA15939@alinoe.com> References: <4A243D54.6020300@lindenlab.com> <4A256373.9040004@lindenlab.com> <4A2597CD.6050904@gmail.com> <20090602233729.GA15939@alinoe.com> Message-ID: <4A25CD8F.6010804@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carlo Wood wrote: > I see that *ALL* the time, with 1.22.11. > But this issue is another if I'm correct. This is about others seeing a cloud. > If rebake doesn't work right (I think that there was a behaviour change in 1.23), others are not going to see you or see clouds only. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKJc2Mn11XseNj94gRAkXsAKCjvNLpwduaZVu87ntFb7NYyIzhkACeKB/O RK8nrZexOzzHxiAxMCY1bOk= =c1KY -----END PGP SIGNATURE----- From GordonWendt at gmail.com Tue Jun 2 18:25:24 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue, 2 Jun 2009 21:25:24 -0400 Subject: [sldev] url format change on OSS builds + new build Message-ID: <493033a70906021825u7c09ded3n80eea6c5cd07b41d@mail.gmail.com> I just wanted to give anyone who relies on the wiki template links to the OSS builds a heads up that they're out of date at a moment, a new version came out today (links below) but since the URL has changed until the template can be updated that will be out of date and point to the older version. -Gordon --- Downloads -- Linux: http://secondlife.com/developers/opensource/downloads/2009/easybuild-2/2346/SecondLife-i686-1.23.2.2346.tar.bz2 http://secondlife.com/developers/opensource/downloads/2009/easybuild-2/2346/good-build.Linux Darwin: http://secondlife.com/developers/opensource/downloads/2009/easybuild-2/2346/SecondLife_1_23_2_2346_OSS.dmg http://secondlife.com/developers/opensource/downloads/2009/easybuild-2/2346/good-build.Darwin CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/easybuild-2/2346/Second_Life_1-23-2-2346_OSS_Setup.exe http://secondlife.com/developers/opensource/downloads/2009/easybuild-2/2346/good-build.CYGWIN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090602/ca5c8534/attachment.htm From snowfox102 at dragonkeepcreations.com Tue Jun 2 19:40:44 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Tue, 02 Jun 2009 21:40:44 -0500 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A200ECC.2040702@lindenlab.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> <4A200ECC.2040702@lindenlab.com> Message-ID: <4A25E2AC.2020704@dragonkeepcreations.com> Now that I've got compiling a non-standalone viewer figured out, are there instructions available about compiling a standalone viewer anywhere? I'd like to know about that for the sake of completeness. Thanks for the help so far, everyone. :) ~Maya From robin.cornelius at gmail.com Wed Jun 3 00:44:25 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed, 3 Jun 2009 08:44:25 +0100 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: <4A25E2AC.2020704@dragonkeepcreations.com> References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> <4A200ECC.2040702@lindenlab.com> <4A25E2AC.2020704@dragonkeepcreations.com> Message-ID: On Wed, Jun 3, 2009 at 3:40 AM, Maya Remblai wrote: > Now that I've got compiling a non-standalone viewer figured out, are > there instructions available about compiling a standalone viewer > anywhere? I'd like to know about that for the sake of completeness. Not really for windows. Standalone on a windows platform is a bit more involved as you would have to find/fetch and get to compile all the dependencies. It will probably give you no advantage and there is little reason to do it unless you have for example a very specific bug in a given library and in this case you could just replace the one library. Other possible reasons are recompiling for windows 64, optimization tests etc. The main purpose of standalone is on linux where all the dependencies (i say all its a little distro dependent) can be supplied by the distributions standard package management system so this makes 64 bit builds on linux possible with little extra work, where are non-standalone will not work on a 64bit linux system (with out a lot of manual intervention) as not all the prebuilt librarys are available. Regards Robin From robin.cornelius at gmail.com Wed Jun 3 01:11:11 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed, 3 Jun 2009 09:11:11 +0100 Subject: [sldev] PLEASE READ Re: Repro help: VWR-13757 - Avatar rebaking problems In-Reply-To: <4A25CD8F.6010804@gmail.com> References: <4A243D54.6020300@lindenlab.com> <4A256373.9040004@lindenlab.com> <4A2597CD.6050904@gmail.com> <20090602233729.GA15939@alinoe.com> <4A25CD8F.6010804@gmail.com> Message-ID: On Wed, Jun 3, 2009 at 2:10 AM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Carlo Wood wrote: > >> I see that *ALL* the time, with 1.22.11. >> But this issue is another if I'm correct. This is about others seeing a cloud. >> > > If rebake doesn't work right (I think that there was a behaviour change > in 1.23), others are not going to see you or see clouds only. > Yes there was a change. Currently the list of ALL textures the avatar is wearing is available on the wire, to all viewers. If the agents own viewer did not do the baking correctly another viewer would fill in the gaps but only for a single discard level. The 1.23 viewer does away with this feature where a 3rd party viewer can provide a bake in preparation for the texture assets to only be given to the agents viewer, so that other viewers only ever see the completed bakes in future to provide more security for the textures and to provide more flexibility for arbitrary numbers of layers forming the bake. Also there is an UploadBakedTexture CAP now too used for sending the bake to the server instead of the old xfer system. I'm not 100% sure exactly when this CAP started being available but if it is co-incident with the 1.23/http-texture branches then this transparent avatar problem could be a problem on the server and not just the baking on the local viewer. I'm assuming the viewer is coded for a fall back to xfer if the cap is not available so an easy test may be to disable the cap and upload bakes via xfer. If this solves the problem its a server side issue. If i escape out of boost hell i will try this in some more detail From open at autistici.org Wed Jun 3 06:22:40 2009 From: open at autistici.org (Opensource Obscure) Date: Wed, 03 Jun 2009 13:22:40 +0000 Subject: [sldev] VWR-13604 and transparent UI on Snowglobe Message-ID: <23fef0fe9078ffc67a396e7c7d51730e@localhost> My UI just got partially transparent on Snowglobe, as shown in the snapshot attached by Ephyu Reino at https://jira.secondlife.com/browse/VWR-13604 A rebake didn't fix this - worst: it made all my clothes disappear (confirmed by other avatars). This is the second time I get this 'transparent UI' on Snowglobe and I got a similar issue where UI became partially blackened. Anyone else experienced this? Should I open a new PJIRA issue or I comment VWR-13604 ? ciao, Opensource Obscure linux Ubuntu 9.04 Snowglobe 1.23.2 (2338) May 30 2009 12:25:53 (Second Life OSS) Release Notes Built with GCC version 40102 CPU: Intel(R) Core(TM)2 CPU 6420 @ 2.13GHz Memory: 4025 MB OS Version: Linux 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:48:10 UTC 2009 i686 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 9600 GT/PCI/SSE2 OpenGL Version: 3.0.0 NVIDIA 180.44 libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3.3 c-ares/1.4.0 J2C Decoder Version: KDU Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: ALSA Software on default LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24375 (Mozilla GRE version 1.8.1.18_0000000000) From monkowsk at watson.ibm.com Wed Jun 3 08:17:35 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 03 Jun 2009 11:17:35 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> Message-ID: <4A26940F.1020403@watson.ibm.com> Philippe Bossut (Merov Linden) wrote: > Also note that the videos by MS are *not* demos (i.e. > live effective code) but staged shooting. Here's the live demo. Pretty much the same script. http://www.youtube.com/watch?v=GH_gDreIdcM From merov at lindenlab.com Wed Jun 3 09:57:37 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 3 Jun 2009 09:57:37 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A26940F.1020403@watson.ibm.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> Message-ID: Hi, On Jun 3, 2009, at 8:17 AM, Mike Monkowski wrote: > Philippe Bossut (Merov Linden) wrote: >> Also note that the videos by MS are *not* demos (i.e. live >> effective code) but staged shooting. > > Here's the live demo. Pretty much the same script. > http://www.youtube.com/watch?v=GH_gDreIdcM > Wait, wait: that's not the same script at all: - single player only (I'm so not surprised...), 2 players only to silhouette (no 3D required there, no tracking either BTW) - huge space for the camera tracking (ditto), ideal conditions really Note that most of the effects in the ball game could be controlled by simple silhouetting, no rigging of an avatar. Similar demos are visible on Softkinetic website I mentioned yesterday. Here's another one BTW for the curious: http://www.omekinteractive.com/ I like the paint party game though. GestureTek is proposing similar (and as good) interactive games since years now (http://www.gesturetek.com/ ). Mostly for commercial settings and museums though. The really tricky things that could be seen in the other demo (close range capture in a busy living room, multiplayer, full body rigging) are, as far as I can tell, not there yet. I do agree though that it's a matter of time before we see them available (by one of the actors I mentioned, not necessarily MS, plus a bunch of stealth start ups I know are working on this). So let's not argue about this. The real question for SL (and VW in general) is: are those technologies relevant to VW interaction? What do *we* (as a community) want from these technologies? I think Ron/Hiro was spot on addressing this question yesterday and this is where we should focus our attention on. Cheers, - Merov From monkowsk at watson.ibm.com Wed Jun 3 11:09:24 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 03 Jun 2009 14:09:24 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> Message-ID: <4A26BC54.40307@watson.ibm.com> Philippe Bossut (Merov Linden) wrote: > On Jun 3, 2009, at 8:17 AM, Mike Monkowski wrote: > > >>Philippe Bossut (Merov Linden) wrote: >> >>>Also note that the videos by MS are *not* demos (i.e. live >>>effective code) but staged shooting. >> >>Here's the live demo. Pretty much the same script. >>http://www.youtube.com/watch?v=GH_gDreIdcM >> > Wait, wait: that's not the same script at all: It's the same as the second of the two earlier videos. They even do the elephant drawing the same way. The first of the two videos earlier, as was pointed out before, was just a concept video. I agree with you, though, that this isn't really what would be effective for SL. For SL, conversational cues would be more useful: nodding yes, no, wave, and maybe hand gestures while speaking. The UI controls with this might be tricky. Would you have a push-to-move control like the push-to-talk for the microphone? If not, you could get a lot of movement out of context for the avatar. Virtual nose picking? :-) Ooh, how about handshakes across the internet? That would be difficult. Sounds like a good topic for the User Experince Interest Group meeting. Mike From tigrospottystripes at gmail.com Wed Jun 3 12:01:29 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 03 Jun 2009 16:01:29 -0300 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A26BC54.40307@watson.ibm.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> Message-ID: <4A26C889.7090308@Gmail.com> handshaking without haptic feedback and with SL's usual latency wouldn't work, I imagine it would be possible to make a handshake work in SL by adapting the IK code used to position the hand and arm while selecting an object at arm's reach, and then locally on each client play an animation over the IK moving both avatar's hands (or the IK target itself) up and down (if it was done server side, or just on one client and communicated to the other, or each client animating only it's own av, there would be the risk of things not matching or lagging too much I guess) Mike Monkowski escreveu: > Philippe Bossut (Merov Linden) wrote: > >> On Jun 3, 2009, at 8:17 AM, Mike Monkowski wrote: >> >> >> >>> Philippe Bossut (Merov Linden) wrote: >>> >>> >>>> Also note that the videos by MS are *not* demos (i.e. live >>>> effective code) but staged shooting. >>>> >>> Here's the live demo. Pretty much the same script. >>> http://www.youtube.com/watch?v=GH_gDreIdcM >>> >>> >> Wait, wait: that's not the same script at all: >> > > It's the same as the second of the two earlier videos. They even do the > elephant drawing the same way. > > The first of the two videos earlier, as was pointed out before, was just > a concept video. > > I agree with you, though, that this isn't really what would be effective > for SL. For SL, conversational cues would be more useful: nodding yes, > no, wave, and maybe hand gestures while speaking. > > The UI controls with this might be tricky. Would you have a > push-to-move control like the push-to-talk for the microphone? If not, > you could get a lot of movement out of context for the avatar. Virtual > nose picking? :-) > > Ooh, how about handshakes across the internet? That would be difficult. > > Sounds like a good topic for the User Experince Interest Group meeting. > > Mike > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From tom at streamsense.net Wed Jun 3 12:48:15 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed, 03 Jun 2009 20:48:15 +0100 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> Message-ID: <4A26D37F.8070004@streamsense.net> Right, but the technology is live, is working, and is impressive, as you can see from this third-party article: http://www.engadget.com/2009/06/03/project-natal-video-hands-on-impressions-and-further-details?icid=sphere_blogsmith_inpage_engadget I'm not suggesting that this technology should be integrated into the core of Second Life; I think that if LL tried to implement this it would end up half working akin to Windlight and many other linden investments, BUT I really would like to see the lab building an /interface/ to allow this level of live avatar control which can be hooked into by third parties in the future. ~T Philippe Bossut (Merov Linden) wrote: > Also note that the videos by MS are *not* demos (i.e. > live effective code) but staged shooting. From jan.ciger at gmail.com Wed Jun 3 13:02:45 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Wed, 03 Jun 2009 22:02:45 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A26C889.7090308@Gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> Message-ID: <4A26D6E5.8070500@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tigro Spottystripes wrote: > handshaking without haptic feedback and with SL's usual latency > wouldn't work, I imagine it would be possible to make a handshake > work in SL by adapting the IK code used to position the hand and arm > while selecting an object at arm's reach, and then locally on each > client play an animation over the IK moving both avatar's hands (or > the IK target itself) up and down (if it was done server side, or > just on one client and communicated to the other, or each client > animating only it's own av, there would be the risk of things not > matching or lagging too much I guess) > We were trying this back during my time at VRlab. It is pretty hopeless without the tactile feedback. Human brain works like a servo-control loop. Without depth/distance perception and tactile sensation that you have reached the objective you will be only flailing around in the space. And who has a head mounted display with a force-feedback exoskeleton at home? To shake hands? Even the animation is very difficult. IK doesn't work too well for chains with many joints and few constraints - like a whole avatar body, not to mention it is terribly slow. Arm IK is not enough, unless you want to look as if you ate a ruler or even fail to reach the target - arm reach is not that big and without bending your upper body the task may be impossible. Furthermore, you are trying to reach a moving target, even without the usual network-induced latencies it is very tricky. If someone is interested in this stuff, look at the animation papers published by Baerlocher et al and Boulic et al. They have developed an IK system for realistic full body animation - however, it is pretty "meaty" stuff, consider yourself warned :) Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKJtbln11XseNj94gRAoHQAKCv5Ra3l/AG78UVrJw1s88a/Dm36ACg1ld7 XjHEQ18jllbJkcDQfzlpdw4= =VGKo -----END PGP SIGNATURE----- From jan.ciger at gmail.com Wed Jun 3 13:06:45 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Wed, 03 Jun 2009 22:06:45 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A26D37F.8070004@streamsense.net> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26D37F.8070004@streamsense.net> Message-ID: <4A26D7D5.7080405@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Grimshaw wrote: > BUT I really would like to see the lab building an > /interface/ to allow this level of live avatar control which can be > hooked into by third parties in the future. All that you need is to expose the positions/quaternions of all bones in the avatar's skeleton using some kind of API. Then it can be driven even by live motion capture, if that is what you desire. However, apart from some kind of puppeteering, this is not that useful technique. You can't really walk in SL or grasp objects with your hands with only some kind of motion capture. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKJtfVn11XseNj94gRAi4tAKCTNtLUiZo97bUQJfL07qJ3smv1xgCg0N1q 5PbmZW/M3FH0ZbY+0a5DagM= =x9Ff -----END PGP SIGNATURE----- From snowfox102 at dragonkeepcreations.com Wed Jun 3 14:55:21 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Wed, 03 Jun 2009 16:55:21 -0500 Subject: [sldev] [HELP] C++ newbie needs help with first compilation In-Reply-To: References: <4A1B5E64.3030502@dragonkeepcreations.com> <493033a70905252107s1837ebbcmc75d7a5a497568f2@mail.gmail.com> <4A1CC449.80101@dragonkeepcreations.com> <4A1F2915.9000004@dragonkeepcreations.com> <4A200ECC.2040702@lindenlab.com> <4A25E2AC.2020704@dragonkeepcreations.com> Message-ID: <4A26F149.9020605@dragonkeepcreations.com> There's another reason to know: Being able to allow others to download an already compiled viewer! I imagine that most of my customers won't know how to apply the patch I made, but some would like to use an already built viewer that allows them to hide their avatar mesh. Although I hope someone with more expertise will provide a built viewer soon, since I already have the files I may as well do it myself if I can find instructions. ~Maya Robin Cornelius wrote: > On Wed, Jun 3, 2009 at 3:40 AM, Maya Remblai > wrote: > >> Now that I've got compiling a non-standalone viewer figured out, are >> there instructions available about compiling a standalone viewer >> anywhere? I'd like to know about that for the sake of completeness. >> > > Not really for windows. Standalone on a windows platform is a bit more > involved as you would have to find/fetch and get to compile all the > dependencies. It will probably give you no advantage and there is > little reason to do it unless you have for example a very specific bug > in a given library and in this case you could just replace the one > library. Other possible reasons are recompiling for windows 64, > optimization tests etc. > > The main purpose of standalone is on linux where all the dependencies > (i say all its a little distro dependent) can be supplied by the > distributions standard package management system so this makes 64 bit > builds on linux possible with little extra work, where are > non-standalone will not work on a 64bit linux system (with out a lot > of manual intervention) as not all the prebuilt librarys are > available. > > Regards > > Robin > > From robla at lindenlab.com Wed Jun 3 17:23:17 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 03 Jun 2009 17:23:17 -0700 Subject: [sldev] Snowglobe QA process Message-ID: <4A2713F5.5030203@lindenlab.com> Hi folks, A while back, I mentioned I'd be documenting our QA process: http://jira.secondlife.com/browse/SNOW-5 Here's what I came up with: https://wiki.secondlife.com/wiki/Snowglobe_QA It's pretty short and sweet. Hopefully it's also complete. If not, please comment on SNOW-5. Thanks! Rob From secret.argent at gmail.com Thu Jun 4 05:00:53 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 4 Jun 2009 07:00:53 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A26C889.7090308@Gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> Message-ID: On 2009-06-03, at 14:01, Tigro Spottystripes wrote: > handshaking without haptic feedback and with SL's usual latency > wouldn't > work, I imagine it would be possible to make a handshake work in SL > by > adapting the IK code used to position the hand and arm while selecting > an object at arm's reach, and then locally on each client play an > animation over the IK moving both avatar's hands (or the IK target > itself) up and down (if it was done server side, or just on one client > and communicated to the other, or each client animating only it's own > av, there would be the risk of things not matching or lagging too > much I > guess) Yes, that's something I've often thought of. I think just allowing a small amount of scripted IK based on having avatar joints track a prim if they were within a certain distance would allow this and more. With or without camera tracking... you'd wear a handshake attachment that would track the matching prim. Then if one or both users had camera tracking code that would be used to drive the handshake, if not the handshake would track the avatar's canned animations. And you could have sit or stand animations with appropriate scripted overrides actually put your hands on your hips or your knees no matter what your avatar size. llTrackAnimation(integer joint, key target, float strength); From jan.ciger at gmail.com Thu Jun 4 06:55:52 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu, 04 Jun 2009 15:55:52 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> Message-ID: <4A27D268.6060104@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > > Yes, that's something I've often thought of. I think just allowing a > small amount of scripted IK based on having avatar joints track a prim > if they were within a certain distance would allow this and more. Argent, read my comment to Tigro's mail. It wouldn't work. At least not in a nice way. For reaching and grasping you need much more IK than just the three arm joints and then you are hitting a severely under-constrained and computationally expensive problem. The trouble with IK is that it treats joints equally and many things that are computationally possible do not look realistic. There is no intrinsic notion of "comfortable" or believable pose for IK and the solver has no means to prefer those. E.g. in one case I have seen the solver to keep the hands next to the avatar's waist but stick the waist forward to reach a goal. Was the objective achieved? Yes. Was it believable animation? No way. We have "fixed" that by tweaking the joint weights (give more priority to arm joints and not to pelvis), but then it blows up in another case, which your tweaks made actually worse (a pose where moving the pelvis is actually preferred to flailing the arms). This leads to a lot of special cases that have to be defined, definitely not a scalable solution. IK is a nice tool, but extremely hard to use unless you have an animator guiding it. On the other hand, the option to actually be able to do scripted/procedural animation (IK falls in that category) instead of only replaying keyframe animations would be great. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKJ9Jkn11XseNj94gRAoX1AKC3tgSQ95LfPp6v0oD+tjQx0hYKMACgmgMe UIFWL7PPEzAGd16sAzdqHF0= =TubX -----END PGP SIGNATURE----- From johnniecarling at gmail.com Thu Jun 4 19:32:20 2009 From: johnniecarling at gmail.com (Johnnie Carling) Date: Thu, 4 Jun 2009 22:32:20 -0400 Subject: [sldev] Snowglobe + easybuild Message-ID: <200906042232.20912.johnniecarling@gmail.com> I thought I'd chime in with my experiences with Snowglobe with easybuild First of all the compilation worked the easybuild way (Debian sid) and I'm using snowglobe right now. But there seems to be 2 issues that I "think" might be related to the easybuild process. (But I'm not a developer so I may be very wrong) 1) The mouse cursor. I just have a default black arrow, it does not change when I place the mouse over an object you can touch, or when you alt-click for example. 2) KDU Stuff. The compiled viewer includes the KDU libraries (With new names compared to 1.22 and 1.23RCs) but Help > About Second Live says it's using OpenJPEG Hope this helps :) :: System Info :: Snowglobe 1.23.2 (121930) Jun 4 2009 19:58:40 (CommunityDeveloper) Release Notes Built with GCC version 40303 You are at 269441.6, 311929.6, 1501.1 in Mayan Myst located at sim8243.agni.lindenlab.com (216.82.38.56:13002) Second Life Server 1.26.4.120562 Release Notes CPU: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz Memory: 2026 MB OS Version: Linux 2.6.29-2-686 #1 SMP Sun May 17 17:56:29 UTC 2009 i686 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7900 GS/PCI/SSE2 OpenGL Version: 2.1.2 NVIDIA 180.44 libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3.3 c-ares/1.4.0 J2C Decoder Version: OpenJPEG: 1.3.0, Runtime: 1.3.0 Audio Driver Version: (none) LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24412 (Mozilla GRE version 1.8.1.18_0000000000) Packets Lost: 226/40092 (0.6%) From sldev at free.fr Fri Jun 5 00:08:31 2009 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 5 Jun 2009 09:08:31 +0200 Subject: [sldev] Snowglobe + easybuild In-Reply-To: <200906042232.20912.johnniecarling@gmail.com> References: <200906042232.20912.johnniecarling@gmail.com> Message-ID: <20090605090831.001e0fd5.sldev@free.fr> On Thu, 4 Jun 2009 22:32:20 -0400, Johnnie Carling wrote: > I thought I'd chime in with my experiences with Snowglobe with easybuild > > First of all the compilation worked the easybuild way (Debian sid) and I'm > using snowglobe right now. But there seems to be 2 issues that I "think" might > be related to the easybuild process. (But I'm not a developer so I may be very > wrong) > > 1) The mouse cursor. I just have a default black arrow, it does not change > when I place the mouse over an object you can touch, or when you alt-click for > example. In the "secondlife" wrapper script, make sure that export LL_ATI_MOUSE_CURSOR_BUG=x is commented out (it normally is by default). This setting is to work around a hardware bug in some ATI Mobility Radeon GPUs (such as Mobility Radeon 9600/9700) which can crash the whole computer under Linux when the hardware mouse cursor is changed while the GPU is 100% loaded. Enabling this work around means that the mouse cursor is not changed any more by the viewer (alas, crashes can still happen when the window manager changes the cursor, for example when moving the cursor over the border of the viewer window). Henri. From johnniecarling at gmail.com Fri Jun 5 01:12:59 2009 From: johnniecarling at gmail.com (Johnnie Carling) Date: Fri, 5 Jun 2009 04:12:59 -0400 Subject: [sldev] Snowglobe + easybuild In-Reply-To: <20090605090831.001e0fd5.sldev@free.fr> References: <200906042232.20912.johnniecarling@gmail.com> <20090605090831.001e0fd5.sldev@free.fr> Message-ID: <200906050412.59262.johnniecarling@gmail.com> On 06/05/09 3:08:31 am, Henri Beauchamp wrote: > In the "secondlife" wrapper script, make sure that > export LL_ATI_MOUSE_CURSOR_BUG=x > is commented out (it normally is by default). Just checked and it is commented out as it should be. Johnnie From sllists at boroon.dasgupta.ch Fri Jun 5 04:29:29 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 05 Jun 2009 13:29:29 +0200 Subject: [sldev] Snowglobe + easybuild In-Reply-To: <200906042232.20912.johnniecarling@gmail.com> References: <200906042232.20912.johnniecarling@gmail.com> Message-ID: <4A290199.7020901@boroon.dasgupta.ch> Johnnie Carling schrieb: > I thought I'd chime in with my experiences with Snowglobe with easybuild > > [...] But there seems to be 2 issues [...] > > 1) The mouse cursor. I just have a default black arrow, it does not change > when I place the mouse over an object you can touch, or when you alt-click for > example. > I've seen this after doing an out-of-source-tree build with outdated libs and artwork packages unpacked on the source tree. A later in-tree build with artwork and libs packages corresponding to the used source revision had the cursors change as expected, so I guess that either the out-of-source-tree building or the not up-to-date packages where the cause. cheers Boroondas From secret.argent at gmail.com Fri Jun 5 04:34:09 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 5 Jun 2009 06:34:09 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A27D268.6060104@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> Message-ID: <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> On 2009-06-04, at 08:55, Jan Ciger wrote: > Argent, read my comment to Tigro's mail. It wouldn't work. At least > not > in a nice way. For reaching and grasping you need much more IK than > just > the three arm joints and then you are hitting a severely > under-constrained and computationally expensive problem. That's why you don't try and solve it computationally. You don't replace normal animation, you use this for minor adjustments to the existing animation, and you limit the strength of the adjustment to small angles and specific joints. So it's down to the person selecting the base animation and providing the strength and possibly range (either distance or angle). > E.g. in one case I have seen the solver to keep the hands next to the > avatar's waist but stick the waist forward to reach a goal. Wouldn't happen, unless the person selected the waist as the joint that would move, and unless the waist was already close to the goal. > IK is a nice tool, but extremely hard to use unless you have an > animator > guiding it. Which is the point. From ron at involve3d.com Fri Jun 5 07:05:11 2009 From: ron at involve3d.com (Ron Blechner) Date: Fri, 5 Jun 2009 10:05:11 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> Message-ID: Question: Why are handshakes so important that they are much more of a topic of discussion of implementation, against facial expressions? -Ron / Hiro On Fri, Jun 5, 2009 at 7:34 AM, Argent Stonecutter wrote: > On 2009-06-04, at 08:55, Jan Ciger wrote: >> Argent, read my comment to Tigro's mail. It wouldn't work. At least >> not >> in a nice way. For reaching and grasping you need much more IK than >> just >> the three arm joints and then you are hitting a severely >> under-constrained and computationally expensive problem. > > That's why you don't try and solve it computationally. You don't > replace normal animation, you use this for minor adjustments to the > existing animation, and you limit the strength of the adjustment to > small angles and specific joints. > > So it's down to the person selecting the base animation and providing > the strength and possibly range (either distance or angle). > >> E.g. in one case I have seen the solver to keep the hands next to the >> avatar's waist but stick the waist forward to reach a goal. > > Wouldn't happen, unless the person selected the waist as the joint > that would move, and unless the waist was already close to the goal. > >> IK is a nice tool, but extremely hard to use unless you have an >> animator >> guiding it. > > Which is the point. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com From jan.ciger at gmail.com Fri Jun 5 08:39:40 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 05 Jun 2009 17:39:40 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> Message-ID: <4A293C3C.6070505@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > That's why you don't try and solve it computationally. You don't > replace normal animation, you use this for minor adjustments to the > existing animation, and you limit the strength of the adjustment to > small angles and specific joints. Ah, really? Did you actually try this? This idea has been around for a while, I have actually former colleagues that have build PhDs on this type of motion re-targeting using IK. How specifically do you decide which joints are relevant for a given case? Also which angles are "small enough" before the keyframe doesn't work anymore? >> E.g. in one case I have seen the solver to keep the hands next to the >> avatar's waist but stick the waist forward to reach a goal. > > Wouldn't happen, unless the person selected the waist as the joint > that would move, and unless the waist was already close to the goal. And what kind of interface you would like to give to the user? A skeleton of joints to pick from? > >> IK is a nice tool, but extremely hard to use unless you have an >> animator >> guiding it. > > Which is the point. Then I am a bit confused - I thought we are talking about real-time automatic animation, not something to produce better keyframe animation to be played at a later time (which is of course doable). Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD4DBQFKKTw8n11XseNj94gRAqMtAKDuuqQg9utwN0sYDSmVSChzSq4rKQCYkiNI 5F9iAqT8dDa+OBKdXhlK+A== =+6mS -----END PGP SIGNATURE----- From lenglish5 at cox.net Fri Jun 5 08:41:51 2009 From: lenglish5 at cox.net (Lawson English) Date: Fri, 05 Jun 2009 08:41:51 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> Message-ID: <4A293CBF.10008@cox.net> Ron Blechner wrote: > Question: > > Why are handshakes so important that they are much more of a topic of > discussion of implementation, against facial expressions? > > -Ron / Hiro > Cultural Bias? :-) (?-?*) Lawson From tateru.nino at gmail.com Fri Jun 5 10:33:54 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 06 Jun 2009 03:33:54 +1000 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> Message-ID: <4A295702.4030705@gmail.com> Maybe it isn't really about handshakes, and more about general lining-up-of-body-parts between avatars? :) However, for most people in first-world western cultures, a handshake is the frequently sole form of socially allowable physical contact between two people who aren't intimates at some level. That makes it strongly symbolic. For handshake you can substitute a few variations: Knuckle-bumps, high-fives and such, but they're all basically a handshake with different emotional flavoring. Ron Blechner wrote: > Question: > > Why are handshakes so important that they are much more of a topic of > discussion of implementation, against facial expressions? > > -Ron / Hiro > > On Fri, Jun 5, 2009 at 7:34 AM, Argent > Stonecutter wrote: > >> On 2009-06-04, at 08:55, Jan Ciger wrote: >> >>> Argent, read my comment to Tigro's mail. It wouldn't work. At least >>> not >>> in a nice way. For reaching and grasping you need much more IK than >>> just >>> the three arm joints and then you are hitting a severely >>> under-constrained and computationally expensive problem. >>> >> That's why you don't try and solve it computationally. You don't >> replace normal animation, you use this for minor adjustments to the >> existing animation, and you limit the strength of the adjustment to >> small angles and specific joints. >> >> So it's down to the person selecting the base animation and providing >> the strength and possibly range (either distance or angle). >> >> >>> E.g. in one case I have seen the solver to keep the hands next to the >>> avatar's waist but stick the waist forward to reach a goal. >>> >> Wouldn't happen, unless the person selected the waist as the joint >> that would move, and unless the waist was already close to the goal. >> >> >>> IK is a nice tool, but extremely hard to use unless you have an >>> animator >>> guiding it. >>> >> Which is the point. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > > > -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090606/5b3887c9/attachment-0001.htm From monkowsk at watson.ibm.com Fri Jun 5 13:12:02 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri, 05 Jun 2009 16:12:02 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A295702.4030705@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> Message-ID: <4A297C12.6030208@watson.ibm.com> Tateru Nino wrote: > Maybe it isn't really about handshakes, and more about general > lining-up-of-body-parts between avatars? :) Oh? Which body parts did *you* have in mind? > However, for most people in first-world western cultures, a handshake is > the frequently sole form of socially allowable physical contact between > two people who aren't intimates at some level. That makes it strongly > symbolic. A handshake in the west. A bow in the east. Maybe we should agree that in a *virtual* world everyone does a curtsy. :-) Aw, c'mon, it's the end of a long week. My mind's on autopilot. :-) Mike From carlo at alinoe.com Fri Jun 5 17:14:00 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 6 Jun 2009 02:14:00 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A295702.4030705@gmail.com> References: <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> Message-ID: <20090606001400.GA13914@alinoe.com> On Sat, Jun 06, 2009 at 03:33:54AM +1000, Tateru Nino wrote: > Maybe it isn't really about handshakes, and more about general > lining-up-of-body-parts between avatars? :) I'd implement this by tracking the *position* of the main points (hands, head top, mouth, shoulder, crotch, etc), and then define the skeleton to be the distances between those points. Thus, if the person recording a movement brings his/her hand to her mouth - that particular distance would go to zero. When playing back, I'd then morph the skeleton such that shorter distances get higher priority. Thus, a distance of zero becomes garanteed zero, while a distance of 1 meter may become 0.9 or 1.1 meter if needed. I'm sure this can be achieved with rather simple matrix operations. In couple animations you can simply extent this model with the main points of the second person. That way you are garanteed that a handshake results in a handshake, a kiss in a kiss and a fuck in a fuck. -- Carlo Wood From merov at lindenlab.com Fri Jun 5 18:35:15 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 5 Jun 2009 18:35:15 -0700 Subject: [sldev] VWR-13505 and VWR-13742 Message-ID: Hi guys, I committed code to fix those 2 bugs in snowglobe. Build 2366 will have both fixes. One problem though is that those are temporary fixes as the true underlying issues (some design assumptions that proved to be partially incorrect) need to be revisited and I'd like the original dev to have a chance to review the problem and, likely, come up with a better implementation. Cheers, - Merov From tateru.nino at gmail.com Fri Jun 5 21:35:20 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 06 Jun 2009 14:35:20 +1000 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <20090606001400.GA13914@alinoe.com> References: <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> <20090606001400.GA13914@alinoe.com> Message-ID: <4A29F208.5070809@gmail.com> Carlo Wood wrote: > On Sat, Jun 06, 2009 at 03:33:54AM +1000, Tateru Nino wrote: > >> Maybe it isn't really about handshakes, and more about general >> lining-up-of-body-parts between avatars? :) >> > > I'd implement this by tracking the *position* of the main > points (hands, head top, mouth, shoulder, crotch, etc), > and then define the skeleton to be the distances between > those points. > > Thus, if the person recording a movement brings his/her > hand to her mouth - that particular distance would go > to zero. > > When playing back, I'd then morph the skeleton such that > shorter distances get higher priority. Thus, a distance of > zero becomes garanteed zero, while a distance of 1 meter > may become 0.9 or 1.1 meter if needed. I'm sure this > can be achieved with rather simple matrix operations. > > In couple animations you can simply extent this model > with the main points of the second person. That way > you are garanteed that a handshake results in a handshake, > a kiss in a kiss and a fuck in a fuck. > > Avatars don't occupy a common coordinate-space, however. All we /really/ know about the avatar is that it is drawn based on the position of the dimensionless point representing the agent (and offset up to 10m or so within a volume centered on that point). The avatar itself (AFAIK) exists in its own independent coordinate-space, sans reference to the common coordinate-space in which other agents are positioned, and with even less relation to the coordinate-spaces of other avatars. As I recall, the "physical avatar" project was supposed to solve that, but appears to be an abandoned effort. -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090606/de4cba58/attachment.htm From tigrospottystripes at gmail.com Fri Jun 5 21:52:42 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 06 Jun 2009 01:52:42 -0300 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A29F208.5070809@gmail.com> References: <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> <20090606001400.GA13914@alinoe.com> <4A29F208.5070809@gmail.com> Message-ID: <4A29F61A.5070500@Gmail.com> is that still the case client side? Tateru Nino escreveu: > > > Carlo Wood wrote: >> On Sat, Jun 06, 2009 at 03:33:54AM +1000, Tateru Nino wrote: >> >>> Maybe it isn't really about handshakes, and more about general >>> lining-up-of-body-parts between avatars? :) >>> >> >> I'd implement this by tracking the *position* of the main >> points (hands, head top, mouth, shoulder, crotch, etc), >> and then define the skeleton to be the distances between >> those points. >> >> Thus, if the person recording a movement brings his/her >> hand to her mouth - that particular distance would go >> to zero. >> >> When playing back, I'd then morph the skeleton such that >> shorter distances get higher priority. Thus, a distance of >> zero becomes garanteed zero, while a distance of 1 meter >> may become 0.9 or 1.1 meter if needed. I'm sure this >> can be achieved with rather simple matrix operations. >> >> In couple animations you can simply extent this model >> with the main points of the second person. That way >> you are garanteed that a handshake results in a handshake, >> a kiss in a kiss and a fuck in a fuck. >> >> > Avatars don't occupy a common coordinate-space, however. All we > /really/ know about the avatar is that it is drawn based on the > position of the dimensionless point representing the agent (and offset > up to 10m or so within a volume centered on that point). The avatar > itself (AFAIK) exists in its own independent coordinate-space, sans > reference to the common coordinate-space in which other agents are > positioned, and with even less relation to the coordinate-spaces of > other avatars. > > As I recall, the "physical avatar" project was supposed to solve that, > but appears to be an abandoned effort. > -- > Tateru Nino > http://dwellonit.taterunino.net/ > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From secret.argent at gmail.com Sat Jun 6 11:43:59 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 6 Jun 2009 13:43:59 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A293C3C.6070505@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> Message-ID: <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> I think you're envisioning a much more ambitious project than I'm suggesting! :) On 2009-06-05, at 10:39, Jan Ciger wrote: > How specifically do you decide which joints are relevant for a given > case? Also which angles are "small enough" before the keyframe doesn't > work anymore? You'd provide them as parameters to the LSL call, and eyeball it, and decide "yeh, that's good enough" or "no, better cut it down". The UI would be an LSL call something like this: llSetAnimationTarget(integer joint, key target_prim, float strength, ...) Or like this: llSetAnimationTargetParams(list parameters); The parameters could be a list of parameters (strength, range, timeouts) or an actual list similar to particle systems [ANIM_MASK, JOINT_RIGHT_WRIST|JOINT_RIGHT_ELBOW, ANIM_RANGE, 0.1, ANIM_STRENGTH, 2, ANIM_ANGLE_LIMIT, JOINT_RIGHT_ELBOW, PI/18, ANIM_TARGET, target_prim, ....]. So this would move the user's hand to clasp the other avatar's hand, while the hand was within 10cm of the goal, with a time facto of two seconds, and not bending the right elbow more than 10 degrees from the original animation. At worst, it wouldn't be nearly as ludicrous as having the avatars waving hands at each other. > Then I am a bit confused - I thought we are talking about real-time > automatic animation, not something to produce better keyframe > animation > to be played at a later time (which is of course doable). The scripter would run the handshake animation, and eyeball the results when played back with a variety of complementary avatars. Individual coder's experience and market forces would be left to handle the results. From secret.argent at gmail.com Sat Jun 6 11:48:47 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 6 Jun 2009 13:48:47 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A295702.4030705@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> Message-ID: <909BFC51-6C63-419C-8BAC-C9E6A4CC0A7F@gmail.com> On 2009-06-05, at 12:33, Tateru Nino wrote: > Maybe it isn't really about handshakes, and more about general > lining-up-of-body-parts between avatars? :) Or within an avatar. My usual avatar (a ferret) has a long body and short arms. Walking animations make my hand bury itself in my back instead of resting on my hip. If I could have it play a target script to tug my hand a few centimeters to the side towards a prim in my hip I could use normal animations and have them look more natural, without having to redo all my animations (even if there was a way to download and edit them). From secret.argent at gmail.com Sat Jun 6 11:54:12 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 6 Jun 2009 13:54:12 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A29F208.5070809@gmail.com> References: <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> <20090606001400.GA13914@alinoe.com> <4A29F208.5070809@gmail.com> Message-ID: <5766ABAF-958F-4044-9674-F320751EB032@gmail.com> On 2009-06-05, at 23:35, Tateru Nino wrote: > Avatars don't occupy a common coordinate-space, however. All we > really know about the avatar is that it is drawn based on the > position of the dimensionless point representing the agent (and > offset up to 10m or so within a volume centered on that point). The > avatar itself (AFAIK) exists in its own independent coordinate- > space, sans reference to the common coordinate-space in which other > agents are positioned, and with even less relation to the coordinate- > spaces of other avatars. But in the viewer the avatar shares a coordinate space with the world. Flexible prims attached to the avatar object global forces, not local ones. Particles from prims attached to the avatar obey a global coordinate space and can target prims attached to other avatars. That's the coordinate space this hypothetical "IK tweaking call" would operate in. From jan.ciger at gmail.com Sat Jun 6 12:40:33 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sat, 06 Jun 2009 21:40:33 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> Message-ID: <4A2AC631.7060508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > I think you're envisioning a much more ambitious project than I'm > suggesting! :) Likely. Call it professional deformation - I have been among these things for quite a few years now :) > So this would move the user's hand to clasp the other avatar's hand, > while the hand was within 10cm of the goal, with a time facto of two > seconds, and not bending the right elbow more than 10 degrees from the > original animation. > > At worst, it wouldn't be nearly as ludicrous as having the avatars > waving hands at each other. > Aha, I see. Well, that is certainly doable, but it will be really difficult to use. On the other hand, having an option to actually use procedural animation from scripts would be great. > > The scripter would run the handshake animation, and eyeball the results > when played back with a variety of complementary avatars. Individual > coder's experience and market forces would be left to handle the results. I see. I understood the goal differently - as having the "hug" or "handshake" action executed automatically using IK only. That certainly wouldn't work. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKKsYrn11XseNj94gRAv/nAJ4lRGNWPYSz2zlwnpzxzoQGBi6DygCfZRk8 M5u8IKhIQB1q6SYBXAGYcmc= =4cYx -----END PGP SIGNATURE----- From secret.argent at gmail.com Sat Jun 6 12:54:13 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 6 Jun 2009 14:54:13 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2AC631.7060508@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> Message-ID: <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> On 2009-06-06, at 14:40, Jan Ciger wrote: > Aha, I see. Well, that is certainly doable, but it will be really > difficult to use. On the other hand, having an option to actually use > procedural animation from scripts would be great. I don't think it would be anywhere near so hard as getting a reliable animation overrider to work in the first place. :) Have you looked at the source for Franimation/ZHAO? Oh, there's a certain amount of gratuitous yak-shaving in the code, but there's all KINDS of special cases... and even then I'm always tinkering with my copy to try and stop things like the skipping-up-steps effect. > I see. I understood the goal differently - as having the "hug" or > "handshake" action executed automatically using IK only. That > certainly > wouldn't work. No, no, I'm not actually insane. :) From jan.ciger at gmail.com Sat Jun 6 15:44:57 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun, 07 Jun 2009 00:44:57 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> Message-ID: <4A2AF169.6040809@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > I don't think it would be anywhere near so hard as getting a reliable > animation overrider to work in the first place. :) > > Have you looked at the source for Franimation/ZHAO? Oh, there's a > certain amount of gratuitous yak-shaving in the code, but there's all > KINDS of special cases... and even then I'm always tinkering with my > copy to try and stop things like the skipping-up-steps effect. You are missing a crucial difference - an AO merely plays "pre-cooked" animations, turning off one and turning on another one. That is the trivial part. The script only triggers them. The special cases are due to the fact that an AO is a gross hack working around the fact that there is no way to tell SL to play different animations instead of the default ones. Generating a procedural animation, be it IK, simple reaching anim or walkcycle is several orders of magnitude more difficult - you have to actually control the whole thing and calculate positions/orientations of every joint and blend it properly. And you are likely doing this on the server, because otherwise you wouldn't be able to synchronize two avatars. Of course, from the script's point of view, it would be all black box. However, tweaking the inputs, e.g. for IK, is far from trivial, requiring deep understanding of how the skeleton works and the math behind. How many scripters actually understand the concept behind the rotation type (quaternion) and hierarchical transformations that are the basic element of this? Here you will be giving the scripters another black magic tool like that, probably even more complex. I doubt that many people would be capable of using it effectively. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKKvFmn11XseNj94gRArJ3AJwL5C0xxUvpegDId0kygys2zYOwyACg60VD Cm60iX0BFbOI6SsYzRPAzVQ= =YoL6 -----END PGP SIGNATURE----- From secret.argent at gmail.com Sat Jun 6 16:45:27 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 6 Jun 2009 18:45:27 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2AF169.6040809@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> Message-ID: On 2009-06-06, at 17:44, Jan Ciger wrote: > Generating a procedural animation, be it IK, simple reaching anim or > walkcycle is several orders of magnitude more difficult - you have to > actually control the whole thing and calculate positions/ > orientations of > every joint and blend it properly. If I was talking about a complete procedural animation from scratch, sure, but I'm not. I'm talking about using IK to tweak a canned animation slightly to adjust for differences between avatars. > And you are likely doing this on the > server, because otherwise you wouldn't be able to synchronize two > avatars. It'd all be done in the client. The canned animation would play and when the prims running the tweak got into a certain range of each other they'd get pulled gently together like magnets in jello. The two different clients might not see the same things happening at quite the same time, but that's already true for canned animations. From dahliatrimble at gmail.com Sat Jun 6 16:47:52 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sat, 6 Jun 2009 16:47:52 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2AF169.6040809@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> Message-ID: I dont think the math or the complexity of IK is beyond all of the scripters in SL, There are some talented scripters around who could easily solve the problem, some of them in SL may even be PhD level mathematicians ;) Rather I think synchronization and lag would prevent a lot of real time on-the-fly animations. Currently animations are pre-recorded and many are cached. There is a quite noticeable delay when new animations are signaled by the sim before the clients play them, due to the need for the viewer to request and download the asset. The assets are highly compressed and may only be a few kbytes for any animation sequence. I don't think that computing IK on the fly is all that expensive either, it may only be a few hundred floating point operations per keyframe for each skeleton, certainly not expensive for modern day hardware. I *do* think that if real time on-the-fly animations were to be implemented in any kind of believable sense, there would need to be an improvement made in the speed in which the data could be distributed between clients. Somehow I don't see it as possible with the current load that many SL sims have to deal with already. On Sat, Jun 6, 2009 at 3:44 PM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Argent Stonecutter wrote: > > I don't think it would be anywhere near so hard as getting a reliable > > animation overrider to work in the first place. :) > > > > Have you looked at the source for Franimation/ZHAO? Oh, there's a > > certain amount of gratuitous yak-shaving in the code, but there's all > > KINDS of special cases... and even then I'm always tinkering with my > > copy to try and stop things like the skipping-up-steps effect. > > You are missing a crucial difference - an AO merely plays "pre-cooked" > animations, turning off one and turning on another one. That is the > trivial part. The script only triggers them. The special cases are due > to the fact that an AO is a gross hack working around the fact that > there is no way to tell SL to play different animations instead of the > default ones. > > Generating a procedural animation, be it IK, simple reaching anim or > walkcycle is several orders of magnitude more difficult - you have to > actually control the whole thing and calculate positions/orientations of > every joint and blend it properly. And you are likely doing this on the > server, because otherwise you wouldn't be able to synchronize two avatars. > > Of course, from the script's point of view, it would be all black box. > However, tweaking the inputs, e.g. for IK, is far from trivial, > requiring deep understanding of how the skeleton works and the math > behind. How many scripters actually understand the concept behind the > rotation type (quaternion) and hierarchical transformations that are the > basic element of this? Here you will be giving the scripters another > black magic tool like that, probably even more complex. I doubt that > many people would be capable of using it effectively. > > Regards, > > Jan > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKKvFmn11XseNj94gRArJ3AJwL5C0xxUvpegDId0kygys2zYOwyACg60VD > Cm60iX0BFbOI6SsYzRPAzVQ= > =YoL6 > -----END PGP SIGNATURE----- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090606/a95103d4/attachment.htm From jan.ciger at gmail.com Sat Jun 6 20:53:11 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun, 07 Jun 2009 05:53:11 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> Message-ID: <4A2B39A7.6080001@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > If I was talking about a complete procedural animation from scratch, > sure, but I'm not. I'm talking about using IK to tweak a canned > animation slightly to adjust for differences between avatars. But you still need to do those calculations. The way this is done is by interpolating quaternions between the pose generated by IK and the original pose, taking the weighting into account, not just modifying the end of the hand, for example. That could lead to inconsistencies, like "rubber-like" stretching limbs if the other joints are not moved correctly as well. Then it needs to be blended with whatever other animations the av is doing (e.g. walking + reaching). And this is still the most primitive approach of how to use IK to modify animations. Of course, this is not something the script will do, but someone has to implement the "magic" behind the LSL function you want ... The relevant code is today on the client *only*. At least part of it would need to be server-side if you want to synchronize two avatars somehow. > It'd all be done in the client. The canned animation would play and > when the prims running the tweak got into a certain range of each > other they'd get pulled gently together like magnets in jello. The two > different clients might not see the same things happening at quite the > same time, but that's already true for canned animations. I do not see what will be really the advantage of all this if it will be client-side only and not same for everyone (my IK solution can be completely different from yours due to lag, numeric accuracy issues, slower machine, etc.). A much simpler and better looking result could be achieved by just implementing synchronization for animations. Then you know that when you start hugging someone at a certain position, he starts too at the right position and you meet correctly. You do not need any IK for that, a huge boon for already slow clients. This is how games implement it - you won't find any IK in today's game engines. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKKzmjn11XseNj94gRAuPxAJ9dWfD/JwE2i16cTK5KcNUgoGyEsACeOrU1 3p6NirL5Rm4XjLSUOnzayaE= =p7/d -----END PGP SIGNATURE----- From jan.ciger at gmail.com Sat Jun 6 21:15:41 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun, 07 Jun 2009 06:15:41 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> Message-ID: <4A2B3EED.1050301@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dahlia Trimble wrote: > I dont think the math or the complexity of IK is beyond all of the > scripters in SL, There are some talented scripters around who could > easily solve the problem, some of them in SL may even be PhD level > mathematicians ;) Right :) I didn't say there aren't any, but that they are tiny minority. I do happen to have that PhD, but most people I know that are scripting (and even very good scripters) don't. Of course, that doesn't mean anything, but I somehow do not think that an average SL creator will be able to use it meaningfully. > Rather I think synchronization and lag would prevent a > lot of real time on-the-fly animations. There is no synchronization at the moment. That is one issue I have described on my reply to Argent. If we had that, I think we won't need IK for the most part. It would be interesting to have it, but 99% of things people would want it for could be done by pre-baked but synchronized animations. > I don't think that computing IK on the fly is all that expensive either, > it may only be a few hundred floating point operations per keyframe for > each skeleton, certainly not expensive for modern day hardware. Eh, did you try? Do you realize that you are dealing with heavily underconstrained problem that even with 15 joints (that is what SL avatars have, if I recall right) will generate lots of solutions and you need to weed bad ones out somehow. That takes time and computational power. We were doing semi-real-time IK on decent machines with 70+ joints (HAnim skeleton), but you could definitely feel the impact (character "thinking" for a few seconds every time IK was triggered). And that was only *one* guy. Now imagine a sim with 5 couples dancing (e.g. ballroom), some people hugging or whatever - and you are calculating IK for every one of them suddenly. The impact would be terrible. You can see an example of the performance here: http://vrlab.epfl.ch/Movies/Movies_index.html Look at the "Counting Beers" video. The characters look ugly even compared to SL, but that was back in 2005 and the design wasn't the point of the video. The animations are all procedurally generated except the few guys dancing and one guy drinking the beer. The walking is procedural, the grasping is IK + special grasping code of my colleague. There you can see clearly also the delays due to the IK solver - e.g. when the two guys are exchanging the beer. And that was on a single, fairly decent machine and heavily tweaked. Moreover, if I recall correctly, it wasn't even using all the joints - I think we have constrained it to upper body only for performance reasons. It won't be too much faster today, because the issue are the algorithms, not the raw number crunching power. The website also shows work on motion re-targeting and adaptation using IK which is state of the art. That should give you an idea what is doable and at what cost - but many of the IK videos are/were produced offline in Maya (calculated using the lab's code and rendered in Maya). It would have been way too slow in real time. > I *do* think that if real time on-the-fly animations were to be > implemented in any kind of believable sense, there would need to be an > improvement made in the speed in which the data could be distributed > between clients. Somehow I don't see it as possible with the current > load that many SL sims have to deal with already. Yes, that is the synchronization issue. That would need to be sorted out first, before any attempts at things like this. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKKz7tn11XseNj94gRAp7BAJ99kNbZev+b6+BteuwVW5SDMEot8ACgvVJJ 5M6MycOEFfj5oHPB2SiVDDs= =Mekj -----END PGP SIGNATURE----- From tateru.nino at gmail.com Sat Jun 6 21:42:02 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun, 07 Jun 2009 14:42:02 +1000 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <5766ABAF-958F-4044-9674-F320751EB032@gmail.com> References: <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> <20090606001400.GA13914@alinoe.com> <4A29F208.5070809@gmail.com> <5766ABAF-958F-4044-9674-F320751EB032@gmail.com> Message-ID: <4A2B451A.9010803@gmail.com> Argent Stonecutter wrote: > On 2009-06-05, at 23:35, Tateru Nino wrote: > >> Avatars don't occupy a common coordinate-space, however. All we >> really know about the avatar is that it is drawn based on the >> position of the dimensionless point representing the agent (and >> offset up to 10m or so within a volume centered on that point). The >> avatar itself (AFAIK) exists in its own independent coordinate- >> space, sans reference to the common coordinate-space in which other >> agents are positioned, and with even less relation to the coordinate- >> spaces of other avatars. >> > > But in the viewer the avatar shares a coordinate space with the world. > Flexible prims attached to the avatar object global forces, not local > ones. Particles from prims attached to the avatar obey a global > coordinate space and can target prims attached to other avatars. > That's the coordinate space this hypothetical "IK tweaking call" would > operate in. > But that's all very dependent on the viewer, which is a wee bit less than deterministic - so it would be plesiokinematic, basically? Everyone would see something different, but that's okay so long as they also see something similar? -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090607/38b820f5/attachment.htm From dahliatrimble at gmail.com Sat Jun 6 21:46:01 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sat, 6 Jun 2009 21:46:01 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2B3EED.1050301@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> Message-ID: Impressive video.. I liked the part where he grabs the beer. Most of my experience with IK animation is using tools such as 3DS Max and blender. I have done a small bit of procedural animation in SL, here are a few examples: http://www.youtube.com/watch?v=VqdeEIa_Ehs http://vimeo.com/946012 all calculations are done in real time in both of those videos. And yes, those are simulated joints ;) There is a crude form of synchronization of animations in SL now, it's usually used in "couple animating poseballs". It assumes that animation sequences have been cached by both viewers and the animations will both start within a close tolerance. There is no start time designated in the signal, the viewers respond when the start message is received so any delays will reduce the quality of the synchronization. On Sat, Jun 6, 2009 at 9:15 PM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dahlia Trimble wrote: > > I dont think the math or the complexity of IK is beyond all of the > > scripters in SL, There are some talented scripters around who could > > easily solve the problem, some of them in SL may even be PhD level > > mathematicians ;) > > Right :) I didn't say there aren't any, but that they are tiny minority. > I do happen to have that PhD, but most people I know that are scripting > (and even very good scripters) don't. Of course, that doesn't mean > anything, but I somehow do not think that an average SL creator will be > able to use it meaningfully. > > > Rather I think synchronization and lag would prevent a > > lot of real time on-the-fly animations. > > There is no synchronization at the moment. That is one issue I have > described on my reply to Argent. If we had that, I think we won't need > IK for the most part. It would be interesting to have it, but 99% of > things people would want it for could be done by pre-baked but > synchronized animations. > > > I don't think that computing IK on the fly is all that expensive either, > > it may only be a few hundred floating point operations per keyframe for > > each skeleton, certainly not expensive for modern day hardware. > > Eh, did you try? Do you realize that you are dealing with heavily > underconstrained problem that even with 15 joints (that is what SL > avatars have, if I recall right) will generate lots of solutions and you > need to weed bad ones out somehow. That takes time and computational power. > > We were doing semi-real-time IK on decent machines with 70+ joints > (HAnim skeleton), but you could definitely feel the impact (character > "thinking" for a few seconds every time IK was triggered). And that was > only *one* guy. Now imagine a sim with 5 couples dancing (e.g. > ballroom), some people hugging or whatever - and you are calculating IK > for every one of them suddenly. The impact would be terrible. > > You can see an example of the performance here: > http://vrlab.epfl.ch/Movies/Movies_index.html > > Look at the "Counting Beers" video. The characters look ugly even > compared to SL, but that was back in 2005 and the design wasn't the > point of the video. The animations are all procedurally generated except > the few guys dancing and one guy drinking the beer. The walking is > procedural, the grasping is IK + special grasping code of my colleague. > There you can see clearly also the delays due to the IK solver - e.g. > when the two guys are exchanging the beer. And that was on a single, > fairly decent machine and heavily tweaked. Moreover, if I recall > correctly, it wasn't even using all the joints - I think we have > constrained it to upper body only for performance reasons. It won't be > too much faster today, because the issue are the algorithms, not the raw > number crunching power. > > The website also shows work on motion re-targeting and adaptation using > IK which is state of the art. That should give you an idea what is > doable and at what cost - but many of the IK videos are/were produced > offline in Maya (calculated using the lab's code and rendered in Maya). > It would have been way too slow in real time. > > > > I *do* think that if real time on-the-fly animations were to be > > implemented in any kind of believable sense, there would need to be an > > improvement made in the speed in which the data could be distributed > > between clients. Somehow I don't see it as possible with the current > > load that many SL sims have to deal with already. > > Yes, that is the synchronization issue. That would need to be sorted out > first, before any attempts at things like this. > > Regards, > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFKKz7tn11XseNj94gRAp7BAJ99kNbZev+b6+BteuwVW5SDMEot8ACgvVJJ > 5M6MycOEFfj5oHPB2SiVDDs= > =Mekj > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090606/267bfd8c/attachment.htm From jan.ciger at gmail.com Sun Jun 7 06:07:09 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun, 07 Jun 2009 15:07:09 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> Message-ID: <4A2BBB7D.3030001@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dahlia, Dahlia Trimble wrote: > Impressive video.. I liked the part where he grabs the beer. Thanks. Or rather that should go to my ex-colleague Tolga who has done the automatic grasping for his PhD. > Most of my experience with IK animation is using tools such as 3DS Max > and blender. I have done a small bit of procedural animation in SL, here > are a few examples: > > http://www.youtube.com/watch?v=VqdeEIa_Ehs > > http://vimeo.com/946012 > > all calculations are done in real time in both of those videos. And yes, > those are simulated joints ;) Nice, that is a cute hack. Didn't see this done before. I guess the sim owners are going to hate you for the load these scripts have to produce :-p Re Max/Blender - that is a different issue, and apples to oranges comparison. There you get realtime IK but with only one end-effector moving at a time (e.g. hand), and it is heavily constrained, typically in 2D plane aligned with your camera view where you are dragging it. You do not have that luxury when animating something like that beer grasping (the solver needs to work in all 3 dimensions at the same time). Also, you have other issues adding complexity - e.g. maintaining balance of the character. If you are reaching for something far away, you will stretch out your leg to keep your center of mass above your other leg - otherwise you would fall over. The IK in the beer video can actually do that (look at the other IK videos at the website - it is the same IK solver), but I have never seen something even close to that in Max or Maya. This is also why the simplistic approach with "only modifying existing animation and locking/weighting down joints" as Argent described wouldn't work - if you lock down the feet ("I am only reaching for things!"), you either wouldn't be able to find the solution (with the VRlab's solver and the balance constraint on) or it would look completely wrong once the object is out of arm's range and you need to bend over to get it. > There is a crude form of synchronization of animations in SL now, it's > usually used in "couple animating poseballs". It assumes that animation > sequences have been cached by both viewers and the animations will both > start within a close tolerance. There is no start time designated in the > signal, the viewers respond when the start message is received so any > delays will reduce the quality of the synchronization. Well, that is not really any synchronization. I am speaking about frame-by-frame sync, or at least synchronizing every few frames with interpolation between. The poseball animations will drift apart after a few seconds, no matter what you are doing. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKK7t6n11XseNj94gRArXyAJ4/oEhlBjCE3BXeCyWNTOPYafmSsgCfQ2Fh c/vnrhwgtZq6IJ4/6DL29c8= =ceeb -----END PGP SIGNATURE----- From secret.argent at gmail.com Sun Jun 7 07:01:26 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 7 Jun 2009 09:01:26 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2B3EED.1050301@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> Message-ID: <12A78011-28E3-420E-8A66-45F79345631C@gmail.com> On 2009-06-06, at 23:15, Jan Ciger wrote: > There is no synchronization at the moment. That is one issue I have > described on my reply to Argent. If we had that, I think we won't need > IK for the most part. It would be interesting to have it, but 99% of > things people would want it for could be done by pre-baked but > synchronized animations. Even without synchronization pre-baked animations are inadequate if your avatar is even slightly different from the one the animation creator built into it. We're all cursed by limbs poking into our bodies or floating in the air. Even if you could easily build animations *for your avatar* and edit them in-world, that wouldn't help people building furniture and the like that has to work with differently shaped avatars. You're assuming a MUCH more complex and sophisticated system than I'm talking about. I'm looking at situations where the completely crude "left arm pointing to the thing your editing", limited to small changes, would produce 1000% improvement in the world. From secret.argent at gmail.com Sun Jun 7 07:02:33 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 7 Jun 2009 09:02:33 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2B451A.9010803@gmail.com> References: <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> <20090606001400.GA13914@alinoe.com> <4A29F208.5070809@gmail.com> <5766ABAF-958F-4044-9674-F320751EB032@gmail.com> <4A2B451A.9010803@gmail.com> Message-ID: <971101D7-722E-4B3A-9132-1157FAD5B6B5@gmail.com> On 2009-06-06, at 23:42, Tateru Nino wrote: > Everyone would see something different, but that's okay so long as > they also see something similar? That's how SL works. We don't even see avatars facing in the same direction at the same time, currently. From secret.argent at gmail.com Sun Jun 7 07:13:45 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 7 Jun 2009 09:13:45 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2BBB7D.3030001@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <4A2BBB7D.3030001@gmail.com> Message-ID: <1A5B8EFF-52DD-445C-A325-33DF86CCD5A6@gmail.com> On 2009-06-07, at 08:07, Jan Ciger wrote: > This is also why the simplistic approach with "only modifying existing > animation and locking/weighting down joints" as Argent described > wouldn't work - if you lock down the feet ("I am only reaching for > things!"), you either wouldn't be able to find the solution (with the > VRlab's solver and the balance constraint on) or it would look > completely wrong once the object is out of arm's range and you need to > bend over to get it. That's WAY more sophisticated and computationally expensive than I'm suggesting. Imagine a canned animation having the avatar drinking a beer. The avatar is siting on a barstool, and he's wearing the beer and a target prim in his mouth. His upper body bends back slightly and his arm lifts. When his hand (holding the beer) gets within a foot of the target prim the preloaded override provided by the script starts adjusting the elbow and shoulder by a few degrees... making the motion move the beer to where his mouth actually is, instead of 5cm inside his head. That's the problem I'm interested in solving. not the much harder problem you're talking about. In your example, if the object is out of range nothing would happen. The existing animation would run... so the worst case is no worse than what we have now. From dmahalko at gmail.com Sun Jun 7 07:56:50 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun, 7 Jun 2009 09:56:50 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <1A5B8EFF-52DD-445C-A325-33DF86CCD5A6@gmail.com> References: <4A2463D7.9050604@Gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <4A2BBB7D.3030001@gmail.com> <1A5B8EFF-52DD-445C-A325-33DF86CCD5A6@gmail.com> Message-ID: In general I expect that scripted interaction animations have to be somewhat unreal to deal with issues of latency and alignment. Neither participating avatar can be expected to be aligned "just right" to perform any given action on the fly So they both virtually step forward to align with the scripted motion, perform it, and then step back to their original position... even though on the sim side neither avatar actually moves. Due to the issue of limb positions sinking inside for prim-bodied avatars, the existing rigid-position animating isn't good enough, since a given handshake animation may look all wrong applied to a prim-bodied AV vs a standard AV. If you want to get serious about it, the motion system needs to have adjustable min/max positions for where limbs can be located relative to the body shape, practically doing physical collisions of say elbow/wrist vs prim-body surface and knowing limits of arm rotation/bend, and having the whole avatar move closer or away in situations where the movements are either out of range of normal arm motion or are causing arm-to-body collision. How does an adult shake hands with a child? The arms of the child are too short so the adult is required to either bend over at the waist or bend the knees, or both. Can your interaction solver handle this extreme situation? Though it's a total joke to discuss this in relation to the current avatar animation system. Arbitrarily tall or short avatars are not permitted. The avatar needs to be weirdly distorted to make tiny AVs, so there IS no hand/arm/elbow to do interaction with, on a tiny avatar.. The existing avatar animation systerm would have to be thrown away and replaced with something that really does allow avatars down to 10 cm tall, with 2 cm long appendages, to allow dynamic direct-calculated AV-to-AV interactions. I'm not volunteering for this. :-) - Dale Mahalko / Scalar Tardis From dmahalko at gmail.com Sun Jun 7 08:18:10 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun, 7 Jun 2009 10:18:10 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <4A2BBB7D.3030001@gmail.com> <1A5B8EFF-52DD-445C-A325-33DF86CCD5A6@gmail.com> Message-ID: Worse yet, what about the avatars which don't have hands? Under the current avatar animation system, for a dragon avatar to have smooth non-jerky wing motion, the avatar may be warped to make the arms into wings which get an overrider for smooth flapping motion, and the arms may only just be unmovable prims. Heh, the avatar should be a free form skeleton definable with N-number of appendages (255 max), two of which can be assigned the standard "LHand/RHand" identifier and thus shakable, while other unlabeled appendages in excess of the standard appendage label allotment are unselectable for action via scripts but still animatable within the avatar itself. This way you can have an Pacific Northwest Tree Octupus avatar with 8 moveable avatar appendages, two of which can be used for shaking hands, dancing, etc. Or a centuar avatar with defined LHand/RHand for shaking hands, etc, distinct from the two pairs of feet. Or a millipede avatar... I'm not sure how a snake/worm would be handled. In that case perhaps the Head labeled appendage also has the LHand/RHand label.. Oh, and getting back on thread topic, how do you map realtime visual motion of a person sitting in front of their computer onto a Tree Octopus avatar? - Dale Mahalko / Scalar Tardis From tateru.nino at gmail.com Sun Jun 7 08:54:39 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 08 Jun 2009 01:54:39 +1000 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <1A5B8EFF-52DD-445C-A325-33DF86CCD5A6@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <4A2BBB7D.3030001@gmail.com> <1A5B8EFF-52DD-445C-A325-33DF86CCD5A6@gmail.com> Message-ID: <4A2BE2BF.7000402@weblogsinc.com> Argent Stonecutter wrote: > On 2009-06-07, at 08:07, Jan Ciger wrote: > >> This is also why the simplistic approach with "only modifying existing >> animation and locking/weighting down joints" as Argent described >> wouldn't work - if you lock down the feet ("I am only reaching for >> things!"), you either wouldn't be able to find the solution (with the >> VRlab's solver and the balance constraint on) or it would look >> completely wrong once the object is out of arm's range and you need to >> bend over to get it. >> > > That's WAY more sophisticated and computationally expensive than I'm > suggesting. > > Imagine a canned animation having the avatar drinking a beer. The > avatar is siting on a barstool, and he's wearing the beer and a target > prim in his mouth. His upper body bends back slightly and his arm > lifts. When his hand (holding the beer) gets within a foot of the > target prim the preloaded override provided by the script starts > adjusting the elbow and shoulder by a few degrees... making the motion > move the beer to where his mouth actually is, instead of 5cm inside > his head. > > That's the problem I'm interested in solving. not the much harder > problem you're talking about. > > In your example, if the object is out of range nothing would happen. > The existing animation would run... so the worst case is no worse than > what we have now. So, if I've got this straight, the problem is essentially two-fold: 1) Something (probably the viewer) should ideally be solving for specific animation outcomes (possibly by adapting template/guideline animations) and, 2) There's currently no actual way to specify what those outcomes are. -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090608/91f0d2f0/attachment.htm From jan.ciger at gmail.com Sun Jun 7 08:54:39 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun, 07 Jun 2009 17:54:39 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <52B3EE50-7492-40C1-9497-07C079DC6D73@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B39A7.6080001@gmail.com> <52B3EE50-7492-40C1-9497-07C079DC6D73@gmail.com> Message-ID: <4A2BE2BF.5080603@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > Of course, the actual modifications would be small angles applied to the > joints. A few degrees at most. If the motion goes outside the range it > just doesn't happen. That would be an incredibly frustrating experience - it would work sometimes and sometimes not, only because the av was a centimeter farther than last time and the IK couldn't converge any more because of your too tight constraints. > >> That could lead to inconsistencies, like >> "rubber-like" stretching limbs if the other joints are not moved >> correctly as well. > > How do you get stretching from an animation system that's only changing > angles? You don't. However you are forgetting that once you are interpolating between the original pose and an IK generated pose, you are screwed in this regard. The angles produced by blending may not be consistent in this way, twisting and stretching the body out of shape. This is why motion adaptation by IK is so difficult - these cases need to be recognized and ruled out or fixed somehow. Just imagine the following interpolation/blending - hand and lower arm from IK and the upper arm from the original keyframe. Suddenly your elbow is stretched and twisted, because the upper arm from the keyframe is completely elsewhere than where the IK needs it. > That's already an issue for multi-animation scripts. It's handled by > eye. Does this combination look right to me? What do you mean "handled by eye"? The animation engine does this automatically - that is what the animation priorities in SL are for when you are uploading animations. I am not talking about "baking animations" into one final keyframe file in Max or Blender here, but about real-time blending - a guy walking, turning his head and waving, while still continuing to walk. Think of playing a gesture while walking in Sl. > None of it would need to be on the server side. There's no > synchronization between different screens in SL, even when effects > associated with avatars are synchronized (eg, particle targets for leash > effects) on each individual screen. That is not relevant. The fact that there is no synchronization now doesn't mean you won't need it if you want to achieve consistent grasping that will look correct to everyone looking at it. If you do everything client side, everyone will see different thing - with IK even WILDLY different. A tiny accuracy difference introduces huge and accumulating errors in IK solvers. > In the absence of lag, we already have synchronization. In the presence > of lag, synchronization fails. Eh? What synchronization exactly? That you start the animations at the same time? I am not sure that you know what synchronization is actually about. That is *not* sufficient - the machines run at slightly different speed, with different load and what not, you get the animations drifting apart almost immediately. Lag or no lag, even if you started the animations at perfect same moment. Saying that we have "synchronization" in the absence of lag reminds me of my former colleague who claimed that everything synchronization-related will be solved if we can synchronize the random number generators at the different computers (as if the RNGs were somehow the cause of drift in the animations ...) > But there's no synchronization between clients, just between avatars on > each client. There is no synchronization between any avatars neither - btw, client and avatar, what do you mean? As if the avatar was not only on the client or what ... This is why you need proper animation synchronization first, before we can think about "shaking hands", "hugging people" or whatever else. It is doable, but with quite a bit of network overhead. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKK+K8n11XseNj94gRAvfuAJ9MX6o49Nx1Su0gAAOb5tzMiWSFswCZARcz ihow9lVKu3owoYvBjieDY+A= =Pfk+ -----END PGP SIGNATURE----- From jan.ciger at gmail.com Sun Jun 7 08:58:48 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun, 07 Jun 2009 17:58:48 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <12A78011-28E3-420E-8A66-45F79345631C@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <12A78011-28E3-420E-8A66-45F79345631C@gmail.com> Message-ID: <4A2BE3B8.8080208@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > Even without synchronization pre-baked animations are inadequate if > your avatar is even slightly different from the one the animation > creator built into it. We're all cursed by limbs poking into our > bodies or floating in the air. Even if you could easily build > animations *for your avatar* and edit them in-world, that wouldn't > help people building furniture and the like that has to work with > differently shaped avatars. Of course. Solution to that is a motion-retargeting, but that is a whole separate issue on its own. > You're assuming a MUCH more complex and sophisticated system than I'm > talking about. I'm looking at situations where the completely crude > "left arm pointing to the thing your editing", limited to small > changes, would produce 1000% improvement in the world. I am just saying that the simplistic idea you are talking about is way too simplistic to meaningfully work. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKK+O4n11XseNj94gRAld+AJ439nKDr6Wo8cy5YE/sIxRSyH1bGwCdGZ7F CCuiLr2kwedsfqEaoakNv6M= =K039 -----END PGP SIGNATURE----- From annie66us at yahoo.com Sun Jun 7 10:24:32 2009 From: annie66us at yahoo.com (Anne Ogborn) Date: Sun, 7 Jun 2009 10:24:32 -0700 (PDT) Subject: [sldev] Body motion and facial expression tracking, Microsoft did it Message-ID: <459139.10051.qm@web42108.mail.mud.yahoo.com> In the games world this sort of on the fly IK is usually called 'behaviors'. NaturalMotion sells a commercial system that does this sort of thing, as does Havok. The Havok system has more promise but is less developed than the NaturalMotion one. I'm not too convinced either one would be a good thing to include in the viewer. From secret.argent at gmail.com Sun Jun 7 11:24:50 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 7 Jun 2009 13:24:50 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2BE2BF.5080603@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A247506.1000108@lindenlab.com> <4A247F1F.4060205@streamsense.net> <4A249FBA.308@dragonkeepcreations.com> <4A24A36C.503@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B39A7.6080001@gmail.com> <52B3EE50-7492-40C1-9497-07C079DC6D73@gmail.com> <4A2BE2BF.5080603@gmail.com> Message-ID: <9EA1B62B-97A9-47DE-A88A-C5AA62CF8E6F@gmail.com> On 2009-06-07, at 10:54, Jan Ciger wrote: > Argent Stonecutter wrote: >> Of course, the actual modifications would be small angles applied >> to the >> joints. A few degrees at most. If the motion goes outside the range >> it >> just doesn't happen. > That would be an incredibly frustrating experience - it would work > sometimes and sometimes not, only because the av was a centimeter > farther than last time and the IK couldn't converge any more because > of > your too tight constraints. It would be no more frustrating than the current situation. And when you're sitting on a barstool, or running an animation involving only your own body, the avatar would never be in the wrong place. > You don't. However you are forgetting that once you are interpolating > between the original pose and an IK generated pose I didn't mention any separate "IK generated pose". > Just imagine the following > interpolation/blending - hand and lower arm from IK and the upper arm > from the original keyframe. Suddenly your elbow is stretched and > twisted, because the upper arm from the keyframe is completely > elsewhere > than where the IK needs it. The IK would only be applied when the keyframe is almost but not quite in the right position. When the keyframe moves it out of range the IK cuts out. SL already does this cutting between animations that have lead-in and lead-out times, and sometimes it looks funky when you have the wrong animations, but usually it looks OK. >> That's already an issue for multi-animation scripts. It's handled by >> eye. Does this combination look right to me? > What do you mean "handled by eye"? I mean you sit there and run this animation on the legs and hips and apply this one that is restricted to the upper body and you look at the result and say "yes, that works" or "no, that looks weird". In this case you'll poke the values into the override list, and run the animation, and go "OK, that looks OK", or "no, that doesn't work". And I still think you're talking about a completely different system than the one I'm talking about. >> But there's no synchronization between clients, just between >> avatars on >> each client. > There is no synchronization between any avatars neither - btw, client > and avatar, what do you mean? As if the avatar was not only on the > client or what ... Right now, in second life, what I see when I look at a pair of avatars standing next to each other may be completely different than what you see. They may be as much as 30 or 40 degrees different on out two computers. It doesn't matter if on my computer we start hugging a few seconds later than we start hugging on your computer. It doesn't matter if I see you turn towards me on my computer, and you see me turn towards you on your computer. Our computers don't need to be in sync with each other, at all. From secret.argent at gmail.com Sun Jun 7 11:26:55 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 7 Jun 2009 13:26:55 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2BE3B8.8080208@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <12A78011-28E3-420E-8A66-45F79345631C@gmail.com> <4A2BE3B8.8080208@gmail.com> Message-ID: On 2009-06-07, at 10:58, Jan Ciger wrote: >> You're assuming a MUCH more complex and sophisticated system than I'm >> talking about. I'm looking at situations where the completely crude >> "left arm pointing to the thing your editing", limited to small >> changes, would produce 1000% improvement in the world. > I am just saying that the simplistic idea you are talking about is way > too simplistic to meaningfully work. It already does work, I've done it, using the "left hand editing" effect to override an animation by having it track a prim in the right place. From secret.argent at gmail.com Sun Jun 7 11:41:15 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 7 Jun 2009 13:41:15 -0500 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2BE2BF.7000402@weblogsinc.com> References: <4A2463D7.9050604@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <4A2BBB7D.3030001@gmail.com> <1A5B8EFF-52DD-445C-A325-33DF86CCD5A6@gmail.com> <4A2BE2BF.7000402@weblogsinc.com> Message-ID: <23EC0B7A-32A3-4F25-A8C3-BF098214F32A@gmail.com> On 2009-06-07, at 10:54, Tateru Nino wrote: > So, if I've got this straight, the problem is essentially two-fold: > 1) Something (probably the viewer) should ideally be solving for > specific animation outcomes (possibly by adapting template/guideline > animations) and, > 2) There's currently no actual way to specify what those outcomes are. Fixing 2 is what I'm suggesting. You specify the outcomes the same way you specify where particles go when you "blow a kiss" or "attach a leash" using particles. You wear prims, and tell the viewer that you want those prims to touch if they get close enough that they're "almost touching". From tateru.nino at gmail.com Sun Jun 7 11:50:53 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 08 Jun 2009 04:50:53 +1000 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <459139.10051.qm@web42108.mail.mud.yahoo.com> References: <459139.10051.qm@web42108.mail.mud.yahoo.com> Message-ID: <4A2C0C0D.1050801@gmail.com> Linden Lab is a NaturalMotion licensee, last I looked. Anne Ogborn wrote: > In the games world this sort of on the fly IK is usually called 'behaviors'. > > NaturalMotion sells a commercial system that does this sort of thing, > as does Havok. > > The Havok system has more promise but is less developed than the NaturalMotion one. > > I'm not too convinced either one would be a good thing to include in the viewer. > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090608/cc30af73/attachment.htm From jan.ciger at gmail.com Sun Jun 7 12:19:20 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sun, 07 Jun 2009 21:19:20 +0200 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <4A2BBB7D.3030001@gmail.com> Message-ID: <4A2C12B8.7000904@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dahlia Trimble wrote: > But that's not how SL works at all. The animated avatar is decoupled > from the physical representation on the simulator. The physical "agent" > is a simple shape and does not take the mass of the avatar appendages > into account. It is also constrained stand upright. In most cases the > beer would have no mass and would not even be "grabbed", but would be > "attached" to the hand of the avatar skeleton. Right, I didn't say that is the way SL works or should work. However, this is the way to go if you want to produce realistic looking results. Otherwise your character will behave like a Wile E. Coyote braking at the edge of a cliff using his toes. If a human did that, he would fall over, basic physics. The engine we have used allowed to satisfy this constraint as well, most commercial ones don't. > From there the only IK > solving would be moving the beer to the mouth and tilting the glass. A > well designed procedural animation algorithm that took gravity into > account might make changes to the entire skeleton to give the appearance > of the avatar compensating for the changes in center of mass, That is something else. The IK solution I have described above is purely kinematic (i.e. no physics involved). However, it has an extra constraint to force the centre of gravity of the character to be between the legs, so that the generated pose would be stable if you did the physical simulation or tried to assume that pose yourself. It may force the solver to extend one leg to counter-balance the character, but again, only centre of gravity is calculated, not really any physical simulation. Try to stand upright and then start leaning forward. At some point you have to either make a step or extend your leg backwards to stop falling over. That is what the solver was doing. It brings added realism to the animations and rules out poses that could reach the goal, but are not realistic for a normal human (standing on tiptoes at a 45 degree angle, for example). > I think adding the ability to do *simple* tweaks to existing animations > such as aligning avatars for a handshake might be helpful feature. Yep, but you do not need IK for that. And IK will still not help you with vastly different skeleton sizes - i.e. if my arm is too short, IK cannot make it "longer" to reach you. Not to mention that there seems to be the impression that "making tweaks to existing animations" is somehow "simpler". It is not - you only load the solver with more constraints. > Currently scripts have no access to any keyframe data, which makes sense > since animations are not synchronized. Not sure how are these things actually related. However, even if you had access to the raw keyframe data (joint orientations/positions), it wouldn't help you much - both LSL and Mono are way too slow and limited to do anything meaningful with them in real time. > Scripts currently can change the > position of an avatar but not rotate it. For something like a handshake, > I think letting a script compute the avatar positions and rotations and > then making adjustments to the hand positions could produce a higher > quality handshake than can be done in SL today. Unfortunately the > current system will not allow it. You can always put two guys on aligned poseballs and it will work just fine, as proved by all the people doing various naughty stuff in SL every day. However, it will work only within the limits of the guys having skeletons compatible with the animation (but IK will not really help you there) and missing animation synchronization (where local, client-only IK is a bad and performance expensive kludge, IMO). To conclude this discussion on IK - if someone knows how to program in C++ and wants to play with IK, have a look at HMS IKAN library: http://cg.cis.upenn.edu/hms/software/ikan/ikan.html It allows up to three joints (I think) to be simulated, e.g. an arm or leg. We have used this library for initial development, it does work, but you will quickly see the problems I was talking about in my previous e-mails. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKLBK4n11XseNj94gRAt0xAJ9PKwSXsqJmDwIpeVWU83IPFpoTIACg41+P loliFqbxuaUJFrJM0pHqBqQ= =7Hud -----END PGP SIGNATURE----- From sllists at boroon.dasgupta.ch Sun Jun 7 14:05:17 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 07 Jun 2009 23:05:17 +0200 Subject: [sldev] [IDEA] MD instead of IK (was: Body motion and facial expression tracking, Microsoft did it) In-Reply-To: <4A2C12B8.7000904@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <4A2BBB7D.3030001@gmail.com> <4A2C12B8.7000904@gmail.com> Message-ID: <4A2C2B8D.1030809@boroon.dasgupta.ch> Jan Ciger schrieb: > Try to stand upright and then start leaning forward. At some > point you have to either make a step or extend your leg backwards to > stop falling over. That is what the solver was doing. It brings added > realism to the animations and rules out poses that could reach the goal, > but are not realistic for a normal human (standing on tiptoes at a 45 > degree angle, for example). Wouldn't a static center of mass analysis rule out solutions that just aren't possible in statics, but are very well possible as part of a dynamic movement where inertia comes into play? Also, a lot of today's canned animations are purposely displaying unphysical behavior to achieve special effects (magic, slow motion, flying/hovering) or just to be funny. Some of them might profit from the proposed retargeting, but would be destroyed if the solver would only allow for physically possible solutions. > > > I think adding the ability to do *simple* tweaks to existing animations > > such as aligning avatars for a handshake might be helpful feature. > > Yep, but you do not need IK for that. And IK will still not help you > with vastly different skeleton sizes - i.e. if my arm is too short, IK > cannot make it "longer" to reach you. Not to mention that there seems to > be the impression that "making tweaks to existing animations" is somehow > "simpler". It is not - you only load the solver with more constraints. Maybe I'm being naive here ... but if the problem is underconstrained, isn't more constraints what you need so reduce the number of solutions? (As long as the constraints don't contradict each other, that is.) Though, to get the magnets-in-jello effect Argent was talking about, MD with bond constraints and proper damping might do the trick cheaper (both, implementation and performance wise) than real IK does. Combining it with canned animations shouldn't be too difficult, either. The force fields could probably even be chosen such that limbs are very unlikely to penetrate the body. cheers Boroondas From melinda at superliminal.com Sun Jun 7 14:10:20 2009 From: melinda at superliminal.com (Melinda Green) Date: Sun, 07 Jun 2009 14:10:20 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2C12B8.7000904@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A293C3C.6070505@gmail.com> <80DED37F-DCFC-4B64-BA32-4999D532A8A6@gmail.com> <4A2AC631.7060508@gmail.com> <1AED211C-EC6F-42DA-AACA-2ED857AA0918@gmail.com> <4A2AF169.6040809@gmail.com> <4A2B3EED.1050301@gmail.com> <4A2BBB7D.3030001@gmail.com> <4A2C12B8.7000904@gmail.com> Message-ID: <4A2C2CBC.50203@superliminal.com> Jan Ciger wrote: > [...] > To conclude this discussion on IK - if someone knows how to program in > C++ and wants to play with IK, have a look at HMS IKAN library: > http://cg.cis.upenn.edu/hms/software/ikan/ikan.html > > It allows up to three joints (I think) to be simulated, e.g. an arm or > leg. We have used this library for initial development, it does work, > but you will quickly see the problems I was talking about in my previous > e-mails. The viewer already uses IK in such a simplified case in order to keep avatar's feet flush with uneven ground or other surfaces. The implementation is quite complicated and therefore buggy and and sometimes funny looking but the results are *much* better than not doing it. So far as I know, it's not terribly computationally expensive, so the question in my mind is what would be the next most valuable situation we could apply it to? Any really big overhauls are unlikely to ever happen, so what should be the next baby step? Personally I would love to see avatar hand-holding implemented but involving multiple avatars may already be too big of a step for such a proof-of-concept. Argent says that he's already done something along these lines and I would love to see the results. I like his approach of only attempting to make the minor adjustments needed to make things fit. I will offer one possible refinement to his suggestion of only attempting IK adjustments when the miss is small: I suspect that we'll want to smooth over the discontinuity between attempting and not attempting IK. I think it might be good to have three zones. Within short error distances, do as he suggests; within a somewhat larger error, use IK to get as close as possible even though it misses; and at further distances, don't invoke IK at all. For example, this would allow you to ride a motorcycle while keeping your hands on the handlebars, but when you get bumped briefly too far, you'll continue reaching for them, and when you get bumped too far, you'll give up trying to maintain your grip. It will therefore look natural when you eventually reattach to the handlebars. I expect that whatever we attempt in this way should probably involve the existing feet-to-ground code, either extending or replacing it. -Melinda From ron at involve3d.com Mon Jun 8 08:31:25 2009 From: ron at involve3d.com (Ron Blechner) Date: Mon, 8 Jun 2009 11:31:25 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A295702.4030705@gmail.com> References: <4A2463D7.9050604@Gmail.com> <4A26940F.1020403@watson.ibm.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> Message-ID: The problem with the handshake: In short - it's 2 seconds worth of interaction. That's a tiny amount of reward for a tremendous amount of work it would take to make it better. And, there are already handshake and bow animations - they don't line up with another avatar, but doing all the work to make handshakes doesn't even create a new function - it just polishes an existing one. Compare that with putting in effort to do better facial animations - that would affect 100% of the time of interaction between two people. And consider that facial animation programming is *client-side* by nature, and doesn't require breaking apart and redoing the avatar code in Second Life to the degree that handshakes / puppeteering does. That's a helluva lot more results for a helluva lot less effort. I'd also like to add that, as Lawson pointed out, there is cultural bias. According to Neilsen, there are 170 million Americans actively using social media. There are twice that in China alone. China has 20% of the world's population. Are we here to make a Western metaverse, or a global one based on ideals not bound by one country, or one culture? The reason we handshake instead of bow is because the West has controlled the vast amounts of wealth in the world. Like it or not, the West is spending its Wealth and a tremendous amount is going to the East. In 20 years - we all may be bowing, like it or not. I don't want to ruffle too many features, but it's an important exercise to escape one's own assumptions and biases when debating functionality with a platform whose stated goal is to be "a new country", as Rosedale would say. And to bring this back - the larger issue is that people tend to get caught up in particular niceties like handshakes and miss bigger-picture items. What good are handshakes if the rest of the conversation is less meaningful because it lacks facial expression? I say, FORGET puppeteering. Forget handshakes. Let's focus our efforts on something much easier to accomplish, and with far more impact on Second Life. Facial expressions from video. *runs off to blog these thoughts* -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com SL: Hiro Pendragon p.s. PLUG! http://secondtense.blogspot.com On Fri, Jun 5, 2009 at 1:33 PM, Tateru Nino wrote: > Maybe it isn't really about handshakes, and more about general > lining-up-of-body-parts between avatars? :) > > However, for most people in first-world western cultures, a handshake is the > frequently sole form of socially allowable physical contact between two > people who aren't intimates at some level. That makes it strongly symbolic. > > For handshake you can substitute a few variations: Knuckle-bumps, high-fives > and such, but they're all basically a handshake with different emotional > flavoring. > > Ron Blechner wrote: > > Question: > > Why are handshakes so important that they are much more of a topic of > discussion of implementation, against facial expressions? > > -Ron / Hiro > > On Fri, Jun 5, 2009 at 7:34 AM, Argent > Stonecutter wrote: > > > On 2009-06-04, at 08:55, Jan Ciger wrote: > > > Argent, read my comment to Tigro's mail. It wouldn't work. At least > not > in a nice way. For reaching and grasping you need much more IK than > just > the three arm joints and then you are hitting a severely > under-constrained and computationally expensive problem. > > > That's why you don't try and solve it computationally. You don't > replace normal animation, you use this for minor adjustments to the > existing animation, and you limit the strength of the adjustment to > small angles and specific joints. > > So it's down to the person selecting the base animation and providing > the strength and possibly range (either distance or angle). > > > > E.g. in one case I have seen the solver to keep the hands next to the > avatar's waist but stick the waist forward to reach a goal. > > > Wouldn't happen, unless the person selected the waist as the joint > that would move, and unless the waist was already close to the goal. > > > > IK is a nice tool, but extremely hard to use unless you have an > animator > guiding it. > > > Which is the point. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > > > > -- > Tateru Nino > http://dwellonit.taterunino.net/ > > From ron at involve3d.com Mon Jun 8 09:08:19 2009 From: ron at involve3d.com (Ron Blechner) Date: Mon, 8 Jun 2009 12:08:19 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> Message-ID: Oh, p.s. I met up with someone at the CT Film Festival this weekend who confirmed that the whole body interactive demos by Microsoft? STAGED. Entirely a mock-up demo. The technology apparently works but they're no where near actual product demo. -Ron / Hiro On Mon, Jun 8, 2009 at 11:31 AM, Ron Blechner wrote: > The problem with the handshake: > > In short - it's 2 seconds worth of interaction. That's a tiny amount > of reward for a tremendous amount of work it would take to make it > better. And, there are already handshake and bow animations - they > don't line up with another avatar, but doing all the work to make > handshakes doesn't even create a new function - it just polishes an > existing one. > > Compare that with putting in effort to do better facial animations - > that would affect 100% of the time of interaction between two people. > And consider that facial animation programming is *client-side* by > nature, and doesn't require breaking apart and redoing the avatar code > in Second Life to the degree that handshakes / puppeteering does. > That's a helluva lot more results for a helluva lot less effort. > > I'd also like to add that, as Lawson pointed out, there is cultural > bias. According to Neilsen, there are 170 million Americans actively > using social media. There are twice that in China alone. China has 20% > of the world's population. Are we here to make a Western metaverse, or > a global one based on ideals not bound by one country, or one culture? > The reason we handshake instead of bow is because the West has > controlled the vast amounts of wealth in the world. Like it or not, > the West is spending its Wealth and a tremendous amount is going to > the East. In 20 years - we all may be bowing, like it or not. > > I don't want to ruffle too many features, but it's an important > exercise to escape one's own assumptions and biases when debating > functionality with a platform whose stated goal is to be "a new > country", as Rosedale would say. > > And to bring this back - the larger issue is that people tend to get > caught up in particular niceties like handshakes and miss > bigger-picture items. What good are handshakes if the rest of the > conversation is less meaningful because it lacks facial expression? > > I say, FORGET puppeteering. Forget handshakes. Let's focus our efforts > on something much easier to accomplish, and with far more impact on > Second Life. Facial expressions from video. > > *runs off to blog these thoughts* > > > -- > Ron Blechner > Chief Technology Officer > Involve, Inc > www.involve3d.com > SL: Hiro Pendragon > > > p.s. PLUG! http://secondtense.blogspot.com > > On Fri, Jun 5, 2009 at 1:33 PM, Tateru Nino wrote: >> Maybe it isn't really about handshakes, and more about general >> lining-up-of-body-parts between avatars? :) >> >> However, for most people in first-world western cultures, a handshake is the >> frequently sole form of socially allowable physical contact between two >> people who aren't intimates at some level. That makes it strongly symbolic. >> >> For handshake you can substitute a few variations: Knuckle-bumps, high-fives >> and such, but they're all basically a handshake with different emotional >> flavoring. >> >> Ron Blechner wrote: >> >> Question: >> >> Why are handshakes so important that they are much more of a topic of >> discussion of implementation, against facial expressions? >> >> -Ron / Hiro >> >> On Fri, Jun 5, 2009 at 7:34 AM, Argent >> Stonecutter wrote: >> >> >> On 2009-06-04, at 08:55, Jan Ciger wrote: >> >> >> Argent, read my comment to Tigro's mail. It wouldn't work. At least >> not >> in a nice way. For reaching and grasping you need much more IK than >> just >> the three arm joints and then you are hitting a severely >> under-constrained and computationally expensive problem. >> >> >> That's why you don't try and solve it computationally. You don't >> replace normal animation, you use this for minor adjustments to the >> existing animation, and you limit the strength of the adjustment to >> small angles and specific joints. >> >> So it's down to the person selecting the base animation and providing >> the strength and possibly range (either distance or angle). >> >> >> >> E.g. in one case I have seen the solver to keep the hands next to the >> avatar's waist but stick the waist forward to reach a goal. >> >> >> Wouldn't happen, unless the person selected the waist as the joint >> that would move, and unless the waist was already close to the goal. >> >> >> >> IK is a nice tool, but extremely hard to use unless you have an >> animator >> guiding it. >> >> >> Which is the point. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> >> >> >> >> -- >> Tateru Nino >> http://dwellonit.taterunino.net/ >> >> > -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com From dahliatrimble at gmail.com Mon Jun 8 09:24:19 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon, 8 Jun 2009 09:24:19 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> Message-ID: A few points about the Natal video that I find difficult to believe from a technological perspective: * the actor's arms are often occluded from the sensor by their bodies yet the avatars react as if the arm positions are tracked * a few of the actors are wearing flowing clothing that can occlude body positions such as loose open sweaters * at the very beginning of one of the videos there is some text along the bottom left: "Product vision: actual features and functionality may vary" Given that, I don't think a company like Microsoft would publicize non-existent technology unless they had some proof of concept working in their labs. 3D scene recognition via stereo cameras has been around for quite a few years now and I think the time is ripe for consumer products like this to come about. I somehow doubt that the first generation products will work as well as the video suggests. On Mon, Jun 8, 2009 at 9:08 AM, Ron Blechner wrote: > Oh, p.s. > > I met up with someone at the CT Film Festival this weekend who > confirmed that the whole body interactive demos by Microsoft? STAGED. > Entirely a mock-up demo. The technology apparently works but they're > no where near actual product demo. > > -Ron / Hiro > > On Mon, Jun 8, 2009 at 11:31 AM, Ron Blechner wrote: > > The problem with the handshake: > > > > In short - it's 2 seconds worth of interaction. That's a tiny amount > > of reward for a tremendous amount of work it would take to make it > > better. And, there are already handshake and bow animations - they > > don't line up with another avatar, but doing all the work to make > > handshakes doesn't even create a new function - it just polishes an > > existing one. > > > > Compare that with putting in effort to do better facial animations - > > that would affect 100% of the time of interaction between two people. > > And consider that facial animation programming is *client-side* by > > nature, and doesn't require breaking apart and redoing the avatar code > > in Second Life to the degree that handshakes / puppeteering does. > > That's a helluva lot more results for a helluva lot less effort. > > > > I'd also like to add that, as Lawson pointed out, there is cultural > > bias. According to Neilsen, there are 170 million Americans actively > > using social media. There are twice that in China alone. China has 20% > > of the world's population. Are we here to make a Western metaverse, or > > a global one based on ideals not bound by one country, or one culture? > > The reason we handshake instead of bow is because the West has > > controlled the vast amounts of wealth in the world. Like it or not, > > the West is spending its Wealth and a tremendous amount is going to > > the East. In 20 years - we all may be bowing, like it or not. > > > > I don't want to ruffle too many features, but it's an important > > exercise to escape one's own assumptions and biases when debating > > functionality with a platform whose stated goal is to be "a new > > country", as Rosedale would say. > > > > And to bring this back - the larger issue is that people tend to get > > caught up in particular niceties like handshakes and miss > > bigger-picture items. What good are handshakes if the rest of the > > conversation is less meaningful because it lacks facial expression? > > > > I say, FORGET puppeteering. Forget handshakes. Let's focus our efforts > > on something much easier to accomplish, and with far more impact on > > Second Life. Facial expressions from video. > > > > *runs off to blog these thoughts* > > > > > > -- > > Ron Blechner > > Chief Technology Officer > > Involve, Inc > > www.involve3d.com > > SL: Hiro Pendragon > > > > > > p.s. PLUG! http://secondtense.blogspot.com > > > > On Fri, Jun 5, 2009 at 1:33 PM, Tateru Nino > wrote: > >> Maybe it isn't really about handshakes, and more about general > >> lining-up-of-body-parts between avatars? :) > >> > >> However, for most people in first-world western cultures, a handshake is > the > >> frequently sole form of socially allowable physical contact between two > >> people who aren't intimates at some level. That makes it strongly > symbolic. > >> > >> For handshake you can substitute a few variations: Knuckle-bumps, > high-fives > >> and such, but they're all basically a handshake with different emotional > >> flavoring. > >> > >> Ron Blechner wrote: > >> > >> Question: > >> > >> Why are handshakes so important that they are much more of a topic of > >> discussion of implementation, against facial expressions? > >> > >> -Ron / Hiro > >> > >> On Fri, Jun 5, 2009 at 7:34 AM, Argent > >> Stonecutter wrote: > >> > >> > >> On 2009-06-04, at 08:55, Jan Ciger wrote: > >> > >> > >> Argent, read my comment to Tigro's mail. It wouldn't work. At least > >> not > >> in a nice way. For reaching and grasping you need much more IK than > >> just > >> the three arm joints and then you are hitting a severely > >> under-constrained and computationally expensive problem. > >> > >> > >> That's why you don't try and solve it computationally. You don't > >> replace normal animation, you use this for minor adjustments to the > >> existing animation, and you limit the strength of the adjustment to > >> small angles and specific joints. > >> > >> So it's down to the person selecting the base animation and providing > >> the strength and possibly range (either distance or angle). > >> > >> > >> > >> E.g. in one case I have seen the solver to keep the hands next to the > >> avatar's waist but stick the waist forward to reach a goal. > >> > >> > >> Wouldn't happen, unless the person selected the waist as the joint > >> that would move, and unless the waist was already close to the goal. > >> > >> > >> > >> IK is a nice tool, but extremely hard to use unless you have an > >> animator > >> guiding it. > >> > >> > >> Which is the point. > >> > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/SLDev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > >> > >> > >> > >> > >> > >> -- > >> Tateru Nino > >> http://dwellonit.taterunino.net/ > >> > >> > > > > > > -- > Ron Blechner > Chief Technology Officer > Involve, Inc > www.involve3d.com > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090608/1515e568/attachment-0001.htm From robla at lindenlab.com Mon Jun 8 10:13:04 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 08 Jun 2009 10:13:04 -0700 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> Message-ID: <4A2D46A0.2060002@lindenlab.com> Hi folks, Let's wrap this conversation up, at least until someone takes the time to document the salient, actionable points of this conversation here: https://wiki.secondlife.com/wiki/Camera-based_Input If you'd like to continue to discuss this, a good place to put your thoughts is here: https://wiki.secondlife.com/wiki/Talk:Camera-based_Input Thanks, Rob On 06/08/2009 09:24 AM, Dahlia Trimble wrote: > A few points about the Natal video that I find difficult to believe > from a technological perspective: > > * the actor's arms are often occluded from the sensor by their bodies > yet the avatars react as if the arm positions are tracked > > * a few of the actors are wearing flowing clothing that can occlude > body positions such as loose open sweaters > > * at the very beginning of one of the videos there is some text along > the bottom left: "Product vision: actual features and functionality > may vary" > > Given that, I don't think a company like Microsoft would publicize > non-existent technology unless they had some proof of concept working > in their labs. 3D scene recognition via stereo cameras has been around > for quite a few years now and I think the time is ripe for consumer > products like this to come about. I somehow doubt that the first > generation products will work as well as the video suggests. > > On Mon, Jun 8, 2009 at 9:08 AM, Ron Blechner > wrote: > > Oh, p.s. > > I met up with someone at the CT Film Festival this weekend who > confirmed that the whole body interactive demos by Microsoft? STAGED. > Entirely a mock-up demo. The technology apparently works but they're > no where near actual product demo. > > -Ron / Hiro > > On Mon, Jun 8, 2009 at 11:31 AM, Ron Blechner > wrote: > > The problem with the handshake: > > > > In short - it's 2 seconds worth of interaction. That's a tiny amount > > of reward for a tremendous amount of work it would take to make it > > better. And, there are already handshake and bow animations - they > > don't line up with another avatar, but doing all the work to make > > handshakes doesn't even create a new function - it just polishes an > > existing one. > > > > Compare that with putting in effort to do better facial animations - > > that would affect 100% of the time of interaction between two > people. > > And consider that facial animation programming is *client-side* by > > nature, and doesn't require breaking apart and redoing the > avatar code > > in Second Life to the degree that handshakes / puppeteering does. > > That's a helluva lot more results for a helluva lot less effort. > > > > I'd also like to add that, as Lawson pointed out, there is cultural > > bias. According to Neilsen, there are 170 million Americans actively > > using social media. There are twice that in China alone. China > has 20% > > of the world's population. Are we here to make a Western > metaverse, or > > a global one based on ideals not bound by one country, or one > culture? > > The reason we handshake instead of bow is because the West has > > controlled the vast amounts of wealth in the world. Like it or not, > > the West is spending its Wealth and a tremendous amount is going to > > the East. In 20 years - we all may be bowing, like it or not. > > > > I don't want to ruffle too many features, but it's an important > > exercise to escape one's own assumptions and biases when debating > > functionality with a platform whose stated goal is to be "a new > > country", as Rosedale would say. > > > > And to bring this back - the larger issue is that people tend to get > > caught up in particular niceties like handshakes and miss > > bigger-picture items. What good are handshakes if the rest of the > > conversation is less meaningful because it lacks facial expression? > > > > I say, FORGET puppeteering. Forget handshakes. Let's focus our > efforts > > on something much easier to accomplish, and with far more impact on > > Second Life. Facial expressions from video. > > > > *runs off to blog these thoughts* > > > > > > -- > > Ron Blechner > > Chief Technology Officer > > Involve, Inc > > www.involve3d.com > > SL: Hiro Pendragon > > > > > > p.s. PLUG! http://secondtense.blogspot.com > > > > On Fri, Jun 5, 2009 at 1:33 PM, Tateru > Nino> wrote: > >> Maybe it isn't really about handshakes, and more about general > >> lining-up-of-body-parts between avatars? :) > >> > >> However, for most people in first-world western cultures, a > handshake is the > >> frequently sole form of socially allowable physical contact > between two > >> people who aren't intimates at some level. That makes it > strongly symbolic. > >> > >> For handshake you can substitute a few variations: > Knuckle-bumps, high-fives > >> and such, but they're all basically a handshake with different > emotional > >> flavoring. > >> > >> Ron Blechner wrote: > >> > >> Question: > >> > >> Why are handshakes so important that they are much more of a > topic of > >> discussion of implementation, against facial expressions? > >> > >> -Ron / Hiro > >> > >> On Fri, Jun 5, 2009 at 7:34 AM, Argent > >> Stonecutter > wrote: > >> > >> > >> On 2009-06-04, at 08:55, Jan Ciger wrote: > >> > >> > >> Argent, read my comment to Tigro's mail. It wouldn't work. At least > >> not > >> in a nice way. For reaching and grasping you need much more IK than > >> just > >> the three arm joints and then you are hitting a severely > >> under-constrained and computationally expensive problem. > >> > >> > >> That's why you don't try and solve it computationally. You don't > >> replace normal animation, you use this for minor adjustments to the > >> existing animation, and you limit the strength of the adjustment to > >> small angles and specific joints. > >> > >> So it's down to the person selecting the base animation and > providing > >> the strength and possibly range (either distance or angle). > >> > >> > >> > >> E.g. in one case I have seen the solver to keep the hands next > to the > >> avatar's waist but stick the waist forward to reach a goal. > >> > >> > >> Wouldn't happen, unless the person selected the waist as the joint > >> that would move, and unless the waist was already close to the > goal. > >> > >> > >> > >> IK is a nice tool, but extremely hard to use unless you have an > >> animator > >> guiding it. > >> > >> > >> Which is the point. > >> > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/SLDev > >> Please read the policies before posting to keep unmoderated posting > >> privileges > >> > >> > >> > >> > >> > >> -- > >> Tateru Nino > >> http://dwellonit.taterunino.net/ > >> > >> > > > > > > -- > Ron Blechner > Chief Technology Officer > Involve, Inc > www.involve3d.com > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From dmahalko at gmail.com Mon Jun 8 11:02:23 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon, 8 Jun 2009 13:02:23 -0500 Subject: [sldev] Define for wiki: Boost hell...? Message-ID: The topic of problems with Boost comes up a lot on this mailing list. The SL wiki is extremely vague on the topic, saying only it is an external library used for tokenization, but that is all. A search of the wiki for "tokenization" turns up nothing. In general I get the idea that this has something to do with: 1. The free Visual Studio Express is missing something from the commercial product 2. The free C++ Boost libraries are being used to replace whatever it is that is missing 3. ....??... Boost is apparently not a perfect matched replacement for the missing bits 4 .....??... Whatever the inbuilt adaptation is for Boost support, it's not very good Or something like that. Can someone explain so it can go in the wiki? - Dale Mahalko / Scalar Tardis From monkowsk at watson.ibm.com Mon Jun 8 11:11:56 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 08 Jun 2009 14:11:56 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: References: <4A2463D7.9050604@Gmail.com> <4A26BC54.40307@watson.ibm.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> Message-ID: <4A2D546C.4030909@watson.ibm.com> Did "someone at the CT Film Festival" also say that the live demo at E3 2009 was a fake? Ron Blechner wrote: > Oh, p.s. > > I met up with someone at the CT Film Festival this weekend who > confirmed that the whole body interactive demos by Microsoft? STAGED. > Entirely a mock-up demo. The technology apparently works but they're > no where near actual product demo. > > -Ron / Hiro From robla at lindenlab.com Mon Jun 8 11:41:58 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 08 Jun 2009 11:41:58 -0700 Subject: [sldev] Define for wiki: Boost hell...? In-Reply-To: References: Message-ID: <4A2D5B76.8070300@lindenlab.com> On 06/08/2009 11:02 AM, Dale Mahalko wrote: > The topic of problems with Boost comes up a lot on this mailing list. > The SL wiki is extremely vague on the topic, saying only it is an > external library used for tokenization, but that is all. A search of > the wiki for "tokenization" turns up nothing. > > In general I get the idea that this has something to do with: > > 1. The free Visual Studio Express is missing something from the > commercial product > 2. The free C++ Boost libraries are being used to replace whatever it > is that is missing > 3. ....??... Boost is apparently not a perfect matched replacement for > the missing bits > 4 .....??... Whatever the inbuilt adaptation is for Boost support, > it's not very good > > Or something like that. Can someone explain so it can go in the wiki? > > Hi Dale, I'm assuming you're referring to this page: https://wiki.secondlife.com/wiki/Microsoft_Windows_Builds The problem is that it's not possible to provide precompiled Boost libraries that work for both VS 2005 and VS 2008. Since Linden Lab has standardized on VS 2005, that's what we provide. Unfortunately, Microsoft has stopped supporting VS 2005 Express, only offering VS 2008 Express, so there is a strong desire to have VS 2008-compatible libraries from a number of people who want to use the free libraries. Rob From tom at streamsense.net Mon Jun 8 12:21:22 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon, 08 Jun 2009 20:21:22 +0100 Subject: [sldev] Define for wiki: Boost hell...? In-Reply-To: <4A2D5B76.8070300@lindenlab.com> References: <4A2D5B76.8070300@lindenlab.com> Message-ID: <4A2D64B2.7000001@streamsense.net> Hey Rob, I'm not sure if "not possible" is right; cmake would just have to detect the build environment and download the appropriate libraries /and/ headers, based on my experience with it (I build under VS2008 as a matter of course). ~Tom Rob Lanphier wrote: > I'm assuming you're referring to this page: > https://wiki.secondlife.com/wiki/Microsoft_Windows_Builds > > The problem is that it's not possible to provide precompiled Boost > libraries that work for both VS 2005 and VS 2008. Since Linden Lab has > standardized on VS 2005, that's what we provide. Unfortunately, > Microsoft has stopped supporting VS 2005 Express, only offering VS 2008 > Express, so there is a strong desire to have VS 2008-compatible > libraries from a number of people who want to use the free libraries. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > Hi Dale, From ron at involve3d.com Mon Jun 8 12:33:58 2009 From: ron at involve3d.com (Ron Blechner) Date: Mon, 8 Jun 2009 15:33:58 -0400 Subject: [sldev] Body motion and facial expression tracking, Microsoft did it In-Reply-To: <4A2D546C.4030909@watson.ibm.com> References: <4A2463D7.9050604@Gmail.com> <4A26C889.7090308@Gmail.com> <4A27D268.6060104@gmail.com> <90167726-AEA4-469F-82CB-1B7742ECD0D1@gmail.com> <4A295702.4030705@gmail.com> <4A2D546C.4030909@watson.ibm.com> Message-ID: That's what the person was referring to, yeah. And M-soft didn't have to lie - they said "the technology is available now" which is true, but they never said that their live demo USED that tech - it's just a prototype by the minimal sense - a prototype is supposed to show function and how it works, but does not need to actually "work" itself. -Ron On Mon, Jun 8, 2009 at 2:11 PM, Mike Monkowski wrote: > Did "someone at the CT Film Festival" also say that the live demo at E3 2009 > was a fake? > > Ron Blechner wrote: >> >> Oh, p.s. >> >> I met up with someone at the CT Film Festival this weekend who >> confirmed that the whole body interactive demos by Microsoft? STAGED. >> Entirely a mock-up demo. The technology apparently works but they're >> no where near actual product demo. >> >> -Ron / Hiro > -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com From robla at lindenlab.com Mon Jun 8 12:38:15 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 08 Jun 2009 12:38:15 -0700 Subject: [sldev] Define for wiki: Boost hell...? In-Reply-To: <4A2D64B2.7000001@streamsense.net> References: <4A2D5B76.8070300@lindenlab.com> <4A2D64B2.7000001@streamsense.net> Message-ID: <4A2D68A7.5070200@lindenlab.com> Hi Tom Let me clarify: it's not possible to provide a single compiled Boost library that works for both VS 2005 and VS 2008. It's quite possible to separate libraries for VS 2005 and VS 2008 respectively...we just haven't gotten around to it. Rob On 06/08/2009 12:21 PM, Thomas Grimshaw wrote: > Hey Rob, > > I'm not sure if "not possible" is right; cmake would just have to > detect the build environment and download the > appropriate libraries /and/ headers, based on my experience with it (I > build under VS2008 as a matter of course). > > ~Tom > > Rob Lanphier wrote: > >> I'm assuming you're referring to this page: >> https://wiki.secondlife.com/wiki/Microsoft_Windows_Builds >> >> The problem is that it's not possible to provide precompiled Boost >> libraries that work for both VS 2005 and VS 2008. Since Linden Lab has >> standardized on VS 2005, that's what we provide. Unfortunately, >> Microsoft has stopped supporting VS 2005 Express, only offering VS 2008 >> Express, so there is a strong desire to have VS 2008-compatible >> libraries from a number of people who want to use the free libraries. >> >> Rob >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> Hi Dale, >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From brad at lindenlab.com Mon Jun 8 14:01:48 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Mon, 08 Jun 2009 14:01:48 -0700 Subject: [sldev] Define for wiki: Boost hell...? In-Reply-To: <4A2D68A7.5070200@lindenlab.com> References: <4A2D5B76.8070300@lindenlab.com><4A2D64B2.7000001@stream sense.net> <4A2D68A7.5070200@lindenlab.com> Message-ID: <4A2D7C3C.1010205@lindenlab.com> Speaking of getting around to it.... I will be looking into providing library packages that contain binaries for both versions shortly. Hopefully in the next week or two. -Brad Rob Lanphier wrote: > Hi Tom > > Let me clarify: it's not possible to provide a single compiled Boost > library that works for both VS 2005 and VS 2008. It's quite possible to > separate libraries for VS 2005 and VS 2008 respectively...we just > haven't gotten around to it. > > Rob > > On 06/08/2009 12:21 PM, Thomas Grimshaw wrote: > >> Hey Rob, >> >> I'm not sure if "not possible" is right; cmake would just have to >> detect the build environment and download the >> appropriate libraries /and/ headers, based on my experience with it (I >> build under VS2008 as a matter of course). >> >> ~Tom >> >> Rob Lanphier wrote: >> >> >>> I'm assuming you're referring to this page: >>> https://wiki.secondlife.com/wiki/Microsoft_Windows_Builds >>> >>> The problem is that it's not possible to provide precompiled Boost >>> libraries that work for both VS 2005 and VS 2008. Since Linden Lab has >>> standardized on VS 2005, that's what we provide. Unfortunately, >>> Microsoft has stopped supporting VS 2005 Express, only offering VS 2008 >>> Express, so there is a strong desire to have VS 2008-compatible >>> libraries from a number of people who want to use the free libraries. >>> >>> Rob >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> Hi Dale, >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From tigrospottystripes at gmail.com Mon Jun 8 16:09:30 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 08 Jun 2009 20:09:30 -0300 Subject: [sldev] sorry for the off-topic, need assistance from someone that understands the insides of the client Message-ID: <4A2D9A2A.90009@Gmail.com> I know I shouldn't be posting about my own technical issues here, but it has been quite difficult to get any help anywhere else. The help I did got didn't lead much anywhere, and I'm growing tired of fruitless blind try and error, I really would like someone to help me figure out exactly what is wrong, but preferably by actually studying the problem instead of trying random fixes for unkown problems most of the description of the issue is in http://forums.secondlife.com/showthread.php?t=324077 I've seen other people complaining about similar issues, but haven't been able to confirm anyone got the exact same thing, so I will not be posting a jira entry about this for the moment (with the excetion of a the one I already posting requesting for a workaround to be coded in, https://jira.secondlife.com/browse/VWR-10698 ), quite some time ago, close to when I first got this issue, I tried using LL's tech support, I wasn't left a good impression, and much less any solution From carlo at alinoe.com Mon Jun 8 16:55:38 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 9 Jun 2009 01:55:38 +0200 Subject: [sldev] sorry for the off-topic, need assistance from someone that understands the insides of the client In-Reply-To: <4A2D9A2A.90009@Gmail.com> References: <4A2D9A2A.90009@Gmail.com> Message-ID: <20090608235538.GA19717@alinoe.com> On Mon, Jun 08, 2009 at 08:09:30PM -0300, Tigro Spottystripes wrote: > I know I shouldn't be posting about my own technical issues here, but it > has been quite difficult to get any help anywhere else. The help I did > got didn't lead much anywhere, and I'm growing tired of fruitless blind > try and error, I really would like someone to help me figure out exactly > what is wrong, but preferably by actually studying the problem instead > of trying random fixes for unkown problems I read everything, even http://pastebin.com/f603fe150 and I think that your login problems might be a direct result of that freeze. If the viewer freezes for a long time, it 'times out' connections and the login will simply fail. I'm afraid it's just a guess - but if I was you I'd concentrate on finding out what the viewer is doing (ie, by using a debugger) at the moment it freezes. That being said, if you want to do any serious research at all regarding a viewer problem you will have to START with compiling it yourself. -- Carlo Wood From tigrospottystripes at gmail.com Mon Jun 8 18:51:00 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 08 Jun 2009 22:51:00 -0300 Subject: [sldev] sorry for the off-topic, need assistance from someone that understands the insides of the client In-Reply-To: <20090608235538.GA19717@alinoe.com> References: <4A2D9A2A.90009@Gmail.com> <20090608235538.GA19717@alinoe.com> Message-ID: <4A2DC004.8070203@Gmail.com> Carlo Wood escreveu: > > I'm afraid it's just a guess - but if I was you I'd concentrate > on finding out what the viewer is doing (ie, by using a debugger) > at the moment it freezes. > > That being said, if you want to do any serious research at all > regarding a viewer problem you will have to START with compiling > it yourself. > > I don't know enough to know how to do that or how to interpret the information aquired with those techiniques, but like I said on the forum thread, I am willing to follow orientations to aquire more info, but as I mentioned before, I'm kinda tired of blind try and error. Btw, I uninstalled Klite mega-codec pack and nothing changed, so, after rebooting and trying SL again, I put it back for the moment, it's good to not have to worry about codecs From mwhite at leporidae.net Tue Jun 9 06:58:24 2009 From: mwhite at leporidae.net (Matt White) Date: Tue, 9 Jun 2009 09:58:24 -0400 Subject: [sldev] Snowglobe Pauses Message-ID: Good Morning! I've been trying to use Snowglobe as my primary viewer for a while, but the last few builds have had major issues with the viewer pausing completely; the UI freezes and rendering stops. (But I can still hear wind sounds in the background.) Sometimes the viewer will recover on its own, but most of the time I end up having to kill the process to regain control of my system. I'm running Vista64 with an nVidia GTX260 with the latest drivers. The deferred pipeline is not on. Are there any tricks that I should know on how to get the system to either force a crash (so a crash dump can be sent back) or to just gather information that could be helpful on how and why this is happening? -- Matt White / Bunny Halberd From stickman at gmail.com Tue Jun 9 07:06:48 2009 From: stickman at gmail.com (Stickman) Date: Tue, 9 Jun 2009 07:06:48 -0700 Subject: [sldev] Snowglobe Pauses In-Reply-To: References: Message-ID: > I've been trying to use Snowglobe as my primary viewer for a while, > but the last few builds have had major issues with the viewer pausing > completely; the UI freezes and rendering stops. (But I can still hear > wind sounds in the background.) Sometimes the viewer will recover on > its own, but most of the time I end up having to kill the process to > regain control of my system. Usually the solution I hear in any game (read: 3D rendered world) with problems like this is try setting it to use only one core. I dunno if that's still applicable in SL, though. -Stickman From mwhite at leporidae.net Tue Jun 9 07:22:59 2009 From: mwhite at leporidae.net (Matt White) Date: Tue, 9 Jun 2009 10:22:59 -0400 Subject: [sldev] Snowglobe Pauses In-Reply-To: References: Message-ID: On Tue, Jun 9, 2009 at 10:06 AM, Stickman wrote: > Usually the solution I hear in any game (read: 3D rendered world) with > problems like this is try setting it to use only one core. This is only a very recent thing. SL runs very well on multi-core machines - I've had to go back to the release client since Snowglobe is nearly unusable with all of the pauses. The release client works great on the same hardware. I'm just interested in trying to track down what's doing it so I can hand it over to the developers to get it fixed in future builds. :) -- Matt White / Bunny Halberd From robin.cornelius at gmail.com Tue Jun 9 07:54:38 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 9 Jun 2009 15:54:38 +0100 Subject: [sldev] Snowglobe Pauses In-Reply-To: References: Message-ID: On Tue, Jun 9, 2009 at 3:22 PM, Matt White wrote: > On Tue, Jun 9, 2009 at 10:06 AM, Stickman wrote: > >> Usually the solution I hear in any game (read: 3D rendered world) with >> problems like this is try setting it to use only one core. > > This is only a very recent thing. SL runs very well on multi-core > machines - I've had to go back to the release client since Snowglobe > is nearly unusable with all of the pauses. The release client works > great on the same hardware. > > I'm just interested in trying to track down what's doing it so I can > hand it over to the developers to get it fixed in future builds. :) > I'm afraid this is probably going to take a build from source to attack. If your up for that then its not too difficult (doing the build is the most difficult bit) to grab some stack traces from the various threads. All you would need to do is hit pause in visual studio during one of these events then open the thread and stack trace window and copy and paste to a notepad the stack trace for each thread and hopefully that will point at what is blocking. Some other ideas, What the fast timers (advanced menu->consoles->fast timers) if the viewer resumes from one of these pauses you should with luck see one of the counters shoot of the screen, if you click to pause the timers and click on the really excessive bar you get a break down of the timers on the left. It may point to a particular place in the viewer. Also watching the log file can be helpful. If you are on windows, find WinTail and open the SecondLife.log file and watch in real time, see if a particular message is associated with the pauses. My gut instinct says this is related to some of the arp_locking that has been played with recently due to various texture decode issues, and this sticks of a dead lock condition. Robin From mwhite at leporidae.net Tue Jun 9 08:09:43 2009 From: mwhite at leporidae.net (Matt White) Date: Tue, 9 Jun 2009 11:09:43 -0400 Subject: [sldev] Snowglobe Pauses In-Reply-To: References: Message-ID: On Tue, Jun 9, 2009 at 10:54 AM, Robin Cornelius wrote: > I'm afraid this is probably going to take a build from source to attack. > > If your up for that then its not too difficult (doing the build is the > most difficult bit) to grab some stack traces from the various > threads. All you would need to do is hit pause in visual studio during > one of these events then open the thread and stack trace window and > copy and paste to a notepad the stack trace for each thread and > hopefully that will point at what is blocking. I was afraid of that. Up till this point I have resisted the urge to go grab the source and compile it myself... not because I can't do it, but because I have a very full plate as it is and I really didn't want to get sucked into something else... playing with the viewer source is the sort of thing I could really get lost in and completely lose track of time. :) But if that's what it takes, I'll just have to do it... and keep an eye on the clock. > What the fast timers (advanced menu->consoles->fast timers) if the > viewer resumes from one of these pauses you should with luck see one > of the counters shoot of the screen, if you click to pause the timers > and click on the really excessive bar you get a break down of the > timers on the left. It may point to a particular place in the viewer. Good idea. > Also watching the log file can be helpful. If you are on windows, find > WinTail and open the SecondLife.log file and watch in real time, see > if a particular message is associated with the pauses. Another good idea. > My gut instinct says this is related to some of the arp_locking that > has been played with recently due to various texture decode issues, > and this sticks of a dead lock condition. Same here. I follow the sl-commits mailing list and I've noticed that some things have been changing in regards to the texture cache (what I'm not completely sure - I'm completely unfamiliar with the code). It freezes much more often when I'm moving a lot of stuff on the screen - for example flying around in a mall full of textures. -- Matt White / Bunny Halberd From dzonatas at gmail.com Tue Jun 9 10:03:07 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 09 Jun 2009 10:03:07 -0700 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption In-Reply-To: References: <4A241603.1050403@lindenlab.com> Message-ID: <4A2E95CB.4070300@gmail.com> Soft wrote: > It would also be great to see any numbers on 32- vs 64-bit > performance, for any of you producing 32- and 64-bit stand-alone > viewers. 64-bit would make setup easier. It would be helpful to know > of any other gains. > 32bit systems are limited to 4GB of main memory, but many motherboards limit that further to only 2-3GB . We can easily expect 64bit systems to support at least 8GB of main memory. Even cheap 64bit boards support 32GB of main memory. There is alone is shows there is no way to compare the performance of a 32bit system to a 64 bit system with a program that is designed to work only within the limits of a 32 bit system. One thing that can change is default cache size. If on a 64bit system, don't limit it to 1.5 GB. =) From dzonatas at gmail.com Tue Jun 9 10:05:02 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Tue, 09 Jun 2009 10:05:02 -0700 Subject: [sldev] Gesture client code Re: Anyone here with OpenCV experience? In-Reply-To: <4A20653B.7020805@lindenlab.com> References: <4A15AEBC.7070800@lindenlab.com> <4A161CD0.7020600@lindenlab.com> <4A16C680.9020607@gmail.com> <4A16E5FC.6050403@lindenlab.com> <4A170D8B.1050404@gmail.com> <4A171497.2000302@lindenlab.com> <4A171947.9050709@gmail.com> <4A17340C.4020202@lindenlab.com> <4A20653B.7020805@lindenlab.com> Message-ID: <4A2E963E.7090509@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090609/805d9749/attachment.htm From agati at procele.com.br Tue Jun 9 10:23:34 2009 From: agati at procele.com.br (Salvador Agati) Date: Tue, 9 Jun 2009 14:23:34 -0300 Subject: [sldev] TRIGERED WINDOWS ON VIEWER In-Reply-To: References: Message-ID: <1D64572AAFA845CDB07B8C07F722A587@tury> Hi all devs, I read almost everything you post here and I am aware that I'm not in the average level you are. So if the question is irrelevant, please forgive me. Is there any technical constraint to have the "Fast Pay" and the "Dialog" windows still active when we get out of a money() or listen() state? It will be technically difficult to have an internal timer, as an argument in these functions, that cleared the windows in the client side, after the timer reachs zero? Something like that: llSetPayPrice(............, integer timer); llDialog(........., integer timer); Regards to all, Agathos Frascati From robla at lindenlab.com Tue Jun 9 10:39:33 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 09 Jun 2009 10:39:33 -0700 Subject: [sldev] Snowglobe Pauses In-Reply-To: References: Message-ID: <4A2E9E55.7050000@lindenlab.com> On 06/09/2009 06:58 AM, Matt White wrote: > Good Morning! > > I've been trying to use Snowglobe as my primary viewer for a while, > but the last few builds have had major issues with the viewer pausing > completely; the UI freezes and rendering stops. (But I can still hear > wind sounds in the background.) Sometimes the viewer will recover on > its own, but most of the time I end up having to kill the process to > regain control of my system. > > I'm running Vista64 with an nVidia GTX260 with the latest drivers. The > deferred pipeline is not on. > > Are there any tricks that I should know on how to get the system to > either force a crash (so a crash dump can be sent back) or to just > gather information that could be helpful on how and why this is > happening? > Hi Matt, Can you pinpoint when it was that the problems started happening? In particular, look through this list here: http://svn.secondlife.com/trac/linden/log/projects/2009/http-texture ...and then try downloading an earlier corresponding to something earlier than a fishy looking change here: https://lists.secondlife.com/pipermail/sldev-commits/2009-May/subject.html#2582 https://lists.secondlife.com/pipermail/sldev-commits/2009-June/subject.html#2728 (look for the mails with "Successful Build for ...") I'm going to guess that r2324 is the earliest rev worth testing, as before that we had a lot of OpenJPEG crashes that would probably mask any problems that you're having now. Just knowing if 2324 doesn't exhibit this problem would provide us with a lot of information: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/Second_Life_1-23-2-2324_OSS_Setup.exe Of course, the suggestion to build your own will also be helpful, so don't let me stop you from doing that. This is just an alternative that you can try if you can't fully invest in getting a build going. Rob From philip at lindenlab.com Tue Jun 9 10:57:22 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Tue, 09 Jun 2009 10:57:22 -0700 Subject: [sldev] Snowglobe Pauses In-Reply-To: <4A2E9E55.7050000@lindenlab.com> References: <4A2E9E55.7050000@lindenlab.com> Message-ID: <4A2EA282.5000307@lindenlab.com> Matt: thanks for taking on doing this build, too. Appreciate any help with finding problems in Snowglobe. P Rob Lanphier wrote: > On 06/09/2009 06:58 AM, Matt White wrote: > >> Good Morning! >> >> I've been trying to use Snowglobe as my primary viewer for a while, >> but the last few builds have had major issues with the viewer pausing >> completely; the UI freezes and rendering stops. (But I can still hear >> wind sounds in the background.) Sometimes the viewer will recover on >> its own, but most of the time I end up having to kill the process to >> regain control of my system. >> >> I'm running Vista64 with an nVidia GTX260 with the latest drivers. The >> deferred pipeline is not on. >> >> Are there any tricks that I should know on how to get the system to >> either force a crash (so a crash dump can be sent back) or to just >> gather information that could be helpful on how and why this is >> happening? >> >> > > Hi Matt, > > Can you pinpoint when it was that the problems started happening? In > particular, look through this list here: > http://svn.secondlife.com/trac/linden/log/projects/2009/http-texture > > ...and then try downloading an earlier corresponding to something > earlier than a fishy looking change here: > https://lists.secondlife.com/pipermail/sldev-commits/2009-May/subject.html#2582 > https://lists.secondlife.com/pipermail/sldev-commits/2009-June/subject.html#2728 > > (look for the mails with "Successful Build for ...") > > I'm going to guess that r2324 is the earliest rev worth testing, as > before that we had a lot of OpenJPEG crashes that would probably mask > any problems that you're having now. Just knowing if 2324 doesn't > exhibit this problem would provide us with a lot of information: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/Second_Life_1-23-2-2324_OSS_Setup.exe > > Of course, the suggestion to build your own will also be helpful, so > don't let me stop you from doing that. This is just an alternative that > you can try if you can't fully invest in getting a build going. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090609/4665eae4/attachment.htm From merov at lindenlab.com Tue Jun 9 10:58:14 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 9 Jun 2009 10:58:14 -0700 Subject: [sldev] Snowglobe Pauses In-Reply-To: <4A2E9E55.7050000@lindenlab.com> References: <4A2E9E55.7050000@lindenlab.com> Message-ID: <6819177C-C1E1-44E8-88BE-18DEAC8C4701@lindenlab.com> Hi Matt, Also, useful information if you don't want to run from source and step through the code under a debugger: - keep a copy of the SecondLife.log file (under "Documents and Settings//Application Data/SecondLife/logs") when that happens. There are quite a bit of warnings and printouts around http-texture code that are useful to us - tell us which region and approximate coordinates you've been in (so we can try to repro ourselves) If you could put that in a PJIRA, that would be great. Cheers, - merov On Jun 9, 2009, at 10:39 AM, Rob Lanphier wrote: > On 06/09/2009 06:58 AM, Matt White wrote: >> Good Morning! >> >> I've been trying to use Snowglobe as my primary viewer for a while, >> but the last few builds have had major issues with the viewer pausing >> completely; the UI freezes and rendering stops. (But I can still hear >> wind sounds in the background.) Sometimes the viewer will recover on >> its own, but most of the time I end up having to kill the process to >> regain control of my system. >> >> I'm running Vista64 with an nVidia GTX260 with the latest drivers. >> The >> deferred pipeline is not on. >> >> Are there any tricks that I should know on how to get the system to >> either force a crash (so a crash dump can be sent back) or to just >> gather information that could be helpful on how and why this is >> happening? >> > > Hi Matt, > > Can you pinpoint when it was that the problems started happening? In > particular, look through this list here: > http://svn.secondlife.com/trac/linden/log/projects/2009/http-texture > > ...and then try downloading an earlier corresponding to something > earlier than a fishy looking change here: > https://lists.secondlife.com/pipermail/sldev-commits/2009-May/subject.html > #2582 > https://lists.secondlife.com/pipermail/sldev-commits/2009-June/subject.html > #2728 > > (look for the mails with "Successful Build for ...") > > I'm going to guess that r2324 is the earliest rev worth testing, as > before that we had a lot of OpenJPEG crashes that would probably mask > any problems that you're having now. Just knowing if 2324 doesn't > exhibit this problem would provide us with a lot of information: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2324/Second_Life_1-23-2-2324_OSS_Setup.exe > > Of course, the suggestion to build your own will also be helpful, so > don't let me stop you from doing that. This is just an alternative > that > you can try if you can't fully invest in getting a build going. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From zha.ewry at gmail.com Tue Jun 9 11:16:11 2009 From: zha.ewry at gmail.com (Zha Ewry) Date: Tue, 9 Jun 2009 14:16:11 -0400 Subject: [sldev] Odd bake behavior in snowglobe Message-ID: <920d7d850906091116t7e1fa155u68b6226cdeddd98f@mail.gmail.com> I have started using snowglobe as my primary viewer, and I'm seeing some funny baking issues which I'm trying to pin down. (I think I'm homing in on a full re-create) When I change outfits, people see me with what I'd describe as "mixed" bakes. In general, they are seeing parts of bakes from one or two outfit changes back. Has anyone else seen this? I'm setting up a couple of two client tests with alts for this, and I'll try and refine a re-create and set of exampls shortly, but I thought I ask if anyone else has seen similar issues. ~ Zha From monkowsk at watson.ibm.com Tue Jun 9 11:39:16 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 09 Jun 2009 14:39:16 -0400 Subject: [sldev] TRIGERED WINDOWS ON VIEWER In-Reply-To: <1D64572AAFA845CDB07B8C07F722A587@tury> References: <1D64572AAFA845CDB07B8C07F722A587@tury> Message-ID: <4A2EAC54.8090103@watson.ibm.com> The only technical difficulty would be adding an extra argument to the LSL functions. But that's more than just a technical difficulty. The reason the notifications stay active is because they do not know the state of the script which is running on the server. Mike Salvador Agati wrote: > Hi all devs, > > I read almost everything you post here and I am aware that I'm not in the > average level you are. So if the question is irrelevant, please forgive me. > > Is there any technical constraint to have the "Fast Pay" and the "Dialog" > windows still active when we get out of a money() or listen() state? > > It will be technically difficult to have an internal timer, as an argument > in these functions, that cleared the windows in the client side, after the > timer reachs zero? > > Something like that: > > llSetPayPrice(............, integer timer); > llDialog(........., integer timer); > > Regards to all, > Agathos Frascati > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From colin.kern at gmail.com Tue Jun 9 11:41:07 2009 From: colin.kern at gmail.com (Colin Kern) Date: Tue, 9 Jun 2009 14:41:07 -0400 Subject: [sldev] Odd bake behavior in snowglobe In-Reply-To: <920d7d850906091116t7e1fa155u68b6226cdeddd98f@mail.gmail.com> References: <920d7d850906091116t7e1fa155u68b6226cdeddd98f@mail.gmail.com> Message-ID: <77c421f00906091141j5a8ea41cwed853d6aa86e0955@mail.gmail.com> On Tue, Jun 9, 2009 at 2:16 PM, Zha Ewry wrote: > I have started using snowglobe as my primary viewer, and I'm seeing > some funny baking issues which I'm trying to pin down. (I think I'm > homing in on a full re-create) ?When I change outfits, people see me > with what I'd describe as "mixed" bakes. In general, they are seeing > parts of bakes from one or two outfit changes back. Has anyone else > seen this? I'm setting up a couple of two client tests with alts for > this, and I'll try and refine a re-create and set of exampls shortly, > but I thought I ask if anyone else has seen similar issues. > > ~ Zha I've experienced this with the 1.23 RC viewer. I had changed my shirt and logged off. Then the next day I logged in and changed my shirt again, only to discover when someone sent me a snapshot that they were seeing me wearing the shirt I had changed out before I had logged off the last time. No amount of rebaking or changing seemed to fix this. I logged into the 1.22 viewer and rebaked and the problem was fixed immediately. Colin From zha.ewry at gmail.com Tue Jun 9 11:45:59 2009 From: zha.ewry at gmail.com (Zha Ewry) Date: Tue, 9 Jun 2009 14:45:59 -0400 Subject: [sldev] Odd bake behavior in snowglobe In-Reply-To: <77c421f00906091141j5a8ea41cwed853d6aa86e0955@mail.gmail.com> References: <920d7d850906091116t7e1fa155u68b6226cdeddd98f@mail.gmail.com> <77c421f00906091141j5a8ea41cwed853d6aa86e0955@mail.gmail.com> Message-ID: <920d7d850906091145r615570a8g647d50aa1f8695e9@mail.gmail.com> That certainly sounds like exactly the behavior I've been seeing in snowglobe. I've never seen it in the 1.23 RC tho. I'll try it in both across logouts. On Tue, Jun 9, 2009 at 2:41 PM, Colin Kern wrote: > On Tue, Jun 9, 2009 at 2:16 PM, Zha Ewry wrote: >> I have started using snowglobe as my primary viewer, and I'm seeing >> some funny baking issues which I'm trying to pin down. (I think I'm >> homing in on a full re-create) ?When I change outfits, people see me >> with what I'd describe as "mixed" bakes. In general, they are seeing >> parts of bakes from one or two outfit changes back. Has anyone else >> seen this? I'm setting up a couple of two client tests with alts for >> this, and I'll try and refine a re-create and set of exampls shortly, >> but I thought I ask if anyone else has seen similar issues. >> >> ~ Zha > > I've experienced this with the 1.23 RC viewer. ?I had changed my shirt > and logged off. ?Then the next day I logged in and changed my shirt > again, only to discover when someone sent me a snapshot that they were > seeing me wearing the shirt I had changed out before I had logged off > the last time. ?No amount of rebaking or changing seemed to fix this. > I logged into the 1.22 viewer and rebaked and the problem was fixed > immediately. > > Colin > From robin.cornelius at gmail.com Tue Jun 9 12:27:02 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 09 Jun 2009 20:27:02 +0100 Subject: [sldev] Define for wiki: Boost hell...? In-Reply-To: <4A2D7C3C.1010205@lindenlab.com> References: <4A2D5B76.8070300@lindenlab.com><4A2D64B2.7000001@stream sense.net> <4A2D68A7.5070200@lindenlab.com> <4A2D7C3C.1010205@lindenlab.com> Message-ID: <4A2EB786.6080000@gmail.com> Brad Kittenbrink (Brad Linden) wrote: > Speaking of getting around to it.... > > I will be looking into providing library packages that contain binaries > for both versions shortly. Hopefully in the next week or two. Cool this will be useful. I started doing this and ran in to some stupid linking errors that I just ran out of time tracking down. So if you are going to finish this thats great. But if you get diverted and its going to be months, please ping back and I will finished off what i started. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090609/2b520be0/attachment.pgp From mwhite at leporidae.net Tue Jun 9 12:30:39 2009 From: mwhite at leporidae.net (Matt White) Date: Tue, 9 Jun 2009 15:30:39 -0400 Subject: [sldev] Snowglobe Pauses In-Reply-To: <4A2E9E55.7050000@lindenlab.com> References: <4A2E9E55.7050000@lindenlab.com> Message-ID: On Tue, Jun 9, 2009 at 1:39 PM, Rob Lanphier wrote: > Of course, the suggestion to build your own will also be helpful, so > don't let me stop you from doing that. This is just an alternative that > you can try if you can't fully invest in getting a build going. Since I'd like to provide the best information I can back to LL, I'll try to build the viewer myself. Snowglobe is a fairly important project, so it'll be worthwhile to me to help nail this down as much as I can. I might see some of you tonight on IRC looking for help on getting it to build correctly. :) Thanks! -- Matt White / Bunny Halberd From thickbrick.sleaford at gmail.com Tue Jun 9 14:02:36 2009 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Wed, 10 Jun 2009 00:02:36 +0300 Subject: [sldev] Odd bake behavior in snowglobe In-Reply-To: <920d7d850906091116t7e1fa155u68b6226cdeddd98f@mail.gmail.com> References: <920d7d850906091116t7e1fa155u68b6226cdeddd98f@mail.gmail.com> Message-ID: <7343a84b0906091402s2acc0a8ay28c0a704fc802d98@mail.gmail.com> http://jira.secondlife.com/browse/SNOW-8 The title for this JIRA is a bit misleading, but it deals with this issue. So far from my experimenting, I see bakes sometimes propagate to the other session partially (?), or with a long delay (5-10 minutes), but more often they don't propagate at all. I don't know if it is indicative of a problem or not, but looking in the logs, I always see a few lines complaining APR failed to open a texture file, immediately after the lines dealing with baking. (pasted into the jira above) On Tue, Jun 9, 2009 at 9:16 PM, Zha Ewry wrote: > I have started using snowglobe as my primary viewer, and I'm seeing > some funny baking issues which I'm trying to pin down. (I think I'm > homing in on a full re-create) ?When I change outfits, people see me > with what I'd describe as "mixed" bakes. In general, they are seeing > parts of bakes from one or two outfit changes back. Has anyone else > seen this? I'm setting up a couple of two client tests with alts for > this, and I'll try and refine a re-create and set of exampls shortly, > but I thought I ask if anyone else has seen similar issues. > > ~ Zha -- Thickbrick Sleaford From robla at lindenlab.com Tue Jun 9 17:20:50 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 09 Jun 2009 17:20:50 -0700 Subject: [sldev] Odd bake behavior in snowglobe In-Reply-To: <7343a84b0906091402s2acc0a8ay28c0a704fc802d98@mail.gmail.com> References: <920d7d850906091116t7e1fa155u68b6226cdeddd98f@mail.gmail.com> <7343a84b0906091402s2acc0a8ay28c0a704fc802d98@mail.gmail.com> Message-ID: <4A2EFC62.6080703@lindenlab.com> Those of you watching may have noticed that I attached a patch to SNOW-8 that *might* be a fix for this problem. Anyone willing to try applying the patch and seeing if it fixes the problem? Rob On 06/09/2009 02:02 PM, Thickbrick Sleaford wrote: > http://jira.secondlife.com/browse/SNOW-8 > > The title for this JIRA is a bit misleading, but it deals with this > issue. So far from my experimenting, I see bakes sometimes propagate > to the other session partially (?), or with a long delay (5-10 > minutes), but more often they don't propagate at all. > > I don't know if it is indicative of a problem or not, but looking in > the logs, I always see a few lines complaining APR failed to open a > texture file, immediately after the lines dealing with baking. (pasted > into the jira above) > > > On Tue, Jun 9, 2009 at 9:16 PM, Zha Ewry wrote: > >> I have started using snowglobe as my primary viewer, and I'm seeing >> some funny baking issues which I'm trying to pin down. (I think I'm >> homing in on a full re-create) When I change outfits, people see me >> with what I'd describe as "mixed" bakes. In general, they are seeing >> parts of bakes from one or two outfit changes back. Has anyone else >> seen this? I'm setting up a couple of two client tests with alts for >> this, and I'll try and refine a re-create and set of exampls shortly, >> but I thought I ask if anyone else has seen similar issues. >> >> ~ Zha >> > > From carlo at alinoe.com Tue Jun 9 17:50:52 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 10 Jun 2009 02:50:52 +0200 Subject: [sldev] Snowglobe Pauses In-Reply-To: References: Message-ID: <20090610005052.GA4590@alinoe.com> On Tue, Jun 09, 2009 at 09:58:24AM -0400, Matt White wrote: > I've been trying to use Snowglobe as my primary viewer for a while, > but the last few builds have had major issues with the viewer pausing > completely; the UI freezes and rendering stops. (But I can still hear > wind sounds in the background.) Sometimes the viewer will recover on > its own, but most of the time I end up having to kill the process to > regain control of my system. That very likely means that a thread doesn't return to the main loop anymore. My guess is that this is a semi dead lock - where the rendering thread is waiting for a lock that sometimes is unlocked by another thread - which apparently does the real 'hanging'. So, interesting would be to know what the threads are doing (on what mutexes they are waiting). You can see that with a debugger (like gdb). -- Carlo Wood From robla at lindenlab.com Tue Jun 9 17:56:59 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 09 Jun 2009 17:56:59 -0700 Subject: [sldev] SNOW-2: getting to the bottom of the curl crashers Message-ID: <4A2F04DB.2020305@lindenlab.com> Hi folks, We're trying to decide just how important SNOW-2 is: http://jira.secondlife.com/browse/SNOW-2 This is our tracking issue for the vague crash reports we have involving curl. We're not getting good stack traces or anything like that, and people have generally not been complaining about this particular problem. However, based on some evidence that Merov noticed and is digging into now, it would seem that the curl crashers seem to happen in the map code (because secondlife.log indicates to be accessing S3 at the time of the crash). Furthermore, the problem generally might be linked to improper use of curl in the viewer (e.g. overusing the same curl handle). This might be a case where gentle use of the map works like a charm, but using the map while chatting and teleporting and using the inworld web browser may be another story altogether. So, we'd like you to help by hammering on this issue, and reporting your results (either positive or negative) in SNOW-2. In particular, some things to try: 1. Lots of things that would use HTTP simultaneously (e.g moving around in the map, then quickly teleporting before the map loads in all of the way) 2. Really use the map. Zoom out, zoom in, try to find regions with missing textures 3. grep the code yourself for libcurl usage, and figure out other ways of torturing that code. Let's figure out if we need to figure this problem out before declaring this "Snowglobe 1.0". Thanks! Rob From poppy at lindenlab.com Tue Jun 9 18:34:11 2009 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Tue, 09 Jun 2009 18:34:11 -0700 Subject: [sldev] SNOW-2: getting to the bottom of the curl crashers In-Reply-To: <4A2F04DB.2020305@lindenlab.com> References: <4A2F04DB.2020305@lindenlab.com> Message-ID: <4A2F0D93.2050106@lindenlab.com> any link(s) to the relevant source? + poppy Rob Lanphier wrote: > Hi folks, > > We're trying to decide just how important SNOW-2 is: > http://jira.secondlife.com/browse/SNOW-2 > > This is our tracking issue for the vague crash reports we have involving > curl. We're not getting good stack traces or anything like that, and > people have generally not been complaining about this particular problem. > > However, based on some evidence that Merov noticed and is digging into > now, it would seem that the curl crashers seem to happen in the map code > (because secondlife.log indicates to be accessing S3 at the time of the > crash). Furthermore, the problem generally might be linked to improper > use of curl in the viewer (e.g. overusing the same curl handle). This > might be a case where gentle use of the map works like a charm, but > using the map while chatting and teleporting and using the inworld web > browser may be another story altogether. > > So, we'd like you to help by hammering on this issue, and reporting your > results (either positive or negative) in SNOW-2. In particular, some > things to try: > 1. Lots of things that would use HTTP simultaneously (e.g moving around > in the map, then quickly teleporting before the map loads in all of the way) > 2. Really use the map. Zoom out, zoom in, try to find regions with > missing textures > 3. grep the code yourself for libcurl usage, and figure out other ways > of torturing that code. > > Let's figure out if we need to figure this problem out before declaring > this "Snowglobe 1.0". > > Thanks! > Rob > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From sheet.spotter at gmail.com Tue Jun 9 20:37:39 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Tue, 9 Jun 2009 22:37:39 -0500 Subject: [sldev] SNOW-2: getting to the bottom of the curl crashers In-Reply-To: <4A2F0D93.2050106@lindenlab.com> References: <4A2F04DB.2020305@lindenlab.com> <4A2F0D93.2050106@lindenlab.com> Message-ID: <30B204D9290541878A6BCECCA815F08D@kenb> The main starting point for information about the new Snowglobe viewer is: http://wiki.secondlife.com/wiki/Snowglobe You can browse the source code for Snowglobe (also known as the http-texture branch) here: http://svn.secondlife.com/trac/linden/browser/projects/2009/http-texture You can use an SVN client to check out the source code from: http://svn.secondlife.com/svn/linden/projects/2009/http-texture Snowglobe now has its own section in the JIRA. It might also be helpful to prefix the Snowglobe related posts to SLDev with "[sldev][SNOW]" to group the related emails. Sheet Spotter -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Paul Oppenheim (Poppy Linden) Sent: June 9, 2009 8:34 PM To: Rob Lanphier Cc: Second Life Developer Mailing List Subject: Re: [sldev] SNOW-2: getting to the bottom of the curl crashers any link(s) to the relevant source? + poppy Rob Lanphier wrote: > Hi folks, > > We're trying to decide just how important SNOW-2 is: > http://jira.secondlife.com/browse/SNOW-2 > > This is our tracking issue for the vague crash reports we have involving > curl. We're not getting good stack traces or anything like that, and > people have generally not been complaining about this particular problem. > > However, based on some evidence that Merov noticed and is digging into > now, it would seem that the curl crashers seem to happen in the map code > (because secondlife.log indicates to be accessing S3 at the time of the > crash). Furthermore, the problem generally might be linked to improper > use of curl in the viewer (e.g. overusing the same curl handle). This > might be a case where gentle use of the map works like a charm, but > using the map while chatting and teleporting and using the inworld web > browser may be another story altogether. > > So, we'd like you to help by hammering on this issue, and reporting your > results (either positive or negative) in SNOW-2. In particular, some > things to try: > 1. Lots of things that would use HTTP simultaneously (e.g moving around > in the map, then quickly teleporting before the map loads in all of the way) > 2. Really use the map. Zoom out, zoom in, try to find regions with > missing textures > 3. grep the code yourself for libcurl usage, and figure out other ways > of torturing that code. > > Let's figure out if we need to figure this problem out before declaring > this "Snowglobe 1.0". > > Thanks! > Rob > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From robla at lindenlab.com Wed Jun 10 12:29:33 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 10 Jun 2009 12:29:33 -0700 Subject: [sldev] Code review request: branding patch SNOW-17 for Linux Message-ID: <4A30099D.6090801@lindenlab.com> Hi folks, More branding work. SNOW-17 has three patches, only one of which is ready for prime time. See: https://jira.secondlife.com/secure/ManageAttachments.jspa?id=34683 This has a couple of common changes plus the Linux-specific portion. It's not the perfect abstraction for branding, but it's a baby step in that direction. I'll check it in when I get a thumbs up from a committer. Rob From sldev at free.fr Wed Jun 10 13:36:35 2009 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 10 Jun 2009 22:36:35 +0200 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption In-Reply-To: <4A2E95CB.4070300@gmail.com> References: <4A241603.1050403@lindenlab.com> <4A2E95CB.4070300@gmail.com> Message-ID: <20090610223635.4d17e285.sldev@free.fr> On Tue, 09 Jun 2009 10:03:07 -0700, Dzonatas Sol wrote: > Soft wrote: > > It would also be great to see any numbers on 32- vs 64-bit > > performance, for any of you producing 32- and 64-bit stand-alone > > viewers. 64-bit would make setup easier. It would be helpful to know > > of any other gains. > > 32bit systems are limited to 4GB of main memory, but many motherboards > limit that further to only 2-3GB . This is wrong. 32bits systems can use up to 64GB of RAM, with 2.6 Linux kernels... It's just a matter of compiling the kernel with the right option: Processor type and feature --> High memory support --> 64GB (HIGHMEM64G) Henri. From dzonatas at gmail.com Wed Jun 10 14:42:16 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 10 Jun 2009 14:42:16 -0700 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption In-Reply-To: <20090610223635.4d17e285.sldev@free.fr> References: <4A241603.1050403@lindenlab.com> <4A2E95CB.4070300@gmail.com> <20090610223635.4d17e285.sldev@free.fr> Message-ID: <4A3028B8.5060302@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090610/33f7d440/attachment.htm From sldev at free.fr Wed Jun 10 16:37:48 2009 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 11 Jun 2009 01:37:48 +0200 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption Message-ID: <20090611013748.0ef1c326.sldev@free.fr> On Wed, 10 Jun 2009 14:42:16 -0700, Dzonatas Sol wrote: > Henri Beauchamp wrote:On Tue, 09 Jun 2009 10:03:07 -0700, Dzonatas Sol wrote: > > Soft wrote: > It would also be great to see any numbers on 32- vs 64-bit > performance, for any of you producing 32- and 64-bit stand-alone > viewers. 64-bit would make setup easier. It would be helpful to know > of any other gains. > 32bit systems are limited to 4GB of main memory, but many motherboards > limit that further to only 2-3GB . > > This is wrong. 32bits systems can use up to 64GB of RAM, with 2.6 Linux > kernels... It's just a matter of compiling the kernel with the right > option: > > Processor type and feature > --> High memory support > --> 64GB (HIGHMEM64G) > > Henri. > > When someone buys a Compaq Presario Home PC, you can expect the common > person who buys such a pre-built system won't be? one to uninstall > Windows and install a custom Linux Kernel. I'm afraid you are out of the topic... Like indicated in the message Subject line, Soft's original message dealt with 64bits *Linux* systems, not with Windows... Henri. From dzonatas at gmail.com Wed Jun 10 17:47:06 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 10 Jun 2009 17:47:06 -0700 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption In-Reply-To: <20090611013748.0ef1c326.sldev@free.fr> References: <20090611013748.0ef1c326.sldev@free.fr> Message-ID: <4A30540A.8070704@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090610/436634ed/attachment.htm From fire at b3dMultitech.com Wed Jun 10 17:35:30 2009 From: fire at b3dMultitech.com (Fire) Date: Wed, 10 Jun 2009 17:35:30 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? Message-ID: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> Hi everyone, just wondering (and I am sure this question has been asked before) but why, oh why, hasn't LL implemented the feature of writing to notecards? Wouldnt this solve a lot of our scripting nightmares? Ie: List memory limits etc? Give me an early merry xmass LLLD! (lovely linden lab developers) thoughts... ideas? opinions? all welcome! *Paul 'Fire' Preibisch* Educator, Content Creator, Virtual World Builder, Web 2.0 Consultant [image: Spreadfirefox Affiliate Button] [image: Spreadfirefox Affiliate Button] *Connect your Facebook Profile with your Second Life! http://apps.facebook.com/second-life/* *Need a Learning Management System for Second Life?Use Sloodle! * *Skype: Eslteacherlink.com* *Services: *Second Life Virtual World Construction, Machinima - Animation, Joomla Programming, Educational Website, LibsecondLife, Virtual Event Services Fire Centaur in Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090610/934ed6c5/attachment.htm From tigrospottystripes at gmail.com Wed Jun 10 17:46:21 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 10 Jun 2009 21:46:21 -0300 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> Message-ID: <4A3053DD.2010403@Gmail.com> I believe it has somthing to do with wanting to reduce the ways the asset server(s) can be (D)DOS'ed Fire escreveu: > Hi everyone, > > just wondering (and I am sure this question has been asked before) > but why, oh why, hasn't LL implemented the feature of writing to > notecards? > > Wouldnt this solve a lot of our scripting nightmares? Ie: List memory > limits > etc? > > Give me an early merry xmass LLLD! (lovely linden lab developers) > > thoughts... ideas? opinions? all welcome! > > > *Paul 'Fire' Preibisch* > Educator, Content Creator, Virtual World Builder, Web 2.0 Consultant > > Spreadfirefox > Affiliate Button > > > > Spreadfirefox Affiliate Button > > /Connect your Facebook Profile with your Second Life! > http://apps.facebook.com/second-life// > /Need a Learning Management System for Second Life?Use Sloodle! > / > /Skype: Eslteacherlink.com/ > *Services: *Second Life Virtual World Construction, Machinima - > Animation, Joomla Programming, Educational Website, LibsecondLife, > Virtual Event Services > Fire Centaur in Second Life > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From fire at b3dMultitech.com Wed Jun 10 17:48:28 2009 From: fire at b3dMultitech.com (Fire) Date: Wed, 10 Jun 2009 17:48:28 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A3053DD.2010403@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A3053DD.2010403@Gmail.com> Message-ID: <1dabc2a30906101748q66aeed71o83ef019a071f6e9f@mail.gmail.com> I promise I won't! ;p actually, why not just impose a limit on it like everything else? (just make it more than 32k please ;p;p;p) *Paul 'Fire' Preibisch* Educator, Content Creator, Virtual World Builder, Web 2.0 Consultant [image: Spreadfirefox Affiliate Button] [image: Spreadfirefox Affiliate Button] *Connect your Facebook Profile with your Second Life! http://apps.facebook.com/second-life/* *Need a Learning Management System for Second Life?Use Sloodle! * *Skype: Eslteacherlink.com* *Services: *Second Life Virtual World Construction, Machinima - Animation, Joomla Programming, Educational Website, LibsecondLife, Virtual Event Services Fire Centaur in Second Life On Wed, Jun 10, 2009 at 5:46 PM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > I believe it has somthing to do with wanting to reduce the ways the > asset server(s) can be (D)DOS'ed > > Fire escreveu: > > Hi everyone, > > > > just wondering (and I am sure this question has been asked before) > > but why, oh why, hasn't LL implemented the feature of writing to > > notecards? > > > > Wouldnt this solve a lot of our scripting nightmares? Ie: List memory > > limits > > etc? > > > > Give me an early merry xmass LLLD! (lovely linden lab developers) > > > > thoughts... ideas? opinions? all welcome! > > > > > > *Paul 'Fire' Preibisch* > > Educator, Content Creator, Virtual World Builder, Web 2.0 Consultant > > > > < > http://world.secondlife.com/resident/2102f5ab-6854-4ec3-aec5-6cd6233c31c6 > >Spreadfirefox > > Affiliate Button > > > > > > > > Spreadfirefox Affiliate Button > > > > /Connect your Facebook Profile with your Second Life! > > http://apps.facebook.com/second-life// > > /Need a Learning Management System for Second Life?Use Sloodle! > > / > > /Skype: Eslteacherlink.com/ > > *Services: *Second Life Virtual World Construction, Machinima - > > Animation, Joomla Programming, Educational Website, LibsecondLife, > > Virtual Event Services > > Fire Centaur in Second Life > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090610/f9e02b0d/attachment-0001.htm From dzonatas at gmail.com Wed Jun 10 18:09:29 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 10 Jun 2009 18:09:29 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> Message-ID: <4A305949.80102@gmail.com> Fire wrote: > Hi everyone, > > just wondering (and I am sure this question has been asked before) > but why, oh why, hasn't LL implemented the feature of writing to > notecards? > > Wouldnt this solve a lot of our scripting nightmares? Ie: List memory > limits > etc? > > Give me an early merry xmass LLLD! (lovely linden lab developers) > > thoughts... ideas? opinions? all welcome! > Notecards are tied to a UUID. When you edit a notecard, it creates a new UUID for each new version of the notecard. It's rumored someone at LL decided to prevent a continuous (and possible abusive) creation of new UUIDs for each version of a notecard by simplly not implementing the LSL command to write to notecards. If you need a DB like storage, just write a listener/sender LSL-program to store values in memory. One LSL program is good for 8K of memory (actually more than that is available, but you'll need room to copy arrays around to avoid a script crash). From missannotoole at yahoo.com Wed Jun 10 18:06:49 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed, 10 Jun 2009 18:06:49 -0700 (PDT) Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A305949.80102@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A305949.80102@gmail.com> Message-ID: <493371.88333.qm@web59102.mail.re1.yahoo.com> script memory limits are incoming. It is unwise to assume there will always be plenty of memory for scripts. I.e. at some point newly activated scripts in a parcel or in attachments will cease functioning if the memory pool limit is exceeded. Better to use a web host and use out of grid assets you control for data persistence. ________________________________ From: Dzonatas Sol To: fire at b3dMultitech.com Cc: "sldev at lists.secondlife.com >> SLDev" Sent: Wednesday, June 10, 2009 9:09:29 PM Subject: Re: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? Fire wrote: > Hi everyone, > > just wondering (and I am sure this question has been asked before) > but why, oh why, hasn't LL implemented the feature of writing to > notecards? > > Wouldnt this solve a lot of our scripting nightmares? Ie: List memory > limits > etc? > > Give me an early merry xmass LLLD! (lovely linden lab developers) > > thoughts... ideas? opinions? all welcome! > Notecards are tied to a UUID. When you edit a notecard, it creates a new UUID for each new version of the notecard. It's rumored someone at LL decided to prevent a continuous (and possible abusive) creation of new UUIDs for each version of a notecard by simplly not implementing the LSL command to write to notecards. If you need a DB like storage, just write a listener/sender LSL-program to store values in memory. One LSL program is good for 8K of memory (actually more than that is available, but you'll need room to copy arrays around to avoid a script crash). _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090610/8abf4230/attachment.htm From lenglish5 at cox.net Wed Jun 10 18:33:39 2009 From: lenglish5 at cox.net (Lawson English) Date: Wed, 10 Jun 2009 18:33:39 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A305949.80102@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A305949.80102@gmail.com> Message-ID: <4A305EF3.7090706@cox.net> Dzonatas Sol wrote: > Fire wrote: > >> Hi everyone, >> >> just wondering (and I am sure this question has been asked before) >> but why, oh why, hasn't LL implemented the feature of writing to >> notecards? >> >> Wouldnt this solve a lot of our scripting nightmares? Ie: List memory >> limits >> etc? >> >> Give me an early merry xmass LLLD! (lovely linden lab developers) >> >> thoughts... ideas? opinions? all welcome! >> >> > > Notecards are tied to a UUID. When you edit a notecard, it creates a new > UUID for each new version of the notecard. It's rumored someone at LL > decided to prevent a continuous (and possible abusive) creation of new > UUIDs for each version of a notecard by simplly not implementing the LSL > command to write to notecards. > > If you need a DB like storage, just write a listener/sender LSL-program > to store values in memory. One LSL program is good for 8K of memory > (actually more than that is available, but you'll need room to copy > arrays around to avoid a script crash). > Is the practical limitation the same with mono-compiled scripts? L. From dzonatas at gmail.com Wed Jun 10 18:57:43 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 10 Jun 2009 18:57:43 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A305EF3.7090706@cox.net> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A305949.80102@gmail.com> <4A305EF3.7090706@cox.net> Message-ID: <4A306497.2080209@gmail.com> Lawson English wrote: >> > > Is the practical limitation the same with mono-compiled scripts? > > L. > =) Not if one wants to setup like 128 LSL programs in a single object and use each program as a bank of memory, that would be 8K * 128 = 1 megabyte of memory, at least. One could even run OpenSim and set the max memory size per script as they please. *wink* From tigrospottystripes at gmail.com Wed Jun 10 18:54:48 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Wed, 10 Jun 2009 22:54:48 -0300 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A306497.2080209@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A305949.80102@gmail.com> <4A305EF3.7090706@cox.net> <4A306497.2080209@gmail.com> Message-ID: <4A3063E8.8070805@Gmail.com> mono uses double the memory for strings, you only get more memory than non-mono scripts if you don't use strings I think Dzonatas Sol escreveu: > Lawson English wrote: > >>> >>> >> Is the practical limitation the same with mono-compiled scripts? >> >> L. >> >> > > > =) > > > Not if one wants to setup like 128 LSL programs in a single object and > use each program as a bank of memory, that would be 8K * 128 = 1 > megabyte of memory, at least. One could even run OpenSim and set the > max memory size per script as they please. *wink* > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From stickman at gmail.com Wed Jun 10 19:12:18 2009 From: stickman at gmail.com (Stickman) Date: Wed, 10 Jun 2009 19:12:18 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <493371.88333.qm@web59102.mail.re1.yahoo.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A305949.80102@gmail.com> <493371.88333.qm@web59102.mail.re1.yahoo.com> Message-ID: > script memory limits are incoming. REALLY anxious to hear the metrics LL has been collecting on this, as well as their proposed caps. -Stickman From dmahalko at gmail.com Wed Jun 10 19:23:59 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed, 10 Jun 2009 21:23:59 -0500 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> Message-ID: Saving a notecard makes a new one. The old data hangs around in the asset server apparently forever, so if you have 16k of temporary data and you change 1 byte of it and save the change, you're burning 16 kb per write. Over time this could end up being gigabytes to terabytes of wasted space in the asset system across thousands of program write operations, and LL has to provide expensive RAID and do tape archiving, etc etc of all that.. UUIDs are not reused when objects are modified because of some design concept regarding data-access efficiency and caching. Woohoo, don't you love clear and direct answers? I think this was discussed a long while back but I don't see anything in my SLDev keyword searches. Okay, um, if I recall right, saving UUID changes would make the cached asset state stale and then you need to add mechanisms to keep the cache up to date with the main db, or for the main db to notify cache siblings of UUID state changes. If you don't ever allow UUID changes then the cached state never needs to be checked and can always be handed out to clients at much greater speed than if state checks were needed, but this speed comes at the price of poor storage efficiency of not recovering space used by changed UUIDs that may never be accessed ever again. There's no way to assess whether a saved asset was just temporary data that will never be used again vs a UUID that just won't be used again for a very very long time. LL can prune "infrequently used" UUIDs out of the main db running on expensive 15,000 RPM SAS drives, and move the infrequent assets to slower less-expensive "nearline storage", but LL can't ever really delete anything since there's no way to know if it might be needed by a user, or really never again. The slack from unused objects that were temporary and will never be accessed, probably accounts for a certain sizable chunk of those terabytes of growing asset storage you sometimes hear about. - Dale Mahalko / Scalar Tardis On Wed, Jun 10, 2009 at 7:35 PM, Fire wrote: > just wondering (and I am sure this question has been asked before) > but why, oh why, hasn't LL implemented the feature of writing to notecards? > > Wouldnt this solve a lot of our scripting nightmares?? Ie: List memory > limits > etc? From secret.argent at gmail.com Wed Jun 10 19:54:41 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 10 Jun 2009 21:54:41 -0500 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> Message-ID: A better solution would be something line http://jira.secondlife.com/browse/SVC-1406 since the memory would (a) be reused, (b) be more efficient than script storage, and (c) be on the sim rather than the asset server, so it would scale better. From kelly at lindenlab.com Wed Jun 10 19:59:39 2009 From: kelly at lindenlab.com (kelly at lindenlab.com) Date: Wed, 10 Jun 2009 19:59:39 -0700 (PDT) Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> Message-ID: <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> Dale is pretty darn close, so I'll only hit on the differences. And some about other emails I have seen in this thread. :) * We do garbage collection on the asset system. We scan for references to other assets (and anything that looks like an asset ID etc) and move unreferenced objects off to the side. After some period of no requests for those assets they are deleted. This is relatively effective at our current rate of asset creation. The actual growth rate of the asset server is well within reason at this point and is not unbounded. (I say 'current' and 'at this point' because this hasn't always been the case and I've been involved in more than a couple projects to reduce the rate at which we create new assets. :) ) * A large part of the "new asset for every save" is pure legacy. The system started and was designed as "write once", and there are a lot of optimizations you can make if you know a specific UUID will always point to the exact same thing. Now our system is large and complex. We have worked on rewritable assets for various reasons (usually attachment related) but these projects are difficult and complicated and tend to break things you wouldn't expect. * Content creators tend to think notecards because notecards are what we have and what we can store manually entered data into and read from. They aren't optimal though even if we ignore the show stopping asset creation rate in the current system. Every time you read from a notecard the simulator must fetch that notecard from the asset server and load it into memory. Sure it keeps a LRU cache of cards around so it doesn't fetch for *every* read, but this is hardly the right way to go about script data storage. Also this data isn't exactly random access, I think reading a notecard via lsl line by line is an O(n^2) operation. And another point - how do you handle the inevitable race conditions as two scripts read and write to the same asset? SVC-1406 that Argent mentions is a good example of better out of the box thinking. * I *hate* the project name "memory limits". While it is true that part of this project will be limiting total sim-wide script memory available, we are likely talking about levels that already significantly degrade simulator performance. As a content creator I am *really* looking forward to "memory limits" because with it we can introduce dynamic memory sizes for individual scripts. Forget that project that needs 10 scripts, half of each of which is the communication glue for them to work together. Instead have one script that can use the memory it needs. I don't have all the details on the final design, and I'm sure it will be adjusted with every round of statistics we collect, but you could look at how we handle URLs for HTTP-In as a starting point. In short, writable notecards just aren't going to happen. It would be a horrible hack anyway with crappy performance. We have llHTTPRequest already which is ideal for accessing and storing data on an external host. I have even seen services specifically for LSL that will store a small amount for free. Perhaps http_request, maybe specifically because it can do obj->obj, will open new options in 1.27 (on aditi now!). And so probably will the "script memory limits" project. - Kelly > Saving a notecard makes a new one. The old data hangs around in the > asset server apparently forever, so if you have 16k of temporary data > and you change 1 byte of it and save the change, you're burning 16 kb > per write. Over time this could end up being gigabytes to terabytes of > wasted space in the asset system across thousands of program write > operations, and LL has to provide expensive RAID and do tape > archiving, etc etc of all that.. > > UUIDs are not reused when objects are modified because of some design > concept regarding data-access efficiency and caching. Woohoo, don't > you love clear and direct answers? I think this was discussed a long > while back but I don't see anything in my SLDev keyword searches. > > > Okay, um, if I recall right, saving UUID changes would make the cached > asset state stale and then you need to add mechanisms to keep the > cache up to date with the main db, or for the main db to notify cache > siblings of UUID state changes. > > If you don't ever allow UUID changes then the cached state never needs > to be checked and can always be handed out to clients at much greater > speed than if state checks were needed, but this speed comes at the > price of poor storage efficiency of not recovering space used by > changed UUIDs that may never be accessed ever again. > > > There's no way to assess whether a saved asset was just temporary data > that will never be used again vs a UUID that just won't be used again > for a very very long time. LL can prune "infrequently used" UUIDs out > of the main db running on expensive 15,000 RPM SAS drives, and move > the infrequent assets to slower less-expensive "nearline storage", but > LL can't ever really delete anything since there's no way to know if > it might be needed by a user, or really never again. > > The slack from unused objects that were temporary and will never be > accessed, probably accounts for a certain sizable chunk of those > terabytes of growing asset storage you sometimes hear about. > > - Dale Mahalko / Scalar Tardis > > > On Wed, Jun 10, 2009 at 7:35 PM, Fire wrote: >> just wondering (and I am sure this question has been asked before) >> but why, oh why, hasn't LL implemented the feature of writing to >> notecards? >> >> Wouldnt this solve a lot of our scripting nightmares?? Ie: List memory >> limits >> etc? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From dzonatas at gmail.com Wed Jun 10 21:02:11 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 10 Jun 2009 21:02:11 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> Message-ID: <4A3081C3.6020606@gmail.com> +1 kelly at lindenlab.com wrote: > SVC-1406 that Argent mentions is a good example > of better out of the box thinking. From tigrospottystripes at gmail.com Wed Jun 10 21:06:23 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 11 Jun 2009 01:06:23 -0300 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> Message-ID: <4A3082BF.8090803@Gmail.com> slightly off-topic question, could you explain how exaclty the system confirms that some old UUID isn't inside someone's inventory or inside an object or even a notecard before deleting it please? kelly at lindenlab.com escreveu: > Dale is pretty darn close, so I'll only hit on the differences. And some > about other emails I have seen in this thread. :) > > * We do garbage collection on the asset system. We scan for references to > other assets (and anything that looks like an asset ID etc) and move > unreferenced objects off to the side. After some period of no requests > for those assets they are deleted. This is relatively effective at our > current rate of asset creation. The actual growth rate of the asset > server is well within reason at this point and is not unbounded. (I say > 'current' and 'at this point' because this hasn't always been the case and > I've been involved in more than a couple projects to reduce the rate at > which we create new assets. :) ) > > * A large part of the "new asset for every save" is pure legacy. The > system started and was designed as "write once", and there are a lot of > optimizations you can make if you know a specific UUID will always point > to the exact same thing. Now our system is large and complex. We have > worked on rewritable assets for various reasons (usually attachment > related) but these projects are difficult and complicated and tend to > break things you wouldn't expect. > > * Content creators tend to think notecards because notecards are what we > have and what we can store manually entered data into and read from. They > aren't optimal though even if we ignore the show stopping asset creation > rate in the current system. Every time you read from a notecard the > simulator must fetch that notecard from the asset server and load it into > memory. Sure it keeps a LRU cache of cards around so it doesn't fetch for > *every* read, but this is hardly the right way to go about script data > storage. Also this data isn't exactly random access, I think reading a > notecard via lsl line by line is an O(n^2) operation. And another point - > how do you handle the inevitable race conditions as two scripts read and > write to the same asset? SVC-1406 that Argent mentions is a good example > of better out of the box thinking. > > * I *hate* the project name "memory limits". While it is true that part > of this project will be limiting total sim-wide script memory available, > we are likely talking about levels that already significantly degrade > simulator performance. As a content creator I am *really* looking forward > to "memory limits" because with it we can introduce dynamic memory sizes > for individual scripts. Forget that project that needs 10 scripts, half > of each of which is the communication glue for them to work together. > Instead have one script that can use the memory it needs. I don't have > all the details on the final design, and I'm sure it will be adjusted with > every round of statistics we collect, but you could look at how we handle > URLs for HTTP-In as a starting point. > > In short, writable notecards just aren't going to happen. It would be a > horrible hack anyway with crappy performance. We have llHTTPRequest > already which is ideal for accessing and storing data on an external host. > I have even seen services specifically for LSL that will store a small > amount for free. Perhaps http_request, maybe specifically because it can > do obj->obj, will open new options in 1.27 (on aditi now!). And so > probably will the "script memory limits" project. > > - Kelly > > > >> Saving a notecard makes a new one. The old data hangs around in the >> asset server apparently forever, so if you have 16k of temporary data >> and you change 1 byte of it and save the change, you're burning 16 kb >> per write. Over time this could end up being gigabytes to terabytes of >> wasted space in the asset system across thousands of program write >> operations, and LL has to provide expensive RAID and do tape >> archiving, etc etc of all that.. >> >> UUIDs are not reused when objects are modified because of some design >> concept regarding data-access efficiency and caching. Woohoo, don't >> you love clear and direct answers? I think this was discussed a long >> while back but I don't see anything in my SLDev keyword searches. >> >> >> Okay, um, if I recall right, saving UUID changes would make the cached >> asset state stale and then you need to add mechanisms to keep the >> cache up to date with the main db, or for the main db to notify cache >> siblings of UUID state changes. >> >> If you don't ever allow UUID changes then the cached state never needs >> to be checked and can always be handed out to clients at much greater >> speed than if state checks were needed, but this speed comes at the >> price of poor storage efficiency of not recovering space used by >> changed UUIDs that may never be accessed ever again. >> >> >> There's no way to assess whether a saved asset was just temporary data >> that will never be used again vs a UUID that just won't be used again >> for a very very long time. LL can prune "infrequently used" UUIDs out >> of the main db running on expensive 15,000 RPM SAS drives, and move >> the infrequent assets to slower less-expensive "nearline storage", but >> LL can't ever really delete anything since there's no way to know if >> it might be needed by a user, or really never again. >> >> The slack from unused objects that were temporary and will never be >> accessed, probably accounts for a certain sizable chunk of those >> terabytes of growing asset storage you sometimes hear about. >> >> - Dale Mahalko / Scalar Tardis >> >> >> On Wed, Jun 10, 2009 at 7:35 PM, Fire wrote: >> >>> just wondering (and I am sure this question has been asked before) >>> but why, oh why, hasn't LL implemented the feature of writing to >>> notecards? >>> >>> Wouldnt this solve a lot of our scripting nightmares? Ie: List memory >>> limits >>> etc? >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From kelly at lindenlab.com Wed Jun 10 21:53:33 2009 From: kelly at lindenlab.com (kelly at lindenlab.com) Date: Wed, 10 Jun 2009 21:53:33 -0700 (PDT) Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A3082BF.8090803@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> Message-ID: <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> MAGIC! I don't know the exact details about how the current version works so *please* don't respond to my answer with the million ways it could be optimized or what it will miss etc. A lot of effort and revisions have gone into this. This is extremely roughly what it does, or did at one point and covers the gist of how GC on assets might work. * Step 1: Scan the contents of every asset, every simstate and every residents inventory for anything that looks vaguely like a UUID and build a list of those UUIDs. This means the text of every script, the contents of every notecard, the inventory of every item. * Step 2: Delete anything not in that list, but created before the scan started. * Step 3: Go to step 1. That is an extremely simplified version of course, and it gets more complicated as you work to make it more robust (find all those ids), safer (don't delete straight away) and faster. - Kelly > slightly off-topic question, could you explain how exaclty the system > confirms that some old UUID isn't inside someone's inventory or inside > an object or even a notecard before deleting it please? > > kelly at lindenlab.com escreveu: >> Dale is pretty darn close, so I'll only hit on the differences. And >> some >> about other emails I have seen in this thread. :) >> >> * We do garbage collection on the asset system. We scan for references >> to >> other assets (and anything that looks like an asset ID etc) and move >> unreferenced objects off to the side. After some period of no requests >> for those assets they are deleted. This is relatively effective at our >> current rate of asset creation. The actual growth rate of the asset >> server is well within reason at this point and is not unbounded. (I say >> 'current' and 'at this point' because this hasn't always been the case >> and >> I've been involved in more than a couple projects to reduce the rate at >> which we create new assets. :) ) >> >> * A large part of the "new asset for every save" is pure legacy. The >> system started and was designed as "write once", and there are a lot of >> optimizations you can make if you know a specific UUID will always point >> to the exact same thing. Now our system is large and complex. We have >> worked on rewritable assets for various reasons (usually attachment >> related) but these projects are difficult and complicated and tend to >> break things you wouldn't expect. >> >> * Content creators tend to think notecards because notecards are what we >> have and what we can store manually entered data into and read from. >> They >> aren't optimal though even if we ignore the show stopping asset creation >> rate in the current system. Every time you read from a notecard the >> simulator must fetch that notecard from the asset server and load it >> into >> memory. Sure it keeps a LRU cache of cards around so it doesn't fetch >> for >> *every* read, but this is hardly the right way to go about script data >> storage. Also this data isn't exactly random access, I think reading a >> notecard via lsl line by line is an O(n^2) operation. And another point >> - >> how do you handle the inevitable race conditions as two scripts read and >> write to the same asset? SVC-1406 that Argent mentions is a good >> example >> of better out of the box thinking. >> >> * I *hate* the project name "memory limits". While it is true that part >> of this project will be limiting total sim-wide script memory available, >> we are likely talking about levels that already significantly degrade >> simulator performance. As a content creator I am *really* looking >> forward >> to "memory limits" because with it we can introduce dynamic memory sizes >> for individual scripts. Forget that project that needs 10 scripts, half >> of each of which is the communication glue for them to work together. >> Instead have one script that can use the memory it needs. I don't have >> all the details on the final design, and I'm sure it will be adjusted >> with >> every round of statistics we collect, but you could look at how we >> handle >> URLs for HTTP-In as a starting point. >> >> In short, writable notecards just aren't going to happen. It would be a >> horrible hack anyway with crappy performance. We have llHTTPRequest >> already which is ideal for accessing and storing data on an external >> host. >> I have even seen services specifically for LSL that will store a small >> amount for free. Perhaps http_request, maybe specifically because it >> can >> do obj->obj, will open new options in 1.27 (on aditi now!). And so >> probably will the "script memory limits" project. >> >> - Kelly >> >> >> >>> Saving a notecard makes a new one. The old data hangs around in the >>> asset server apparently forever, so if you have 16k of temporary data >>> and you change 1 byte of it and save the change, you're burning 16 kb >>> per write. Over time this could end up being gigabytes to terabytes of >>> wasted space in the asset system across thousands of program write >>> operations, and LL has to provide expensive RAID and do tape >>> archiving, etc etc of all that.. >>> >>> UUIDs are not reused when objects are modified because of some design >>> concept regarding data-access efficiency and caching. Woohoo, don't >>> you love clear and direct answers? I think this was discussed a long >>> while back but I don't see anything in my SLDev keyword searches. >>> >>> >>> Okay, um, if I recall right, saving UUID changes would make the cached >>> asset state stale and then you need to add mechanisms to keep the >>> cache up to date with the main db, or for the main db to notify cache >>> siblings of UUID state changes. >>> >>> If you don't ever allow UUID changes then the cached state never needs >>> to be checked and can always be handed out to clients at much greater >>> speed than if state checks were needed, but this speed comes at the >>> price of poor storage efficiency of not recovering space used by >>> changed UUIDs that may never be accessed ever again. >>> >>> >>> There's no way to assess whether a saved asset was just temporary data >>> that will never be used again vs a UUID that just won't be used again >>> for a very very long time. LL can prune "infrequently used" UUIDs out >>> of the main db running on expensive 15,000 RPM SAS drives, and move >>> the infrequent assets to slower less-expensive "nearline storage", but >>> LL can't ever really delete anything since there's no way to know if >>> it might be needed by a user, or really never again. >>> >>> The slack from unused objects that were temporary and will never be >>> accessed, probably accounts for a certain sizable chunk of those >>> terabytes of growing asset storage you sometimes hear about. >>> >>> - Dale Mahalko / Scalar Tardis >>> >>> >>> On Wed, Jun 10, 2009 at 7:35 PM, Fire wrote: >>> >>>> just wondering (and I am sure this question has been asked before) >>>> but why, oh why, hasn't LL implemented the feature of writing to >>>> notecards? >>>> >>>> Wouldnt this solve a lot of our scripting nightmares? Ie: List memory >>>> limits >>>> etc? >>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > From tigrospottystripes at gmail.com Wed Jun 10 22:07:39 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 11 Jun 2009 02:07:39 -0300 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> Message-ID: <4A30911B.9050908@Gmail.com> kelly at lindenlab.com escreveu: > MAGIC! > > I don't know the exact details about how the current version works so > *please* don't respond to my answer with the million ways it could be > optimized or what it will miss etc. A lot of effort and revisions have > gone into this. This is extremely roughly what it does, or did at one > point and covers the gist of how GC on assets might work. > > * Step 1: Scan the contents of every asset, every simstate and every > residents inventory for anything that looks vaguely like a UUID and build > a list of those UUIDs. This means the text of every script, the contents > of every notecard, the inventory of every item. > * Step 2: Delete anything not in that list, but created before the scan > started. > * Step 3: Go to step 1. > > That is an extremely simplified version of course, and it gets more > complicated as you work to make it more robust (find all those ids), safer > (don't delete straight away) and faster. > > - Kelly > > Interesting, much more comprehensive than I expected, but can you explain me why the client doesn't got such a thorough capability of reading the inventory? (the total item count for my inv varies from about 9k to 30k+ depending on my luck, regardless of how many items I add or delete) Or does the check randomly misses things in the inventory like the client do? From tateru.nino at gmail.com Wed Jun 10 22:30:20 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu, 11 Jun 2009 15:30:20 +1000 Subject: [sldev] Asset garbage collection and inventory (Was: Why hasn't Linden Lab implemented WRITING to NOTECARD?) In-Reply-To: <4A30911B.9050908@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> Message-ID: <4A30966C.20000@weblogsinc.com> Tigro Spottystripes wrote: > kelly at lindenlab.com escreveu: > >> MAGIC! >> >> I don't know the exact details about how the current version works so >> *please* don't respond to my answer with the million ways it could be >> optimized or what it will miss etc. A lot of effort and revisions have >> gone into this. This is extremely roughly what it does, or did at one >> point and covers the gist of how GC on assets might work. >> >> * Step 1: Scan the contents of every asset, every simstate and every >> residents inventory for anything that looks vaguely like a UUID and build >> a list of those UUIDs. This means the text of every script, the contents >> of every notecard, the inventory of every item. >> * Step 2: Delete anything not in that list, but created before the scan >> started. >> * Step 3: Go to step 1. >> >> That is an extremely simplified version of course, and it gets more >> complicated as you work to make it more robust (find all those ids), safer >> (don't delete straight away) and faster. >> >> - Kelly >> >> >> > Interesting, much more comprehensive than I expected, but can you > explain me why the client doesn't got such a thorough capability of > reading the inventory? (the total item count for my inv varies from > about 9k to 30k+ depending on my luck, regardless of how many items I > add or delete) Or does the check randomly misses things in the inventory > like the client do? Inventory is transferred to the viewer by a not-entirely-reliable means (something that I understand is in the throes of being replaced) - it's possible for the viewer to wind up caching what is only a subset of your inventory and thinking that it has it all. The full inventory is still there, and in place on the inventory servers, but the viewer isn't necessarily seeing it. My understanding is that the agent inventory service is supposed to provide an autoreliable transfer of that list to the viewer. It was slated for Q1 2009, but appears to have slipped a little. I am honestly quite curious as to how that's getting on. -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090611/9aaa7728/attachment-0001.htm From dzonatas at gmail.com Wed Jun 10 22:52:26 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 10 Jun 2009 22:52:26 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A30911B.9050908@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> Message-ID: <4A309B9A.8080305@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090610/e67ead5d/attachment.htm From tigrospottystripes at gmail.com Wed Jun 10 22:53:59 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 11 Jun 2009 02:53:59 -0300 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A309B9A.8080305@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> Message-ID: <4A309BF7.4020204@Gmail.com> I believe I understood most of what you said. The client does many analysis on the contents of the inventory each time any new info about it comes, so with a big inventory there is lots to do each time, and lots of times. But your explanation raised two questions IMO,why the client can't walk and chew bubble gum at the same time, and why it was allowed to think it got the whole inventory when it doesn't. Actually, 3 questions, the rhird is why the client was allowed to have the login process be so fragile while at the same time throwing heavy things into the login process. Dzonatas Sol escreveu: > If you look at LLGestureManager, you'll notice that it has "listeners" > that watch changes to the active list of inventory items (for gesture > in the case of LLGestureManager). When a change happens, then a > routine is called that reads the active list, sorts the items, and > builds arrays of data for later processes like combo boxes, or search > keys, and more. The problem is that it does a fresh sort every time > the list is touched. That means as the login process happens, about > the point where the progress meter reaches just beyond half way, it'll > send and receive inventory requests and sort all that data over and > over again for each special list for each item received. If you've > messed with the login process at all, you'll find that it is really > easy to timeout the login process. Most likely, if you have 30K > objects, you are well beyond the possibility of sorting those lists a > couple ten thousand times before you appear in world. This further > means that any time spent too long to sort those lists could lead to > packets being dropped. If I haven't confused you yet, then you would > realize that after you login, it could be very easy for you entire > inventory not to appear, and you'll have to refresh it (manually) > where you'll have more luck to complete the inventory download since > the local cache has already has stored many of the recently requested > assets, which means it doesn't have to request all the inventory from > the server the next time around. > > Anybody, feel free to explain that easier, go ahead! =) > > Tigro Spottystripes wrote: >> >> Interesting, much more comprehensive than I expected, but can you >> explain me why the client doesn't got such a thorough capability of >> reading the inventory? (the total item count for my inv varies from >> about 9k to 30k+ depending on my luck, regardless of how many items I >> add or delete) Or does the check randomly misses things in the inventory >> like the client do? >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > From melinda at superliminal.com Wed Jun 10 23:07:11 2009 From: melinda at superliminal.com (Melinda Green) Date: Wed, 10 Jun 2009 23:07:11 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A309BF7.4020204@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> Message-ID: <4A309F0F.3060908@superliminal.com> Tigro Spottystripes wrote: > I believe I understood most of what you said. The client does many > analysis on the contents of the inventory each time any new info about > it comes, so with a big inventory there is lots to do each time, and > lots of times. But your explanation raised two questions IMO,why the > client can't walk and chew bubble gum at the same time, That question makes no sense. Obviously the client does lots of things at once and that complexity contributes a lot to these problems. > and why it was > allowed to think it got the whole inventory when it doesn't. Uh, maybe because there's a bug in there somewhere that hasn't been squished yet? > Actually, 3 > questions, the rhird is why the client was allowed to have the login > process be so fragile while at the same time throwing heavy things into > the login process. > Because it grew organically, one feature at a time the way living software does. Of course feature addition needs to be balanced with refactoring activities to keep things manageable, but those activities do happen to, maybe just not at the level that they should. In short, creating a vibrant, self-sustaining world is hard. At least your questions are easy! :-) -Melinda > Dzonatas Sol escreveu: > >> If you look at LLGestureManager, you'll notice that it has "listeners" >> that watch changes to the active list of inventory items (for gesture >> in the case of LLGestureManager). When a change happens, then a >> routine is called that reads the active list, sorts the items, and >> builds arrays of data for later processes like combo boxes, or search >> keys, and more. The problem is that it does a fresh sort every time >> the list is touched. That means as the login process happens, about >> the point where the progress meter reaches just beyond half way, it'll >> send and receive inventory requests and sort all that data over and >> over again for each special list for each item received. If you've >> messed with the login process at all, you'll find that it is really >> easy to timeout the login process. Most likely, if you have 30K >> objects, you are well beyond the possibility of sorting those lists a >> couple ten thousand times before you appear in world. This further >> means that any time spent too long to sort those lists could lead to >> packets being dropped. If I haven't confused you yet, then you would >> realize that after you login, it could be very easy for you entire >> inventory not to appear, and you'll have to refresh it (manually) >> where you'll have more luck to complete the inventory download since >> the local cache has already has stored many of the recently requested >> assets, which means it doesn't have to request all the inventory from >> the server the next time around. >> >> Anybody, feel free to explain that easier, go ahead! =) >> >> Tigro Spottystripes wrote: >> >>> Interesting, much more comprehensive than I expected, but can you >>> explain me why the client doesn't got such a thorough capability of >>> reading the inventory? (the total item count for my inv varies from >>> about 9k to 30k+ depending on my luck, regardless of how many items I >>> add or delete) Or does the check randomly misses things in the inventory >>> like the client do? >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> >>> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From dzonatas at gmail.com Wed Jun 10 23:31:11 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Wed, 10 Jun 2009 23:31:11 -0700 Subject: [sldev] Asset GC, inventory, login process Re: Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A309BF7.4020204@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> Message-ID: <4A30A4AF.8060709@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090610/b8f9de39/attachment.htm From tigrospottystripes at gmail.com Wed Jun 10 23:29:03 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 11 Jun 2009 03:29:03 -0300 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A309F0F.3060908@superliminal.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> Message-ID: <4A30A42F.9050705@Gmail.com> Melinda Green escreveu: > Tigro Spottystripes wrote: >> I believe I understood most of what you said. The client does many >> analysis on the contents of the inventory each time any new info about >> it comes, so with a big inventory there is lots to do each time, and >> lots of times. But your explanation raised two questions IMO,why the >> client can't walk and chew bubble gum at the same time, > > That question makes no sense. Obviously the client does lots of things > at once and that complexity contributes a lot to these problems. From melinda at superliminal.com Thu Jun 11 02:24:31 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 11 Jun 2009 02:24:31 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A30A42F.9050705@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> Message-ID: <4A30CD4F.4050807@superliminal.com> Tigro Spottystripes wrote: > Melinda Green escreveu: > >> Tigro Spottystripes wrote: >> >>> I believe I understood most of what you said. The client does many >>> analysis on the contents of the inventory each time any new info about >>> it comes, so with a big inventory there is lots to do each time, and >>> lots of times. But your explanation raised two questions IMO,why the >>> client can't walk and chew bubble gum at the same time, >>> >> That question makes no sense. Obviously the client does lots of things >> at once and that complexity contributes a lot to these problems. >> > > >From what Dzonatas said, I understood that the client somtimes might > bite more than it can chew and allows for things to time out during > login instead of doing things in the background at the same time it > makes sure the server doesn't think the client is gone. > Well, you can't have walking and chewing without some biting I guess. :-) I like Dzonatas' solution to defer sorting until actually needed for display, if ever. If you like it too, then please notice that his solution adds more complexity in the form of the dirty flag. If that flag ever gets out of sync, then the list won't appear sorted. Although there was previously a performance issue, that type of synchronization bug was at least not possible. Was the performance savings worth the complexity? Maybe so but I'd really rather find a solution with less risk. Like perhaps only sorting when the drop-down is opened. My point is not on what is the best solution to this problem but simply that sometimes it's worth suffering some extra code complexity and the inevitable future bugs that complexity always brings. Bugs such as this one that seems to make you so upset. What I don't understand is what your point is in insulting the code. Lots of the viewer code is beautiful and lots of it is messy and fragile, but calling it all stupid is almost the same as calling the developers dumb which is not what we need. -Melinda From fire at b3dMultitech.com Thu Jun 11 02:46:48 2009 From: fire at b3dMultitech.com (Fire) Date: Thu, 11 Jun 2009 02:46:48 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A305949.80102@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A305949.80102@gmail.com> Message-ID: <1dabc2a30906110246i3a01b53eua7da3e6abf8dc4e6@mail.gmail.com> Hi Dzonatas, thanks for the response. you wrote: *"When you edit a notecard, it creates a new UUID for each new version of the notecard."* This is interesting, I'm curious though, why is each consequitive "save" allocated a new UUID? Does this mean, when I open a notecard, type a few lines, press save, then type a few more lines, press save, two UUID's would have been dispatched? Or do you mean, if you copy the notecard from one prim to another - a separate UUID is dispatched? -- while on the subject of notecard content - I'm wondering if Linden Labs has ever heard the request for HTML / live web content made available in notecards. It might add quite an interesting dimension to SL. With the proper xml handshaking / scripting code having a direct to the web would open up a tonne of interesting concoctions. Certainly would make inworld user manuals prettier. Would allow for the publications of magazines in HTML, etc etc.. hmmm... ok, I'll stop before I go too far down the rabit hole... heh On Wed, Jun 10, 2009 at 6:09 PM, Dzonatas Sol wrote: > Fire wrote: > >> Hi everyone, >> >> just wondering (and I am sure this question has been asked before) >> but why, oh why, hasn't LL implemented the feature of writing to >> notecards? >> >> Wouldnt this solve a lot of our scripting nightmares? Ie: List memory >> limits >> etc? >> >> Give me an early merry xmass LLLD! (lovely linden lab developers) >> >> thoughts... ideas? opinions? all welcome! >> >> > Notecards are tied to a UUID. When you edit a notecard, it creates a new > UUID for each new version of the notecard. It's rumored someone at LL > decided to prevent a continuous (and possible abusive) creation of new UUIDs > for each version of a notecard by simplly not implementing the LSL command > to write to notecards. > > If you need a DB like storage, just write a listener/sender LSL-program to > store values in memory. One LSL program is good for 8K of memory (actually > more than that is available, but you'll need room to copy arrays around to > avoid a script crash). > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090611/7635323b/attachment-0001.htm From tigrospottystripes at gmail.com Thu Jun 11 02:49:30 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 11 Jun 2009 06:49:30 -0300 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A30CD4F.4050807@superliminal.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> Message-ID: <4A30D32A.5060909@Gmail.com> Melinda Green escreveu: > Tigro Spottystripes wrote: >> Melinda Green escreveu: >> >>> Tigro Spottystripes wrote: >>> >>>> I believe I understood most of what you said. The client does many >>>> analysis on the contents of the inventory each time any new info about >>>> it comes, so with a big inventory there is lots to do each time, and >>>> lots of times. But your explanation raised two questions IMO,why the >>>> client can't walk and chew bubble gum at the same time, >>> That question makes no sense. Obviously the client does lots of things >>> at once and that complexity contributes a lot to these problems. >>> >> >> >From what Dzonatas said, I understood that the client somtimes might >> bite more than it can chew and allows for things to time out during >> login instead of doing things in the background at the same time it >> makes sure the server doesn't think the client is gone. >> > > Well, you can't have walking and chewing without some biting I guess. > :-) > > I like Dzonatas' solution to defer sorting until actually needed for > display, if ever. If you like it too, then please notice that his > solution adds more complexity in the form of the dirty flag. If that > flag ever gets out of sync, then the list won't appear sorted. > Although there was previously a performance issue, that type of > synchronization bug was at least not possible. Was the performance > savings worth the complexity? Maybe so but I'd really rather find a > solution with less risk. Like perhaps only sorting when the drop-down > is opened. My point is not on what is the best solution to this > problem but simply that sometimes it's worth suffering some extra code > complexity and the inevitable future bugs that complexity always > brings. Bugs such as this one that seems to make you so upset. What I > don't understand is what your point is in insulting the code. Lots of > the viewer code is beautiful and lots of it is messy and fragile, but > calling it all stupid is almost the same as calling the developers > dumb which is not what we need. > > -Melinda > The way I would do it would be to make sure the client is completly logged in, before trying to make any less important tasks, IMO there seems to be too many things being done during login that could just as well be done before and/or after login has been stabilished, and have the client always prioritize staying connected over other things, never the other way around, there is no point in doing anything else if you endup disconnected (unless of course if it is after the user has requested to be disconnected) Any insults to the code, if present at all, were only meant to emphasize my surprise/disappointment with the existence of apparent flaws and in some cases add a bit of comical relief, I never meant to offend anyone. I understand that organicly grown software systems tend to get somewhat messy, that is often an inherent feature of orgagnicly developed anything, take a look a the human body :P There are great things and ingenious hacks around non-great things, but there are a great number of people who would have major changes done from scratch instead of built over existing mistakes done, I'm talking about the human body, but it also applies to the SL client. But I am aware that with complex systems, specially organicly developed ones, minor changes often produce unexpected results in things that were expected to be independent, I do appreciate the work done with SL, it's the type of thing that would be expected to not work and yet it does (to some extent depending on who you ask), t is amazingly fragile and yet unexpectedly robust, in many aspects it's kinda like the Antonov 225, too big to fly, reconditioned old tech, and yet it achieves greatly. From melinda at superliminal.com Thu Jun 11 04:12:03 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 11 Jun 2009 04:12:03 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A30D32A.5060909@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> Message-ID: <4A30E683.2010904@superliminal.com> Tigro Spottystripes wrote: > Melinda Green escreveu: > >> Tigro Spottystripes wrote: >> >>> Melinda Green escreveu: >>> >>> >>>> Tigro Spottystripes wrote: >>>> >>>> >>>>> I believe I understood most of what you said. The client does many >>>>> analysis on the contents of the inventory each time any new info about >>>>> it comes, so with a big inventory there is lots to do each time, and >>>>> lots of times. But your explanation raised two questions IMO,why the >>>>> client can't walk and chew bubble gum at the same time, >>>>> >>>> That question makes no sense. Obviously the client does lots of things >>>> at once and that complexity contributes a lot to these problems. >>>> >>>> >>> >From what Dzonatas said, I understood that the client somtimes might >>> bite more than it can chew and allows for things to time out during >>> login instead of doing things in the background at the same time it >>> makes sure the server doesn't think the client is gone. >>> >>> >> Well, you can't have walking and chewing without some biting I guess. >> :-) >> >> I like Dzonatas' solution to defer sorting until actually needed for >> display, if ever. If you like it too, then please notice that his >> solution adds more complexity in the form of the dirty flag. If that >> flag ever gets out of sync, then the list won't appear sorted. >> Although there was previously a performance issue, that type of >> synchronization bug was at least not possible. Was the performance >> savings worth the complexity? Maybe so but I'd really rather find a >> solution with less risk. Like perhaps only sorting when the drop-down >> is opened. My point is not on what is the best solution to this >> problem but simply that sometimes it's worth suffering some extra code >> complexity and the inevitable future bugs that complexity always >> brings. Bugs such as this one that seems to make you so upset. What I >> don't understand is what your point is in insulting the code. Lots of >> the viewer code is beautiful and lots of it is messy and fragile, but >> calling it all stupid is almost the same as calling the developers >> dumb which is not what we need. >> >> -Melinda >> >> > > The way I would do it would be to make sure the client is completly > logged in, before trying to make any less important tasks, IMO there > seems to be too many things being done during login that could just as > well be done before and/or after login has been stabilished, and have > the client always prioritize staying connected over other things, never > the other way around, there is no point in doing anything else if you > endup disconnected (unless of course if it is after the user has > requested to be disconnected) > > Any insults to the code, if present at all, were only meant to emphasize > my surprise/disappointment with the existence of apparent flaws and in > some cases add a bit of comical relief, I never meant to offend anyone. > I understand that organicly grown software systems tend to get somewhat > messy, that is often an inherent feature of orgagnicly developed > anything, take a look a the human body :P > > There are great things and ingenious hacks around non-great things, but > there are a great number of people who would have major changes done > from scratch instead of built over existing mistakes done, I'm talking > about the human body, but it also applies to the SL client. > > But I am aware that with complex systems, specially organicly developed > ones, minor changes often produce unexpected results in things that were > expected to be independent, I do appreciate the work done with SL, it's > the type of thing that would be expected to not work and yet it does (to > some extent depending on who you ask), t is amazingly fragile and yet > unexpectedly robust, in many aspects it's kinda like the Antonov 225, > too big to fly, reconditioned old tech, and yet it achieves greatly. > Well, now that's the sort of analysis, suggestion, and tone that I think *is* helpful, thanks! Regarding work done on log-in, if we defer doing all those things that you call less important (to you, that is), then when the time comes to do all that work, if they happen all at once, then we're just going to delay the time before we suddenly grind down and get disconnected. That's assuming that all those things are atomic and independent, which they're not. Having spent a fair amount of time in that start-up code, I know too well what a delicate choreography it requires to make sure that each service is initialized before it's needed to initialize some other service. I spent the better part of a month simply turning about 50 global pointers into proper singletons for exactly that reason. The reason it took that long was because of circular interdependencies that needed to be untangled, and this was only one small part of the start-up process. So I agree that it's almost a miracle that it works at all. Taking your suggestion to it's logical extreme we would end up after enormous effort with services broken into clean modules that are packaged as shared libraries that get loaded the first moment they're accessed, if ever. I like that idea a lot but have to point out that it's not all upside. Aside from crashes that will happen when an attempt is made to load a module that didn't get packaged, or when the wrong version is loaded, users will then experience noticeable pauses the first time they access major components. Sure, log-in will be quick, but there will be a new kind of annoyance that happens when you go to do anything new. So there's value in initializing everything right up front and in a well-defined order, and there's value in initializing modules on demand, and none of the choices seem easy or obvious to me. -Melinda From tigrospottystripes at gmail.com Thu Jun 11 04:58:47 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 11 Jun 2009 08:58:47 -0300 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A30E683.2010904@superliminal.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> Message-ID: <4A30F177.8030204@Gmail.com> Melinda Green escreveu: > Tigro Spottystripes wrote: >> >> >> >> The way I would do it would be to make sure the client is completly >> logged in, before trying to make any less important tasks, IMO there >> seems to be too many things being done during login that could just as >> well be done before and/or after login has been stabilished, and have >> the client always prioritize staying connected over other things, never >> the other way around, there is no point in doing anything else if you >> endup disconnected (unless of course if it is after the user has >> requested to be disconnected) >> >> Any insults to the code, if present at all, were only meant to emphasize >> my surprise/disappointment with the existence of apparent flaws and in >> some cases add a bit of comical relief, I never meant to offend anyone. >> I understand that organicly grown software systems tend to get somewhat >> messy, that is often an inherent feature of orgagnicly developed >> anything, take a look a the human body :P >> >> There are great things and ingenious hacks around non-great things, but >> there are a great number of people who would have major changes done >> from scratch instead of built over existing mistakes done, I'm talking >> about the human body, but it also applies to the SL client. >> >> But I am aware that with complex systems, specially organicly developed >> ones, minor changes often produce unexpected results in things that were >> expected to be independent, I do appreciate the work done with SL, it's >> the type of thing that would be expected to not work and yet it does (to >> some extent depending on who you ask), t is amazingly fragile and yet >> unexpectedly robust, in many aspects it's kinda like the Antonov 225, >> too big to fly, reconditioned old tech, and yet it achieves greatly. >> > > Well, now that's the sort of analysis, suggestion, and tone that I > think *is* helpful, thanks! > > Regarding work done on log-in, if we defer doing all those things that > you call less important (to you, that is), then when the time comes > to do all that work, if they happen all at once, then we're just going > to delay the time before we suddenly grind down and get disconnected. > That's assuming that all those things are atomic and independent, > which they're not. Having spent a fair amount of time in that start-up > code, I know too well what a delicate choreography it requires to make > sure that each service is initialized before it's needed to initialize > some other service. I spent the better part of a month simply turning > about 50 global pointers into proper singletons for exactly that > reason. The reason it took that long was because of circular > interdependencies that needed to be untangled, and this was only one > small part of the start-up process. So I agree that it's almost a > miracle that it works at all. > > Taking your suggestion to it's logical extreme we would end up after > enormous effort with services broken into clean modules that are > packaged as shared libraries that get loaded the first moment they're > accessed, if ever. I like that idea a lot but have to point out that > it's not all upside. Aside from crashes that will happen when an > attempt is made to load a module that didn't get packaged, or when the > wrong version is loaded, users will then experience noticeable pauses > the first time they access major components. Sure, log-in will be > quick, but there will be a new kind of annoyance that happens when you > go to do anything new. So there's value in initializing everything > right up front and in a well-defined order, and there's value in > initializing modules on demand, and none of the choices seem easy or > obvious to me. > > -Melinda > is it not possible to prioritize different activities, like always making sure the most important things involved in keeping the client connected always have enough system resources to perform regardless of how much work other things have in mind? I imagine people wouldn't care much about inventory being sorted fast if they get disconnected, things with less priority might run slower, and everything that would cause issues if done without other things having finished first should check if the requirements have been met, and if they haven't, check if they are in the process of getitng done, if not, ask them to start. Doing it like that, nothing should cause disconnections due to timeouts, and regardless of the current state, things would make the right state be achieved. So if the machine is powerful enough, everything gets done before the progress bar reaches the end, and if the machine isn't powerful enough, things will simply load up while they are used, in many cases people are used to things loading gradually, like objects loading from close to far, sculpty and textures progressively getting more details, avatars deruthing property by property (at least that used to be the case before Ruth got hidden away and replaced with the cloud or in some cases simply nothing), I believe people would handle it well if there was active indication of progress, no big stops in progress bars, and no repetitive animation that doesn't differentiate beginning from middle from end of operation, and things like indications of different steps , like text explaining what exactly is being done, or simply icons, colors or changes in the gui that are easily recognizable as individual stages etc are present;. Things shouldn't freeze other things, gui should remain responsive, connection essential operations should continue being triggered in time, things being done simultaneously shouldn't hog avaiable resources all to themselves, they should share the resources, slowing down process depending on their priority, only things with very little priority should ever actually freeze to a halt for any noticeable amount of time, and there should never be doubt for the user about whether things are still working or have reached an irreversible unwelcome state (freeze, crash, or simply hav no idea what to do with the current condition/data and can't find it's way back to normal behavior etc). The user should always be given positive confirmation goals are being achieved, work is being done, that the client knows what it is doing and haven't forgot of the user. If some things already can be done while others are still being prepared, the user should be allowed to do them while not being left in the dark about the progress of what is not avaible yet. IMO, partial functionality, with information on what is missing and how long till is it avaiable is better than passively watching a progress bar, or having to wonder if the client will ever resume being responssive again. From nexiim at googlemail.com Thu Jun 11 05:12:40 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Thu, 11 Jun 2009 13:12:40 +0100 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> Message-ID: <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> Why not simply run inventory sorting in a different thread on the second core? Nearly everyone has at least Dual Core, despite my computer being ancient, I still have at least two cores, one being unused 99% of the time due to the client not being effectively architectured to accomodate multithreading. - Nexii Malthus Edit: Re-posting, I wish gmail supported mailing lists automatically. On Thu, Jun 11, 2009 at 1:10 PM, Nexii Malthus wrote: > Why not simply run inventory sorting in a different thread on the second > core? Nearly everyone has at least Dual Core, despite my computer being > ancient, I still have at least two cores, one being unused 99% of the time > due to the client not being effectively architectured to accomodate > multithreading. > > Nexii Malthus > > > On Thu, Jun 11, 2009 at 12:58 PM, Tigro Spottystripes < > tigrospottystripes at gmail.com> wrote: > >> Melinda Green escreveu: >> > Tigro Spottystripes wrote: >> >> >> >> >> >> >> >> The way I would do it would be to make sure the client is completly >> >> logged in, before trying to make any less important tasks, IMO there >> >> seems to be too many things being done during login that could just as >> >> well be done before and/or after login has been stabilished, and have >> >> the client always prioritize staying connected over other things, never >> >> the other way around, there is no point in doing anything else if you >> >> endup disconnected (unless of course if it is after the user has >> >> requested to be disconnected) >> >> >> >> Any insults to the code, if present at all, were only meant to >> emphasize >> >> my surprise/disappointment with the existence of apparent flaws and in >> >> some cases add a bit of comical relief, I never meant to offend anyone. >> >> I understand that organicly grown software systems tend to get somewhat >> >> messy, that is often an inherent feature of orgagnicly developed >> >> anything, take a look a the human body :P >> >> >> >> There are great things and ingenious hacks around non-great things, but >> >> there are a great number of people who would have major changes done >> >> from scratch instead of built over existing mistakes done, I'm talking >> >> about the human body, but it also applies to the SL client. >> >> >> >> But I am aware that with complex systems, specially organicly developed >> >> ones, minor changes often produce unexpected results in things that >> were >> >> expected to be independent, I do appreciate the work done with SL, it's >> >> the type of thing that would be expected to not work and yet it does >> (to >> >> some extent depending on who you ask), t is amazingly fragile and yet >> >> unexpectedly robust, in many aspects it's kinda like the Antonov 225, >> >> too big to fly, reconditioned old tech, and yet it achieves greatly. >> >> >> > >> > Well, now that's the sort of analysis, suggestion, and tone that I >> > think *is* helpful, thanks! >> > >> > Regarding work done on log-in, if we defer doing all those things that >> > you call less important (to you, that is), then when the time comes >> > to do all that work, if they happen all at once, then we're just going >> > to delay the time before we suddenly grind down and get disconnected. >> > That's assuming that all those things are atomic and independent, >> > which they're not. Having spent a fair amount of time in that start-up >> > code, I know too well what a delicate choreography it requires to make >> > sure that each service is initialized before it's needed to initialize >> > some other service. I spent the better part of a month simply turning >> > about 50 global pointers into proper singletons for exactly that >> > reason. The reason it took that long was because of circular >> > interdependencies that needed to be untangled, and this was only one >> > small part of the start-up process. So I agree that it's almost a >> > miracle that it works at all. >> > >> > Taking your suggestion to it's logical extreme we would end up after >> > enormous effort with services broken into clean modules that are >> > packaged as shared libraries that get loaded the first moment they're >> > accessed, if ever. I like that idea a lot but have to point out that >> > it's not all upside. Aside from crashes that will happen when an >> > attempt is made to load a module that didn't get packaged, or when the >> > wrong version is loaded, users will then experience noticeable pauses >> > the first time they access major components. Sure, log-in will be >> > quick, but there will be a new kind of annoyance that happens when you >> > go to do anything new. So there's value in initializing everything >> > right up front and in a well-defined order, and there's value in >> > initializing modules on demand, and none of the choices seem easy or >> > obvious to me. >> > >> > -Melinda >> > >> >> is it not possible to prioritize different activities, like always >> making sure the most important things involved in keeping the client >> connected always have enough system resources to perform regardless of >> how much work other things have in mind? I imagine people wouldn't care >> much about inventory being sorted fast if they get disconnected, things >> with less priority might run slower, and everything that would cause >> issues if done without other things having finished first should check >> if the requirements have been met, and if they haven't, check if they >> are in the process of getitng done, if not, ask them to start. Doing it >> like that, nothing should cause disconnections due to timeouts, and >> regardless of the current state, things would make the right state be >> achieved. So if the machine is powerful enough, everything gets done >> before the progress bar reaches the end, and if the machine isn't >> powerful enough, things will simply load up while they are used, in many >> cases people are used to things loading gradually, like objects loading >> from close to far, sculpty and textures progressively getting more >> details, avatars deruthing property by property (at least that used to >> be the case before Ruth got hidden away and replaced with the cloud or >> in some cases simply nothing), I believe people would handle it well if >> there was active indication of progress, no big stops in progress bars, >> and no repetitive animation that doesn't differentiate beginning from >> middle from end of operation, and things like indications of different >> steps , like text explaining what exactly is being done, or simply >> icons, colors or changes in the gui that are easily recognizable as >> individual stages etc are present;. Things shouldn't freeze other >> things, gui should remain responsive, connection essential operations >> should continue being triggered in time, things being done >> simultaneously shouldn't hog avaiable resources all to themselves, they >> should share the resources, slowing down process depending on their >> priority, only things with very little priority should ever actually >> freeze to a halt for any noticeable amount of time, and there should >> never be doubt for the user about whether things are still working or >> have reached an irreversible unwelcome state (freeze, crash, or simply >> hav no idea what to do with the current condition/data and can't find >> it's way back to normal behavior etc). The user should always be given >> positive confirmation goals are being achieved, work is being done, that >> the client knows what it is doing and haven't forgot of the user. If >> some things already can be done while others are still being prepared, >> the user should be allowed to do them while not being left in the dark >> about the progress of what is not avaible yet. >> >> >> IMO, partial functionality, with information on what is missing and how >> long till is it avaiable is better than passively watching a progress >> bar, or having to wonder if the client will ever resume being >> responssive again. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090611/92efd772/attachment-0001.htm From carlo at alinoe.com Thu Jun 11 05:31:25 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 11 Jun 2009 14:31:25 +0200 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption In-Reply-To: <4A30540A.8070704@gmail.com> References: <20090611013748.0ef1c326.sldev@free.fr> <4A30540A.8070704@gmail.com> Message-ID: <20090611123125.GA10688@alinoe.com> On Wed, Jun 10, 2009 at 05:47:06PM -0700, Dzonatas Sol wrote: > enough for productivity. Only my newer 64 bit system, I have e-mail, a few IDEs > left open, several sessions of iceweasel, music player,? compiz, about 15 > shells sessions, 8 virtual desktops, and quite often compiling the viewer over > and over... and I still remain productive. Yes, there are some freakin' obvious > gains with the amount of productivity that can be achieved with 64 bit systems. Me too(tm), but I think is more related to having for cores (and the fact that the viewer only uses one core effectively). The obvious advantage of running the viewer 64bit is that it can use the same shared libraries as everything else on my machine. If I was forced to run 32bit (I wouldn't, even) then I'd need to have a GB of shared libraries in RAM solely for the sake of the viewer alone. I'm not going to talk about advantages of processing things with 64bit instead of 32bit (although in some cases I've seen a factor of two speed increase) because the viewer is written so inefficient, it would be a lot easier to gain speed elsewhere. -- Carlo Wood From carlo at alinoe.com Thu Jun 11 05:37:38 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 11 Jun 2009 14:37:38 +0200 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> Message-ID: <20090611123738.GB10688@alinoe.com> On Wed, Jun 10, 2009 at 09:23:59PM -0500, Dale Mahalko wrote: > Saving a notecard makes a new one. The old data hangs around in the > asset server apparently forever, so if you have 16k of temporary data > and you change 1 byte of it and save the change, you're burning 16 kb > per write. Over time this could end up being gigabytes to terabytes of > wasted space in the asset system across thousands of program write > operations, and LL has to provide expensive RAID and do tape > archiving, etc etc of all that.. No comment ... -- Carlo Wood From chaosstar at gmail.com Thu Jun 11 05:38:27 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 11 Jun 2009 14:38:27 +0200 Subject: [sldev] Numbers on 32-bit vs 64-bit Linux deskop adoption In-Reply-To: <20090611123125.GA10688@alinoe.com> References: <20090611013748.0ef1c326.sldev@free.fr> <4A30540A.8070704@gmail.com> <20090611123125.GA10688@alinoe.com> Message-ID: <9bb32d430906110538g5b72500cwcc3a46b8fdbba6f9@mail.gmail.com> I'm not quite sure the viewer will ever effectively take advantage of 64bit systems. It's just not a piece of software that -can- take an effective advantage, unless exept maybe things like 64bit integers and such. Which actually also can be done in 32bit software, ironically, and I doubt the ram usage ever should go above what 32bit systems allow. However, I agree that the usage of 64bit systems depends usually on the general usage of the PC as a whole. I actually presume that in the Linux area, more and more 64bit systems will pop up. It's taking a long time, but slowly, very very slowly 32bit systems are fading out. Gotta say it, especially with the Windows 7 RC seeming flawlessy running in its 64bit version. Even with the 24.6% adoption on the Linux side in current statistics...that's one third, almost :> I would guess that's quite a good threshold to focus on a better supported 64bit Linux library set for the viewer on LL's side. On Thu, Jun 11, 2009 at 14:31, Carlo Wood wrote: > On Wed, Jun 10, 2009 at 05:47:06PM -0700, Dzonatas Sol wrote: >> enough for productivity. Only my newer 64 bit system, I have e-mail, a few IDEs >> left open, several sessions of iceweasel, music player,? compiz, about 15 >> shells sessions, 8 virtual desktops, and quite often compiling the viewer over >> and over... and I still remain productive. Yes, there are some freakin' obvious >> gains with the amount of productivity that can be achieved with 64 bit systems. > > Me too(tm), but I think is more related to having for cores (and the fact that > the viewer only uses one core effectively). > > The obvious advantage of running the viewer 64bit is that it can use the > same shared libraries as everything else on my machine. If I was forced to > run 32bit (I wouldn't, even) then I'd need to have a GB of shared libraries > in RAM solely for the sake of the viewer alone. > > I'm not going to talk about advantages of processing things with 64bit > instead of 32bit (although in some cases I've seen a factor of two speed > increase) because the viewer is written so inefficient, it would be a > lot easier to gain speed elsewhere. > > -- > Carlo Wood > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From lists.secondlife.com at trap.wereanimal.net Thu Jun 11 08:04:03 2009 From: lists.secondlife.com at trap.wereanimal.net (Techwolf Lupindo) Date: Thu, 11 Jun 2009 11:04:03 -0400 Subject: [sldev] Some early automation tests results. Message-ID: <200906111104.03650.lists.secondlife.com@trap.wereanimal.net> Last week Open Source meeting, there was a call put out to make some automated client side test to measure lag and so on. I pick up the challenge and it was a LOT tougher then I though with all the limitations and shortcomings of SL. BUT, I managed to get a repeatable test that can be use across different versions of the SL client, including snowglobe. Here is some early results of that effort. Right now, it is just a simple walk around a sim I found on the beta grid. Each run 1 was started with a rm -fr ~/.secondlife and run 2 was the same client started with previous run .secondlife cache intact. -------------------------------------------------------------- Second Life 1.23.3 (122255) Jun 4 2009 15:43:30 (Second Life Release Candidate) Release Notes Built with GCC version 40303 You are at 219201.0, 296768.7, 38.0 in SkyBeam located at sim3004.aditi.lindenlab.com (216.82.49.230:13002) Second Life Beta Server 1.27.0.122984 Release Notes CPU: AMD Phenom(tm) 9950 Quad-Core Processor Memory: 8008 MB OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue Jun 2 00:59:07 EDT 2009 x86_64 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 260/PCI/SSE2 OpenGL Version: 3.0.0 NVIDIA 180.60 libcurl Version: libcurl/7.19.4 OpenSSL/0.9.8k zlib/1.2.3 libidn/1.15 J2C Decoder Version: OpenJPEG: 1.3.0, Runtime: 1.3.0 Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.7.411 / OpenAL Community / OpenAL Soft: ALSA Software LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24566 (Mozilla GRE version 1.8.1.21_0000000000) Packets Lost: 0/665 (0.0%) Run 1 2009-06-11T12:42:04Z INFO: display_stats: FPS: 0.10 2009-06-11T12:42:13Z INFO: display_stats: FPS: 78.00 2009-06-11T12:42:23Z INFO: display_stats: FPS: 67.00 2009-06-11T12:42:33Z INFO: display_stats: FPS: 59.20 2009-06-11T12:42:43Z INFO: display_stats: FPS: 54.20 2009-06-11T12:42:53Z INFO: display_stats: FPS: 54.30 2009-06-11T12:43:03Z INFO: display_stats: FPS: 57.30 2009-06-11T12:43:13Z INFO: display_stats: FPS: 62.60 2009-06-11T12:43:23Z INFO: display_stats: FPS: 70.30 2009-06-11T12:43:33Z INFO: display_stats: FPS: 64.70 2009-06-11T12:43:44Z INFO: display_stats: FPS: 62.60 2009-06-11T12:43:54Z INFO: display_stats: FPS: 65.30 2009-06-11T12:44:04Z INFO: display_stats: FPS: 70.70 2009-06-11T12:44:14Z INFO: display_stats: FPS: 72.00 2009-06-11T12:44:24Z INFO: display_stats: FPS: 67.50 2009-06-11T12:44:34Z INFO: display_stats: FPS: 64.70 2009-06-11T12:44:44Z INFO: display_stats: FPS: 61.00 2009-06-11T12:44:54Z INFO: display_stats: FPS: 60.60 2009-06-11T12:45:04Z INFO: display_stats: FPS: 61.00 2009-06-11T12:45:14Z INFO: display_stats: FPS: 63.60 2009-06-11T12:45:24Z INFO: display_stats: FPS: 68.30 2009-06-11T12:45:34Z INFO: display_stats: FPS: 64.80 2009-06-11T12:45:44Z INFO: display_stats: FPS: 59.60 2009-06-11T12:45:54Z INFO: display_stats: FPS: 54.60 2009-06-11T12:46:04Z INFO: display_stats: FPS: 48.30 2009-06-11T12:46:14Z INFO: display_stats: FPS: 50.90 Run 2 2009-06-11T12:49:54Z INFO: display_stats: FPS: 0.10 2009-06-11T12:50:04Z INFO: display_stats: FPS: 74.40 2009-06-11T12:50:14Z INFO: display_stats: FPS: 67.00 2009-06-11T12:50:24Z INFO: display_stats: FPS: 62.10 2009-06-11T12:50:34Z INFO: display_stats: FPS: 59.00 2009-06-11T12:50:44Z INFO: display_stats: FPS: 59.90 2009-06-11T12:50:54Z INFO: display_stats: FPS: 62.70 2009-06-11T12:51:04Z INFO: display_stats: FPS: 70.90 2009-06-11T12:51:14Z INFO: display_stats: FPS: 73.50 2009-06-11T12:51:24Z INFO: display_stats: FPS: 64.00 2009-06-11T12:51:34Z INFO: display_stats: FPS: 65.90 2009-06-11T12:51:44Z INFO: display_stats: FPS: 72.50 2009-06-11T12:51:54Z INFO: display_stats: FPS: 69.10 2009-06-11T12:52:04Z INFO: display_stats: FPS: 70.80 2009-06-11T12:52:14Z INFO: display_stats: FPS: 71.40 2009-06-11T12:52:24Z INFO: display_stats: FPS: 64.70 2009-06-11T12:52:34Z INFO: display_stats: FPS: 64.90 2009-06-11T12:52:44Z INFO: display_stats: FPS: 65.70 2009-06-11T12:52:54Z INFO: display_stats: FPS: 58.20 2009-06-11T12:53:04Z INFO: display_stats: FPS: 65.30 2009-06-11T12:53:14Z INFO: display_stats: FPS: 65.10 2009-06-11T12:53:24Z INFO: display_stats: FPS: 63.40 2009-06-11T12:53:34Z INFO: display_stats: FPS: 59.40 2009-06-11T12:53:44Z INFO: display_stats: FPS: 52.00 2009-06-11T12:53:54Z INFO: display_stats: FPS: 48.30 2009-06-11T12:54:04Z INFO: display_stats: FPS: 47.30 --------------------------------------------------------------------------- 1.22.11 (with ctrl-c bug, unable to copy about help) Run 1 2009-06-11T12:57:47Z INFO: display_stats: FPS: 44.48 2009-06-11T12:58:47Z INFO: display_stats: FPS: 58.90 2009-06-11T12:59:47Z INFO: display_stats: FPS: 60.25 2009-06-11T13:00:47Z INFO: display_stats: FPS: 61.30 Run 2 2009-06-11T13:03:41Z INFO: display_stats: FPS: 44.38 2009-06-11T13:04:41Z INFO: display_stats: FPS: 59.08 2009-06-11T13:05:41Z INFO: display_stats: FPS: 64.47 2009-06-11T13:06:41Z INFO: display_stats: FPS: 57.98 --------------------------------------------------------------------------- Snowglobe 1.23.2 (121930) Jun 7 2009 14:56:10 (CommunityDeveloper) Release Notes Built with GCC version 40303 You are at 219201.0, 296768.7, 38.0 in SkyBeam located at sim3004.aditi.lindenlab.com (216.82.49.230:13002) Second Life Beta Server 1.27.0.122984 Release Notes CPU: AMD Phenom(tm) 9950 Quad-Core Processor Memory: 8008 MB OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue Jun 2 00:59:07 EDT 2009 x86_64 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 260/PCI/SSE2 OpenGL Version: 3.0.0 NVIDIA 180.60 libcurl Version: libcurl/7.19.4 OpenSSL/0.9.8k zlib/1.2.3 libidn/1.15 J2C Decoder Version: OpenJPEG: 1.3.0, Runtime: 1.3.0 Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.7.411 / OpenAL Community / OpenAL Soft: ALSA Software LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24567 (Mozilla GRE version 1.8.1.21_0000000000) Run 1 2009-06-11T13:20:40Z INFO: display_stats: FPS: 0.10 2009-06-11T13:20:50Z INFO: display_stats: FPS: 72.50 2009-06-11T13:21:00Z INFO: display_stats: FPS: 72.50 2009-06-11T13:21:10Z INFO: display_stats: FPS: 66.60 2009-06-11T13:21:20Z INFO: display_stats: FPS: 63.80 2009-06-11T13:21:30Z INFO: display_stats: FPS: 61.40 2009-06-11T13:21:40Z INFO: display_stats: FPS: 64.10 2009-06-11T13:21:50Z INFO: display_stats: FPS: 68.30 2009-06-11T13:22:00Z INFO: display_stats: FPS: 69.20 2009-06-11T13:22:10Z INFO: display_stats: FPS: 69.30 2009-06-11T13:22:20Z INFO: display_stats: FPS: 64.70 2009-06-11T13:22:30Z INFO: display_stats: FPS: 68.80 2009-06-11T13:22:40Z INFO: display_stats: FPS: 76.80 2009-06-11T13:22:50Z INFO: display_stats: FPS: 87.30 2009-06-11T13:23:00Z INFO: display_stats: FPS: 87.40 2009-06-11T13:23:10Z INFO: display_stats: FPS: 70.30 2009-06-11T13:23:20Z INFO: display_stats: FPS: 65.30 2009-06-11T13:23:30Z INFO: display_stats: FPS: 66.70 2009-06-11T13:23:40Z INFO: display_stats: FPS: 66.70 2009-06-11T13:23:50Z INFO: display_stats: FPS: 66.40 2009-06-11T13:24:00Z INFO: display_stats: FPS: 100.60 2009-06-11T13:24:10Z INFO: display_stats: FPS: 71.90 2009-06-11T13:24:20Z INFO: display_stats: FPS: 65.30 2009-06-11T13:24:30Z INFO: display_stats: FPS: 59.80 2009-06-11T13:24:40Z INFO: display_stats: FPS: 55.70 Run 2 2009-06-11T13:26:29Z INFO: display_stats: FPS: 0.10 2009-06-11T13:26:38Z INFO: display_stats: FPS: 71.30 2009-06-11T13:26:48Z INFO: display_stats: FPS: 68.80 2009-06-11T13:26:58Z INFO: display_stats: FPS: 60.50 2009-06-11T13:27:08Z INFO: display_stats: FPS: 66.50 2009-06-11T13:27:18Z INFO: display_stats: FPS: 63.60 2009-06-11T13:27:28Z INFO: display_stats: FPS: 71.70 2009-06-11T13:27:38Z INFO: display_stats: FPS: 88.30 2009-06-11T13:27:48Z INFO: display_stats: FPS: 89.20 2009-06-11T13:27:58Z INFO: display_stats: FPS: 92.30 2009-06-11T13:28:08Z INFO: display_stats: FPS: 67.50 2009-06-11T13:28:18Z INFO: display_stats: FPS: 69.80 2009-06-11T13:28:28Z INFO: display_stats: FPS: 94.90 2009-06-11T13:28:38Z INFO: display_stats: FPS: 109.20 2009-06-11T13:28:48Z INFO: display_stats: FPS: 83.30 2009-06-11T13:28:58Z INFO: display_stats: FPS: 69.00 2009-06-11T13:29:08Z INFO: display_stats: FPS: 64.80 2009-06-11T13:29:18Z INFO: display_stats: FPS: 62.20 2009-06-11T13:29:29Z INFO: display_stats: FPS: 61.90 2009-06-11T13:29:39Z INFO: display_stats: FPS: 70.90 2009-06-11T13:29:49Z INFO: display_stats: FPS: 124.40 2009-06-11T13:29:59Z INFO: display_stats: FPS: 117.10 2009-06-11T13:30:09Z INFO: display_stats: FPS: 106.40 2009-06-11T13:30:19Z INFO: display_stats: FPS: 85.60 2009-06-11T13:30:29Z INFO: display_stats: FPS: 73.90 -------------------------------------------------------------------------- 1.22.11 LL bianary Run 1 2009-06-11T13:39:23Z INFO: display_stats: FPS: 47.98 2009-06-11T13:40:23Z INFO: display_stats: FPS: 58.83 2009-06-11T13:41:23Z INFO: display_stats: FPS: 61.90 2009-06-11T13:42:23Z INFO: display_stats: FPS: 60.53 Run 2 2009-06-11T13:44:24Z INFO: display_stats: FPS: 43.88 2009-06-11T13:45:24Z INFO: display_stats: FPS: 59.22 2009-06-11T13:46:24Z INFO: display_stats: FPS: 80.30 2009-06-11T13:47:24Z INFO: display_stats: FPS: 61.57 ---------------------------------------------------------------------------- Second Life 1.23.3 (122255) May 30 2009 13:26:56 (Second Life Release Candidate) Release Notes Built with GCC version 40102 You are at 219201.0, 296768.7, 38.0 in SkyBeam located at sim3004.aditi.lindenlab.com (216.82.49.230:13002) Second Life Beta Server 1.27.0.122984 Release Notes CPU: AMD Phenom(tm) 9950 Quad-Core Processor Memory: 8008 MB OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue Jun 2 00:59:07 EDT 2009 x86_64 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 260/PCI/SSE2 OpenGL Version: 3.0.0 NVIDIA 180.60 libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0 J2C Decoder Version: KDU Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: ALSA Software on default LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24568 (Mozilla GRE version 1.8.1.18_0000000000) Run 1 2009-06-11T13:54:41Z INFO: display_stats: FPS: 0.10 2009-06-11T13:54:51Z INFO: display_stats: FPS: 68.80 2009-06-11T13:55:01Z INFO: display_stats: FPS: 66.40 2009-06-11T13:55:11Z INFO: display_stats: FPS: 63.70 2009-06-11T13:55:21Z INFO: display_stats: FPS: 62.50 2009-06-11T13:55:31Z INFO: display_stats: FPS: 58.40 2009-06-11T13:55:41Z INFO: display_stats: FPS: 63.60 2009-06-11T13:55:51Z INFO: display_stats: FPS: 68.00 2009-06-11T13:56:01Z INFO: display_stats: FPS: 73.10 2009-06-11T13:56:11Z INFO: display_stats: FPS: 67.60 2009-06-11T13:56:21Z INFO: display_stats: FPS: 65.40 2009-06-11T13:56:31Z INFO: display_stats: FPS: 69.40 2009-06-11T13:56:41Z INFO: display_stats: FPS: 74.10 2009-06-11T13:56:51Z INFO: display_stats: FPS: 73.40 2009-06-11T13:57:01Z INFO: display_stats: FPS: 70.50 2009-06-11T13:57:11Z INFO: display_stats: FPS: 67.30 2009-06-11T13:57:21Z INFO: display_stats: FPS: 64.30 2009-06-11T13:57:31Z INFO: display_stats: FPS: 63.60 2009-06-11T13:57:41Z INFO: display_stats: FPS: 64.70 2009-06-11T13:57:51Z INFO: display_stats: FPS: 64.10 2009-06-11T13:58:01Z INFO: display_stats: FPS: 69.10 2009-06-11T13:58:11Z INFO: display_stats: FPS: 67.30 2009-06-11T13:58:21Z INFO: display_stats: FPS: 62.10 2009-06-11T13:58:31Z INFO: display_stats: FPS: 54.60 2009-06-11T13:58:41Z INFO: display_stats: FPS: 53.50 Run 2 2009-06-11T13:59:39Z INFO: display_stats: FPS: 0.10 2009-06-11T13:59:49Z INFO: display_stats: FPS: 68.80 2009-06-11T13:59:59Z INFO: display_stats: FPS: 65.80 2009-06-11T14:00:09Z INFO: display_stats: FPS: 57.80 2009-06-11T14:00:19Z INFO: display_stats: FPS: 55.70 2009-06-11T14:00:29Z INFO: display_stats: FPS: 57.60 2009-06-11T14:00:39Z INFO: display_stats: FPS: 59.80 2009-06-11T14:00:49Z INFO: display_stats: FPS: 65.70 2009-06-11T14:00:59Z INFO: display_stats: FPS: 68.60 2009-06-11T14:01:09Z INFO: display_stats: FPS: 65.60 2009-06-11T14:01:19Z INFO: display_stats: FPS: 62.20 2009-06-11T14:01:29Z INFO: display_stats: FPS: 65.10 2009-06-11T14:01:39Z INFO: display_stats: FPS: 74.90 2009-06-11T14:01:49Z INFO: display_stats: FPS: 105.40 2009-06-11T14:01:59Z INFO: display_stats: FPS: 91.50 2009-06-11T14:02:09Z INFO: display_stats: FPS: 81.30 2009-06-11T14:02:19Z INFO: display_stats: FPS: 62.30 2009-06-11T14:02:29Z INFO: display_stats: FPS: 61.40 2009-06-11T14:02:39Z INFO: display_stats: FPS: 61.90 2009-06-11T14:02:49Z INFO: display_stats: FPS: 61.60 2009-06-11T14:02:59Z INFO: display_stats: FPS: 67.70 2009-06-11T14:03:09Z INFO: display_stats: FPS: 65.10 2009-06-11T14:03:19Z INFO: display_stats: FPS: 62.70 2009-06-11T14:03:29Z INFO: display_stats: FPS: 56.10 2009-06-11T14:03:39Z INFO: display_stats: FPS: 53.10 ---------------------------------------------------------------------------- Snowglobe 0.9.0 (2381) Jun 10 2009 15:33:48 (Snowglobe Test Build) Release Notes Built with GCC version 40102 You are at 219201.0, 296768.7, 38.0 in SkyBeam located at sim3004.aditi.lindenlab.com (216.82.49.230:13002) Second Life Beta Server 1.27.0.122984 Release Notes CPU: AMD Phenom(tm) 9950 Quad-Core Processor Memory: 8008 MB OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue Jun 2 00:59:07 EDT 2009 x86_64 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 260/PCI/SSE2 OpenGL Version: 3.0.0 NVIDIA 180.60 libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0 J2C Decoder Version: KDU Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: ALSA Software on default LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24568 (Mozilla GRE version 1.8.1.18_0000000000) Run 1 2009-06-11T14:10:47Z INFO: display_stats: FPS: 0.10 2009-06-11T14:10:57Z INFO: display_stats: FPS: 75.20 2009-06-11T14:11:07Z INFO: display_stats: FPS: 76.30 2009-06-11T14:11:17Z INFO: display_stats: FPS: 68.80 2009-06-11T14:11:27Z INFO: display_stats: FPS: 65.40 2009-06-11T14:11:37Z INFO: display_stats: FPS: 66.00 2009-06-11T14:11:47Z INFO: display_stats: FPS: 64.50 2009-06-11T14:11:57Z INFO: display_stats: FPS: 67.10 2009-06-11T14:12:07Z INFO: display_stats: FPS: 71.90 2009-06-11T14:12:17Z INFO: display_stats: FPS: 69.10 2009-06-11T14:12:27Z INFO: display_stats: FPS: 66.00 2009-06-11T14:12:37Z INFO: display_stats: FPS: 70.20 2009-06-11T14:12:47Z INFO: display_stats: FPS: 79.20 2009-06-11T14:12:57Z INFO: display_stats: FPS: 83.10 2009-06-11T14:13:07Z INFO: display_stats: FPS: 73.20 2009-06-11T14:13:17Z INFO: display_stats: FPS: 71.30 2009-06-11T14:13:27Z INFO: display_stats: FPS: 76.00 2009-06-11T14:13:37Z INFO: display_stats: FPS: 68.40 2009-06-11T14:13:48Z INFO: display_stats: FPS: 68.70 2009-06-11T14:13:58Z INFO: display_stats: FPS: 68.40 2009-06-11T14:14:08Z INFO: display_stats: FPS: 79.10 2009-06-11T14:14:18Z INFO: display_stats: FPS: 68.10 2009-06-11T14:14:28Z INFO: display_stats: FPS: 66.40 2009-06-11T14:14:38Z INFO: display_stats: FPS: 56.80 2009-06-11T14:14:48Z INFO: display_stats: FPS: 55.50 Run 2 2009-06-11T14:15:46Z INFO: display_stats: FPS: 0.10 2009-06-11T14:15:56Z INFO: display_stats: FPS: 79.60 2009-06-11T14:16:06Z INFO: display_stats: FPS: 76.30 2009-06-11T14:16:16Z INFO: display_stats: FPS: 63.20 2009-06-11T14:16:26Z INFO: display_stats: FPS: 75.90 2009-06-11T14:16:36Z INFO: display_stats: FPS: 79.10 2009-06-11T14:16:46Z INFO: display_stats: FPS: 79.10 2009-06-11T14:16:56Z INFO: display_stats: FPS: 105.60 2009-06-11T14:17:06Z INFO: display_stats: FPS: 104.60 2009-06-11T14:17:16Z INFO: display_stats: FPS: 91.30 2009-06-11T14:17:26Z INFO: display_stats: FPS: 84.90 2009-06-11T14:17:36Z INFO: display_stats: FPS: 81.20 2009-06-11T14:17:46Z INFO: display_stats: FPS: 103.00 2009-06-11T14:17:56Z INFO: display_stats: FPS: 106.00 2009-06-11T14:18:06Z INFO: display_stats: FPS: 102.90 2009-06-11T14:18:16Z INFO: display_stats: FPS: 92.80 2009-06-11T14:18:26Z INFO: display_stats: FPS: 73.40 2009-06-11T14:18:36Z INFO: display_stats: FPS: 62.90 2009-06-11T14:18:46Z INFO: display_stats: FPS: 65.60 2009-06-11T14:18:56Z INFO: display_stats: FPS: 87.40 2009-06-11T14:19:06Z INFO: display_stats: FPS: 110.60 2009-06-11T14:19:16Z INFO: display_stats: FPS: 83.90 2009-06-11T14:19:26Z INFO: display_stats: FPS: 71.30 2009-06-11T14:19:36Z INFO: display_stats: FPS: 60.20 2009-06-11T14:19:46Z INFO: display_stats: FPS: 59.70 --Techwolf Lupindo From dzonatas at gmail.com Thu Jun 11 09:28:30 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 11 Jun 2009 09:28:30 -0700 Subject: [sldev] (Gesture tracker hint) Re: Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A30CD4F.4050807@superliminal.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> Message-ID: <4A3130AE.9080703@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090611/92dcd1eb/attachment-0001.htm From kelly at lindenlab.com Thu Jun 11 09:16:20 2009 From: kelly at lindenlab.com (Kelly) Date: Thu, 11 Jun 2009 09:16:20 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A30911B.9050908@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> Message-ID: <4A312DD4.9010308@lindenlab.com> Tigro Spottystripes wrote: > kelly at lindenlab.com escreveu: > >> MAGIC! >> >> I don't know the exact details about how the current version works so >> *please* don't respond to my answer with the million ways it could be >> optimized or what it will miss etc. A lot of effort and revisions have >> gone into this. This is extremely roughly what it does, or did at one >> point and covers the gist of how GC on assets might work. >> >> * Step 1: Scan the contents of every asset, every simstate and every >> residents inventory for anything that looks vaguely like a UUID and build >> a list of those UUIDs. This means the text of every script, the contents >> of every notecard, the inventory of every item. >> * Step 2: Delete anything not in that list, but created before the scan >> started. >> * Step 3: Go to step 1. >> >> That is an extremely simplified version of course, and it gets more >> complicated as you work to make it more robust (find all those ids), safer >> (don't delete straight away) and faster. >> >> - Kelly >> >> >> > Interesting, much more comprehensive than I expected, but can you > explain me why the client doesn't got such a thorough capability of > reading the inventory? (the total item count for my inv varies from > about 9k to 30k+ depending on my luck, regardless of how many items I > add or delete) Or does the check randomly misses things in the inventory > like the client do? > I think this has been covered by others but just in case. The GC process is running behind our firewall and has direct access to the asset system and the inventory databases. Viewer inventory goes through the login server (for the base skeleton), the simulator, the dataserver to the database and back - through the dataserver, the simulator and finally to your viewer. There are a lot of potential places for bugs. The code for managing inventory and for viewing inventory are both far more complicated than a scan of all UUIDs in the table. And thats before anyone even mentions the word "permissions" which the GC can happily ignore. For example one bug we have had in the past could cause items in inventory to become orphaned - to lose their parent folder. This would cause the object to not appear in inventory but have no effect on the GC's abillity to find the related UUIDs for the item. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090611/1b867849/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090611/1b867849/attachment.pgp From robla at lindenlab.com Thu Jun 11 11:54:09 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 11 Jun 2009 11:54:09 -0700 Subject: [sldev] Snowglobe status Message-ID: <4A3152D1.7020604@lindenlab.com> Hi folks, Here's the latest status on Snowglobe. We'd really like to be able to release this thing next week (shooting for Thursday, June 18). Merov is currently chasing down the curl crashers (SNOW-2), and I'm doing some of the branding work (SNOW-17). Merov: http://jira.secondlife.com/browse/SNOW-2 Rob: http://jira.secondlife.com/browse/SNOW-17 Anecdotal evidence is suggesting that SNOW-8 is a particularly bad problem, and one that may constitute a blocker for release. Alexa (who has also seen this) is working out a solid repro case for this: http://jira.secondlife.com/browse/SNOW-8 There was an internal patch that we thought might address this, but based on Thickbrick and Robin's attempts, either it doesn't fix the problem, or they are missing the necessary context to adapt the patch correctly. Anyway, that's where we stand. Thanks everyone for your efforts so far on SNOW-8. We're not done yet, so any further help here would be *greatly* appreciated. Thanks! Rob From brad.king at kitware.com Thu Jun 11 13:24:25 2009 From: brad.king at kitware.com (Brad King) Date: Thu, 11 Jun 2009 16:24:25 -0400 Subject: [sldev] Code review request: branding patch SNOW-17 for Linux In-Reply-To: <4A30099D.6090801@lindenlab.com> References: <4A30099D.6090801@lindenlab.com> Message-ID: <4A3167F9.2040005@kitware.com> Rob Lanphier wrote: > Hi folks, > > More branding work. SNOW-17 has three patches, only one of which is > ready for prime time. See: > https://jira.secondlife.com/secure/ManageAttachments.jspa?id=34683 > > This has a couple of common changes plus the Linux-specific portion. > It's not the perfect abstraction for branding, but it's a baby step in > that direction. > > I'll check it in when I get a thumbs up from a committer. The commit: http://svn.secondlife.com/trac/linden/changeset/2381/projects/2009/http-texture includes this hunk: @@ -697,7 +720,7 @@ class Linux_i686Manifest(LinuxManifest): class Linux_x86_64Manifest(LinuxManifest): def construct(self): super(Linux_x86_64Manifest, self).construct() - self.path("secondlife-stripped","bin/do-not-directly-run-secondlife-bin") + self.path("secondlife-stripped",self.get_linuxbin()) self.path("../linux_crash_logger/linux-crash-logger-stripped","linux-crash-logger.bin") self.path("linux_tools/launch_url.sh","launch_url.sh") if self.prefix("res-sdl"): However, get_linuxbin() is not defined anywhere I can see. It leads to the error below. -Brad Traceback (most recent call last): File "/.../linden/indra/newview/viewer_manifest.py", line 735, in main() File "/.../linden/indra/newview/../lib/python/indra/util/llmanifest.py", line 236, in main wm.do(*args['actions']) File "/.../linden/indra/newview/../lib/python/indra/util/llmanifest.py", line 650, in do self.construct() File "/.../linden/indra/newview/viewer_manifest.py", line 723, in construct self.path("secondlife-stripped",self.get_linuxbin()) AttributeError: 'Linux_x86_64Manifest' object has no attribute 'get_linuxbin' make[2]: *** [newview/Snowglobe-x86_64-0.9.0.2369.tar.bz2] Error 1 From melinda at superliminal.com Thu Jun 11 13:43:58 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 11 Jun 2009 13:43:58 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A30F177.8030204@Gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <1293.75.33.197.92.1244689179.squirrel@mail.lindenlab.com> <4A3082BF.8090803@Gmail.com> <3263.75.33.197.92.1244696013.squirrel@mail.lindenlab.com> <4A30911B.9050908@Gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> Message-ID: <4A316C8E.8030807@superliminal.com> Tigro Spottystripes wrote: > Melinda Green escreveu: > >> Tigro Spottystripes wrote: >> >>> >>> >>> The way I would do it would be to make sure the client is completly >>> logged in, before trying to make any less important tasks, IMO there >>> seems to be too many things being done during login that could just as >>> well be done before and/or after login has been stabilished, and have >>> the client always prioritize staying connected over other things, never >>> the other way around, there is no point in doing anything else if you >>> endup disconnected (unless of course if it is after the user has >>> requested to be disconnected) >>> >>> Any insults to the code, if present at all, were only meant to emphasize >>> my surprise/disappointment with the existence of apparent flaws and in >>> some cases add a bit of comical relief, I never meant to offend anyone. >>> I understand that organicly grown software systems tend to get somewhat >>> messy, that is often an inherent feature of orgagnicly developed >>> anything, take a look a the human body :P >>> >>> There are great things and ingenious hacks around non-great things, but >>> there are a great number of people who would have major changes done >>> from scratch instead of built over existing mistakes done, I'm talking >>> about the human body, but it also applies to the SL client. >>> >>> But I am aware that with complex systems, specially organicly developed >>> ones, minor changes often produce unexpected results in things that were >>> expected to be independent, I do appreciate the work done with SL, it's >>> the type of thing that would be expected to not work and yet it does (to >>> some extent depending on who you ask), t is amazingly fragile and yet >>> unexpectedly robust, in many aspects it's kinda like the Antonov 225, >>> too big to fly, reconditioned old tech, and yet it achieves greatly. >>> >>> >> Well, now that's the sort of analysis, suggestion, and tone that I >> think *is* helpful, thanks! >> >> Regarding work done on log-in, if we defer doing all those things that >> you call less important (to you, that is), then when the time comes >> to do all that work, if they happen all at once, then we're just going >> to delay the time before we suddenly grind down and get disconnected. >> That's assuming that all those things are atomic and independent, >> which they're not. Having spent a fair amount of time in that start-up >> code, I know too well what a delicate choreography it requires to make >> sure that each service is initialized before it's needed to initialize >> some other service. I spent the better part of a month simply turning >> about 50 global pointers into proper singletons for exactly that >> reason. The reason it took that long was because of circular >> interdependencies that needed to be untangled, and this was only one >> small part of the start-up process. So I agree that it's almost a >> miracle that it works at all. >> >> Taking your suggestion to it's logical extreme we would end up after >> enormous effort with services broken into clean modules that are >> packaged as shared libraries that get loaded the first moment they're >> accessed, if ever. I like that idea a lot but have to point out that >> it's not all upside. Aside from crashes that will happen when an >> attempt is made to load a module that didn't get packaged, or when the >> wrong version is loaded, users will then experience noticeable pauses >> the first time they access major components. Sure, log-in will be >> quick, but there will be a new kind of annoyance that happens when you >> go to do anything new. So there's value in initializing everything >> right up front and in a well-defined order, and there's value in >> initializing modules on demand, and none of the choices seem easy or >> obvious to me. >> >> -Melinda >> >> > > is it not possible to prioritize different activities, like always > making sure the most important things involved in keeping the client > connected always have enough system resources to perform regardless of > how much work other things have in mind? Not really. I mean you might be able to prioritize the value of particular services, but there are so many interconnected dependencies that you'll often need to initialize what appears to be a low-priority service earlier than you'd think because it's depended upon by some higher priority service. Regarding resources (CPU cycles in this case), even if you wait for a quiet moment to initialize low priority services, there's no guarantee that it will stay quiet. You can't predict when a bunch of people are going to TP into your region for example. > I imagine people wouldn't care > much about inventory being sorted fast if they get disconnected, No, but they'll complain about incorrectly sorted inventory when they don't. ;-) > things > with less priority might run slower, and everything that would cause > issues if done without other things having finished first should check > if the requirements have been met, and if they haven't, check if they > are in the process of getitng done, if not, ask them to start. Doing it > like that, nothing should cause disconnections due to timeouts, and > regardless of the current state, things would make the right state be > achieved. So if the machine is powerful enough, everything gets done > before the progress bar reaches the end, and if the machine isn't > powerful enough, things will simply load up while they are used, in many > cases people are used to things loading gradually, like objects loading > from close to far, sculpty and textures progressively getting more > details, avatars deruthing property by property (at least that used to > be the case before Ruth got hidden away and replaced with the cloud or > in some cases simply nothing), I believe people would handle it well if > there was active indication of progress, no big stops in progress bars, > and no repetitive animation that doesn't differentiate beginning from > middle from end of operation, and things like indications of different > steps , like text explaining what exactly is being done, or simply > icons, colors or changes in the gui that are easily recognizable as > individual stages etc are present;. Things shouldn't freeze other > things, gui should remain responsive, connection essential operations > should continue being triggered in time, things being done > simultaneously shouldn't hog avaiable resources all to themselves, they > should share the resources, slowing down process depending on their > priority, only things with very little priority should ever actually > freeze to a halt for any noticeable amount of time, and there should > never be doubt for the user about whether things are still working or > have reached an irreversible unwelcome state (freeze, crash, or simply > hav no idea what to do with the current condition/data and can't find > it's way back to normal behavior etc). The user should always be given > positive confirmation goals are being achieved, work is being done, that > the client knows what it is doing and haven't forgot of the user. If > some things already can be done while others are still being prepared, > the user should be allowed to do them while not being left in the dark > about the progress of what is not avaible yet. > > > IMO, partial functionality, with information on what is missing and how > long till is it avaiable is better than passively watching a progress > bar, or having to wonder if the client will ever resume being > responssive again. > You just used the word "should" 11 times, and for the most part I agree that the code will ideally do all of those things, and in ways that don't confuse, irritate or overwhelm the user. There are ways of approaching all of the things you mention but none of them are easy. -Melinda From melinda at superliminal.com Thu Jun 11 13:53:34 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 11 Jun 2009 13:53:34 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> Message-ID: <4A316ECE.4050300@superliminal.com> If you think things are complicated now, just wait until we start leaning heavily on multithreading to spread the load! There is a special circle of hell reserved for debugging threading problems. Seriously though, there is work under weigh to use more threads in the viewer to tackle some of these sorts of problems. Inventory sorting could well be such a task that could be done in parallel and make a noticeable difference but I have no idea whether that's true because the inventory system is one of the most complex parts of the viewer. -Melinda Nexii Malthus wrote: > Why not simply run inventory sorting in a different thread on the > second core? Nearly everyone has at least Dual Core, despite my > computer being ancient, I still have at least two cores, one being > unused 99% of the time due to the client not being effectively > architectured to accomodate multithreading. > > On Thu, Jun 11, 2009 at 12:58 PM, Tigro Spottystripes > > wrote: > > Melinda Green escreveu: > > Tigro Spottystripes wrote: > >> > >> > >> > >> The way I would do it would be to make sure the client is > completly > >> logged in, before trying to make any less important tasks, > IMO there > >> seems to be too many things being done during login that > could just as > >> well be done before and/or after login has been > stabilished, and have > >> the client always prioritize staying connected over other > things, never > >> the other way around, there is no point in doing anything > else if you > >> endup disconnected (unless of course if it is after the > user has > >> requested to be disconnected) > >> > >> Any insults to the code, if present at all, were only meant > to emphasize > >> my surprise/disappointment with the existence of apparent > flaws and in > >> some cases add a bit of comical relief, I never meant to > offend anyone. > >> I understand that organicly grown software systems tend to > get somewhat > >> messy, that is often an inherent feature of orgagnicly > developed > >> anything, take a look a the human body :P > >> > >> There are great things and ingenious hacks around non-great > things, but > >> there are a great number of people who would have major > changes done > >> from scratch instead of built over existing mistakes done, > I'm talking > >> about the human body, but it also applies to the SL client. > >> > >> But I am aware that with complex systems, specially > organicly developed > >> ones, minor changes often produce unexpected results in > things that were > >> expected to be independent, I do appreciate the work done > with SL, it's > >> the type of thing that would be expected to not work and > yet it does (to > >> some extent depending on who you ask), t is amazingly > fragile and yet > >> unexpectedly robust, in many aspects it's kinda like the > Antonov 225, > >> too big to fly, reconditioned old tech, and yet it achieves > greatly. > >> > > > > Well, now that's the sort of analysis, suggestion, and tone > that I > > think *is* helpful, thanks! > > > > Regarding work done on log-in, if we defer doing all those > things that > > you call less important (to you, that is), then when the > time comes > > to do all that work, if they happen all at once, then we're > just going > > to delay the time before we suddenly grind down and get > disconnected. > > That's assuming that all those things are atomic and > independent, > > which they're not. Having spent a fair amount of time in > that start-up > > code, I know too well what a delicate choreography it > requires to make > > sure that each service is initialized before it's needed to > initialize > > some other service. I spent the better part of a month > simply turning > > about 50 global pointers into proper singletons for exactly that > > reason. The reason it took that long was because of circular > > interdependencies that needed to be untangled, and this was > only one > > small part of the start-up process. So I agree that it's > almost a > > miracle that it works at all. > > > > Taking your suggestion to it's logical extreme we would end > up after > > enormous effort with services broken into clean modules that are > > packaged as shared libraries that get loaded the first > moment they're > > accessed, if ever. I like that idea a lot but have to point > out that > > it's not all upside. Aside from crashes that will happen when an > > attempt is made to load a module that didn't get packaged, > or when the > > wrong version is loaded, users will then experience > noticeable pauses > > the first time they access major components. Sure, log-in > will be > > quick, but there will be a new kind of annoyance that > happens when you > > go to do anything new. So there's value in initializing > everything > > right up front and in a well-defined order, and there's value in > > initializing modules on demand, and none of the choices seem > easy or > > obvious to me. > > > > -Melinda > > > > is it not possible to prioritize different activities, like always > making sure the most important things involved in keeping the > client > connected always have enough system resources to perform > regardless of > how much work other things have in mind? I imagine people > wouldn't care > much about inventory being sorted fast if they get > disconnected, things > with less priority might run slower, and everything that would > cause > issues if done without other things having finished first > should check > if the requirements have been met, and if they haven't, check > if they > are in the process of getitng done, if not, ask them to start. > Doing it > like that, nothing should cause disconnections due to > timeouts, and > regardless of the current state, things would make the right > state be > achieved. So if the machine is powerful enough, everything > gets done > before the progress bar reaches the end, and if the machine isn't > powerful enough, things will simply load up while they are > used, in many > cases people are used to things loading gradually, like > objects loading > from close to far, sculpty and textures progressively getting more > details, avatars deruthing property by property (at least that > used to > be the case before Ruth got hidden away and replaced with the > cloud or > in some cases simply nothing), I believe people would handle > it well if > there was active indication of progress, no big stops in > progress bars, > and no repetitive animation that doesn't differentiate > beginning from > middle from end of operation, and things like indications of > different > steps , like text explaining what exactly is being done, or simply > icons, colors or changes in the gui that are easily > recognizable as > individual stages etc are present;. Things shouldn't freeze other > things, gui should remain responsive, connection essential > operations > should continue being triggered in time, things being done > simultaneously shouldn't hog avaiable resources all to > themselves, they > should share the resources, slowing down process depending on > their > priority, only things with very little priority should ever > actually > freeze to a halt for any noticeable amount of time, and there > should > never be doubt for the user about whether things are still > working or > have reached an irreversible unwelcome state (freeze, crash, > or simply > hav no idea what to do with the current condition/data and > can't find > it's way back to normal behavior etc). The user should always > be given > positive confirmation goals are being achieved, work is being > done, that > the client knows what it is doing and haven't forgot of the > user. If > some things already can be done while others are still being > prepared, > the user should be allowed to do them while not being left in > the dark > about the progress of what is not avaible yet. > > > IMO, partial functionality, with information on what is > missing and how > long till is it avaiable is better than passively watching a > progress > bar, or having to wonder if the client will ever resume being > responssive again. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From dzonatas at gmail.com Thu Jun 11 14:19:17 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 11 Jun 2009 14:19:17 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A316ECE.4050300@superliminal.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> Message-ID: <4A3174D5.1050901@gmail.com> Melinda Green wrote: > If you think things are complicated now, just wait until we start > leaning heavily on multithreading to spread the load! Sounds like a good time to move UI implementation from C++ and go C#. It'll make it that much less complicated. From melinda at superliminal.com Thu Jun 11 15:26:53 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 11 Jun 2009 15:26:53 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A3174D5.1050901@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> Message-ID: <4A3184AD.10208@superliminal.com> Dzonatas Sol wrote: > Melinda Green wrote: >> If you think things are complicated now, just wait until we start >> leaning heavily on multithreading to spread the load! > > Sounds like a good time to move UI implementation from C++ and go C#. > It'll make it that much less complicated. OMG, Yes! Unfortunately I think we're too far along the current path to do that. A change that big would in practice require a complete rewrite. If we ever achieve greater code separation, then this sort of thing becomes possible by layering a 2D Java/Swing or C# GUI over the existing 3D engine. That's my dream anyway. -Melinda From dzonatas at gmail.com Thu Jun 11 16:33:38 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 11 Jun 2009 16:33:38 -0700 Subject: [sldev] Snowglobe-Sharp Re: Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A3184AD.10208@superliminal.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A3184AD.10208@superliminal.com> Message-ID: <4A319452.5090603@gmail.com> Melinda Green wrote: > Dzonatas Sol wrote: >> Melinda Green wrote: >>> If you think things are complicated now, just wait until we start >>> leaning heavily on multithreading to spread the load! >> >> Sounds like a good time to move UI implementation from C++ and go C#. >> It'll make it that much less complicated. > > OMG, Yes! Unfortunately I think we're too far along the current path > to do that. A change that big would in practice require a complete > rewrite. If we ever achieve greater code separation, then this sort of > thing becomes possible by layering a 2D Java/Swing or C# GUI over the > existing 3D engine. That's my dream anyway. > > -Melinda > Well, then part of your dream has already become a reality. I've went ahead and already started on Snowglob-Sharp. Since it is the API being exported by glib, it doesn't need to be dependant on C#, as gobject exports are being supported by many languages, like Java, Python, Ruby, Perl, and more. Here is where I'm at now: * "snowglobe-sharp: Determine a template/boilerplate to use to auto-generate the C & H GObject files" http://jira.dzonux.net:8080/browse/MVS-40 ** Since I've already made several API objects, eventually they should be all auto-generated, and I can use what I started to create a template for them. I went through several UML->MDA->text model conversions and determined what is available advanced for its specific implementation and too complicated to have it do something simple and similar to glib-genmarshal. UML is not even on the stove at this time. * "snowglobe-sharp: use GAPI tools to auto-generate API wrappers to libsnowglobe.dll" http://jira.dzonux.net:8080/browse/MVS-38 ** I just completed this. Basically I took all the direct API I had done, so far, and wrapped them up to where GAPI tools can auto-gen the C# API. This became Snowglobe-Sharp. Eventually I'll untie this part from the MonoVida code, but for now I want it to build together for the single-keypress build all command that I hit often (plus the API changes too quickly to untie right now). *"Reimplement all chat/communicate panels as MonoVida.Panel.*" http://jira.dzonux.net:8080/browse/MVS-25 ** The basics for "local chat" is done. See screenshot here: https://wiki.secondlife.com/wiki/Alternate_viewers#MonoVida_Studio ** I've moved on to IM sessions, so I have stubs and structures in code for that right now. * Threads are no problem. I already have code that I haven't merged and commited where Mono/.NET threads are used instead of what the viewer uses. I recently disabled the default signal handler in the viewer, so that Mono gives a complete C# stacktrace + gdb output. I consider code separation already being on the path of being achieved. Wish we were working together on it... From melinda at superliminal.com Thu Jun 11 18:04:56 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 11 Jun 2009 18:04:56 -0700 Subject: [sldev] Snowglobe-Sharp Re: Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A319452.5090603@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A3184AD.10208@superliminal.com> <4A319452.5090603@gmail.com> Message-ID: <4A31A9B8.6070501@superliminal.com> Dzonatas Sol wrote: > Melinda Green wrote: >> Dzonatas Sol wrote: >>> Melinda Green wrote: >>>> If you think things are complicated now, just wait until we start >>>> leaning heavily on multithreading to spread the load! >>> >>> Sounds like a good time to move UI implementation from C++ and go >>> C#. It'll make it that much less complicated. >> >> OMG, Yes! Unfortunately I think we're too far along the current path >> to do that. A change that big would in practice require a complete >> rewrite. If we ever achieve greater code separation, then this sort >> of thing becomes possible by layering a 2D Java/Swing or C# GUI over >> the existing 3D engine. That's my dream anyway. >> >> -Melinda >> > Well, then part of your dream has already become a reality. > > I've went ahead and already started on Snowglob-Sharp. Since it is the > API being exported by glib, it doesn't need to be dependant on C#, as > gobject exports are being supported by many languages, like Java, > Python, Ruby, Perl, and more. That sounds fantastic!! > Here is where I'm at now: > > * "snowglobe-sharp: Determine a template/boilerplate to use to > auto-generate the C & H GObject files" > http://jira.dzonux.net:8080/browse/MVS-40 > > ** Since I've already made several API objects, eventually they should > be all auto-generated, and I can use what I started to create a > template for them. I went through several UML->MDA->text model > conversions and determined what is available advanced for its specific > implementation and too complicated to have it do something simple and > similar to glib-genmarshal. UML is not even on the stove at this time. > > * "snowglobe-sharp: use GAPI tools to auto-generate API wrappers to > libsnowglobe.dll" http://jira.dzonux.net:8080/browse/MVS-38 > > ** I just completed this. Basically I took all the direct API I had > done, so far, and wrapped them up to where GAPI tools can auto-gen the > C# API. This became Snowglobe-Sharp. Eventually I'll untie this part > from the MonoVida code, but for now I want it to build together for > the single-keypress build all command that I hit often (plus the API > changes too quickly to untie right now). > > *"Reimplement all chat/communicate panels as MonoVida.Panel.*" > http://jira.dzonux.net:8080/browse/MVS-25 > > ** The basics for "local chat" is done. See screenshot here: > https://wiki.secondlife.com/wiki/Alternate_viewers#MonoVida_Studio Oh, that's not a C++ XUI window? It looks just like it! While I love the idea of being able to break out parts of the UI in one or more separate windows, I think it will be important to be able to overlay the 2D and 3D views in the same window. Regardless of how the app is packaged, I'd love to be able to take the 3D view out of maximized mode and into just another floater that I can position wherever I like within (or outside) the main window, but that's a separate issue. Also, does clicking on a resident's name in chat still bring up their profile in the 3D view? > ** I've moved on to IM sessions, so I have stubs and structures in > code for that right now. What are your plans for supporting drag-and-drop from inventory into IM windows? While we could do without that if we had to, it's a wonderful feature. Drag-and-drop is important in general too, beyond inventory->IM. > * Threads are no problem. I already have code that I haven't merged > and commited where Mono/.NET threads are used instead of what the > viewer uses. I recently disabled the default signal handler in the > viewer, so that Mono gives a complete C# stacktrace + gdb output. So how does that work? Is the main method in C#? Multithreading should be *so* much less of an issue in C#! > I consider code separation already being on the path of being achieved. > > Wish we were working together on it... Well, if you can get it all wrapped up as a clean C# project that treats the 3D rendering as a DLL or other black box, then I expect that would generate a lot of interest. I would sure prefer to do SL development in such an environment. -Melinda From TammyNowotny at mac.com Thu Jun 11 18:42:04 2009 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Thu, 11 Jun 2009 21:42:04 -0400 Subject: [sldev] Snowglobe-Sharp Re: Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A31A9B8.6070501@superliminal.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A3184AD.10208@superliminal.com> <4A319452.5090603@gmail.com> <4A31A9B8.6070501@superliminal.com> Message-ID: <4A31B26C.6080903@mac.com> Although there are other reasons why you might want to write to a notecard with a script, the main reason would be so you store data inside an object. Data like... config settings. It might be more sensible to find a better way to store config data and the like inside a scripted object: the notecard-reading thing is a kludge. We could probably allow custom properties on an object, for example. > From dzonatas at gmail.com Thu Jun 11 21:22:36 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 11 Jun 2009 21:22:36 -0700 Subject: [sldev] Snowglobe-Sharp In-Reply-To: <4A31A9B8.6070501@superliminal.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A3184AD.10208@superliminal.com> <4A319452.5090603@gmail.com> <4A31A9B8.6070501@superliminal.com> Message-ID: <4A31D80C.1000407@gmail.com> Melinda Green wrote: >> >> *"Reimplement all chat/communicate panels as MonoVida.Panel.*" >> http://jira.dzonux.net:8080/browse/MVS-25 >> >> ** The basics for "local chat" is done. See screenshot here: >> https://wiki.secondlife.com/wiki/Alternate_viewers#MonoVida_Studio > > Oh, that's not a C++ XUI window? It looks just like it! Outside the scene is all Gtk. Inside the scene is still being rendered by Snowglobe. I left the original UI windows in until I completed reimplemented them into Gtk. The Login panel is completely redone at this time. The GL context is handled in a Gtk widget, called GtkGLArea. The Gnome team accepted the GtkGLArea widget library into main trunk, but for now its best to just include the C# DLL until that version of the Gnome tunk hits Debian stable. > > While I love the idea of being able to break out parts of the UI in > one or more separate windows, I think it will be important to be able > to overlay the 2D and 3D views in the same window. I've put a lot of thought into this. While it may be good to have the UI overlay the 3D scene, and it still is possible to do such, there are programs like compiz that allow some very nice features for UIs. Even if we put aside what compiz can do and such, Gtk still offers a huge set of themes to choose from. One could put Gtk inside of GL, but compiz already does this along with all other applications available on the desktop. Compiz is a composite manager. Both Linux and Mac have fully featured composite managers, so it seems be kinda redundant continue a special UI overlay. Then, I thought about it more, and wondered why any specific UI window is not features as an asset(s), which would be just like HUD objects. Given a time when HUD objects are pretty advanced to handle UI features, that would render the current UI overlay design obsolete. Whenever that time happens is a matter of when the features in the client are there to allow it to happen. It obvious the render capabilities exist. In other words, the simple abilities to point-n-click a rendered UI and make keyboards interactions in the GLArea won't change. If you are interested in a blackbox version of this, as mentioned below, then I'll stop there with the hints on possibilities. > > Regardless of how the app is packaged, I'd love to be able to take the > 3D view out of maximized mode and into just another floater that I can > position wherever I like within (or outside) the main window, but > that's a separate issue. I like to put chat on one desktop screen, the main view on another desktop, and (someday) a more advanced inventory on another. This goes beyond just a simple wide window that fits on two monitors. > > Also, does clicking on a resident's name in chat still bring up their > profile in the 3D view? The click action works currently. I haven't reimplemented the profile view, yet, so it just prints who you clicked on instead of call the profile view. I could tie it in to the C++ based profile view, but... hmmm. I've already had a brainstorm of ways to redesign that little action with features of Gtk# that probably aren't easily available in the C++ code now. > >> ** I've moved on to IM sessions, so I have stubs and structures in >> code for that right now. > > What are your plans for supporting drag-and-drop from inventory into > IM windows? While we could do without that if we had to, it's a > wonderful feature. Drag-and-drop is important in general too, beyond > inventory->IM. It wouldn't be the same without drag-n-drop. Given time, I hope this feature can become much more advance. Why not, have a separate GL window specifically to view items in 3D as they are drag-n-drop'd. (I won't get into the details of how to render them without a remote sim, as there are many.) Yes, wouldn't want to leave out the basic drag-n-drop ability into any window. Perhaps a generic interface class could be made to handle such events. > >> * Threads are no problem. I already have code that I haven't merged >> and commited where Mono/.NET threads are used instead of what the >> viewer uses. I recently disabled the default signal handler in the >> viewer, so that Mono gives a complete C# stacktrace + gdb output. > > So how does that work? Is the main method in C#? Multithreading should > be *so* much less of an issue in C#! It starts in Mono/.Net. Then it loads snowglobe-sharp, which also loads snowglobe. I made the changes to compile the viewer as a shared library. And, yes, it makes it much easier to standardize multi-threading details when the same base classes can be used across platforms. > >> I consider code separation already being on the path of being achieved. >> >> Wish we were working together on it... > > Well, if you can get it all wrapped up as a clean C# project that > treats the 3D rendering as a DLL or other black box, then I expect > that would generate a lot of interest. I would sure prefer to do SL > development in such an environment. > > -Melinda > As mentioned above, Snowglobe-Sharp is already a DLL. I'm open to here about ideas to blackbox it further. For the first round, the API design is extruded directly from the current design in the viewer. I haven't follow any particular rule to keep it extruded or to fully redesign functionality. C# presents ways to do things much differently, so there is much temptation to let go of the extruded classes and play with "features," and just leave behind the network & render code in the DLL. From olli_aro at yahoo.co.uk Thu Jun 11 23:09:25 2009 From: olli_aro at yahoo.co.uk (Olli Aro) Date: Fri, 12 Jun 2009 07:09:25 +0100 Subject: [sldev] Web login Message-ID: Hi all, I found the wiki page at http://wiki.secondlife.com/wiki/Viewer_Authentication and tested it, but could not get it working. Does anyone know if there is a way to get web logins working (if not as detailed on the wiki page then some other approach)? Regards, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090612/a43228ac/attachment.htm From poppy at lindenlab.com Fri Jun 12 00:13:56 2009 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Fri, 12 Jun 2009 00:13:56 -0700 Subject: [sldev] C++ Unit Testing interface is changing Message-ID: <4A320034.10108@lindenlab.com> Unit tests are small projects that combine tiny parts of the source tree with testing harnesses. By running tests against small portions of the project with every submit, new bugs are caught as early as possible. In the Lab we've been ramping up to write many more of these tests. If you've started writing unit tests for your code, thanks! This message is for you about some changes coming up. This is a notice that the CMake interface for adding unit tests in indra code is going to be changing quite a bit very soon. The gist of it is that ADD_BUILD_TEST is now LL_ADD_PROJECT_UNIT_TESTS, and it behaves much more like adding a target in cmake (as it now takes a list of all sources under test for a project). In the process, I'm heavily updating our docs on unit testing, centrally accessible from: https://wiki.secondlife.com/wiki/Unit_tests Just letting you know - if you're writing unit tests, you will have to change your CMakeLists.txt. There are some subtle new features, you can see some of them in use in indra/newview/CMakeLists.txt after the merge. This change is being done to facilitate future work in making unit testing in our builds more scalable. + poppy From jan.ciger at gmail.com Fri Jun 12 01:01:42 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 12 Jun 2009 10:01:42 +0200 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A3174D5.1050901@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> Message-ID: <4A320B66.7020908@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dzonatas Sol wrote: > Melinda Green wrote: >> If you think things are complicated now, just wait until we start >> leaning heavily on multithreading to spread the load! > > Sounds like a good time to move UI implementation from C++ and go C#. > It'll make it that much less complicated. I am sorry, but you honestly do not know what you are talking about. How are threading problems somehow less complex in C#? Race conditions and deadlocks do not magically go away. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFKMgtjn11XseNj94gRAvJXAJ4mx2KttQQ8ilZ0WZdPLnHkn0cP1gCg8keg G8yLZRsKwupiAsHt6l5+ZuA= =7qUE -----END PGP SIGNATURE----- From carlo at alinoe.com Fri Jun 12 04:32:44 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 12 Jun 2009 13:32:44 +0200 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A320B66.7020908@gmail.com> References: <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A320B66.7020908@gmail.com> Message-ID: <20090612113244.GA16862@alinoe.com> On Fri, Jun 12, 2009 at 10:01:42AM +0200, Jan Ciger wrote: > I am sorry, but you honestly do not know what you are talking about. How > are threading problems somehow less complex in C#? Race conditions and > deadlocks do not magically go away. Also, all viewer developers currently are C++ experts; I don't think it's a good idea to drag in some new language at this point. -- Carlo Wood From dmahalko at gmail.com Fri Jun 12 05:01:41 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri, 12 Jun 2009 07:01:41 -0500 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <20090612113244.GA16862@alinoe.com> References: <4A30A42F.9050705@Gmail.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A320B66.7020908@gmail.com> <20090612113244.GA16862@alinoe.com> Message-ID: Well this has turned out to be a suprisingly fruitful thread. Would be nice if someone could distill all this into a couple of pages for the wiki, though I am not volunteering for that at the moment. :-) Inventory retrieval process Login processes Asset garbage collection Asset server operation UUID implentation / reuse - Dale From dzonatas at gmail.com Fri Jun 12 07:01:04 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 12 Jun 2009 07:01:04 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A320B66.7020908@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A320B66.7020908@gmail.com> Message-ID: <4A325FA0.2090500@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090612/90e4c016/attachment.htm From dzonatas at gmail.com Fri Jun 12 07:06:23 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 12 Jun 2009 07:06:23 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <20090612113244.GA16862@alinoe.com> References: <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A320B66.7020908@gmail.com> <20090612113244.GA16862@alinoe.com> Message-ID: <4A3260DF.3020703@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090612/23658bbe/attachment.htm From suzyq at pobox.com Fri Jun 12 06:48:34 2009 From: suzyq at pobox.com (Suzy Deffeyes) Date: Fri, 12 Jun 2009 08:48:34 -0500 Subject: [sldev] PreferredMaturity setting and settings.xml Message-ID: <2bd5b7f10906120648w7d7a8dc3j5a02339911017024@mail.gmail.com> Hi All, I'm working on porting OGP ( http://wiki.secondlife.com/wiki/Open_Grid_Protocol ) login and teleport from the OGP9 branch to Snowglobe. I had a question about the PreferredMaturity setting. I can understand why the viewer would get the maturity flags from the server, but why save them in settings.xml? For authentication systems that don't pass back agent_region_access (like OpenSim or OGP), wouldn't that mean that I'd end up getting whatever the last main grid authenticate happened to store in my settings.xml? And wouldn't this mean the setting.xml value for PreferredMaturity would in fact not be user controllable via settings.xml? From soft at lindenlab.com Fri Jun 12 07:47:22 2009 From: soft at lindenlab.com (Soft) Date: Fri, 12 Jun 2009 09:47:22 -0500 Subject: [sldev] PreferredMaturity setting and settings.xml In-Reply-To: <2bd5b7f10906120648w7d7a8dc3j5a02339911017024@mail.gmail.com> References: <2bd5b7f10906120648w7d7a8dc3j5a02339911017024@mail.gmail.com> Message-ID: My bad - I pointed this out internally, but I don't think I captured it in JIRA. It's too late for 1.23, but if that's still set persistent in settings.xml, I'll unset it. On Fri, Jun 12, 2009 at 8:48 AM, Suzy Deffeyes wrote: > Hi All, > > I'm working on porting OGP > (http://wiki.secondlife.com/wiki/Open_Grid_Protocol ) login and teleport > from the OGP9 branch to Snowglobe. > > I had a question about the PreferredMaturity setting.? I can understand why > the viewer would get the maturity flags from the server, but why save them > in settings.xml?? For authentication systems that don't pass back > agent_region_access (like OpenSim or OGP), wouldn't that mean that I'd end > up getting whatever the last main grid authenticate happened to store in my > settings.xml? And wouldn't this mean the setting.xml value for > PreferredMaturity would in fact not be user controllable via settings.xml? > > From llstartup.cpp: > ??? ??? ??? // this is the value of their preference setting for that > content > ??? ??? ??? // which will always be <= agent_access_max > ??? ??? ??? text = > LLUserAuth::getInstance()->getResponse("agent_region_access"); > ??? ??? ??? if (!text.empty()) > ??? ??? ??? { > ??? ??? ??? ??? int preferredMaturity = > LLAgent::convertTextToMaturity(text[0]); > ??? ??? ??? ??? gSavedSettings.setU32("PreferredMaturity", > preferredMaturity); > ??? ??? ??? } > > Thanks > Suzy Deffeyes/ Pixel Gausman > IBM > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From q at lindenlab.com Fri Jun 12 07:43:40 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Fri, 12 Jun 2009 10:43:40 -0400 Subject: [sldev] PreferredMaturity setting and settings.xml In-Reply-To: <2bd5b7f10906120648w7d7a8dc3j5a02339911017024@mail.gmail.com> References: <2bd5b7f10906120648w7d7a8dc3j5a02339911017024@mail.gmail.com> Message-ID: Hi, Suzy. We wanted this flag to be stored on the server, across logins and clients, because the information needs to be evaluated at the server. It's also stored in settings.xml for two reasons: a) It allows us to show that setting during the login process (but, you'll note, it's not editable there because you haven't logged in yet). b) The settings system provides a convenient mechanism for access to user settings information across the whole viewer, and it's the standard way we do preferences. Changing it does require a server connection, and the viewer value is always overridden by what the server knows at login. So yes, editing it in settings.xml might affect what the viewer does only until next time you log in at which time it will be overridden. And for any server transaction, the value that the server has wins. Q On Jun 12, 2009, at 9:48 AM, Suzy Deffeyes wrote: > Hi All, > > I'm working on porting OGP (http://wiki.secondlife.com/wiki/Open_Grid_Protocol > ) login and teleport from the OGP9 branch to Snowglobe. > > I had a question about the PreferredMaturity setting. I can > understand why the viewer would get the maturity flags from the > server, but why save them in settings.xml? For authentication > systems that don't pass back agent_region_access (like OpenSim or > OGP), wouldn't that mean that I'd end up getting whatever the last > main grid authenticate happened to store in my settings.xml? And > wouldn't this mean the setting.xml value for PreferredMaturity would > in fact not be user controllable via settings.xml? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090612/55a7acce/attachment.htm From fire at b3dMultitech.com Fri Jun 12 12:54:18 2009 From: fire at b3dMultitech.com (Fire) Date: Fri, 12 Jun 2009 12:54:18 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A3260DF.3020703@gmail.com> References: <4A30A42F.9050705@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A320B66.7020908@gmail.com> <20090612113244.GA16862@alinoe.com> <4A3260DF.3020703@gmail.com> Message-ID: <1dabc2a30906121254q8c71b1epba28e35defa6d0c8@mail.gmail.com> Yes indeed, this has been a fruitful discussion! Thanks for everyone for contributing. I'm looking forward to a day where notecards can have full HTML pulled content from the web. Wouldnt that be an interesting surprise... Once again, I must say, it is a privilege to have so many creative and dedicated minds postulating the possibilities of these emerging virtual worlds! Cheers everyone, and thanks! On Fri, Jun 12, 2009 at 7:06 AM, Dzonatas Sol wrote: > Carlo Wood wrote: > > > Also, all viewer developers currently are C++ experts; > I don't think it's a good idea to drag in some new language at > this point. > > > > > > I mentioned in my other post that the API can be exported various > languages, and that includes C++ for those that want to stay with C++. Do > you not think it is a good idea to make the network and render engine > available to a wide base of programmers, or only to C++ programmers? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090612/66f3ceda/attachment.htm From jhurliman at jhurliman.org Fri Jun 12 12:54:32 2009 From: jhurliman at jhurliman.org (John Hurliman) Date: Fri, 12 Jun 2009 12:54:32 -0700 Subject: [sldev] Web login In-Reply-To: References: Message-ID: web_login_key parsing is crippled in new viewers. It's only a couple lines of code to change in the SL viewer to fix it if you want do that and submit a patch to JIRA. John On Thu, Jun 11, 2009 at 11:09 PM, Olli Aro wrote: > Hi all, > > > > I found the wiki page at > http://wiki.secondlife.com/wiki/Viewer_Authentication and tested it, but > could not get it working. > > > > Does anyone know if there is a way to get web logins working (if not as > detailed on the wiki page then some other approach)? > > > > Regards, > > > > Olli > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From carlo at alinoe.com Fri Jun 12 19:15:47 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 13 Jun 2009 04:15:47 +0200 Subject: [sldev] Deadlock in llmedia Message-ID: <20090613021547.GA12153@alinoe.com> Hiyas, I'm trying to make LLFilePicker NOT lock up the viewer (so that you lose connection if you don't quickly pick a file). In order to do that, I run it in it's own thread. This means that GTK must be made thread safe, of course. I made the necessary changes (I think) to the viewer code to have a thread-safe GTK approach, basically by initializing gdk for threads (that initialization as completely missing) and calling gdk_threads_enter() to take the main lock that gdk/gtk use. This lock is kept at all time in the main thread / main loop, except once per loop (usually inside gtk_main) where it is released to let other threads run (which should wrap their calls to gtk_* inside a gdk_threads_enter/leave). Everything runs fine this way, and the viewer happily continues to run even with a file picker window open, until I start audio ... Namely, LLMediaImplGStreamer::updateMedia calls g_main_context_pending, which calls g_main_context_prepare which seems to dead lock on the lock set by gdk_threads_enter (I'm not sure it's the same lock, and it seems a bit weird because g_* is not gdk... but releasing the lock with gdk_threads_leave makes the dead lock disappear). I'd like to try to release this main lock just prior to calling g_main_context_pending(), but llmedia doesn't include the gdk header path... and I have no idea how to add this to cmake :/ So, my question is: What do I have to change in wich cmake files do to be able to call gdk_threads_enter/leave in llmedia/llmediaimplgstreamer.cpp ? Thanks in advance for the help with part that outside my expertise, Carlo Wood From dzonatas at gmail.com Fri Jun 12 19:56:05 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 12 Jun 2009 19:56:05 -0700 Subject: [sldev] Deadlock in llmedia In-Reply-To: <20090613021547.GA12153@alinoe.com> References: <20090613021547.GA12153@alinoe.com> Message-ID: <4A331545.3060500@gmail.com> The quick solution is attached, but I wouldn't use the suggestion I posted on IRC: On IRC I sent you a better solution for the filepicker, which is to call _leave() and not even call _do(). Instead of do, use g_connect() to the "response" signal. This way you don't even wait inside a _enter()/_leave() state, and you can still use the default gtk lock. You could just put the thread to sleep, and the response can awake it. Carlo Wood wrote: > So, my question is: > > What do I have to change in wich cmake files do to be able > to call gdk_threads_enter/leave in llmedia/llmediaimplgstreamer.cpp ? > > Thanks in advance for the help with part that > outside my expertise, > > Carlo Wood > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff Url: http://lists.secondlife.com/pipermail/sldev/attachments/20090612/ef779e03/attachment.txt From dzonatas at gmail.com Fri Jun 12 22:13:43 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 12 Jun 2009 22:13:43 -0700 Subject: [sldev] On making threads less complex with using g-objects Message-ID: <4A333587.8080209@gmail.com> The interest is to allow several languages access to a base dynamic shared object (i.e. DLL) given an API that can be used across each language. Some languages provide their own methods for process threads. If the API supports an abstract class that can be used across each languages, then this is the kind of standardization that is less complex. The interface is the same instead of the complexity of many different implementation across each language. There is also further complexity when a specific language actually is actually supported by its hosts environment, which is common with virtual machines. These VMs work best when the threads are controlled by the VM instead of by the guest environment, the DLL in this case. There are some advanced topics about this I'll avoid here. When you run the viewer as a standalone executable, it is its own host and guest. The viewer doesn't need to be a standalone executable, as the base code for it could support an API as noted above. This essentially turns what was the viewer into a DLL. The communication layer in-n-out of the blackbox, like between the DLL and any specific language, is the g-objects. I think some were confused by that with the mention of other languages. This is beyond the proof-of-concept stage. To pick out a use case, I'd point out the need for a multi-threaded API that works for each language. From malachi at tamzap.com Fri Jun 12 22:17:12 2009 From: malachi at tamzap.com (malachi at tamzap.com) Date: Sat, 13 Jun 2009 01:17:12 -0400 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <4A333587.8080209@gmail.com> References: <4A333587.8080209@gmail.com> Message-ID: <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> call it stupid. or just call it a late night rant amongst friends. but after a few rounds at the ol think box we have found a very easy way to if not completely eliminate at least prevent a majority of griefers from attacking us. ;) we already have to pay to upload sounds. and textures. and even animations. and griefers tend to do this on their main accounts and then copy the asset uuid to patch into their scripts. but what if......... and please bare in mind this is silly but it might just work..... what if LL slapped a nice little charge on scripts. be it a 10L per script charge. or a method of forcing residents to age and payment verify before given the ability to create scripts. the latter would force all the stupid script kiddies off the grid as they couldnt show proof of their age and surely these 14-15 year old punks dont have credit cards. Plus the added benifit that LL would have RL contact information on these clowns that waste region resources with stupid prims and particles. Griefing is another form of internet terrorism in some cases lol. the per script charge way would also link alts to main accounts as the main would be sending 10 or 20L at a time to their alts so they could create scripts. alt abuse causes you to lose both accounts. this would show these people that just cause they use an alt doesnt mean they have the right to grief others. i know that alot of people will say that charging residents for the right to script is wrong... ye but if you look at it that way.. charging me to have a texture is wrong too. LL charges for textures and sounds and animations cause they take up space on LL servers. scripts do too. so why not charge for them? i personally would not mind paying for the right to create scripted content. and this would benifit the community as well cause you would then have the feeling of security that when you go shopping for an item you know that the person that made it has legit information with LL and they arent jsut some conartist selling you some fake scripted something. sorry for taking up your time guys and gals... keep up the good work with the viewer work. just thought i would get the opinion of others that are legit creators in this virtual world we all share. mal From soft at lindenlab.com Fri Jun 12 22:20:45 2009 From: soft at lindenlab.com (Soft) Date: Sat, 13 Jun 2009 00:20:45 -0500 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> Message-ID: On Sat, Jun 13, 2009 at 12:17 AM, wrote: > call it stupid. or just call it a late night rant amongst friends. but after > a few rounds at the ol think box we have found a very easy way to if not > completely eliminate at least prevent a majority of griefers from attacking > us. ;) > > we already have to pay to upload sounds. and textures. and even animations. > and griefers tend to do this on their main accounts and then copy the asset > uuid to patch into their scripts. but what if......... and please bare in > mind this is silly but it might just work..... > > what if LL slapped a nice little charge on scripts. be it a 10L per script > charge. or a method of forcing residents to age and payment verify before > given the ability to create scripts. the latter would force all the stupid > script kiddies off the grid as they couldnt show proof of their age and > surely these 14-15 year old punks dont have credit cards. Plus the added > benifit that LL would have RL contact information on these clowns that waste > region resources with stupid prims and particles. Griefing is another form > of internet terrorism in some cases lol. What do you do about a library item dragged out of inventory with a script already in it, or something acquired from a freebie shop? Most of those scripts are modifiable. From tom at streamsense.net Fri Jun 12 22:21:30 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Sat, 13 Jun 2009 06:21:30 +0100 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> Message-ID: <4A33375A.3040909@streamsense.net> malachi at tamzap.com wrote: > what if LL slapped a nice little charge on scripts. All the scripters would leave, and SL would stop functioning. Scripts drive everything that you enjoy in world. When i'm scripting a product, I might save/upload scripts maybe 2000 times through the whole product lifecycle, i'm not going to pay for the privilege. ~T From malachi at tamzap.com Fri Jun 12 22:25:56 2009 From: malachi at tamzap.com (malachi at tamzap.com) Date: Sat, 13 Jun 2009 01:25:56 -0400 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> Message-ID: <9E7F77EE09274E658CF44499B475CA87@slsystemspc> well i understand as i said its a bit silly. just think that if people were forced to age and payment verify that it would limit the number of people creating new scripts. and for Thomas i wasnt imply a charge per edited script only new scripts.;) like i said its silly just thought it would be a way to prevent alot of griefers that log in and copy paste from a wiki somewhere into a script and then you have hundreds of self replicating prims running around. ----- Original Message ----- From: "Soft" To: Cc: "Second Life Developer Mailing List" Sent: Saturday, June 13, 2009 1:20 AM Subject: Re: [sldev] Late night thoughts on ways to prevent griefing > On Sat, Jun 13, 2009 at 12:17 AM, wrote: >> call it stupid. or just call it a late night rant amongst friends. but >> after >> a few rounds at the ol think box we have found a very easy way to if not >> completely eliminate at least prevent a majority of griefers from >> attacking >> us. ;) >> >> we already have to pay to upload sounds. and textures. and even >> animations. >> and griefers tend to do this on their main accounts and then copy the >> asset >> uuid to patch into their scripts. but what if......... and please bare in >> mind this is silly but it might just work..... >> >> what if LL slapped a nice little charge on scripts. be it a 10L per >> script >> charge. or a method of forcing residents to age and payment verify before >> given the ability to create scripts. the latter would force all the >> stupid >> script kiddies off the grid as they couldnt show proof of their age and >> surely these 14-15 year old punks dont have credit cards. Plus the added >> benifit that LL would have RL contact information on these clowns that >> waste >> region resources with stupid prims and particles. Griefing is another >> form >> of internet terrorism in some cases lol. > > What do you do about a library item dragged out of inventory with a > script already in it, or something acquired from a freebie shop? Most > of those scripts are modifiable. From partners at scifipc.com Sat Jun 13 03:19:02 2009 From: partners at scifipc.com (Science Fiction Computer - SCi-Fi PC) Date: Sat, 13 Jun 2009 20:19:02 +1000 Subject: [sldev] Question: 3rd Party Website link to Second Life Message-ID: SLDev, Are there any guidelines for 3rd party, real life Business Websites who want to setup a dedicated web page that features information to their customers about their activities and involvement in Second Life? Observing & respecting the usage guidelines of the inSLT logo program, my business is interested in using the full name of Second LifeR in a website subfolder and/or in the Title of a web page. For example, a web address: http://www.mywebaddress.com/second-life/ or http://www.mywebaddress.com/inSL/ EG. Web Page Title My Unique Domain Name - We're located in Second LifeR Or My Unique Domain Name - inSLT Regards, DMC Zsigmond PS. Sorry to post this web development question here, but I'm not finding an answer to this question on the Second LifeR Branding Center (including FAQ) or in the Terms of Service. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090613/742f8eed/attachment.htm From secret.argent at gmail.com Sat Jun 13 04:43:29 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 13 Jun 2009 06:43:29 -0500 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> Message-ID: <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> On 2009-06-13, at 00:17, wrote: > what if LL slapped a nice little charge on scripts. be it a 10L per > script > charge. or a method of forcing residents to age and payment verify > before > given the ability to create scripts. [...] People keep suggesting this. If you had to pay to "upload" scripts when I joined SL, I wouldn't have joined SL. You don't just "upload" scripts once and have done with them, like textures, you're always editing and re-editing it. The only way to stop griefer alts is to go back to June 2006 and require payment info for EVERYONE. They should never have opened the grid up to unverified accounts in the first place. People can grief without scripts, they can't grief without an account. From carlo at alinoe.com Sat Jun 13 04:50:10 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 13 Jun 2009 13:50:10 +0200 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> Message-ID: <20090613115010.GA16555@alinoe.com> On Sat, Jun 13, 2009 at 12:20:45AM -0500, Soft wrote: > What do you do about a library item dragged out of inventory with a > script already in it, or something acquired from a freebie shop? Most > of those scripts are modifiable. What he (they) basically try to do is that you aren't allowed to run a script unless the RL identity of the person who last made changes to a script is known with LL. In other words, script won't run unless the creator's identity is known, and saving a script after making changes should change the name of the creator. Payment is not needed. The problem that I see with this is that every scripter wannabee has to be verified first... which is very nice in the case of griefers, but has a major negative impact on a LOT of other users. We have already proof that LL doesn't give a damn about the latter, so I thought I'd bring this up before after 6 months of silence this is suddenly enforced. Seems better to me to discuss it *before* it's implemented :p -- Carlo Wood From tigrospottystripes at gmail.com Sat Jun 13 04:51:15 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 13 Jun 2009 08:51:15 -0300 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> Message-ID: <4A3392B3.5060707@Gmail.com> Argent Stonecutter escreveu: > On 2009-06-13, at 00:17, > wrote: > >> what if LL slapped a nice little charge on scripts. be it a 10L per >> script >> charge. or a method of forcing residents to age and payment verify >> before >> given the ability to create scripts. [...] >> > > People keep suggesting this. If you had to pay to "upload" scripts > when I joined SL, I wouldn't have joined SL. You don't just "upload" > scripts once and have done with them, like textures, you're always > editing and re-editing it. > > The only way to stop griefer alts is to go back to June 2006 and > require payment info for EVERYONE. They should never have opened the > grid up to unverified accounts in the first place. People can grief > without scripts, they can't grief without an account. > > there wasn't any griefing back when alll accounts where paid? From GordonWendt at gmail.com Sat Jun 13 08:41:40 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sat, 13 Jun 2009 11:41:40 -0400 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <4A3392B3.5060707@Gmail.com> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> <4A3392B3.5060707@Gmail.com> Message-ID: <493033a70906130841r3d8c295ewa991d29224eb91b8@mail.gmail.com> On Sat, Jun 13, 2009 at 7:51 AM, Tigro Spottystripes < tigrospottystripes at gmail.com> wrote: > Argent Stonecutter escreveu: > > The only way to stop griefer alts is to go back to June 2006 and > > require payment info for EVERYONE. They should never have opened the > > grid up to unverified accounts in the first place. People can grief > > without scripts, they can't grief without an account. > > there wasn't any griefing back when alll accounts where paid? > There was and even when LL knew everyone's identity they didn't make use of it, they just did the same thing they do know which is suspend/ban griefers as they see them and remove objects and scripts as needed. Pre-6/6/06 everyone was known but there was no deterrent because everyone knew then as they know now that LL wouldn't use the information that they had to actually go after people. That being said I don't see how they could go after people since you can't sue for damage for a prim damaging the roof of your virtual house. People asked and are asking the impossible of LL which makes it seem like an ignorant idea. -G.W. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090613/1d2b5ef1/attachment.htm From garmin.kawaguichi at magalaxie.com Sat Jun 13 08:46:39 2009 From: garmin.kawaguichi at magalaxie.com (Garmin Kawaguichi) Date: Sat, 13 Jun 2009 17:46:39 +0200 Subject: [sldev] Late night thoughts on ways to prevent griefing References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> Message-ID: I agree with Soft's remark and I complete it : Griefers (or not griefers) have to pay only one time 10 l$ or to verify for only one script their age; they have just to copy the accepted first script and exchange it among themselves to produce thousand of scripts. Pictures, sounds etc are not editable in world and may be charged! GK From tigrospottystripes at gmail.com Sat Jun 13 09:20:22 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 13 Jun 2009 13:20:22 -0300 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> Message-ID: <4A33D1C6.8010504@Gmail.com> would that even be necessary with free modifiable scripts already avaiable ont he Library? Garmin Kawaguichi escreveu: > I agree with Soft's remark and I complete it : > > Griefers (or not griefers) have to pay only one time 10 l$ or to verify for > only one script their age; they have just to copy the accepted first script > and exchange it among themselves to produce thousand of scripts. Pictures, > sounds etc are not editable in world and may be charged! > > GK > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From twisted_laws at hotmail.com Sat Jun 13 09:30:30 2009 From: twisted_laws at hotmail.com (Twisted Laws) Date: Sat, 13 Jun 2009 12:30:30 -0400 Subject: [sldev] Snowglobe, svn and prebuilts In-Reply-To: <4A3152D1.7020604@lindenlab.com> References: <4A3152D1.7020604@lindenlab.com> Message-ID: when you do an svn checkout you get version 2369 ... the pre-builts are 2391 ... what is the differences between these? _________________________________________________________________ Windows Live?: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090613/658ad0ba/attachment.htm From armin.weatherwax at googlemail.com Sat Jun 13 09:56:17 2009 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Sat, 13 Jun 2009 18:56:17 +0200 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> Message-ID: <200906131856.17597.Armin.Weatherwax@gmail.com> Am Saturday 13 June 2009 07:17:12 schrieb malachi at tamzap.com: > what if LL slapped a nice little charge on scripts. be it a 10L per script > charge. Griefing can be done just by using chat, so you'd also should ask for a 10L charge for every line of chat. Also using voice, so charge 10L for any use of the middle mouse button. Doing such a thing would mean that anybody writing a script (using chat ...) would be griefed, without griefers having to be even online. Armin From sheet.spotter at gmail.com Sat Jun 13 10:24:03 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Sat, 13 Jun 2009 12:24:03 -0500 Subject: [sldev] Snowglobe, svn and prebuilts In-Reply-To: References: <4A3152D1.7020604@lindenlab.com> Message-ID: <7F7EBBB057B44A828F8247D9ECCB978C@kenb> You can see the changes in each revision by browsing the archive from the sldev-commits mailing list. You can navigate to the archives from this page: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits The http-texture branch is now at revision 2401. Sheet _____ From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Twisted Laws Sent: June 13, 2009 11:31 AM To: sldev at lists.secondlife.com Subject: [sldev] Snowglobe, svn and prebuilts when you do an svn checkout you get version 2369 ... the pre-builts are 2391 ... what is the differences between these? _____ Windows LiveT: Keep your life in sync. Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090613/a1f79fdf/attachment.htm From melinda at superliminal.com Sat Jun 13 11:08:01 2009 From: melinda at superliminal.com (Melinda Green) Date: Sat, 13 Jun 2009 11:08:01 -0700 Subject: [sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD? In-Reply-To: <4A320B66.7020908@gmail.com> References: <1dabc2a30906101735w31c09c94g89296eef38f79465@mail.gmail.com> <4A309B9A.8080305@gmail.com> <4A309BF7.4020204@Gmail.com> <4A309F0F.3060908@superliminal.com> <4A30A42F.9050705@Gmail.com> <4A30CD4F.4050807@superliminal.com> <4A30D32A.5060909@Gmail.com> <4A30E683.2010904@superliminal.com> <4A30F177.8030204@Gmail.com> <824c8ab70906110510p683d7b5cj8234292e2d0574f7@mail.gmail.com> <824c8ab70906110512h49740e55w5ce39757aac58ef4@mail.gmail.com> <4A316ECE.4050300@superliminal.com> <4A3174D5.1050901@gmail.com> <4A320B66.7020908@gmail.com> Message-ID: <4A33EB01.4040401@superliminal.com> Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dzonatas Sol wrote: > >> Melinda Green wrote: >> >>> If you think things are complicated now, just wait until we start >>> leaning heavily on multithreading to spread the load! >>> >> Sounds like a good time to move UI implementation from C++ and go C#. >> It'll make it that much less complicated. >> > > I am sorry, but you honestly do not know what you are talking about. How > are threading problems somehow less complex in C#? Race conditions and > deadlocks do not magically go away. I agree with Dzonatas that there's no reason to be insulting here. I won't say any more about that and will just deal with your question which is fair and which will make me reevaluate my opinions on the subject. First off, I'm a C++-turned-Java/Swing programmer and have never compiled a line of C# in my life. My understanding of C# is that it's a blatent, near identical copy of Java that happened because Sun screwed up by leaving Microsoft the legal option to do that. Because they'd gotten away with it, Microsoft didn't need to worry about trying to make C# look terribly different from Java, so they're basically the same language with similar standard services. So when I think about threading issues in Java, I find that I have the confidence to tackle many more tricky new threading issues than I ever would except to succeed with using C++. It's just so much easier pushing code around while feeling around for the most maintainable, scalable designs. Dealing with threading issues in Java feels more like a walk in the park compared to performing a high-wire act without a net. Sure, you can get good at these dangerous activities, but I see no need to bother when there are safer alternatives. Solving existing threading problems won't be any easier unless the code in question can be translated into C# first (which I do not recommend). On the other hand, new code which could benefit from being run asynchronously would be easier to write, test, debug and manage than the same C++ code would be. In my experience, I can consistently get four times as much finished, productive code in Java than I can in the same amount of time with C++. The lightning compile/link times completely changes the way that you develop code when your previously long long compile, edit, test, debug. cycle time suddenly drops to nothing. I have the same expectations from other interpreted languages such as Python. I know very little about Python but I feel it could be yet another language the GUI could be implemented in. This might look like an attractive option for many existing Linden developers who are already using Python for other critical components. Interpreted languages just rock. The C++ true-believers have two strong cards they like to play. The first is that the viewer is already in C++ and it just simplifies things if there is only one compiler involved. That argument carries some real weight. For better or worse, to introduce another language into the viewer we would need to get the legacy code to talk to code in another language. That weight definitely goes on the side of the scale that wants to keep everything in C++. But with a growing number of Python programmers in the ranks, they'd probably assess that weight as not terribly heavy. The second strong card they'll play is that there are certain situations in which performance is critical, and you can't get nearly the performance needed from a compiled language from an interpreted one. My answer is that sometimes you underestimate just how fast the object code produced by just-in-time compilers can be. The Java JIT compiler writes C++ versions of the Java logic for methods which it then compiles using the C++ compiler, so in the end the machine is running mostly native code produced by the java code. So the speed cost of Java/C# may surprise some people, and even in the worse case where some expensive inner loop really needs to be coded directly in C++ and maybe a little assembly code, that's fine. Coding those critical components in C++ would be using the right tool for the job. They're just an extremely rare case since that sort of code nearly always represents less than 5% of the code. Sometimes much less. My basic argument is that for the other 95% of the code, C++ is the *wrong* tool for the job. -Melinda From me at signpostmarv.name Sat Jun 13 11:23:14 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sat, 13 Jun 2009 19:23:14 +0100 Subject: [sldev] Question: 3rd Party Website link to Second Life In-Reply-To: References: Message-ID: <4A33EE92.8010204@signpostmarv.name> I believe the inSL (and related brand-center) guidelines you're referring to are the only guidelines for 3rd-party usage of the Second Life in the manner you're citing. http://secondlife.com/corporate/brand/ ~ Marv. Science Fiction Computer - SCi-Fi PC wrote: > > SLDev, > > Are there any guidelines for 3^rd party, real life Business Websites > who want to setup a dedicated web page that features information to > their customers about their activities and involvement in Second Life? > > Observing & respecting the usage guidelines of the inSL? logo program, > my business is interested in using the full name of Second Life? in a > website subfolder and/or in the Title of a web page. > > For example, a web address: > > http://www.mywebaddress.com/second-life/ > > or > > http://www.mywebaddress.com/inSL/ > > EG. Web Page Title > > My Unique Domain Name ? We?re located in Second Life? > > Or > > My Unique Domain Name ? inSL? > > Regards, > > DMC Zsigmond > > PS. Sorry to post this web development question here, but I?m not > finding an answer to this question on the Second Life? Branding Center > (including FAQ) or in the Terms of Service. > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090613/80b28466/attachment.bin From secret.argent at gmail.com Sat Jun 13 13:51:47 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat, 13 Jun 2009 15:51:47 -0500 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <4A3392B3.5060707@Gmail.com> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> <4A3392B3.5060707@Gmail.com> Message-ID: <7A7BA783-1479-49C1-BE67-2240E2DC8159@gmail.com> On 2009-06-13, at 06:51, Tigro Spottystripes wrote: > there wasn't any griefing back when alll accounts where paid? Not as much. Griefing took off like a rocket in June 2006, when they quit requiring a valid credit card to get an account. From tayra.dagostino at gmail.com Sat Jun 13 14:01:36 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sat, 13 Jun 2009 23:01:36 +0200 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <7A7BA783-1479-49C1-BE67-2240E2DC8159@gmail.com> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> <4A3392B3.5060707@Gmail.com> <7A7BA783-1479-49C1-BE67-2240E2DC8159@gmail.com> Message-ID: <20090613230136.568afe2f.tayra.dagostino@gmail.com> On Sat, 13 Jun 2009 15:51:47 -0500 Argent Stonecutter wrote: > > there wasn't any griefing back when alll accounts where paid? > Not as much. > Griefing took off like a rocket in June 2006, when they quit > requiring a valid credit card to get an account. I think age verification should be a requirement for ALL, basic/freee account too, no more registration without submit a valid document number... this help to solve griefing too From tigrospottystripes at gmail.com Sat Jun 13 14:04:10 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 13 Jun 2009 18:04:10 -0300 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <20090613230136.568afe2f.tayra.dagostino@gmail.com> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> <4A3392B3.5060707@Gmail.com> <7A7BA783-1479-49C1-BE67-2240E2DC8159@gmail.com> <20090613230136.568afe2f.tayra.dagostino@gmail.com> Message-ID: <4A34144A.9000704@Gmail.com> Tayra Dagostino escreveu: > On Sat, 13 Jun 2009 15:51:47 -0500 > Argent Stonecutter wrote: > > > I think age verification should be a requirement for ALL, basic/freee > account too, no more registration without submit a valid document > number... this help to solve griefing too > > perhaps you haven't heard about it, there are plenty of valuable people who isn't able to use the right information to be verified, or doesn't trust Aristotle with their personal identification data From rdw at lindenlab.com Sat Jun 13 14:10:49 2009 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Sat, 13 Jun 2009 14:10:49 -0700 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <4A34144A.9000704@Gmail.com> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> <4A3392B3.5060707@Gmail.com> <7A7BA783-1479-49C1-BE67-2240E2DC8159@gmail.com><20090613230136.568afe2f.tayra.dagostino@gmail.com> <4A34144A.9000704@Gmail.com> Message-ID: <4A3415D9.2050208@lindenlab.com> On 6/13/09 2:04 PM, Tigro Spottystripes wrote: > Tayra Dagostino escreveu: > >> On Sat, 13 Jun 2009 15:51:47 -0500 >> Argent Stonecutter wrote: >> >> >> I think age verification should be a requirement for ALL, basic/freee >> account too, no more registration without submit a valid document >> number... this help to solve griefing too >> >> >> > > > perhaps you haven't heard about it, there are plenty of valuable people > who isn't able to use the right information to be verified, or doesn't > trust Aristotle with their personal identification data > It seems like this conversation isn't really suitable for sldev. Do y'all mind taking it to some other venue? :-) From malachi at tamzap.com Sat Jun 13 15:30:12 2009 From: malachi at tamzap.com (malachi at tamzap.com) Date: Sat, 13 Jun 2009 18:30:12 -0400 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <493033a70906130841r3d8c295ewa991d29224eb91b8@mail.gmail.com> References: <4A333587.8080209@gmail.com><8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com><4A3392B3.5060707@Gmail.com> <493033a70906130841r3d8c295ewa991d29224eb91b8@mail.gmail.com> Message-ID: they dont always remove items that are used for griefing. my wife still to this day gets im spam from objects all over the grid because some stupid group placed a mass im spammer in a freebie AO and passed it out to noobs. she has reported this to LL hundreds of times over the last 2 years.... yet for some reason LL overlooks the item even though she has tracked it down and given it to the lindens. either its laziness on their part or they just dont care hell i dont know. my intentions were not to erradicate... more to prevent. there is no way to completely stop griefers. not with the source open to all. when scripting isnt available to people to use for griefing they turn to clients. and ew bots.... i just really think that it would force at least a bunch of griefers elsewhere if they were forced to have some legitimate details logged with LL ----- Original Message ----- From: Gordon Wendt To: Second Life Developer Mailing List Sent: Saturday, June 13, 2009 11:41 AM Subject: Re: [sldev] Late night thoughts on ways to prevent griefing On Sat, Jun 13, 2009 at 7:51 AM, Tigro Spottystripes wrote: Argent Stonecutter escreveu: > The only way to stop griefer alts is to go back to June 2006 and > require payment info for EVERYONE. They should never have opened the > grid up to unverified accounts in the first place. People can grief > without scripts, they can't grief without an account. there wasn't any griefing back when alll accounts where paid? There was and even when LL knew everyone's identity they didn't make use of it, they just did the same thing they do know which is suspend/ban griefers as they see them and remove objects and scripts as needed. Pre-6/6/06 everyone was known but there was no deterrent because everyone knew then as they know now that LL wouldn't use the information that they had to actually go after people. That being said I don't see how they could go after people since you can't sue for damage for a prim damaging the roof of your virtual house. People asked and are asking the impossible of LL which makes it seem like an ignorant idea. -G.W. ------------------------------------------------------------------------------ _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090613/3e68b49c/attachment.htm From malachi at tamzap.com Sat Jun 13 15:33:46 2009 From: malachi at tamzap.com (malachi at tamzap.com) Date: Sat, 13 Jun 2009 18:33:46 -0400 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <4A34144A.9000704@Gmail.com> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> <4A3392B3.5060707@Gmail.com> <7A7BA783-1479-49C1-BE67-2240E2DC8159@gmail.com><20090613230136.568afe2f.tayra.dagostino@gmail.com> <4A34144A.9000704@Gmail.com> Message-ID: so do what we did. fax LL a copy of your information. no Aristotle nothing. you and LL. ----- Original Message ----- From: "Tigro Spottystripes" To: "Tayra Dagostino" Cc: "Second Life Developer Mailing List" Sent: Saturday, June 13, 2009 5:04 PM Subject: Re: [sldev] Late night thoughts on ways to prevent griefing > > > Tayra Dagostino escreveu: >> On Sat, 13 Jun 2009 15:51:47 -0500 >> Argent Stonecutter wrote: >> >> >> I think age verification should be a requirement for ALL, basic/freee >> account too, no more registration without submit a valid document >> number... this help to solve griefing too >> >> > > > perhaps you haven't heard about it, there are plenty of valuable people > who isn't able to use the right information to be verified, or doesn't > trust Aristotle with their personal identification data > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tigrospottystripes at gmail.com Sat Jun 13 16:17:31 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sat, 13 Jun 2009 20:17:31 -0300 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> <4A3392B3.5060707@Gmail.com> <7A7BA783-1479-49C1-BE67-2240E2DC8159@gmail.com><20090613230136.568afe2f.tayra.dagostino@gmail.com> <4A34144A.9000704@Gmail.com> Message-ID: <4A34338B.2070808@Gmail.com> some people don't trust LL either, some people don't trust the internet in general, in my case if I had to send a fax of my documments to LL, I would probably need to do some sort of complicated path, like taking a digital photography, then printing, then passing the paper thru the fax machine on an international call, my fax machine can't handle stiff things like laminated documents, many people will not have either fax, or digital camera, things get complicated. And as mentioned earlier, even back when LL knew who everyone was griefing still took place. IMO the path to reducing griefing involves better tools for people to defend themselves and/or avoid griefers, and better instruction on what is involved etc, a while ago I read some people were falling for spampire tricks, this thign about adult segregation could in a big part be resolved by people being taught they can TP away if they see somthign they don't like, that thing they almost did, but backed away, resident governance, would also be helpfull, better handling of ARs, both the valid ones that get ignored and the bogus ones that punish innocent people. Also things like complete sensorial muting (don't render anything from the muted av, including the av itself, no particles, no sounds no physical interactions etc). With better punishment of the guilty, better protection of the innocent, and better ways for the innocent to not be botherred by the guilty-to-be things would be much easier, while using verification, let's say the PResley familly would grow quite a bit and people in SL would continue to be griefed. malachi at tamzap.com escreveu: > so do what we did. fax LL a copy of your information. no Aristotle > nothing. you and LL. > ----- Original Message ----- From: "Tigro Spottystripes" > > To: "Tayra Dagostino" > Cc: "Second Life Developer Mailing List" > Sent: Saturday, June 13, 2009 5:04 PM > Subject: Re: [sldev] Late night thoughts on ways to prevent griefing > > >> >> >> Tayra Dagostino escreveu: >>> On Sat, 13 Jun 2009 15:51:47 -0500 >>> Argent Stonecutter wrote: >>> >>> >>> I think age verification should be a requirement for ALL, basic/freee >>> account too, no more registration without submit a valid document >>> number... this help to solve griefing too >>> >>> >> >> >> perhaps you haven't heard about it, there are plenty of valuable people >> who isn't able to use the right information to be verified, or doesn't >> trust Aristotle with their personal identification data >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > From merov at lindenlab.com Sat Jun 13 16:49:22 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Sat, 13 Jun 2009 16:49:22 -0700 Subject: [sldev] Patch for SNOW-8 Message-ID: Hi, I posted a patch for SNOW-8 ("after re-logging, avatar shows previously-worn outfit (or invisible)" http://jira.secondlife.com/browse/SNOW-8) . I played with it yesterday night and it seemed to work. Unfortunately today, my 2nd Mac at home decided to die (can't even reboot from CD!) and I can't test that patch fully :( I'll have to wait Monday and be in the office to make a full blown test. In the meantime I'll try to fit a trip to the Apple Store in the middle of this weekend family time... If someone wants to review the patch and comment in the JIRA, I'll truly appreciate. Cheers, - Merov From partners at scifipc.com Sat Jun 13 17:41:59 2009 From: partners at scifipc.com (Science Fiction Computer - SCi-Fi PC) Date: Sun, 14 Jun 2009 10:41:59 +1000 Subject: [sldev] Question: 3rd Party Website link to Second Life - Web Address Subfolders In-Reply-To: <4A33EE92.8010204@signpostmarv.name> References: <4A33EE92.8010204@signpostmarv.name> Message-ID: Thank you Marv for your reply. My original question was mainly directed towards the use of the generic noun "Second Life(R)" by a 3rd party website. Under section #3 of this Second Life(R) Brand Center web page: http://secondlife.com/corporate/brand/trademark/sl_insl.php#guidelines ...guidelines include an example using inSL(tm) which is okay: e.g. http://www.ArchitecturalDesignServices.com/inSL ...However, is it possible to use the full name of Second Life in a visible website subfolder from an SEO perspective: e.g. http://www.website.com/second-life or http://www.website.com/secondlife The Second Life Brand Center does cover the use of the generic noun in "Titles" under publications, at the bottom of this page: http://secondlife.com/corporate/brand/trademark/reference.php ... listing: book, magazine, periodical, audio-visual work, event, or conference. The list does not implicitly include, "website", which one would logically assume would be included under "publications" as well anyway. To restate: From bogus@does.not.exist.com Fri Jun 12 11:19:36 2009 From: bogus@does.not.exist.com () Date: Fri, 12 Jun 2009 18:19:36 -0000 Subject: No subject Message-ID: the "Second Life Grid", whereby our business has a presence within Second Life in some way, it would be optimal for us to be able to establish a formally-addressed "web page" on our website that is clearly "Titled" and "Sub-foldered" to be identifiable to Internet surfers and SEO friendly to search engines - to disclose our motive. I have seen several websites already do this. To begin with, this means ensuring our use of the generic noun "Second Life(R)" in our Website Title/s either falls within publication guideline accordance, or, it means falling back to the use of inSL(tm), which from an SEO and readership perspective is 'less identifiable'. Importantly here, I am excluding text-based business names, trademarks, domain names, or even the use of the SL logo without expressed written permission from Linden Lab Research, Inc. which is already covered under Second Life (R) Brand Center Guidelines. My business interest is End User promotion and comprehension, SEO, and website subfolders. "Can the full generic noun "*/secondlife or */second-life" be used in a 3rd party website sub-folder that is visible on the Internet?" There is nothing I can find that 'implicitly' covers 'website address sub-folders' in the Second Life(R) Brand Center Guidelines. With many thanks, David (DMC Zsigmond) -----Original Message----- From: SignpostMarv Martin [mailto:me at signpostmarv.name] Sent: Sunday, June 14, 2009 4:23 AM To: Science Fiction Computer - SCi-Fi PC Cc: sldev at lists.secondlife.com Subject: Re: [sldev] Question: 3rd Party Website link to Second Life I believe the inSL (and related brand-center) guidelines you're referring to are the only guidelines for 3rd-party usage of the Second Life in the manner you're citing. http://secondlife.com/corporate/brand/ ~ Marv. Science Fiction Computer - SCi-Fi PC wrote: > > SLDev, > > Are there any guidelines for 3^rd party, real life Business Websites > who want to setup a dedicated web page that features information to > their customers about their activities and involvement in Second Life? > > Observing & respecting the usage guidelines of the inSLT logo program, > my business is interested in using the full name of Second LifeR in a > website subfolder and/or in the Title of a web page. > > For example, a web address: > > http://www.mywebaddress.com/second-life/ > > or > > http://www.mywebaddress.com/inSL/ > > EG. Web Page Title > > My Unique Domain Name - We're located in Second LifeR > > Or > > My Unique Domain Name - inSLT > > Regards, > > DMC Zsigmond > > PS. Sorry to post this web development question here, but I'm not > finding an answer to this question on the Second LifeR Branding Center > (including FAQ) or in the Terms of Service. > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.67/2174 - Release Date: 06/13/09 17:54:00 From partners at scifipc.com Sat Jun 13 18:23:56 2009 From: partners at scifipc.com (Science Fiction Computer - SCi-Fi PC) Date: Sun, 14 Jun 2009 11:23:56 +1000 Subject: [sldev] Question: 3rd Party Website link to Second Life - WebAddress Subfolders In-Reply-To: References: <4A33EE92.8010204@signpostmarv.name> Message-ID: Thanks, Jonathan. We'll call through to LL direct about "Website Subfolders" based on your tip, because the ticket system doesn't have a category for this query, which we looked at also. Appreciate your time to reply, David (DMC Zsigmond) -----Original Message----- From: Jonathan Bishop [mailto:bishopj at bishopphillips.com] Sent: Sunday, June 14, 2009 11:24 AM To: 'Science Fiction Computer - SCi-Fi PC' Subject: RE: [sldev] Question: 3rd Party Website link to Second Life - WebAddress Subfolders You are going to have to get this resolved by LL directly, unless Phillip chimes in. This list, obviously, doesn't have the authority to make a comment, other than point at the material you have already located. There was a fuss about this a year or so ago when the inSL programme was announced, and the emphatic comment made by the LL/LR officials was that Second Life was their brand/trade mark and they had an obligation properly protect it. (In fact you have to protect the TM under the TM laws or you loose it). I seem to recall that they specifically excluded the use of second life in a domain name, but whether it does, or can extend to the folder names within a web site is another issue. Similarly, while LL specifically allows the use of the phrase in publications, the fact is that they could not prevent this in any case as the words taken individually and together are a common use phrase (ie they are not made up words), and even if they were there are other protections such as fair use, etc that allow the use of the terms in written and conversational material. Ultimately the context and intention of use matters. Clearly the only way to be certain on this relatively grey issue is to 1. Get a direct response from the relevant part of LL/RL 2. Get advice from an IP lawyer. Even the LL people on this list with a couple of exceptions, are probably not authorized to express a view, let alone a definitive answer. Regards Jonathan Bishop Managing Director Bishop Phillips Consulting | Melbourne, Australia - Vancouver, Canada Mobile +61 411.404.483 | Office +61 (3) 9525.7066 | Fax +61 (3) 9525.6080 bishopj at bishopphillips.com | www.bishopphillips.com -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Science Fiction Computer - SCi-Fi PC Sent: Sunday, 14 June 2009 10:42 AM To: 'SignpostMarv Martin' Cc: sldev at lists.secondlife.com Subject: Re: [sldev] Question: 3rd Party Website link to Second Life - WebAddress Subfolders Thank you Marv for your reply. My original question was mainly directed towards the use of the generic noun "Second Life(R)" by a 3rd party website. Under section #3 of this Second Life(R) Brand Center web page: http://secondlife.com/corporate/brand/trademark/sl_insl.php#guidelines ...guidelines include an example using inSL(tm) which is okay: e.g. http://www.ArchitecturalDesignServices.com/inSL ...However, is it possible to use the full name of Second Life in a visible website subfolder from an SEO perspective: e.g. http://www.website.com/second-life or http://www.website.com/secondlife The Second Life Brand Center does cover the use of the generic noun in "Titles" under publications, at the bottom of this page: http://secondlife.com/corporate/brand/trademark/reference.php ... listing: book, magazine, periodical, audio-visual work, event, or conference. The list does not implicitly include, "website", which one would logically assume would be included under "publications" as well anyway. To restate: >From a 3rd party RL business website perspective investing in operations on the "Second Life Grid", whereby our business has a presence within Second Life in some way, it would be optimal for us to be able to establish a formally-addressed "web page" on our website that is clearly "Titled" and "Sub-foldered" to be identifiable to Internet surfers and SEO friendly to search engines - to disclose our motive. I have seen several websites already do this. To begin with, this means ensuring our use of the generic noun "Second Life(R)" in our Website Title/s either falls within publication guideline accordance, or, it means falling back to the use of inSL(tm), which from an SEO and readership perspective is 'less identifiable'. Importantly here, I am excluding text-based business names, trademarks, domain names, or even the use of the SL logo without expressed written permission from Linden Lab Research, Inc. which is already covered under Second Life (R) Brand Center Guidelines. My business interest is End User promotion and comprehension, SEO, and website subfolders. "Can the full generic noun "*/secondlife or */second-life" be used in a 3rd party website sub-folder that is visible on the Internet?" There is nothing I can find that 'implicitly' covers 'website address sub-folders' in the Second Life(R) Brand Center Guidelines. With many thanks, David (DMC Zsigmond) -----Original Message----- From: SignpostMarv Martin [mailto:me at signpostmarv.name] Sent: Sunday, June 14, 2009 4:23 AM To: Science Fiction Computer - SCi-Fi PC Cc: sldev at lists.secondlife.com Subject: Re: [sldev] Question: 3rd Party Website link to Second Life I believe the inSL (and related brand-center) guidelines you're referring to are the only guidelines for 3rd-party usage of the Second Life in the manner you're citing. http://secondlife.com/corporate/brand/ ~ Marv. Science Fiction Computer - SCi-Fi PC wrote: > > SLDev, > > Are there any guidelines for 3^rd party, real life Business Websites > who want to setup a dedicated web page that features information to > their customers about their activities and involvement in Second Life? > > Observing & respecting the usage guidelines of the inSLT logo program, > my business is interested in using the full name of Second LifeR in a > website subfolder and/or in the Title of a web page. > > For example, a web address: > > http://www.mywebaddress.com/second-life/ > > or > > http://www.mywebaddress.com/inSL/ > > EG. Web Page Title > > My Unique Domain Name - We're located in Second LifeR > > Or > > My Unique Domain Name - inSLT > > Regards, > > DMC Zsigmond > > PS. Sorry to post this web development question here, but I'm not > finding an answer to this question on the Second LifeR Branding Center > (including FAQ) or in the Terms of Service. > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.67/2174 - Release Date: 06/13/09 17:54:00 _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.67/2174 - Release Date: 06/13/09 17:54:00 From lenglish5 at cox.net Sat Jun 13 18:26:13 2009 From: lenglish5 at cox.net (Lawson English) Date: Sat, 13 Jun 2009 18:26:13 -0700 Subject: [sldev] [ANN]Links to various Second Life compatible viewers: C++, C#, GPL, BSD, etc Message-ID: <4A3451B5.1030804@cox.net> I set up a category for viewer links on the AW Groupies page. Feel free to edit/correct/add-to as needed: https://wiki.secondlife.com/wiki/AW_Groupies#External_Resources Lawson From twisted_laws at hotmail.com Sat Jun 13 21:03:08 2009 From: twisted_laws at hotmail.com (Twisted Laws) Date: Sun, 14 Jun 2009 00:03:08 -0400 Subject: [sldev] Snowglobe, svn and prebuilts In-Reply-To: <7F7EBBB057B44A828F8247D9ECCB978C@kenb> References: <4A3152D1.7020604@lindenlab.com> <7F7EBBB057B44A828F8247D9ECCB978C@kenb> Message-ID: Ok :) but why doesn't the svn checkout match? You can see the changes in each revision by browsing the archive from the sldev-commits mailing list. You can navigate to the archives from this page: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits The http-texture branch is now at revision 2401. Sheet _________________________________________________________________ Hotmail? has ever-growing storage! Don?t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090614/47fbda2e/attachment.htm From robla at lindenlab.com Sun Jun 14 00:31:56 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Sun, 14 Jun 2009 00:31:56 -0700 Subject: [sldev] Snowglobe, svn and prebuilts In-Reply-To: References: <4A3152D1.7020604@lindenlab.com> <7F7EBBB057B44A828F8247D9ECCB978C@kenb> Message-ID: <4A34A76C.2040700@lindenlab.com> On 06/13/2009 09:03 PM, Twisted Laws wrote: > Ok :) but why doesn't the svn checkout match? This file: indra/llcommon/llversionviewer.h ...determines what the viewer is going to report its version number as. That file isn't automatically updated with every checkout/checkin, but rather, gets incremented as an uncommitted local mod whenever the build machine builds a new version. That means when you build, you're going to get something different. Rob On 06/13/2009 09:03 PM, Twisted Laws wrote: > Ok :) but why doesn't the svn checkout match? > > ------------------------------------------------------------------------ > > You can see the changes in each revision by browsing the archive from > the sldev-commits mailing list. You can navigate to the archives from > this page: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits > > > > The http-texture branch is now at revision 2401. > > > > > > Sheet > > > > > > ------------------------------------------------------------------------ > Hotmail? has ever-growing storage! Don?t worry about storage limits. > Check it out. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From tigrospottystripes at gmail.com Sun Jun 14 01:53:12 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 14 Jun 2009 05:53:12 -0300 Subject: [sldev] Late night thoughts on ways to prevent griefing In-Reply-To: <4A34B4F7.60906@superliminal.com> References: <4A333587.8080209@gmail.com> <8B967AC1138A43DFA5C405A1A74DA06D@slsystemspc> <3BF24F94-FC36-4657-BF1A-6207652A87B1@gmail.com> <4A3392B3.5060707@Gmail.com> <7A7BA783-1479-49C1-BE67-2240E2DC8159@gmail.com><20090613230136.568afe2f.tayra.dagostino@gmail.com> <4A34144A.9000704@Gmail.com> <4A34338B.2070808@Gmail.com> <4A34B4F7.60906@superliminal.com> Message-ID: <4A34BA78.9060000@Gmail.com> Melinda Green escreveu: > > > Tigro Spottystripes wrote: >> [...] >> >> IMO the path to reducing griefing involves [...] things like complete >> sensorial muting (don't render >> anything from the muted av, including the av itself, no particles, no >> sounds no physical interactions etc). > > Then they'll be invisible to u but u won't be to them, so when you're > standing around with friends and one says "Hey, did u guys see what > that guy just did?", and your other friend says, "Yeah, that was > crazy", you'll be like "Who are u talking about? I don't see anyone?" > it can already happen "lol that joke was great!" and you "huh? did anyone say antying?", chat muting is already present, so is voice muting, if you think a certain grieffer is more laughing matter than annoyance, just watch instead of muting From jamey at beau.org Sun Jun 14 15:25:24 2009 From: jamey at beau.org (Jamey Fletcher) Date: Sun, 14 Jun 2009 17:25:24 -0500 Subject: [sldev] Hover Text Gone Wild! Message-ID: <4A3578D4.8070902@beau.org> Here's something a friend of mine happened to have an issue with the other day, and looks like it's on the client side. The Lindens have downrated it to "Nice To Have", but in a hover-text crowded environment like a store, it could make it very difficult to shop. http://jira.secondlife.com/browse/VWR-6994 - "Avatar Rendering Cost" (and other Info Displays) blank current hover text There's repro info, and someone has listed what they think is the problematic section of code. If I knew enough OO, I'd take a shot at it myself. From lenglish5 at cox.net Sun Jun 14 19:11:31 2009 From: lenglish5 at cox.net (Lawson English) Date: Sun, 14 Jun 2009 19:11:31 -0700 Subject: [sldev] Hover Text Gone Wild! In-Reply-To: <4A3578D4.8070902@beau.org> References: <4A3578D4.8070902@beau.org> Message-ID: <4A35ADD3.3070907@cox.net> Jamey Fletcher wrote: > Here's something a friend of mine happened to have an issue with the > other day, and looks like it's on the client side. The Lindens have > downrated it to "Nice To Have", but in a hover-text crowded environment > like a store, it could make it very difficult to shop. > > http://jira.secondlife.com/browse/VWR-6994 - "Avatar Rendering Cost" > (and other Info Displays) blank current hover text > > There's repro info, and someone has listed what they think is the > problematic section of code. If I knew enough OO, I'd take a shot at it > myself. > IIRC, floating text is part of the ObjectUpdate packet, which means its kinda a heavy call for sim <=> client traffic. Lawson From feilen1000 at gmail.com Sun Jun 14 20:38:39 2009 From: feilen1000 at gmail.com (Feilen) Date: Sun, 14 Jun 2009 22:38:39 -0500 Subject: [sldev] Option to make minimap display map data? Message-ID: <4A35C23F.6090203@gmail.com> I've often noticed that the map displays full color incremental screenshots of an entire sim, while the minimap simply layers on grey for wherever prims are. Though this can sometimes be useful, the grey is very often skyboxes or useless data. Could there be an option to make the minmap display simple map data, for a more static, general but detailed look at the sim, rather than the current prims on display? From melinda at superliminal.com Sun Jun 14 22:49:52 2009 From: melinda at superliminal.com (Melinda Green) Date: Sun, 14 Jun 2009 22:49:52 -0700 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <4A35C23F.6090203@gmail.com> References: <4A35C23F.6090203@gmail.com> Message-ID: <4A35E100.60009@superliminal.com> Feilen wrote: > I've often noticed that the map displays full color incremental > screenshots of an entire sim, while the minimap simply layers on grey > for wherever prims are. Though this can sometimes be useful, the grey is > very often skyboxes or useless data. Could there be an option to make > the minmap display simple map data, for a more static, general but > detailed look at the sim, rather than the current prims on display? You mean like the "terrain" tab on the main map? Sure, that could be done but then we start to erase the differences between main and mini-map. The mini-map is more for seeing symbolic representations so I suspect that's not a great idea, however it might be a good idea to only draw gray for prims within some vertical range around your current elevation. -Melinda From feilen1000 at gmail.com Sun Jun 14 21:00:24 2009 From: feilen1000 at gmail.com (Feilen) Date: Sun, 14 Jun 2009 23:00:24 -0500 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <4A35E100.60009@superliminal.com> References: <4A35C23F.6090203@gmail.com> <4A35E100.60009@superliminal.com> Message-ID: <4A35C758.8010808@gmail.com> Melinda Green wrote: > Feilen wrote: >> I've often noticed that the map displays full color incremental >> screenshots of an entire sim, while the minimap simply layers on grey >> for wherever prims are. Though this can sometimes be useful, the grey >> is very often skyboxes or useless data. Could there be an option to >> make the minmap display simple map data, for a more static, general >> but detailed look at the sim, rather than the current prims on display? > > You mean like the "terrain" tab on the main map? Sure, that could be > done but then we start to erase the differences between main and > mini-map. The mini-map is more for seeing symbolic representations so > I suspect that's not a great idea, however it might be a good idea to > only draw gray for prims within some vertical range around your > current elevation. > > -Melinda > No, just the regular map, as in just the image, instead of the rectangles in grey show in the minimap. From tateru.nino at gmail.com Sun Jun 14 23:09:33 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon, 15 Jun 2009 16:09:33 +1000 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <4A35E100.60009@superliminal.com> References: <4A35C23F.6090203@gmail.com> <4A35E100.60009@superliminal.com> Message-ID: <4A35E59D.8010908@gmail.com> Melinda Green wrote: > Feilen wrote: > >> I've often noticed that the map displays full color incremental >> screenshots of an entire sim, while the minimap simply layers on grey >> for wherever prims are. Though this can sometimes be useful, the grey is >> very often skyboxes or useless data. Could there be an option to make >> the minmap display simple map data, for a more static, general but >> detailed look at the sim, rather than the current prims on display? >> > > You mean like the "terrain" tab on the main map? Sure, that could be > done but then we start to erase the differences between main and > mini-map. The mini-map is more for seeing symbolic representations so I > suspect that's not a great idea, however it might be a good idea to only > draw gray for prims within some vertical range around your current > elevation. > Certainly, for many sims, the overall appearance of the minimap is either entirely gray or almost entirely gray. That, in itself, seems to obviate the purpose of having an image in it at all :) Over time, though, the creeping gray has more or less trained me out of really using the minimap (except for spotting campers and bots). It doesn't provide me enough information to be useful on a day-to-day basis. -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090615/f5df4439/attachment.htm From feilen1000 at gmail.com Sun Jun 14 21:22:07 2009 From: feilen1000 at gmail.com (Feilen) Date: Sun, 14 Jun 2009 23:22:07 -0500 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <4A35E59D.8010908@gmail.com> References: <4A35C23F.6090203@gmail.com> <4A35E100.60009@superliminal.com> <4A35E59D.8010908@gmail.com> Message-ID: <4A35CC6F.7060705@gmail.com> Tateru Nino wrote: > > > Melinda Green wrote: >> Feilen wrote: >> >>> I've often noticed that the map displays full color incremental >>> screenshots of an entire sim, while the minimap simply layers on grey >>> for wherever prims are. Though this can sometimes be useful, the grey is >>> very often skyboxes or useless data. Could there be an option to make >>> the minmap display simple map data, for a more static, general but >>> detailed look at the sim, rather than the current prims on display? >>> >> >> You mean like the "terrain" tab on the main map? Sure, that could be >> done but then we start to erase the differences between main and >> mini-map. The mini-map is more for seeing symbolic representations so I >> suspect that's not a great idea, however it might be a good idea to only >> draw gray for prims within some vertical range around your current >> elevation. >> > Certainly, for many sims, the overall appearance of the minimap is > either entirely gray or almost entirely gray. That, in itself, seems > to obviate the purpose of having an image in it at all :) > > Over time, though, the creeping gray has more or less trained me out > of really using the minimap (except for spotting campers and bots). It > doesn't provide me enough information to be useful on a day-to-day basis. > -- > Tateru Nino > http://dwellonit.taterunino.net/ > That's why it would be useful to make it simply run off images loaded from the map database, as it is hardly even useful when it does show a few prims and the environment as it has very little to show at that point, while the map database has a detailed map of the area around it (unless it's one of the sims that purposefully trys to spell out or place an image on the overall map). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090614/a978c63e/attachment.htm From melinda at superliminal.com Sun Jun 14 23:44:12 2009 From: melinda at superliminal.com (Melinda Green) Date: Sun, 14 Jun 2009 23:44:12 -0700 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <4A35E59D.8010908@gmail.com> References: <4A35C23F.6090203@gmail.com> <4A35E100.60009@superliminal.com> <4A35E59D.8010908@gmail.com> Message-ID: <4A35EDBC.6090403@superliminal.com> Tateru Nino wrote: > > > Melinda Green wrote: >> Feilen wrote: >> >>> I've often noticed that the map displays full color incremental >>> screenshots of an entire sim, while the minimap simply layers on grey >>> for wherever prims are. Though this can sometimes be useful, the grey is >>> very often skyboxes or useless data. Could there be an option to make >>> the minmap display simple map data, for a more static, general but >>> detailed look at the sim, rather than the current prims on display? >>> >> >> You mean like the "terrain" tab on the main map? Sure, that could be >> done but then we start to erase the differences between main and >> mini-map. The mini-map is more for seeing symbolic representations so I >> suspect that's not a great idea, however it might be a good idea to only >> draw gray for prims within some vertical range around your current >> elevation. >> > Certainly, for many sims, the overall appearance of the minimap is > either entirely gray or almost entirely gray. That, in itself, seems > to obviate the purpose of having an image in it at all :) > > Over time, though, the creeping gray has more or less trained me out > of really using the minimap (except for spotting campers and bots). It > doesn't provide me enough information to be useful on a day-to-day basis. That's why I suggested the idea of only displaying gray for objects that are within a given vertical range of your avatar.If you're above that threshold then it'd make sense to stop drawing the terrain, but when you're low, such a height filter would "roll back the creeping gray" while making the map make more sense at all elevations. I *think* the mini-map has that object/height data but I'm not certain. Aimee would know for sure. -Melinda From secret.argent at gmail.com Mon Jun 15 01:20:21 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 15 Jun 2009 03:20:21 -0500 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <4A35E59D.8010908@gmail.com> References: <4A35C23F.6090203@gmail.com> <4A35E100.60009@superliminal.com> <4A35E59D.8010908@gmail.com> Message-ID: <1FF0668A-0449-4E33-93F6-3213085C61AE@gmail.com> On 2009-06-15, at 01:09, Tateru Nino wrote: > Over time, though, the creeping gray has more or less trained me out > of really using the minimap (except for spotting campers and bots). > It doesn't provide me enough information to be useful on a day-to- > day basis. On the other hand when you're doing a large build it's useful to see all the blue and purkle prims, even the ones at odd elevations... perhaps best would be to have a settable vertical range limit on the mini-map/radar. From izzee at hotmail.co.uk Mon Jun 15 05:35:26 2009 From: izzee at hotmail.co.uk (izze euler) Date: Mon, 15 Jun 2009 12:35:26 +0000 Subject: [sldev] How do I remove fmod from viewer? Message-ID: Hi, I would like to exclude Fmod from my viewer. Apart from excluding files for Fmod, do I need to make any changes to the source code? If so, are there any instructions for how to do this? I need to be able to distribute my viewer. I am building with CMake and Visual Studio 2005. Izze _________________________________________________________________ With Windows Live, you can organise, edit, and share your photos. http://clk.atdmt.com/UKM/go/134665338/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090615/2ce92996/attachment.htm From monkowsk at watson.ibm.com Mon Jun 15 08:34:57 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 15 Jun 2009 11:34:57 -0400 Subject: [sldev] [ANN]Links to various Second Life compatible viewers: C++, C#, GPL, BSD, etc In-Reply-To: <4A3451B5.1030804@cox.net> References: <4A3451B5.1030804@cox.net> Message-ID: <4A366A21.7050102@watson.ibm.com> There used to be a wiki article "Alternate viewers." Someone redirected that page to one called "Downloads." You can find the information there. I must say, though, that "Alternate viewers" seems a lot more descriptive than "Downloads". Mike Lawson English wrote: > I set up a category for viewer links on the AW Groupies page. Feel free > to edit/correct/add-to as needed: > > https://wiki.secondlife.com/wiki/AW_Groupies#External_Resources > > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From lenglish5 at cox.net Mon Jun 15 08:41:31 2009 From: lenglish5 at cox.net (Lawson English) Date: Mon, 15 Jun 2009 08:41:31 -0700 Subject: [sldev] [ANN]Links to various Second Life compatible viewers: C++, C#, GPL, BSD, etc In-Reply-To: <4A366A21.7050102@watson.ibm.com> References: <4A3451B5.1030804@cox.net> <4A366A21.7050102@watson.ibm.com> Message-ID: <4A366BAB.7010907@cox.net> Mike Monkowski wrote: > There used to be a wiki article "Alternate viewers." Someone redirected > that page to one called "Downloads." You can find the information > there. I must say, though, that "Alternate viewers" seems a lot more > descriptive than "Downloads". > > Mike > > Hi Mike, yeah, that link is there and someone (you?) corrected it. However, there are viewers not based on LL code, and there is at least one client lib (pyogp) written totally in Python. I've also heard rumors of a libmov-derived viewer project written in C++. I expect others to appear as time goes on. L. From lenglish5 at cox.net Mon Jun 15 09:28:16 2009 From: lenglish5 at cox.net (Lawson English) Date: Mon, 15 Jun 2009 09:28:16 -0700 Subject: [sldev] [ANN]Links to various Second Life compatible viewers: C++, C#, GPL, BSD, etc In-Reply-To: <4A366BAB.7010907@cox.net> References: <4A3451B5.1030804@cox.net> <4A366A21.7050102@watson.ibm.com> <4A366BAB.7010907@cox.net> Message-ID: <4A3676A0.9030607@cox.net> Lawson English wrote: > Mike Monkowski wrote: > >> There used to be a wiki article "Alternate viewers." Someone redirected >> that page to one called "Downloads." You can find the information >> there. I must say, though, that "Alternate viewers" seems a lot more >> descriptive than "Downloads". >> >> Mike >> >> >> > > Hi Mike, yeah, that link is there and someone (you?) corrected it. > However, there are viewers not based on LL code, and there > is at least one client lib (pyogp) written totally in Python. I've also > heard rumors of a libmov-derived viewer project written in C++. > > I expect others to appear as time goes on. > > > Well, my bad. Not only is the Alternate views link NOT fixed, but there are links to both GPL-derived and libmov viewers randomly listed. I'll try to work off the existing page (does "Second Life Compatible viewers" sound like a reasonable title for the page?) and reindex the existing viewers' links and add the ones linked from the Groupies page under the appropriate heading. Redundancy, aint it awesomely wonderful? L From feilen1000 at gmail.com Mon Jun 15 10:07:46 2009 From: feilen1000 at gmail.com (Feilen) Date: Mon, 15 Jun 2009 12:07:46 -0500 Subject: [sldev] Option to make minimap display map data? Message-ID: <4A367FE2.40301@gmail.com> On 2009-06-15, at 3:20, Argent Stonecutter wrote: On the other hand when you're doing a large build it's useful to see all the blue and purkle prims, even the ones at odd elevations... perhaps best would be to have a settable vertical range limit on the mini-map/radar. That's why I thought it would be best as an option, if possible added to the View toolbar, to where unless you're building you can view the detailed map of the sim, which is much more useful except in the event of building. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090615/e69cf1e5/attachment.htm From nexiim at googlemail.com Mon Jun 15 13:23:08 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Mon, 15 Jun 2009 21:23:08 +0100 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <4A367FE2.40301@gmail.com> References: <4A367FE2.40301@gmail.com> Message-ID: <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> Why on earth can't it be a combination? (ie local region data on top AND world map texture under it) Also it is ridicolously easy to add a "culling" for megaprims in the llnetmap.cpp file, I did this as a feature to my Vertical Life client such that it negates the impact of megaprims and revives the usefulness of the minimap. (One of my top favourite features in my client, it is great to be able to do these simple but very important things that make life easier). On 6/15/09, Feilen wrote: > On 2009-06-15, at 3:20, Argent Stonecutter wrote: > > On the other hand when you're doing a large build it's useful to see > all the blue and purkle prims, even the ones at odd elevations... perhaps > best would be to have a settable vertical range limit on the > mini-map/radar. > > > > That's why I thought it would be best as an option, if possible added to > the View toolbar, to where unless you're building you can view the > detailed map of the sim, which is much more useful except in the event > of building. > > From nexiim at googlemail.com Mon Jun 15 13:26:03 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Mon, 15 Jun 2009 21:26:03 +0100 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> References: <4A367FE2.40301@gmail.com> <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> Message-ID: <824c8ab70906151326k13ad3672of96d3960adcbae6f@mail.gmail.com> And to the question of additional useful data, I think it would be great to be able to differentiate higher or lower prims from the minimap. I think what could be done is incrementally darken or lighten the minimap objects based on height slightly, I think I am going to try this in my custom client. On 6/15/09, Nexii Malthus wrote: > Why on earth can't it be a combination? (ie local region data on top > AND world map texture under it) > > Also it is ridicolously easy to add a "culling" for megaprims in the > llnetmap.cpp file, I did this as a feature to my Vertical Life client > such that it negates the impact of megaprims and revives the > usefulness of the minimap. (One of my top favourite features in my > client, it is great to be able to do these simple but very important > things that make life easier). > > On 6/15/09, Feilen wrote: >> On 2009-06-15, at 3:20, Argent Stonecutter wrote: >> >> On the other hand when you're doing a large build it's useful to see >> all the blue and purkle prims, even the ones at odd elevations... >> perhaps >> best would be to have a settable vertical range limit on the >> mini-map/radar. >> >> >> >> That's why I thought it would be best as an option, if possible added to >> the View toolbar, to where unless you're building you can view the >> detailed map of the sim, which is much more useful except in the event >> of building. >> >> > From tigrospottystripes at gmail.com Mon Jun 15 13:31:09 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 15 Jun 2009 17:31:09 -0300 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <824c8ab70906151326k13ad3672of96d3960adcbae6f@mail.gmail.com> References: <4A367FE2.40301@gmail.com> <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> <824c8ab70906151326k13ad3672of96d3960adcbae6f@mail.gmail.com> Message-ID: <4A36AF8D.7060209@Gmail.com> how about making prims above/bellow a given height range (perhaps based on draw distance, dunno) be semitransparent, perhaps even make them gradually more transparent further they are from the limit? Nexii Malthus escreveu: > And to the question of additional useful data, I think it would be > great to be able to differentiate higher or lower prims from the > minimap. I think what could be done is incrementally darken or lighten > the minimap objects based on height slightly, I think I am going to > try this in my custom client. > > On 6/15/09, Nexii Malthus wrote: > >> Why on earth can't it be a combination? (ie local region data on top >> AND world map texture under it) >> >> Also it is ridicolously easy to add a "culling" for megaprims in the >> llnetmap.cpp file, I did this as a feature to my Vertical Life client >> such that it negates the impact of megaprims and revives the >> usefulness of the minimap. (One of my top favourite features in my >> client, it is great to be able to do these simple but very important >> things that make life easier). >> >> On 6/15/09, Feilen wrote: >> >>> On 2009-06-15, at 3:20, Argent Stonecutter wrote: >>> >>> On the other hand when you're doing a large build it's useful to see >>> all the blue and purkle prims, even the ones at odd elevations... >>> perhaps >>> best would be to have a settable vertical range limit on the >>> mini-map/radar. >>> >>> >>> >>> That's why I thought it would be best as an option, if possible added to >>> the View toolbar, to where unless you're building you can view the >>> detailed map of the sim, which is much more useful except in the event >>> of building. >>> >>> >>> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From melinda at superliminal.com Mon Jun 15 13:38:11 2009 From: melinda at superliminal.com (Melinda Green) Date: Mon, 15 Jun 2009 13:38:11 -0700 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <824c8ab70906151326k13ad3672of96d3960adcbae6f@mail.gmail.com> References: <4A367FE2.40301@gmail.com> <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> <824c8ab70906151326k13ad3672of96d3960adcbae6f@mail.gmail.com> Message-ID: <4A36B133.7000805@superliminal.com> We could even allow the user to rotate the mini-map in 3D to see elevation data vertically. Then you could alt-zoom into it and we could replace the avatar dots with impostor images, add a micro-mini-map, etc. I'm kidding of course but just to make the point that the purpose of the mini-map is provide a highly simplified, symbolic map in which too much realism would be a bad thing. Adding shading effects would feel to me like going too far in that direction. -Melinda Nexii Malthus wrote: > And to the question of additional useful data, I think it would be > great to be able to differentiate higher or lower prims from the > minimap. I think what could be done is incrementally darken or lighten > the minimap objects based on height slightly, I think I am going to > try this in my custom client. > > On 6/15/09, Nexii Malthus wrote: > >> Why on earth can't it be a combination? (ie local region data on top >> AND world map texture under it) >> >> Also it is ridicolously easy to add a "culling" for megaprims in the >> llnetmap.cpp file, I did this as a feature to my Vertical Life client >> such that it negates the impact of megaprims and revives the >> usefulness of the minimap. (One of my top favourite features in my >> client, it is great to be able to do these simple but very important >> things that make life easier). >> >> On 6/15/09, Feilen wrote: >> >>> On 2009-06-15, at 3:20, Argent Stonecutter wrote: >>> >>> On the other hand when you're doing a large build it's useful to see >>> all the blue and purkle prims, even the ones at odd elevations... >>> perhaps >>> best would be to have a settable vertical range limit on the >>> mini-map/radar. >>> >>> >>> >>> That's why I thought it would be best as an option, if possible added to >>> the View toolbar, to where unless you're building you can view the >>> detailed map of the sim, which is much more useful except in the event >>> of building. >>> >>> >>> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From tigrospottystripes at gmail.com Mon Jun 15 13:42:16 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 15 Jun 2009 17:42:16 -0300 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <4A36B133.7000805@superliminal.com> References: <4A367FE2.40301@gmail.com> <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> <824c8ab70906151326k13ad3672of96d3960adcbae6f@mail.gmail.com> <4A36B133.7000805@superliminal.com> Message-ID: <4A36B228.50507@Gmail.com> it's not really shading effect, just a representation of depth of flat rectangles IMO that is more important than, or at least as important as, different colored dots for friends and people in general Melinda Green escreveu: > We could even allow the user to rotate the mini-map in 3D to see > elevation data vertically. Then you could alt-zoom into it and we could > replace the avatar dots with impostor images, add a micro-mini-map, etc. > I'm kidding of course but just to make the point that the purpose of the > mini-map is provide a highly simplified, symbolic map in which too much > realism would be a bad thing. Adding shading effects would feel to me > like going too far in that direction. > > -Melinda > > Nexii Malthus wrote: > >> And to the question of additional useful data, I think it would be >> great to be able to differentiate higher or lower prims from the >> minimap. I think what could be done is incrementally darken or lighten >> the minimap objects based on height slightly, I think I am going to >> try this in my custom client. >> >> On 6/15/09, Nexii Malthus wrote: >> >> >>> Why on earth can't it be a combination? (ie local region data on top >>> AND world map texture under it) >>> >>> Also it is ridicolously easy to add a "culling" for megaprims in the >>> llnetmap.cpp file, I did this as a feature to my Vertical Life client >>> such that it negates the impact of megaprims and revives the >>> usefulness of the minimap. (One of my top favourite features in my >>> client, it is great to be able to do these simple but very important >>> things that make life easier). >>> >>> On 6/15/09, Feilen wrote: >>> >>> >>>> On 2009-06-15, at 3:20, Argent Stonecutter wrote: >>>> >>>> On the other hand when you're doing a large build it's useful to see >>>> all the blue and purkle prims, even the ones at odd elevations... >>>> perhaps >>>> best would be to have a settable vertical range limit on the >>>> mini-map/radar. >>>> >>>> >>>> >>>> That's why I thought it would be best as an option, if possible added to >>>> the View toolbar, to where unless you're building you can view the >>>> detailed map of the sim, which is much more useful except in the event >>>> of building. >>>> >>>> >>>> >>>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From nexiim at googlemail.com Mon Jun 15 14:11:26 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Mon, 15 Jun 2009 22:11:26 +0100 Subject: [sldev] Fwd: Option to make minimap display map data? In-Reply-To: <824c8ab70906151410i1f18df54qd102c65aa62ad47d@mail.gmail.com> References: <4A367FE2.40301@gmail.com> <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> <824c8ab70906151326k13ad3672of96d3960adcbae6f@mail.gmail.com> <4A36B133.7000805@superliminal.com> <4A36B228.50507@Gmail.com> <824c8ab70906151410i1f18df54qd102c65aa62ad47d@mail.gmail.com> Message-ID: <824c8ab70906151411g3166c96dt720beeb94a83506d@mail.gmail.com> God damn gmail. Forwarding to mailing list; ---------- Forwarded message ---------- From: Nexii Malthus Date: Mon, 15 Jun 2009 22:10:33 +0100 Subject: Re: [sldev] Option to make minimap display map data? To: TigroSpottystripes at gmail.com Indeed, we are just polling ideas of how to leverage existing data to make the minimap more useful. Depth has been a long standing issue to try express in the minimap, a slight difference in brightness could help a LOT in creating more definition and a sense of structure from the otherwise huge blocks of grey which don't convey the needed information for understanding the structure of the region. A use-case example, it is very hard to relate to the minimap if your in a city region for example where all terrain is covered by prims. If we added a brightness differentation for say buildings and streets which are naturally higher or lower prims, it would be FAR easier to relate to the minimap and MUCH less confusing for the user than watching avatar dots move in grey goo. On 6/15/09, Tigro Spottystripes wrote: > it's not really shading effect, just a representation of depth of flat > rectangles > > IMO that is more important than, or at least as important as, different > colored dots for friends and people in general > > Melinda Green escreveu: >> We could even allow the user to rotate the mini-map in 3D to see >> elevation data vertically. Then you could alt-zoom into it and we could >> replace the avatar dots with impostor images, add a micro-mini-map, etc. >> I'm kidding of course but just to make the point that the purpose of the >> mini-map is provide a highly simplified, symbolic map in which too much >> realism would be a bad thing. Adding shading effects would feel to me >> like going too far in that direction. >> >> -Melinda >> >> Nexii Malthus wrote: >> >>> And to the question of additional useful data, I think it would be >>> great to be able to differentiate higher or lower prims from the >>> minimap. I think what could be done is incrementally darken or lighten >>> the minimap objects based on height slightly, I think I am going to >>> try this in my custom client. >>> >>> On 6/15/09, Nexii Malthus wrote: >>> >>> >>>> Why on earth can't it be a combination? (ie local region data on top >>>> AND world map texture under it) >>>> >>>> Also it is ridicolously easy to add a "culling" for megaprims in the >>>> llnetmap.cpp file, I did this as a feature to my Vertical Life client >>>> such that it negates the impact of megaprims and revives the >>>> usefulness of the minimap. (One of my top favourite features in my >>>> client, it is great to be able to do these simple but very important >>>> things that make life easier). >>>> >>>> On 6/15/09, Feilen wrote: >>>> >>>> >>>>> On 2009-06-15, at 3:20, Argent Stonecutter wrote: >>>>> >>>>> On the other hand when you're doing a large build it's useful to >>>>> see >>>>> all the blue and purkle prims, even the ones at odd elevations... >>>>> perhaps >>>>> best would be to have a settable vertical range limit on the >>>>> mini-map/radar. >>>>> >>>>> >>>>> >>>>> That's why I thought it would be best as an option, if possible added >>>>> to >>>>> the View toolbar, to where unless you're building you can view the >>>>> detailed map of the sim, which is much more useful except in the event >>>>> of building. >>>>> >>>>> >>>>> >>>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > From tigrospottystripes at gmail.com Mon Jun 15 16:32:00 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 15 Jun 2009 20:32:00 -0300 Subject: [sldev] Fwd: Option to make minimap display map data? In-Reply-To: <824c8ab70906151411g3166c96dt720beeb94a83506d@mail.gmail.com> References: <4A367FE2.40301@gmail.com> <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> <824c8ab70906151326k13ad3672of96d3960adcbae6f@mail.gmail.com> <4A36B133.7000805@superliminal.com> <4A36B228.50507@Gmail.com> <824c8ab70906151410i1f18df54qd102c65aa62ad47d@mail.gmail.com> <824c8ab70906151411g3166c96dt720beeb94a83506d@mail.gmail.com> Message-ID: <4A36D9F0.7030804@Gmail.com> btw, an idea I came up with partially inspired by this discussion http://jira.secondlife.com/browse/VWR-14048 From khyota at redhyena.net Mon Jun 15 18:44:21 2009 From: khyota at redhyena.net (Khyota) Date: Mon, 15 Jun 2009 21:44:21 -0400 Subject: [sldev] Strange camera/avatar behavior in 1.23.4 on opensuse 11.1 Message-ID: <200906152144.22111.khyota@redhyena.net> Has anyone tried 1.23 yet? im having this weird issue whare the camera appears to be stuck to my pelvis and is uncontrollable, but after teleporting i can see myself with no avatar mesh. I could only repro it on opensuse 11.1 x86_64, did not on windows xp or gentoo x86. see http://jira.secondlife.com/browse/VWR-14050 Thanks guys! From aimee.trescothick at gmail.com Mon Jun 15 18:49:04 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 16 Jun 2009 02:49:04 +0100 Subject: [sldev] Option to make minimap display map data? In-Reply-To: <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> References: <4A367FE2.40301@gmail.com> <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> Message-ID: On 15 Jun 2009, at 21:23, Nexii Malthus wrote: > Also it is ridicolously easy to add a "culling" for megaprims in the > llnetmap.cpp file, I did this as a feature to my Vertical Life client > such that it negates the impact of megaprims and revives the > usefulness of the minimap. Definitely agreed, makes a huge difference. http://jira.secondlife.com/browse/VWR-12631 This may be a good candidate for Snowglobe on the next cycle. > And to the question of additional useful data, I think it would be > great to be able to differentiate higher or lower prims from the > minimap. I think what could be done is incrementally darken or lighten > the minimap objects based on height slightly, I think I am going to > try this in my custom client. Yes, I've been considering doing that too, there's a very elementary precedent for it now, in that prims below water level are drawn darker. Personally I'd like to be able to choose a hybrid view, using the S3 map texture as a mini-map background, and only draw objects live that have been updated within a certain amount of time, so exploring a long established sim you have the advantage of a properly rendered view, but will still see vehicles that are in motion, or the stuff someone's throwing at you for example. There's a lot of other useful things that could be displayed as optional overlays, such as parcel boundaries, or chat range limits. I'd like to be able to select whichever combination of layers I want to see at the time. An isometric scanner style representation is not as far-fetched as it may sound either, and has been proposed before (http://wiki.secondlife.com/wiki/User_Experience_Interest_Group/Transcripts/2009-01-15 ), heck, Acornsoft's Elite had it back in the 1980's and that was on a 2Mhz 6502 with 32K =) Aimee. From merov at lindenlab.com Mon Jun 15 23:18:22 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Mon, 15 Jun 2009 23:18:22 -0700 Subject: [sldev] Option to make minimap display map data? In-Reply-To: References: <4A367FE2.40301@gmail.com> <824c8ab70906151323v22645757p7765a86a79a9cb14@mail.gmail.com> Message-ID: <5A54D28B-78B8-4C48-9B60-7699D3F1F0D5@lindenlab.com> Hi, On Jun 15, 2009, at 6:49 PM, Aimee Trescothick wrote: > Personally I'd like to be able to choose a hybrid view, using the S3 > map texture as a mini-map background, and only draw objects live that > have been updated within a certain amount of time, so exploring a long > established sim you have the advantage of a properly rendered view, > but will still see vehicles that are in motion, or the stuff someone's > throwing at you for example. I had a similar idea I actually discussed with Melinda back in the days... :) It wouldn't be hard to use the S3 tiles as background for sure as is done in the map (it will be a tad slower though as, currently, there's nothing to fetch from any server to display the minimap). Then overlay on top of that the "symbolic" info that Melinda and you Aim?e are talking about (people, range, camera cone, etc...). The problem I have with the current display is that, indeed, I only see gray instead of a legible map of terrain and building. It sort of defeats the purpose. I've been playing with using the map itself as a navigation help and found it more usable for exploration (unless I'm visiting a mall or a covered area). Cheers, - Merov From nexiim at googlemail.com Tue Jun 16 02:08:50 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Tue, 16 Jun 2009 10:08:50 +0100 Subject: [sldev] Attempting to build 1.23 Message-ID: <824c8ab70906160208p4f765b72t1506e0190a30cb4e@mail.gmail.com> I'm getting a lot of external symbol errors, what libraries have been changed in 1.23 after moving from 1.22? I have run cmake and all perfectly fine but it seems like I must be missing some additional libraries or my libraries are older versions. I have compiled the 1.22 client perfectly fine before but 1.23.4 has stumped me. I'm unable to find any references on the wiki and I am frankly just getting frustrated. Being able to compile 1.23 would help me find the origin of mysterious crashes that occur on me with the official client, as well as update my custom client to the new codebase. For a full error list see the attachment in this forum post: http://nexii.ordoimperialis.com/viewtopic.php?f=4&t=58 I have exhausted most of my options and a friend suggested it might be that this is a library issue. From nexiim at googlemail.com Tue Jun 16 02:42:26 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Tue, 16 Jun 2009 10:42:26 +0100 Subject: [sldev] Some early automation tests results. In-Reply-To: <200906111104.03650.lists.secondlife.com@trap.wereanimal.net> References: <200906111104.03650.lists.secondlife.com@trap.wereanimal.net> Message-ID: <824c8ab70906160242l46e24d82q1dd75a042c38859d@mail.gmail.com> Very nice work. Could the results perhaps be posted into a statistics graph? A graph may be more readable than plain text. On 6/11/09, Techwolf Lupindo wrote: > > Last week Open Source meeting, there was a call put out to make some > automated > client side test to measure lag and so on. I pick up the challenge and it > was > a LOT tougher then I though with all the limitations and shortcomings of SL. > > BUT, I managed to get a repeatable test that can be use across different > versions of the SL client, including snowglobe. > > Here is some early results of that effort. Right now, it is just a simple > walk > around a sim I found on the beta grid. Each run 1 was started with a rm -fr > ~/.secondlife and run 2 was the same client started with previous run > .secondlife cache intact. > -------------------------------------------------------------- > Second Life 1.23.3 (122255) Jun 4 2009 15:43:30 (Second Life Release > Candidate) > Release Notes > > Built with GCC version 40303 > > You are at 219201.0, 296768.7, 38.0 in SkyBeam located at > sim3004.aditi.lindenlab.com (216.82.49.230:13002) > Second Life Beta Server 1.27.0.122984 > Release Notes > > CPU: AMD Phenom(tm) 9950 Quad-Core Processor > Memory: 8008 MB > OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue Jun 2 00:59:07 EDT > 2009 > x86_64 > Graphics Card Vendor: NVIDIA Corporation > Graphics Card: GeForce GTX 260/PCI/SSE2 > OpenGL Version: 3.0.0 NVIDIA 180.60 > > libcurl Version: libcurl/7.19.4 OpenSSL/0.9.8k zlib/1.2.3 libidn/1.15 > J2C Decoder Version: OpenJPEG: 1.3.0, Runtime: 1.3.0 > Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.7.411 / OpenAL Community > / > OpenAL Soft: ALSA Software > LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24566 (Mozilla GRE version > 1.8.1.21_0000000000) > Packets Lost: 0/665 (0.0%) > > Run 1 > 2009-06-11T12:42:04Z INFO: display_stats: FPS: 0.10 > 2009-06-11T12:42:13Z INFO: display_stats: FPS: 78.00 > 2009-06-11T12:42:23Z INFO: display_stats: FPS: 67.00 > 2009-06-11T12:42:33Z INFO: display_stats: FPS: 59.20 > 2009-06-11T12:42:43Z INFO: display_stats: FPS: 54.20 > 2009-06-11T12:42:53Z INFO: display_stats: FPS: 54.30 > 2009-06-11T12:43:03Z INFO: display_stats: FPS: 57.30 > 2009-06-11T12:43:13Z INFO: display_stats: FPS: 62.60 > 2009-06-11T12:43:23Z INFO: display_stats: FPS: 70.30 > 2009-06-11T12:43:33Z INFO: display_stats: FPS: 64.70 > 2009-06-11T12:43:44Z INFO: display_stats: FPS: 62.60 > 2009-06-11T12:43:54Z INFO: display_stats: FPS: 65.30 > 2009-06-11T12:44:04Z INFO: display_stats: FPS: 70.70 > 2009-06-11T12:44:14Z INFO: display_stats: FPS: 72.00 > 2009-06-11T12:44:24Z INFO: display_stats: FPS: 67.50 > 2009-06-11T12:44:34Z INFO: display_stats: FPS: 64.70 > 2009-06-11T12:44:44Z INFO: display_stats: FPS: 61.00 > 2009-06-11T12:44:54Z INFO: display_stats: FPS: 60.60 > 2009-06-11T12:45:04Z INFO: display_stats: FPS: 61.00 > 2009-06-11T12:45:14Z INFO: display_stats: FPS: 63.60 > 2009-06-11T12:45:24Z INFO: display_stats: FPS: 68.30 > 2009-06-11T12:45:34Z INFO: display_stats: FPS: 64.80 > 2009-06-11T12:45:44Z INFO: display_stats: FPS: 59.60 > 2009-06-11T12:45:54Z INFO: display_stats: FPS: 54.60 > 2009-06-11T12:46:04Z INFO: display_stats: FPS: 48.30 > 2009-06-11T12:46:14Z INFO: display_stats: FPS: 50.90 > > Run 2 > 2009-06-11T12:49:54Z INFO: display_stats: FPS: 0.10 > 2009-06-11T12:50:04Z INFO: display_stats: FPS: 74.40 > 2009-06-11T12:50:14Z INFO: display_stats: FPS: 67.00 > 2009-06-11T12:50:24Z INFO: display_stats: FPS: 62.10 > 2009-06-11T12:50:34Z INFO: display_stats: FPS: 59.00 > 2009-06-11T12:50:44Z INFO: display_stats: FPS: 59.90 > 2009-06-11T12:50:54Z INFO: display_stats: FPS: 62.70 > 2009-06-11T12:51:04Z INFO: display_stats: FPS: 70.90 > 2009-06-11T12:51:14Z INFO: display_stats: FPS: 73.50 > 2009-06-11T12:51:24Z INFO: display_stats: FPS: 64.00 > 2009-06-11T12:51:34Z INFO: display_stats: FPS: 65.90 > 2009-06-11T12:51:44Z INFO: display_stats: FPS: 72.50 > 2009-06-11T12:51:54Z INFO: display_stats: FPS: 69.10 > 2009-06-11T12:52:04Z INFO: display_stats: FPS: 70.80 > 2009-06-11T12:52:14Z INFO: display_stats: FPS: 71.40 > 2009-06-11T12:52:24Z INFO: display_stats: FPS: 64.70 > 2009-06-11T12:52:34Z INFO: display_stats: FPS: 64.90 > 2009-06-11T12:52:44Z INFO: display_stats: FPS: 65.70 > 2009-06-11T12:52:54Z INFO: display_stats: FPS: 58.20 > 2009-06-11T12:53:04Z INFO: display_stats: FPS: 65.30 > 2009-06-11T12:53:14Z INFO: display_stats: FPS: 65.10 > 2009-06-11T12:53:24Z INFO: display_stats: FPS: 63.40 > 2009-06-11T12:53:34Z INFO: display_stats: FPS: 59.40 > 2009-06-11T12:53:44Z INFO: display_stats: FPS: 52.00 > 2009-06-11T12:53:54Z INFO: display_stats: FPS: 48.30 > 2009-06-11T12:54:04Z INFO: display_stats: FPS: 47.30 > > --------------------------------------------------------------------------- > 1.22.11 (with ctrl-c bug, unable to copy about help) > > Run 1 > 2009-06-11T12:57:47Z INFO: display_stats: FPS: 44.48 > 2009-06-11T12:58:47Z INFO: display_stats: FPS: 58.90 > 2009-06-11T12:59:47Z INFO: display_stats: FPS: 60.25 > 2009-06-11T13:00:47Z INFO: display_stats: FPS: 61.30 > > Run 2 > 2009-06-11T13:03:41Z INFO: display_stats: FPS: 44.38 > 2009-06-11T13:04:41Z INFO: display_stats: FPS: 59.08 > 2009-06-11T13:05:41Z INFO: display_stats: FPS: 64.47 > 2009-06-11T13:06:41Z INFO: display_stats: FPS: 57.98 > > --------------------------------------------------------------------------- > Snowglobe 1.23.2 (121930) Jun 7 2009 14:56:10 (CommunityDeveloper) > Release Notes > > Built with GCC version 40303 > > You are at 219201.0, 296768.7, 38.0 in SkyBeam located at > sim3004.aditi.lindenlab.com (216.82.49.230:13002) > Second Life Beta Server 1.27.0.122984 > Release Notes > > CPU: AMD Phenom(tm) 9950 Quad-Core Processor > Memory: 8008 MB > OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue Jun 2 00:59:07 EDT > 2009 > x86_64 > Graphics Card Vendor: NVIDIA Corporation > Graphics Card: GeForce GTX 260/PCI/SSE2 > OpenGL Version: 3.0.0 NVIDIA 180.60 > > libcurl Version: libcurl/7.19.4 OpenSSL/0.9.8k zlib/1.2.3 libidn/1.15 > J2C Decoder Version: OpenJPEG: 1.3.0, Runtime: 1.3.0 > Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.7.411 / OpenAL Community > / > OpenAL Soft: ALSA Software > LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24567 (Mozilla GRE version > 1.8.1.21_0000000000) > > Run 1 > 2009-06-11T13:20:40Z INFO: display_stats: FPS: 0.10 > 2009-06-11T13:20:50Z INFO: display_stats: FPS: 72.50 > 2009-06-11T13:21:00Z INFO: display_stats: FPS: 72.50 > 2009-06-11T13:21:10Z INFO: display_stats: FPS: 66.60 > 2009-06-11T13:21:20Z INFO: display_stats: FPS: 63.80 > 2009-06-11T13:21:30Z INFO: display_stats: FPS: 61.40 > 2009-06-11T13:21:40Z INFO: display_stats: FPS: 64.10 > 2009-06-11T13:21:50Z INFO: display_stats: FPS: 68.30 > 2009-06-11T13:22:00Z INFO: display_stats: FPS: 69.20 > 2009-06-11T13:22:10Z INFO: display_stats: FPS: 69.30 > 2009-06-11T13:22:20Z INFO: display_stats: FPS: 64.70 > 2009-06-11T13:22:30Z INFO: display_stats: FPS: 68.80 > 2009-06-11T13:22:40Z INFO: display_stats: FPS: 76.80 > 2009-06-11T13:22:50Z INFO: display_stats: FPS: 87.30 > 2009-06-11T13:23:00Z INFO: display_stats: FPS: 87.40 > 2009-06-11T13:23:10Z INFO: display_stats: FPS: 70.30 > 2009-06-11T13:23:20Z INFO: display_stats: FPS: 65.30 > 2009-06-11T13:23:30Z INFO: display_stats: FPS: 66.70 > 2009-06-11T13:23:40Z INFO: display_stats: FPS: 66.70 > 2009-06-11T13:23:50Z INFO: display_stats: FPS: 66.40 > 2009-06-11T13:24:00Z INFO: display_stats: FPS: 100.60 > 2009-06-11T13:24:10Z INFO: display_stats: FPS: 71.90 > 2009-06-11T13:24:20Z INFO: display_stats: FPS: 65.30 > 2009-06-11T13:24:30Z INFO: display_stats: FPS: 59.80 > 2009-06-11T13:24:40Z INFO: display_stats: FPS: 55.70 > > Run 2 > 2009-06-11T13:26:29Z INFO: display_stats: FPS: 0.10 > 2009-06-11T13:26:38Z INFO: display_stats: FPS: 71.30 > 2009-06-11T13:26:48Z INFO: display_stats: FPS: 68.80 > 2009-06-11T13:26:58Z INFO: display_stats: FPS: 60.50 > 2009-06-11T13:27:08Z INFO: display_stats: FPS: 66.50 > 2009-06-11T13:27:18Z INFO: display_stats: FPS: 63.60 > 2009-06-11T13:27:28Z INFO: display_stats: FPS: 71.70 > 2009-06-11T13:27:38Z INFO: display_stats: FPS: 88.30 > 2009-06-11T13:27:48Z INFO: display_stats: FPS: 89.20 > 2009-06-11T13:27:58Z INFO: display_stats: FPS: 92.30 > 2009-06-11T13:28:08Z INFO: display_stats: FPS: 67.50 > 2009-06-11T13:28:18Z INFO: display_stats: FPS: 69.80 > 2009-06-11T13:28:28Z INFO: display_stats: FPS: 94.90 > 2009-06-11T13:28:38Z INFO: display_stats: FPS: 109.20 > 2009-06-11T13:28:48Z INFO: display_stats: FPS: 83.30 > 2009-06-11T13:28:58Z INFO: display_stats: FPS: 69.00 > 2009-06-11T13:29:08Z INFO: display_stats: FPS: 64.80 > 2009-06-11T13:29:18Z INFO: display_stats: FPS: 62.20 > 2009-06-11T13:29:29Z INFO: display_stats: FPS: 61.90 > 2009-06-11T13:29:39Z INFO: display_stats: FPS: 70.90 > 2009-06-11T13:29:49Z INFO: display_stats: FPS: 124.40 > 2009-06-11T13:29:59Z INFO: display_stats: FPS: 117.10 > 2009-06-11T13:30:09Z INFO: display_stats: FPS: 106.40 > 2009-06-11T13:30:19Z INFO: display_stats: FPS: 85.60 > 2009-06-11T13:30:29Z INFO: display_stats: FPS: 73.90 > -------------------------------------------------------------------------- > 1.22.11 LL bianary > > Run 1 > 2009-06-11T13:39:23Z INFO: display_stats: FPS: 47.98 > 2009-06-11T13:40:23Z INFO: display_stats: FPS: 58.83 > 2009-06-11T13:41:23Z INFO: display_stats: FPS: 61.90 > 2009-06-11T13:42:23Z INFO: display_stats: FPS: 60.53 > > Run 2 > 2009-06-11T13:44:24Z INFO: display_stats: FPS: 43.88 > 2009-06-11T13:45:24Z INFO: display_stats: FPS: 59.22 > 2009-06-11T13:46:24Z INFO: display_stats: FPS: 80.30 > 2009-06-11T13:47:24Z INFO: display_stats: FPS: 61.57 > ---------------------------------------------------------------------------- > Second Life 1.23.3 (122255) May 30 2009 13:26:56 (Second Life Release > Candidate) > Release Notes > > Built with GCC version 40102 > > You are at 219201.0, 296768.7, 38.0 in SkyBeam located at > sim3004.aditi.lindenlab.com (216.82.49.230:13002) > Second Life Beta Server 1.27.0.122984 > Release Notes > > CPU: AMD Phenom(tm) 9950 Quad-Core Processor > Memory: 8008 MB > OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue Jun 2 00:59:07 EDT > 2009 > x86_64 > Graphics Card Vendor: NVIDIA Corporation > Graphics Card: GeForce GTX 260/PCI/SSE2 > OpenGL Version: 3.0.0 NVIDIA 180.60 > > libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0 > J2C Decoder Version: KDU > Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: > ALSA Software on default > LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24568 (Mozilla GRE version > 1.8.1.18_0000000000) > > Run 1 > 2009-06-11T13:54:41Z INFO: display_stats: FPS: 0.10 > 2009-06-11T13:54:51Z INFO: display_stats: FPS: 68.80 > 2009-06-11T13:55:01Z INFO: display_stats: FPS: 66.40 > 2009-06-11T13:55:11Z INFO: display_stats: FPS: 63.70 > 2009-06-11T13:55:21Z INFO: display_stats: FPS: 62.50 > 2009-06-11T13:55:31Z INFO: display_stats: FPS: 58.40 > 2009-06-11T13:55:41Z INFO: display_stats: FPS: 63.60 > 2009-06-11T13:55:51Z INFO: display_stats: FPS: 68.00 > 2009-06-11T13:56:01Z INFO: display_stats: FPS: 73.10 > 2009-06-11T13:56:11Z INFO: display_stats: FPS: 67.60 > 2009-06-11T13:56:21Z INFO: display_stats: FPS: 65.40 > 2009-06-11T13:56:31Z INFO: display_stats: FPS: 69.40 > 2009-06-11T13:56:41Z INFO: display_stats: FPS: 74.10 > 2009-06-11T13:56:51Z INFO: display_stats: FPS: 73.40 > 2009-06-11T13:57:01Z INFO: display_stats: FPS: 70.50 > 2009-06-11T13:57:11Z INFO: display_stats: FPS: 67.30 > 2009-06-11T13:57:21Z INFO: display_stats: FPS: 64.30 > 2009-06-11T13:57:31Z INFO: display_stats: FPS: 63.60 > 2009-06-11T13:57:41Z INFO: display_stats: FPS: 64.70 > 2009-06-11T13:57:51Z INFO: display_stats: FPS: 64.10 > 2009-06-11T13:58:01Z INFO: display_stats: FPS: 69.10 > 2009-06-11T13:58:11Z INFO: display_stats: FPS: 67.30 > 2009-06-11T13:58:21Z INFO: display_stats: FPS: 62.10 > 2009-06-11T13:58:31Z INFO: display_stats: FPS: 54.60 > 2009-06-11T13:58:41Z INFO: display_stats: FPS: 53.50 > > Run 2 > 2009-06-11T13:59:39Z INFO: display_stats: FPS: 0.10 > 2009-06-11T13:59:49Z INFO: display_stats: FPS: 68.80 > 2009-06-11T13:59:59Z INFO: display_stats: FPS: 65.80 > 2009-06-11T14:00:09Z INFO: display_stats: FPS: 57.80 > 2009-06-11T14:00:19Z INFO: display_stats: FPS: 55.70 > 2009-06-11T14:00:29Z INFO: display_stats: FPS: 57.60 > 2009-06-11T14:00:39Z INFO: display_stats: FPS: 59.80 > 2009-06-11T14:00:49Z INFO: display_stats: FPS: 65.70 > 2009-06-11T14:00:59Z INFO: display_stats: FPS: 68.60 > 2009-06-11T14:01:09Z INFO: display_stats: FPS: 65.60 > 2009-06-11T14:01:19Z INFO: display_stats: FPS: 62.20 > 2009-06-11T14:01:29Z INFO: display_stats: FPS: 65.10 > 2009-06-11T14:01:39Z INFO: display_stats: FPS: 74.90 > 2009-06-11T14:01:49Z INFO: display_stats: FPS: 105.40 > 2009-06-11T14:01:59Z INFO: display_stats: FPS: 91.50 > 2009-06-11T14:02:09Z INFO: display_stats: FPS: 81.30 > 2009-06-11T14:02:19Z INFO: display_stats: FPS: 62.30 > 2009-06-11T14:02:29Z INFO: display_stats: FPS: 61.40 > 2009-06-11T14:02:39Z INFO: display_stats: FPS: 61.90 > 2009-06-11T14:02:49Z INFO: display_stats: FPS: 61.60 > 2009-06-11T14:02:59Z INFO: display_stats: FPS: 67.70 > 2009-06-11T14:03:09Z INFO: display_stats: FPS: 65.10 > 2009-06-11T14:03:19Z INFO: display_stats: FPS: 62.70 > 2009-06-11T14:03:29Z INFO: display_stats: FPS: 56.10 > 2009-06-11T14:03:39Z INFO: display_stats: FPS: 53.10 > ---------------------------------------------------------------------------- > Snowglobe 0.9.0 (2381) Jun 10 2009 15:33:48 (Snowglobe Test Build) > Release Notes > > Built with GCC version 40102 > > You are at 219201.0, 296768.7, 38.0 in SkyBeam located at > sim3004.aditi.lindenlab.com (216.82.49.230:13002) > Second Life Beta Server 1.27.0.122984 > Release Notes > > CPU: AMD Phenom(tm) 9950 Quad-Core Processor > Memory: 8008 MB > OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue Jun 2 00:59:07 EDT > 2009 > x86_64 > Graphics Card Vendor: NVIDIA Corporation > Graphics Card: GeForce GTX 260/PCI/SSE2 > OpenGL Version: 3.0.0 NVIDIA 180.60 > > libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0 > J2C Decoder Version: KDU > Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: > ALSA Software on default > LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24568 (Mozilla GRE version > 1.8.1.18_0000000000) > > Run 1 > 2009-06-11T14:10:47Z INFO: display_stats: FPS: 0.10 > 2009-06-11T14:10:57Z INFO: display_stats: FPS: 75.20 > 2009-06-11T14:11:07Z INFO: display_stats: FPS: 76.30 > 2009-06-11T14:11:17Z INFO: display_stats: FPS: 68.80 > 2009-06-11T14:11:27Z INFO: display_stats: FPS: 65.40 > 2009-06-11T14:11:37Z INFO: display_stats: FPS: 66.00 > 2009-06-11T14:11:47Z INFO: display_stats: FPS: 64.50 > 2009-06-11T14:11:57Z INFO: display_stats: FPS: 67.10 > 2009-06-11T14:12:07Z INFO: display_stats: FPS: 71.90 > 2009-06-11T14:12:17Z INFO: display_stats: FPS: 69.10 > 2009-06-11T14:12:27Z INFO: display_stats: FPS: 66.00 > 2009-06-11T14:12:37Z INFO: display_stats: FPS: 70.20 > 2009-06-11T14:12:47Z INFO: display_stats: FPS: 79.20 > 2009-06-11T14:12:57Z INFO: display_stats: FPS: 83.10 > 2009-06-11T14:13:07Z INFO: display_stats: FPS: 73.20 > 2009-06-11T14:13:17Z INFO: display_stats: FPS: 71.30 > 2009-06-11T14:13:27Z INFO: display_stats: FPS: 76.00 > 2009-06-11T14:13:37Z INFO: display_stats: FPS: 68.40 > 2009-06-11T14:13:48Z INFO: display_stats: FPS: 68.70 > 2009-06-11T14:13:58Z INFO: display_stats: FPS: 68.40 > 2009-06-11T14:14:08Z INFO: display_stats: FPS: 79.10 > 2009-06-11T14:14:18Z INFO: display_stats: FPS: 68.10 > 2009-06-11T14:14:28Z INFO: display_stats: FPS: 66.40 > 2009-06-11T14:14:38Z INFO: display_stats: FPS: 56.80 > 2009-06-11T14:14:48Z INFO: display_stats: FPS: 55.50 > > Run 2 > 2009-06-11T14:15:46Z INFO: display_stats: FPS: 0.10 > 2009-06-11T14:15:56Z INFO: display_stats: FPS: 79.60 > 2009-06-11T14:16:06Z INFO: display_stats: FPS: 76.30 > 2009-06-11T14:16:16Z INFO: display_stats: FPS: 63.20 > 2009-06-11T14:16:26Z INFO: display_stats: FPS: 75.90 > 2009-06-11T14:16:36Z INFO: display_stats: FPS: 79.10 > 2009-06-11T14:16:46Z INFO: display_stats: FPS: 79.10 > 2009-06-11T14:16:56Z INFO: display_stats: FPS: 105.60 > 2009-06-11T14:17:06Z INFO: display_stats: FPS: 104.60 > 2009-06-11T14:17:16Z INFO: display_stats: FPS: 91.30 > 2009-06-11T14:17:26Z INFO: display_stats: FPS: 84.90 > 2009-06-11T14:17:36Z INFO: display_stats: FPS: 81.20 > 2009-06-11T14:17:46Z INFO: display_stats: FPS: 103.00 > 2009-06-11T14:17:56Z INFO: display_stats: FPS: 106.00 > 2009-06-11T14:18:06Z INFO: display_stats: FPS: 102.90 > 2009-06-11T14:18:16Z INFO: display_stats: FPS: 92.80 > 2009-06-11T14:18:26Z INFO: display_stats: FPS: 73.40 > 2009-06-11T14:18:36Z INFO: display_stats: FPS: 62.90 > 2009-06-11T14:18:46Z INFO: display_stats: FPS: 65.60 > 2009-06-11T14:18:56Z INFO: display_stats: FPS: 87.40 > 2009-06-11T14:19:06Z INFO: display_stats: FPS: 110.60 > 2009-06-11T14:19:16Z INFO: display_stats: FPS: 83.90 > 2009-06-11T14:19:26Z INFO: display_stats: FPS: 71.30 > 2009-06-11T14:19:36Z INFO: display_stats: FPS: 60.20 > 2009-06-11T14:19:46Z INFO: display_stats: FPS: 59.70 > > > --Techwolf Lupindo > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From nexiim at googlemail.com Tue Jun 16 04:30:46 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Tue, 16 Jun 2009 12:30:46 +0100 Subject: [sldev] Attempting to build 1.23 In-Reply-To: <824c8ab70906160208p4f765b72t1506e0190a30cb4e@mail.gmail.com> References: <824c8ab70906160208p4f765b72t1506e0190a30cb4e@mail.gmail.com> Message-ID: <824c8ab70906160430mc8917bet5f513754ca15f83b@mail.gmail.com> Is Google Performance Tools library the culprit here? I can't seem to find a linker to it in my solution, neither does it appear in the install.xml/installed.xml. But there is a mention of the google-perftools license in the LICENSE-libraries-win32.txt file. Was this added recently and accidentally left out in the cmake files? On 6/16/09, Nexii Malthus wrote: > I'm getting a lot of external symbol errors, what libraries have been > changed in 1.23 after moving from 1.22? > > I have run cmake and all perfectly fine but it seems like I must be > missing some additional libraries or my libraries are older versions. > I have compiled the 1.22 client perfectly fine before but 1.23.4 has > stumped me. I'm unable to find any references on the wiki and I am > frankly just getting frustrated. Being able to compile 1.23 would help > me find the origin of mysterious crashes that occur on me with the > official client, as well as update my custom client to the new > codebase. > > For a full error list see the attachment in this forum post: > http://nexii.ordoimperialis.com/viewtopic.php?f=4&t=58 > > I have exhausted most of my options and a friend suggested it might be > that this is a library issue. > From brad at lindenlab.com Tue Jun 16 08:30:52 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Tue, 16 Jun 2009 11:30:52 -0400 Subject: [sldev] Attempting to build 1.23 In-Reply-To: <824c8ab70906160430mc8917bet5f513754ca15f83b@mail.gmail.com> References: <824c8ab70906160208p4f765b72t1506e0190a30cb4e@mail.gmail.com> <824c8ab70906160430mc8917bet5f513754ca15f83b@mail.gmail.com> Message-ID: <4A37BAAC.5040307@lindenlab.com> Google-perftools is intentionally not enabled in 1.23, but all of our other 3rd party libraries were rebuilt in preparation for it (or some other memory allocator that we may settle on in the future). So all of our library packages were replaced. We had been linking statically to the Microsoft C Runtime Library, but now we are linking dynamically. From your error messages it appears that this is your problem, it's failing to find symbols that are defined in the C Runtime Library, and it's warning that symbols imported from a dll are also defined inline. This likely means that some .obj files have not been rebuilt that need to be, and are still referring to the static CRT library. If you're building any 3rd party libs yourself, you will need to have this option (/MD) selected for all code linked into the viewer binary (it's under C++->Code Generation). If you're using our library packages specified in install.xml and downloaded automatically by cmake, then this should all "just work". Additionally you should make sure you're building from a clean checkout. Let me know if this doesn't fix it for you. -Brad Nexii Malthus wrote: > Is Google Performance Tools library the culprit here? I can't seem to > find a linker to it in my solution, neither does it appear in the > install.xml/installed.xml. But there is a mention of the > google-perftools license in the LICENSE-libraries-win32.txt file. Was > this added recently and accidentally left out in the cmake files? > > On 6/16/09, Nexii Malthus wrote: > >> I'm getting a lot of external symbol errors, what libraries have been >> changed in 1.23 after moving from 1.22? >> >> I have run cmake and all perfectly fine but it seems like I must be >> missing some additional libraries or my libraries are older versions. >> I have compiled the 1.22 client perfectly fine before but 1.23.4 has >> stumped me. I'm unable to find any references on the wiki and I am >> frankly just getting frustrated. Being able to compile 1.23 would help >> me find the origin of mysterious crashes that occur on me with the >> official client, as well as update my custom client to the new >> codebase. >> >> For a full error list see the attachment in this forum post: >> http://nexii.ordoimperialis.com/viewtopic.php?f=4&t=58 >> >> I have exhausted most of my options and a friend suggested it might be >> that this is a library issue. >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From robla at lindenlab.com Tue Jun 16 08:37:32 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 16 Jun 2009 08:37:32 -0700 Subject: [sldev] Patch review: more "Snowglobe"ification (SNOW-24) Message-ID: <4A37BC3C.8040102@lindenlab.com> Hi folks, A pretty simple patch to the installer is here: https://jira.secondlife.com/browse/SNOW-24 I'll check this in later today barring objections here. Rob From marinekelley at gmail.com Tue Jun 16 08:48:45 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Tue, 16 Jun 2009 17:48:45 +0200 Subject: [sldev] 1.23.4 released in a hurry ? Message-ID: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> Hi all, Sorry for making this message sound like a rant, but it seems that the RC viewer has finally gone gold... without any prior warning. As a result, a lot of people are now asking me when the compatible Restrained Life viewer will be out, while I have not even finished working on my latest version. I am now forced to release a half-done viewer (it is operational, it just doesn't have all the features that I had planned to add for 1.23) so that people can just keep using it. Even worse, the 1.22 series are not even available anymore, I guess because of the adult changes. In other words, the Restrained Life viewer is not compatible with anything for the next few hours, while people keep messaging me. In the future, like one week before a RC is released, can we please get some kind of clue so that custom viewer developers have time to react and make a smooth transition ? Thank you in advance, A suddenly very busy Marine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090616/9288427d/attachment.htm From khyota at redhyena.net Tue Jun 16 09:21:44 2009 From: khyota at redhyena.net (Khyota) Date: Tue, 16 Jun 2009 12:21:44 -0400 Subject: [sldev] Strange camera/avatar behavior in 1.23.4 on opensuse 11.1 In-Reply-To: <200906152144.22111.khyota@redhyena.net> References: <200906152144.22111.khyota@redhyena.net> Message-ID: <200906161221.44283.khyota@redhyena.net> On Monday 15 June 2009 9:44:21 you wrote: > Has anyone tried 1.23 yet? im having this weird issue whare the camera > appears to be stuck to my pelvis and is uncontrollable, but after > teleporting i can see myself with no avatar mesh. I could only repro it on > opensuse 11.1 x86_64, did not on windows xp or gentoo x86. > > see http://jira.secondlife.com/browse/VWR-14050 > > Thanks guys! Disregard this, i just needed to clear out my settings. lol From tom at streamsense.net Tue Jun 16 10:14:51 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue, 16 Jun 2009 18:14:51 +0100 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> Message-ID: <4A37D30B.7040400@streamsense.net> Hey, 1.23 seems to still have a lot of issues, group chat seems more broken than ever, crashes are very frequent and the nvidia driver crashes are back :( LL, please don't make this viewer compulsory for a while! ~T Marine Kelley wrote: > Hi all, > > Sorry for making this message sound like a rant, but it seems that the > RC viewer has finally gone gold... without any prior warning. As a > result, a lot of people are now asking me when the compatible > Restrained Life viewer will be out, while I have not even finished > working on my latest version. I am now forced to release a half-done > viewer (it is operational, it just doesn't have all the features that > I had planned to add for 1.23) so that people can just keep using it. > > Even worse, the 1.22 series are not even available anymore, I guess > because of the adult changes. In other words, the Restrained Life > viewer is not compatible with anything for the next few hours, while > people keep messaging me. > > In the future, like one week before a RC is released, can we please > get some kind of clue so that custom viewer developers have time to > react and make a smooth transition ? > > Thank you in advance, > A suddenly very busy Marine > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From tateru.nino at gmail.com Tue Jun 16 10:17:22 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed, 17 Jun 2009 03:17:22 +1000 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <4A37D30B.7040400@streamsense.net> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D30B.7040400@streamsense.net> Message-ID: <4A37D3A2.6040207@gmail.com> The group chat breakage was introduced server-side about a week or so ago. It's a new bug and particularly worse for large groups than any of the pre-existing issues. Not something to blame on the viewer. Thomas Grimshaw wrote: > Hey, > > 1.23 seems to still have a lot of issues, group chat seems more broken > than ever, crashes are very frequent and the nvidia driver crashes are > back :( > > LL, please don't make this viewer compulsory for a while! > > ~T > > Marine Kelley wrote: > >> Hi all, >> >> Sorry for making this message sound like a rant, but it seems that the >> RC viewer has finally gone gold... without any prior warning. As a >> result, a lot of people are now asking me when the compatible >> Restrained Life viewer will be out, while I have not even finished >> working on my latest version. I am now forced to release a half-done >> viewer (it is operational, it just doesn't have all the features that >> I had planned to add for 1.23) so that people can just keep using it. >> >> Even worse, the 1.22 series are not even available anymore, I guess >> because of the adult changes. In other words, the Restrained Life >> viewer is not compatible with anything for the next few hours, while >> people keep messaging me. >> >> In the future, like one week before a RC is released, can we please >> get some kind of clue so that custom viewer developers have time to >> react and make a smooth transition ? >> >> Thank you in advance, >> A suddenly very busy Marine >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090617/15930264/attachment.htm From tom at streamsense.net Tue Jun 16 10:18:11 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue, 16 Jun 2009 18:18:11 +0100 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <4A37D3A2.6040207@gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D30B.7040400@streamsense.net> <4A37D3A2.6040207@gmail.com> Message-ID: <4A37D3D3.9030305@streamsense.net> I'm aware of that, but it appears to have gotten even worse with the viewer update, sessions just will not connect. ~T Tateru Nino wrote: > The group chat breakage was introduced server-side about a week or so > ago. It's a new bug and particularly worse for large groups than any > of the pre-existing issues. Not something to blame on the viewer. > > Thomas Grimshaw wrote: >> Hey, >> >> 1.23 seems to still have a lot of issues, group chat seems more broken >> than ever, crashes are very frequent and the nvidia driver crashes are >> back :( >> >> LL, please don't make this viewer compulsory for a while! >> >> ~T >> >> Marine Kelley wrote: >> >>> Hi all, >>> >>> Sorry for making this message sound like a rant, but it seems that the >>> RC viewer has finally gone gold... without any prior warning. As a >>> result, a lot of people are now asking me when the compatible >>> Restrained Life viewer will be out, while I have not even finished >>> working on my latest version. I am now forced to release a half-done >>> viewer (it is operational, it just doesn't have all the features that >>> I had planned to add for 1.23) so that people can just keep using it. >>> >>> Even worse, the 1.22 series are not even available anymore, I guess >>> because of the adult changes. In other words, the Restrained Life >>> viewer is not compatible with anything for the next few hours, while >>> people keep messaging me. >>> >>> In the future, like one week before a RC is released, can we please >>> get some kind of clue so that custom viewer developers have time to >>> react and make a smooth transition ? >>> >>> Thank you in advance, >>> A suddenly very busy Marine >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > -- > Tateru Nino > http://dwellonit.taterunino.net/ > From brad at lindenlab.com Tue Jun 16 10:19:18 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Tue, 16 Jun 2009 13:19:18 -0400 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> Message-ID: <4A37D416.2010101@lindenlab.com> I'm not sure I understand what your complaint is. There's nothing blocking 1.22 viewers from logging in. Our policy for deprecating older viewers is described here: https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions Quite frankly if you're looking for "Some kind of clue" that a new viewer is going to be released, then IMHO you should treat our release of RC0 as that clue. We've been bad in previous releases by calling things that weren't even close to releasable quality "RC" viewers, but the 1.23 RC process is what we've been aiming for ever since we started doing Release Candidates. We're sorry if you've gotten used to us sucking, but this is one case where I'm glad to disappoint you. ;) -Brad Marine Kelley wrote: > Hi all, > > Sorry for making this message sound like a rant, but it seems that the > RC viewer has finally gone gold... without any prior warning. As a > result, a lot of people are now asking me when the compatible > Restrained Life viewer will be out, while I have not even finished > working on my latest version. I am now forced to release a half-done > viewer (it is operational, it just doesn't have all the features that > I had planned to add for 1.23) so that people can just keep using it. > > Even worse, the 1.22 series are not even available anymore, I guess > because of the adult changes. In other words, the Restrained Life > viewer is not compatible with anything for the next few hours, while > people keep messaging me. > > In the future, like one week before a RC is released, can we please > get some kind of clue so that custom viewer developers have time to > react and make a smooth transition ? > > Thank you in advance, > A suddenly very busy Marine > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From monkowsk at watson.ibm.com Tue Jun 16 10:41:26 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 16 Jun 2009 13:41:26 -0400 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> Message-ID: <4A37D946.30309@watson.ibm.com> In what way is the 1.22 series no longer available? And in what way is your viewer not compatible with anything? There was a notice in March https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions that said only the current version and one version back would be supported, with a 30 day phase out of the old release. I'm still able to run the 1.21 viewer, so it all looks like what was posted. And you can still get the old executables at http://wiki.secondlife.com/wiki/Old_versions Mike Marine Kelley wrote: > Even worse, the 1.22 series are not even available anymore, I guess > because of the adult changes. In other words, the Restrained Life viewer > is not compatible with anything for the next few hours, while people > keep messaging me. From nexiim at googlemail.com Tue Jun 16 11:24:33 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Tue, 16 Jun 2009 19:24:33 +0100 Subject: [sldev] Attempting to build 1.23 In-Reply-To: <4A37BAAC.5040307@lindenlab.com> References: <824c8ab70906160208p4f765b72t1506e0190a30cb4e@mail.gmail.com> <824c8ab70906160430mc8917bet5f513754ca15f83b@mail.gmail.com> <4A37BAAC.5040307@lindenlab.com> Message-ID: <824c8ab70906161124j536c814ctbb1681d53bf28f83@mail.gmail.com> Ahhh! Thank you so much, that explains it. It seems my copy of the windows platform SDK (Microsoft Platform SDK for Windows Server 2003 R2) doesn't have msvcrt.lib in the Lib folder, instead msvcrt.lib is only offered in the folders for the different architectures. Odd. -Nexii Malthus On Tue, Jun 16, 2009 at 4:30 PM, Brad Kittenbrink (Brad Linden) < brad at lindenlab.com> wrote: > Google-perftools is intentionally not enabled in 1.23, but all of our other > 3rd party libraries were rebuilt in preparation for it (or some other memory > allocator that we may settle on in the future). So all of our library > packages were replaced. > > We had been linking statically to the Microsoft C Runtime Library, but now > we are linking dynamically. > > From your error messages it appears that this is your problem, it's failing > to find symbols that are defined in the C Runtime Library, and it's warning > that symbols imported from a dll are also defined inline. This likely means > that some .obj files have not been rebuilt that need to be, and are still > referring to the static CRT library. > > If you're building any 3rd party libs yourself, you will need to have this > option (/MD) selected for all code linked into the viewer binary (it's under > C++->Code Generation). > If you're using our library packages specified in install.xml and > downloaded automatically by cmake, then this should all "just work". > Additionally you should make sure you're building from a clean checkout. > > Let me know if this doesn't fix it for you. > > -Brad > > > Nexii Malthus wrote: > >> Is Google Performance Tools library the culprit here? I can't seem to >> find a linker to it in my solution, neither does it appear in the >> install.xml/installed.xml. But there is a mention of the >> google-perftools license in the LICENSE-libraries-win32.txt file. Was >> this added recently and accidentally left out in the cmake files? >> >> On 6/16/09, Nexii Malthus wrote: >> >> >>> I'm getting a lot of external symbol errors, what libraries have been >>> changed in 1.23 after moving from 1.22? >>> >>> I have run cmake and all perfectly fine but it seems like I must be >>> missing some additional libraries or my libraries are older versions. >>> I have compiled the 1.22 client perfectly fine before but 1.23.4 has >>> stumped me. I'm unable to find any references on the wiki and I am >>> frankly just getting frustrated. Being able to compile 1.23 would help >>> me find the origin of mysterious crashes that occur on me with the >>> official client, as well as update my custom client to the new >>> codebase. >>> >>> For a full error list see the attachment in this forum post: >>> http://nexii.ordoimperialis.com/viewtopic.php?f=4&t=58 >>> >>> I have exhausted most of my options and a friend suggested it might be >>> that this is a library issue. >>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090616/b6e44f9b/attachment.htm From bogus@does.not.exist.com Fri Jun 12 11:19:36 2009 From: bogus@does.not.exist.com () Date: Fri, 12 Jun 2009 18:19:36 -0000 Subject: No subject Message-ID: ling to find symbols that are defined in the C Runtime Library, and it'= s warning that symbols imported from a dll are also defined inline. =A0This= likely means that some .obj files have not been rebuilt that need to be, a= nd are still referring to the static CRT library.

If you're building any 3rd party libs yourself, you will need to have t= his option (/MD) selected for all code linked into the viewer binary (it= 9;s under C++->Code Generation). =A0
If you're using our library packages specified in install.xml and downl= oaded automatically by cmake, then this should all "just work". A= dditionally you should make sure you're building from a clean checkout.=

Let me know if this doesn't fix it for you.

-Brad


Nexii Malthus wrote:
<= div class=3D"h5"> Is Google Performance Tools library the culprit here? I can't seem to find a linker to it in my solution, neither does it appear in the
install.xml/installed.xml. But there is a mention of the
google-perftools license in the LICENSE-libraries-win32.txt file. Was
this added recently and accidentally left out in the cmake files?

On 6/16/09, Nexii Malthus <nexiim at googlemail.com> wrote:
=A0
I'm getting a lot of external symbol errors, what libraries have been changed in 1.23 after moving from 1.22?

I have run cmake and all perfectly fine but it seems like I must be
missing some additional libraries or my libraries are older versions.
I have compiled the 1.22 client perfectly fine before but 1.23.4 has
stumped me. I'm unable to find any references on the wiki and I am
frankly just getting frustrated. Being able to compile 1.23 would help
me find the origin of mysterious crashes that occur on me with the
official client, as well as update my custom client to the new
codebase.

For a full error list see the attachment in this forum post:
http://nexii.ordoimperialis.com/viewtopic.php?f=3D4&t= =3D58

I have exhausted most of my options and a friend suggested it might be
that this is a library issue.

=A0 =A0
_______________________________________________
Policies and (un)subscribe information available here:
http://= wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privile= ges
=A0


--000e0cd28d144a4e59046c7b49e0-- From marinekelley at gmail.com Tue Jun 16 11:41:41 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Tue, 16 Jun 2009 20:41:41 +0200 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <4A37D946.30309@watson.ibm.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D946.30309@watson.ibm.com> Message-ID: <9e52a8c10906161141s551b9774re98e9adf2cc80a34@mail.gmail.com> Thanks for the link Mike, I didn't know that one (or I knew it and forgot). Brad, yes I know 1.22 can still connect, my problem is that it is not on the main download page anymore, and as the average user always downloads what is just released, they find themselves with libraries and settings file that are incompatible with the latest executable I produce, hence crash, complaints etc. Marine 2009/6/16 Mike Monkowski > In what way is the 1.22 series no longer available? And in what way is > your viewer not compatible with anything? > > There was a notice in March > https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versionsthat said only the current version and one version back would be supported, > with a 30 day phase out of the old release. I'm still able to run the 1.21 > viewer, so it all looks like what was posted. > > And you can still get the old executables at > http://wiki.secondlife.com/wiki/Old_versions > > Mike > > > Marine Kelley wrote: > >> Even worse, the 1.22 series are not even available anymore, I guess >> because of the adult changes. In other words, the Restrained Life viewer is >> not compatible with anything for the next few hours, while people keep >> messaging me. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090616/7e3479ed/attachment.htm From gigstaggart at gmail.com Tue Jun 16 12:03:46 2009 From: gigstaggart at gmail.com (Gigs) Date: Tue, 16 Jun 2009 15:03:46 -0400 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <9e52a8c10906161141s551b9774re98e9adf2cc80a34@mail.gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D946.30309@watson.ibm.com> <9e52a8c10906161141s551b9774re98e9adf2cc80a34@mail.gmail.com> Message-ID: <4A37EC92.5080907@gmail.com> Marine Kelley wrote: > Thanks for the link Mike, I didn't know that one (or I knew it and > forgot). > > Brad, yes I know 1.22 can still connect, my problem is that it is not > on the main download page anymore, and as the average user always > downloads what is just released, they find themselves with libraries > and settings file that are incompatible with the latest executable I > produce, hence crash, complaints etc. > So it's because you are doing an overlay. Well the simple answer is to stop relying on proprietary libraries. An alternative is what Boy Lane has done, where his installer will fetch the proprietary parts and install them for the user. You can probably use his code as well, I think it's freely available. -Jason From brad at lindenlab.com Tue Jun 16 12:09:09 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Tue, 16 Jun 2009 15:09:09 -0400 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <9e52a8c10906161141s551b9774re98e9adf2cc80a34@mail.gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D946.30309@watson.ibm.com> <9e52a8c10906161141s551b9774re98e9adf2cc80a34@mail.gmail.com> Message-ID: <4A37EDD5.7070305@lindenlab.com> Marine Kelley wrote: > Thanks for the link Mike, I didn't know that one (or I knew it and > forgot). > > Brad, yes I know 1.22 can still connect, my problem is that it is not > on the main download page anymore, and as the average user always > downloads what is just released, they find themselves with libraries > and settings file that are incompatible with the latest executable I > produce, hence crash, complaints etc. > > Marine If settings files are your concern, you should be packaging your viewer with "--settings settings_restrainedlife.xml" or something similar on the command line like we do for the release candidate viewers. Unfortunately I don't recall the specifics of how to configure this off the top of my head. We should work on getting this documented. I can't be sure how to address your library concerns without more details however. -Brad From nexiim at googlemail.com Tue Jun 16 12:34:52 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Tue, 16 Jun 2009 20:34:52 +0100 Subject: [sldev] Attempting to build 1.23 In-Reply-To: <824c8ab70906161124j536c814ctbb1681d53bf28f83@mail.gmail.com> References: <824c8ab70906160208p4f765b72t1506e0190a30cb4e@mail.gmail.com> <824c8ab70906160430mc8917bet5f513754ca15f83b@mail.gmail.com> <4A37BAAC.5040307@lindenlab.com> <824c8ab70906161124j536c814ctbb1681d53bf28f83@mail.gmail.com> Message-ID: <824c8ab70906161234s337bbd43l28eb049a3afca970@mail.gmail.com> Yeah, after some research it seems that .NET Framework SDK 1.1 installation is required to get the C Run-Time libraries. (Since my unstable connection makes it absolutely impossible to download the newer platform SDK which is 1GB, so I had to find alternative ways that don't require downloading 1GB off a slow microsoft server) Ugh, the .NET SDK is 100mb, that doesn't help much either.. Gotta hate the way microsoft does things. On Tue, Jun 16, 2009 at 7:24 PM, Nexii Malthus wrote: > Ahhh! Thank you so much, that explains it. > > It seems my copy of the windows platform SDK (Microsoft Platform SDK for > Windows Server 2003 R2) doesn't have msvcrt.lib in the Lib folder, instead > msvcrt.lib is only offered in the folders for the different architectures. > Odd. > > -Nexii Malthus > > > > On Tue, Jun 16, 2009 at 4:30 PM, Brad Kittenbrink (Brad Linden) < > brad at lindenlab.com> wrote: > >> Google-perftools is intentionally not enabled in 1.23, but all of our >> other 3rd party libraries were rebuilt in preparation for it (or some other >> memory allocator that we may settle on in the future). So all of our >> library packages were replaced. >> >> We had been linking statically to the Microsoft C Runtime Library, but now >> we are linking dynamically. >> >> From your error messages it appears that this is your problem, it's >> failing to find symbols that are defined in the C Runtime Library, and it's >> warning that symbols imported from a dll are also defined inline. This >> likely means that some .obj files have not been rebuilt that need to be, and >> are still referring to the static CRT library. >> >> If you're building any 3rd party libs yourself, you will need to have this >> option (/MD) selected for all code linked into the viewer binary (it's under >> C++->Code Generation). >> If you're using our library packages specified in install.xml and >> downloaded automatically by cmake, then this should all "just work". >> Additionally you should make sure you're building from a clean checkout. >> >> Let me know if this doesn't fix it for you. >> >> -Brad >> >> >> Nexii Malthus wrote: >> >>> Is Google Performance Tools library the culprit here? I can't seem to >>> find a linker to it in my solution, neither does it appear in the >>> install.xml/installed.xml. But there is a mention of the >>> google-perftools license in the LICENSE-libraries-win32.txt file. Was >>> this added recently and accidentally left out in the cmake files? >>> >>> On 6/16/09, Nexii Malthus wrote: >>> >>> >>>> I'm getting a lot of external symbol errors, what libraries have been >>>> changed in 1.23 after moving from 1.22? >>>> >>>> I have run cmake and all perfectly fine but it seems like I must be >>>> missing some additional libraries or my libraries are older versions. >>>> I have compiled the 1.22 client perfectly fine before but 1.23.4 has >>>> stumped me. I'm unable to find any references on the wiki and I am >>>> frankly just getting frustrated. Being able to compile 1.23 would help >>>> me find the origin of mysterious crashes that occur on me with the >>>> official client, as well as update my custom client to the new >>>> codebase. >>>> >>>> For a full error list see the attachment in this forum post: >>>> http://nexii.ordoimperialis.com/viewtopic.php?f=4&t=58 >>>> >>>> I have exhausted most of my options and a friend suggested it might be >>>> that this is a library issue. >>>> >>>> >>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090616/034e47b8/attachment.htm From bogus@does.not.exist.com Fri Jun 12 11:19:36 2009 From: bogus@does.not.exist.com () Date: Fri, 12 Jun 2009 18:19:36 -0000 Subject: No subject Message-ID: ling to find symbols that are defined in the C Runtime Library, and it'= s warning that symbols imported from a dll are also defined inline. =A0This= likely means that some .obj files have not been rebuilt that need to be, a= nd are still referring to the static CRT library.

If you're building any 3rd party libs yourself, you will need to have t= his option (/MD) selected for all code linked into the viewer binary (it= 9;s under C++->Code Generation). =A0
If you're using our library packages specified in install.xml and downl= oaded automatically by cmake, then this should all "just work". A= dditionally you should make sure you're building from a clean checkout.=

Let me know if this doesn't fix it for you.

-Brad


Nexii Malthus wrote:
<= div> Is Google Performance Tools library the culprit here? I can't seem to find a linker to it in my solution, neither does it appear in the
install.xml/installed.xml. But there is a mention of the
google-perftools license in the LICENSE-libraries-win32.txt file. Was
this added recently and accidentally left out in the cmake files?

On 6/16/09, Nexii Malthus <nexiim at googlemail.com> wrote:
=A0
I'm getting a lot of external symbol errors, what libraries have been changed in 1.23 after moving from 1.22?

I have run cmake and all perfectly fine but it seems like I must be
missing some additional libraries or my libraries are older versions.
I have compiled the 1.22 client perfectly fine before but 1.23.4 has
stumped me. I'm unable to find any references on the wiki and I am
frankly just getting frustrated. Being able to compile 1.23 would help
me find the origin of mysterious crashes that occur on me with the
official client, as well as update my custom client to the new
codebase.

For a full error list see the attachment in this forum post:
http://nexii.ordoimperialis.com/viewtopic.php?f=3D4&t= =3D58

I have exhausted most of my options and a friend suggested it might be
that this is a library issue.

=A0 =A0
_______________________________________________
Policies and (un)subscribe information available here:
http://= wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privile= ges
=A0



--000e0cd25048c153e9046c7c449c-- From sllists at boroon.dasgupta.ch Tue Jun 16 12:52:26 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue, 16 Jun 2009 21:52:26 +0200 Subject: [sldev] [HELP] Generating from HG repo fails Message-ID: <4A37F7FA.9070906@boroon.dasgupta.ch> When running cmake on a checkout of http://bitbucket.org/lindenlab/http-texture/ I get the following error: > [...] > -- Version of viewer is 1.23.2.122630 > -- Configuring done > CMake Error in newview/CMakeLists.txt: > Cannot find source file "panel_group_finder.xml". Tried extensions .c .C > .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx > > CMake Error in newview/CMakeLists.txt: > Cannot find source file "panel_group_voting.xml". Tried extensions .c .C > .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx This doesn't happen with https://svn.secondlife.com/svn/linden/projects/2009/http-texture which builds just fine. This is on gentoo linux with Unix Makefiles as CMake Generator. Has anyone else observed this? Is the HG repository missing files? cheers Boroondas From brad at lindenlab.com Tue Jun 16 12:57:17 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Tue, 16 Jun 2009 15:57:17 -0400 Subject: [sldev] Attempting to build 1.23 In-Reply-To: <824c8ab70906161234s337bbd43l28eb049a3afca970@mail.gmail.com> References: <824c8ab70906160208p4f765b72t1506e0190a30cb4e@mail.gmail.com> <824c8ab70906160430mc8917bet5f513754ca15f83b@mail.gmail.com> <4A37BAAC.5040307@lindenlab.com> <824c8ab70906161124j536c814ctbb1681d53bf28f83@mail.gmail.com> <824c8ab70906161234s337bbd43l28eb049a3afca970@mail.gmail.com> Message-ID: <4A37F91D.7010101@lindenlab.com> To my knowledge that shouldn't be necessary, although things may have changed recently with recent express versions of visual studio. Hopefully one of the following links should have the dlls you need(depending on your compiler version), but the .libs that reference them should have shipped with your visual studio version. http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A191EE&displaylang=en http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en -Brad Nexii Malthus wrote: > Yeah, after some research it seems that .NET Framework SDK 1.1 > installation is required to get the C Run-Time libraries. (Since my > unstable connection makes it absolutely impossible to download the > newer platform SDK which is 1GB, so I had to find alternative ways > that don't require downloading 1GB off a slow microsoft server) > > Ugh, the .NET SDK is 100mb, that doesn't help much either.. > Gotta hate the way microsoft does things. > > On Tue, Jun 16, 2009 at 7:24 PM, Nexii Malthus > wrote: > > Ahhh! Thank you so much, that explains it. > > It seems my copy of the windows platform SDK (Microsoft Platform > SDK for Windows Server 2003 R2) doesn't have msvcrt.lib in the Lib > folder, instead msvcrt.lib is only offered in the folders for the > different architectures. Odd. > > -Nexii Malthus > > > > On Tue, Jun 16, 2009 at 4:30 PM, Brad Kittenbrink (Brad Linden) > > wrote: > > Google-perftools is intentionally not enabled in 1.23, but all > of our other 3rd party libraries were rebuilt in preparation > for it (or some other memory allocator that we may settle on > in the future). So all of our library packages were replaced. > > We had been linking statically to the Microsoft C Runtime > Library, but now we are linking dynamically. > > From your error messages it appears that this is your problem, > it's failing to find symbols that are defined in the C Runtime > Library, and it's warning that symbols imported from a dll are > also defined inline. This likely means that some .obj files > have not been rebuilt that need to be, and are still referring > to the static CRT library. > > If you're building any 3rd party libs yourself, you will need > to have this option (/MD) selected for all code linked into > the viewer binary (it's under C++->Code Generation). > If you're using our library packages specified in install.xml > and downloaded automatically by cmake, then this should all > "just work". Additionally you should make sure you're building > from a clean checkout. > > Let me know if this doesn't fix it for you. > > -Brad > > > Nexii Malthus wrote: > > Is Google Performance Tools library the culprit here? I > can't seem to > find a linker to it in my solution, neither does it appear > in the > install.xml/installed.xml. But there is a mention of the > google-perftools license in the > LICENSE-libraries-win32.txt file. Was > this added recently and accidentally left out in the cmake > files? > > On 6/16/09, Nexii Malthus > wrote: > > > I'm getting a lot of external symbol errors, what > libraries have been > changed in 1.23 after moving from 1.22? > > I have run cmake and all perfectly fine but it seems > like I must be > missing some additional libraries or my libraries are > older versions. > I have compiled the 1.22 client perfectly fine before > but 1.23.4 has > stumped me. I'm unable to find any references on the > wiki and I am > frankly just getting frustrated. Being able to compile > 1.23 would help > me find the origin of mysterious crashes that occur on > me with the > official client, as well as update my custom client to > the new > codebase. > > For a full error list see the attachment in this forum > post: > http://nexii.ordoimperialis.com/viewtopic.php?f=4&t=58 > > > I have exhausted most of my options and a friend > suggested it might be > that this is a library issue. > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep > unmoderated posting privileges > > > > > From melinda at superliminal.com Tue Jun 16 14:34:43 2009 From: melinda at superliminal.com (Melinda Green) Date: Tue, 16 Jun 2009 14:34:43 -0700 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <4A37D416.2010101@lindenlab.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D416.2010101@lindenlab.com> Message-ID: <4A380FF3.8090005@superliminal.com> And there you have it folks: LL admits that they consistently suck! :-) Seriously though, great reply Brad. -Melinda Brad Kittenbrink (Brad Linden) wrote: > I'm not sure I understand what your complaint is. There's nothing > blocking 1.22 viewers from logging in. Our policy for deprecating older > viewers is described here: > https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions > > Quite frankly if you're looking for "Some kind of clue" that a new > viewer is going to be released, then IMHO you should treat our release > of RC0 as that clue. We've been bad in previous releases by calling > things that weren't even close to releasable quality "RC" viewers, but > the 1.23 RC process is what we've been aiming for ever since we started > doing Release Candidates. We're sorry if you've gotten used to us > sucking, but this is one case where I'm glad to disappoint you. ;) > > -Brad > > Marine Kelley wrote: > >> Hi all, >> >> Sorry for making this message sound like a rant, but it seems that the >> RC viewer has finally gone gold... without any prior warning. As a >> result, a lot of people are now asking me when the compatible >> Restrained Life viewer will be out, while I have not even finished >> working on my latest version. I am now forced to release a half-done >> viewer (it is operational, it just doesn't have all the features that >> I had planned to add for 1.23) so that people can just keep using it. >> >> Even worse, the 1.22 series are not even available anymore, I guess >> because of the adult changes. In other words, the Restrained Life >> viewer is not compatible with anything for the next few hours, while >> people keep messaging me. >> >> In the future, like one week before a RC is released, can we please >> get some kind of clue so that custom viewer developers have time to >> react and make a smooth transition ? >> >> Thank you in advance, >> A suddenly very busy Marine >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From monkowsk at watson.ibm.com Tue Jun 16 15:04:12 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 16 Jun 2009 18:04:12 -0400 Subject: [sldev] [HELP] Generating from HG repo fails In-Reply-To: <4A37F7FA.9070906@boroon.dasgupta.ch> References: <4A37F7FA.9070906@boroon.dasgupta.ch> Message-ID: <4A3816DC.6080509@watson.ibm.com> These XML files are usually located in indra/newview/skins/default/xui/en-us/ If I look in http://bitbucket.org/lindenlab/http-texture/ I see many XML files, but not these. If I look in https://svn.secondlife.com/svn/linden/projects/2009/http-texture I do find them. They are also not in the trunk, having been removed in r2126, 4/16/09, so I'm guessing that hg was updated from the trunk, not from http-texture. Mike Boroondas Gupte wrote: > When running cmake on a checkout of > http://bitbucket.org/lindenlab/http-texture/ I get the following error: > >>[...] >>-- Version of viewer is 1.23.2.122630 >>-- Configuring done >>CMake Error in newview/CMakeLists.txt: >> Cannot find source file "panel_group_finder.xml". Tried extensions .c .C >> .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx >> >>CMake Error in newview/CMakeLists.txt: >> Cannot find source file "panel_group_voting.xml". Tried extensions .c .C >> .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx > > This doesn't happen with > https://svn.secondlife.com/svn/linden/projects/2009/http-texture which > builds just fine. This is on gentoo linux with Unix Makefiles as CMake > Generator. > > Has anyone else observed this? Is the HG repository missing files? > > cheers > Boroondas > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From robla at lindenlab.com Tue Jun 16 19:10:20 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 16 Jun 2009 19:10:20 -0700 Subject: [sldev] SNOW-25: XUI updates for Snowglobe Message-ID: <4A38508C.7080505@lindenlab.com> Hi all, I did some XUI updates for Snowglobe, trying to zero in on just the strings that are viewer related (as opposed to referring to the Second Life service, website, or community, for example). Here's what I came up with: https://jira.secondlife.com/browse/SNOW-25 I'll check in the default/en-us version later tonight or tomorrow, then move onto the other directories after that if all goes well. Let me know if you see any mistakes there. Rob From danteferret at gmail.com Tue Jun 16 19:30:34 2009 From: danteferret at gmail.com (Dante Tucker) Date: Tue, 16 Jun 2009 22:30:34 -0400 Subject: [sldev] SNOW-25: XUI updates for Snowglobe In-Reply-To: <4A38508C.7080505@lindenlab.com> References: <4A38508C.7080505@lindenlab.com> Message-ID: <4d211a610906161930m1aa8efack94713ee423f510d2@mail.gmail.com> menu_login.xml: wrote: > Hi all, > > I did some XUI updates for Snowglobe, trying to zero in on just the > strings that are viewer related (as opposed to referring to the Second > Life service, website, or community, for example). Here's what I came > up with: > https://jira.secondlife.com/browse/SNOW-25 > > I'll check in the default/en-us version later tonight or tomorrow, then > move onto the other directories after that if all goes well. Let me > know if you see any mistakes there. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090616/1e64947a/attachment.htm From robla at lindenlab.com Tue Jun 16 22:28:05 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 16 Jun 2009 22:28:05 -0700 Subject: [sldev] SNOW-25: XUI updates for Snowglobe In-Reply-To: <4d211a610906161930m1aa8efack94713ee423f510d2@mail.gmail.com> References: <4A38508C.7080505@lindenlab.com> <4d211a610906161930m1aa8efack94713ee423f510d2@mail.gmail.com> Message-ID: <4A387EE5.9010009@lindenlab.com> On 06/16/2009 07:30 PM, Dante Tucker wrote: > menu_login.xml: height="19" label="Second Life Help" left="0" > > The help link leads to the support portal at secondlife.com > . I think it would be best to leave the string > that way. Anything else would not make sense, unless you plan to have > it not link to http://secondlife.com anymore. Yeah, I thought about that. My first edit said "Snowglobe Help", which, after using the menu, was a rather jarring experience to see the Second Life-branded stuff (which we won't be rebranding, because a lot of the content there is specific to the Second Life service). However, having just "Second Life Help" creates a different problem, which is that someone looking for help with Snowglobe might be inclined to overlook that. The compromise I ended up with was making the link say "Snowglobe/Second Life Help", since both viewer and service help are covered there. Anyway, we're pretty far into the weeds on this conversation for it to be something for this wide of a distribution. Let's have any further conversation here: https://jira.secondlife.com/browse/SNOW-25 Thanks for the careful reading of the issue, and the thoughtful feedback! Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090616/3f8e3438/attachment.htm From robla at lindenlab.com Wed Jun 17 00:54:40 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 17 Jun 2009 00:54:40 -0700 Subject: [sldev] Test sprint #2 this Thursday, 2pm PDT (regular OSS meeting time)? Message-ID: <4A38A140.7010601@lindenlab.com> Hi folks, We'd previously been aiming for a Thursday release of Snowglobe 1.0, but given that we're still checking in the last bits of code, that's looking less realistic as the day approaches. What we're much firmer on is getting an RC0 by the end of tomorrow. So, you'll see a few more checkins tomorrow as we get through the last few tweaks we'd like to make before sticking a fork in this and calling it done. The changes are bugfixes cherrypicked from 1.23 that happened since the last merge - mainly sticking with a couple of crash fixes, plus a fix for VWR-8818 (Texture Picker & People Chooser lags w/large inventory), and some fixes to the crash reporter. Anyway, the RC tomorrow is a true "release candidate". We haven't budgeted a lot of time for iteration, and we're eager to get this to a wider audience. Getting to the subject of this mail: let's make the Thursday OSS meeting about testing this viewer for general release by doing another test sprint. Then some time after that, we can go through the list of issues pretty carefully, and figure out if there's any seriously embarrassing issues that would stop us from putting this up. If not, we can make a call on when to declare it ready for primetime. If we're feeling really bold, the answer would be "let's put it up now!" Here's hoping we're ready for that! Rob From lenglish5 at cox.net Wed Jun 17 01:20:45 2009 From: lenglish5 at cox.net (Lawson English) Date: Wed, 17 Jun 2009 01:20:45 -0700 Subject: [sldev] [AWG] Transcripts of Tuesday's meeting Message-ID: <4A38A75D.1030205@cox.net> Rather meaty, I think: https://wiki.secondlife.com/wiki/AW_Groupies/Chat_Logs/AWGroupies-2009-06-16 Lawson From latifer at streamgrid.net Wed Jun 17 04:48:48 2009 From: latifer at streamgrid.net (Latif Khalifa) Date: Wed, 17 Jun 2009 13:48:48 +0200 Subject: [sldev] 1.23.4 released in a hurry ? In-Reply-To: <4A37D416.2010101@lindenlab.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D416.2010101@lindenlab.com> Message-ID: <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> On Tue, Jun 16, 2009 at 7:19 PM, Brad Kittenbrink (Brad Linden) wrote: > I'm not sure I understand what your complaint is. ?There's nothing > blocking 1.22 viewers from logging in. ?Our policy for deprecating older > viewers is described here: > https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions > > Quite frankly if you're looking for "Some kind of clue" that a new > viewer is going to be released, then IMHO you should treat our release > of RC0 as that clue. ?We've been bad in previous releases by calling > things that weren't even close to releasable quality "RC" viewers, but > the 1.23 RC process is what we've been aiming for ever since we started > doing Release Candidates. ?We're sorry if you've gotten used to us > sucking, but this is one case where I'm glad to disappoint you. ;) It really takes a brave man to claim 1.23RC4 and now production 1.24.4 "releasable quality". Is that why comments were closed after a few dozen or so on the blog post announcing the new viewer? From q at lindenlab.com Wed Jun 17 06:35:48 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 17 Jun 2009 09:35:48 -0400 Subject: [sldev] 1.23.4 released in a hurry ? NO. In-Reply-To: <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com><4A37D416.2010101@lindenlab.com> <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> Message-ID: On Jun 17, 2009, at 7:48 AM, Latif Khalifa wrote: > On Tue, Jun 16, 2009 at 7:19 PM, Brad Kittenbrink (Brad > Linden) wrote: >> I'm not sure I understand what your complaint is. There's nothing >> blocking 1.22 viewers from logging in. Our policy for deprecating >> older >> viewers is described here: >> https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions >> >> Quite frankly if you're looking for "Some kind of clue" that a new >> viewer is going to be released, then IMHO you should treat our >> release >> of RC0 as that clue. We've been bad in previous releases by calling >> things that weren't even close to releasable quality "RC" viewers, >> but >> the 1.23 RC process is what we've been aiming for ever since we >> started >> doing Release Candidates. We're sorry if you've gotten used to us >> sucking, but this is one case where I'm glad to disappoint you. ;) > > It really takes a brave man to claim 1.23RC4 and now production 1.24.4 > "releasable quality". Is that why comments were closed after a few > dozen or so on the blog post announcing the new viewer? I absolutely claim that 1.23 is not only of releasable quality, but the best viewer we've ever shipped. It met its design goals on RC1. The bugs that were found and fixed in the next 3 RCs were minimal. On a global statistics level, the crash rates are lower than they've ever been, even when you include crashes caused by specific video cards. There are some individuals who are upset about some of the design decisions, like the redesign of pie menus. That's not a quality issue. There are other individuals who are upset about some of the technical decisions, such as the imposition of rendering limits where we never had them before. That's not a quality issue either. And there are people who don't like the new Adult-Only stuff. That's also not a quality issue. The definition of quality is meeting the specification. We executed on this viewer better than we've ever done it before, and I'm pretty proud of our team for doing it. By the way, contrary to the implication in the subject line, we released 1.23.4 almost exactly according to the schedule I announced internally in February. The internal decision to ship was based on quality. As every professional software organization does, for every open issue we balance the risk of shipping a product with that issue against the risk of trying to fix it. When all the risks of shipping are lower than the risks of fixing, we ship it. Which is what we did with RC4. Q From gretzky.harleen at gmail.com Wed Jun 17 07:02:27 2009 From: gretzky.harleen at gmail.com (Harleen Gretzky) Date: Wed, 17 Jun 2009 10:02:27 -0400 Subject: [sldev] Rendering Limits Message-ID: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> Can you elaborate on what the new rendering limits are? On Wed, Jun 17, 2009 at 9:35 AM, Kent Quirk (Q Linden) wrote: > > > I absolutely claim that 1.23 is not only of releasable quality, but > the best viewer we've ever shipped. It met its design goals on RC1. > The bugs that were found and fixed in the next 3 RCs were minimal. On > a global statistics level, the crash rates are lower than they've ever > been, even when you include crashes caused by specific video cards. > > There are some individuals who are upset about some of the design > decisions, like the redesign of pie menus. That's not a quality issue. > There are other individuals who are upset about some of the technical > decisions, such as the imposition of rendering limits where we never > had them before. That's not a quality issue either. And there are > people who don't like the new Adult-Only stuff. That's also not a > quality issue. > > The definition of quality is meeting the specification. We executed on > this viewer better than we've ever done it before, and I'm pretty > proud of our team for doing it. > > By the way, contrary to the implication in the subject line, we > released 1.23.4 almost exactly according to the schedule I announced > internally in February. The internal decision to ship was based on > quality. As every professional software organization does, for every > open issue we balance the risk of shipping a product with that issue > against the risk of trying to fix it. When all the risks of shipping > are lower than the risks of fixing, we ship it. Which is what we did > with RC4. > > Q > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090617/51100a83/attachment-0001.htm From missannotoole at yahoo.com Wed Jun 17 07:01:27 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed, 17 Jun 2009 07:01:27 -0700 (PDT) Subject: [sldev] 1.23.4 released in a hurry ? NO. In-Reply-To: References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com><4A37D416.2010101@lindenlab.com> <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> Message-ID: <555577.29496.qm@web59108.mail.re1.yahoo.com> I'm surprised protests are being tolerated in this mailing list. As for the rendering limits that were put in you can override them as an option. If your frame rate suffers because of your system configuration then it is your choice. Frankly I don't even consider frame rates in the SL viewer to even matter since you are not getting server frame rates above 45 anyway. In order to record cinema quality video the SL frame rate would have to be above 60 FPS to accommodate the recording overhead to get to the ~30 FPS needed. If people want to dispute the release then they need to apply pressure to the executive level of Linden Research Inc. Not the SLDEV mailing list. IMHO anyway. ________________________________ From: Kent Quirk (Q Linden) To: Latif Khalifa Cc: sldev Sent: Wednesday, June 17, 2009 9:35:48 AM Subject: Re: [sldev] 1.23.4 released in a hurry ? NO. On Jun 17, 2009, at 7:48 AM, Latif Khalifa wrote: > On Tue, Jun 16, 2009 at 7:19 PM, Brad Kittenbrink (Brad > Linden) wrote: >> I'm not sure I understand what your complaint is. There's nothing >> blocking 1.22 viewers from logging in. Our policy for deprecating >> older >> viewers is described here: >> https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions >> >> Quite frankly if you're looking for "Some kind of clue" that a new >> viewer is going to be released, then IMHO you should treat our >> release >> of RC0 as that clue. We've been bad in previous releases by calling >> things that weren't even close to releasable quality "RC" viewers, >> but >> the 1.23 RC process is what we've been aiming for ever since we >> started >> doing Release Candidates. We're sorry if you've gotten used to us >> sucking, but this is one case where I'm glad to disappoint you. ;) > > It really takes a brave man to claim 1.23RC4 and now production 1.24.4 > "releasable quality". Is that why comments were closed after a few > dozen or so on the blog post announcing the new viewer? I absolutely claim that 1.23 is not only of releasable quality, but the best viewer we've ever shipped. It met its design goals on RC1. The bugs that were found and fixed in the next 3 RCs were minimal. On a global statistics level, the crash rates are lower than they've ever been, even when you include crashes caused by specific video cards. There are some individuals who are upset about some of the design decisions, like the redesign of pie menus. That's not a quality issue. There are other individuals who are upset about some of the technical decisions, such as the imposition of rendering limits where we never had them before. That's not a quality issue either. And there are people who don't like the new Adult-Only stuff. That's also not a quality issue. The definition of quality is meeting the specification. We executed on this viewer better than we've ever done it before, and I'm pretty proud of our team for doing it. By the way, contrary to the implication in the subject line, we released 1.23.4 almost exactly according to the schedule I announced internally in February. The internal decision to ship was based on quality. As every professional software organization does, for every open issue we balance the risk of shipping a product with that issue against the risk of trying to fix it. When all the risks of shipping are lower than the risks of fixing, we ship it. Which is what we did with RC4. Q _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090617/01dbc90c/attachment.htm From gretzky.harleen at gmail.com Wed Jun 17 07:18:37 2009 From: gretzky.harleen at gmail.com (Harleen Gretzky) Date: Wed, 17 Jun 2009 10:18:37 -0400 Subject: [sldev] 1.23.4 released in a hurry ? NO. In-Reply-To: <555577.29496.qm@web59108.mail.re1.yahoo.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D416.2010101@lindenlab.com> <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> <555577.29496.qm@web59108.mail.re1.yahoo.com> Message-ID: <5c63fe8c0906170718q2cee8ddeue06f0ae02afda860@mail.gmail.com> How do you override them? On Wed, Jun 17, 2009 at 10:01 AM, Ann Otoole wrote: > I'm surprised protests are being tolerated in this mailing list. > > As for the rendering limits that were put in you can override them as an > option. If your frame rate suffers because of your system configuration then > it is your choice. Frankly I don't even consider frame rates in the SL > viewer to even matter since you are not getting server frame rates above 45 > anyway. In order to record cinema quality video the SL frame rate would have > to be above 60 FPS to accommodate the recording overhead to get to the ~30 > FPS needed. > > If people want to dispute the release then they need to apply pressure to > the executive level of Linden Research Inc. Not the SLDEV mailing list. IMHO > anyway. > > ------------------------------ > *From:* Kent Quirk (Q Linden) > *To:* Latif Khalifa > *Cc:* sldev > *Sent:* Wednesday, June 17, 2009 9:35:48 AM > *Subject:* Re: [sldev] 1.23.4 released in a hurry ? NO. > > > On Jun 17, 2009, at 7:48 AM, Latif Khalifa wrote: > > > On Tue, Jun 16, 2009 at 7:19 PM, Brad Kittenbrink (Brad > > Linden) wrote: > >> I'm not sure I understand what your complaint is. There's nothing > >> blocking 1.22 viewers from logging in. Our policy for deprecating > >> older > >> viewers is described here: > >> > https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions > >> > >> Quite frankly if you're looking for "Some kind of clue" that a new > >> viewer is going to be released, then IMHO you should treat our > >> release > >> of RC0 as that clue. We've been bad in previous releases by calling > >> things that weren't even close to releasable quality "RC" viewers, > >> but > >> the 1.23 RC process is what we've been aiming for ever since we > >> started > >> doing Release Candidates. We're sorry if you've gotten used to us > >> sucking, but this is one case where I'm glad to disappoint you. ;) > > > > It really takes a brave man to claim 1.23RC4 and now production 1.24.4 > > "releasable quality". Is that why comments were closed after a few > > dozen or so on the blog post announcing the new viewer? > > > I absolutely claim that 1.23 is not only of releasable quality, but > the best viewer we've ever shipped. It met its design goals on RC1. > The bugs that were found and fixed in the next 3 RCs were minimal. On > a global statistics level, the crash rates are lower than they've ever > been, even when you include crashes caused by specific video cards. > > There are some individuals who are upset about some of the design > decisions, like the redesign of pie menus. That's not a quality issue. > There are other individuals who are upset about some of the technical > decisions, such as the imposition of rendering limits where we never > had them before. That's not a quality issue either. And there are > people who don't like the new Adult-Only stuff. That's also not a > quality issue. > > The definition of quality is meeting the specification. We executed on > this viewer better than we've ever done it before, and I'm pretty > proud of our team for doing it. > > By the way, contrary to the implication in the subject line, we > released 1.23.4 almost exactly according to the schedule I announced > internally in February. The internal decision to ship was based on > quality. As every professional software organization does, for every > open issue we balance the risk of shipping a product with that issue > against the risk of trying to fix it. When all the risks of shipping > are lower than the risks of fixing, we ship it. Which is what we did > with RC4. > > Q > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090617/f852420d/attachment.htm From open at autistici.org Wed Jun 17 07:34:57 2009 From: open at autistici.org (Opensource Obscure) Date: Wed, 17 Jun 2009 14:34:57 +0000 Subject: [sldev] =?utf-8?q?1=2E23=2E4_released_in_a_hurry_=3F?= In-Reply-To: <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D416.2010101@lindenlab.com> <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> Message-ID: <4b1b72a0814623bbd7253612f4e726b8@localhost> On Wed, 17 Jun 2009 13:48:48 +0200, Latif Khalifa wrote: > Is that why comments were closed after a few > dozen or so on the blog post announcing the new viewer? Comments are open. They were moved -with a bit of lag in the process- to a separate page, as usual in the new blogs setup: https://blogs.secondlife.com/thread/1461 Tip: when I saw that comments were closed, I wrote an email to the LL employee who had written the post - after a few hours, I got a reply with an explanation and some details. bye Opensource Obscure From missannotoole at yahoo.com Wed Jun 17 07:38:13 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed, 17 Jun 2009 07:38:13 -0700 (PDT) Subject: [sldev] 1.23.4 released in a hurry ? NO. In-Reply-To: <5c63fe8c0906170718q2cee8ddeue06f0ae02afda860@mail.gmail.com> References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D416.2010101@lindenlab.com> <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> <555577.29496.qm@web59108.mail.re1.yahoo.com> <5c63fe8c0906170718q2cee8ddeue06f0ae02afda860@mail.gmail.com> Message-ID: <52680.20660.qm@web59107.mail.re1.yahoo.com> raise debug setting renderMaxNodeSize above 4096 (default). I use 8192 without any discernible difference on my nVidia 8500GT on 4GB ram/Vista64/quad core. Your system configuration will determine if you can have an acceptable experience with increased vertices. In addition it seems to only kick in and matter when zoomed on my machine. I do wonder if the widespread reports of avatars no longer rendering are related. But I have seen that in some regions for over a year so how could it be related to this new tiny code addition? Sheet Spotter is the person that found the change: -------------------- Sheet Spotter commented on VWR-13868: ------------------------------------- There are 173 prims in the necklace placed at secondlife://Hippotropolis/238/28/23 and most of the prims are detailed, high resolution sculpties. The large number of highly detailed sculpties has exceeded a recently added limit on the maximum number of vertices that the rendering engine will process. When the limit is exceeded, the renderer stops rendering any later vertices. The skip vertices could be from the same object or any other object in the scene. Aside: vertices are the "corners" of all the prims we normally talk about. High resolution sculpties have more vertices than most other prim types, so the issue may be more noticeable with sculpties. The workaround for this problem is to reduce the number of high resolution scrulpties, or to adjust one of the debug settings "renderMaxNodeSize". The default value of 4096 for renderMaxNodeSize causes some portions of the necklace to disappear when zoomed. Incresing this value above 6000 displayed all the elements of the necklace. (You might have to wait up to 30 seconds after adjusting the value to see any effect. Be patient.) Referring to the source code for the viewer...The following lines were added to the "LLVolumeGeometryManager::rebuildGeom" method in the "indra/newview/llvovolume.cpp" source file between revision 1760 and 1817. if (cur_total > max_total) { facep->mVertexBuffer = NULL; facep->mLastVertexBuffer = NULL; continue; } When the limit set by renderMaxNodeSize is exceeded these statements cause the renderer to skip the processing of any later prims. The skipped prims could be from the same object or any other object within the scene. ---------------------- On to tangentally related observations: More worrisome is how the public nightly build shows texture 8b8ee746-d658-1a93-065a-3ed78bc20961 8 * 8 pixels black) as a 1024*1024 semi transparent texture. How does one viewer show an asset as 8*8 black and another viewer show the exact same asset as a 1024*1024 semi transparent texture? This sort of defect seems to be capable of catastphic damages. I specifically use this 8*8 to reduce rendering overhead on the majority of faces in a build. To see the most efficient texture asset possible get changed to the worst possible resolution with alpha is absolutely astounding. Anyway I'm happy Q thinks they improved their processes. We all know and have complained loudly about the apparent lack of methodologies and procedures at LL so if they are improving that aspect it can only lead to good down the road. One step forward at a time. ________________________________ From: Harleen Gretzky To: Ann Otoole Cc: sldev at lists.secondlife.com Sent: Wednesday, June 17, 2009 10:18:37 AM Subject: Re: [sldev] 1.23.4 released in a hurry ? NO. How do you override them? On Wed, Jun 17, 2009 at 10:01 AM, Ann Otoole wrote: I'm surprised protests are being tolerated in this mailing list. As for the rendering limits that were put in you can override them as an option. If your frame rate suffers because of your system configuration then it is your choice. Frankly I don't even consider frame rates in the SL viewer to even matter since you are not getting server frame rates above 45 anyway. In order to record cinema quality video the SL frame rate would have to be above 60 FPS to accommodate the recording overhead to get to the ~30 FPS needed. If people want to dispute the release then they need to apply pressure to the executive level of Linden Research Inc. Not the SLDEV mailing list. IMHO anyway. ________________________________ From: Kent Quirk (Q Linden) To: Latif Khalifa Cc: sldev Sent: Wednesday, June 17, 2009 9:35:48 AM Subject: Re: [sldev] 1.23.4 released in a hurry ? NO. On Jun 17, 2009, at 7:48 AM, Latif Khalifa wrote: > On Tue, Jun 16, 2009 at 7:19 PM, Brad Kittenbrink (Brad > Linden) wrote: >> I'm not sure I understand what your complaint is. There's nothing >> blocking 1.22 viewers from logging in. Our policy for deprecating >> older >> viewers is described here: >> https://blogs.secondlife.com/community/technology/blog/2009/03/09/supported-viewer-versions >> >> Quite frankly if you're looking for "Some kind of clue" that a new >> viewer is going to be released, then IMHO you should treat our >> release >> of RC0 as that clue. We've been bad in previous releases by calling >> things that weren't even close to releasable quality "RC" viewers, >> but >> the 1.23 RC process is what we've been aiming for ever since we >> started >> doing Release Candidates. We're sorry if you've gotten used to us >> sucking, but this is one case where I'm glad to disappoint you. ;) > > It really takes a brave man to claim 1.23RC4 and now production 1.24.4 > "releasable quality". Is that why comments were closed after a few > dozen or so on the blog post announcing the new viewer? I absolutely claim that 1.23 is not only of releasable quality, but the best viewer we've ever shipped. It met its design goals on RC1. The bugs that were found and fixed in the next 3 RCs were minimal. On a global statistics level, the crash rates are lower than they've ever been, even when you include crashes caused by specific video cards. There are some individuals who are upset about some of the design decisions, like the redesign of pie menus. That's not a quality issue. There are other individuals who are upset about some of the technical decisions, such as the imposition of rendering limits where we never had them before. That's not a quality issue either. And there are people who don't like the new Adult-Only stuff. That's also not a quality issue. The definition of quality is meeting the specification. We executed on this viewer better than we've ever done it before, and I'm pretty proud of our team for doing it. By the way, contrary to the implication in the subject line, we released 1.23.4 almost exactly according to the schedule I announced internally in February. The internal decision to ship was based on quality. As every professional software organization does, for every open issue we balance the risk of shipping a product with that issue against the risk of trying to fix it. When all the risks of shipping are lower than the risks of fixing, we ship it. Which is what we did with RC4. Q _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090617/8be8e60b/attachment-0001.htm From latifer at streamgrid.net Wed Jun 17 11:01:47 2009 From: latifer at streamgrid.net (Latif Khalifa) Date: Wed, 17 Jun 2009 20:01:47 +0200 Subject: [sldev] 1.23.4 released in a hurry ? NO. In-Reply-To: References: <9e52a8c10906160848m764155ecl58983f6ce0b31906@mail.gmail.com> <4A37D416.2010101@lindenlab.com> <5ebce2ec0906170448g5b10c0fs582077f9686466d3@mail.gmail.com> Message-ID: <5ebce2ec0906171101r21dd4bc0n1a3143788cee4bdd@mail.gmail.com> > I absolutely claim that 1.23 is not only of releasable quality, but the best > viewer we've ever shipped. It met its design goals on RC1. The bugs that > were found and fixed in the next 3 RCs were minimal. On a global statistics > level, the crash rates are lower than they've ever been, even when you > include crashes caused by specific video cards. > > There are some individuals who are upset about some of the design decisions, > like the redesign of pie menus. That's not a quality issue. There are other > individuals who are upset about some of the technical decisions, such as the > imposition of rendering limits where we never had them before. That's not a > quality issue either. And there are people who don't like the new Adult-Only > stuff. That's also not a quality issue. > > The definition of quality is meeting the specification. We executed on this > viewer better than we've ever done it before, and I'm pretty proud of our > team for doing it. > > By the way, contrary to the implication in the subject line, we released > 1.23.4 almost exactly according to the schedule I announced internally in > February. The internal decision to ship was based on quality. As every > professional software organization does, for every open issue we balance the > risk of shipping a product with that issue against the risk of trying to fix > it. When all the risks of shipping are lower than the risks of fixing, we > ship it. Which is what we did with RC4. Yes, it was released exactly on schedule. And it was released despite many reports about fresh new bugs discovered during the public RC process. Issues like VWR-12984 which makes doing anything in a skybox or a build platform unbearable with 1.23. Issue reported back in April with included snapshots and videos for easy repro. It was released despite wide-spread problems with avatar rendering making nearby avatars become fully or partially invisible (VWR-12906), issue that was reproduced during a bug triage with 5 Lindens in attendance. Or avatars all of a sudden becoming "cloud ghosts" when they attempt to change outfit (VWR-12934 which claims to be fixed, but its not). Or issues that you claim to be working as expected (VWR-13868) where prims you deem to complex to render simply vanish from the view when zooming instead of degrading their rendering quality if they're causing trouble. From user perspective this is always a bug despite fancy technical rationalizations why it is not. So if by quality you mean "released on schedule", then sure, this is high quality release indeed. -- L From boy.lane at yahoo.com Wed Jun 17 11:51:48 2009 From: boy.lane at yahoo.com (Boy Lane) Date: Thu, 18 Jun 2009 02:51:48 +0800 Subject: [sldev] 1.23.4 released in a hurry ? NO. References: Message-ID: <002401c9ef7c$ac75bc30$0600a8c0@hp> That's absolutely the most ever single bullsh*t posting I've read on this mailing list. 1.23.4 is the worst viewer ever, it did not fix most of existing bugs but introduced tons of new ones. LL did not respond to most of important user concerns but ignored them, as in the past. And you guys are proud to follow your new release policy by pushing unfinished software out to users for nothing but political reasons. Shame on you Linden Lab! Boy Lane > Message: 7 > Date: Wed, 17 Jun 2009 09:35:48 -0400 > From: "Kent Quirk (Q Linden)" > Subject: Re: [sldev] 1.23.4 released in a hurry ? NO. > To: Latif Khalifa > Cc: sldev > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > I absolutely claim that 1.23 is not only of releasable quality, but > the best viewer we've ever shipped. It met its design goals on RC1. > The bugs that were found and fixed in the next 3 RCs were minimal. On > a global statistics level, the crash rates are lower than they've ever > been, even when you include crashes caused by specific video cards. > > There are some individuals who are upset about some of the design > decisions, like the redesign of pie menus. That's not a quality issue. > There are other individuals who are upset about some of the technical > decisions, such as the imposition of rendering limits where we never > had them before. That's not a quality issue either. And there are > people who don't like the new Adult-Only stuff. That's also not a > quality issue. > > The definition of quality is meeting the specification. We executed on > this viewer better than we've ever done it before, and I'm pretty > proud of our team for doing it. > > By the way, contrary to the implication in the subject line, we > released 1.23.4 almost exactly according to the schedule I announced > internally in February. The internal decision to ship was based on > quality. As every professional software organization does, for every > open issue we balance the risk of shipping a product with that issue > against the risk of trying to fix it. When all the risks of shipping > are lower than the risks of fixing, we ship it. Which is what we did > with RC4. > > Q From q at lindenlab.com Wed Jun 17 12:31:49 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed, 17 Jun 2009 15:31:49 -0400 Subject: [sldev] 1.23.4 released in a hurry ? NO. In-Reply-To: <002401c9ef7c$ac75bc30$0600a8c0@hp> References: <002401c9ef7c$ac75bc30$0600a8c0@hp> Message-ID: <0E2C0E8B-0208-41D9-85BE-E5C31BA4648A@lindenlab.com> Ouch. Ya know, I'm trying really hard to be polite and rational and explain the reasons behind what we do. I tried to show that we actually have a professional development organization with a process. We've documented what we fixed and what we changed. Perhaps you forget that we serve about a million customers a month. Almost a million of them are not you. From all the tracking data we have, I can objectively see that over hundreds of thousands of sessions, this is the most stable viewer we've ever shipped. I hope that over the next several weeks, we'll even see a small uptick in new users and retained users who find the viewer easier to use and more understandable because of the changes we've made. I will admit that your personal experience may in fact be worse. And if that's the case, I'm sorry. Sadly, we can't code Second Life individually for each user. For what it's worth, I'm actually working toward the goal of making it possible for you to customize your experience much more than you do today. It'll take a while to get there, though. In the mean time, we'll continue to try to incrementally make the best viewer we can for the greatest number of people. I'd appreciate it if in the future you'd keep the name calling off this list. Q On Jun 17, 2009, at 2:51 PM, Boy Lane wrote: > That's absolutely the most ever single bullsh*t posting I've read on > this > mailing list. 1.23.4 is the worst viewer ever, it did not fix most of > existing bugs but introduced tons of new ones. LL did not respond to > most of > important user concerns but ignored them, as in the past. And you > guys are > proud to follow your new release policy by pushing unfinished > software out > to users for nothing but political reasons. Shame on you Linden Lab! > > Boy Lane > > > >> Message: 7 >> Date: Wed, 17 Jun 2009 09:35:48 -0400 >> From: "Kent Quirk (Q Linden)" >> Subject: Re: [sldev] 1.23.4 released in a hurry ? NO. >> To: Latif Khalifa >> Cc: sldev >> Message-ID: >> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > >> I absolutely claim that 1.23 is not only of releasable quality, but >> the best viewer we've ever shipped. It met its design goals on RC1. >> The bugs that were found and fixed in the next 3 RCs were minimal. On >> a global statistics level, the crash rates are lower than they've >> ever >> been, even when you include crashes caused by specific video cards. >> >> There are some individuals who are upset about some of the design >> decisions, like the redesign of pie menus. That's not a quality >> issue. >> There are other individuals who are upset about some of the technical >> decisions, such as the imposition of rendering limits where we never >> had them before. That's not a quality issue either. And there are >> people who don't like the new Adult-Only stuff. That's also not a >> quality issue. >> >> The definition of quality is meeting the specification. We executed >> on >> this viewer better than we've ever done it before, and I'm pretty >> proud of our team for doing it. >> >> By the way, contrary to the implication in the subject line, we >> released 1.23.4 almost exactly according to the schedule I announced >> internally in February. The internal decision to ship was based on >> quality. As every professional software organization does, for every >> open issue we balance the risk of shipping a product with that issue >> against the risk of trying to fix it. When all the risks of shipping >> are lower than the risks of fixing, we ship it. Which is what we did >> with RC4. >> >> Q > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From tom at streamsense.net Wed Jun 17 12:55:17 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed, 17 Jun 2009 20:55:17 +0100 Subject: [sldev] 1.23.4 released in a hurry ? NO. In-Reply-To: <0E2C0E8B-0208-41D9-85BE-E5C31BA4648A@lindenlab.com> References: <002401c9ef7c$ac75bc30$0600a8c0@hp> <0E2C0E8B-0208-41D9-85BE-E5C31BA4648A@lindenlab.com> Message-ID: <4A394A25.4040106@streamsense.net> Kent, Whilst I appreciate that you guys are proud of what you have accomplished, it's really not fair of you to make claims such as "the best viewer we've ever shipped" and then be offended when your own users disagree. There's new media bugs in 1.23 which cause the UI to turn black when quicktime is used, editing prims is a nightmare now due to changes to the sub unit mapping, the terrain and water flicker at altitude is unbearable.. As for crashes, my 1.23 viewer has frozen several times today and did not trigger the crash logger. I have a lot of respect for what you guys do, but please, just listen to our feedback and stop blowing your own trumpet. ~Tom Kent Quirk (Q Linden) wrote: > Ouch. > > Ya know, I'm trying really hard to be polite and rational and explain > the reasons behind what we do. I tried to show that we actually have a > professional development organization with a process. We've documented > what we fixed and what we changed. > > Perhaps you forget that we serve about a million customers a month. > Almost a million of them are not you. > > From all the tracking data we have, I can objectively see that over > hundreds of thousands of sessions, this is the most stable viewer > we've ever shipped. I hope that over the next several weeks, we'll > even see a small uptick in new users and retained users who find the > viewer easier to use and more understandable because of the changes > we've made. > > I will admit that your personal experience may in fact be worse. And > if that's the case, I'm sorry. > > Sadly, we can't code Second Life individually for each user. For what > it's worth, I'm actually working toward the goal of making it possible > for you to customize your experience much more than you do today. > It'll take a while to get there, though. In the mean time, we'll > continue to try to incrementally make the best viewer we can for the > greatest number of people. > > I'd appreciate it if in the future you'd keep the name calling off > this list. > > Q > > On Jun 17, 2009, at 2:51 PM, Boy Lane wrote: > > >> That's absolutely the most ever single bullsh*t posting I've read on >> this >> mailing list. 1.23.4 is the worst viewer ever, it did not fix most of >> existing bugs but introduced tons of new ones. LL did not respond to >> most of >> important user concerns but ignored them, as in the past. And you >> guys are >> proud to follow your new release policy by pushing unfinished >> software out >> to users for nothing but political reasons. Shame on you Linden Lab! >> >> Boy Lane >> >> >> >> >>> Message: 7 >>> Date: Wed, 17 Jun 2009 09:35:48 -0400 >>> From: "Kent Quirk (Q Linden)" >>> Subject: Re: [sldev] 1.23.4 released in a hurry ? NO. >>> To: Latif Khalifa >>> Cc: sldev >>> Message-ID: >>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >>> >> >>> I absolutely claim that 1.23 is not only of releasable quality, but >>> the best viewer we've ever shipped. It met its design goals on RC1. >>> The bugs that were found and fixed in the next 3 RCs were minimal. On >>> a global statistics level, the crash rates are lower than they've >>> ever >>> been, even when you include crashes caused by specific video cards. >>> >>> There are some individuals who are upset about some of the design >>> decisions, like the redesign of pie menus. That's not a quality >>> issue. >>> There are other individuals who are upset about some of the technical >>> decisions, such as the imposition of rendering limits where we never >>> had them before. That's not a quality issue either. And there are >>> people who don't like the new Adult-Only stuff. That's also not a >>> quality issue. >>> >>> The definition of quality is meeting the specification. We executed >>> on >>> this viewer better than we've ever done it before, and I'm pretty >>> proud of our team for doing it. >>> >>> By the way, contrary to the implication in the subject line, we >>> released 1.23.4 almost exactly according to the schedule I announced >>> internally in February. The internal decision to ship was based on >>> quality. As every professional software organization does, for every >>> open issue we balance the risk of shipping a product with that issue >>> against the risk of trying to fix it. When all the risks of shipping >>> are lower than the risks of fixing, we ship it. Which is what we did >>> with RC4. >>> >>> Q >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From robla at lindenlab.com Wed Jun 17 13:00:58 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 17 Jun 2009 13:00:58 -0700 Subject: [sldev] Mailing list tone Message-ID: <4A394B7A.3080005@lindenlab.com> Hi all, I'd like to remind everyone here about the SLDev posting policies: https://wiki.secondlife.com/wiki/SLDev In particular: * Constructive criticism is welcome, but general complaints which only serve to discourage use of Second Life or discourage cooperation with Linden Lab should be taken elsewhere. * Blog policy applies: https://blogs.secondlife.com/community/features/blog/2009/02/25/guidelines-for-the-sl-blogs We endeavor to maintain a respectful tone in our communications, which we imagine the vast majority of the 950+ subscribers to this mailing list appreciate. Allowing other behavior threatens our ability to continue to provide this venue. I'll be sending out private warnings to people who are running afoul of the policies. Additionally, moving forward, egregious violations will result in immediate suspension. If you find people you feel are running afoul of these policies, I'd suggest you either contact them directly off-list, or send mail to sldev-owner at lists.secondlife.com pointing this behavior out. Please don't engage them on list. It just starts a cycle that's tough to break by implicitly inviting the offender to further post "the last word". It rarely, if ever, results in a public apology. If you have problems with this policy, email me personally, or attach a comment here: https://wiki.secondlife.com/wiki/Talk:SLDev Please, let's *not* spin up a meta-discussion about this on the mailing list. Thanks Rob From soft at lindenlab.com Wed Jun 17 13:10:57 2009 From: soft at lindenlab.com (Soft) Date: Wed, 17 Jun 2009 15:10:57 -0500 Subject: [sldev] 1.23 perceptions - help us out here Message-ID: There are some disparate views on the list about the importance of the remaining 1.23 bugs, but I don't see anything productive coming from it so far. Some of you have mentioned specific issues, which is a start. But the best way to gather all this for evaluation would be to create a meta JIRA that links only to 1.23 regressions which you would have classified as showstoppers. Anyone want to volunteer to compile a JIRA like that? Again, to be most valuable, it would be anything you perceive as (a) a regression new to 1.23, (b) approaching showstopper importance, and (c) still present in 1.23.4. From tayra.dagostino at gmail.com Wed Jun 17 15:42:08 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Thu, 18 Jun 2009 00:42:08 +0200 Subject: [sldev] about last SG build Message-ID: <20090618004208.ea6544b9.tayra.dagostino@gmail.com> i dunno.... or there are teleport problem on the grid, or latest snowglobe have a trouble on TP: first TP work, all other no... before fill a jira... somebody else? 2nd: every relog i lost all hud, i must re-wear every time, same above before fill a jira, somebody else? From dahliatrimble at gmail.com Wed Jun 17 18:02:29 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 17 Jun 2009 18:02:29 -0700 Subject: [sldev] Question about Snowglobe binaries Message-ID: I've been using Snowglobe "Second Life 1.23.2 (2324) May 27 2009 15:18:08 (Second Life OSS)" on my Ubuntu 8.04 x64 system but I've had difficulties with bump maps not working so I thought I'd try a newer version. I downloaded a newer linux build from this page: https://lists.secondlife.com/pipermail/sldev-commits/2009-June/002823.html and I get the following error when I try to execute it: Secondlife/Snowglobe-i686-0.9.0.2418 bin/snowglobe-do-not-run-directly: error while loading shared libraries: libz.so: cannot open shared object file: No such file or directory *** Bad shutdown. *** According to aptitude, the libz I'm using is the most recent for my distribution. Here is a listing of the relevant files: root at nkubuntu:/usr/lib# ls -al libz.s* lrwxrwxrwx 1 root root 15 2008-07-29 21:59 libz.so -> libz.so.1.2.3.3 lrwxrwxrwx 1 root root 15 2008-07-28 16:50 libz.so.1 -> libz.so.1.2.3.3 -rw-r--r-- 1 root root 93536 2007-11-15 05:12 libz.so.1.2.3.3 Is there some other libz I would need to run these executables, hopefully one which would be compatible with other applications/libraries on my system? Or are there plans to distribute recent binaries which would run in the same environments as the production SL viewers? Also a suggestion: please consider offering 64 bit binaries :) Regards, -Dahlia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090617/e5f2c563/attachment.htm From robla at lindenlab.com Wed Jun 17 21:02:19 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 17 Jun 2009 21:02:19 -0700 Subject: [sldev] Question about Snowglobe binaries In-Reply-To: References: Message-ID: <4A39BC4B.80002@lindenlab.com> Here's what worked on my Jaunty 64-bit system: * Make sure lib32z1 is installed * cd /usr/lib32/ * sudo ln -s /usr/lib32/libz.so.1 libz.so.1 After that, Snowglobe-y goodness. Someone willing to submit a patch to Snowglobe to make sure we link to the right library without resorting to a symlink? See here for more about supporting Linux 64-bit: https://jira.secondlife.com/browse/VWR-13793 Rob On 06/17/2009 06:02 PM, Dahlia Trimble wrote: > I've been using Snowglobe "Second Life 1.23.2 (2324) May 27 2009 > 15:18:08 (Second Life OSS)" on my Ubuntu 8.04 x64 system but I've had > difficulties with bump maps not working so I thought I'd try a newer > version. > > I downloaded a newer linux build from this page: > https://lists.secondlife.com/pipermail/sldev-commits/2009-June/002823.html and > I get the following error when I try to execute it: > > Secondlife/Snowglobe-i686-0.9.0.2418 > bin/snowglobe-do-not-run-directly: error while loading shared > libraries: libz.so: cannot open shared object file: No such file or > directory > *** Bad shutdown. *** > According to aptitude, the libz I'm using is the most recent for my > distribution. Here is a listing of the relevant files: > > root at nkubuntu:/usr/lib # ls -al libz.s* > lrwxrwxrwx 1 root root 15 2008-07-29 21:59 libz.so -> libz.so.1.2.3.3 > lrwxrwxrwx 1 root root 15 2008-07-28 16:50 libz.so.1 -> libz.so.1.2.3.3 > -rw-r--r-- 1 root root 93536 2007-11-15 05:12 libz.so.1.2.3.3 > > Is there some other libz I would need to run these executables, > hopefully one which would be compatible with other > applications/libraries on my system? Or are there plans to distribute > recent binaries which would run in the same environments as the > production SL viewers? > > Also a suggestion: please consider offering 64 bit binaries :) > > Regards, > -Dahlia > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From dahliatrimble at gmail.com Wed Jun 17 22:22:10 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 17 Jun 2009 22:22:10 -0700 Subject: [sldev] Question about Snowglobe binaries In-Reply-To: <4A39BC4B.80002@lindenlab.com> References: <4A39BC4B.80002@lindenlab.com> Message-ID: Thanks for the hint Rob. Here's what I had to do to get Snowglobe to start up: sudo ln -s /usr/lib32/libz.so.1.2.3.3 /usr/lib32/libz.so Also in Snowglobe-i686-0.9.0.2423/lib/ there was a circular reference for libuuid.so.1 so I deleted it and copied libuuid.so.1 from SecondLife-i686-1.23.4.123908/lib/ And now I'm happy that bump maps appear to be working in this version :) Regards, -Dahlia On Wed, Jun 17, 2009 at 9:02 PM, Rob Lanphier wrote: > Here's what worked on my Jaunty 64-bit system: > * Make sure lib32z1 is installed > * cd /usr/lib32/ > * sudo ln -s /usr/lib32/libz.so.1 libz.so.1 > > After that, Snowglobe-y goodness. > > Someone willing to submit a patch to Snowglobe to make sure we link to > the right library without resorting to a symlink? > > See here for more about supporting Linux 64-bit: > https://jira.secondlife.com/browse/VWR-13793 > > Rob > > On 06/17/2009 06:02 PM, Dahlia Trimble wrote: > > I've been using Snowglobe "Second Life 1.23.2 (2324) May 27 2009 > > 15:18:08 (Second Life OSS)" on my Ubuntu 8.04 x64 system but I've had > > difficulties with bump maps not working so I thought I'd try a newer > > version. > > > > I downloaded a newer linux build from this page: > > > https://lists.secondlife.com/pipermail/sldev-commits/2009-June/002823.htmland > > I get the following error when I try to execute it: > > > > Secondlife/Snowglobe-i686-0.9.0.2418 > > bin/snowglobe-do-not-run-directly: error while loading shared > > libraries: libz.so: cannot open shared object file: No such file or > > directory > > *** Bad shutdown. *** > > According to aptitude, the libz I'm using is the most recent for my > > distribution. Here is a listing of the relevant files: > > > > root at nkubuntu:/usr/lib # ls -al libz.s* > > lrwxrwxrwx 1 root root 15 2008-07-29 21:59 libz.so -> libz.so.1.2.3.3 > > lrwxrwxrwx 1 root root 15 2008-07-28 16:50 libz.so.1 -> > libz.so.1.2.3.3 > > -rw-r--r-- 1 root root 93536 2007-11-15 05:12 libz.so.1.2.3.3 > > > > Is there some other libz I would need to run these executables, > > hopefully one which would be compatible with other > > applications/libraries on my system? Or are there plans to distribute > > recent binaries which would run in the same environments as the > > production SL viewers? > > > > Also a suggestion: please consider offering 64 bit binaries :) > > > > Regards, > > -Dahlia > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090617/0a73fe81/attachment-0001.htm From snowfox102 at dragonkeepcreations.com Wed Jun 17 23:01:57 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Thu, 18 Jun 2009 01:01:57 -0500 Subject: [sldev] 1.23.4 released in a hurry ? NO. In-Reply-To: <0E2C0E8B-0208-41D9-85BE-E5C31BA4648A@lindenlab.com> References: <002401c9ef7c$ac75bc30$0600a8c0@hp> <0E2C0E8B-0208-41D9-85BE-E5C31BA4648A@lindenlab.com> Message-ID: <4A39D855.8010409@dragonkeepcreations.com> I'll withhold most of my own comments about this viewer, all I'll say is, I did my part in warning LL. That said, the only way you could get a user base count of a million a month is if you counted the daily log ins as each being separate users, which isn't the case. It's the same people each time for the most part. Unless you've got several hundred thousand secret users. Your message also sounds like you care more about keeping new users than the old ones who made SL what it is. I'm sure you don't mean it that way, do you? All in all, I don't care what 1.23.4 is like. It doesn't fulfill my needs as a content creator so I'm not interested in it. Besides, the sooner 1.23 work is stopped, the sooner alpha masking can be implemented, something the users actually need. Maya Kent Quirk (Q Linden) wrote: > Ouch. > > Ya know, I'm trying really hard to be polite and rational and explain > the reasons behind what we do. I tried to show that we actually have a > professional development organization with a process. We've documented > what we fixed and what we changed. > > Perhaps you forget that we serve about a million customers a month. > Almost a million of them are not you. > > From all the tracking data we have, I can objectively see that over > hundreds of thousands of sessions, this is the most stable viewer > we've ever shipped. I hope that over the next several weeks, we'll > even see a small uptick in new users and retained users who find the > viewer easier to use and more understandable because of the changes > we've made. > > I will admit that your personal experience may in fact be worse. And > if that's the case, I'm sorry. > > Sadly, we can't code Second Life individually for each user. For what > it's worth, I'm actually working toward the goal of making it possible > for you to customize your experience much more than you do today. > It'll take a while to get there, though. In the mean time, we'll > continue to try to incrementally make the best viewer we can for the > greatest number of people. > > I'd appreciate it if in the future you'd keep the name calling off > this list. > > Q > > On Jun 17, 2009, at 2:51 PM, Boy Lane wrote: > > >> That's absolutely the most ever single bullsh*t posting I've read on >> this >> mailing list. 1.23.4 is the worst viewer ever, it did not fix most of >> existing bugs but introduced tons of new ones. LL did not respond to >> most of >> important user concerns but ignored them, as in the past. And you >> guys are >> proud to follow your new release policy by pushing unfinished >> software out >> to users for nothing but political reasons. Shame on you Linden Lab! >> >> Boy Lane >> >> >> >> >>> Message: 7 >>> Date: Wed, 17 Jun 2009 09:35:48 -0400 >>> From: "Kent Quirk (Q Linden)" >>> Subject: Re: [sldev] 1.23.4 released in a hurry ? NO. >>> To: Latif Khalifa >>> Cc: sldev >>> Message-ID: >>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >>> >> >>> I absolutely claim that 1.23 is not only of releasable quality, but >>> the best viewer we've ever shipped. It met its design goals on RC1. >>> The bugs that were found and fixed in the next 3 RCs were minimal. On >>> a global statistics level, the crash rates are lower than they've >>> ever >>> been, even when you include crashes caused by specific video cards. >>> >>> There are some individuals who are upset about some of the design >>> decisions, like the redesign of pie menus. That's not a quality >>> issue. >>> There are other individuals who are upset about some of the technical >>> decisions, such as the imposition of rendering limits where we never >>> had them before. That's not a quality issue either. And there are >>> people who don't like the new Adult-Only stuff. That's also not a >>> quality issue. >>> >>> The definition of quality is meeting the specification. We executed >>> on >>> this viewer better than we've ever done it before, and I'm pretty >>> proud of our team for doing it. >>> >>> By the way, contrary to the implication in the subject line, we >>> released 1.23.4 almost exactly according to the schedule I announced >>> internally in February. The internal decision to ship was based on >>> quality. As every professional software organization does, for every >>> open issue we balance the risk of shipping a product with that issue >>> against the risk of trying to fix it. When all the risks of shipping >>> are lower than the risks of fixing, we ship it. Which is what we did >>> with RC4. >>> >>> Q >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From robla at lindenlab.com Thu Jun 18 00:06:36 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 18 Jun 2009 00:06:36 -0700 Subject: [sldev] Snowglobe Release Candidate download links (hopefully) Message-ID: <4A39E77C.1060800@lindenlab.com> Hi folks The Windows and Mac builds of the Snowglobe viewer just got done, and the Linux versino should be rolling off the build machine shortly. If my powers of prediction are correct, here's the links for the upcoming builds. Windows http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1-0-0-2435_Setup.exe Mac http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1_0_0_2435_SNOWGLOBERELEASE.dmg Linux http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe-i686-1.0.0.2435.tar.bz2 Barring any showstopper bugs (not present in 1.23, easily reproducable, and high impact for a large number of residents) or maybe extremely low-risk cosmetic fixes we'd like to get in, this build has a pretty good chance of being Snowglobe 1.0. So, please, really beat on this version. It's going to get into a lot of hands, so let's make sure this is a version that's going to leave a good first impression. Thanks! Rob From chaosstar at gmail.com Thu Jun 18 00:59:46 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 18 Jun 2009 09:59:46 +0200 Subject: [sldev] Rendering Limits In-Reply-To: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> Message-ID: <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> This is news to me as well. Rendering limits? Which? I personally have not noticed anything that I might recognize as a new rendering limit? On Wed, Jun 17, 2009 at 16:02, Harleen Gretzky wrote: > Can you elaborate on what the new rendering limits are? > > > On Wed, Jun 17, 2009 at 9:35 AM, Kent Quirk (Q Linden) > wrote: >> >> >> I absolutely claim that 1.23 is not only of releasable quality, but >> the best viewer we've ever shipped. It met its design goals on RC1. >> The bugs that were found and fixed in the next 3 RCs were minimal. On >> a global statistics level, the crash rates are lower than they've ever >> been, even when you include crashes caused by specific video cards. >> >> There are some individuals who are upset about some of the design >> decisions, like the redesign of pie menus. That's not a quality issue. >> There are other individuals who are upset about some of the technical >> decisions, such as the imposition of rendering limits where we never >> had them before. That's not a quality issue either. And there are >> people who don't like the new Adult-Only stuff. That's also not a >> quality issue. >> >> The definition of quality is meeting the specification. We executed on >> this viewer better than we've ever done it before, and I'm pretty >> proud of our team for doing it. >> >> By the way, contrary to the implication in the subject line, we >> released 1.23.4 almost exactly according to the schedule I announced >> internally in February. The internal decision to ship was based on >> quality. As every professional software organization does, for every >> open issue we balance the risk of shipping a product with that issue >> against the risk of trying to fix it. When all the risks of shipping >> are lower than the risks of fixing, we ship it. Which is what we did >> with RC4. >> >> ? ? ? ?Q >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From dahliatrimble at gmail.com Thu Jun 18 01:01:07 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 18 Jun 2009 01:01:07 -0700 Subject: [sldev] Snowglobe Release Candidate download links (hopefully) In-Reply-To: <4A39E77C.1060800@lindenlab.com> References: <4A39E77C.1060800@lindenlab.com> Message-ID: Looks like the linux viewer in this build has the same circular link reference for the file lib/libuuid.so.1 On Thu, Jun 18, 2009 at 12:06 AM, Rob Lanphier wrote: > Hi folks > > The Windows and Mac builds of the Snowglobe viewer just got done, and > the Linux versino should be rolling off the build machine shortly. If > my powers of prediction are correct, here's the links for the upcoming > builds. > > Windows > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1-0-0-2435_Setup.exe > > Mac > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1_0_0_2435_SNOWGLOBERELEASE.dmg > > Linux > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe-i686-1.0.0.2435.tar.bz2 > > Barring any showstopper bugs (not present in 1.23, easily reproducable, > and high impact for a large number of residents) or maybe extremely > low-risk cosmetic fixes we'd like to get in, this build has a pretty > good chance of being Snowglobe 1.0. > > So, please, really beat on this version. It's going to get into a lot > of hands, so let's make sure this is a version that's going to leave a > good first impression. > > Thanks! > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/00196a23/attachment.htm From chaosstar at gmail.com Thu Jun 18 01:07:27 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 18 Jun 2009 10:07:27 +0200 Subject: [sldev] 1.23 perceptions - help us out here In-Reply-To: References: Message-ID: <9bb32d430906180107g26a521ckbb3a9cd5bc222b59@mail.gmail.com> I have two bugs in mind that I consider to be affecting the general populance, and being noticable by even new users. They'd be the occasional rendering of avatar parts as transparent (in some cases across half the face :P), pie menu failing on non-prim avatar parts at times. I guess I can start such a JIRA later, with those two bugs included as a start. What should the JIRA be called? 'META: High priority 1.23 release bugs?' On Wed, Jun 17, 2009 at 22:10, Soft wrote: > There are some disparate views on the list about the importance of the > remaining 1.23 bugs, but I don't see anything productive coming from > it so far. Some of you have mentioned specific issues, which is a > start. But the best way to gather all this for evaluation would be to > create a meta JIRA that links only to 1.23 regressions which you would > have classified as showstoppers. > > Anyone want to volunteer to compile a JIRA like that? Again, to be > most valuable, it would be anything you perceive as (a) a regression > new to 1.23, (b) approaching showstopper importance, and (c) still > present in 1.23.4. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From chaosstar at gmail.com Thu Jun 18 01:07:27 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 18 Jun 2009 10:07:27 +0200 Subject: [sldev] 1.23 perceptions - help us out here In-Reply-To: References: Message-ID: <9bb32d430906180107g26a521ckbb3a9cd5bc222b59@mail.gmail.com> I have two bugs in mind that I consider to be affecting the general populance, and being noticable by even new users. They'd be the occasional rendering of avatar parts as transparent (in some cases across half the face :P), pie menu failing on non-prim avatar parts at times. I guess I can start such a JIRA later, with those two bugs included as a start. What should the JIRA be called? 'META: High priority 1.23 release bugs?' On Wed, Jun 17, 2009 at 22:10, Soft wrote: > There are some disparate views on the list about the importance of the > remaining 1.23 bugs, but I don't see anything productive coming from > it so far. Some of you have mentioned specific issues, which is a > start. But the best way to gather all this for evaluation would be to > create a meta JIRA that links only to 1.23 regressions which you would > have classified as showstoppers. > > Anyone want to volunteer to compile a JIRA like that? Again, to be > most valuable, it would be anything you perceive as (a) a regression > new to 1.23, (b) approaching showstopper importance, and (c) still > present in 1.23.4. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From soft at lindenlab.com Thu Jun 18 07:45:30 2009 From: soft at lindenlab.com (Soft) Date: Thu, 18 Jun 2009 09:45:30 -0500 Subject: [sldev] Rendering Limits In-Reply-To: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> Message-ID: I'll attach the diff. It addresses cases where baddies were creating attachments tuned to lag out viewers with wild vertex counts. With the necklace for VWR-13868, view it in wireframe mode or turn on render->info displays->sculpt to see why it's a really unusual asset: at the typical resolution and view distance, it's going to have like 30 faces per pixel. It's literally got more polygons than both teams in a typical console basketball game. If anyone is really attached to affected assets and wants to contribute an alternative patch, it might be possible to do something like dropping LOD on sculpts and tori when a set is wildly expensive. I think more time didn't go into that because the few non-griefer assets we were given were overkill for a space the size of a room, let alone as an attachment. There are many more tasks requiring graphics dev time, which affect more resis. On Wed, Jun 17, 2009 at 9:02 AM, Harleen Gretzky wrote: > Can you elaborate on what the new rendering limits are? > > > On Wed, Jun 17, 2009 at 9:35 AM, Kent Quirk (Q Linden) > wrote: >> >> rendering limits where we never had them before -------------- next part -------------- A non-text attachment was scrubbed... Name: DEV-18445.patch Type: text/x-patch Size: 1262 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090618/c2834807/attachment-0001.bin From carlo at alinoe.com Thu Jun 18 07:49:53 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 18 Jun 2009 16:49:53 +0200 Subject: [sldev] I found a possible problem on linux (gdk/gtk related) Message-ID: <20090618144953.GA31637@alinoe.com> My question is: what percentage of the users is using linux? Here I am assuming that linux users, and only linux users, are using the GTK part (and gstreamer). I have reason to believe that GTK is not being used thread-safe, which should cause random crashes on linux. The reason that I believe this is because I started to use GTK seriously from a new thread which immediately caused very frequent crashes (more than 95% of the time) which led me quickly to find out that gdk threading wasn't initialized (no locking takes place at all in the current viewer). I added that initialization and locking, and added some necessary (missing) locking calls... until my new thread ran perfectly. However, what I run into now are deadlocks (without using my new thread). This indicates that the viewer (without my changes) is using gdk/gtk from two different threads at the same time (and without locking thus). That this works in most cases could be just luck. I was/am planning to provide a patch for this, but I'm busy :p So, hence the question at the top. I'd expect crashes on linux while people are playing music and open a file picker window at the same time; if this is not the case, then I guess that the gstreamer mainloop doesn't bite the filepicker by coincidence, what would make this a not so hight priority to fix though. Carlo Wood From soft at lindenlab.com Thu Jun 18 07:53:00 2009 From: soft at lindenlab.com (Soft) Date: Thu, 18 Jun 2009 09:53:00 -0500 Subject: [sldev] Rendering Limits In-Reply-To: <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> Message-ID: Try creating a 128x128 sculpted prim, then link 255 of those together in a 16x16 grid (remove one to make 255). Then scale them down as far as they'll go and wear it like a badge. You should start to see some prims in the set vanish. On Thu, Jun 18, 2009 at 2:59 AM, Ambrosia wrote: > This is news to me as well. Rendering limits? Which? I personally have > not noticed anything that I might recognize as a new rendering limit? > > On Wed, Jun 17, 2009 at 16:02, Harleen Gretzky wrote: >> Can you elaborate on what the new rendering limits are? From missannotoole at yahoo.com Thu Jun 18 08:09:45 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 18 Jun 2009 08:09:45 -0700 (PDT) Subject: [sldev] Snowglobe Release Candidate download links (hopefully) In-Reply-To: <4A39E77C.1060800@lindenlab.com> References: <4A39E77C.1060800@lindenlab.com> Message-ID: <67617.4551.qm@web59101.mail.re1.yahoo.com> Rob, I am not sure if I need to enter a pjira issue on this. It is clearly disturbing to see an entire region rez in under 30 seconds. Are you sure this is the right thing for Second Life? Should we prep counseling centers to help residents suffering trauma from seeing too many textures rez instantly and greyness withdrawal? :D Looking good so far. ________________________________ From: Rob Lanphier To: Second Life Developer Mailing List Sent: Thursday, June 18, 2009 3:06:36 AM Subject: [sldev] Snowglobe Release Candidate download links (hopefully) Hi folks The Windows and Mac builds of the Snowglobe viewer just got done, and the Linux versino should be rolling off the build machine shortly. If my powers of prediction are correct, here's the links for the upcoming builds. Windows http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1-0-0-2435_Setup.exe Mac http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1_0_0_2435_SNOWGLOBERELEASE.dmg Linux http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe-i686-1.0.0.2435.tar.bz2 Barring any showstopper bugs (not present in 1.23, easily reproducable, and high impact for a large number of residents) or maybe extremely low-risk cosmetic fixes we'd like to get in, this build has a pretty good chance of being Snowglobe 1.0. So, please, really beat on this version. It's going to get into a lot of hands, so let's make sure this is a version that's going to leave a good first impression. Thanks! Rob _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/a481ea11/attachment.htm From moriz.gupte at gmail.com Thu Jun 18 08:15:29 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Thu, 18 Jun 2009 09:15:29 -0600 Subject: [sldev] Rendering Limits In-Reply-To: References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> Message-ID: I think rendering limits are inevitable, resources tend not to be unlimited. There will be disagreements regarding rendering prioritizations/limits ... this is to be expected. Perhaps one approach would be to see how much pain is inflicted on the community if a limit is imposed. If most don't even notice it, then it's probably a proper rendering limitation...which would then qualify as an 'optimization'. One thing is very helpful though, and think Soft has done some of it already, is to publish these limitations and how it impacts rendering (must be easier for LL to initiate that than the community). *forgive me * if this is published somewhere already, may be share the link. On Thu, Jun 18, 2009 at 8:53 AM, Soft wrote: > Try creating a 128x128 sculpted prim, then link 255 of those together > in a 16x16 grid (remove one to make 255). Then scale them down as far > as they'll go and wear it like a badge. You should start to see some > prims in the set vanish. > > On Thu, Jun 18, 2009 at 2:59 AM, Ambrosia wrote: >> This is news to me as well. Rendering limits? Which? I personally have >> not noticed anything that I might recognize as a new rendering limit? >> >> On Wed, Jun 17, 2009 at 16:02, Harleen Gretzky wrote: >>> Can you elaborate on what the new rendering limits are? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 More info at http://tr.im/RRamloll From missannotoole at yahoo.com Thu Jun 18 08:18:01 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 18 Jun 2009 08:18:01 -0700 (PDT) Subject: [sldev] Rendering Limits In-Reply-To: References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> Message-ID: <939372.98867.qm@web59104.mail.re1.yahoo.com> Soft, It is your opinion you are expressing as to what is overkill. Which is why we need Linden Lab to be converted to a standard corporation where software developers are relegated to coding to customer requirements and do not make any decisions whatsoever. You are going to experience a severe backlash over your decision to destroy most of second life. That being said as long as you do not disable the customer's ability to opverride your unqualified decision that was not based on customer requyirements then it is all good. Because everyone is just going to up rendermaxnodesize to get the viewer back to where it was operating perfectly well. Also you should be embarrassed for categorizing as and calling most of the content creators and artists in Second Life griefers. We made this world. You would not even have this job if SL did not look good because of our work. We pay your salary. ________________________________ From: Soft To: Harleen Gretzky Cc: sldev Sent: Thursday, June 18, 2009 10:45:30 AM Subject: Re: [sldev] Rendering Limits I'll attach the diff. It addresses cases where baddies were creating attachments tuned to lag out viewers with wild vertex counts. With the necklace for VWR-13868, view it in wireframe mode or turn on render->info displays->sculpt to see why it's a really unusual asset: at the typical resolution and view distance, it's going to have like 30 faces per pixel. It's literally got more polygons than both teams in a typical console basketball game. If anyone is really attached to affected assets and wants to contribute an alternative patch, it might be possible to do something like dropping LOD on sculpts and tori when a set is wildly expensive. I think more time didn't go into that because the few non-griefer assets we were given were overkill for a space the size of a room, let alone as an attachment. There are many more tasks requiring graphics dev time, which affect more resis. On Wed, Jun 17, 2009 at 9:02 AM, Harleen Gretzky wrote: > Can you elaborate on what the new rendering limits are? > > > On Wed, Jun 17, 2009 at 9:35 AM, Kent Quirk (Q Linden) > wrote: >> >> rendering limits where we never had them before -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/b9d6c1fe/attachment.htm From soft at lindenlab.com Thu Jun 18 08:20:09 2009 From: soft at lindenlab.com (Soft) Date: Thu, 18 Jun 2009 10:20:09 -0500 Subject: [sldev] Rendering Limits In-Reply-To: <939372.98867.qm@web59104.mail.re1.yahoo.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <939372.98867.qm@web59104.mail.re1.yahoo.com> Message-ID: On Thu, Jun 18, 2009 at 10:18 AM, Ann Otoole wrote: > > Also you should be embarrassed for categorizing as and calling most of the > content creators and artists in Second Life griefers. Nicely trolled. That was nowhere in my text. From kf6kjg at gmail.com Thu Jun 18 08:33:40 2009 From: kf6kjg at gmail.com (Ricky) Date: Thu, 18 Jun 2009 15:33:40 +0000 Subject: [sldev] Display corruption when switching Anisotropic/Antialiasing hardware options Message-ID: <3bb9647e0906180833u24ebd7ceycc8c5f583b17ebc3@mail.gmail.com> At least snowglobe (1.0.0.0.2435) doesn't crash! I tried repoing on 1.23_rc4, but it crashed instead of corrupting... The effect is the same no matter what skin I use: The display turns whitish, all text characters turn into rectangles, skin borders go away, etc. Restarting Snowglobe fixes the issue. Can anyone else repo? The steps are as follows: 1: Start Snowglobe (don't log in) 2: Goto Edit->Preferences 3: Select the Graphics tab 4: Pres the "Hardware Options" button 5: Select the Anisotropic Filtering checkbox, and set Antialiasing to 4x or more. If at first it doesn't corrupt, try other AA values. I am running Gentoo with KDE4.2.4: -------------------------------------------- Snowglobe 1.0.0 (2435) Jun 18 2009 00:25:30 (Snowglobe Release) Release Notes Built with GCC version 40102 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ Memory: 7995 MB OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue May 26 04:53:37 Local time zone must be set-- x86_64 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8600 GTS/PCI/SSE2 OpenGL Version: 1.4 (3.0.0 NVIDIA 180.60) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0 J2C Decoder Version: KDU Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: ALSA Software on default LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24737 (Mozilla GRE version 1.8.1.18_0000000000) -------------------------------------------- If I can get another repo (especially on another platform,) I'll open a JIRA report. I'll also be testing on Windows XP and OSX in the next 24 hours. Ricky aka Cron Stardust From tigrospottystripes at gmail.com Thu Jun 18 08:34:53 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 18 Jun 2009 12:34:53 -0300 Subject: [sldev] Rendering Limits In-Reply-To: References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> Message-ID: <4A3A5E9D.3@Gmail.com> would it be too hard to make things that are above the limit be LOD'ed down gradually, and only start unrendering things when a huge chunk of everything on screen is already at lowest LOD? Also, any such limits should be a slider with a typeable textbox next to it on the graphics tab of the preferences screen IMO. Moriz Gupte escreveu: > I think rendering limits are inevitable, resources tend not to be > unlimited. There will be disagreements regarding rendering > prioritizations/limits ... this is to be expected. Perhaps one > approach would be to see how much pain is inflicted on the community > if a limit is imposed. If most don't even notice it, then it's > probably a proper rendering limitation...which would then qualify as > an 'optimization'. One thing is very helpful though, and think Soft > has done some of it already, is to publish these limitations and how > it impacts rendering (must be easier for LL to initiate that than the > community). *forgive me * if this is published somewhere already, may > be share the link. > > > > On Thu, Jun 18, 2009 at 8:53 AM, Soft wrote: > >> Try creating a 128x128 sculpted prim, then link 255 of those together >> in a 16x16 grid (remove one to make 255). Then scale them down as far >> as they'll go and wear it like a badge. You should start to see some >> prims in the set vanish. >> >> On Thu, Jun 18, 2009 at 2:59 AM, Ambrosia wrote: >> >>> This is news to me as well. Rendering limits? Which? I personally have >>> not noticed anything that I might recognize as a new rendering limit? >>> >>> On Wed, Jun 17, 2009 at 16:02, Harleen Gretzky wrote: >>> >>>> Can you elaborate on what the new rendering limits are? >>>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > > > From missannotoole at yahoo.com Thu Jun 18 08:57:23 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 18 Jun 2009 08:57:23 -0700 (PDT) Subject: [sldev] Rendering Limits In-Reply-To: <4A3A5E9D.3@Gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> Message-ID: <53079.85326.qm@web59106.mail.re1.yahoo.com> Watch this video for an idea as to the significance of the destroyed content. http://www.youtube.com/watch?v=Cr3_bqlYQwQ That video was posted on http://jira.secondlife.com/browse/VWR-14049 which is pretty obviously a duplicate of http://jira.secondlife.com/browse/VWR-13868 but I'm not closing it since it has more angry people piling in. It is not limited to small art pieces like that necklace and pretty much a lot of period jewelry and outfits. I have heard reports of half of people's stores vanishing causing them to try putting stuff back when the prims are still there. I expect to hear about "phantom prims, and all sort of stuff. No announcement was made about such a catastrophic nuking of Second Life before it was rolled out. There was nothing I saw in release notes indicating LL had elected to destroy content in this manner. Again, as long as rendermaxnodesize is available to be overridden then it is a matter of educating the residents. Or LL could raise the limit to 8192 and most builds would be fine and only people with computers not even qualified to connect to SL would experience impeded frame rates. LL needs to increase the minimum hardware requirements to 2GB and nvidia 8000 or better GPU anyway. ________________________________ From: Tigro Spottystripes To: Moriz Gupte Cc: sldev Sent: Thursday, June 18, 2009 11:34:53 AM Subject: Re: [sldev] Rendering Limits would it be too hard to make things that are above the limit be LOD'ed down gradually, and only start unrendering things when a huge chunk of everything on screen is already at lowest LOD? Also, any such limits should be a slider with a typeable textbox next to it on the graphics tab of the preferences screen IMO. Moriz Gupte escreveu: > I think rendering limits are inevitable, resources tend not to be > unlimited. There will be disagreements regarding rendering > prioritizations/limits ... this is to be expected. Perhaps one > approach would be to see how much pain is inflicted on the community > if a limit is imposed. If most don't even notice it, then it's > probably a proper rendering limitation...which would then qualify as > an 'optimization'. One thing is very helpful though, and think Soft > has done some of it already, is to publish these limitations and how > it impacts rendering (must be easier for LL to initiate that than the > community). *forgive me * if this is published somewhere already, may > be share the link. > > > > On Thu, Jun 18, 2009 at 8:53 AM, Soft wrote: > >> Try creating a 128x128 sculpted prim, then link 255 of those together >> in a 16x16 grid (remove one to make 255). Then scale them down as far >> as they'll go and wear it like a badge. You should start to see some >> prims in the set vanish. >> >> On Thu, Jun 18, 2009 at 2:59 AM, Ambrosia wrote: >> >>> This is news to me as well. Rendering limits? Which? I personally have >>> not noticed anything that I might recognize as a new rendering limit? >>> >>> On Wed, Jun 17, 2009 at 16:02, Harleen Gretzky wrote: >>> >>>> Can you elaborate on what the new rendering limits are? >>>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > > > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/003ccb53/attachment.htm From missannotoole at yahoo.com Thu Jun 18 09:01:21 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 18 Jun 2009 09:01:21 -0700 (PDT) Subject: [sldev] Display corruption when switching Anisotropic/Antialiasing hardware options In-Reply-To: <3bb9647e0906180833u24ebd7ceycc8c5f583b17ebc3@mail.gmail.com> References: <3bb9647e0906180833u24ebd7ceycc8c5f583b17ebc3@mail.gmail.com> Message-ID: <124359.69249.qm@web59105.mail.re1.yahoo.com> nVidia 8500GT on Vista64/4GB/Quad Core here and no repro. I went to 16x antialiasing with ansiotropc on and nothing unexpected happened except it appeared to change resolution more gracefully than v1.22. ________________________________ From: Ricky To: Second Life Developer Mailing List Sent: Thursday, June 18, 2009 11:33:40 AM Subject: [sldev] Display corruption when switching Anisotropic/Antialiasing hardware options At least snowglobe (1.0.0.0.2435) doesn't crash! I tried repoing on 1.23_rc4, but it crashed instead of corrupting... The effect is the same no matter what skin I use: The display turns whitish, all text characters turn into rectangles, skin borders go away, etc. Restarting Snowglobe fixes the issue. Can anyone else repo? The steps are as follows: 1: Start Snowglobe (don't log in) 2: Goto Edit->Preferences 3: Select the Graphics tab 4: Pres the "Hardware Options" button 5: Select the Anisotropic Filtering checkbox, and set Antialiasing to 4x or more. If at first it doesn't corrupt, try other AA values. I am running Gentoo with KDE4.2.4: -------------------------------------------- Snowglobe 1.0.0 (2435) Jun 18 2009 00:25:30 (Snowglobe Release) Release Notes Built with GCC version 40102 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ Memory: 7995 MB OS Version: Linux 2.6.29-gentoo-r5 #2 SMP PREEMPT Tue May 26 04:53:37 Local time zone must be set-- x86_64 Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8600 GTS/PCI/SSE2 OpenGL Version: 1.4 (3.0.0 NVIDIA 180.60) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 c-ares/1.4.0 J2C Decoder Version: KDU Audio Driver Version: OpenAL, version 1.1 / OpenAL Community / OpenAL Soft: ALSA Software on default LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24737 (Mozilla GRE version 1.8.1.18_0000000000) -------------------------------------------- If I can get another repo (especially on another platform,) I'll open a JIRA report. I'll also be testing on Windows XP and OSX in the next 24 hours. Ricky aka Cron Stardust _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/298a77f9/attachment.htm From maggie at matrisync.com Thu Jun 18 08:40:03 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Thu, 18 Jun 2009 11:40:03 -0400 Subject: [sldev] SLDev Digest, Vol 30, Issue 47 In-Reply-To: References: Message-ID: On Wed, Jun 17, 2009 at 9:35 AM, Kent Quirk (Q Linden) > The bugs that were found and fixed in the next 3 RCs were minimal. On > a global statistics level, the crash rates are lower than they've ever > been, even when you include crashes caused by specific video cards. Well, we can only go by our own crash rates and word-of-mouth since we don't get to see the global stats. Our local crash rates here are still what I would call "awful", and clearly worse on 1.23 than 1.22, with two users making heavy use of hardware selected and purchased specifically on the basis of the published requirements for SLV. The crashes are almost always due --as far as I can see from the information available-- to virtual memory exhaustion. Perhaps I have "a specific video card". If so, I think the "specific video card manufacturer" would be interested in hearing about a claim that their card is crashing your app...I'd be interested in hearing the details of the bugs you filed with them, assuming it's not constrained by an NDA.. (The last time I dealt with a severe SLV bug that was repeatedly and strenuously attributed to the video card driver, it turned out to be the result of a trivial code defect in SLV, found by a third party developer). I do hope your crash rate is calculated per session hour. Because if it's a raw number of crashes per day or even per session, I do know that the uptake of 1.23 in our operation was limited by the fact that the thing kept leaking up and falling over, and if others were affected the same way then a raw crash rate per day would be badly distorted. Any chance you'll start publishing the viewer crash stats? Maggie Darwin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/c082e3e4/attachment.htm From mwhite at leporidae.net Thu Jun 18 08:38:30 2009 From: mwhite at leporidae.net (Matt White) Date: Thu, 18 Jun 2009 11:38:30 -0400 Subject: [sldev] Display corruption when switching Anisotropic/Antialiasing hardware options In-Reply-To: <3bb9647e0906180833u24ebd7ceycc8c5f583b17ebc3@mail.gmail.com> References: <3bb9647e0906180833u24ebd7ceycc8c5f583b17ebc3@mail.gmail.com> Message-ID: On Thu, Jun 18, 2009 at 11:33 AM, Ricky wrote: > The effect is the same no matter what skin I use: The display turns > whitish, all text characters turn into rectangles, skin borders go > away, etc. > > [repo deleted] > > If I can get another repo (especially on another platform,) I'll open > a JIRA report. ?I'll also be testing on Windows XP and OSX in the next > 24 hours. I can confirm this on Vista. It's a fairly minor thing - the viewer doesn't crash and everything returns to normal on a restart. (Sometimes just resizing the window will bring it back as well.) - Matt From mike.dickson at hp.com Thu Jun 18 09:16:02 2009 From: mike.dickson at hp.com (Mike Dickson) Date: Thu, 18 Jun 2009 11:16:02 -0500 Subject: [sldev] I found a possible problem on linux (gdk/gtk related) In-Reply-To: <20090618144953.GA31637@alinoe.com> References: <20090618144953.GA31637@alinoe.com> Message-ID: <1245341762.26216.28.camel@mdickson-laptop> As long as all the drawing is done on the main thread there's no reason to initialize the toolkit for threading. I've never had any real positive experience with GTK and threading. Especially since many of the libraries you might use are likely not thread safe. Certainly can use threads for computation but if you make proper use of the eventing system and use idle_add to push gtk stuff onto the main thread. Yes, I know gtk and thread can supposedly be done. I've just never had much luck with it personally. The above patterns work much better for me. Mike On Thu, 2009-06-18 at 14:49 +0000, Carlo Wood wrote: > My question is: what percentage of the users is using linux? > > Here I am assuming that linux users, and only linux users, are > using the GTK part (and gstreamer). > > I have reason to believe that GTK is not being used thread-safe, > which should cause random crashes on linux. The reason that I > believe this is because I started to use GTK seriously from > a new thread which immediately caused very frequent crashes > (more than 95% of the time) which led me quickly to find out > that gdk threading wasn't initialized (no locking takes place > at all in the current viewer). > > I added that initialization and locking, and added some necessary > (missing) locking calls... until my new thread ran perfectly. > > However, what I run into now are deadlocks (without using my new > thread). This indicates that the viewer (without my changes) is > using gdk/gtk from two different threads at the same time (and > without locking thus). That this works in most cases could be > just luck. > > I was/am planning to provide a patch for this, but I'm busy :p > So, hence the question at the top. I'd expect crashes on linux > while people are playing music and open a file picker window > at the same time; if this is not the case, then I guess that > the gstreamer mainloop doesn't bite the filepicker by coincidence, > what would make this a not so hight priority to fix though. > > Carlo Wood > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From dzonatas at gmail.com Thu Jun 18 09:43:10 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Thu, 18 Jun 2009 09:43:10 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <4A3A5E9D.3@Gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> Message-ID: <4A3A6E9E.4040707@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/e97b0a0a/attachment.htm From carlo at alinoe.com Thu Jun 18 09:33:13 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 18 Jun 2009 18:33:13 +0200 Subject: [sldev] I found a possible problem on linux (gdk/gtk related) In-Reply-To: <1245341762.26216.28.camel@mdickson-laptop> References: <20090618144953.GA31637@alinoe.com> <1245341762.26216.28.camel@mdickson-laptop> Message-ID: <20090618163313.GA10137@alinoe.com> On Thu, Jun 18, 2009 at 11:16:02AM -0500, Mike Dickson wrote: > As long as all the drawing is done on the main thread there's no reason > to initialize the toolkit for threading. I've never had any real > positive experience with GTK and threading. Especially since many of > the libraries you might use are likely not thread safe. Certainly can > use threads for computation but if you make proper use of the eventing > system and use idle_add to push gtk stuff onto the main thread. > > Yes, I know gtk and thread can supposedly be done. I've just never had > much luck with it personally. The above patterns work much better for > me. The main reason I want to do this is because currently every call to gtk_main() (ie, every gtk window; like file upload / download file pickers) *completely* freeze the (mainloop of the) viewer. If you don't pick a file right away, you time out! After my changes, you can just open a file picker window, and move it around, not resulting anymore in a black screen. Everything continues to work perfectly. This is how it should be; not stupid time outs. I solve the deadlock in the meantime anyway... I needed it to be fixed myself, it was annoying. But there is no high priority to make a patch for snowglobe until I'd include a patch to make the filepickers non-blocking, as it turns out not to be a dead lock due to multiple threads using gtk, but it was a recursive call because I had been too laze to wrap all gtk_main()'s in 'enter'/'leave' functions. -- Carlo Wood From overdrive at dceo.rutgers.edu Thu Jun 18 09:40:37 2009 From: overdrive at dceo.rutgers.edu (Ron Festa) Date: Thu, 18 Jun 2009 12:40:37 -0400 Subject: [sldev] Display corruption when switching Anisotropic/Antialiasing hardware options Message-ID: <3c59673d0906180940m30ca60e0ua602a9ce81ae1158@mail.gmail.com> I've had this issue too. I'm running Ubuntu 9.04 32bit with a Geforce 9500GT. I haven't yet tried Snowglobe, but with 1.23 if I enabled FSAA & AF I got that corruption till I closed the client. The good thing is when I restarted it, it retained my setting changes and had no graphical corruption. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/2996b0d9/attachment.htm From snowfox102 at dragonkeepcreations.com Thu Jun 18 10:43:11 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Thu, 18 Jun 2009 12:43:11 -0500 Subject: [sldev] Rendering Limits In-Reply-To: References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <939372.98867.qm@web59104.mail.re1.yahoo.com> Message-ID: <4A3A7CAF.7080006@dragonkeepcreations.com> Soft wrote: > On Thu, Jun 18, 2009 at 10:18 AM, Ann Otoole wrote: > >> Also you should be embarrassed for categorizing as and calling most of the >> content creators and artists in Second Life griefers. >> > > Nicely trolled. That was nowhere in my text. Yeah, it was. Soft wrote: > I think more time didn't go into that because the few non-griefer > assets we were given were overkill for a space the size of a room, let > alone as an attachment. The vast majority of jewelry pieces are fairly high poly, therefore you're saying most jewelry content creators are greifers, whether you meant to or not. I'm not saying I agree with such high poly builds, but they're only a problem when a person is wearing multiple pieces that are of a particularly high level of detail, so it's a non issue. LL shouldn't be meddling in how much detail a person is allowed to see anyway. And Ann is right, while it's the customers that do the buying, without us, the content creators, LL doesn't make money and its employees don't get paid. Users first, personal preferences second. Maya From robertltux at gmail.com Thu Jun 18 10:51:32 2009 From: robertltux at gmail.com (Robert Martin) Date: Thu, 18 Jun 2009 13:51:32 -0400 Subject: [sldev] Rendering Limits In-Reply-To: <4A3A7CAF.7080006@dragonkeepcreations.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <939372.98867.qm@web59104.mail.re1.yahoo.com> <4A3A7CAF.7080006@dragonkeepcreations.com> Message-ID: also there is the problem of "furry" avatars if you want to be anything above a "toon" your av will eat prims even with "human" avs females tend to have a lot of prims in Hair, skirts, prim attachments (poof sleeves and such). I would say have a limit but put it where it should not be a problem (high graphics at near max level medium graphics at 110% of "reasonable" low graphics at 90% of "reasonable"). Ive got a low end card on this system and i have rendermax set to 6000 at the moment with zero problems. -- Robert L Martin From missannotoole at yahoo.com Thu Jun 18 10:56:30 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 18 Jun 2009 10:56:30 -0700 (PDT) Subject: [sldev] Snowglobe Release Candidate download links (hopefully) In-Reply-To: <4A39E77C.1060800@lindenlab.com> References: <4A39E77C.1060800@lindenlab.com> Message-ID: <330419.86948.qm@web59101.mail.re1.yahoo.com> 4.5 hours in world and no crash. I see a specific texture rerezzing frequently though. Just one texture on one specific sculpty. It is a ribbon from the fantasy fair for RFL ribbon hunt. I did not create it so I can't get the UUIDs involved. They will be dropped all over those regions over the next few days by the fantasy fair people in case anyone feels like trying to find one for a repro. ________________________________ From: Rob Lanphier To: Second Life Developer Mailing List Sent: Thursday, June 18, 2009 3:06:36 AM Subject: [sldev] Snowglobe Release Candidate download links (hopefully) Hi folks The Windows and Mac builds of the Snowglobe viewer just got done, and the Linux versino should be rolling off the build machine shortly. If my powers of prediction are correct, here's the links for the upcoming builds. Windows http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1-0-0-2435_Setup.exe Mac http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1_0_0_2435_SNOWGLOBERELEASE.dmg Linux http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe-i686-1.0.0.2435.tar.bz2 Barring any showstopper bugs (not present in 1.23, easily reproducable, and high impact for a large number of residents) or maybe extremely low-risk cosmetic fixes we'd like to get in, this build has a pretty good chance of being Snowglobe 1.0. So, please, really beat on this version. It's going to get into a lot of hands, so let's make sure this is a version that's going to leave a good first impression. Thanks! Rob _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/dee5f074/attachment.htm From kck325 at gmail.com Thu Jun 18 11:48:05 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Thu, 18 Jun 2009 13:48:05 -0500 Subject: [sldev] lscript_compile project build problem Message-ID: I am trying to run this on visual studio 2008, facing this problem... any clues? 1>------ Build started: Project: lscript_compile, Configuration: RelWithDebInfo Win32 ------ 1>Generating indra.y.cpp, indra.y.hpp 1>m4: cannot open `Files\GnuWin32/share/bison': No such file or directory 1>m4: cannot open `F:\Program': No such file or directory 1>m4: cannot open `Files\GnuWin32/share/bison/m4sugar/m4sugar.m4': No such file or directory -- Regards, Fraser -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/f4a34fbc/attachment.htm From soft at lindenlab.com Thu Jun 18 11:49:47 2009 From: soft at lindenlab.com (Soft) Date: Thu, 18 Jun 2009 13:49:47 -0500 Subject: [sldev] Rendering Limits In-Reply-To: <4A3A7CAF.7080006@dragonkeepcreations.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <939372.98867.qm@web59104.mail.re1.yahoo.com> <4A3A7CAF.7080006@dragonkeepcreations.com> Message-ID: On Thu, Jun 18, 2009 at 12:43 PM, Maya Remblai wrote: > Soft wrote: >> On Thu, Jun 18, 2009 at 10:18 AM, Ann Otoole wrote: > > Soft wrote: > >> I think more time didn't go into that because the few non-griefer >> assets we were given were overkill for a space the size of a room, let >> alone as an attachment. > > The vast majority of jewelry pieces are fairly high poly, therefore you're saying most > jewelry content creators are greifers, whether you meant to or not. Then you're saying that (a) most jewelry content was broken and (b) that copies of these were given to us? I can categorically state that neither is true. Re-read what I wrote above. If you have specific items, add locations where the items can be seen to the JIRA. We can't fix what we don't see. > LL shouldn't be meddling in how much detail a person is allowed to see > anyway. Residents' framerates and stability are very much something we meddle in. This solution was not perfect, and given infinite developers it would have been done differently. But laggy or destabilizing objects partly disappearing is an improvement over seemingly random crashes or lag that residents can't identify. Add details to JIRA, or help develop a patch with a better solution. That's what this list is for. From soft at lindenlab.com Thu Jun 18 11:54:24 2009 From: soft at lindenlab.com (Soft) Date: Thu, 18 Jun 2009 13:54:24 -0500 Subject: [sldev] lscript_compile project build problem In-Reply-To: References: Message-ID: On Thu, Jun 18, 2009 at 1:48 PM, chandra kiran kuchi wrote: > I am trying to run this on visual studio 2008, facing this problem... any > clues? > > 1>------ Build started: Project: lscript_compile, Configuration: > RelWithDebInfo Win32 ------ > 1>Generating indra.y.cpp, indra.y.hpp > 1>m4: cannot open `Files\GnuWin32/share/bison': No such file or directory > 1>m4: cannot open `F:\Program': No such file or directory > 1>m4: cannot open `Files\GnuWin32/share/bison/m4sugar/m4sugar.m4': No such > file or directory It's helpful to say which source branch you're building - trunk? snowglobe? 1.23 release? Also, Visual Studio 2008 will give you significant problems, no matter which branch you use. If at all possible, getting a copy of Visual Studio 2005 will make your life easier. From kck325 at gmail.com Thu Jun 18 12:08:08 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Thu, 18 Jun 2009 14:08:08 -0500 Subject: [sldev] lscript_compile project build problem In-Reply-To: References: Message-ID: Hi, I am using 1.21. Yeah I saw that across many forums, but unable to find Visual Studio 2005 Express edition. On Thu, Jun 18, 2009 at 1:54 PM, Soft wrote: > On Thu, Jun 18, 2009 at 1:48 PM, chandra kiran kuchi > wrote: > > I am trying to run this on visual studio 2008, facing this problem... any > > clues? > > > > 1>------ Build started: Project: lscript_compile, Configuration: > > RelWithDebInfo Win32 ------ > > 1>Generating indra.y.cpp, indra.y.hpp > > 1>m4: cannot open `Files\GnuWin32/share/bison': No such file or directory > > 1>m4: cannot open `F:\Program': No such file or directory > > 1>m4: cannot open `Files\GnuWin32/share/bison/m4sugar/m4sugar.m4': No > such > > file or directory > > It's helpful to say which source branch you're building - trunk? > snowglobe? 1.23 release? > > Also, Visual Studio 2008 will give you significant problems, no matter > which branch you use. If at all possible, getting a copy of Visual > Studio 2005 will make your life easier. > -- Regards, Chandra K Kuchi Graduate Student Experimental Computing Lab University of Cincinnati Cincinnati. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/c015077a/attachment.htm From robla at lindenlab.com Thu Jun 18 12:12:39 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 18 Jun 2009 12:12:39 -0700 Subject: [sldev] zlib patch for Snowglobe 1.0 (Re: Question about Snowglobe binaries) In-Reply-To: References: <4A39BC4B.80002@lindenlab.com> Message-ID: <4A3A91A7.3050406@lindenlab.com> I just filed the libz issue here: http://jira.secondlife.com/browse/SNOW-32 ...along with the patch we're probably going to apply today for a second release candidate (RC1) Rob On 06/17/2009 10:22 PM, Dahlia Trimble wrote: > Thanks for the hint Rob. Here's what I had to do to get Snowglobe to > start up: > > sudo ln -s /usr/lib32/libz.so.1.2.3.3 /usr/lib32/libz.so > > Also in Snowglobe-i686-0.9.0.2423/lib/ there was a circular reference > for libuuid.so.1 so I deleted it and copied libuuid.so.1 > from SecondLife-i686-1.23.4.123908/lib/ > > And now I'm happy that bump maps appear to be working in this version :) > > Regards, > -Dahlia > > > > On Wed, Jun 17, 2009 at 9:02 PM, Rob Lanphier > wrote: > > Here's what worked on my Jaunty 64-bit system: > * Make sure lib32z1 is installed > * cd /usr/lib32/ > * sudo ln -s /usr/lib32/libz.so.1 libz.so.1 > > After that, Snowglobe-y goodness. > > Someone willing to submit a patch to Snowglobe to make sure we link to > the right library without resorting to a symlink? > > See here for more about supporting Linux 64-bit: > https://jira.secondlife.com/browse/VWR-13793 > > Rob > > On 06/17/2009 06:02 PM, Dahlia Trimble wrote: > > I've been using Snowglobe "Second Life 1.23.2 (2324) May 27 2009 > > 15:18:08 (Second Life OSS)" on my Ubuntu 8.04 x64 system but > I've had > > difficulties with bump maps not working so I thought I'd try a newer > > version. > > > > I downloaded a newer linux build from this page: > > > https://lists.secondlife.com/pipermail/sldev-commits/2009-June/002823.html > and > > I get the following error when I try to execute it: > > > > Secondlife/Snowglobe-i686-0.9.0.2418 > > bin/snowglobe-do-not-run-directly: error while loading shared > > libraries: libz.so: cannot open shared object file: No such file or > > directory > > *** Bad shutdown. *** > > According to aptitude, the libz I'm using is the most recent for my > > distribution. Here is a listing of the relevant files: > > > > root at nkubuntu:/usr/lib :/usr/lib># ls -al libz.s* > > lrwxrwxrwx 1 root root 15 2008-07-29 21:59 libz.so -> > libz.so.1.2.3.3 > > lrwxrwxrwx 1 root root 15 2008-07-28 16:50 libz.so.1 -> > libz.so.1.2.3.3 > > -rw-r--r-- 1 root root 93536 2007-11-15 05:12 libz.so.1.2.3.3 > > > > Is there some other libz I would need to run these executables, > > hopefully one which would be compatible with other > > applications/libraries on my system? Or are there plans to > distribute > > recent binaries which would run in the same environments as the > > production SL viewers? > > > > Also a suggestion: please consider offering 64 bit binaries :) > > > > Regards, > > -Dahlia > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated > posting privileges > > From robla at lindenlab.com Thu Jun 18 12:37:47 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 18 Jun 2009 12:37:47 -0700 Subject: [sldev] Status on Snowglobe release plus call to action Message-ID: <4A3A978B.8060404@lindenlab.com> Hi everyone, Call to action: * Download and run *the latest* version of Snowglobe * Provide reliable repros/data on issues referenced below * Come to the Open Source Meeting today and help test Info on all of this is below. As alluded to in my earlier mail, we're probably going to have to have a second release candidate for Snowglobe. We're working on a couple of minor fixes: Linux zlib problem: http://jira.secondlife.com/browse/SNOW-32 Mac installer cosmetic issues; http://jira.secondlife.com/browse/SNOW-33 We're not planning to fix the curl crash issues, since we don't seem to have a reliable repro case or any sense of what we'd need to fix. We're pretty comfortable that what we have right now is quite usable, and that with more usage, we'll get the data we need to fix any curl problems. That issue is here: http://jira.secondlife.com/browse/SNOW-2 Thickbrick also saw an issue here with clouds showing as grey: http://jira.secondlife.com/browse/SNOW-31 This one could be worrisome if its widespread. If it only happens for some people on rare occassions, we'll live with it. As stated earlier, please download and run *the latest* version of Snowglobe: Windows http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1-0-0-2435_Setup.exe Mac http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1_0_0_2435_SNOWGLOBERELEASE.dmg Linux http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe-i686-1.0.0.2435.tar.bz2 As you come to the Open Source Meeting today, please make sure you've installed the latest version of Snowglobe. We're going to try really beating on this thing, making sure that we've got something that we're all comfortable with. More on the meeting here: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda We're getting close to getting this thing done. Let's finish it off and get it out there. Thanks! Rob From missannotoole at yahoo.com Thu Jun 18 13:10:42 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 18 Jun 2009 13:10:42 -0700 (PDT) Subject: [sldev] Status on Snowglobe release plus call to action In-Reply-To: <4A3A978B.8060404@lindenlab.com> References: <4A3A978B.8060404@lindenlab.com> Message-ID: <736925.3253.qm@web59103.mail.re1.yahoo.com> 7 hours straight with no crash even after risking the switch turning on ansiotropic and 16x anti aliasing and switching it back off. This is the longest I have remained logged on SL in a while. Gonna see how long I can keep it running. ________________________________ From: Rob Lanphier To: Second Life Developer Mailing List Sent: Thursday, June 18, 2009 3:37:47 PM Subject: [sldev] Status on Snowglobe release plus call to action Hi everyone, Call to action: * Download and run *the latest* version of Snowglobe * Provide reliable repros/data on issues referenced below * Come to the Open Source Meeting today and help test Info on all of this is below. As alluded to in my earlier mail, we're probably going to have to have a second release candidate for Snowglobe. We're working on a couple of minor fixes: Linux zlib problem: http://jira.secondlife.com/browse/SNOW-32 Mac installer cosmetic issues; http://jira.secondlife.com/browse/SNOW-33 We're not planning to fix the curl crash issues, since we don't seem to have a reliable repro case or any sense of what we'd need to fix. We're pretty comfortable that what we have right now is quite usable, and that with more usage, we'll get the data we need to fix any curl problems. That issue is here: http://jira.secondlife.com/browse/SNOW-2 Thickbrick also saw an issue here with clouds showing as grey: http://jira.secondlife.com/browse/SNOW-31 This one could be worrisome if its widespread. If it only happens for some people on rare occassions, we'll live with it. As stated earlier, please download and run *the latest* version of Snowglobe: Windows http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1-0-0-2435_Setup.exe Mac http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1_0_0_2435_SNOWGLOBERELEASE.dmg Linux http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe-i686-1.0.0.2435.tar.bz2 As you come to the Open Source Meeting today, please make sure you've installed the latest version of Snowglobe. We're going to try really beating on this thing, making sure that we've got something that we're all comfortable with. More on the meeting here: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda We're getting close to getting this thing done. Let's finish it off and get it out there. Thanks! Rob _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/1201c822/attachment.htm From tinselsilvera at frontiernet.net Thu Jun 18 13:54:28 2009 From: tinselsilvera at frontiernet.net (tinselsilvera at frontiernet.net) Date: Thu, 18 Jun 2009 20:54:28 +0000 (UTC) Subject: [sldev] Snowglobe Release Candidate download links (hopefully) Message-ID: <251758708.5278411245358468048.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> I've been using the viewer inworld for several hours now with no crashes. I am finding one issue that may have already been discussed but I missed reading about. I'm standing on no build land. The "build" button at the bottom of my screen is blanked out as should be. However in the menu View > Build I can still rezz a prim on the no build land. Otherwise works and looks great so far. -- Tinsel Silvera Virtual Worlds Traveler http://tinselsilvera.blogspot.com/ From tinselsilvera at frontiernet.net Thu Jun 18 14:02:58 2009 From: tinselsilvera at frontiernet.net (tinselsilvera at frontiernet.net) Date: Thu, 18 Jun 2009 21:02:58 +0000 (UTC) Subject: [sldev] Snowglobe Release Candidate download links (hopefully) Message-ID: <768089987.5279471245358978556.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> Let me modify previous submission. I cannot build on land owned by others. However I can build on group deeded &/or set lands that I am a member of even though I do not have that group tag activated. Top bar shows building/rezzing not allowed. Bottom bar build option not pressable. But I can build through the View > Build menu option. -- Tinsel Silvera Virtual Worlds Traveler http://tinselsilvera.blogspot.com/ From zha.ewry at gmail.com Thu Jun 18 14:40:56 2009 From: zha.ewry at gmail.com (Zha Ewry) Date: Thu, 18 Jun 2009 17:40:56 -0400 Subject: [sldev] Status on Snowglobe release plus call to action In-Reply-To: <736925.3253.qm@web59103.mail.re1.yahoo.com> References: <4A3A978B.8060404@lindenlab.com> <736925.3253.qm@web59103.mail.re1.yahoo.com> Message-ID: <920d7d850906181440q785026b4l417025d799b89f50@mail.gmail.com> I've been using it as a primary client today, and I've seen one crash, while massively camera flying in a busy sim. Overall, tho, quite stable. I've even popped in and out of the deferred rending pipeline successfully. (I will note that the deferred pipeline is *very* slow, compared to some of the third party versions, or even snow globe a few weeks back, and still doesn't render in snapshots, but.. that's not anything that's on the supposed to work list for snowglobe) My impression is that it loads most scenes faster than the current 1.23.4 client, and it feels more smooth. ~ Zha On Thu, Jun 18, 2009 at 4:10 PM, Ann Otoole wrote: > 7 hours straight with no crash even after risking the switch turning on > ansiotropic and 16x anti aliasing and switching it back off. > > This is the longest I have remained logged on SL in a while. Gonna see how > long I can keep it running. > > ________________________________ > From: Rob Lanphier > To: Second Life Developer Mailing List > Sent: Thursday, June 18, 2009 3:37:47 PM > Subject: [sldev] Status on Snowglobe release plus call to action > > Hi everyone, > > Call to action: > *? Download and run *the latest* version of Snowglobe > *? Provide reliable repros/data on issues referenced below > *? Come to the Open Source Meeting today and help test > > Info on all of this is below. > > As alluded to in my earlier mail, we're probably going to have to have a > second release candidate for Snowglobe.? We're working on a couple of > minor fixes: > > Linux zlib problem: > http://jira.secondlife.com/browse/SNOW-32 > > Mac installer cosmetic issues; > http://jira.secondlife.com/browse/SNOW-33 > > We're not planning to fix the curl crash issues, since we don't seem to > have a reliable repro case or any sense of what we'd need to fix.? We're > pretty comfortable that what we have right now is quite usable, and that > with more usage, we'll get the data we need to fix any curl problems. > That issue is here: > http://jira.secondlife.com/browse/SNOW-2 > > Thickbrick also saw an issue here with clouds showing as grey: > http://jira.secondlife.com/browse/SNOW-31 > > This one could be worrisome if its widespread.? If it only happens for > some people on rare occassions, we'll live with it. > > As stated earlier, please download and run *the latest* version of > Snowglobe: > Windows > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1-0-0-2435_Setup.exe > Mac > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1_0_0_2435_SNOWGLOBERELEASE.dmg > Linux > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe-i686-1.0.0.2435.tar.bz2 > > As you come to the Open Source Meeting today, please make sure you've > installed the latest version of Snowglobe.? We're going to try really > beating on this thing, making sure that we've got something that we're > all comfortable with.? More on the meeting here: > https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > We're getting close to getting this thing done.? Let's finish it off and > get it out there. > > Thanks! > Rob > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From colin.kern at gmail.com Thu Jun 18 16:18:36 2009 From: colin.kern at gmail.com (Colin Kern) Date: Thu, 18 Jun 2009 16:18:36 -0700 Subject: [sldev] Snowglobe Release Candidate download links (hopefully) In-Reply-To: <4A39E77C.1060800@lindenlab.com> References: <4A39E77C.1060800@lindenlab.com> Message-ID: <77c421f00906181618i612d306dr49a098260e856c6e@mail.gmail.com> I'm seeing a weird glitch on the world map. A black square appears and disappears around the sim Danger Point as I scroll and zoom the map. The square is exactly the size of a 2x2 block of sims, and Danger Point fills the upper left of this block. Can anyone else reproduce this, or find it other places on the map? Colin On Thu, Jun 18, 2009 at 12:06 AM, Rob Lanphier wrote: > Hi folks > > The Windows and Mac builds of the Snowglobe viewer just got done, and > the Linux versino ?should be rolling off the build machine shortly. ?If > my powers of prediction are correct, here's the links for the upcoming > builds. > > Windows > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1-0-0-2435_Setup.exe > > Mac > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe_1_0_0_2435_SNOWGLOBERELEASE.dmg > > Linux > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2435/Snowglobe-i686-1.0.0.2435.tar.bz2 > > Barring any showstopper bugs (not present in 1.23, easily reproducable, > and high impact for a large number of residents) or maybe extremely > low-risk cosmetic fixes we'd like to get in, this build has a pretty > good chance of being Snowglobe 1.0. > > So, please, really beat on this version. ?It's going to get into a lot > of hands, so let's make sure this is a version that's going to leave a > good first impression. > > Thanks! > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From snowfox102 at dragonkeepcreations.com Thu Jun 18 16:37:44 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Thu, 18 Jun 2009 18:37:44 -0500 Subject: [sldev] Rendering Limits In-Reply-To: References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <939372.98867.qm@web59104.mail.re1.yahoo.com> <4A3A7CAF.7080006@dragonkeepcreations.com> Message-ID: <4A3ACFC8.300@dragonkeepcreations.com> Soft wrote: > Then you're saying that (a) most jewelry content was broken and (b) > that copies of these were given to us? I can categorically state that > neither is true. Re-read what I wrote above. > > If you have specific items, add locations where the items can be seen > to the JIRA. We can't fix what we don't see. > I never said you were given the examples. I've not heard of this "problem" before now so I couldn't have directed you anyway. I also don't make jewelry very often. As for content being "broken", it's not broken if the customers say it's not. If something is selling, that usually means people like it the way it is. LL has a bad habit of "fixing" things that aren't a problem for most users, and breaking content just because LL says there's a problem. They've been warned about that already, I won't go further here. > Residents' framerates and stability are very much something we meddle > in. This solution was not perfect, and given infinite developers it > would have been done differently. But laggy or destabilizing objects > partly disappearing is an improvement over seemingly random crashes or > lag that residents can't identify. I...eh, forget it. I'm tired, and only one person from LL has ever listened to me in the past, so I'm not even going to bother. Maya From jessesa at gmail.com Thu Jun 18 16:36:40 2009 From: jessesa at gmail.com (Jesse Barnett) Date: Thu, 18 Jun 2009 19:36:40 -0400 Subject: [sldev] Rendering Limits In-Reply-To: References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <939372.98867.qm@web59104.mail.re1.yahoo.com> <4A3A7CAF.7080006@dragonkeepcreations.com> Message-ID: This may not really be the right place but I sent a ping to Soft earlier today and now wanted to share a couple of opposing thoughts with everyone. Everyone knows I am an outspoken critic of some policies of LL(especially concerning the forums). I even made a couple of snarky remarks about this release until I started thinking about it some. But credit also needs to be given where credit is due....................... It has been a long time since I was actively involved with the dev community. I still build a viewer every now and then but have never submitted a patch. I am by no means an expert with C++ BUT I was there at the beginning when Rob joined and sldev was formed. I looked at the code then and have seen it now and even with an untrained eye, the viewer code is immensely improved over what it was and it will continue to improve. Even though I can not see the server code, the improvement on that side is also readily apparent to everyone. Not every release is perfect and sometimes content does get broken but we are still light years beyond the point where we were at just two years ago. Seems to be some outrage with this release but this is nothing compared to the past. Gone are the days of the Wednesday updates where a couple of times NO ONE could log in world for days afterwards. Hmmmmm, how long has it been since 5K online was really pushing the boundaries? There used to be major breakage with every jump of 5K concurrency and now that is a thing of the past. If you have content broken then it is always bad but please put it into context. The immediate problems will be solved and they will be solved without having to kick everyone off for a couple of days (or longer). Virtual cookies to all the devs, those with a Linden last name and those without. Hope everyone can forgive this intrusion and hopefully we can put this thread behind us. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/8ef07a78/attachment.htm From stickman at gmail.com Thu Jun 18 16:46:05 2009 From: stickman at gmail.com (Stickman) Date: Thu, 18 Jun 2009 16:46:05 -0700 Subject: [sldev] Rendering Limits In-Reply-To: References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <939372.98867.qm@web59104.mail.re1.yahoo.com> <4A3A7CAF.7080006@dragonkeepcreations.com> Message-ID: I've been attending school for production animation. Part of our education is for how to create models for video games. This doesn't make me an expert, but it does help me express an opinion. Many next-gen game engines (which Second Life currently is not, though I admit I'm impressed with how well it renders what's thrown at it while maintaining reasonable framerates) will have the MAIN CHARACTER of the main around 20,000 tris. Newer ones up that to as high as 80,000 tris, though generally those sorts of games tend not to have excessively detailed environments. I've looked many times, but have been unable to find a tri count for different sorts of primitives in Second Life. Assuming 1024 tris on a sculpty, the famous neckless in question is probably around 125,000 tris. But that's with a made up tri count. I'd need more info to make a proper call. My biggest beef with Second Life is that it does not educate content creators on the standard limits of their engine, and what's considered an acceptable build. So you get people creating excessively detailed and beautiful items that an art director would fire you for. I believe one of the fixes for this issue is for Second Life to determine what their engine is capable of, and release some guidelines for content creators about texture limits, primitive limits, shader limits, and etc, and include some better tools to help them determine how well content creators are fitting within these limits. Yes, every computer is different. That's why this wouldn't be a law, it would be a guildeline. Those that choose to follow it, may. Those that choose to create 172 prim necklaces may continue to do so. Because of the freeness of the camera in SL, a 172 prim necklace actually has a point, where in most games it would be severe, severe overkill. What if SL made a "test app" that used SL's engine, and attempted to render various polycounts, and submitted the stats and hardware back to LL, which would give them some hard numbers to work from? Heck, just a few special sims and an external tool that hooks into the viewer and sends back hardware details and stuff would work. Whatever is easiest on your end. -Stickman From chaosstar at gmail.com Thu Jun 18 17:19:31 2009 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 19 Jun 2009 02:19:31 +0200 Subject: [sldev] Rendering Limits In-Reply-To: References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <939372.98867.qm@web59104.mail.re1.yahoo.com> <4A3A7CAF.7080006@dragonkeepcreations.com> Message-ID: <9bb32d430906181719h64d5f2b7gde4bef981b5e9d61@mail.gmail.com> Thank you, Stickman. Some people don't seem to have any idea that while SL lacks many 'special effects' of modern games, it has vertexes/trianglecounts that make some other games look very very pale in comparison. Not that this is necessarily a good thing, mind you. It is partially a reason why SL performs so low in FPS compared to other games. Just to compare: Doom3 creatures have a polygon count of around 3000-4000. Yet people complain that the 50+k polygon avatar in SL renders slower than that game for example. Press ctrl+shift+1 in your client. Open the 'advanced' tab and look at 'ktris drawn'. I currently render 600K tris every frame. 600K. The lack of uploadable texture shaders, custom bumpmaps, reflection maps and the like often enough raise the -need- to go high with the triangle count. Quite frankly it shouldn't be like this, but currently..alas. Things might get better when the shadow code goes final, but still, SL currently has a way too high requirement for triangles to make things look proper. That, or very cleverly baked textures people tend to make in Maya, however most are simply not skilled for it, or..quite simply can't afford such a monster of an application. So there is the dilemma. People complaining about SL lagging on a 8800, yet raging when LL tackles a source of avatar lag that simply exists due to a technical circumstance. What to do indeed. I personally can live with those new render limits. To be honest, I haven't even noticed them at all yet, which is why I was so surprised to read about them in this thread. I honestly didn't notice in my everyday SL. And yes, I hang around high detail avatars. Personally I think LL -needs- to invest into the development of what is normal in many games. Shadows and light are coming. we need various texture map types, alpha maps, shaders, mesh import, reflection maps. We need to put things in that give detail without requiring lots of triangles. From robla at lindenlab.com Thu Jun 18 18:42:17 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 18 Jun 2009 18:42:17 -0700 Subject: [sldev] Timing of The Hippos Message-ID: <4A3AECF9.6030809@lindenlab.com> Hi everyone, In the rush to get Snowglobe out, I've neglected to mention what's going on with the Linden Lab Innovation Awards, aka The Hippos. For those of you not aware, this is what it is: https://wiki.secondlife.com/wiki/Linden_Lab_Innovation_Awards In years past, we've presented these awards at SLCC. SLCC is a great event, and we've always been really appreciative of the organizers who have made a spot for us to present these things. However, we've found that it's really important for there to be an in-world component for this event, for the obvious reason that this is about community participation in Second Life. So, in years past, we've made it a mixed reality event, and made sure that the nominees could be around in one place or the other. This year, we find ourselves trying to get something quite ambitious off the ground (Snowglobe) while not having the primary organizer for The Hippo awards (Liana) working in this area anymore. Liana really lead the charge on this effort, so with her spending 100% of her time on search, it's difficult to have something in place by SLCC that clears the high bar she set. This is a long winded way of saying "yes, we still plan to hold The Hippos for 2009", but not by SLCC. We haven't finalized the timing, but we're looking for something that roughly coincides with the anniversary of the original launch of our open source program: https://blogs.secondlife.com/community/features/blog/2007/01/08/embracing-the-inevitable We plan to focus our efforts toward making the inworld experience great, rather than leaving ourselves vulnerable to the gods of hotel wifi and a/v madness in order to make it work. Having something in January-ish makes for more of a "year in review". It also makes this one a rather long year (sorry), but I think we'll be happier with the timing in future years if we make this adjustment now. Anyway, sorry to disappoint those of you who were anticipating this happening really soon. Today's bug sprint made it really clear we've got a great community to work with and no shortage of potential nominees and worthy recipients. Thanks for everything you do, and don't hesitate to ask me if you have questions. Thanks, Rob From melinda at superliminal.com Thu Jun 18 19:03:01 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 18 Jun 2009 19:03:01 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <4A3A6E9E.4040707@gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> Message-ID: <4A3AF1D5.4060506@superliminal.com> I love what Jesse, Stickman, and Ambrosia have already said on this subject so I won't repeat them but I will heartily endorse their opinions. The one thing I will add is to drill a little deeper into what Dzonatas is suggesting here to refine the LOD selection mechanism. There is a large body of published research on this subject and I once implemented one particularly exciting algorithm from a SIGGRAPH proceedings in the mid 90's. I'm sorry that I can't find it but the basic idea was to use a modified knapsack algorithm (normally NP complete but cheap if you can accept quality within 90% of optimal) to select the greatest rendering result for the cost given a set of LODs for each object and heuristically calculated costs and benefits for each. This relates to Dzonatas' suggestion because moving objects do indeed reduce the benefits of drawing them at higher LOD. The question is not how fast the object or user is moving, but how fast a given object is moving in the user's screen space. So if you're flying forward, for example, you'd want high resolution directly in your direction of travel since objects there won't move much on your screen. The algorithm also gives weight to each object's size on the screen, so even that complicated necklace becomes worth the high LOD of the whole building you're in when you are admiring it close up. It even weights objects higher when they're near the center of your screen on the assumption that you're probably more interested in things you're pointed directly at. All this is to say that if we're going to get much more sophisticated in our handling of LOD, there are some excellent techniques available and it might be best to consider a holistic approach to the problem rather than to grow another ad hoc solution. -Melinda Dzonatas Sol wrote: > Further, it would be good to know how many times the limit was hit per > frame, if the limit is done per render object (being prims that share > the same linkset or the same axis origin). If the limit is hit often, > then it would be a way to let the user know the scene is too complex > for their graphics platform. Some settings could be changed > automatically in order for the user experience to stay relatively > responsive. > > The rumor is that the limit is a cutoff per frame right now for > enumerated vertices. If that is true, then the above suggestion is > only workable if a limit is made for a maxium per object as above. > > With this, for example, there could be logic for: if( !moving ) > renderHigherDetail() else if( movingfast ) renderLowerDetail() else > renderNormalDetail() > > Tigro Spottystripes wrote: >> would it be too hard to make things that are above the limit be LOD'ed >> down gradually, and only start unrendering things when a huge chunk of >> everything on screen is already at lowest LOD? >> >> Also, any such limits should be a slider with a typeable textbox next to >> it on the graphics tab of the preferences screen IMO. >> >> Moriz Gupte escreveu: >> >>> I think rendering limits are inevitable, resources tend not to be >>> unlimited. There will be disagreements regarding rendering >>> prioritizations/limits ... this is to be expected. Perhaps one >>> approach would be to see how much pain is inflicted on the community >>> if a limit is imposed. If most don't even notice it, then it's >>> probably a proper rendering limitation...which would then qualify as >>> an 'optimization'. One thing is very helpful though, and think Soft >>> has done some of it already, is to publish these limitations and how >>> it impacts rendering (must be easier for LL to initiate that than the >>> community). *forgive me * if this is published somewhere already, may >>> be share the link. >>> >>> >>> >>> On Thu, Jun 18, 2009 at 8:53 AM, Soft wrote: >>> >>> >>>> Try creating a 128x128 sculpted prim, then link 255 of those together >>>> in a 16x16 grid (remove one to make 255). Then scale them down as far >>>> as they'll go and wear it like a badge. You should start to see some >>>> prims in the set vanish. >>>> >>>> On Thu, Jun 18, 2009 at 2:59 AM, Ambrosia wrote: >>>> >>>> >>>>> This is news to me as well. Rendering limits? Which? I personally have >>>>> not noticed anything that I might recognize as a new rendering limit? >>>>> >>>>> On Wed, Jun 17, 2009 at 16:02, Harleen Gretzky wrote: >>>>> >>>>> >>>>>> Can you elaborate on what the new rendering limits are? >>>>>> >>>>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting privileges >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From kck325 at gmail.com Thu Jun 18 19:18:16 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Thu, 18 Jun 2009 21:18:16 -0500 Subject: [sldev] lscript_compile project build problem In-Reply-To: References: Message-ID: Hello, I was able to resolve that by installing bison in the program\files directory instead of program files. But I am facing another problem, looks like case of missing library, stack trace is 1>'FLEX-NOTFOUND' is not recognized as an internal or external command, 1>operable program or batch file. Which library is missing? On Thu, Jun 18, 2009 at 2:08 PM, chandra kiran kuchi wrote: > Hi, > > I am using 1.21. > > Yeah I saw that across many forums, but unable to find Visual Studio 2005 > Express edition. > > > > On Thu, Jun 18, 2009 at 1:54 PM, Soft wrote: > >> On Thu, Jun 18, 2009 at 1:48 PM, chandra kiran kuchi >> wrote: >> > I am trying to run this on visual studio 2008, facing this problem... >> any >> > clues? >> > >> > 1>------ Build started: Project: lscript_compile, Configuration: >> > RelWithDebInfo Win32 ------ >> > 1>Generating indra.y.cpp, indra.y.hpp >> > 1>m4: cannot open `Files\GnuWin32/share/bison': No such file or >> directory >> > 1>m4: cannot open `F:\Program': No such file or directory >> > 1>m4: cannot open `Files\GnuWin32/share/bison/m4sugar/m4sugar.m4': No >> such >> > file or directory >> >> It's helpful to say which source branch you're building - trunk? >> snowglobe? 1.23 release? >> >> Also, Visual Studio 2008 will give you significant problems, no matter >> which branch you use. If at all possible, getting a copy of Visual >> Studio 2005 will make your life easier. >> > > > > -- > > -- Regards, Fraser -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/ed5149f0/attachment.htm From lenglish5 at cox.net Thu Jun 18 21:18:59 2009 From: lenglish5 at cox.net (Lawson English) Date: Thu, 18 Jun 2009 21:18:59 -0700 Subject: [sldev] Display corruption when switching Anisotropic/Antialiasing hardware options In-Reply-To: <3bb9647e0906180833u24ebd7ceycc8c5f583b17ebc3@mail.gmail.com> References: <3bb9647e0906180833u24ebd7ceycc8c5f583b17ebc3@mail.gmail.com> Message-ID: <4A3B11B3.6060701@cox.net> Ricky wrote: > At least snowglobe (1.0.0.0.2435) doesn't crash! I tried repoing on > 1.23_rc4, but it crashed instead of corrupting... > > The effect is the same no matter what skin I use: The display turns > whitish, all text characters turn into rectangles, skin borders go > away, etc. > > Restarting Snowglobe fixes the issue. > > Can anyone else repo? The steps are as follows: > 1: Start Snowglobe (don't log in) > 2: Goto Edit->Preferences > 3: Select the Graphics tab > 4: Pres the "Hardware Options" button > 5: Select the Anisotropic Filtering checkbox, and set Antialiasing to > 4x or more. > > If at first it doesn't corrupt, try other AA values. > > I am running Gentoo with KDE4.2.4: > -------------------------------------------- > Snowglobe 1.0.0 (2435) Jun 18 2009 00:25:30 (Snowglobe Release) > Release Notes > > Built with GCC version 40102 > > On a bootstrapped Mac running XP, I get a situation where avatar skins look cloud-ruthed indefinitely, when I set anti-aliasing on. No crashes from that specifically, though it seems a tad unstable overall. If I turn anti-aliasing off, the avatars revert. On the same Mac running Mac OS X 10.5.7, I don't get visual artifacts (just drastic slowdown) at any setting, but sometimes, the scene goes completely black or close to it, and I need to TP to correct the situation. Occasional random crashes when I'm testing on MacOS X, but nothing obviously reproduceable. L From missannotoole at yahoo.com Thu Jun 18 22:33:58 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 18 Jun 2009 22:33:58 -0700 (PDT) Subject: [sldev] Status on Snowglobe release plus call to action In-Reply-To: <736925.3253.qm@web59103.mail.re1.yahoo.com> References: <4A3A978B.8060404@lindenlab.com> <736925.3253.qm@web59103.mail.re1.yahoo.com> Message-ID: <138882.62262.qm@web59102.mail.re1.yahoo.com> Made it to the 16 hours logged in mark and then the client decided to log me out with the sim having issues message. I was able to log back in immediately and the same people were in the sim so the sim was not restarting or anything like that. Longest I have been able to keep a client logged on for a very long time. Observation: In the other viewers I noticed it typically used 1.3GB memory. This viewer seems to load and retain more textures yet averages 830MB with increases in some notoriously high lag regions to 1.1GB. Then the memory drops back to 830MB steady once out of the laggy sims. Something seems to be greatly improved with memory. :) ________________________________ From: Ann Otoole To: Rob Lanphier ; Second Life Developer Mailing List Sent: Thursday, June 18, 2009 4:10:42 PM Subject: Re: [sldev] Status on Snowglobe release plus call to action 7 hours straight with no crash even after risking the switch turning on ansiotropic and 16x anti aliasing and switching it back off. This is the longest I have remained logged on SL in a while. Gonna see how long I can keep it running. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090618/fa7ba8f2/attachment.htm From kf6kjg at gmail.com Thu Jun 18 23:37:36 2009 From: kf6kjg at gmail.com (Ricky) Date: Fri, 19 Jun 2009 06:37:36 +0000 Subject: [sldev] Display corruption when switching Anisotropic/Antialiasing hardware options In-Reply-To: <4A3B11B3.6060701@cox.net> References: <3bb9647e0906180833u24ebd7ceycc8c5f583b17ebc3@mail.gmail.com> <4A3B11B3.6060701@cox.net> Message-ID: <3bb9647e0906182337i7ab5f189gd6602495caf2c46f@mail.gmail.com> Hehe, too bad I didn't have the time last night to hunt JIRA... Lares Carter created VWR-12955 on 23/Apr/09, and that was exactly the problem I was observing. Thanks all for your speedy repos and even the "didn't fail for me" response! Now to add our 2 cents to the JIRA! Ricky aka Cron Stardust On Fri, Jun 19, 2009 at 4:18 AM, Lawson English wrote: > Ricky wrote: >> >> At least snowglobe (1.0.0.0.2435) doesn't crash! I tried repoing on >> 1.23_rc4, but it crashed instead of corrupting... >> >> The effect is the same no matter what skin I use: The display turns >> whitish, all text characters turn into rectangles, skin borders go >> away, etc. >> >> Restarting Snowglobe fixes the issue. >> >> Can anyone else repo? The steps are as follows: >> 1: Start Snowglobe (don't log in) >> 2: Goto Edit->Preferences >> 3: Select the Graphics tab >> 4: Pres the "Hardware Options" button >> 5: Select the Anisotropic Filtering checkbox, and set Antialiasing to >> 4x or more. >> >> If at first it doesn't corrupt, try other AA values. >> >> I am running Gentoo with KDE4.2.4: >> -------------------------------------------- >> Snowglobe 1.0.0 (2435) Jun 18 2009 00:25:30 (Snowglobe Release) >> Release Notes >> >> Built with GCC version 40102 >> >> > > On a bootstrapped Mac running XP, I get a situation where avatar skins look > cloud-ruthed indefinitely, when > I set anti-aliasing on. No crashes from that specifically, though it seems a > tad unstable overall. > > If I turn anti-aliasing off, the avatars revert. > > On the same Mac running Mac OS X 10.5.7, I don't get visual artifacts (just > drastic slowdown) at any setting, > but sometimes, the scene goes completely black or close to it, and I need to > TP to correct the situation. > > Occasional random crashes when I'm testing on MacOS X, but nothing obviously > reproduceable. > > > > > L > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/e4cbecec/attachment.htm From robla at lindenlab.com Fri Jun 19 02:45:14 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 19 Jun 2009 02:45:14 -0700 Subject: [sldev] Snowglobe RC1 Message-ID: <4A3B5E2A.6020206@lindenlab.com> Hi folks, Another day, another RC. In this case, RC1, though it's probably less ambiguous to refer to "build 2446" (see [1]). Upgrading to this version is very important if you're on Windows. While Windows users shouldn't see much of a difference from RC0, the crash reports we get should be more useful. Here's the list of RC1 builds: Win32: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe_1-0-1-2446_Setup.exe Mac: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe_1_0_1_2446.dmg Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe-i686-1.0.1.2446.tar.bz2 Let us know if we should put the brakes on this release, or if we've cleared the "good enough" threshold. Thanks! Rob [1] If you were hitting "reload" on the Snowglobe homepage, you might have seen a couple of earlier builds listed as "RC 1": https://wiki.secondlife.com/w/index.php?title=Template:Snowglobe-installers&action=history From dahliatrimble at gmail.com Fri Jun 19 04:06:41 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri, 19 Jun 2009 04:06:41 -0700 Subject: [sldev] Snowglobe RC1 In-Reply-To: <4A3B5E2A.6020206@lindenlab.com> References: <4A3B5E2A.6020206@lindenlab.com> Message-ID: Hi Rob, I'm still having the same circular reference problem with this latest linux build. Here's what's left of the error message that didn't scroll off my xterm: 64-bit Linux detected: Disabling GStreamer (streaming video and music) by default; edit ./snowglobe to re-enable. Running from /home/dt/Secondlife/Snowglobe-i686-1.0.1.2446 bin/snowglobe-do-not-run-directly: error while loading shared libraries: libuuid.so.1: cannot open shared object file: No such file or directory *** Bad shutdown. *** You are running the Second Life Viewer on a x86_64 platform. The most common problems when launching the Viewer (particularly 'bin/snowglobe-do-not-run-directly: not found' and 'error while loading shared libraries') may be solved by installing your Linux distribution's 32-bit compatibility packages. For example, on Ubuntu and other Debian-based Linuxes you might run: $ sudo apt-get install ia32-libs ia32-libs-gtk ia32-libs-kde ia32-libs-sdl ******************************************************* This is a BETA release of the Second Life linux client. Thank you for testing! Please see README-linux.txt before reporting problems. And here is the file: ~/Secondlife/Snowglobe/lib$ ls -al libuuid.so.1 lrwxrwxrwx 1 dt dt 12 2009-06-19 03:54 libuuid.so.1 -> libuuid.so.1 As you can see it is a symbolic link that points to itself. Once again, deleting this link and copying the libuuid.so.1 from the latest production viewer solves the problem. On Fri, Jun 19, 2009 at 2:45 AM, Rob Lanphier wrote: > Hi folks, > Another day, another RC. In this case, RC1, though it's probably less > ambiguous to refer to "build 2446" (see [1]). Upgrading to this version > is very important if you're on Windows. While Windows users shouldn't > see much of a difference from RC0, the crash reports we get should be > more useful. > > Here's the list of RC1 builds: > > Win32: > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe_1-0-1-2446_Setup.exe > Mac: > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe_1_0_1_2446.dmg > Linux: > > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe-i686-1.0.1.2446.tar.bz2 > > Let us know if we should put the brakes on this release, or if we've > cleared the "good enough" threshold. > > Thanks! > Rob > > > [1] If you were hitting "reload" on the Snowglobe homepage, you might > have seen a couple of earlier builds listed as "RC 1": > > https://wiki.secondlife.com/w/index.php?title=Template:Snowglobe-installers&action=history > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/ed883ad9/attachment-0001.htm From meni.kaiousei at gmail.com Fri Jun 19 06:12:07 2009 From: meni.kaiousei at gmail.com (Meni Kaiousei) Date: Fri, 19 Jun 2009 15:12:07 +0200 Subject: [sldev] Snowglobe RC1 In-Reply-To: <4A3B5E2A.6020206@lindenlab.com> References: <4A3B5E2A.6020206@lindenlab.com> Message-ID: <7139dfaa0906190612k3b7c43cbkdb6198694917bbd0@mail.gmail.com> Hoi Rob, I have this issue with the mac build: * For some reason I cannot drag the Snowglobe icon to the Application folder for installation. However, I can install the application when I drag the text "Snowglobe.app". Regards, Meni On Fri, Jun 19, 2009 at 11:45, Rob Lanphier wrote: > Hi folks, > Another day, another RC. ?In this case, RC1, though it's probably less > ambiguous to refer to "build 2446" (see [1]). ?Upgrading to this version > is very important if you're on Windows. ?While Windows users shouldn't > see much of a difference from RC0, the crash reports we get should be > more useful. > > Here's the list of RC1 builds: > > Win32: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe_1-0-1-2446_Setup.exe > Mac: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe_1_0_1_2446.dmg > Linux: > http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe-i686-1.0.1.2446.tar.bz2 > > Let us know if we should put the brakes on this release, or if we've > cleared the "good enough" threshold. > > Thanks! > Rob > > > [1] ?If you were hitting "reload" on the Snowglobe homepage, you might > have seen a couple of earlier builds listed as "RC 1": > https://wiki.secondlife.com/w/index.php?title=Template:Snowglobe-installers&action=history > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From mwhite at leporidae.net Fri Jun 19 06:20:44 2009 From: mwhite at leporidae.net (Matt White) Date: Fri, 19 Jun 2009 09:20:44 -0400 Subject: [sldev] Snowglobe - False Min Specs Warning Message-ID: Hello! Snowglobe 2246 is warning me that my system doesn't meet the min specs for Second Life. (The normal viewer doesn't do this.) This system is very much a supported configuration: CPU: Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (2327 MHz) Memory: 9214 MB OS Version: Microsoft Windows XP x64 Edition Service Pack 2 (Build 3790) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 260/PCI/SSE2 Windows Graphics Driver Version: 6.14.0011.8585 OpenGL Version: 3.0.0 ...it then proceeds to come up in a minimal graphics configuration, giving me over 150fps. :) - Matt From mwhite at leporidae.net Fri Jun 19 06:32:00 2009 From: mwhite at leporidae.net (Matt White) Date: Fri, 19 Jun 2009 09:32:00 -0400 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: Message-ID: On Fri, Jun 19, 2009 at 9:20 AM, Matt White wrote: > Snowglobe 2246 is warning me that my system doesn't meet the min specs for Second Life. Grr. Typeo. That should be 2446: Snowglobe 1.0.1 (2446) Jun 19 2009 02:26:09 (Snowglobe Release) - Matt From I_really_needed_a_new_mailbox at gmx.de Fri Jun 19 06:42:24 2009 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Fri, 19 Jun 2009 15:42:24 +0200 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: Message-ID: Needs moar RAM. ^^ on a more serious note: Maybe connected to http://jira.secondlife.com/browse/VWR-8339 ? I had the min specs warning on my notebook with the regular viewer sometimes, while it was a false positive as well. I guess that people who own high-end PCs won't take it serious anyway. --zai Memory: 9214 MB > > - Matt > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/d063c202/attachment.htm From soft at lindenlab.com Fri Jun 19 06:45:14 2009 From: soft at lindenlab.com (Soft) Date: Fri, 19 Jun 2009 08:45:14 -0500 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: Message-ID: On Fri, Jun 19, 2009 at 8:32 AM, Matt White wrote: > On Fri, Jun 19, 2009 at 9:20 AM, Matt White wrote: > >> Snowglobe 2246 is warning me that my system doesn't meet the min specs for Second Life. > > Grr. Typeo. That should be 2446: > > Snowglobe 1.0.1 (2446) Jun 19 2009 02:26:09 (Snowglobe Release) Windows XP x64 is very much unsupported. It peaked with as many users as a small Linux distro and has only been shrinking since. But if you would capture this in a JIRA and search for the block in the log file where it's doing system identification (or email me your log privately), we'll see if there's a quick fix. You might also give Vista 64 a try if you haven't yet. xp64's 32-bit compatibility subsystem is a mess. Even if Vista 64 is more bloated, its 32-bit compatibility is far better. Vista 64 also makes much better use of that extra memory for disk cache. Does 1.23 misguess your card's capabilities as well? From missannotoole at yahoo.com Fri Jun 19 07:08:56 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 19 Jun 2009 07:08:56 -0700 (PDT) Subject: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly In-Reply-To: References: Message-ID: <578355.6920.qm@web59104.mail.re1.yahoo.com> Some people on the xstreetsl.com forums are reporting textures don't load or load more slowly in Snowglobe. I doubt we can get them to participate in pjira issue reports. So I thought I would mention it here. I find it odd since I have such fast texture loading speeds on my system using Snowglobe. I'm curious as to why one computer would get high speeds with snowglobe and poor performance in the normal 1.22/1.23 while another gets bad performance in both. Could it be anti virus systems or something? I use Avast which scans everything coming in yet I still get good speeds in Snowglobe. Perhaps they are using anti virus inline scanners that are terribly slow? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/4661cee1/attachment.htm From jesseSA at gmail.com Fri Jun 19 07:15:33 2009 From: jesseSA at gmail.com (jesseSA at gmail.com) Date: Fri, 19 Jun 2009 14:15:33 +0000 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: Message-ID: <001636283b0a53a64f046cb42804@google.com> On Jun 19, 2009 9:45am, Soft wrote: > You might also give Vista 64 a try if you haven't yet. xp64's 32-bit > compatibility subsystem is a mess. Even if Vista 64 is more bloated, > its 32-bit compatibility is far better. Vista 64 also makes much > better use of that extra memory for disk cache. If you were going to go this route then I would suggest skipping Vista and going straight for Windows 7 Release Candidate. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/6842ede4/attachment.htm From mwhite at leporidae.net Fri Jun 19 07:15:49 2009 From: mwhite at leporidae.net (Matt White) Date: Fri, 19 Jun 2009 10:15:49 -0400 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: Message-ID: On Fri, Jun 19, 2009 at 9:45 AM, Soft wrote: > Windows XP x64 is very much unsupported. It peaked with as many users > as a small Linux distro and has only been shrinking since. But if you > would capture this in a JIRA and search for the block in the log file > where it's doing system identification (or email me your log > privately), we'll see if there's a quick fix. I'll email it off to you privately. Second Life runs very nicely on XP x64, but I didn't know it wasn't an officially supported OS by LL. (I'm an IT professional that uses a lot of virtual machines. It's not uncommon for me to have 3-4 VMs running at once, which is why I shoved this box full of RAM and installed XP x64.) > Does 1.23 misguess your card's capabilities as well? Just installed the stock 1.23 and didn't get a warning. - Matt From kck325 at gmail.com Fri Jun 19 07:33:49 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Fri, 19 Jun 2009 09:33:49 -0500 Subject: [sldev] lscript_compile project build problem In-Reply-To: References: Message-ID: Well I was able to solve that problem too. Can somebody help me with this problem? It came on the build in latest version from trunk. libboost_program_options-vc80-mt-1_34_1.lib(cmdline.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::_String_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::erase(class std::_String_iterator,class std::allocator >)" (__imp_?erase@?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QAE?AV?$_String_iterator at DU?$char_traits at D@std@ @V?$allocator at D@2@@2 at V32@@Z) referenced in function "public: class std::vector,class std::allocator > > __thiscall boost::program_options::detail::cmdline::parse_short_option(class std::vector,class std::allocator >,class std::allocator,class std::allocator > > > &)" (?parse_short_option at cmdline @detail at program_options@boost@@QAE?AV?$vector at V?$basic_option at D @program_options at boost@@V?$allocator at V?$basic_option at D@program_options at boost @@@std@@@std@@AAV?$vector at V?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@V?$allocator at V?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@@2@@6@@Z) 1>libboost_program_options-vc80-mt-1_34_1.lib(convert.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) const std::locale::facet::`vftable'" (__imp_??_7facet at locale@std@@6B@) referenced in function "public: virtual __thiscall boost::program_options::detail::utf8_codecvt_facet::~utf8_codecvt_facet(void)" (??1utf8_codecvt_facet at detail@program_options at boost@@UAE at XZ) 1>libboost_program_options-vc80-mt-1_34_1.lib(convert.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) private: static void __cdecl std::locale::facet::facet_Register(class std::locale::facet *)" (__imp_?facet_Register at facet@locale at std@@CAXPAV123@@Z) referenced in function "class std::codecvt const & __cdecl std::use_facet >(class std::locale const &)" (??$use_facet at V?$codecvt at _WDH@std@@@std@@YAABV?$codecvt at _WDH@0 @ABVlocale at 0@@Z) 1>libboost_program_options-vc80-mt-1_34_1.lib(convert.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static unsigned int __cdecl std::codecvt::_Getcat(class std::locale::facet const * *)" (__imp_?_Getcat@?$codecvt at _WDH@std@@SAIPAPBVfacet at locale@2@@Z) referenced in function "class std::codecvt const & __cdecl std::use_facet >(class std::locale const &)" (??$use_facet at V?$codecvt at _WDH@std@@@std@@YAABV?$codecvt at _WDH@0 @ABVlocale at 0@@Z) 1>libboost_program_options-vc80-mt-1_34_1.lib(convert.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::replace(class std::_String_iterator,class std::allocator >,class std::_String_iterator,class std::allocator >,class std::basic_string,class std::allocator > const &)" (__imp_?replace@?$basic_string@ _WU?$char_traits at _W@std@@V?$allocator at _W@2@@std@@QAEAAV12 at V ?$_String_iterator at _WU?$char_traits at _W@std@@V?$allocator at _W@2@@2 at 0ABV12@@Z) referenced in function "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::_Replace(class std::_String_iterator,class std::allocator >,class std::_String_iterator,class std::allocator >,wchar_t *,wchar_t *,struct std::input_iterator_tag)" (??$_Replace at PA_W@?$basic_string@ _WU?$char_traits at _W@std@@V?$allocator at _W@2@@std@@QAEAAV01 at V ?$_String_iterator at _WU?$char_traits at _W@std@@V?$allocator at _W@2 @@1 at 0PA_W1Uinput_iterator_tag@1@@Z) 1>libboost_program_options-vc80-mt-1_34_1.lib(convert.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::replace(class std::_String_iterator,class std::allocator >,class std::_String_iterator,class std::allocator >,class std::basic_string,class std::allocator > const &)" (__imp_?replace@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEAAV12 at V?$_String_iterator at DU ?$char_traits at D@std@@V?$allocator at D@2@@2 at 0ABV12@@Z) referenced in function "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::_Replace(class std::_String_iterator,class std::allocator >,class std::_String_iterator,class std::allocator >,char *,char *,struct std::input_iterator_tag)" (??$_Replace at PAD@?$basic_string at DU?$char_traits at D @std@@V?$allocator at D@2@@std@@QAEAAV01 at V?$_String_iterator at DU?$char_traits at D @std@@V?$allocator at D@2@@1 at 0PAD1Uinput_iterator_tag@1@@Z) 1>libboost_regex-vc80-mt-1_34_1.lib(instances.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::_String_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::insert(class std::_String_iterator,class std::allocator >,char)" (__imp_?insert@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE?AV?$_String_iterator at DU ?$char_traits at D@std@@V?$allocator at D@2@@2 at V32@D at Z) referenced in function "public: struct boost::re_detail::re_syntax_base * __thiscall boost::re_detail::basic_regex_creator > >::append_set(class boost::re_detail::basic_char_set > > const &,struct boost::mpl::bool_<0> *)" (?append_set@?$basic_regex_creator at DU ?$regex_traits at DV?$w32_regex_traits at D@boost@@@boost@@@re_detail at boost @@QAEPAUre_syntax_base at 23@ABV?$basic_char_set at DU?$regex_traits at DV ?$w32_regex_traits at D@boost@@@boost@@@23 at PAU?$bool_@$0A@@mpl at 3@@Z) 1>C:\linden\indra\build-vc90\newview\RelWithDebInfo\secondlife-bin.exe : fatal error LNK1120: 7 unresolved externals 1>Build log was saved at "file://c:\linden\indra\build-vc90\newview\secondlife-bin.dir\RelWithDebInfo\BuildLog.htm" 1>secondlife-bin - 8 error(s), 12 warning(s) On Thu, Jun 18, 2009 at 9:18 PM, chandra kiran kuchi wrote: > Hello, > > I was able to resolve that by installing bison in the program\files > directory instead of program files. > > But I am facing another problem, looks like case of missing library, stack > trace is > > 1>'FLEX-NOTFOUND' is not recognized as an internal or external command, > 1>operable program or batch file. > > Which library is missing? > > > > On Thu, Jun 18, 2009 at 2:08 PM, chandra kiran kuchi wrote: > >> Hi, >> >> I am using 1.21. >> >> Yeah I saw that across many forums, but unable to find Visual Studio 2005 >> Express edition. >> >> >> >> On Thu, Jun 18, 2009 at 1:54 PM, Soft wrote: >> >>> On Thu, Jun 18, 2009 at 1:48 PM, chandra kiran kuchi >>> wrote: >>> > I am trying to run this on visual studio 2008, facing this problem... >>> any >>> > clues? >>> > >>> > 1>------ Build started: Project: lscript_compile, Configuration: >>> > RelWithDebInfo Win32 ------ >>> > 1>Generating indra.y.cpp, indra.y.hpp >>> > 1>m4: cannot open `Files\GnuWin32/share/bison': No such file or >>> directory >>> > 1>m4: cannot open `F:\Program': No such file or directory >>> > 1>m4: cannot open `Files\GnuWin32/share/bison/m4sugar/m4sugar.m4': No >>> such >>> > file or directory >>> >>> It's helpful to say which source branch you're building - trunk? >>> snowglobe? 1.23 release? >>> >>> Also, Visual Studio 2008 will give you significant problems, no matter >>> which branch you use. If at all possible, getting a copy of Visual >>> Studio 2005 will make your life easier. >>> >> >> >> >> -- >> >> > > > -- > Regards, > Fraser > -- Regards, Chandra K Kuchi Graduate Student Experimental Computing Lab University of Cincinnati Cincinnati. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/5b88a182/attachment-0001.htm From evolutie at gmail.com Fri Jun 19 07:35:02 2009 From: evolutie at gmail.com (evolutie) Date: Fri, 19 Jun 2009 16:35:02 +0200 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: Message-ID: <5fb4b1fa0906190735l44030b49kcfc36d13f45fc95a@mail.gmail.com> I'm on vista x64 with nvidia GTX280. I'm not getting the message about the min specs, but have problems rendering the ocean.. Tiles are not being rendered or flickering. (see http://www.evolutie.org/movies/snowglobe.mov) I'm getting this behaviour also with RC 1.23. I'm fine on 1.21.6 evo (lost in duplicated and related jira issues) On Fri, Jun 19, 2009 at 4:15 PM, Matt White wrote: > On Fri, Jun 19, 2009 at 9:45 AM, Soft wrote: > >> Windows XP x64 is very much unsupported. It peaked with as many users >> as a small Linux distro and has only been shrinking since. But if you >> would capture this in a JIRA and search for the block in the log file >> where it's doing system identification (or email me your log >> privately), we'll see if there's a quick fix. > > I'll email it off to you privately. > > Second Life runs very nicely on XP x64, but I didn't know it wasn't an > officially supported OS by LL. (I'm an IT professional that uses a lot > of virtual machines. It's not uncommon for me to have 3-4 VMs running > at once, which is why I shoved this box full of RAM and installed XP > x64.) > >> Does 1.23 misguess your card's capabilities as well? > > Just installed the stock 1.23 and didn't get a warning. > > - Matt > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -- http://www.creativemachinery.org http://blog.wdka.nl/crosslab From mwhite at leporidae.net Fri Jun 19 08:07:29 2009 From: mwhite at leporidae.net (Matt White) Date: Fri, 19 Jun 2009 11:07:29 -0400 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: <98e40fa00906190748g3f98486axf3c0089776c6900f@mail.gmail.com> References: <98e40fa00906190748g3f98486axf3c0089776c6900f@mail.gmail.com> Message-ID: On Fri, Jun 19, 2009 at 10:48 AM, Ellla McMahon wrote: > Are you seeing http://jira.secondlife.com/browse/SNOW-22 "Warning, High end > system does not meet minimum requiments" ? Looks like it. Rather than start a new issue I'll update SNOW-22 with my report. I noticed nVidia released new drivers yesterday (6/18). I just updated and I'm still getting the same message. Thanks Ella. I hate to open a new PJIRA if I know there's always one there. -- Matt White / Bunny Halberd From nexiim at googlemail.com Fri Jun 19 08:17:52 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Fri, 19 Jun 2009 16:17:52 +0100 Subject: [sldev] SLDev Digest, Vol 30, Issue 47 In-Reply-To: References: Message-ID: <824c8ab70906190817l1925b2bqfa028d77c9c12728@mail.gmail.com> Yes, please start publishing these global stats, ESPECIALLY for custom channels, let the client developers see their own crash rates, we could REALLY need that. - Nexii Malthus On Thu, Jun 18, 2009 at 4:40 PM, Maggie Leber (sl: Maggie Darwin) < maggie at matrisync.com> wrote: > On Wed, Jun 17, 2009 at 9:35 AM, Kent Quirk (Q Linden) > > > The bugs that were found and fixed in the next 3 RCs were minimal. On > > a global statistics level, the crash rates are lower than they've ever > > been, even when you include crashes caused by specific video cards. > Well, we can only go by our own crash rates and word-of-mouth since we > don't get to see the global stats. Our local crash rates here are still what > I would call "awful", and clearly worse on 1.23 than 1.22, with two users > making heavy use of hardware selected and purchased specifically on the > basis of the published requirements for SLV. > > The crashes are almost always due --as far as I can see from the > information available-- to virtual memory exhaustion. > > Perhaps I have "a specific video card". If so, I think the "specific video > card manufacturer" would be interested in hearing about a claim that their > card is crashing your app...I'd be interested in hearing the details of the > bugs you filed with them, assuming it's not constrained by an NDA.. (The > last time I dealt with a severe SLV bug that was repeatedly and strenuously > attributed to the video card driver, it turned out to be the result of a > trivial code defect in SLV, found by a third party developer). > > I do hope your crash rate is calculated per session hour. Because if it's a > raw number of crashes per day or even per session, I do know that the uptake > of 1.23 in our operation was limited by the fact that the thing kept leaking > up and falling over, and if others were affected the same way then a raw > crash rate per day would be badly distorted. > > Any chance you'll start publishing the viewer crash stats? > > Maggie Darwin > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/7f7f4d12/attachment.htm From mwhite at leporidae.net Fri Jun 19 08:29:35 2009 From: mwhite at leporidae.net (Matt White) Date: Fri, 19 Jun 2009 11:29:35 -0400 Subject: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly In-Reply-To: <578355.6920.qm@web59104.mail.re1.yahoo.com> References: <578355.6920.qm@web59104.mail.re1.yahoo.com> Message-ID: On Fri, Jun 19, 2009 at 10:08 AM, Ann Otoole wrote: > Some people on the xstreetsl.com forums are reporting textures don't load or > load more slowly in Snowglobe. Ann - I've been noticing this a lot too. I just managed to catch it in the act... please see the following screen captures: http://www.rabbitglen.com/badTextures.jpg http://www.rabbitglen.com/goodTextures.jpg The "badTextures" was made with Snowglobe 2446. Notice that I left the texture console open to show that there's nothing downloading. This really only seems to be an issue on sculpties - the rocks I'm looking at are large sclupites. I notice the same thing on sclupted trees as well. The "goodTextures" shot was made with a stock 1.23 install. -- Matt White / Bunny Halberd From stickman at gmail.com Fri Jun 19 08:55:22 2009 From: stickman at gmail.com (Stickman) Date: Fri, 19 Jun 2009 08:55:22 -0700 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: <98e40fa00906190748g3f98486axf3c0089776c6900f@mail.gmail.com> Message-ID: > Thanks Ella. I hate to open a new PJIRA if I know there's always one there. Reopened Techwolf's issue with my own system specs, since it's doing it to me, too. -Stickman From stickman at gmail.com Fri Jun 19 08:57:13 2009 From: stickman at gmail.com (Stickman) Date: Fri, 19 Jun 2009 08:57:13 -0700 Subject: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly In-Reply-To: References: <578355.6920.qm@web59104.mail.re1.yahoo.com> Message-ID: > http://www.rabbitglen.com/badTextures.jpg > http://www.rabbitglen.com/goodTextures.jpg I see the same sort of thing with the floating island in Aggro. Megaprims maybe? -Stickman From stickman at gmail.com Fri Jun 19 08:59:27 2009 From: stickman at gmail.com (Stickman) Date: Fri, 19 Jun 2009 08:59:27 -0700 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: Message-ID: > search for the block in the log file > where it's doing system identification (or email me your log > privately), we'll see if there's a quick fix. Should I do this as well? Also, where do I find said log? There are no .log files within the Snowglobe directory. Do I need to enable it with a command line switch? -Stickman From missannotoole at yahoo.com Fri Jun 19 08:59:55 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 19 Jun 2009 08:59:55 -0700 (PDT) Subject: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly In-Reply-To: References: <578355.6920.qm@web59104.mail.re1.yahoo.com> Message-ID: <627853.12780.qm@web59103.mail.re1.yahoo.com> I have not had any texture issues at all anywhere including around oversize prims so it seems to me like it has to be something to do with the way the computers are handling http connections. ________________________________ From: Stickman To: Matt White Cc: Ann Otoole ; sldev at lists.secondlife.com Sent: Friday, June 19, 2009 11:57:13 AM Subject: Re: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly > http://www.rabbitglen.com/badTextures.jpg > http://www.rabbitglen.com/goodTextures.jpg I see the same sort of thing with the floating island in Aggro. Megaprims maybe? -Stickman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/7580d989/attachment.htm From joel.foner at gmail.com Fri Jun 19 09:33:57 2009 From: joel.foner at gmail.com (Joel Foner) Date: Fri, 19 Jun 2009 12:33:57 -0400 Subject: [sldev] SLDev Digest, Vol 30, Issue 47 In-Reply-To: <824c8ab70906190817l1925b2bqfa028d77c9c12728@mail.gmail.com> References: <824c8ab70906190817l1925b2bqfa028d77c9c12728@mail.gmail.com> Message-ID: <7c58f6610906190933m5c006551ud3002bd4d252f15d@mail.gmail.com> Is a crash of the Vivox/SL Voice subsystem considered a "crash" in crash rate stats? I and others I know have been having repeated voice subsystem crashes at a higher rate than previous viewers (Windows XP popup explaining that voice module has crashed while the viewer is still apparently running), and I'm wondering if this is transparent to the crash logging. Perhaps it's just better error reporting and the crash rate of voice is the same - not sure - but it is visible more frequently. In addition, I've been regularly getting crashes/lockups on startup (before splash screen is fully rendered) that do not seem to trigger a crash report. Just a couple notes from the outback, Joel On Fri, Jun 19, 2009 at 11:17 AM, Nexii Malthus wrote: > Yes, please start publishing these global stats, ESPECIALLY for custom > channels, let the client developers see their own crash rates, we could > REALLY need that. > > - Nexii Malthus > > On Thu, Jun 18, 2009 at 4:40 PM, Maggie Leber (sl: Maggie Darwin) < > maggie at matrisync.com> wrote: > >> On Wed, Jun 17, 2009 at 9:35 AM, Kent Quirk (Q Linden) >> >> > The bugs that were found and fixed in the next 3 RCs were minimal. On >> > a global statistics level, the crash rates are lower than they've ever >> > been, even when you include crashes caused by specific video cards. >> Well, we can only go by our own crash rates and word-of-mouth since we >> don't get to see the global stats. Our local crash rates here are still what >> I would call "awful", and clearly worse on 1.23 than 1.22, with two users >> making heavy use of hardware selected and purchased specifically on the >> basis of the published requirements for SLV. >> >> The crashes are almost always due --as far as I can see from the >> information available-- to virtual memory exhaustion. >> >> Perhaps I have "a specific video card". If so, I think the "specific video >> card manufacturer" would be interested in hearing about a claim that their >> card is crashing your app...I'd be interested in hearing the details of the >> bugs you filed with them, assuming it's not constrained by an NDA.. (The >> last time I dealt with a severe SLV bug that was repeatedly and strenuously >> attributed to the video card driver, it turned out to be the result of a >> trivial code defect in SLV, found by a third party developer). >> >> I do hope your crash rate is calculated per session hour. Because if it's >> a raw number of crashes per day or even per session, I do know that the >> uptake of 1.23 in our operation was limited by the fact that the thing kept >> leaking up and falling over, and if others were affected the same way then a >> raw crash rate per day would be badly distorted. >> >> Any chance you'll start publishing the viewer crash stats? >> >> Maggie Darwin >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/be06a00f/attachment-0001.htm From sllists at boroon.dasgupta.ch Fri Jun 19 09:52:37 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 19 Jun 2009 18:52:37 +0200 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: Message-ID: <4A3BC255.5050307@boroon.dasgupta.ch> Stickman schrieb: > Also, where do I find said log? It's not in SL/Snowglobes installation dir, but in the one where it also keeps your settings. The location of the settings dir depends on the OS, see http://wiki.secondlife.com/wiki/Debug_Help#Where_do_I_find_my_SecondLife.log_file.3F cheers Boroondas From stickman at gmail.com Fri Jun 19 10:13:11 2009 From: stickman at gmail.com (Stickman) Date: Fri, 19 Jun 2009 10:13:11 -0700 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: <4A3BC255.5050307@boroon.dasgupta.ch> References: <4A3BC255.5050307@boroon.dasgupta.ch> Message-ID: On Fri, Jun 19, 2009 at 9:52 AM, Boroondas Gupte wrote: > Stickman schrieb: >> Also, where do I find said log? > It's not in SL/Snowglobes installation dir, but in the one where it also > keeps your settings. The location of the settings dir depends on the OS, see > http://wiki.secondlife.com/wiki/Debug_Help#Where_do_I_find_my_SecondLife.log_file.3F Thanks, found it! Also, I notice all three of us have a 260 GTX. First time I've seen specs on a Jira line up like that. Anyone else experiencing the issue? Anyone with a 260 GTX not experiencing it? -Stickman From mwhite at leporidae.net Fri Jun 19 10:18:06 2009 From: mwhite at leporidae.net (Matt White) Date: Fri, 19 Jun 2009 13:18:06 -0400 Subject: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly In-Reply-To: <627853.12780.qm@web59103.mail.re1.yahoo.com> References: <578355.6920.qm@web59104.mail.re1.yahoo.com> <627853.12780.qm@web59103.mail.re1.yahoo.com> Message-ID: On Fri, Jun 19, 2009 at 11:59 AM, Ann Otoole wrote: > I have not had any texture issues at all anywhere including around oversize > prims so it seems to me like it has to be something to do with the way the > computers are handling http connections. I don't think it's limited to oversized prims. Here's a (less obvious) example with a 10x10x10 prim: http://www.rabbitglen.com/goodTextures2.jpg http://www.rabbitglen.com/badTextures2.jpg Look at the flowering pink tree - this one is harder to see because the prim is much smaller. It's really hit or miss... most of the time works, but every now and then it won't. ...HTTP connections? As far as I know, the only thing that's using HTTP connections in Snowglobe is the map tiles. I believe that textures are still being transferred over the UDP circuit like before. (Someone please correct me if I'm wrong!) -- Matt White / Bunny Halberd From robla at lindenlab.com Fri Jun 19 10:31:18 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 19 Jun 2009 10:31:18 -0700 Subject: [sldev] Filing issues from the test runs Message-ID: <4A3BCB66.6010409@lindenlab.com> Hi folks, Thanks everyone for the great effort during the testing sprint! Here's the link to the test plan: https://wiki.secondlife.com/wiki/Snowglobe_Test_Plans/Test_Pass_2 ...and the parent jira task with all of the issues: https://jira.secondlife.com/browse/SNOW-34 Scattered in the results looks like a lot of bugs that have been found. At first skim, there are reports there that are concerning, but nothing yet that makes me think "we've gotta stop this train!". That said, it's all stuff that should be dealt with one way or another (i.e. after Snowglobe 1.0). So, the next step in the process is getting those issues teased out of the test results, and filed as separate bugs. The person who originally ran the test is probably in the best position to file a good report, but even more helpful is if someone can independently confirm the result before filing an issue. Anyone willing to help in that process? Rob From mwhite at leporidae.net Fri Jun 19 10:44:38 2009 From: mwhite at leporidae.net (Matt White) Date: Fri, 19 Jun 2009 13:44:38 -0400 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: <4A3BC255.5050307@boroon.dasgupta.ch> Message-ID: On Fri, Jun 19, 2009 at 1:13 PM, Stickman wrote: > Also, I notice all three of us have a 260 GTX. First time I've seen > specs on a Jira line up like that. I noticed that too. If I copy the gpu_table.txt file from 1.23.4 over to Snowglobe, the warning goes away. Snowglobe's gpu_table.txt contains more cards than the one shipped with 1.23.4. The GTX-250 was added in Snowglobe's file, but I can't see anything wrong with the entry. Someone that knows the layout of this file more than I is going to have to look at it. -- Matt White / Bunny Halberd From brad at lindenlab.com Fri Jun 19 10:46:12 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Fri, 19 Jun 2009 13:46:12 -0400 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: References: <4A3BC255.5050307@boroon.dasgupta.ch> Message-ID: <4A3BCEE4.5060805@lindenlab.com> There was a late patch in the 1.23 RC cycle to add the 260 GTX to gpu_table.txt. It probably hasn't made it anywhere other than the viewer_1-23 branch yet... -Brad Stickman wrote: > On Fri, Jun 19, 2009 at 9:52 AM, Boroondas > Gupte wrote: > >> Stickman schrieb: >> >>> Also, where do I find said log? >>> >> It's not in SL/Snowglobes installation dir, but in the one where it also >> keeps your settings. The location of the settings dir depends on the OS, see >> http://wiki.secondlife.com/wiki/Debug_Help#Where_do_I_find_my_SecondLife.log_file.3F >> > > Thanks, found it! > > Also, I notice all three of us have a 260 GTX. First time I've seen > specs on a Jira line up like that. > > Anyone else experiencing the issue? Anyone with a 260 GTX not experiencing it? > > -Stickman > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From gretzky.harleen at gmail.com Fri Jun 19 11:50:56 2009 From: gretzky.harleen at gmail.com (Harleen Gretzky) Date: Fri, 19 Jun 2009 14:50:56 -0400 Subject: [sldev] Rendering Limits In-Reply-To: <4A3AF1D5.4060506@superliminal.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> Message-ID: <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> It appears to be more than just jewelry that is effected. VWR-14049 and VWR-14146 are builds that are effected also. When posing this question I was really trying to understand how the rendering limits work. For instance, does the renderMaxNodeSize limit apply to the entire scene, or only to portions of the scene? Does it apply to avatars as well as objects? It seems to have something to do with 'spatial groups' but what are 'spatial groups'? Is renderMaxNodeSize the only rendering limit? If renderMaxNodeSize is the only setting that, I would think the best solution as has been suggested on the JIRAs and here is to move the setting onto the Graphics preference tab. Since it seems to be a little low for those running graphics at High and Ultra it should probably be increased for those users. So maybe something like: Low - 2048 Mid - 4096 High - 8192 Ultra - 8192 Then if a user chooses Custom there should be a slider control to allow it to be set to the value of their choice. Just my two cents. -Harleen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/51b8ebe8/attachment.htm From colin.kern at gmail.com Fri Jun 19 12:13:44 2009 From: colin.kern at gmail.com (Colin Kern) Date: Fri, 19 Jun 2009 15:13:44 -0400 Subject: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly In-Reply-To: <578355.6920.qm@web59104.mail.re1.yahoo.com> References: <578355.6920.qm@web59104.mail.re1.yahoo.com> Message-ID: <77c421f00906191213h2cc08584w6a69020b3738ac5b@mail.gmail.com> If they're the kind of people who wouldn't use pjira, maybe they're also the kind of people who wouldn't realize their maximum bandwidth setting has reset to 500 kbps. Colin On Fri, Jun 19, 2009 at 10:08 AM, Ann Otoole wrote: > Some people on the xstreetsl.com forums are reporting textures don't load or > load more slowly in Snowglobe. > I doubt we can get them to participate in pjira issue reports. > So I thought I would mention it here. > > I find it odd since I have such fast texture loading speeds on my system > using Snowglobe. > > I'm curious as to why one computer would get high speeds with snowglobe and > poor performance in the normal 1.22/1.23 while another gets bad performance > in both. > Could it be anti virus systems or something? > I use Avast which scans everything coming in yet I still get good speeds in > Snowglobe. > Perhaps they are using anti virus inline scanners that are terribly slow? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From tofu.linden at lindenlab.com Fri Jun 19 12:45:14 2009 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Fri, 19 Jun 2009 20:45:14 +0100 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: <4A3BCEE4.5060805@lindenlab.com> References: <4A3BC255.5050307@boroon.dasgupta.ch> <4A3BCEE4.5060805@lindenlab.com> Message-ID: <4A3BEACA.1010602@lindenlab.com> Actually IIRC that's not in 1.23 (it's in render-pipeline) but it *was* cherrypicked over to Snowglobe, supposedly. Brad Kittenbrink (Brad Linden) wrote: > There was a late patch in the 1.23 RC cycle to add the 260 GTX to > gpu_table.txt. It probably hasn't made it anywhere other than the > viewer_1-23 branch yet... > > -Brad > > Stickman wrote: >> On Fri, Jun 19, 2009 at 9:52 AM, Boroondas >> Gupte wrote: >> >>> Stickman schrieb: >>> >>>> Also, where do I find said log? >>>> >>> It's not in SL/Snowglobes installation dir, but in the one where it also >>> keeps your settings. The location of the settings dir depends on the OS, see >>> http://wiki.secondlife.com/wiki/Debug_Help#Where_do_I_find_my_SecondLife.log_file.3F >>> >> Thanks, found it! >> >> Also, I notice all three of us have a 260 GTX. First time I've seen >> specs on a Jira line up like that. >> >> Anyone else experiencing the issue? Anyone with a 260 GTX not experiencing it? >> >> -Stickman >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From missannotoole at yahoo.com Fri Jun 19 13:10:20 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 19 Jun 2009 13:10:20 -0700 (PDT) Subject: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly In-Reply-To: <77c421f00906191213h2cc08584w6a69020b3738ac5b@mail.gmail.com> References: <578355.6920.qm@web59104.mail.re1.yahoo.com> <77c421f00906191213h2cc08584w6a69020b3738ac5b@mail.gmail.com> Message-ID: <804944.66292.qm@web59108.mail.re1.yahoo.com> I tried to point that out to no avail. Oh well no pjira no bug. I certainly cannot repro it. ________________________________ From: Colin Kern To: Ann Otoole Cc: sldev at lists.secondlife.com Sent: Friday, June 19, 2009 3:13:44 PM Subject: Re: [sldev] Snowglobe - Reports of textures not rezzingor rezzing very slowly If they're the kind of people who wouldn't use pjira, maybe they're also the kind of people who wouldn't realize their maximum bandwidth setting has reset to 500 kbps. Colin On Fri, Jun 19, 2009 at 10:08 AM, Ann Otoole wrote: > Some people on the xstreetsl.com forums are reporting textures don't load or > load more slowly in Snowglobe. > I doubt we can get them to participate in pjira issue reports. > So I thought I would mention it here. > > I find it odd since I have such fast texture loading speeds on my system > using Snowglobe. > > I'm curious as to why one computer would get high speeds with snowglobe and > poor performance in the normal 1.22/1.23 while another gets bad performance > in both. > Could it be anti virus systems or something? > I use Avast which scans everything coming in yet I still get good speeds in > Snowglobe. > Perhaps they are using anti virus inline scanners that are terribly slow? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/920dbe9a/attachment.htm From nexiim at googlemail.com Fri Jun 19 13:10:38 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Fri, 19 Jun 2009 21:10:38 +0100 Subject: [sldev] Rendering Limits In-Reply-To: <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> Message-ID: <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> I think by spatial groups you could consider how dense an area is. We really should open many more options on the preferences menu. Perhaps it should branch off into a seperate menu due to the relevant complexity, imagine how complex the windlight sliders are, but they are also nicely dispersed into their relevant categories and sections. We should aim to achieve the same, not to mention the explanations that were provided in the WindLight menu were pretty cool and awesome to understand what the settings do. WindLight is a mere single subsystem of the entire graphics system, why can't we have the same attention put into other areas in terms of control via the UI? There are many hidden settings, some that are not even affected by the more generalised "Low, Medium, High, Ultra" that have an impact on FPS and the experience. L$0.02. - Nexii Malthus On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky wrote: > It appears to be more than just jewelry that is effected. VWR-14049 and > VWR-14146 are builds that are effected also. When posing this question I was > really trying to understand how the rendering limits work. For instance, does > the renderMaxNodeSize limit apply to the entire scene, or only to portions > of the scene? Does it apply to avatars as well as objects? It seems to > have something to do with 'spatial groups' but what are 'spatial groups'? Is > renderMaxNodeSize the only rendering limit? > > If renderMaxNodeSize is the only setting that, I would think the best > solution as has been suggested on the JIRAs and here is to move the setting > onto the Graphics preference tab. Since it seems to be a little low for > those running graphics at High and Ultra it should probably be increased for > those users. So maybe something like: > > Low - 2048 > Mid - 4096 > High - 8192 > Ultra - 8192 > > Then if a user chooses Custom there should be a slider control to allow it > to be set to the value of their choice. Just my two cents. > > -Harleen > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/1ecf799d/attachment.htm From thomas.shikami at online.de Fri Jun 19 13:20:42 2009 From: thomas.shikami at online.de (Thomas Shikami) Date: Fri, 19 Jun 2009 22:20:42 +0200 Subject: [sldev] How do I remove fmod from viewer? In-Reply-To: References: Message-ID: <4A3BF31A.9070901@online.de> izze euler wrote: > I would like to exclude Fmod from my viewer. Apart from excluding > files for Fmod, do I need to make any changes to the source code? If > so, are there any instructions for how to do this? I need to be able > to distribute my viewer. this is easy, just do not put any fmod libraries into your working copy, develop.py should automatically detect that FMOD is missing and your viewer will compile without. To explicitely exlude fmod from a VS2005 compile use something like: develop.py -G VC80 configure -DFMOD:BOOL=OFF From brad at lindenlab.com Fri Jun 19 13:20:56 2009 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Fri, 19 Jun 2009 16:20:56 -0400 Subject: [sldev] Snowglobe - False Min Specs Warning In-Reply-To: <4A3BEACA.1010602@lindenlab.com> References: <4A3B C255.5050307@boroon.dasgupta.ch><4A3BCEE4.5060805@lindenlab.com> <4A3BEACA.1010602@lindenlab.com> Message-ID: <4A3BF328.4090607@lindenlab.com> Oops, my mistake. /me is apparently off his rocker on this one... -Brad Tofu Linden wrote: > Actually IIRC that's not in 1.23 (it's in render-pipeline) but it > *was* cherrypicked over to Snowglobe, supposedly. > > Brad Kittenbrink (Brad Linden) wrote: > >> There was a late patch in the 1.23 RC cycle to add the 260 GTX to >> gpu_table.txt. It probably hasn't made it anywhere other than the >> viewer_1-23 branch yet... >> >> -Brad >> >> Stickman wrote: >> >>> On Fri, Jun 19, 2009 at 9:52 AM, Boroondas >>> Gupte wrote: >>> >>> >>>> Stickman schrieb: >>>> >>>> >>>>> Also, where do I find said log? >>>>> >>>>> >>>> It's not in SL/Snowglobes installation dir, but in the one where it also >>>> keeps your settings. The location of the settings dir depends on the OS, see >>>> http://wiki.secondlife.com/wiki/Debug_Help#Where_do_I_find_my_SecondLife.log_file.3F >>>> >>>> >>> Thanks, found it! >>> >>> Also, I notice all three of us have a 260 GTX. First time I've seen >>> specs on a Jira line up like that. >>> >>> Anyone else experiencing the issue? Anyone with a 260 GTX not experiencing it? >>> >>> -Stickman >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From melinda at superliminal.com Fri Jun 19 13:45:44 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 19 Jun 2009 13:45:44 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> Message-ID: <4A3BF8F8.3030703@superliminal.com> That's an interesting suggestion, Nexii. I'm not sure how the LL designers feel about all those Windlight preferences but I wouldn't be surprised if they'd mostly prefer to hide or eliminate most of them. There's always a tension between number of controls and the all-important SL learning curve. One way to break this logjam is to start using the new XUI features to allow external designers to create custom UI without the need for developers to hook them in and compile entire custom viewer binaries and then update them with each viewer version. Skinning is the first step on that road but there is a lot of other useful stuff under the hood that can also be used today. My favorite is the "control_name" XUI tag which lets you associate check box and slider values with particular saved settings. When you load a floater or other XUI element containing a check box or slider with that tag, then it takes it's initial value from the named saved setting and automatically saves back out modified values as the user interacts with those controls. This is extremely powerful and should let you create your custom panel to control any of the boolean or real valued settings that you see in the debug settings floater. The only thing really missing here (other than support for more control types) is the ability to launch a custom floater. Ideally that would come with the badly needed keyboard remapping functionality to allow you to specify a hot key to load a named floater. (Hint: Great Snowglobe feature here!) Since we don't have that yet, you'd probably have to append your controls to some existing floater if you want to add controls without programming, but that shouldn't be too awful. -Melinda Nexii Malthus wrote: > I think by spatial groups you could consider how dense an area is. > > We really should open many more options on the preferences menu. > Perhaps it should branch off into a seperate menu due to the relevant > complexity, imagine how complex the windlight sliders are, but they > are also nicely dispersed into their relevant categories and sections. > We should aim to achieve the same, not to mention the explanations > that were provided in the WindLight menu were pretty cool and awesome > to understand what the settings do. > > WindLight is a mere single subsystem of the entire graphics system, > why can't we have the same attention put into other areas in terms of > control via the UI? > > There are many hidden settings, some that are not even affected by the > more generalised "Low, Medium, High, Ultra" that have an impact on FPS > and the experience. > > L$0.02. > > - Nexii Malthus > > On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky > > wrote: > > It appears to be more than just jewelry that is effected. > VWR-14049 and VWR-14146 are builds that are effected also. When > posing this question I was really trying to understand how the > rendering limits work. For instance, does the renderMaxNodeSize > limit apply to the entire scene, or only to portions of the scene? > Does it apply to avatars as well as objects? It seems to have > something to do with 'spatial groups' but what are 'spatial > groups'? Is renderMaxNodeSize the only rendering limit? > > If renderMaxNodeSize is the only setting that, I would think the > best solution as has been suggested on the JIRAs and here is to > move the setting onto the Graphics preference tab. Since it seems > to be a little low for those running graphics at High and Ultra it > should probably be increased for those users. So maybe something like: > > Low - 2048 > Mid - 4096 > High - 8192 > Ultra - 8192 > > Then if a user chooses Custom there should be a slider control to > allow it to be set to the value of their choice. Just my two cents. > > -Harleen > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From robla at lindenlab.com Fri Jun 19 14:10:28 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 19 Jun 2009 14:10:28 -0700 Subject: [sldev] Snowglobe RC1 In-Reply-To: <7139dfaa0906190612k3b7c43cbkdb6198694917bbd0@mail.gmail.com> References: <4A3B5E2A.6020206@lindenlab.com> <7139dfaa0906190612k3b7c43cbkdb6198694917bbd0@mail.gmail.com> Message-ID: <4A3BFEC4.6040508@lindenlab.com> Hi Meni, We've gotten several reports of this, and think we have the fix for it here: https://s3.amazonaws.com/viewer-source-downloads/2009/http-texture/2448/Snowglobe_1_0_1_2448.dmg Let us know if that works better for you Rob On 06/19/2009 06:12 AM, Meni Kaiousei wrote: > Hoi Rob, > > I have this issue with the mac build: > > * For some reason I cannot drag the Snowglobe icon to the Application > folder for installation. However, I can install the application when I > drag the text "Snowglobe.app". > > Regards, > Meni > > On Fri, Jun 19, 2009 at 11:45, Rob Lanphier wrote: > >> Hi folks, >> Another day, another RC. In this case, RC1, though it's probably less >> ambiguous to refer to "build 2446" (see [1]). Upgrading to this version >> is very important if you're on Windows. While Windows users shouldn't >> see much of a difference from RC0, the crash reports we get should be >> more useful. >> >> Here's the list of RC1 builds: >> >> Win32: >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe_1-0-1-2446_Setup.exe >> Mac: >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe_1_0_1_2446.dmg >> Linux: >> http://secondlife.com/developers/opensource/downloads/2009/http-texture/2446/Snowglobe-i686-1.0.1.2446.tar.bz2 >> >> Let us know if we should put the brakes on this release, or if we've >> cleared the "good enough" threshold. >> >> Thanks! >> Rob >> >> >> [1] If you were hitting "reload" on the Snowglobe homepage, you might >> have seen a couple of earlier builds listed as "RC 1": >> https://wiki.secondlife.com/w/index.php?title=Template:Snowglobe-installers&action=history >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> From melinda at superliminal.com Fri Jun 19 14:27:49 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 19 Jun 2009 14:27:49 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <824c8ab70906191359p3c6ee5ffj37e603205d395ba3@mail.gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> <4A3BF8F8.3030703@superliminal.com> <824c8ab70906191359p3c6ee5ffj37e603205d395ba3@mail.gmail.com> Message-ID: <4A3C02D5.5030209@superliminal.com> Nexi, I'm not stating an opinion about the value of Windlight controls one way or the other. I do agree with you that it would be better if the setting names were better chosen in order to organize them into some meaningful hierarchy, but the chance to do that passed a long time ago. Even if someone did the huge job of changing the names throughout the entire source code and XUI content, that patch would never be accepted because of the branches within LL (and externally) that would be affected. The end result is that once you name a setting or control, it's nearly impossible/impractical to change it. We're then left with an underlying flat list of settings for better or worse and I therefore believe this is *not* the place to start! We could of course impose an external organization onto that list though a config UI like you suggest. That sounds like a good idea to me but is completely orthogonal to taking advantage of the existing XUI<-->saved settings bridge. If anyone wants to see good examples of doing the sort of stuff I'm talking about, I recommend looking at the new View->Beacons floater implementation that I created. It was implemented almost entirely in XML, only requiring C++ code to launch the floater and to enforce a couple of the previous quirky interactions between the beacon types. The rest is implemented entirely in XUI making heavy use of the control_name tag. BTW, this is how many of the Windlight controls were implemented too and was where I found the examples I needed when doing the beacons work. This is an incredibly powerful and underused pattern. -Melinda Nexii Malthus wrote: > Well, I think we could start by re-working the debug-settings menu a bit. > > Load up Firefox and go to this page: "about:config" > > Thats an excellent example of a good debug settings menu. The settings > are easily understandable imho. > > Seperated into their relevant sections, I think it would be great if > we had that a similiar naming scheme. That would be at least one step > towards opening up the deeper parts of the engine towards users. Not > to mention the help it would provide to developers, lindens and > non-lindens alike for making it easier to test out experimental > features or performance optimizations. > > Imagine a naming scheme towards the graphical subsystems. > render.spatial.maxnodesize for this situation as a loose example. > > Wouldn't it be easier and efficient to expose only the relevant debug > settings to each subsystem too? render.* being available to the render > stuff. network.* being for the network stuff. > > If we want to revamp the whole way preferences work we need to move > step-by-step from the bottom up. > > I do agree that the LL designers feel a bit itchy about the current > windlight preferences and I agree, it is messy. But its wrong to hide > the tools for the right job when you consider the majority of > individuals that are willing to go a step further to make their > experience so much better. > > Just look at the stuff Torley and other talented photographers have > made in snapshots by messing about in the windlight settings and shadows. > > - Nexii Malthus > > On Fri, Jun 19, 2009 at 9:45 PM, Melinda Green > > wrote: > > That's an interesting suggestion, Nexii. I'm not sure how the LL > designers feel about all those Windlight preferences but I > wouldn't be surprised if they'd mostly prefer to hide or eliminate > most of them. There's always a tension between number of controls > and the all-important SL learning curve. > > One way to break this logjam is to start using the new XUI > features to allow external designers to create custom UI without > the need for developers to hook them in and compile entire custom > viewer binaries and then update them with each viewer version. > Skinning is the first step on that road but there is a lot of > other useful stuff under the hood that can also be used today. My > favorite is the "control_name" XUI tag which lets you associate > check box and slider values with particular saved settings. When > you load a floater or other XUI element containing a check box or > slider with that tag, then it takes it's initial value from the > named saved setting and automatically saves back out modified > values as the user interacts with those controls. > > This is extremely powerful and should let you create your custom > panel to control any of the boolean or real valued settings that > you see in the debug settings floater. The only thing really > missing here (other than support for more control types) is the > ability to launch a custom floater. Ideally that would come with > the badly needed keyboard remapping functionality to allow you to > specify a hot key to load a named floater. (Hint: Great Snowglobe > feature here!) Since we don't have that yet, you'd probably have > to append your controls to some existing floater if you want to > add controls without programming, but that shouldn't be too awful. > > -Melinda > > Nexii Malthus wrote: > > I think by spatial groups you could consider how dense an area is. > > We really should open many more options on the preferences > menu. Perhaps it should branch off into a seperate menu due to > the relevant complexity, imagine how complex the windlight > sliders are, but they are also nicely dispersed into their > relevant categories and sections. We should aim to achieve the > same, not to mention the explanations that were provided in > the WindLight menu were pretty cool and awesome to understand > what the settings do. > > WindLight is a mere single subsystem of the entire graphics > system, why can't we have the same attention put into other > areas in terms of control via the UI? > > There are many hidden settings, some that are not even > affected by the more generalised "Low, Medium, High, Ultra" > that have an impact on FPS and the experience. > > L$0.02. > > - Nexii Malthus > > On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky > > >> wrote: > > It appears to be more than just jewelry that is effected. > VWR-14049 and VWR-14146 are builds that are effected also. When > posing this question I was really trying to understand how the > rendering limits work. For instance, does the renderMaxNodeSize > limit apply to the entire scene, or only to portions of the > scene? > Does it apply to avatars as well as objects? It seems to have > something to do with 'spatial groups' but what are 'spatial > groups'? Is renderMaxNodeSize the only rendering limit? > > If renderMaxNodeSize is the only setting that, I would > think the > best solution as has been suggested on the JIRAs and here is to > move the setting onto the Graphics preference tab. Since it > seems > to be a little low for those running graphics at High and > Ultra it > should probably be increased for those users. So maybe > something like: > > Low - 2048 > Mid - 4096 > High - 8192 > Ultra - 8192 > > Then if a user chooses Custom there should be a slider > control to > allow it to be set to the value of their choice. Just my > two cents. > > -Harleen > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > From dzonatas at gmail.com Fri Jun 19 15:57:38 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Fri, 19 Jun 2009 15:57:38 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <4A3C02D5.5030209@superliminal.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> <4A3BF8F8.3030703@superliminal.com> <824c8ab70906191359p3c6ee5ffj37e603205d395ba3@mail.gmail.com> <4A3C02D5.5030209@superliminal.com> Message-ID: <4A3C17E2.6070004@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090619/8870ccb7/attachment.htm From robla at lindenlab.com Fri Jun 19 20:26:47 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 19 Jun 2009 20:26:47 -0700 Subject: [sldev] Snowglobe Release Candidate 2 Message-ID: <4A3C56F7.7050406@lindenlab.com> Hi all, After getting several reports of problems with drag and drop in the Mac dmg installer, we spent a little time working on a fix, and figured it out. That is the *only* viewer change from RC1, so don't expect any big improvements by downloading a new build. However, we would appreciate it if you did test it anyway, just in case there is some phase-of-the-moon problem with the build rig. We also worked around a problem with the crash reporter which kept the crash reports from being terribly useful. It's not truly fixed, but it's in good enough shape such that crash reports on Windows moving forward will be more useful than past crash reports. So, if you had a crash before this afternoon, and you know how to reproduce it, please do so so that we can capture the new problem. Builds are in the following locations. Win32: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2451/Snowglobe_1-0-2-2451_Setup.exe Mac: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2451/Snowglobe_1_0_2_2451.dmg Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2451/Snowglobe-i686-1.0.2.2451.tar.bz2 Almost there. Thanks for all of your help! Rob From melinda at superliminal.com Sat Jun 20 14:10:09 2009 From: melinda at superliminal.com (Melinda Green) Date: Sat, 20 Jun 2009 14:10:09 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <4A3C17E2.6070004@gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> <4A3BF8F8.3030703@superliminal.com> <824c8ab70906191359p3c6ee5ffj37e603205d395ba3@mail.gmail.com> <4A3C02D5.5030209@superliminal.com> <4A3C17E2.6070004@gmail.com> Message-ID: <4A3D5031.4040503@superliminal.com> It is definitely on the road map to eventually support a fully scriptable XUI format as well as to allow programmatic viewer control from external processes through published APIs. I don't expect that the native scripting language will be anything like LSL, but who knows, that might not be such a bad idea. Visual GUI builders are definitely another direction in which I expect this to grow, and implementing one as an Eclipse plug-in definitely looks like the quickest path to me. I don't know anything about Glade but perhaps that would make that task even easier. The key will be to get such GUI builders to read and write XUI files. That much could be done today even without any scripting ability, and even the LL designers struggle to hand-code XUI when such a GUI builder would save so much time in the long run. That's definitely a plumb task that an enterprising SLDev member could take on and earn much love. In the meantime I highly encourage anyone interested to get more familiar with the powerful XUI features available today. Much of it is undocumented, and helping to create *that* missing piece would be a great place to start since clear specs are absolute prerequisites for creating GUI builders or any other infrastructure on top of it. -Melinda Dzonatas Sol wrote: > I think what some people want is a like a LSL based code-behind > feature to the UI. > > Did I say it? Oops, I did. > > Hold that thought. > > Actually, I'm eager for GtkBuilder to fully phase-in, then UI builders > like the Glade Interface Designer would have lots of fun interactive, > custom widgets ready to use in the palette: > http://glade.gnome.org/screenshots.html > > Example vid of using Glade: > http://people.redhat.com/overholt/nativeeclipse/ > > Of course, that was with Eclipse, and the Eclipse UI is written with > Gtk. Hmmm - powerful enough for holistic programmers. > > Here is an older review of Glade: > http://loosexaml.wordpress.com/2008/10/14/giving-glade-a-fair-shake/ > > The Glade Interface Designer is also a library, so it is embeddable > (into some viewer app someday maybe): > http://glade.gnome.org/docs/index.html > > Ok, I said too much. > > Cheers, > http://twitter.com/Dzonatas > > Melinda Green wrote: >> Nexi, >> >> I'm not stating an opinion about the value of Windlight controls one way >> or the other. I do agree with you that it would be better if the setting >> names were better chosen in order to organize them into some meaningful >> hierarchy, but the chance to do that passed a long time ago. Even if >> someone did the huge job of changing the names throughout the entire >> source code and XUI content, that patch would never be accepted because >> of the branches within LL (and externally) that would be affected. The >> end result is that once you name a setting or control, it's nearly >> impossible/impractical to change it. We're then left with an underlying >> flat list of settings for better or worse and I therefore believe this >> is *not* the place to start! We could of course impose an external >> organization onto that list though a config UI like you suggest. That >> sounds like a good idea to me but is completely orthogonal to taking >> advantage of the existing XUI<-->saved settings bridge. >> >> If anyone wants to see good examples of doing the sort of stuff I'm >> talking about, I recommend looking at the new View->Beacons floater >> implementation that I created. It was implemented almost entirely in >> XML, only requiring C++ code to launch the floater and to enforce a >> couple of the previous quirky interactions between the beacon types. The >> rest is implemented entirely in XUI making heavy use of the control_name >> tag. BTW, this is how many of the Windlight controls were implemented >> too and was where I found the examples I needed when doing the beacons >> work. This is an incredibly powerful and underused pattern. >> >> -Melinda >> >> Nexii Malthus wrote: >> >>> Well, I think we could start by re-working the debug-settings menu a bit. >>> >>> Load up Firefox and go to this page: "about:config" >>> >>> Thats an excellent example of a good debug settings menu. The settings >>> are easily understandable imho. >>> >>> Seperated into their relevant sections, I think it would be great if >>> we had that a similiar naming scheme. That would be at least one step >>> towards opening up the deeper parts of the engine towards users. Not >>> to mention the help it would provide to developers, lindens and >>> non-lindens alike for making it easier to test out experimental >>> features or performance optimizations. >>> >>> Imagine a naming scheme towards the graphical subsystems. >>> render.spatial.maxnodesize for this situation as a loose example. >>> >>> Wouldn't it be easier and efficient to expose only the relevant debug >>> settings to each subsystem too? render.* being available to the render >>> stuff. network.* being for the network stuff. >>> >>> If we want to revamp the whole way preferences work we need to move >>> step-by-step from the bottom up. >>> >>> I do agree that the LL designers feel a bit itchy about the current >>> windlight preferences and I agree, it is messy. But its wrong to hide >>> the tools for the right job when you consider the majority of >>> individuals that are willing to go a step further to make their >>> experience so much better. >>> >>> Just look at the stuff Torley and other talented photographers have >>> made in snapshots by messing about in the windlight settings and shadows. >>> >>> - Nexii Malthus >>> >>> On Fri, Jun 19, 2009 at 9:45 PM, Melinda Green >>> > wrote: >>> >>> That's an interesting suggestion, Nexii. I'm not sure how the LL >>> designers feel about all those Windlight preferences but I >>> wouldn't be surprised if they'd mostly prefer to hide or eliminate >>> most of them. There's always a tension between number of controls >>> and the all-important SL learning curve. >>> >>> One way to break this logjam is to start using the new XUI >>> features to allow external designers to create custom UI without >>> the need for developers to hook them in and compile entire custom >>> viewer binaries and then update them with each viewer version. >>> Skinning is the first step on that road but there is a lot of >>> other useful stuff under the hood that can also be used today. My >>> favorite is the "control_name" XUI tag which lets you associate >>> check box and slider values with particular saved settings. When >>> you load a floater or other XUI element containing a check box or >>> slider with that tag, then it takes it's initial value from the >>> named saved setting and automatically saves back out modified >>> values as the user interacts with those controls. >>> >>> This is extremely powerful and should let you create your custom >>> panel to control any of the boolean or real valued settings that >>> you see in the debug settings floater. The only thing really >>> missing here (other than support for more control types) is the >>> ability to launch a custom floater. Ideally that would come with >>> the badly needed keyboard remapping functionality to allow you to >>> specify a hot key to load a named floater. (Hint: Great Snowglobe >>> feature here!) Since we don't have that yet, you'd probably have >>> to append your controls to some existing floater if you want to >>> add controls without programming, but that shouldn't be too awful. >>> >>> -Melinda >>> >>> Nexii Malthus wrote: >>> >>> I think by spatial groups you could consider how dense an area is. >>> >>> We really should open many more options on the preferences >>> menu. Perhaps it should branch off into a seperate menu due to >>> the relevant complexity, imagine how complex the windlight >>> sliders are, but they are also nicely dispersed into their >>> relevant categories and sections. We should aim to achieve the >>> same, not to mention the explanations that were provided in >>> the WindLight menu were pretty cool and awesome to understand >>> what the settings do. >>> >>> WindLight is a mere single subsystem of the entire graphics >>> system, why can't we have the same attention put into other >>> areas in terms of control via the UI? >>> >>> There are many hidden settings, some that are not even >>> affected by the more generalised "Low, Medium, High, Ultra" >>> that have an impact on FPS and the experience. >>> >>> L$0.02. >>> >>> - Nexii Malthus >>> >>> On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky >>> >>> >> >> wrote: >>> >>> It appears to be more than just jewelry that is effected. >>> VWR-14049 and VWR-14146 are builds that are effected also. When >>> posing this question I was really trying to understand how the >>> rendering limits work. For instance, does the renderMaxNodeSize >>> limit apply to the entire scene, or only to portions of the >>> scene? >>> Does it apply to avatars as well as objects? It seems to have >>> something to do with 'spatial groups' but what are 'spatial >>> groups'? Is renderMaxNodeSize the only rendering limit? >>> >>> If renderMaxNodeSize is the only setting that, I would >>> think the >>> best solution as has been suggested on the JIRAs and here is to >>> move the setting onto the Graphics preference tab. Since it >>> seems >>> to be a little low for those running graphics at High and >>> Ultra it >>> should probably be increased for those users. So maybe >>> something like: >>> >>> Low - 2048 >>> Mid - 4096 >>> High - 8192 >>> Ultra - 8192 >>> >>> Then if a user chooses Custom there should be a slider >>> control to >>> allow it to be set to the value of their choice. Just my >>> two cents. >>> >>> -Harleen >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated >>> posting privileges >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated >>> posting privileges >>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > From gbrandon at gmail.com Sat Jun 20 14:34:04 2009 From: gbrandon at gmail.com (Brandon Lockaby) Date: Sat, 20 Jun 2009 17:34:04 -0400 Subject: [sldev] Upload changes as of simulator 1.27.0.124190 Message-ID: Hi everyone. I know the aforementioned simulator isn't released yet, but I heard about these changes recently and had to hop on the preview grid to see. It appears we are close to having HTTP for all asset uploads! It's important to note that in several cases upload is no longer allowed via UDP, and in some of those cases the initial upload isn't allowed via HTTP either. I mustard all of my graphics skills to create this chart showing which upload methods we will need to use after the update, for each type of asset: http://i39.tinypic.com/4hv4gp.jpg For the most part we are already using HTTP to upload assets, but some of us may need to change the way we upload certain types of assets, so it's good to be ready. For instance, if you are uploading scripts or gestures, the new requirement is to use both UDP (CreateInventoryItem) and then HTTP (UpdateScriptAgent, UpdateGestureAgentInventory). However, I'm only trying on my own to find out what works and what doesn't! So if anyone knows, is there anything I missed? I hope the chart is helpful <3 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090620/8fafbb8e/attachment.htm From dzonatas at gmail.com Sat Jun 20 16:36:08 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Sat, 20 Jun 2009 16:36:08 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <4A3D5031.4040503@superliminal.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> <4A3BF8F8.3030703@superliminal.com> <824c8ab70906191359p3c6ee5ffj37e603205d395ba3@mail.gmail.com> <4A3C02D5.5030209@superliminal.com> <4A3C17E2.6070004@gmail.com> <4A3D5031.4040503@superliminal.com> Message-ID: <4A3D7268.5010505@gmail.com> The XUI standard is still tied to Java. That means the fully scriptable XUI formats are limited to Java programmers. With the XUI standard also being tied to mobile devices that depend on Java, well, I guess the right question to ask is how to get XUI to work well, being fully scripted (with Java), on mobile devices that don't run Java? I'm sure further discussion on that will go beyond interfaces to handle rendering limits. Also note, there are already Eclipse plug-ins for XUI builders. Since there are more than a few, I'll just link to a forum about them: http://sourceforge.net/forum/forum.php?forum_id=556171 If the fully scriptable XUI/Java based interface can reach the same API that any other alternative scriptable UI can reach, then that API is key... rather than require transformations of XUI to any degree. Note, I have already made an API for ControlGroup classes in Snowglobe-Sharp, and it does make things that much more powerful (as you even noted with XUI). Melinda Green wrote: > It is definitely on the road map to eventually support a fully > scriptable XUI format as well as to allow programmatic viewer control > from external processes through published APIs. I don't expect that > the native scripting language will be anything like LSL, but who > knows, that might not be such a bad idea. Visual GUI builders are > definitely another direction in which I expect this to grow, and > implementing one as an Eclipse plug-in definitely looks like the > quickest path to me. I don't know anything about Glade but perhaps > that would make that task even easier. The key will be to get such GUI > builders to read and write XUI files. That much could be done today > even without any scripting ability, and even the LL designers struggle > to hand-code XUI when such a GUI builder would save so much time in > the long run. That's definitely a plumb task that an enterprising > SLDev member could take on and earn much love. In the meantime I > highly encourage anyone interested to get more familiar with the > powerful XUI features available today. Much of it is undocumented, and > helping to create *that* missing piece would be a great place to start > since clear specs are absolute prerequisites for creating GUI builders > or any other infrastructure on top of it. > > -Melinda > > Dzonatas Sol wrote: >> I think what some people want is a like a LSL based code-behind >> feature to the UI. >> >> Did I say it? Oops, I did. >> >> Hold that thought. >> >> Actually, I'm eager for GtkBuilder to fully phase-in, then UI >> builders like the Glade Interface Designer would have lots of fun >> interactive, custom widgets ready to use in the palette: >> http://glade.gnome.org/screenshots.html >> >> Example vid of using Glade: >> http://people.redhat.com/overholt/nativeeclipse/ >> >> Of course, that was with Eclipse, and the Eclipse UI is written with >> Gtk. Hmmm - powerful enough for holistic programmers. >> >> Here is an older review of Glade: >> http://loosexaml.wordpress.com/2008/10/14/giving-glade-a-fair-shake/ >> >> The Glade Interface Designer is also a library, so it is embeddable >> (into some viewer app someday maybe): >> http://glade.gnome.org/docs/index.html >> >> Ok, I said too much. >> >> Cheers, >> http://twitter.com/Dzonatas >> >> Melinda Green wrote: >>> Nexi, >>> >>> I'm not stating an opinion about the value of Windlight controls one >>> way or the other. I do agree with you that it would be better if the >>> setting names were better chosen in order to organize them into some >>> meaningful hierarchy, but the chance to do that passed a long time >>> ago. Even if someone did the huge job of changing the names >>> throughout the entire source code and XUI content, that patch would >>> never be accepted because of the branches within LL (and externally) >>> that would be affected. The end result is that once you name a >>> setting or control, it's nearly impossible/impractical to change it. >>> We're then left with an underlying flat list of settings for better >>> or worse and I therefore believe this is *not* the place to start! >>> We could of course impose an external organization onto that list >>> though a config UI like you suggest. That sounds like a good idea to >>> me but is completely orthogonal to taking advantage of the existing >>> XUI<-->saved settings bridge. >>> >>> If anyone wants to see good examples of doing the sort of stuff I'm >>> talking about, I recommend looking at the new View->Beacons floater >>> implementation that I created. It was implemented almost entirely in >>> XML, only requiring C++ code to launch the floater and to enforce a >>> couple of the previous quirky interactions between the beacon types. >>> The rest is implemented entirely in XUI making heavy use of the >>> control_name tag. BTW, this is how many of the Windlight controls >>> were implemented too and was where I found the examples I needed >>> when doing the beacons work. This is an incredibly powerful and >>> underused pattern. >>> >>> -Melinda >>> >>> Nexii Malthus wrote: >>> >>>> Well, I think we could start by re-working the debug-settings menu >>>> a bit. >>>> >>>> Load up Firefox and go to this page: "about:config" >>>> >>>> Thats an excellent example of a good debug settings menu. The >>>> settings are easily understandable imho. >>>> >>>> Seperated into their relevant sections, I think it would be great >>>> if we had that a similiar naming scheme. That would be at least one >>>> step towards opening up the deeper parts of the engine towards >>>> users. Not to mention the help it would provide to developers, >>>> lindens and non-lindens alike for making it easier to test out >>>> experimental features or performance optimizations. >>>> >>>> Imagine a naming scheme towards the graphical subsystems. >>>> render.spatial.maxnodesize for this situation as a loose example. >>>> >>>> Wouldn't it be easier and efficient to expose only the relevant >>>> debug settings to each subsystem too? render.* being available to >>>> the render stuff. network.* being for the network stuff. >>>> >>>> If we want to revamp the whole way preferences work we need to move >>>> step-by-step from the bottom up. >>>> >>>> I do agree that the LL designers feel a bit itchy about the current >>>> windlight preferences and I agree, it is messy. But its wrong to >>>> hide the tools for the right job when you consider the majority of >>>> individuals that are willing to go a step further to make their >>>> experience so much better. >>>> >>>> Just look at the stuff Torley and other talented photographers have >>>> made in snapshots by messing about in the windlight settings and >>>> shadows. >>>> >>>> - Nexii Malthus >>>> >>>> On Fri, Jun 19, 2009 at 9:45 PM, Melinda Green >>>> > wrote: >>>> >>>> That's an interesting suggestion, Nexii. I'm not sure how the LL >>>> designers feel about all those Windlight preferences but I >>>> wouldn't be surprised if they'd mostly prefer to hide or eliminate >>>> most of them. There's always a tension between number of controls >>>> and the all-important SL learning curve. >>>> >>>> One way to break this logjam is to start using the new XUI >>>> features to allow external designers to create custom UI without >>>> the need for developers to hook them in and compile entire custom >>>> viewer binaries and then update them with each viewer version. >>>> Skinning is the first step on that road but there is a lot of >>>> other useful stuff under the hood that can also be used today. My >>>> favorite is the "control_name" XUI tag which lets you associate >>>> check box and slider values with particular saved settings. When >>>> you load a floater or other XUI element containing a check box or >>>> slider with that tag, then it takes it's initial value from the >>>> named saved setting and automatically saves back out modified >>>> values as the user interacts with those controls. >>>> >>>> This is extremely powerful and should let you create your custom >>>> panel to control any of the boolean or real valued settings that >>>> you see in the debug settings floater. The only thing really >>>> missing here (other than support for more control types) is the >>>> ability to launch a custom floater. Ideally that would come with >>>> the badly needed keyboard remapping functionality to allow you to >>>> specify a hot key to load a named floater. (Hint: Great Snowglobe >>>> feature here!) Since we don't have that yet, you'd probably have >>>> to append your controls to some existing floater if you want to >>>> add controls without programming, but that shouldn't be too awful. >>>> >>>> -Melinda >>>> >>>> Nexii Malthus wrote: >>>> >>>> I think by spatial groups you could consider how dense an >>>> area is. >>>> >>>> We really should open many more options on the preferences >>>> menu. Perhaps it should branch off into a seperate menu due to >>>> the relevant complexity, imagine how complex the windlight >>>> sliders are, but they are also nicely dispersed into their >>>> relevant categories and sections. We should aim to achieve the >>>> same, not to mention the explanations that were provided in >>>> the WindLight menu were pretty cool and awesome to understand >>>> what the settings do. >>>> >>>> WindLight is a mere single subsystem of the entire graphics >>>> system, why can't we have the same attention put into other >>>> areas in terms of control via the UI? >>>> >>>> There are many hidden settings, some that are not even >>>> affected by the more generalised "Low, Medium, High, Ultra" >>>> that have an impact on FPS and the experience. >>>> >>>> L$0.02. >>>> >>>> - Nexii Malthus >>>> >>>> On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky >>>> >>>> >>> >> wrote: >>>> >>>> It appears to be more than just jewelry that is effected. >>>> VWR-14049 and VWR-14146 are builds that are effected >>>> also. When >>>> posing this question I was really trying to understand >>>> how the >>>> rendering limits work. For instance, does the >>>> renderMaxNodeSize >>>> limit apply to the entire scene, or only to portions of the >>>> scene? >>>> Does it apply to avatars as well as objects? It seems to >>>> have >>>> something to do with 'spatial groups' but what are 'spatial >>>> groups'? Is renderMaxNodeSize the only rendering limit? >>>> >>>> If renderMaxNodeSize is the only setting that, I would >>>> think the >>>> best solution as has been suggested on the JIRAs and >>>> here is to >>>> move the setting onto the Graphics preference tab. Since it >>>> seems >>>> to be a little low for those running graphics at High and >>>> Ultra it >>>> should probably be increased for those users. So maybe >>>> something like: >>>> >>>> Low - 2048 >>>> Mid - 4096 >>>> High - 8192 >>>> Ultra - 8192 >>>> >>>> Then if a user chooses Custom there should be a slider >>>> control to >>>> allow it to be set to the value of their choice. Just my >>>> two cents. >>>> >>>> -Harleen >>>> >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated >>>> posting privileges >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated >>>> posting privileges >>>> >>>> >>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >> > From snowfox102 at dragonkeepcreations.com Sat Jun 20 18:26:12 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Sat, 20 Jun 2009 20:26:12 -0500 Subject: [sldev] Unfamiliar Snowglobe build error In-Reply-To: <4A3C56F7.7050406@lindenlab.com> References: <4A3C56F7.7050406@lindenlab.com> Message-ID: <4A3D8C34.6000901@dragonkeepcreations.com> Me again. Since the RCs of Snowglobe looked pretty promising to me, I decided to try building from source to get a version useful to me. Before doing any patching, I tried building with just the supplied code. The build goes fine, though VS doesn't launch the compiled program. Running secondlife-bin.exe results in a pop-up saying ERROR: LLControlGroup::getLLSD: Invalid LLSD control Locations I've not seen this with any other source code. Any ideas? Maya From nexiim at googlemail.com Sat Jun 20 18:40:28 2009 From: nexiim at googlemail.com (Nexii Malthus) Date: Sun, 21 Jun 2009 02:40:28 +0100 Subject: [sldev] Upload changes as of simulator 1.27.0.124190 In-Reply-To: References: Message-ID: <824c8ab70906201840p19badaabtca5ac30b07078127@mail.gmail.com> Ah, excellent, so temporary textures still allowed. I exposed this functionality for content creators to create free temporary textures in my custom client, which I think is an ideal option for allowing creators that need to preview their products realtime but without the expenses and weight added onto the asset servers. - Nexii Malthus On Sat, Jun 20, 2009 at 10:34 PM, Brandon Lockaby wrote: > Hi everyone. I know the aforementioned simulator isn't released yet, but I > heard about these changes recently and had to hop on the preview grid to > see. > > It appears we are close to having HTTP for all asset uploads! It's > important to note that in several cases upload is no longer allowed via UDP, > and in some of those cases the initial upload isn't allowed via HTTP > either. I mustard all of my graphics skills to create this chart showing > which upload methods we will need to use after the update, for each type of > asset: > > http://i39.tinypic.com/4hv4gp.jpg > > For the most part we are already using HTTP to upload assets, but some of > us may need to change the way we upload certain types of assets, so it's > good to be ready. For instance, if you are uploading scripts or gestures, > the new requirement is to use both UDP (CreateInventoryItem) and then HTTP > (UpdateScriptAgent, UpdateGestureAgentInventory). > > However, I'm only trying on my own to find out what works and what > doesn't! So if anyone knows, is there anything I missed? I hope the chart > is helpful <3 > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090621/cab58b4d/attachment.htm From snowfox102 at dragonkeepcreations.com Sat Jun 20 18:44:46 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Sat, 20 Jun 2009 20:44:46 -0500 Subject: [sldev] Unfamiliar Snowglobe build error In-Reply-To: <824c8ab70906201834j395e3154m6cafe7e117968199@mail.gmail.com> References: <4A3C56F7.7050406@lindenlab.com> <4A3D8C34.6000901@dragonkeepcreations.com> <824c8ab70906201834j395e3154m6cafe7e117968199@mail.gmail.com> Message-ID: <4A3D908E.2080800@dragonkeepcreations.com> It's there, but that does give me an idea of what the problem may be. I don't recall ever seeing any info on errors about settings_files.xml being missing, so I've fixed it in other versions by copying in the file from a successful build. But this time, the copied file was not from the same version of the viewer, so that may be the problem. Maya Nexii Malthus wrote: > A preliminary guess is that your settings xml is incorrect or not > present under app_settings? > > - Nexii Malthus > > On Sun, Jun 21, 2009 at 2:26 AM, Maya Remblai > > wrote: > > Me again. > > Since the RCs of Snowglobe looked pretty promising to me, I decided to > try building from source to get a version useful to me. Before > doing any > patching, I tried building with just the supplied code. The build goes > fine, though VS doesn't launch the compiled program. Running > secondlife-bin.exe results in a pop-up saying > > ERROR: LLControlGroup::getLLSD: Invalid LLSD control Locations > > I've not seen this with any other source code. Any ideas? > > Maya > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > From melinda at superliminal.com Sat Jun 20 18:44:19 2009 From: melinda at superliminal.com (Melinda Green) Date: Sat, 20 Jun 2009 18:44:19 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <4A3D7268.5010505@gmail.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> <4A3BF8F8.3030703@superliminal.com> <824c8ab70906191359p3c6ee5ffj37e603205d395ba3@mail.gmail.com> <4A3C02D5.5030209@superliminal.com> <4A3C17E2.6070004@gmail.com> <4A3D5031.4040503@superliminal.com> <4A3D7268.5010505@gmail.com> Message-ID: <4A3D9073.7020000@superliminal.com> Maybe there is more than one XUI here and I could be the one causing the confusion but I had thought that what LL's calls XUI was an entirely homegrown XML schema. (Or is that LLUI?) Anyway, there's no connection to Java that I'm aware of, and being a big Java nut, I'd certainly have remembered that. Good luck getting traction with your Snowglobe-Sharp API. That does sound interesting. -Melinda Dzonatas Sol wrote: > The XUI standard is still tied to Java. That means the fully > scriptable XUI formats are limited to Java programmers. With the XUI > standard also being tied to mobile devices that depend on Java, well, > I guess the right question to ask is how to get XUI to work well, > being fully scripted (with Java), on mobile devices that don't run > Java? I'm sure further discussion on that will go beyond interfaces to > handle rendering limits. > > Also note, there are already Eclipse plug-ins for XUI builders. Since > there are more than a few, I'll just link to a forum about them: > http://sourceforge.net/forum/forum.php?forum_id=556171 > > If the fully scriptable XUI/Java based interface can reach the same > API that any other alternative scriptable UI can reach, then that API > is key... rather than require transformations of XUI to any degree. > > Note, I have already made an API for ControlGroup classes in > Snowglobe-Sharp, and it does make things that much more powerful (as > you even noted with XUI). > > Melinda Green wrote: >> It is definitely on the road map to eventually support a fully >> scriptable XUI format as well as to allow programmatic viewer control >> from external processes through published APIs. I don't expect that >> the native scripting language will be anything like LSL, but who >> knows, that might not be such a bad idea. Visual GUI builders are >> definitely another direction in which I expect this to grow, and >> implementing one as an Eclipse plug-in definitely looks like the >> quickest path to me. I don't know anything about Glade but perhaps >> that would make that task even easier. The key will be to get such >> GUI builders to read and write XUI files. That much could be done >> today even without any scripting ability, and even the LL designers >> struggle to hand-code XUI when such a GUI builder would save so much >> time in the long run. That's definitely a plumb task that an >> enterprising SLDev member could take on and earn much love. In the >> meantime I highly encourage anyone interested to get more familiar >> with the powerful XUI features available today. Much of it is >> undocumented, and helping to create *that* missing piece would be a >> great place to start since clear specs are absolute prerequisites for >> creating GUI builders or any other infrastructure on top of it. >> >> -Melinda >> >> Dzonatas Sol wrote: >>> I think what some people want is a like a LSL based code-behind >>> feature to the UI. >>> >>> Did I say it? Oops, I did. >>> >>> Hold that thought. >>> >>> Actually, I'm eager for GtkBuilder to fully phase-in, then UI >>> builders like the Glade Interface Designer would have lots of fun >>> interactive, custom widgets ready to use in the palette: >>> http://glade.gnome.org/screenshots.html >>> >>> Example vid of using Glade: >>> http://people.redhat.com/overholt/nativeeclipse/ >>> >>> Of course, that was with Eclipse, and the Eclipse UI is written with >>> Gtk. Hmmm - powerful enough for holistic programmers. >>> >>> Here is an older review of Glade: >>> http://loosexaml.wordpress.com/2008/10/14/giving-glade-a-fair-shake/ >>> >>> The Glade Interface Designer is also a library, so it is embeddable >>> (into some viewer app someday maybe): >>> http://glade.gnome.org/docs/index.html >>> >>> Ok, I said too much. >>> >>> Cheers, >>> http://twitter.com/Dzonatas >>> >>> Melinda Green wrote: >>>> Nexi, >>>> >>>> I'm not stating an opinion about the value of Windlight controls >>>> one way or the other. I do agree with you that it would be better >>>> if the setting names were better chosen in order to organize them >>>> into some meaningful hierarchy, but the chance to do that passed a >>>> long time ago. Even if someone did the huge job of changing the >>>> names throughout the entire source code and XUI content, that patch >>>> would never be accepted because of the branches within LL (and >>>> externally) that would be affected. The end result is that once you >>>> name a setting or control, it's nearly impossible/impractical to >>>> change it. We're then left with an underlying flat list of settings >>>> for better or worse and I therefore believe this is *not* the place >>>> to start! We could of course impose an external organization onto >>>> that list though a config UI like you suggest. That sounds like a >>>> good idea to me but is completely orthogonal to taking advantage of >>>> the existing XUI<-->saved settings bridge. >>>> >>>> If anyone wants to see good examples of doing the sort of stuff I'm >>>> talking about, I recommend looking at the new View->Beacons floater >>>> implementation that I created. It was implemented almost entirely >>>> in XML, only requiring C++ code to launch the floater and to >>>> enforce a couple of the previous quirky interactions between the >>>> beacon types. The rest is implemented entirely in XUI making heavy >>>> use of the control_name tag. BTW, this is how many of the Windlight >>>> controls were implemented too and was where I found the examples I >>>> needed when doing the beacons work. This is an incredibly powerful >>>> and underused pattern. >>>> >>>> -Melinda >>>> >>>> Nexii Malthus wrote: >>>> >>>>> Well, I think we could start by re-working the debug-settings menu >>>>> a bit. >>>>> >>>>> Load up Firefox and go to this page: "about:config" >>>>> >>>>> Thats an excellent example of a good debug settings menu. The >>>>> settings are easily understandable imho. >>>>> >>>>> Seperated into their relevant sections, I think it would be great >>>>> if we had that a similiar naming scheme. That would be at least >>>>> one step towards opening up the deeper parts of the engine towards >>>>> users. Not to mention the help it would provide to developers, >>>>> lindens and non-lindens alike for making it easier to test out >>>>> experimental features or performance optimizations. >>>>> >>>>> Imagine a naming scheme towards the graphical subsystems. >>>>> render.spatial.maxnodesize for this situation as a loose example. >>>>> >>>>> Wouldn't it be easier and efficient to expose only the relevant >>>>> debug settings to each subsystem too? render.* being available to >>>>> the render stuff. network.* being for the network stuff. >>>>> >>>>> If we want to revamp the whole way preferences work we need to >>>>> move step-by-step from the bottom up. >>>>> >>>>> I do agree that the LL designers feel a bit itchy about the >>>>> current windlight preferences and I agree, it is messy. But its >>>>> wrong to hide the tools for the right job when you consider the >>>>> majority of individuals that are willing to go a step further to >>>>> make their experience so much better. >>>>> >>>>> Just look at the stuff Torley and other talented photographers >>>>> have made in snapshots by messing about in the windlight settings >>>>> and shadows. >>>>> >>>>> - Nexii Malthus >>>>> >>>>> On Fri, Jun 19, 2009 at 9:45 PM, Melinda Green >>>>> > wrote: >>>>> >>>>> That's an interesting suggestion, Nexii. I'm not sure how the LL >>>>> designers feel about all those Windlight preferences but I >>>>> wouldn't be surprised if they'd mostly prefer to hide or >>>>> eliminate >>>>> most of them. There's always a tension between number of controls >>>>> and the all-important SL learning curve. >>>>> >>>>> One way to break this logjam is to start using the new XUI >>>>> features to allow external designers to create custom UI without >>>>> the need for developers to hook them in and compile entire custom >>>>> viewer binaries and then update them with each viewer version. >>>>> Skinning is the first step on that road but there is a lot of >>>>> other useful stuff under the hood that can also be used today. My >>>>> favorite is the "control_name" XUI tag which lets you associate >>>>> check box and slider values with particular saved settings. When >>>>> you load a floater or other XUI element containing a check box or >>>>> slider with that tag, then it takes it's initial value from the >>>>> named saved setting and automatically saves back out modified >>>>> values as the user interacts with those controls. >>>>> >>>>> This is extremely powerful and should let you create your custom >>>>> panel to control any of the boolean or real valued settings that >>>>> you see in the debug settings floater. The only thing really >>>>> missing here (other than support for more control types) is the >>>>> ability to launch a custom floater. Ideally that would come with >>>>> the badly needed keyboard remapping functionality to allow you to >>>>> specify a hot key to load a named floater. (Hint: Great Snowglobe >>>>> feature here!) Since we don't have that yet, you'd probably have >>>>> to append your controls to some existing floater if you want to >>>>> add controls without programming, but that shouldn't be too >>>>> awful. >>>>> >>>>> -Melinda >>>>> >>>>> Nexii Malthus wrote: >>>>> >>>>> I think by spatial groups you could consider how dense an >>>>> area is. >>>>> >>>>> We really should open many more options on the preferences >>>>> menu. Perhaps it should branch off into a seperate menu >>>>> due to >>>>> the relevant complexity, imagine how complex the windlight >>>>> sliders are, but they are also nicely dispersed into their >>>>> relevant categories and sections. We should aim to achieve >>>>> the >>>>> same, not to mention the explanations that were provided in >>>>> the WindLight menu were pretty cool and awesome to understand >>>>> what the settings do. >>>>> >>>>> WindLight is a mere single subsystem of the entire graphics >>>>> system, why can't we have the same attention put into other >>>>> areas in terms of control via the UI? >>>>> >>>>> There are many hidden settings, some that are not even >>>>> affected by the more generalised "Low, Medium, High, Ultra" >>>>> that have an impact on FPS and the experience. >>>>> >>>>> L$0.02. >>>>> >>>>> - Nexii Malthus >>>>> >>>>> On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky >>>>> >>>>> >>>> >> wrote: >>>>> >>>>> It appears to be more than just jewelry that is effected. >>>>> VWR-14049 and VWR-14146 are builds that are effected >>>>> also. When >>>>> posing this question I was really trying to understand >>>>> how the >>>>> rendering limits work. For instance, does the >>>>> renderMaxNodeSize >>>>> limit apply to the entire scene, or only to portions of >>>>> the >>>>> scene? >>>>> Does it apply to avatars as well as objects? It seems >>>>> to have >>>>> something to do with 'spatial groups' but what are >>>>> 'spatial >>>>> groups'? Is renderMaxNodeSize the only rendering limit? >>>>> >>>>> If renderMaxNodeSize is the only setting that, I would >>>>> think the >>>>> best solution as has been suggested on the JIRAs and >>>>> here is to >>>>> move the setting onto the Graphics preference tab. >>>>> Since it >>>>> seems >>>>> to be a little low for those running graphics at High and >>>>> Ultra it >>>>> should probably be increased for those users. So maybe >>>>> something like: >>>>> >>>>> Low - 2048 >>>>> Mid - 4096 >>>>> High - 8192 >>>>> Ultra - 8192 >>>>> >>>>> Then if a user chooses Custom there should be a slider >>>>> control to >>>>> allow it to be set to the value of their choice. Just my >>>>> two cents. >>>>> >>>>> -Harleen >>>>> >>>>> >>>>> _______________________________________________ >>>>> Policies and (un)subscribe information available here: >>>>> http://wiki.secondlife.com/wiki/SLDev >>>>> Please read the policies before posting to keep >>>>> unmoderated >>>>> posting privileges >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Policies and (un)subscribe information available here: >>>>> http://wiki.secondlife.com/wiki/SLDev >>>>> Please read the policies before posting to keep unmoderated >>>>> posting privileges >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>>> >>> >> > > From dzonatas at gmail.com Sat Jun 20 19:58:27 2009 From: dzonatas at gmail.com (Dzonatas Sol) Date: Sat, 20 Jun 2009 19:58:27 -0700 Subject: [sldev] Rendering Limits In-Reply-To: <4A3D9073.7020000@superliminal.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> <4A3BF8F8.3030703@superliminal.com> <824c8ab70906191359p3c6ee5ffj37e603205d395ba3@mail.gmail.com> <4A3C02D5.5030209@superliminal.com> <4A3C17E2.6070004@gmail.com> <4A3D5031.4040503@superliminal.com> <4A3D7268.5010505@gmail.com> <4A3D9073.7020000@superliminal.com> Message-ID: <4A3DA1D3.5000604@gmail.com> Ah! Yes, a bit of confusion most certainly! Thank you for the luck. To touch back on rendering limits, I wonder how many extra vertices the UI overlay adds. I was just thinking about this limit while I was in a group IM session. The viewer window is not set fullscreen. There are many reasons why I don't usually set it fullscreen, and those range from performance to mainly that I like being able to have several IDEs on my screen at once (or where they can be quickly tabbed). I took a screenshot of the IM session (and moved IDEs out of the way beforehand). Take a peek: http://mono.dzonux.net/file/MonoVida-20090620a.png Now, the long lines make it harder to see much further in the past conversation unless I scroll the window. It would be easier if the window was resized larger to see longer types lines on one line instead of multiple lines. To achieve that with the normal viewer, I would have to go fullscreen. This brings up issues that fullscreen would block my other windows that I have open and could make the performance go down (hence, my thought track on render limits). Sometimes when I click fullscreen, it is quick, but usually on a busier scene it takes awhile to flip to fullscreen and flip back when I want to get back to the IDEs. With MonoVida, where it can display the communication window as a totally separate window from the viewer, I'm able just "fullscreen" the communication window, or even give half the screen to comms and the rest to the main view, like this: http://mono.dzonux.net/file/MonoVida-20090620b.png In the normal viewer, the communication window would be extra vertices to process. In MonoVida, there are no GL verticies or GL text to process, as the communication window doesn't even use GL. I could make the main view very small and just be involved with the commuication windows and maybe other applications/IDEs. I think you'll agree the fuller view of the communication window is much easier to read. Anways, mainly wanted to add a question how many extra vertices are being used by LLUI? Melinda Green wrote: > Maybe there is more than one XUI here and I could be the one causing > the confusion but I had thought that what LL's calls XUI was an > entirely homegrown XML schema. (Or is that LLUI?) Anyway, there's no > connection to Java that I'm aware of, and being a big Java nut, I'd > certainly have remembered that. > > Good luck getting traction with your Snowglobe-Sharp API. That does > sound interesting. > -Melinda > > Dzonatas Sol wrote: >> The XUI standard is still tied to Java. That means the fully >> scriptable XUI formats are limited to Java programmers. With the XUI >> standard also being tied to mobile devices that depend on Java, well, >> I guess the right question to ask is how to get XUI to work well, >> being fully scripted (with Java), on mobile devices that don't run >> Java? I'm sure further discussion on that will go beyond interfaces >> to handle rendering limits. >> >> Also note, there are already Eclipse plug-ins for XUI builders. Since >> there are more than a few, I'll just link to a forum about them: >> http://sourceforge.net/forum/forum.php?forum_id=556171 >> >> If the fully scriptable XUI/Java based interface can reach the same >> API that any other alternative scriptable UI can reach, then that API >> is key... rather than require transformations of XUI to any degree. >> >> Note, I have already made an API for ControlGroup classes in >> Snowglobe-Sharp, and it does make things that much more powerful (as >> you even noted with XUI). >> >> Melinda Green wrote: >>> It is definitely on the road map to eventually support a fully >>> scriptable XUI format as well as to allow programmatic viewer >>> control from external processes through published APIs. I don't >>> expect that the native scripting language will be anything like LSL, >>> but who knows, that might not be such a bad idea. Visual GUI >>> builders are definitely another direction in which I expect this to >>> grow, and implementing one as an Eclipse plug-in definitely looks >>> like the quickest path to me. I don't know anything about Glade but >>> perhaps that would make that task even easier. The key will be to >>> get such GUI builders to read and write XUI files. That much could >>> be done today even without any scripting ability, and even the LL >>> designers struggle to hand-code XUI when such a GUI builder would >>> save so much time in the long run. That's definitely a plumb task >>> that an enterprising SLDev member could take on and earn much love. >>> In the meantime I highly encourage anyone interested to get more >>> familiar with the powerful XUI features available today. Much of it >>> is undocumented, and helping to create *that* missing piece would be >>> a great place to start since clear specs are absolute prerequisites >>> for creating GUI builders or any other infrastructure on top of it. >>> >>> -Melinda >>> >>> Dzonatas Sol wrote: >>>> I think what some people want is a like a LSL based code-behind >>>> feature to the UI. >>>> >>>> Did I say it? Oops, I did. >>>> >>>> Hold that thought. >>>> >>>> Actually, I'm eager for GtkBuilder to fully phase-in, then UI >>>> builders like the Glade Interface Designer would have lots of fun >>>> interactive, custom widgets ready to use in the palette: >>>> http://glade.gnome.org/screenshots.html >>>> >>>> Example vid of using Glade: >>>> http://people.redhat.com/overholt/nativeeclipse/ >>>> >>>> Of course, that was with Eclipse, and the Eclipse UI is written >>>> with Gtk. Hmmm - powerful enough for holistic programmers. >>>> >>>> Here is an older review of Glade: >>>> http://loosexaml.wordpress.com/2008/10/14/giving-glade-a-fair-shake/ >>>> >>>> The Glade Interface Designer is also a library, so it is embeddable >>>> (into some viewer app someday maybe): >>>> http://glade.gnome.org/docs/index.html >>>> >>>> Ok, I said too much. >>>> >>>> Cheers, >>>> http://twitter.com/Dzonatas >>>> >>>> Melinda Green wrote: >>>>> Nexi, >>>>> >>>>> I'm not stating an opinion about the value of Windlight controls >>>>> one way or the other. I do agree with you that it would be better >>>>> if the setting names were better chosen in order to organize them >>>>> into some meaningful hierarchy, but the chance to do that passed a >>>>> long time ago. Even if someone did the huge job of changing the >>>>> names throughout the entire source code and XUI content, that >>>>> patch would never be accepted because of the branches within LL >>>>> (and externally) that would be affected. The end result is that >>>>> once you name a setting or control, it's nearly >>>>> impossible/impractical to change it. We're then left with an >>>>> underlying flat list of settings for better or worse and I >>>>> therefore believe this is *not* the place to start! We could of >>>>> course impose an external organization onto that list though a >>>>> config UI like you suggest. That sounds like a good idea to me but >>>>> is completely orthogonal to taking advantage of the existing >>>>> XUI<-->saved settings bridge. >>>>> >>>>> If anyone wants to see good examples of doing the sort of stuff >>>>> I'm talking about, I recommend looking at the new View->Beacons >>>>> floater implementation that I created. It was implemented almost >>>>> entirely in XML, only requiring C++ code to launch the floater and >>>>> to enforce a couple of the previous quirky interactions between >>>>> the beacon types. The rest is implemented entirely in XUI making >>>>> heavy use of the control_name tag. BTW, this is how many of the >>>>> Windlight controls were implemented too and was where I found the >>>>> examples I needed when doing the beacons work. This is an >>>>> incredibly powerful and underused pattern. >>>>> >>>>> -Melinda >>>>> >>>>> Nexii Malthus wrote: >>>>> >>>>>> Well, I think we could start by re-working the debug-settings >>>>>> menu a bit. >>>>>> >>>>>> Load up Firefox and go to this page: "about:config" >>>>>> >>>>>> Thats an excellent example of a good debug settings menu. The >>>>>> settings are easily understandable imho. >>>>>> >>>>>> Seperated into their relevant sections, I think it would be >>>>>> great if we had that a similiar naming scheme. That would be at >>>>>> least one step towards opening up the deeper parts of the engine >>>>>> towards users. Not to mention the help it would provide to >>>>>> developers, lindens and non-lindens alike for making it easier to >>>>>> test out experimental features or performance optimizations. >>>>>> >>>>>> Imagine a naming scheme towards the graphical subsystems. >>>>>> render.spatial.maxnodesize for this situation as a loose example. >>>>>> >>>>>> Wouldn't it be easier and efficient to expose only the relevant >>>>>> debug settings to each subsystem too? render.* being available to >>>>>> the render stuff. network.* being for the network stuff. >>>>>> >>>>>> If we want to revamp the whole way preferences work we need to >>>>>> move step-by-step from the bottom up. >>>>>> >>>>>> I do agree that the LL designers feel a bit itchy about the >>>>>> current windlight preferences and I agree, it is messy. But its >>>>>> wrong to hide the tools for the right job when you consider the >>>>>> majority of individuals that are willing to go a step further to >>>>>> make their experience so much better. >>>>>> >>>>>> Just look at the stuff Torley and other talented photographers >>>>>> have made in snapshots by messing about in the windlight settings >>>>>> and shadows. >>>>>> >>>>>> - Nexii Malthus >>>>>> >>>>>> On Fri, Jun 19, 2009 at 9:45 PM, Melinda Green >>>>>> > wrote: >>>>>> >>>>>> That's an interesting suggestion, Nexii. I'm not sure how the LL >>>>>> designers feel about all those Windlight preferences but I >>>>>> wouldn't be surprised if they'd mostly prefer to hide or >>>>>> eliminate >>>>>> most of them. There's always a tension between number of >>>>>> controls >>>>>> and the all-important SL learning curve. >>>>>> >>>>>> One way to break this logjam is to start using the new XUI >>>>>> features to allow external designers to create custom UI without >>>>>> the need for developers to hook them in and compile entire >>>>>> custom >>>>>> viewer binaries and then update them with each viewer version. >>>>>> Skinning is the first step on that road but there is a lot of >>>>>> other useful stuff under the hood that can also be used >>>>>> today. My >>>>>> favorite is the "control_name" XUI tag which lets you associate >>>>>> check box and slider values with particular saved settings. When >>>>>> you load a floater or other XUI element containing a check >>>>>> box or >>>>>> slider with that tag, then it takes it's initial value from the >>>>>> named saved setting and automatically saves back out modified >>>>>> values as the user interacts with those controls. >>>>>> >>>>>> This is extremely powerful and should let you create your custom >>>>>> panel to control any of the boolean or real valued settings that >>>>>> you see in the debug settings floater. The only thing really >>>>>> missing here (other than support for more control types) is the >>>>>> ability to launch a custom floater. Ideally that would come with >>>>>> the badly needed keyboard remapping functionality to allow >>>>>> you to >>>>>> specify a hot key to load a named floater. (Hint: Great >>>>>> Snowglobe >>>>>> feature here!) Since we don't have that yet, you'd probably have >>>>>> to append your controls to some existing floater if you want to >>>>>> add controls without programming, but that shouldn't be too >>>>>> awful. >>>>>> >>>>>> -Melinda >>>>>> >>>>>> Nexii Malthus wrote: >>>>>> >>>>>> I think by spatial groups you could consider how dense an >>>>>> area is. >>>>>> >>>>>> We really should open many more options on the preferences >>>>>> menu. Perhaps it should branch off into a seperate menu >>>>>> due to >>>>>> the relevant complexity, imagine how complex the windlight >>>>>> sliders are, but they are also nicely dispersed into their >>>>>> relevant categories and sections. We should aim to >>>>>> achieve the >>>>>> same, not to mention the explanations that were provided in >>>>>> the WindLight menu were pretty cool and awesome to >>>>>> understand >>>>>> what the settings do. >>>>>> >>>>>> WindLight is a mere single subsystem of the entire graphics >>>>>> system, why can't we have the same attention put into other >>>>>> areas in terms of control via the UI? >>>>>> >>>>>> There are many hidden settings, some that are not even >>>>>> affected by the more generalised "Low, Medium, High, Ultra" >>>>>> that have an impact on FPS and the experience. >>>>>> >>>>>> L$0.02. >>>>>> >>>>>> - Nexii Malthus >>>>>> >>>>>> On Fri, Jun 19, 2009 at 7:50 PM, Harleen Gretzky >>>>>> >>>>> >>>>>> >>>>> >> wrote: >>>>>> >>>>>> It appears to be more than just jewelry that is effected. >>>>>> VWR-14049 and VWR-14146 are builds that are effected >>>>>> also. When >>>>>> posing this question I was really trying to understand >>>>>> how the >>>>>> rendering limits work. For instance, does the >>>>>> renderMaxNodeSize >>>>>> limit apply to the entire scene, or only to portions >>>>>> of the >>>>>> scene? >>>>>> Does it apply to avatars as well as objects? It seems >>>>>> to have >>>>>> something to do with 'spatial groups' but what are >>>>>> 'spatial >>>>>> groups'? Is renderMaxNodeSize the only rendering limit? >>>>>> >>>>>> If renderMaxNodeSize is the only setting that, I would >>>>>> think the >>>>>> best solution as has been suggested on the JIRAs and >>>>>> here is to >>>>>> move the setting onto the Graphics preference tab. >>>>>> Since it >>>>>> seems >>>>>> to be a little low for those running graphics at High and >>>>>> Ultra it >>>>>> should probably be increased for those users. So maybe >>>>>> something like: >>>>>> >>>>>> Low - 2048 >>>>>> Mid - 4096 >>>>>> High - 8192 >>>>>> Ultra - 8192 >>>>>> >>>>>> Then if a user chooses Custom there should be a slider >>>>>> control to >>>>>> allow it to be set to the value of their choice. Just my >>>>>> two cents. >>>>>> >>>>>> -Harleen >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Policies and (un)subscribe information available here: >>>>>> http://wiki.secondlife.com/wiki/SLDev >>>>>> Please read the policies before posting to keep >>>>>> unmoderated >>>>>> posting privileges >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Policies and (un)subscribe information available here: >>>>>> http://wiki.secondlife.com/wiki/SLDev >>>>>> Please read the policies before posting to keep unmoderated >>>>>> posting privileges >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Policies and (un)subscribe information available here: >>>>> http://wiki.secondlife.com/wiki/SLDev >>>>> Please read the policies before posting to keep unmoderated >>>>> posting privileges >>>>> >>>>> >>>> >>> >> >> > From sheet.spotter at gmail.com Sat Jun 20 22:04:46 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Sun, 21 Jun 2009 00:04:46 -0500 Subject: [sldev] [SNOW] Problems with high resolution textures Message-ID: <13A7696F1258448882C8C2DE7CAD0940@kenb> An enhancement in the Snowglobe viewer may be responsible for problems with high resolution textures. I'm hoping someone in SLDev can confirm this and start the search for solutions. Two examples of this problem are SNOW-45 (some large textures do not render properly) and SNOW-48 (textures not resolving on megaprims). The Texture Console provided a clue to the underlying cause. In SNOW-45 and SNOW-48 when you zoom in on the objects the "Area" column in the Texture Console seems to be artificially limited to 4,096 or 65,536 for the misbehaving textures. (You need to right-click and edit the object to see its textures highlighted in the Texture Console.) In some cases the Area value actually drops when you zoom in. The new Snowglobe viewer includes optimizations that reduce the detail in textures that are "not important to the camera". This seems to be aimed at improving memory utilization by limiting the use of large textures when they have no benefit. For example, when a face is "less important" it will be drawn with only a 64x64 texture (that's where the 4,096 comes from). Larger faces that are less important may be drawn with a 256x256 texture (that's the 65,536 value). In the Snowglobe source code the LLFace::calcImportanceToCamera method determines how important each face is in the avatar's camera, and the LLFace::getTextureVirtualSize method imposes limits on the texture size based on this importance. (The value returned by getTextureVirtualSize is displayed in the Area column in the Texture console.) One of these two methods seems to be responsible for limiting the detail in the textures displayed in SNOW-45 and SNOW-48. I hope someone more experienced in this area of the code can confirm these findings, and further the cause by proposing possible solutions. A simpler explanation of these findings will be added as a comment to SNOW-48. Sheet Spotter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090621/753ca933/attachment.htm From GordonWendt at gmail.com Sat Jun 20 22:30:03 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sun, 21 Jun 2009 01:30:03 -0400 Subject: [sldev] [SNOW] Problems with high resolution textures In-Reply-To: <13A7696F1258448882C8C2DE7CAD0940@kenb> References: <13A7696F1258448882C8C2DE7CAD0940@kenb> Message-ID: <493033a70906202230w1e66e651jd4ec6052d931422e@mail.gmail.com> There's also a really popular misfiled (at vwr instead of snow) at http://jira.secondlife.com/browse/VWR-14180 that's about this problem just an fyi. -Gordon On Sun, Jun 21, 2009 at 1:04 AM, Sheet Spotter wrote: > An enhancement in the Snowglobe viewer may be responsible for problems > with high resolution textures. I?m hoping someone in SLDev can confirm this > and start the search for solutions. > > > > Two examples of this problem are SNOW-45 (some large textures do not render > properly) and SNOW-48 (textures not resolving on megaprims). > > > > The Texture Console provided a clue to the underlying cause. In SNOW-45 and > SNOW-48 when you zoom in on the objects the ?Area? column in the Texture > Console seems to be artificially limited to 4,096 or 65,536 for the > misbehaving textures. (You need to right-click and edit the object to see > its textures highlighted in the Texture Console.) In some cases the Area > value actually drops when you zoom in. > > > > The new Snowglobe viewer includes optimizations that reduce the detail in > textures that are ?not important to the camera?. This seems to be aimed at > improving memory utilization by limiting the use of large textures when they > have no benefit. For example, when a face is ?less important? it will be > drawn with only a 64x64 texture (that?s where the 4,096 comes from). Larger > faces that are less important may be drawn with a 256x256 texture (that?s > the 65,536 value). > > > > In the Snowglobe source code the LLFace::calcImportanceToCamera method > determines how important each face is in the avatar?s camera, and the > LLFace::getTextureVirtualSize method imposes limits on the texture size > based on this importance. (The value returned by getTextureVirtualSize is > displayed in the Area column in the Texture console.) One of these two > methods seems to be responsible for limiting the detail in the textures > displayed in SNOW-45 and SNOW-48. > > > > I hope someone more experienced in this area of the code can confirm these > findings, and further the cause by proposing possible solutions. A simpler > explanation of these findings will be added as a comment to SNOW-48. > > > > > > Sheet Spotter > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090621/ff4950e5/attachment.htm From gretzky.harleen at gmail.com Sat Jun 20 22:36:32 2009 From: gretzky.harleen at gmail.com (Harleen Gretzky) Date: Sun, 21 Jun 2009 01:36:32 -0400 Subject: [sldev] [SNOW] Problems with high resolution textures In-Reply-To: <493033a70906202230w1e66e651jd4ec6052d931422e@mail.gmail.com> References: <13A7696F1258448882C8C2DE7CAD0940@kenb> <493033a70906202230w1e66e651jd4ec6052d931422e@mail.gmail.com> Message-ID: <5c63fe8c0906202236j6b9bf3q412f64a0dc32d549@mail.gmail.com> I moved VWR-14180 to SNOW-48 this afternoon, it was originally SNOW-30. On Sun, Jun 21, 2009 at 1:30 AM, Gordon Wendt wrote: > There's also a really popular misfiled (at vwr instead of snow) at > http://jira.secondlife.com/browse/VWR-14180 that's about this problem just > an fyi. > > -Gordon > > On Sun, Jun 21, 2009 at 1:04 AM, Sheet Spotter wrote: > >> An enhancement in the Snowglobe viewer may be responsible for problems >> with high resolution textures. I?m hoping someone in SLDev can confirm this >> and start the search for solutions. >> >> >> >> Two examples of this problem are SNOW-45 (some large textures do not >> render properly) and SNOW-48 (textures not resolving on megaprims). >> >> >> >> The Texture Console provided a clue to the underlying cause. In SNOW-45 >> and SNOW-48 when you zoom in on the objects the ?Area? column in the Texture >> Console seems to be artificially limited to 4,096 or 65,536 for the >> misbehaving textures. (You need to right-click and edit the object to see >> its textures highlighted in the Texture Console.) In some cases the Area >> value actually drops when you zoom in. >> >> >> >> The new Snowglobe viewer includes optimizations that reduce the detail in >> textures that are ?not important to the camera?. This seems to be aimed at >> improving memory utilization by limiting the use of large textures when they >> have no benefit. For example, when a face is ?less important? it will be >> drawn with only a 64x64 texture (that?s where the 4,096 comes from). Larger >> faces that are less important may be drawn with a 256x256 texture (that?s >> the 65,536 value). >> >> >> >> In the Snowglobe source code the LLFace::calcImportanceToCamera method >> determines how important each face is in the avatar?s camera, and the >> LLFace::getTextureVirtualSize method imposes limits on the texture size >> based on this importance. (The value returned by getTextureVirtualSize is >> displayed in the Area column in the Texture console.) One of these two >> methods seems to be responsible for limiting the detail in the textures >> displayed in SNOW-45 and SNOW-48. >> >> >> >> I hope someone more experienced in this area of the code can confirm these >> findings, and further the cause by proposing possible solutions. A simpler >> explanation of these findings will be added as a comment to SNOW-48. >> >> >> >> >> >> Sheet Spotter >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090621/fa51ec8e/attachment.htm From robla at lindenlab.com Sat Jun 20 23:33:31 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Sat, 20 Jun 2009 23:33:31 -0700 Subject: [sldev] A couple of Snowglobe crashing bugs to repro Message-ID: <4A3DD43B.3080109@lindenlab.com> Hi folks, There's a couple of crashing bugs that I'm hoping people here can try reproducing with Snowglobe, and report your results back in JIRA; Problem #1: Viewer crashes immediately on changing screen mode (Linux): https://jira.secondlife.com/browse/SNOW-43 I tried this myself on Linux, and did not see it. I've not tried this on Windows and Mac yet. If everyone could try this regardless of platform and note your results, that'd be wonderful to know the scope of the issue. Problem #2: Crash occured during TP-ing from Home location to the sim next door https://jira.secondlife.com/browse/SNOW-38 (found during test sprint...no separate issue filed yet) I wasn't able to repro this one either. Anyone else seeing these issues? Rob From snowfox102 at dragonkeepcreations.com Sat Jun 20 23:36:07 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Sun, 21 Jun 2009 01:36:07 -0500 Subject: [sldev] Unfamiliar Snowglobe build error In-Reply-To: <4A3D908E.2080800@dragonkeepcreations.com> References: <4A3C56F7.7050406@lindenlab.com> <4A3D8C34.6000901@dragonkeepcreations.com> <824c8ab70906201834j395e3154m6cafe7e117968199@mail.gmail.com> <4A3D908E.2080800@dragonkeepcreations.com> Message-ID: <4A3DD4D7.3030308@dragonkeepcreations.com> Hm, nope, still erroring. How could the settings XML be incorrect, exactly? Maya Maya Remblai wrote: > It's there, but that does give me an idea of what the problem may be. I > don't recall ever seeing any info on errors about settings_files.xml > being missing, so I've fixed it in other versions by copying in the file > from a successful build. But this time, the copied file was not from the > same version of the viewer, so that may be the problem. > > Maya > > Nexii Malthus wrote: > >> A preliminary guess is that your settings xml is incorrect or not >> present under app_settings? >> >> - Nexii Malthus >> >> On Sun, Jun 21, 2009 at 2:26 AM, Maya Remblai >> > > wrote: >> >> Me again. >> >> Since the RCs of Snowglobe looked pretty promising to me, I decided to >> try building from source to get a version useful to me. Before >> doing any >> patching, I tried building with just the supplied code. The build goes >> fine, though VS doesn't launch the compiled program. Running >> secondlife-bin.exe results in a pop-up saying >> >> ERROR: LLControlGroup::getLLSD: Invalid LLSD control Locations >> >> I've not seen this with any other source code. Any ideas? >> >> Maya >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated >> posting privileges >> >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From gretzky.harleen at gmail.com Sat Jun 20 23:46:25 2009 From: gretzky.harleen at gmail.com (Harleen Gretzky) Date: Sun, 21 Jun 2009 02:46:25 -0400 Subject: [sldev] A couple of Snowglobe crashing bugs to repro In-Reply-To: <4A3DD43B.3080109@lindenlab.com> References: <4A3DD43B.3080109@lindenlab.com> Message-ID: <5c63fe8c0906202346i7272705fi6992c6450a76590@mail.gmail.com> The SNOW-38 crash does not reproduce for me. Snowglobe 1.0.2 (2451) Jun 19 2009 19:29:16 (Snowglobe Release) Release Notes Built with MSVC version 1400 You are at 250696.7, 240751.4, 22.8 in ParrotHead Island located at sim2094.agni.lindenlab.com (216.82.16.99:13004) Second Life Server 1.26.4.120562 Release Notes CPU: Intel Pentium 4 (Unknown model) (3200 MHz) Memory: 2047 MB OS Version: Microsoft Windows XP Service Pack 3 (Build 2600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7800 GTX/PCI/SSE2 Windows Graphics Driver Version: 6.14.0011.8250 OpenGL Version: 2.1.2 libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3 J2C Decoder Version: KDU Audio Driver Version: FMOD version 3.750000 LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.24800 (Mozilla GRE version 1.8.1.21_0000000000) Packets Lost: 124/636259 (0.0%) On Sun, Jun 21, 2009 at 2:33 AM, Rob Lanphier wrote: > Hi folks, > > There's a couple of crashing bugs that I'm hoping people here can try > reproducing with Snowglobe, and report your results back in JIRA; > > Problem #1: Viewer crashes immediately on changing screen mode (Linux): > https://jira.secondlife.com/browse/SNOW-43 > > I tried this myself on Linux, and did not see it. I've not tried this > on Windows and Mac yet. If everyone could try this regardless of > platform and note your results, that'd be wonderful to know the scope of > the issue. > > Problem #2: Crash occured during TP-ing from Home location to the sim > next door > https://jira.secondlife.com/browse/SNOW-38 > (found during test sprint...no separate issue filed yet) > > I wasn't able to repro this one either. > > Anyone else seeing these issues? > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090621/ac3de6d7/attachment.htm From carlo at alinoe.com Sun Jun 21 06:32:01 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 21 Jun 2009 15:32:01 +0200 Subject: [sldev] Compile error Snowglobe SVN Message-ID: <20090621133201.GA1913@alinoe.com> Now that my videocard burned out, I decided to check out (haha) snowglobe and attempt to get it to compile. There is not much information on how to do this on the Wiki imho - so, during this attempt I added some links to the Wiki in the places where I got stuck at first. I won't complain about ./develop.py downloading loads of i686 binaries to my 100% 64bit machine, and then happily compiling a 32bit version, because I know that 64bit is not officially supported (but a warning of some sort would have been nice, or at least a remark on the Wiki). Nevertheless, ./develop.py --help gave me information that is lacking on the Wiki and I configured as follows: ./develop.py --type=Debug -m64 --standalone configure Next I built as follows: ./develop.py --type=Debug -m64 --standalone build this fails to compile with the following error: /usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/test/test.cpp: In member function ?virtual void LLTestCallback::test_completed(const tut::test_result&)?: /usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/test/test.cpp:109: error: ?skip? is not a member of ?tut::test_result? /usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/test/test.cpp: In function ?void wouldHaveCrashed(const std::string&)?: /usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/test/test.cpp:236: error: cannot convert ?std::basic_string, std::allocator >? to ?const char*? for argument ?1? to ?void tut::::fail(const char*)? make[2]: *** [newview/CMakeFiles/llagentaccess_test.dir/__/test/test.cpp.o] Error 1 make[2]: Leaving directory `/usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/viewer-linux-x86_64-debug' -- Carlo Wood From alissa_sabre at yahoo.co.jp Sun Jun 21 06:46:07 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun, 21 Jun 2009 22:46:07 +0900 Subject: [sldev] How to use distcc on Linux using http-texture source Message-ID: <74s0ekwmed4ds40aJ4G5httc.alissa_sabre@yahoo.co.jp> I grabbed the viewer source in the http-texture branch (aka Snowglobe) from the public svn at r2451. I couldn't make use of distcc with it. How can I enable distcc? I tried followings: CXX="distcc i386-redhat-linux-g++" python.py configure The configuration apparently worked, but the generated build.make files contained hard-coded references to /usr/bin/g++ python develop.py --distcc configure This didn't work with a message: Error: option --distcc not recognized Thanks in advance, Alissa Sabre P.S., I have a feeling I always ask distcc related question when the viewer build system has changed... -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From lists.secondlife.com at trap.wereanimal.net Sun Jun 21 08:12:35 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Sun, 21 Jun 2009 11:12:35 -0400 Subject: [sldev] Some early automation tests results. In-Reply-To: <824c8ab70906160242l46e24d82q1dd75a042c38859d@mail.gmail.com> References: <200906111104.03650.lists.secondlife.com@trap.wereanimal.net> <824c8ab70906160242l46e24d82q1dd75a042c38859d@mail.gmail.com> Message-ID: <200906211112.35458.lists.secondlife.com@trap.wereanimal.net> On Tuesday 16 June 2009 5:42:26 am Nexii Malthus wrote: > Very nice work. Could the results perhaps be posted into a statistics > graph? A graph may be more readable than plain text. > I worked on it some more and have created a web page with some graphs. http://gentoo.techwolf.net/performance/ --Techwolf Lupindo From snowfox102 at dragonkeepcreations.com Sun Jun 21 08:35:28 2009 From: snowfox102 at dragonkeepcreations.com (Maya Remblai) Date: Sun, 21 Jun 2009 10:35:28 -0500 Subject: [sldev] Unfamiliar Snowglobe build error In-Reply-To: <4A3DD4D7.3030308@dragonkeepcreations.com> References: <4A3C56F7.7050406@lindenlab.com> <4A3D8C34.6000901@dragonkeepcreations.com> <824c8ab70906201834j395e3154m6cafe7e117968199@mail.gmail.com> <4A3D908E.2080800@dragonkeepcreations.com> <4A3DD4D7.3030308@dragonkeepcreations.com> Message-ID: <4A3E5340.9000101@dragonkeepcreations.com> I got the build to run by making a shortcut to the exe and making the Start In line point to \indra\newview. So that's one mystery solved. Now I have another question. After some urging from some friends, I tried to set up a standalone build. Using this command: develop.py --standalone -G vc80 configure I get cmake errors about "pkg-config tool not found", and one that says "Could not find BerkeleyDB library." Are there some packages I'm missing? There's nothing that I can see about this on the wiki, so I'm pretty much stuck. Maya From carlo at alinoe.com Sun Jun 21 14:46:52 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 21 Jun 2009 23:46:52 +0200 Subject: [sldev] Some early automation tests results. In-Reply-To: <200906211112.35458.lists.secondlife.com@trap.wereanimal.net> References: <200906111104.03650.lists.secondlife.com@trap.wereanimal.net> <824c8ab70906160242l46e24d82q1dd75a042c38859d@mail.gmail.com> <200906211112.35458.lists.secondlife.com@trap.wereanimal.net> Message-ID: <20090621214652.GA15235@alinoe.com> Nice work TechWolf, I'm a bit sceptical about any positive conclusions that might be drawn from this however. Since 40 FPS is more than enough, I'd not be happy if the fps went from 60 to 120 at the cost of LOD or other detail (even drawing less prims due to the new limits). Therefore I think you should try to do a test where the FPS is on the low side; with 1.22.11 under 20 at least, better would be a fps of 10. Although, EVEN in that case I'd like to know how much was actually drawn on the screen (thus, not just a count of the FPS but also the number polygons being drawn and a figure that tells us that the textures look ok. Perhaps you can make a test with a static screen (just standing somewhere), so that every test can be accompanied with a screenshot that will allow us to see the differences in quality (if any). On Sun, Jun 21, 2009 at 11:12:35AM -0400, lists.secondlife.com at trap.wereanimal.net wrote: > I worked on it some more and have created a web page with some graphs. > > http://gentoo.techwolf.net/performance/ > > --Techwolf Lupindo -- Carlo Wood From carlo at alinoe.com Sun Jun 21 15:46:20 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 22 Jun 2009 00:46:20 +0200 Subject: [sldev] Compile error Snowglobe SVN In-Reply-To: <20090621133201.GA1913@alinoe.com> References: <20090621133201.GA1913@alinoe.com> Message-ID: <20090621224620.GA21198@alinoe.com> See http://jira.secondlife.com/browse/VWR-12873 On Sun, Jun 21, 2009 at 03:32:01PM +0200, Carlo Wood wrote: > /usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/test/test.cpp: In member function ?virtual void LLTestCallback::test_completed(const tut::test_result&)?: > /usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/test/test.cpp:109: error: ?skip? is not a member of ?tut::test_result? > /usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/test/test.cpp: In function ?void wouldHaveCrashed(const std::string&)?: > /usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/test/test.cpp:236: error: cannot convert ?std::basic_string, std::allocator >? to ?const char*? for argument ?1? to ?void tut::::fail(const char*)? > make[2]: *** [newview/CMakeFiles/llagentaccess_test.dir/__/test/test.cpp.o] Error 1 > make[2]: Leaving directory `/usr/src/secondlife/secondlife/snowglobe/snowglobe-svn/indra/viewer-linux-x86_64-debug' From kck325 at gmail.com Sun Jun 21 22:47:00 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Mon, 22 Jun 2009 00:47:00 -0500 Subject: [sldev] Error while launching application. Message-ID: I am able to successfully compile version 1.23 on VC++ 2008 Express edition. But while launching the application, I am getting the following error *First-chance exception at 0x012d9a8a in secondlife-bin.exe: 0xC0000005: Access violation writing location 0xabababaf. Unhandled exception at 0x012d9a8a in secondlife-bin.exe: 0xC0000005: Access violation writing location 0xabababaf.* And the application is not launched. Can somebody help me? -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090622/93ce2b12/attachment.htm From robin.cornelius at gmail.com Mon Jun 22 00:33:38 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 22 Jun 2009 08:33:38 +0100 Subject: [sldev] Error while launching application. In-Reply-To: References: Message-ID: On Mon, Jun 22, 2009 at 6:47 AM, chandra kiran kuchi wrote: > I am able to successfully compile version 1.23 on VC++ 2008 Express edition. > > But while launching the application, I am getting the following error > > First-chance exception at 0x012d9a8a in secondlife-bin.exe: 0xC0000005: > Access violation writing location 0xabababaf. > Unhandled exception at 0x012d9a8a in secondlife-bin.exe: 0xC0000005: Access > violation writing location 0xabababaf. > > And the application is not launched. > > Can somebody help me? What did you do about the boost libraries? If the answer is nothing then - The ones that LL supply are NOT compatible with visual studio 2008 and if you look at the stack trace you will see the crash is boost:: related. The options are find a copy of visual studio 2005 or build a newer boost and replace the p rebuilt boost libs with your own Robin From kck325 at gmail.com Mon Jun 22 06:57:47 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Mon, 22 Jun 2009 08:57:47 -0500 Subject: [sldev] Error while launching application. In-Reply-To: References: Message-ID: True, looks like the case. The following is the error message. > secondlife-bin.exe!boost::signals::detail::bound_objects_visitor::operator() > >(const boost::function > & t={...}) Line 76 C++ But I have already built the required boost files and copied into my linden\libraries\i686-win32\release and linden\libraries\i686-win32\debug directories. Should I copy them to any other place? On Mon, Jun 22, 2009 at 2:33 AM, Robin Cornelius wrote: > On Mon, Jun 22, 2009 at 6:47 AM, chandra kiran kuchi > wrote: > > I am able to successfully compile version 1.23 on VC++ 2008 Express > edition. > > > > But while launching the application, I am getting the following error > > > > First-chance exception at 0x012d9a8a in secondlife-bin.exe: 0xC0000005: > > Access violation writing location 0xabababaf. > > Unhandled exception at 0x012d9a8a in secondlife-bin.exe: 0xC0000005: > Access > > violation writing location 0xabababaf. > > > > And the application is not launched. > > > > Can somebody help me? > > What did you do about the boost libraries? If the answer is nothing > then - The ones that LL supply are NOT compatible with visual studio > 2008 and if you look at the stack trace you will see the crash is > boost:: related. The options are find a copy of visual studio 2005 or > build a newer boost and replace the p rebuilt boost libs with your own > > Robin > -- Regards, Chandra K Kuchi Graduate Student Experimental Computing Lab University of Cincinnati Cincinnati. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090622/c6f65916/attachment.htm From monkowsk at watson.ibm.com Mon Jun 22 07:50:08 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 22 Jun 2009 10:50:08 -0400 Subject: [sldev] XUI controls; was: Rendering Limits In-Reply-To: <4A3BF8F8.3030703@superliminal.com> References: <5c63fe8c0906170702x176853b4i40ff0579ff0bd2b8@mail.gmail.com> <9bb32d430906180059u6c812a57pdab0981592581041@mail.gmail.com> <4A3A5E9D.3@Gmail.com> <4A3A6E9E.4040707@gmail.com> <4A3AF1D5.4060506@superliminal.com> <5c63fe8c0906191150x4cd01b7fm3f46b1425a21f428@mail.gmail.com> <824c8ab70906191310yc2a12aate83d177f4891b746@mail.gmail.com> <4A3BF8F8.3030703@superliminal.com> Message-ID: <4A3F9A20.4020309@watson.ibm.com> There is a function "XUI->Load from XML..." in the Advanced menu that allows you to load a floater from an XML file. It is currently broken, but is easily patched. I've been helping Admiral Admiral with an XUI project. I can ask him to post the patch for "Load from XML..." if anyone is interested. He's adding more documentation on the XML elements and attributes. See http://wiki.secondlife.com/wiki/Skinning_HowTo/Basics#Related_to_layout for links to the detailed documentation. It's still a work-in-progress, but the outline is there. There are a *lot* of attributes. Mike SL: Mm Alder, Fiddler Jones Melinda Green wrote: > This is extremely powerful and should let you create your custom panel > to control any of the boolean or real valued settings that you see in > the debug settings floater. The only thing really missing here (other > than support for more control types) is the ability to launch a custom > floater. Ideally that would come with the badly needed keyboard > remapping functionality to allow you to specify a hot key to load a > named floater. (Hint: Great Snowglobe feature here!) Since we don't have > that yet, you'd probably have to append your controls to some existing > floater if you want to add controls without programming, but that > shouldn't be too awful. > > -Melinda From melinda at superliminal.com Mon Jun 22 10:29:41 2009 From: melinda at superliminal.com (Melinda Green) Date: Mon, 22 Jun 2009 10:29:41 -0700 Subject: [sldev] XUI controls; was: Rendering Limits Message-ID: <4A3FBF85.90406@superliminal.com> Great info! I've added some brief documentation on the control-name tag to https://wiki.secondlife.com/wiki/UI_Widgets and https://wiki.secondlife.com/wiki/Skinning_HowTo/Common_XUI_XML_parameters Once the Advanced>XUI->Load from XML control is working again, this will allow designers to control all sorts of thing without programming. Thanks Mike! -Melinda Mike Monkowski wrote: > There is a function "XUI->Load from XML..." in the Advanced menu that > allows you to load a floater from an XML file. It is currently > broken, but is easily patched. I've been helping Admiral Admiral with > an XUI project. I can ask him to post the patch for "Load from > XML..." if anyone is interested. > > He's adding more documentation on the XML elements and attributes. > See > http://wiki.secondlife.com/wiki/Skinning_HowTo/Basics#Related_to_layout > for links to the detailed documentation. It's still a > work-in-progress, but the outline is there. There are a *lot* of > attributes. > > Mike > SL: Mm Alder, Fiddler Jones > > > Melinda Green wrote: >> This is extremely powerful and should let you create your custom >> panel to control any of the boolean or real valued settings that you >> see in the debug settings floater. The only thing really missing here >> (other than support for more control types) is the ability to launch >> a custom floater. Ideally that would come with the badly needed >> keyboard remapping functionality to allow you to specify a hot key to >> load a named floater. (Hint: Great Snowglobe feature here!) Since we >> don't have that yet, you'd probably have to append your controls to >> some existing floater if you want to add controls without >> programming, but that shouldn't be too awful. >> >> -Melinda > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090622/02f7edd5/attachment.htm From kck325 at gmail.com Mon Jun 22 12:37:51 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Mon, 22 Jun 2009 14:37:51 -0500 Subject: [sldev] Error while launching application. In-Reply-To: References: Message-ID: This seems to be one of the common errors when compiling with MSVS 2008, does anybody have fix for this? http://pastebin.com/m55301956 On Mon, Jun 22, 2009 at 8:57 AM, chandra kiran kuchi wrote: > True, looks like the case. The following is the error message. > > > > secondlife-bin.exe!boost::signals::detail::bound_objects_visitor::operator() __cdecl(void),std::allocator > >(const boost::function __cdecl(void),std::allocator > & t={...}) Line 76 C++ > > But I have already built the required boost files and copied into my > linden\libraries\i686-win32\release and linden\libraries\i686-win32\debug > directories. Should I copy them to any other place? > > > > On Mon, Jun 22, 2009 at 2:33 AM, Robin Cornelius < > robin.cornelius at gmail.com> wrote: > >> On Mon, Jun 22, 2009 at 6:47 AM, chandra kiran kuchi >> wrote: >> > I am able to successfully compile version 1.23 on VC++ 2008 Express >> edition. >> > >> > But while launching the application, I am getting the following error >> > >> > First-chance exception at 0x012d9a8a in secondlife-bin.exe: 0xC0000005: >> > Access violation writing location 0xabababaf. >> > Unhandled exception at 0x012d9a8a in secondlife-bin.exe: 0xC0000005: >> Access >> > violation writing location 0xabababaf. >> > >> > And the application is not launched. >> > >> > Can somebody help me? >> >> What did you do about the boost libraries? If the answer is nothing >> then - The ones that LL supply are NOT compatible with visual studio >> 2008 and if you look at the stack trace you will see the crash is >> boost:: related. The options are find a copy of visual studio 2005 or >> build a newer boost and replace the p rebuilt boost libs with your own >> >> Robin >> > > > > -- > Regards, > Chandra K Kuchi > -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090622/03834966/attachment.htm From poppy at lindenlab.com Mon Jun 22 16:42:40 2009 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Mon, 22 Jun 2009 16:42:40 -0700 Subject: [sldev] How to use distcc on Linux using http-texture source In-Reply-To: <74s0ekwmed4ds40aJ4G5httc.alissa_sabre@yahoo.co.jp> References: <74s0ekwmed4ds40aJ4G5httc.alissa_sabre@yahoo.co.jp> Message-ID: <4A4016F0.4000104@lindenlab.com> Alissa Sabre wrote: > I grabbed the viewer source in the http-texture branch (aka Snowglobe) > from the public svn at r2451. I couldn't make use of distcc with it. > > How can I enable distcc? > > I tried followings: > > CXX="distcc i386-redhat-linux-g++" python.py configure > The configuration apparently worked, but the generated build.make > files contained hard-coded references to /usr/bin/g++ develop.py tries to setup CXX itself (line 323 in my checkout, probably dif in yours) You may want to not use develop.py. If you do, modify the CMakeCache.txt file afterward to force your changes. > P.S., I have a feeling I always ask distcc related question when the > viewer build system has changed... yeah, i'd rather not have distcc settings in the build, but it would require a number of changes on our setups here. I've filed an issue internally, but it's not a very high priority. + poppy From izzee at hotmail.co.uk Tue Jun 23 03:29:39 2009 From: izzee at hotmail.co.uk (izze euler) Date: Tue, 23 Jun 2009 10:29:39 +0000 Subject: [sldev] [HELP] How do I hide the debug window? Message-ID: Hi, I have compiled the SL source code using Visual C++ 2005 Express Edition. I compiled with setting "relwithdebinfo" and created an installer. I installed it on my computer and have subsequently uninstalled it, but I still get the debug window showing when I run Second Life. How can I hide this window? If I close the debug window, it closes Second Life. Also, should this window appear if I compile as a release version? Izze _________________________________________________________________ Get the best of MSN on your mobile http://clk.atdmt.com/UKM/go/147991039/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090623/31733450/attachment.htm From latifer at streamgrid.net Tue Jun 23 03:49:19 2009 From: latifer at streamgrid.net (Latif Khalifa) Date: Tue, 23 Jun 2009 12:49:19 +0200 Subject: [sldev] [HELP] How do I hide the debug window? In-Reply-To: References: Message-ID: <5ebce2ec0906230349g38fd9c46u57f6c15345cca809@mail.gmail.com> In the Advanced menu uncheck Console Window. -- L On Tue, Jun 23, 2009 at 12:29 PM, izze euler wrote: > Hi, > > I have compiled the SL source code using Visual C++ 2005 Express Edition. I > compiled with setting "relwithdebinfo" and created an installer. I installed > it on my computer and have subsequently uninstalled it, but I still get the > debug window showing when I run Second Life. How can I hide this window? If > I close the debug window, it closes Second Life. > > Also, should this window appear if I compile as a release version? > > Izze > > ________________________________ > Beyond Hotmail - see what else you can do with Windows Live. Find out more. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From carlo at alinoe.com Tue Jun 23 09:17:49 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 23 Jun 2009 18:17:49 +0200 Subject: [sldev] PATCH for VWR-13996 Message-ID: <20090623161749.GA1094@alinoe.com> Hiya, I attached a patch to http://jira.secondlife.com/browse/VWR-13996 If someone would be so kind to commit it to snowglobe? Thanks, -- Carlo Wood From colin.kern at gmail.com Tue Jun 23 09:24:10 2009 From: colin.kern at gmail.com (Colin Kern) Date: Tue, 23 Jun 2009 12:24:10 -0400 Subject: [sldev] Client bandwidth and server lag Message-ID: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> Hi everyone, There's this idea that seems pretty much ubiquitous in SL now, which is that everyone can help reduce sim lag by not setting their maximum bandwidth about 500 kbps. I want to get everyone's reaction to this, because to me it sounds like a myth. I think the logic that people are following is that since you're not downloading the textures as fast from the server, it puts a lower load on it. But you still have to download the same amount of data, and does it really make that much of a difference if you do it in 5 seconds instead of 20? I could maybe understand lag being more "bursty" with higher bandwidths, but it seems like if you have a fairly busy sim where avatars are teleporting in or moving around frequently, having lower bandwidth settings increases the chances of your download overlapping with someone else's, so the overall load on the server evens out. Also, it seems like it would be trivial to have the servers monitor and throttle their download requests to prevent getting overloaded from client texture requests. What are all your thoughts on this? Thanks, Colin Kern From soft at lindenlab.com Tue Jun 23 09:50:06 2009 From: soft at lindenlab.com (Soft) Date: Tue, 23 Jun 2009 11:50:06 -0500 Subject: [sldev] Client bandwidth and server lag In-Reply-To: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> Message-ID: On Tue, Jun 23, 2009 at 11:24 AM, Colin Kern wrote: > I think the logic that people are following is that since you're not > downloading the textures as fast from the server, it puts a lower load > on it. ?But you still have to download the same amount of data, and > does it really make that much of a difference if you do it in 5 > seconds instead of 20? ?I could maybe understand lag being more > "bursty" with higher bandwidths, but it seems like if you have a > fairly busy sim where avatars are teleporting in or moving around > frequently, having lower bandwidth settings increases the chances of > your download overlapping with someone else's, so the overall load on > the server evens out. It shouldn't matter. Resident connections are all traveling over the same handful of exit interfaces. With tens of thousands of residents' connections blended together, it's not going to make a difference whether individual connections are spiky or sustained if they're pushing the same amount of data over time. That said, an awful lot of people crank the bandwidth up to 1.5mbps because they figure they have a 1.5mbit connection or better. That's often a mistake. Most ISPs overstate the capacity their networks by a good margin, and it's very unlikely that even a 3 mbit DSL connection provides highly reliable 1.5mbit downstream. From joel.foner at gmail.com Tue Jun 23 10:08:08 2009 From: joel.foner at gmail.com (Joel Foner) Date: Tue, 23 Jun 2009 13:08:08 -0400 Subject: [sldev] Client bandwidth and server lag In-Reply-To: References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> Message-ID: <7c58f6610906231008h57a44eabn1d6bb6bfecc5dc26@mail.gmail.com> > > That said, an awful lot of people crank the bandwidth up to 1.5mbps > because they figure they have a 1.5mbit connection or better. That's > often a mistake. Most ISPs overstate the capacity their networks by a > good margin, and it's very unlikely that even a 3 mbit DSL connection > provides highly reliable 1.5mbit downstream. > But for most on cable or fiber it's only a part of what's available :) Is there a reason it's capped at 1.5Mbps? For what it's worth, an easy place to check your actual bandwidth is here http://www.speedtest.net/. Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090623/03a94907/attachment.htm From colin.kern at gmail.com Tue Jun 23 10:18:47 2009 From: colin.kern at gmail.com (Colin Kern) Date: Tue, 23 Jun 2009 13:18:47 -0400 Subject: [sldev] Client bandwidth and server lag In-Reply-To: <7c58f6610906231008h57a44eabn1d6bb6bfecc5dc26@mail.gmail.com> References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> <7c58f6610906231008h57a44eabn1d6bb6bfecc5dc26@mail.gmail.com> Message-ID: <77c421f00906231018o4814e6fep9c7e9cbbcffbfb87@mail.gmail.com> On Tue, Jun 23, 2009 at 1:08 PM, Joel Foner wrote: >> That said, an awful lot of people crank the bandwidth up to 1.5mbps >> because they figure they have a 1.5mbit connection or better. That's >> often a mistake. Most ISPs overstate the capacity their networks by a >> good margin, and it's very unlikely that even a 3 mbit DSL connection >> provides highly reliable 1.5mbit downstream. > > But for most on cable or fiber it's only a part of what's available :) ?Is > there a reason it's capped at 1.5Mbps? > For what it's worth, an easy place to check your actual bandwidth is here > http://www.speedtest.net/. > Joel I noticed in Snowglobe the cap is much higher (6 mbps, IIRC). I have heard some people saying that lowering your bandwidth helps with "rubber-banding", which I think makes more sense. If your bandwidth is too high, it might overload your own internet connection, causing latency problems. Colin From tateru.nino at gmail.com Tue Jun 23 10:35:54 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed, 24 Jun 2009 03:35:54 +1000 Subject: [sldev] Client bandwidth and server lag In-Reply-To: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> Message-ID: <4A41127A.9050402@gmail.com> It certainly makes circuits less fragile over long hauls and spotty links, reduces client-side lag on underpowered systems, and makes it less likely that your viewer will lose connection to the sim while you're mucking about with the file-selector or saving a snapshot. Large quantities of undelivered buffered data at the sim side is probably no better or worse than fat throughput rates, so I'll put the below in the 'myth' category. Colin Kern wrote: > Hi everyone, > > There's this idea that seems pretty much ubiquitous in SL now, which > is that everyone can help reduce sim lag by not setting their maximum > bandwidth about 500 kbps. I want to get everyone's reaction to this, > because to me it sounds like a myth. > > I think the logic that people are following is that since you're not > downloading the textures as fast from the server, it puts a lower load > on it. But you still have to download the same amount of data, and > does it really make that much of a difference if you do it in 5 > seconds instead of 20? I could maybe understand lag being more > "bursty" with higher bandwidths, but it seems like if you have a > fairly busy sim where avatars are teleporting in or moving around > frequently, having lower bandwidth settings increases the chances of > your download overlapping with someone else's, so the overall load on > the server evens out. Also, it seems like it would be trivial to have > the servers monitor and throttle their download requests to prevent > getting overloaded from client texture requests. > > What are all your thoughts on this? > > Thanks, > Colin Kern > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://dwellonit.taterunino.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090624/5256111d/attachment-0001.htm From robla at lindenlab.com Tue Jun 23 12:28:29 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 23 Jun 2009 12:28:29 -0700 Subject: [sldev] Snowglobe status / SNOW-60 Message-ID: <4A412CDD.2060503@lindenlab.com> Hi folks, We went silent a little longer than we hoped. RC2 looks like its going to be the one, though we did find one bug that's made us grit our teeth a little bit as we say that: https://jira.secondlife.com/browse/SNOW-60 The problem, in a nutshell, is that secondlife: urls (e.g. secondlife://Hippotropolis/128/128/128 ) aren't handled gracefully on the Mac, probably due to the rebranding work (that I did...heh) Anyone have some time to take a look at two things? 1. Quick fix for secondlife URLs on the Mac? 2. Generally more graceful secondlife: and slurl.com interaction on all platforms? We'd appreciate some help as we get our ducks in a row on a few other things. Thanks Rob From tigrospottystripes at gmail.com Tue Jun 23 13:08:48 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 23 Jun 2009 17:08:48 -0300 Subject: [sldev] Client bandwidth and server lag In-Reply-To: <77c421f00906231018o4814e6fep9c7e9cbbcffbfb87@mail.gmail.com> References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> <7c58f6610906231008h57a44eabn1d6bb6bfecc5dc26@mail.gmail.com> <77c421f00906231018o4814e6fep9c7e9cbbcffbfb87@mail.gmail.com> Message-ID: <4A413650.1090403@Gmail.com> Colin Kern escreveu: > On Tue, Jun 23, 2009 at 1:08 PM, Joel Foner wrote: > >>> That said, an awful lot of people crank the bandwidth up to 1.5mbps >>> because they figure they have a 1.5mbit connection or better. That's >>> often a mistake. Most ISPs overstate the capacity their networks by a >>> good margin, and it's very unlikely that even a 3 mbit DSL connection >>> provides highly reliable 1.5mbit downstream. >>> >> But for most on cable or fiber it's only a part of what's available :) Is >> there a reason it's capped at 1.5Mbps? >> For what it's worth, an easy place to check your actual bandwidth is here >> http://www.speedtest.net/. >> Joel >> > > I noticed in Snowglobe the cap is much higher (6 mbps, IIRC). > > I have heard some people saying that lowering your bandwidth helps > with "rubber-banding", which I think makes more sense. If your > bandwidth is too high, it might overload your own internet connection, > causing latency problems. > > Colin > With me, somthing I've noticed, usually when I have any noticeable packetloss, if I move the bandwidth throttle all the way down for a few (or several) seconds, the packetloss goes away, once it is gone I can move the throttle back up and packetloss doesn't seem to return (either until another login, or at least for a long time), there a few rare times where doing this doesn't have any effect on the PL though, I imagine that it has a different cause in these cases (I haven't tried Snowlobe yet) From teravus at gmail.com Tue Jun 23 13:41:53 2009 From: teravus at gmail.com (Teravus Ovares) Date: Tue, 23 Jun 2009 16:41:53 -0400 Subject: [sldev] Client bandwidth and server lag In-Reply-To: <4A413650.1090403@Gmail.com> References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> <7c58f6610906231008h57a44eabn1d6bb6bfecc5dc26@mail.gmail.com> <77c421f00906231018o4814e6fep9c7e9cbbcffbfb87@mail.gmail.com> <4A413650.1090403@Gmail.com> Message-ID: <34cc66250906231341u5da200delcea79e72e8ab610a@mail.gmail.com> This message is looking at it from a slightly different point of view, however these are some observations about what happens with the client and OpenSimulator. Firstly, the client will adjust the actual throttle settings based on packet statistics that it internally keeps. This means that the slider is a 'guideline' and the client will do it's own adjustment of that as the network conditions change. With debug on, one can see on the OpenSimulator console, the viewer requesting the throttle set lower and higher as network conditions change. When a user logs in to a Simulator for the first time and has the bandwidth slider at 1.5m, they're prone to having missing prim (prim not displayed but, physics wise, if your character hit one of these prim that your viewer didn't get an update, it would be there). Subsequent logins seem to work fine regardless, though it can take longer. (There's less to download in a sim once you've already been there[textures are cached, uuids are cached, etc]) When a user sets the throttle at 300-500, they enjoy the best experience. When a user sets the throttle to 1.5m and their connection is barely able to support a low connection of 250KB, they have the poorest experience. Additionally, it adds processing overhead on the UDP stack, Memory, and processor of the Simulator machine serving them. This, depending on the quality of the connection and the things that the client requests can become enough of a strain to bring the quality of the simulation down for everyone in some situations. This has been resolved recently, however, in the past, a single user experiencing connectivity issues with an improperly set throttle re-requesting images over and over again could consume 500MB worth of packet data queued up in the throttle system. Additionally, this could produce a situation where too many acks are appended to a packet. :) The moral of the story is, set your bandwidth slider as close to your functional connection speed to linden lab's network as you can. If you set it too low, things will come in slow and queue up in the memory of the server (reducing the available memory for other things). If you set it too high, your packets will get lost on a router somewhere between Linden Lab's servers and your computer. This will trigger the UDP Resend functionality... and consume memory and processing time on the server. Just because your Internet connection is really fast, doesn't necessarily mean that your connection from your computer to Linden Lab's servers is fast. If you set the network slider higher then your actual speed there, your experience will degrade. The client will attempt to compensate for it, but it will not always succeed. Regards Teravus On 6/23/09, Tigro Spottystripes wrote: > > > Colin Kern escreveu: > > On Tue, Jun 23, 2009 at 1:08 PM, Joel Foner wrote: > > > >>> That said, an awful lot of people crank the bandwidth up to 1.5mbps > >>> because they figure they have a 1.5mbit connection or better. That's > >>> often a mistake. Most ISPs overstate the capacity their networks by a > >>> good margin, and it's very unlikely that even a 3 mbit DSL connection > >>> provides highly reliable 1.5mbit downstream. > >>> > >> But for most on cable or fiber it's only a part of what's available :) Is > >> there a reason it's capped at 1.5Mbps? > >> For what it's worth, an easy place to check your actual bandwidth is here > >> http://www.speedtest.net/. > >> Joel > >> > > > > I noticed in Snowglobe the cap is much higher (6 mbps, IIRC). > > > > I have heard some people saying that lowering your bandwidth helps > > with "rubber-banding", which I think makes more sense. If your > > bandwidth is too high, it might overload your own internet connection, > > causing latency problems. > > > > Colin > > > With me, somthing I've noticed, usually when I have any noticeable > packetloss, if I move the bandwidth throttle all the way down for a few > (or several) seconds, the packetloss goes away, once it is gone I can > move the throttle back up and packetloss doesn't seem to return (either > until another login, or at least for a long time), there a few rare > times where doing this doesn't have any effect on the PL though, I > imagine that it has a different cause in these cases (I haven't tried > Snowlobe yet) > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From colin.kern at gmail.com Tue Jun 23 13:59:39 2009 From: colin.kern at gmail.com (Colin Kern) Date: Tue, 23 Jun 2009 16:59:39 -0400 Subject: [sldev] Client bandwidth and server lag In-Reply-To: <34cc66250906231341u5da200delcea79e72e8ab610a@mail.gmail.com> References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> <7c58f6610906231008h57a44eabn1d6bb6bfecc5dc26@mail.gmail.com> <77c421f00906231018o4814e6fep9c7e9cbbcffbfb87@mail.gmail.com> <4A413650.1090403@Gmail.com> <34cc66250906231341u5da200delcea79e72e8ab610a@mail.gmail.com> Message-ID: <77c421f00906231359n47278cei9cb036273527ac10@mail.gmail.com> Interesting. So your experience is that not only can having your bandwidth set too high degrade performance server-side, but having it set too low can too? Colin On Tue, Jun 23, 2009 at 4:41 PM, Teravus Ovares wrote: > This message is looking at it from a slightly different point of view, > however these are some observations about what happens with the client > and OpenSimulator. > > Firstly, the client will adjust the actual throttle settings based on > packet statistics that it internally keeps. ? ?This means that the > slider is a 'guideline' and the client will do it's own adjustment of > that as the network conditions change. ? With debug on, one can see on > the OpenSimulator console, the viewer requesting the throttle set > lower and higher as network conditions change. > > When a user logs in to a Simulator for the first time and has the > bandwidth slider at 1.5m, they're prone to having missing prim (prim > not displayed but, physics wise, if your character hit one of these > prim that your viewer didn't get an update, it would be there). > Subsequent logins seem to work fine regardless, though it can take > longer. ?(There's less to download in a sim once you've already been > there[textures are cached, uuids are cached, etc]) > > When a user sets the throttle at 300-500, they enjoy the best experience. > > When a user sets the throttle to 1.5m and their connection is barely > able to support a low connection of 250KB, they have the poorest > experience. ? ?Additionally, it adds processing overhead on the UDP > stack, Memory, and processor of the Simulator machine serving them. > This, depending on the quality of the connection and the things that > the client requests can become enough of a strain to bring the quality > of the simulation down for everyone in some situations. > > This has been resolved recently, however, in the past, a single user > experiencing connectivity issues with an improperly set throttle > re-requesting images over and over again could consume 500MB worth of > packet data queued up in the throttle system. ? ?Additionally, this > could produce a situation where too many acks are appended to a > packet. :) > > The moral of the story is, set your bandwidth slider as close to your > functional connection speed to linden lab's network as you can. ?If > you set it too low, things will come in slow and queue up in the > memory of the server (reducing the available memory for other things). > ?If you set it too high, your packets will get lost on a router > somewhere between Linden Lab's servers and your computer. ?This will > trigger the UDP Resend functionality... ?and consume memory and > processing time on the server. > > Just because your Internet connection is really fast, doesn't > necessarily mean that your connection from your computer to Linden > Lab's servers is fast. ? If you set the network slider higher then > your actual speed there, your experience will degrade. ? The client > will attempt to compensate for it, but it will not always succeed. > > Regards > > Teravus > > On 6/23/09, Tigro Spottystripes wrote: >> >> >> Colin Kern escreveu: >> > On Tue, Jun 23, 2009 at 1:08 PM, Joel Foner wrote: >> > >> >>> That said, an awful lot of people crank the bandwidth up to 1.5mbps >> >>> because they figure they have a 1.5mbit connection or better. That's >> >>> often a mistake. Most ISPs overstate the capacity their networks by a >> >>> good margin, and it's very unlikely that even a 3 mbit DSL connection >> >>> provides highly reliable 1.5mbit downstream. >> >>> >> >> But for most on cable or fiber it's only a part of what's available :) ?Is >> >> there a reason it's capped at 1.5Mbps? >> >> For what it's worth, an easy place to check your actual bandwidth is here >> >> http://www.speedtest.net/. >> >> Joel >> >> >> > >> > I noticed in Snowglobe the cap is much higher (6 mbps, IIRC). >> > >> > I have heard some people saying that lowering your bandwidth helps >> > with "rubber-banding", which I think makes more sense. ?If your >> > bandwidth is too high, it might overload your own internet connection, >> > causing latency problems. >> > >> > Colin >> > >> With me, somthing I've noticed, usually when I have any noticeable >> packetloss, if I move the bandwidth throttle all the way down for a few >> (or several) seconds, the packetloss goes away, once it is gone I can >> move the throttle back up and packetloss doesn't seem to return (either >> until another login, or at least for a long time), there a few rare >> times where doing this doesn't have any effect on the PL though, I >> imagine that it has a different cause in these cases (I haven't tried >> Snowlobe yet) >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > From tigrospottystripes at gmail.com Tue Jun 23 14:00:49 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Tue, 23 Jun 2009 18:00:49 -0300 Subject: [sldev] Client bandwidth and server lag In-Reply-To: <34cc66250906231341u5da200delcea79e72e8ab610a@mail.gmail.com> References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> <7c58f6610906231008h57a44eabn1d6bb6bfecc5dc26@mail.gmail.com> <77c421f00906231018o4814e6fep9c7e9cbbcffbfb87@mail.gmail.com> <4A413650.1090403@Gmail.com> <34cc66250906231341u5da200delcea79e72e8ab610a@mail.gmail.com> Message-ID: <4A414281.2020201@Gmail.com> I'm sorry, but how does that explain packetloss not returning when I move the slider back up? Teravus Ovares escreveu: > This message is looking at it from a slightly different point of view, > however these are some observations about what happens with the client > and OpenSimulator. > > Firstly, the client will adjust the actual throttle settings based on > packet statistics that it internally keeps. This means that the > slider is a 'guideline' and the client will do it's own adjustment of > that as the network conditions change. With debug on, one can see on > the OpenSimulator console, the viewer requesting the throttle set > lower and higher as network conditions change. > > When a user logs in to a Simulator for the first time and has the > bandwidth slider at 1.5m, they're prone to having missing prim (prim > not displayed but, physics wise, if your character hit one of these > prim that your viewer didn't get an update, it would be there). > Subsequent logins seem to work fine regardless, though it can take > longer. (There's less to download in a sim once you've already been > there[textures are cached, uuids are cached, etc]) > > When a user sets the throttle at 300-500, they enjoy the best experience. > > When a user sets the throttle to 1.5m and their connection is barely > able to support a low connection of 250KB, they have the poorest > experience. Additionally, it adds processing overhead on the UDP > stack, Memory, and processor of the Simulator machine serving them. > This, depending on the quality of the connection and the things that > the client requests can become enough of a strain to bring the quality > of the simulation down for everyone in some situations. > > This has been resolved recently, however, in the past, a single user > experiencing connectivity issues with an improperly set throttle > re-requesting images over and over again could consume 500MB worth of > packet data queued up in the throttle system. Additionally, this > could produce a situation where too many acks are appended to a > packet. :) > > The moral of the story is, set your bandwidth slider as close to your > functional connection speed to linden lab's network as you can. If > you set it too low, things will come in slow and queue up in the > memory of the server (reducing the available memory for other things). > If you set it too high, your packets will get lost on a router > somewhere between Linden Lab's servers and your computer. This will > trigger the UDP Resend functionality... and consume memory and > processing time on the server. > > Just because your Internet connection is really fast, doesn't > necessarily mean that your connection from your computer to Linden > Lab's servers is fast. If you set the network slider higher then > your actual speed there, your experience will degrade. The client > will attempt to compensate for it, but it will not always succeed. > > Regards > > Teravus > > On 6/23/09, Tigro Spottystripes wrote: > >> Colin Kern escreveu: >> >>> On Tue, Jun 23, 2009 at 1:08 PM, Joel Foner wrote: >>> >>> >>>>> That said, an awful lot of people crank the bandwidth up to 1.5mbps >>>>> because they figure they have a 1.5mbit connection or better. That's >>>>> often a mistake. Most ISPs overstate the capacity their networks by a >>>>> good margin, and it's very unlikely that even a 3 mbit DSL connection >>>>> provides highly reliable 1.5mbit downstream. >>>>> >>>>> >>>> But for most on cable or fiber it's only a part of what's available :) Is >>>> there a reason it's capped at 1.5Mbps? >>>> For what it's worth, an easy place to check your actual bandwidth is here >>>> http://www.speedtest.net/. >>>> Joel >>>> >>>> >>> I noticed in Snowglobe the cap is much higher (6 mbps, IIRC). >>> >>> I have heard some people saying that lowering your bandwidth helps >>> with "rubber-banding", which I think makes more sense. If your >>> bandwidth is too high, it might overload your own internet connection, >>> causing latency problems. >>> >>> Colin >>> >>> >> With me, somthing I've noticed, usually when I have any noticeable >> packetloss, if I move the bandwidth throttle all the way down for a few >> (or several) seconds, the packetloss goes away, once it is gone I can >> move the throttle back up and packetloss doesn't seem to return (either >> until another login, or at least for a long time), there a few rare >> times where doing this doesn't have any effect on the PL though, I >> imagine that it has a different cause in these cases (I haven't tried >> Snowlobe yet) >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > From teravus at gmail.com Tue Jun 23 14:21:26 2009 From: teravus at gmail.com (Teravus Ovares) Date: Tue, 23 Jun 2009 17:21:26 -0400 Subject: [sldev] Client bandwidth and server lag In-Reply-To: <4A414281.2020201@Gmail.com> References: <77c421f00906230924n2a6e9de9h1d85b70ea985b328@mail.gmail.com> <7c58f6610906231008h57a44eabn1d6bb6bfecc5dc26@mail.gmail.com> <77c421f00906231018o4814e6fep9c7e9cbbcffbfb87@mail.gmail.com> <4A413650.1090403@Gmail.com> <34cc66250906231341u5da200delcea79e72e8ab610a@mail.gmail.com> <4A414281.2020201@Gmail.com> Message-ID: <34cc66250906231421g7e9a47a6o74b72d3ea4017b05@mail.gmail.com> @TigroSpotty I did not attempt to explain why your packet loss doesn't return when you move the slider back up. However, since we're on this topic now, I would suggest that the viewer cache may have something to do with requesting less stuff. @Colin Yes. The packets have to be queued up somewhere and there needs to be a process within the simulator to figure out how much of that queue to send at least once a second. Additionally, the UDP protocol employs what is known as a 'resend' for reliable packets. This means that it will wait for an 'ack' from the client before tossing the packet out. If it doesn't get an ack back, it will be queued up to be sent to the client again in the resend 'throttle' slot. The resend functionality takes more 'resources' to do then the throttle queues. This is especially evident under load. Regards Teravus Regards Teravus On 6/23/09, Tigro Spottystripes wrote: > I'm sorry, but how does that explain packetloss not returning when I > move the slider back up? > > Teravus Ovares escreveu: > > This message is looking at it from a slightly different point of view, > > however these are some observations about what happens with the client > > and OpenSimulator. > > > > Firstly, the client will adjust the actual throttle settings based on > > packet statistics that it internally keeps. This means that the > > slider is a 'guideline' and the client will do it's own adjustment of > > that as the network conditions change. With debug on, one can see on > > the OpenSimulator console, the viewer requesting the throttle set > > lower and higher as network conditions change. > > > > When a user logs in to a Simulator for the first time and has the > > bandwidth slider at 1.5m, they're prone to having missing prim (prim > > not displayed but, physics wise, if your character hit one of these > > prim that your viewer didn't get an update, it would be there). > > Subsequent logins seem to work fine regardless, though it can take > > longer. (There's less to download in a sim once you've already been > > there[textures are cached, uuids are cached, etc]) > > > > When a user sets the throttle at 300-500, they enjoy the best experience. > > > > When a user sets the throttle to 1.5m and their connection is barely > > able to support a low connection of 250KB, they have the poorest > > experience. Additionally, it adds processing overhead on the UDP > > stack, Memory, and processor of the Simulator machine serving them. > > This, depending on the quality of the connection and the things that > > the client requests can become enough of a strain to bring the quality > > of the simulation down for everyone in some situations. > > > > This has been resolved recently, however, in the past, a single user > > experiencing connectivity issues with an improperly set throttle > > re-requesting images over and over again could consume 500MB worth of > > packet data queued up in the throttle system. Additionally, this > > could produce a situation where too many acks are appended to a > > packet. :) > > > > The moral of the story is, set your bandwidth slider as close to your > > functional connection speed to linden lab's network as you can. If > > you set it too low, things will come in slow and queue up in the > > memory of the server (reducing the available memory for other things). > > If you set it too high, your packets will get lost on a router > > somewhere between Linden Lab's servers and your computer. This will > > trigger the UDP Resend functionality... and consume memory and > > processing time on the server. > > > > Just because your Internet connection is really fast, doesn't > > necessarily mean that your connection from your computer to Linden > > Lab's servers is fast. If you set the network slider higher then > > your actual speed there, your experience will degrade. The client > > will attempt to compensate for it, but it will not always succeed. > > > > Regards > > > > Teravus > > > > On 6/23/09, Tigro Spottystripes wrote: > > > >> Colin Kern escreveu: > >> > >>> On Tue, Jun 23, 2009 at 1:08 PM, Joel Foner wrote: > >>> > >>> > >>>>> That said, an awful lot of people crank the bandwidth up to 1.5mbps > >>>>> because they figure they have a 1.5mbit connection or better. That's > >>>>> often a mistake. Most ISPs overstate the capacity their networks by a > >>>>> good margin, and it's very unlikely that even a 3 mbit DSL connection > >>>>> provides highly reliable 1.5mbit downstream. > >>>>> > >>>>> > >>>> But for most on cable or fiber it's only a part of what's available :) Is > >>>> there a reason it's capped at 1.5Mbps? > >>>> For what it's worth, an easy place to check your actual bandwidth is here > >>>> http://www.speedtest.net/. > >>>> Joel > >>>> > >>>> > >>> I noticed in Snowglobe the cap is much higher (6 mbps, IIRC). > >>> > >>> I have heard some people saying that lowering your bandwidth helps > >>> with "rubber-banding", which I think makes more sense. If your > >>> bandwidth is too high, it might overload your own internet connection, > >>> causing latency problems. > >>> > >>> Colin > >>> > >>> > >> With me, somthing I've noticed, usually when I have any noticeable > >> packetloss, if I move the bandwidth throttle all the way down for a few > >> (or several) seconds, the packetloss goes away, once it is gone I can > >> move the throttle back up and packetloss doesn't seem to return (either > >> until another login, or at least for a long time), there a few rare > >> times where doing this doesn't have any effect on the PL though, I > >> imagine that it has a different cause in these cases (I haven't tried > >> Snowlobe yet) > >> > >> _______________________________________________ > >> Policies and (un)subscribe information available here: > >> http://wiki.secondlife.com/wiki/SLDev > >> Please read the policies before posting to keep unmoderated posting privileges > >> > >> > > > > > > From thomas.shikami at online.de Tue Jun 23 17:18:23 2009 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed, 24 Jun 2009 02:18:23 +0200 Subject: [sldev] Compiling boost for 1.23 and above Message-ID: <4A4170CF.1070403@online.de> Since LL changed from static runtime libraries to shared runtime dlls, new libraries are needed. One of them is boost, and compiling it oneself and using it caused 0xbaadf00d for me in signals. I finally found out how to compile boost specifically for 1.23.4. Here's the full instructons so far for VS2005: (for VS2008 replace msvc-8.0 with msvc-9.0 and vs80 with vs90) * Download & extract boost_1_36_0.7z source for win32 into an empty folder (ex. "boost-source"). * Copy the "boost_1_36_0\boost" folder to "libraries\include\". NOTE: the Boost Wiki says to use the Visual Studio command prompt instead of the regular command prompt. * Open the visual studio command prompt * Change Directory into "boost_1_36_0\tools\jam\src" * Run "build.bat" * Change Directory back to "boost_1_36_0" ( cd ..\..\.. ) * Copy "boost_1_36_0\tools\jam\src\bin.ntx86\bjam.exe" to "boost_1_36_0\" * Using the command prompt, build the static libraries: (inside boost_1_36_0, if you have python 2.6 installed) o set PYTHON_ROOT=C:\Python26 o set PYTHON_VERSION=2.6 o bjam --build-dir=..\boost-build --toolset=msvc-8.0 --with-signals --with-program_options --with-regex --with-python variant=release link=static threading=multi runtime-link=shared define="_SECURE_SCL=0,_SECURE_STL=0" stage o bjam --build-dir=..\boost-build --toolset=msvc-8.0 --with-signals --with-program_options --with-regex --with-python variant=debug link=static threading=multi runtime-link=shared define="_SECURE_SCL=0,_SECURE_STL=0" stage * copy "boost_1_36_0\stage\lib\libboost_program_options-vc80-mt-1_36.lib" to "\libraries\i686-win32\lib\release\" * copy "boost_1_36_0\stage\lib\libboost_program_options-vc80-mt-gd-1_36.lib" to "\libraries\i686-win32\lib\debug\" * copy "boost_1_36_0\stage\lib\libboost_regex-vc80-mt-1_36.lib" to "\libraries\i686-win32\lib\release\" * copy "boost_1_36_0\stage\lib\libboost_regex-vc80-mt-gd-1_36.lib" to "\libraries\i686-win32\lib\debug\" * copy "boost_1_36_0\stage\lib\libboost_python-vc80-mt-1_36.lib" to "\libraries\i686-win32\lib\release\" * copy "boost_1_36_0\stage\lib\libboost_python-vc80-mt-gd-1_36.lib" to "\libraries\i686-win32\lib\debug\" * copy "boost_1_36_0\stage\lib\libboost_signals-vc80-mt-1_36.lib" to "\libraries\i686-win32\lib\release\" * copy "boost_1_36_0\stage\lib\libboost_signals-vc80-mt-gd-1_36.lib" to "\libraries\i686-win32\lib\debug\" The problem lies with deactivating secure SCL and secure STL in the viewer compiles. Libraries that are mixed between secure and non-secure seem to clash and cause weird crashing behaviour. Same can be done with VS2008 as well, resulting into a libraries package for boost, that works with both VS2005 and VS2008. Change Boost.cmake accordingly: # -*- cmake -*- include(Prebuilt) set(Boost_FIND_QUIETLY ON) set(Boost_FIND_REQUIRED ON) if (STANDALONE) include(FindBoost) set(BOOST_PROGRAM_OPTIONS_LIBRARY boost_program_options-mt) set(BOOST_REGEX_LIBRARY boost_regex-mt) set(BOOST_SIGNALS_LIBRARY boost_signals-mt) else (STANDALONE) use_prebuilt_binary(boost) set(Boost_INCLUDE_DIRS ${LIBS_PREBUILT_DIR}/include) if (WINDOWS) set(BOOST_VERSION 1_36) if (MSVC71) set(BOOST_PROGRAM_OPTIONS_LIBRARY optimized libboost_program_options-vc71-mt-${BOOST_VERSION} debug libboost_program_options-vc71-mt-gd-${BOOST_VERSION}) set(BOOST_REGEX_LIBRARY optimized libboost_regex-vc71-mt-${BOOST_VERSION} debug libboost_regex-vc71-mt-gd-${BOOST_VERSION}) set(BOOST_SIGNALS_LIBRARY optimized libboost_signals-vc71-mt-${BOOST_VERSION} debug libboost_signals-vc71-mt-gd-${BOOST_VERSION}) elseif (MSVC80) set(BOOST_PROGRAM_OPTIONS_LIBRARY optimized libboost_program_options-vc80-mt-${BOOST_VERSION} debug libboost_program_options-vc80-mt-gd-${BOOST_VERSION}) set(BOOST_REGEX_LIBRARY optimized libboost_regex-vc80-mt-${BOOST_VERSION} debug libboost_regex-vc80-mt-gd-${BOOST_VERSION}) set(BOOST_SIGNALS_LIBRARY optimized libboost_signals-vc80-mt-${BOOST_VERSION} debug libboost_signals-vc80-mt-gd-${BOOST_VERSION}) elseif (MSVC90) set(BOOST_PROGRAM_OPTIONS_LIBRARY optimized libboost_program_options-vc90-mt-${BOOST_VERSION} debug libboost_program_options-vc90-mt-gd-${BOOST_VERSION}) set(BOOST_REGEX_LIBRARY optimized libboost_regex-vc90-mt-${BOOST_VERSION} debug libboost_regex-vc90-mt-gd-${BOOST_VERSION}) set(BOOST_SIGNALS_LIBRARY optimized libboost_signals-vc90-mt-${BOOST_VERSION} debug libboost_signals-vc90-mt-gd-${BOOST_VERSION}) endif (MSVC71) elseif (DARWIN) set(BOOST_PROGRAM_OPTIONS_LIBRARY boost_program_options-mt) set(BOOST_REGEX_LIBRARY boost_regex-mt) set(BOOST_SIGNALS_LIBRARY boost_signals-mt) elseif (LINUX) set(BOOST_PROGRAM_OPTIONS_LIBRARY boost_program_options-mt) set(BOOST_REGEX_LIBRARY boost_regex-mt) set(BOOST_SIGNALS_LIBRARY boost_signals-mt) endif (WINDOWS) endif (STANDALONE) From tom at streamsense.net Tue Jun 23 17:41:56 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed, 24 Jun 2009 01:41:56 +0100 Subject: [sldev] OpenAL/Win32 Message-ID: <4A417654.9060606@streamsense.net> Hey all, I was wondering if anyone had any compiled OpenAL libraries for win32 compatible with the viewer. I tried to compile from source, but it seems like alut has been unplugged from OpenAL for a while. I'm trying to build an fmod-less windows viewer. :) ~T From tom at streamsense.net Tue Jun 23 18:17:59 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed, 24 Jun 2009 02:17:59 +0100 Subject: [sldev] OpenAL/Win32 In-Reply-To: <4A417654.9060606@streamsense.net> References: <4A417654.9060606@streamsense.net> Message-ID: <4A417EC7.7030501@streamsense.net> Hey, Ignore that last, I found the OpenAL 1.0 tagged release which compiles fine. :) Thanks Tom Thomas Grimshaw wrote: > Hey all, > > I was wondering if anyone had any compiled OpenAL libraries for win32 > compatible with the viewer. > I tried to compile from source, but it seems like alut has been > unplugged from OpenAL for a while. > > I'm trying to build an fmod-less windows viewer. :) > > ~T > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From alissa_sabre at yahoo.co.jp Wed Jun 24 05:43:34 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed, 24 Jun 2009 21:43:34 +0900 Subject: [sldev] How to use distcc on Linux using http-texture source In-Reply-To: <4A4016F0.4000104@lindenlab.com> References: <74s0ekwmed4ds40aJ4G5httc.alissa_sabre@yahoo.co.jp> <4A4016F0.4000104@lindenlab.com> Message-ID: <74nc9ds4ds4dwks8rfi4fv4.alissa_sabre@yahoo.co.jp> > > I grabbed the viewer source in the http-texture branch (aka Snowglobe) > > from the public svn at r2451. I couldn't make use of distcc with it. > > > > How can I enable distcc? > You may want to not use develop.py. If you do, modify the CMakeCache.txt file afterward to force your changes. Hmm. So, the suggestion is not to use develop.py, isn't it? Can somebody give me a pointer to a cover-all instruction to build the viewer without using develop.py, please? I remember in the past messages on this list there are several _clues_ on it but I see no step-by-step or options-to-options explanation. Alissa -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From soft at lindenlab.com Wed Jun 24 06:13:49 2009 From: soft at lindenlab.com (Soft) Date: Wed, 24 Jun 2009 08:13:49 -0500 Subject: [sldev] Open Source Meeting Thu 2pm - Agenda reminder Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda: http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From aleric.inglewood at gmail.com Wed Jun 24 07:14:52 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 24 Jun 2009 16:14:52 +0200 Subject: [sldev] Open Source Meeting Thu 2pm - Agenda reminder Message-ID: <1e01733d0906240714u6c9620ffi83685a83421b1e5e@mail.gmail.com> On Wed, Jun 24, 2009 at 08:13:49AM -0500, Soft wrote: > Our Thursday open source meetings take place at 2pm. If there is > anything you would like on the agenda: > http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda It's not really clear if I should add jira things on that page. 1) There is no jira (VWR-xxxx) link at the moment at all. 2) There are two links at the bottom "Triage list of issues with the SLDev Viewer" and "Triage of "Source Code issues" that both lead to a long list of VWR-xxxx items, but I don't understand how I can add anything to that list. I'd like to add VWR-13996. I posted yesterday to this list that I wrote a patch and got no reaction. The patch is very simple (a one liner) and I'm convinced that it's correct. Because I can never be on the Open Source Meetings on Thursday (I'm am not home then), I will add some final remark to the jira and add it to the agenda nevertheless. Please let me know if I did something wrong. Aleric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090624/df90e84d/attachment.htm From monkowsk at watson.ibm.com Wed Jun 24 07:48:36 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 24 Jun 2009 10:48:36 -0400 Subject: [sldev] Open Source Meeting Thu 2pm - Agenda reminder In-Reply-To: <1e01733d0906240714u6c9620ffi83685a83421b1e5e@mail.gmail.com> References: <1e01733d0906240714u6c9620ffi83685a83421b1e5e@mail.gmail.com> Message-ID: <4A423CC4.8010406@watson.ibm.com> Aleric, If it's a patch to a VWR issue, that is not exclusively an open source code issue, it will get discussed at the Bug Triage meeting http://wiki.secondlife.com/wiki/Bug_triage The open source code issues get discussed at the Open Source Meeting. I think SnowGlobe exclusive issues fall into the latter category, but I'm not sure. Mike Aleric Inglewood wrote: > On Wed, Jun 24, 2009 at 08:13:49AM -0500, Soft wrote: > > Our Thursday open source meetings take place at 2pm. If there is > > anything you would li